Конфигурация облака — новый слой управления, оставшийся без контроля

Привычный периметр в облаке исчезает, и его место занимает конфигурация облачных сервисов. Это новый слой управления, который, согласно модели разделения ответственности (shared responsibility model), находится в зоне ответственности пользователя.

Как выглядят ошибки конфигурации (мисконфигурации) на практике:

• бакет объектного хранилища с публичным доступом на чтение,

• группа безопасности с правилом, открывающим доступ с 0.0.0.0/0,

• управляемая база данных, доступная из интернета,

• root-аккаунт без MFA,

• ключ доступа сервисного аккаунта, который не ротировался два года.

Высокая динамичность и сложность облачной среды делают ручной контроль конфигурации неэффективным. В облаке множество разнотипных объектов: виртуальные машины, бакеты, контейнеры, кластеры Kubernetes, управляемые базы данных, сервисные аккаунты, и у каждого свои настройки и свои риски. Среда меняется ежечасно: сотрудник с достаточными правами может назначить виртуальной машине публичный IP, создать пользователя с избыточными привилегиями или отключить шифрование у бакета, и ИБ-специалист об этом не узнает. Защита традиционными решениями (NGFW, антивирусы, сканеры уязвимостей) оказывается недостаточной, т.к. они не контролируют слой конфигурации.

В результате ошибки в конфигурации становятся главной угрозой безопасности в публичном облаке: по данным Cloud Security Alliance, в 4 из 8 разобранных облачных инцидентов присутствовали ошибки в настройке облачных сервисов или недостатки в управлении доступом.

Специально для контроля этого слоя управления облачной инфраструктурой и были созданы решения класса CSPM.

Чем грозит отсутствие контроля конфигурации облака на практике

Показательный инцидент произошёл в Cisco. Инженер уволился, но его доступ к облачной инфраструктуре не был отозван. Спустя пять месяцев бывший сотрудник подключился к облачной среде под сохранившимися учётными данными и за два часа удалил 456 виртуальных машин, обеспечивавших работу сервиса WebEx Teams. Последствия: сервис был недоступен до двух недель, пострадали более 16 000 аккаунтов клиентов, Cisco понесла миллионные убытки, а злоумышленник получил два года лишения свободы и штраф.

Инцидент стал возможен из-за четырёх недостатков в управлении конфигурацией облака, и все они находятся в зоне контроля CSPM:

• Учётная запись сотрудника не была отозвана при увольнении. Чтобы снизить подобные риски, рекомендуется использовать федерацию удостоверений: тогда блокировка учётной записи в корпоративном каталоге автоматически закрывает и доступ к облаку. Если в облаке остаются локальные (не федеративные) пользователи, CSPM об этом сообщит.

• Учётная запись не была отключена после пяти месяцев неактивности. Никто не заметил, что учётные данные не используются. CSPM автоматически отслеживает неиспользуемые учётные записи, помогая вовремя их отключать.

• Отсутствие ротации учётных данных. Своевременная смена пароля и ключей доступа предотвратила бы инцидент. Проверка срока действия ключей и паролей — стандартное правило любого CSPM.

• Избыточные привилегии. Учётная запись обладала правами, достаточными для массового удаления части инфраструктуры. CSPM находит учётные записи с избыточными правами и помогает привести их в соответствие с принципом минимальных привилегий.

Как работает CSPM

CSPM подключается к облаку по API без агентов и без вмешательства в работу приложений.

Шаг 1. Инвентаризация. Платформа собирает данные обо всех ресурсах, развёрнутых в облаке, и их конфигурации через API облачного провайдера и строит полную картину инфраструктуры. Это решает базовую задачу наглядности (visibility): команда видит, какие объекты действительно развёрнуты и как связаны между собой. Инвентаризация также помогает обнаруживать неучтённые ресурсы, что снижает риски появления теневого ИТ (shadow IT).

Шаг 2. Аудит облачной инфраструктуры. Проверяет конфигурации ресурсов на соответствие встроенным правилам безопасности и на соответствие требованиям стандартов (например, 152-ФЗ).

Шаг 3. Приоритизация. Анализирует обнаруженные риски и ранжирует их по степени критичности. Так ИБ-команда в первую очередь устраняет те проблемы, которые представляют наибольшую угрозу безопасности.

Шаг 4. Оповещения и рекомендации. Уведомляет ответственных лиц и выдаёт рекомендации по исправлению каждой проблемы.

Шаг 5. Предотвращение угроз. Сотрудник, получив рекомендации, исправляет ошибки в настройках до того, как злоумышленник ими воспользуется.

Этот процесс непрерывный: облако динамично, конфигурация меняется каждый день, поэтому CSPM выполняет все шаги — от инвентаризации до рекомендаций — регулярно и автоматически. Таким образом ошибки конфигурации перестают быть неконтролируемой угрозой.

Как выбрать CSPM

Рынок продуктов класса CSPM в России растёт. Чтобы выбрать решение, которое будет отвечать вашим потребностям и современным стандартам, проверьте его по следующему списку вопросов:

Выявление токсичных комбинаций рисков для корректной приоритизации угроз в облаке

Типичный пример трех «жёлтых» алертов где-то в середине очереди:

• виртуальная машина с публичным IP;

• привязанная к виртуальной машине учётная запись (сервисный аккаунт / Agency);

• доступ учётной записи к бакету с чувствительными данными.

Если рассматривать каждый из этих алертов по отдельности, ни один из них не выглядит критичным: средний приоритет, десятки похожих алертов, устранение откладывается на неопределённый срок.

Контекстная приоритизация меняет картину: три «жёлтых» сигнала складываются в один непрерывный путь атаки от интернета до конфиденциальных данных, а это уже критическая угроза, которую нужно устранить сегодня.

Что CSPM не делает

CSPM контролирует конфигурацию и состояние облачной среды, но не заменяет весь комплекс средств информационной безопасности.

• не контролирует сетевые соединения (не заменяет NGFW, Anti-DDoS и WAF);

• не видит уязвимости внутри виртуальных машин ни в операционной системе, ни в приложениях;

• не обеспечивает безопасность Kubernetes;

• не защищает от вредоносного кода;

• не ищет секреты, хранящиеся в открытом виде;

• не контролирует целостность файлов;

• не управляет обновлениями ПО;

• не контролирует конфигурации операционных систем;

• не заменяет средства мониторинга, реагирования и расследования инцидентов.

Это не недостатки конкретных продуктов, а ограничения класса решений. CSPM следует рассматривать как один из компонентов общей архитектуры ИБ.

Эволюция контроля безопасности в публичном облаке: от CSPM к CNAPP

Наибольшая эффективность достигается, когда CSPM используется не как отдельный инструмент, а как часть платформы класса CNAPP (Cloud-Native Application Protection Platform).

В CNAPP-решении данные от CSPM об ошибках в конфигурации облака объединяются с данными от других модулей, входящих в его состав: CWPP (защита виртуальных машин и контейнеров), KSPM (безопасность Kubernetes), CIEM (контроль прав доступа в облаке). Такой подход позволяет получить полную картину происходящего в облаке и корректно расставить приоритеты в устранении угроз.

Две виртуальные машины — один алерт, но разные риски

Представьте: в инфраструктуре появляются две виртуальные машины с публичными IP-адресами.

Первая — без других рисков безопасности.

Вторая — с критической уязвимостью и ключами доступа к бакету объектного хранилища, оставленными в bash history.

Изолированный CSPM назначил бы одинаковый уровень риска обеим виртуальным машинам на основе информации о наличии публичного IP-адреса.

CNAPP, получив данные об уязвимостях и секретах от модуля CWPP, распознает токсичную комбинацию рисков на второй виртуальной машине: «публичный доступ + уязвимость + секрет» и покажет её в «Путях атаки», чтобы ИБ-команда устранила эту угрозу в первую очередь.

Именно так работает платформа Cloud Advisor — #1 CNAPP в России. Она анализирует риски не изолированно, а с учётом всего облачного контекста. Это позволяет выявлять пути атаки и корректно приоритизировать угрозы.

Проверьте CSPM, который вам предлагают

Для объективного сравнения CSPM-решений от разных вендоров используйте чек-лист, представленный ниже. К предлагаемым критериям выбора добавьте свои: стоимость решения, качество технической поддержки, сроки внедрения, сложность эксплуатации и т. д. Для удобства колонка с решением Cloud Advisor уже заполнена.

Необязательно использовать все критерии. Уберите нерелевантные пункты, добавьте свои и посчитайте итоговые баллы с учётом приоритетов вашей организации.

Лучший способ оценить CSPM — подключить его к собственной инфраструктуре и посмотреть, какие ресурсы, ошибки конфигурации и пути атаки он обнаруживает на практике.

Запишитесь на демо Cloud Advisor. Покажем платформу на стенде и ответим на вопросы вашей команды.