По данным CrowdStrike Global Threat Report 2025, 75% вторжений в 2024 году использовали действительные учётные данные, а IBM X-Force фиксирует рост credential-based атак на 71% год к году. Ранее утро - в SIEM падает алерт: сервисный аккаунт SaaS-платформы, неактивный три месяца, начинает массово вычитывать клиентские записи через API. Токен валидный, GeoIP - офисная подсеть. Сотрудник, которому принадлежал аккаунт, уволился в прошлом квартале.
Знакомо? Это компрометация SaaS платформы через Valid Accounts (T1078, Initial Access). Большинство SOC-команд её пропускают - потому что не строят baseline для cloud-логов. Алерт выглядит как легитимная активность, пока не начнёшь копать.
Shared Responsibility Model: где SOC теряет видимость в SaaS
Shared responsibility model облако разделяет зоны ответственности просто: SaaS-провайдер закрывает инфраструктуру (физические дата-центры, сеть, базовый код, патчинг серверных компонентов), клиент - конфигурацию, управление доступом, защиту данных в SaaS и мониторинг пользовательской активности. Подробнее - в нашем статье о мисконфигурация облака атаки.
На практике для SOC это слепые зоны. Провайдер отдаёт audit log уровня приложения: кто залогинился, какой файл открыл, какой API-эндпоинт вызвал. Но вы не видите:
- сетевой трафик между микросервисами внутри платформы провайдера
- конфигурацию tenant isolation multitenancy на инфраструктурном уровне (как именно разделены данные между арендаторами - а это вопрос на миллион)
- уязвимости в зависимостях и SDK провайдерского стека
Конкретные цифры: у Google Workspace audit log содержит порядка 50 типов событий, у Microsoft 365 - более 100, у Salesforce - зависит от лицензии. Если SOC не инвентаризировал, какие именно события и поля доступны для каждого SaaS-приложения, - detection строится на неполных данных. И это не теория - это то, что я вижу в каждом втором проекте.
Векторы компрометации SaaS-платформы: TTPs атакующих
Credential-based атаки: от stuffing до MFA fatigue
По данным Verizon DBIR 2025, 38% утечек данных связаны с кражей учётных данных. Количество cloud-инцидентов выросло на 26% год к году (CrowdStrike). В SaaS-контексте credential-based атаки - основной вектор initial access, и тут ничего не меняется уже третий год подряд.Credential Stuffing (T1110.004, Credential Access) - автоматизированный перебор пар логин/пароль из утекших баз. Атакующий прогоняет базу против публичных login-эндпоинтов (
login.microsoftonline.com, SSO-портал организации). Совпало - доступ к тенанту с правами жертвы.Cloud Accounts (T1078.004, Initial Access / Persistence) - использование скомпрометированных облачных учёток. Украден SSO-токен через фишинг или infostealer - атакующий получает доступ ко всем SaaS-приложениям, интегрированным с IdP, без знания пароля к каждому. CrowdStrike фиксирует: вредоносное использование GenAI для фишинга удвоилось в 2024 году. IBM X-Force добавляет: генерация фишинговых писем с помощью GenAI быстрее в 11.4 раза при сопоставимом качестве. Порог входа для атакующего падает.
MFA fatigue - MFA Request Generation (T1621, Credential Access). Атакующий, знающий пароль, бомбардирует жертву push-уведомлениями. В 2-3 часа ночи пользователь нажимает "Approve", чтобы прекратить поток. Через этот вектор были скомпрометированы учётные записи в ряде публичных инцидентов с SaaS-платформами. Обход MFA (T1556.006, Defense Impairment / Credential Access) - отдельная категория: перехват OTP, компрометация IdP, злоупотребление recovery-процедурами.
Три detection-сигнала, которые нужно ловить: аномальное количество неуспешных логинов с одного IP (stuffing), успешный логин из нового GeoIP после серии failed attempts (account takeover), множественные MFA-запросы за короткий период (fatigue). Каждый требует калибровки порогов под конкретную организацию - дефолтные значения из документации SIEM-вендора тут не работают.
SaaS misconfiguration и утечка данных в облаке
По данным BetterCloud (2025), 56% IT-команд фиксируют случаи внешнего oversharing данных, а 53% называют публично расшаренные файлы с чувствительной информацией главной проблемой.Типичные SaaS misconfiguration риски - вещи, которые встречаются на каждом аудите: файл в SharePoint/Google Drive с настройкой "anyone with the link", API-ключ сервисного аккаунта с избыточными правами, S3-бакет с public access. Каждый из этих кейсов даёт атакующему путь к данным через Data from Cloud Storage (T1530, Collection) - без эксплуатации уязвимостей. Зачем ломать, если дверь открыта?
Для мультитенантных SaaS-платформ misconfiguration на уровне tenant isolation - отдельная история. Если изоляция между арендаторами реализована на уровне приложения (row-level security в БД, фильтрация по
tenant_id в API), а не на уровне инфраструктуры - ошибка в одном API-эндпоинте может дать IDOR между тенантами. На пентестах SaaS-платформ IDOR через tenant_id в path/query parameters - один из первых чеков. В Burp Suite это проверяется подстановкой чужого tenant_id в авторизованный запрос: если в ответе приходят данные другого арендатора - изоляция сломана, Broken Access Control (A01:2021) в чистом виде.Для SOC ключевой detection-сигнал: обращение пользователя к ресурсам, не принадлежащим его тенанту. Если SaaS-провайдер логирует
tenant_id в audit log - это поле обязано присутствовать в корреляционных правилах. GCP Security Command Center и AWS IAM Access Analyzer частично закрывают этот gap для cloud-инфраструктуры, но SaaS-уровень остаётся слепой зоной без SSPM.Insider threat и скомпрометированные легитимные аккаунты
BetterCloud (2025 State of SaaS Report): 48% IT-команд обеспокоены пропуском шагов offboarding при увольнении сотрудников. Insider threat - злонамеренный инсайдер или скомпрометированный легитимный аккаунт - стабильно в топе SaaS-рисков.Сценарий из вступления - не синтетический. Сервисные аккаунты, неотозванные API-токены уволенных сотрудников, OAuth-гранты сторонних приложений с избыточными scope - артефакты, которые копятся в SaaS-среде и становятся точками входа. Отдельная боль - shadow IT: SaaS-приложения, подключённые сотрудниками без ведома IT. По данным BetterCloud, shadow IT остаётся актуальной проблемой. Каждое неучтённое приложение с OAuth-грантом на чтение корпоративной почты - потенциальный канал утечки данных в облаке.
Detection insider threat в SaaS требует поведенческого baseline: объём загрузок файлов, время активности, типичные API-вызовы для каждого пользователя. Аномалия - это отклонение от персонального или группового паттерна, а не абсолютное пороговое значение. Алерт "скачано больше 50 файлов" бесполезен, если у аналитика это нормальный понедельник.
Detection для SaaS-среды: baseline, алерты и правила корреляции
Что мониторить в cloud-логах
Для detection-пайплайна SOC-команде нужны минимум четыре категории событий из каждого SaaS-приложения:- Аутентификация: успешные и неуспешные логины, MFA-события, SSO-токены, изменения паролей - покрывает T1078, T1110, T1621
- Авторизация и привилегии: изменения ролей, добавление администраторов, создание сервисных аккаунтов, назначение OAuth-грантов - Privilege Escalation
- Доступ к данным: загрузка файлов, экспорт отчётов, API-вызовы к чувствительным эндпоинтам - T1530
- Конфигурация: изменение настроек sharing, отключение MFA, модификация IP-whitelist, добавление интеграций - A05:2021
user_id, IP, timestamp, action, resource, geo, device_info. Без стандартизации полей корреляция между несколькими SaaS-приложениями невозможна. Я видел SOC-команды, которые полгода собирали логи из трёх SaaS и не могли скоррелировать ни одного события - потому что userId в одном, user_email в другом и actor.id в третьем.Примеры правил корреляции
Sigma-правило для детектирования массовой загрузки файлов из SaaS-приложения (пороги требуют калибровки под конкретную организацию):
YAML:
title: SaaS Mass File Download - Possible Data Exfiltration
status: experimental
logsource:
product: office365
service: audit
detection:
selection:
Operation: FileDownloaded
condition: selection | count() by UserId > 50
timeframe: 15m
level: highlogin_success по полям UserId, src_ip, geo_country - два успешных логина за менее чем 30 минут из стран, расстояние между которыми превышает 500 км. Большинство SIEM поддерживают такую корреляцию через enrichment GeoIP и таймфреймы.Третий критичный detection-кейс - MFA fatigue: более 5 событий
mfa_challenge с result: denied для одного UserId за 10 минут, за которыми следует mfa_challenge с result: approved. Этот паттерн с высокой точностью указывает на T1621 (MFA Request Generation, Credential Access). Если у вас в SIEM нет такого правила - добавьте сегодня, серьёзно.Baseline: что считать нормой
Detection без baseline - генератор false positive. Дежурный аналитик утонет в алертах за первую смену. Для SaaS-среды baseline строится по трём осям:- Пользовательский: типичное время логина, объём загрузок, набор используемых приложений для каждой роли
- Приложений: нормальный объём API-вызовов, типичные интеграции, стандартные настройки sharing
- Конфигурационный: зафиксированные настройки безопасности (MFA включён, sharing ограничен, admin-список утверждён) - любое изменение генерирует алерт
SSPM инструменты: trade-off таблица для выбора
SaaS Security Posture Management (SSPM) - класс инструментов для непрерывного мониторинга конфигураций SaaS-приложений. На практике SSPM путают с CSPM, CASB и DSPM. Различия критичны, и путаница стоит денег:| Класс решения | Преимущества | Ограничения | Когда использовать | Когда не использовать |
|---|---|---|---|---|
| SSPM (Obsidian Security, Wing Security, AppOmni) | Аудит конфигураций SaaS, OAuth-грантов, избыточных прав, compliance drift | Не видит содержимое данных; покрытие ограничено списком поддерживаемых SaaS (обычно 50-150 приложений) | Корпоративный стек из 30+ SaaS-приложений с требованием compliance | Нужна DLP, контентная инспекция или inline-контроль |
| CSPM (Checkov, AWS Config, GCP SCC) | Аудит IaC-конфигураций, cloud-инфраструктуры (IAM, S3, VPC) | Не покрывает SaaS-уровень - только IaaS/PaaS | Аудит облачной инфраструктуры, на которой работает SaaS-платформа | SaaS-приложения без собственной cloud-инфраструктуры |
| CASB (Netskope, Zscaler, MS Defender for Cloud Apps) | Inline/API контроль доступа, shadow IT discovery, базовая DLP | Latency при inline-режиме, ограниченная глубина posture management | Контроль доступа к SaaS, обнаружение shadow IT | Глубокий аудит конфигураций конкретных приложений |
| DSPM (Varonis, Dig Security) | Классификация данных, мониторинг доступа к чувствительной информации | Высокий false positive при автоклассификации, ресурсоёмкий тюнинг | Локализация PII/PCI-данных в SaaS-среде | Управление конфигурациями и правами доступа |
Из практики внедрения: Obsidian Security и Wing Security дают реальную ценность для аудита OAuth-грантов и обнаружения конфигурационного drift. Иллюзия контроля начинается, когда организация полагается на SSPM как на единственный инструмент - без SIEM-интеграции, без incident response playbook и без поведенческого baseline. SSPM показывает конфигурационный drift, но не детектирует активную атаку в реальном времени. Это два разных инструмента для двух разных задач, и один другой не заменяет.
Zero Trust SaaS архитектура: конкретные контроли для detection
Zero trust SaaS архитектура - не продукт и не галочка в compliance-отчёте, а принцип: каждый запрос к ресурсу проверяется независимо от источника. Для SaaS-среды это три конкретных контроля:
- Conditional Access: доступ к SaaS зависит от контекста - устройство (managed/unmanaged), геолокация, время, risk score пользователя. В Entra ID это Conditional Access Policies, в Okta - Adaptive MFA. Настройка занимает день, экономит месяцы разгребания инцидентов.
- Least Privilege с JIT-доступом: каждый пользователь получает минимальный набор прав для текущей задачи. Административные операции - через just-in-time запрос с автоматическим отзывом через фиксированный интервал. Постоянный admin-доступ "на всякий случай" - подарок атакующему.
- Микросегментация через ZTNA: вместо VPN - доступ к конкретному SaaS-приложению через ZTNA (Cloudflare Access, Zscaler Private Access). Blast radius при компрометации endpoint ограничивается одним приложением, а не всей корпоративной сетью.
Чеклист аудита безопасности SaaS
Готовый чеклист - можно передать SOC-команде или включить в отчёт как есть:SOC-команда выстраивает процесс вокруг этого чеклиста: ежемесячный пересмотр пунктов 6-7, еженедельный мониторинг по пунктам 5 и 11, continuous monitoring по пунктам 3-4.
Большинство SOC-команд, с которыми доводилось работать, мониторят SaaS-стек по остаточному принципу: настроили интеграцию с SIEM при подключении приложения и забыли. Baseline не строят, OAuth-гранты не ревизуют, offboarding в SaaS - процесс, который живёт между HR и IT, и ни одна из сторон не проверяет его полноту. При этом через SaaS идёт основная масса рабочих данных.
Проблема не в инструментах - SSPM, CASB, DSPM решают свои задачи. Проблема в том, что безопасность SaaS до сих пор воспринимается как зона ответственности "кого-то другого". Провайдера. Команды Identity. DevOps. А потом в incident response выясняется, что сервисный аккаунт с правами admin висел без ротации токена полтора года, и никто не знает, кто его создал.
Прогноз: количество cloud-инцидентов через valid accounts продолжит расти, потому что инфостилеры дают атакующим сессионные токены в обход MFA. SOC-команды, которые не научатся строить поведенческий baseline для SaaS-приложений, будут узнавать о компрометации из уведомлений провайдера, а не из собственных алертов. Если ваш SOC только начинает выстраивать detection для SaaS-стека - на codeby.net обсуждают подходы к построению baseline и корреляции cloud-событий под конкретные SIEM.
Последнее редактирование модератором:
