Атаки на цепочку поставок SaaS: уроки для руководителей
Инциденты начала 2025 года показывают, что периметр безопасности компании теперь проходит через SaaS-провайдеров. Что это означает на практике.
В начале 2025 года несколько крупных инцидентов напомнили о том, что когда атакующие не могут пробить периметр напрямую, они атакуют через поставщиков. В контексте современного бизнеса это означает в первую очередь SaaS-провайдеров: инструменты для работы, коммуникаций, разработки, управления данными.
Это не новая тема. SolarWinds в 2020 году обозначил этот вектор предельно ясно. Но инциденты в SaaS-контексте имеют свою специфику, которую стоит понять отдельно.
Чем SaaS-зависимость отличается от обычного стороннего ПО
Когда компания устанавливала стороннее ПО на сервер, она контролировала версию, момент обновления и сетевой доступ. В случае SaaS всё это под контролем провайдера.
Это означает:
- обновление, которое вносит уязвимость или компрометирует систему, происходит без ведома клиента;
- клиент не видит, что происходит внутри инфраструктуры провайдера;
- аутентификационные токены и интеграции работают постоянно, и их компрометация открывает доступ к данным клиента.
Для большинства компаний SaaS-стек сейчас шире, чем когда-либо. Маркетинг, продажи, HR, финансы, разработка - каждый отдел работает с несколькими специализированными инструментами. Каждый из них - потенциальная точка входа.
Что показали инциденты начала 2025 года
Общая картина нескольких инцидентов этого периода:
Первое - атаки через интеграции. Злоумышленники компрометируют не основной SaaS-инструмент, а небольшой вспомогательный сервис, у которого есть OAuth-доступ к основному. Через него получают данные или возможность действовать от имени пользователей.
Второе - атаки через CI/CD и инструменты разработки. Компрометация инструментов, используемых командой разработки, позволяет внедрить изменения в код продукта. Это классический supply chain attack, перенесённый в облачную среду.
Третье - компрометация credential store. Инструменты для хранения конфигураций и секретов - особая цель, потому что через них можно получить доступ ко всей остальной инфраструктуре.
Что это означает для руководителя
Большинство руководителей не могут и не должны погружаться в технические детали каждого инцидента. Но несколько управленческих вопросов стали актуальными независимо от масштаба компании.
Первый вопрос: есть ли у нас актуальный список SaaS-инструментов с указанием, к каким данным и системам они имеют доступ? Большинство компаний, которым я задаю этот вопрос, не имеют такого списка. Это делает управление рисками невозможным.
Второй вопрос: есть ли процедура проверки новых SaaS-инструментов перед тем, как они получают доступ к корпоративным данным? Или новый инструмент появляется, когда сотрудник его просто регистрирует?
Третий вопрос: есть ли у нас возможность быстро отозвать доступ инструмента, если его провайдер сообщил об инциденте? Это требует централизованного управления OAuth-доступами, которого во многих компаниях нет.
Практический минимум
Полное управление SaaS-рисками - зрелая практика, которая строится постепенно. Но есть минимальный набор действий, который имеет смысл сделать в ближайшее время:
- Провести инвентаризацию SaaS-инструментов с указанием владельца от бизнеса и данных, к которым они имеют доступ.
- Проверить OAuth-доступы в основных корпоративных аккаунтах и отозвать доступы неиспользуемых или неизвестных приложений.
- Установить процедуру: новый SaaS-инструмент с доступом к корпоративным данным проходит минимальный security review.
- Убедиться, что у критически важных SaaS-провайдеров подписаны условия обработки данных с уведомлением об инцидентах.
Это не защита от всех угроз. Но это базовая видимость, без которой остальные меры теряют смысл.