SaaS и продуктовые ИТ-компании

Рост SaaS на “цифровом рабочем месте” переносит контроль ближе к пользователю и администраторам заказчика — и именно там чаще всего возникают ошибки и злоупотребления. Риски усиливаются из-за того, что в SaaS почти всё делается через роли, сессии, токены и API.

• Аутентификация и сеансы: слабые политики MFA, некорректная обработка SSO/OAuth, “длинные” сессии, утечки refresh-токенов, отсутствие привязки сессии к устройству/контексту, уязвимости в переключении учётных записей.
• RBAC / ABAC: слишком широкие роли “по умолчанию”, отсутствие разделения обязанностей, ошибки наследования прав, опасные админ-функции без “step-up auth”, отсутствие процедур “break-glass”.
• Теневые интеграции: пользователи подключают сторонние приложения через OAuth/ключи, создавая неконтролируемые каналы доступа и выгрузки данных.
• Инсайдерские действия: экспорт данных, массовые удаления/изменения, изменение правил шаринга, отключение журналирования — и всё это часто выглядит как “легитимная активность”.

В SaaS ключевой риск — нарушение границ арендаторов (tenants): одна ошибка в контексте арендатора может превратиться в cross-tenant доступ.

• Изоляция на уровне приложений: ошибки в tenant-context (IDOR, подмена tenant_id), небезопасные “глобальные” запросы, проблемы безопасности row-level, смешивание кэшей и очередей задач.
• Изоляция на уровне инфраструктуры: общие базы/кластер, совместно используемые хранилища и секреты, а также неверные политики сетевой сегментации.
• Шаринг и коллаборация: публичные ссылки, гостевые пользователи, совместные пространства, шаблоны прав — частый источник “случайной утечки”.
• Резервные копии и экспорты: бэкапы, снапшоты, аналитические витрины, поисковые индексы и логи могут стать “обходным путём” к данным.

Секреты — это кровь SaaS-системы: токены, ключи, пароли, сертификаты, подписи, KMS-ключи. Они часто утекают не через “взлом”, а через процессы.

• секреты в репозиториях, CI-логах, переменных среды, helm-values, IaC;
• один ключ “на всё” вместо разделения по средам/тенантам;
• слабая ротация, отсутствие сканирования секретов, нет политики минимальных прав для сервис-аккаунтов;
• небезопасное хранение/выдача токенов интеграций (веб-хуки, ключи API, PAT).

SaaS релизится часто, поэтому цепочка поставок разработки становится критической поверхностью атаки.

• CI/CD: подмена артефактов, компрометация runner’ов, небезопасные пайплайны, отсутствие подписания артефактов, слабый контроль прав на деплой.
• Зависимости и контейнеры: уязвимые зависимости, тайпсквоттинг, компрометированные пакеты, base images с CVE, отсутствие SBOM и политики обновлений.
• IaC: ошибки в Terraform/CloudFormation, “дрейф” конфигураций, неконтролируемые изменения через консоль.

В реальности много инцидентов начинается с конфигурационных ошибок облака, а не с “0-day”.

• публичные бакеты/снапшоты, лишние группы безопасности, открытые панели администрирования;
• избыточные IAM-права, отсутствие политик границ, незащищённые endpoints метаданных;
• неправильные настройки WAF/rate limits, слабая защита API, отсутствие сегментации;
• слабые настройки шифрования, ключи без ограничений использования.

Даже сильная защита ломается, если нет наблюдаемости и готовности к расследованию — и если не учтены требования клиентов/регуляторов.

• Logging и аудит: неполные журналі аудита (кто, что, когда, откуда, куда), нет корреляции действий, слабая ретенция, нет защиты логов от модификации.
• IR readiness: нет runbook’ов, нет “форензик-готовности”, не проверялись сценарии утечки токенов/компрометации админа/массового экспорта.
• Data residency & governance: где реально живут данные (основные, бэкапы, логи, аналитика), как работает удаление/retention, как управляются субпроцессоры, как выполняются требования GDPR, DPAs и корпоративных клиентов.
• Выбор стандартов: риск “тащить всё” (SOC 2 + ISO 27001 + NIST + CIS + отраслевые) без маппинга контролей — дорого и хаотично; нужен минимальный набор базовых контролей, который покрывает максимум требований.