Облачная инфраструктура требует другого подхода к безопасности — здесь не работают методы, которые применялись для защиты физических серверов. О том, по каким метрикам оценивать защищенность облака и как тестировать его на прочность, рассказывает Егор Сапун, руководитель направления сертификации инфраструктуры «Рег.облака».
Когда компания переносит сервисы в облако, привычные методы защиты перестают работать. Здесь нет серверных стоек, к которым можно прикоснуться, а границы инфраструктуры становятся программными и динамическими. Главный вызов — модель разделенной ответственности: провайдер отвечает за безопасность облака, а вы — за безопасность в облаке. И если конфигурация настроена неверно, данные становятся доступны любому, у кого есть ссылка.
Чтобы проверить, насколько защищены облачные сервисы, нужны измеримые метрики и регулярные тесты на прочность. Разберем, какие показатели отслеживать и как проверять облако через аудит, пентесты и симуляцию атак.
Метрики безопасности облаков
Метрики выполняют две функции: во-первых, они показывают слабые места до того, как туда произойдет инцидент, а во-вторых, позволяют отслеживать динамику. Рассмотрим ключевые показатели.
Время обнаружения и реагирования (MTTD / MTTR)
MTTD (Mean Time to Detect) — среднее время, которое проходит между началом атаки и ее фиксацией системой защиты. MTTR (Mean Time to Respond) — среднее время от обнаружения до полного устранения инцидента.
В облаке атаки распространяются со скоростью выполнения команд. Если злоумышленник получил доступ к консоли управления, он за минуты может выгрузить все базы или зашифровать критичные данные. Чем выше MTTD, тем дороже последствия. Норма для зрелой облачной защиты — обнаружение за минуты, а не за часы. MTTR не должен превышать время, за которое атакующий успевает достичь цели (обычно это 1–2 часа).
Охват защитой (Security Coverage)
Процент облачных ресурсов, которые находятся под мониторингом и защитой. Главный страх — забытые ресурсы: например, инстансы, которые создали для теста два года назад, а потом забыли. На них нет агентов, они не входят в инвентаризацию, но при этом доступны из интернета и работают на старых, уязвимых версиях ПО. Охват в 100% невозможен технически, но целевое значение — не ниже 95% для критичных компонентов.
Уровень привилегий (Privilege Score)
Метрика, которая оценивает, сколько пользователей, сервисов и приложений имеют избыточные права доступа. Рассчитывается как соотношение между выданными правами и реально необходимыми для работы.
Самая частая причина утечек в облаках — скомпрометированные учетные записи с правами администратора. Например, если рядовой разработчик имеет доступ к удалению бакетов или смене политик IAM (Identity and Access Management), это резко повышает риски. Privilege Score позволяет увидеть таких пользователей и отозвать лишнее. Идеал — когда у каждого сервиса есть своя техническая роль с минимально возможными правами, а люди заходят в консоль только через многофакторную аутентификацию.
Индекс конфигурационных ошибок (CIS Benchmark Score)
Оценка соответствия настроек облачных сервисов стандартам безопасности CIS (Center for Internet Security). Измеряется в процентах, где 100% — полное соответствие.
Подавляющее большинство взломов облаков происходит не из-за сложных хакерских техник, а из-за ошибок в конфигурации. CIS Benchmark Score сводит оценку этих настроек в единый показатель. Например, если индекс 65%, значит, треть базовых настроек безопасности не соответствует лучшим практикам. Задача — держать планку не ниже 90–95% для продакшн-среды.
Как тестируют облака на защищенность
Метрики показывают статическую картину: сколько ресурсов защищено, как быстро мы реагируем, нет ли явных ошибок в настройках. Однако чтобы понять, выдержит ли облако реальную атаку, нужны динамические тесты. Они имитируют действия злоумышленника и проверяют защиту в деле. Рассмотрим пять основных видов тестирования.
Аудит конфигураций (Configuration Review)
Проверка того, насколько настройки облачных сервисов соответствуют политикам безопасности и лучшим практикам. Анализируются политики доступа IAM (кто и к каким ресурсам имеет доступ), правила межсетевых экранов, открытые порты, наличие шифрования дисков и баз данных.
Ключевой вопрос, на который должен ответить аудит: «Кто и откуда может зайти в административную панель и что там сделать?». Проверка обычно проводится по чек-листам на основе стандартов CIS. Это самый быстрый и дешевый способ найти критические дыры — часто они обнаруживаются за первые полчаса.
Пентест облачной инфраструктуры (Cloud Penetration Test)
Имитация атаки злоумышленника на облачные ресурсы компании с целью проникновения и закрепления в системе. Важный нюанс: можно тестировать только ту часть, за которую отвечает компания, а не инфраструктуру самого провайдера.
Объектами тестирования становятся приложения, развернутые в облаке, API-шлюзы, виртуальные машины, контейнеры. Типичные сценарии:
- попытка перехода с одной скомпрометированной виртуальной машины на другие (горизонтальное перемещение);
- кража ключей доступа к метаданным инстансов;
- попытка выгрузки данных из объектного хранилища.
Тест на контроль доступа (IAM Privilege Escalation)
Целенаправленная проверка механизмов управления доступом на предмет возможности повышения привилегий. Моделируется ситуация: злоумышленник украл ключи доступа рядового разработчика или скомпрометировал сервисную учетную запись. Задача тестировщика — понять, сможет ли он, имея ограниченные права, расширить их до администратора облачной консоли.
Проверяются цепочки повышения привилегий: например, возможность изменить политику доверенного сервиса, создать новую роль с полным доступом или модифицировать правила, чтобы открыть себе путь к критичным ресурсам.
Моделирование атак (Attack Simulation / Breach and Attack Simulation)
Автоматизированная или полуавтоматическая эмуляция действий хакеров с использованием специальных инструментов, проверяющих срабатывание средств защиты.
Используются фреймворки вроде Atomic Red Team или Stratus Red Team. Они запускают в инфраструктуре безопасные, но реалистичные атаки, соответствующие техникам из MITRE ATT&CK. Задача — проверить, детектирует ли SIEM подозрительную активность, блокирует ли WAF вредоносные запросы, срабатывают ли оповещения в SOC. Это тест не на проникновение, а на то, видит ли защита то, что должна видеть.
Red Teaming с фокусом на облако
Полноценная имитация целевой атаки, максимально приближенная к действиям реальных злоумышленников. Сценарий обычно строится вокруг бизнес-рисков — хакер пытается проникнуть через публичное веб-приложение, закрепиться в облачной среде, переместиться к критичным данным и украсть их (например, из S3-бакета или управляемой базы данных).
В отличие от пентеста, здесь проверяется не только техника, но и люди. Например, как быстро среагирует дежурная команда, правильно ли отработают админы и сработают ли регламенты реагирования на инциденты.
Выводы: чек-лист действий
Безопасность облака — это не проект с датой завершения, а регулярная работа. Метрики помогают понять текущую ситуацию, а тесты — убедиться, что защита сработает, когда это действительно понадобится. Чтобы выстроить процесс оценки, можно начать с четырех шагов:
- Посмотреть на метрики. Зафиксировать, сколько времени сейчас уходит на обнаружение инцидентов, все ли ресурсы под защитой, нет ли учетных записей с лишними правами.
- Проверить конфигурации. Начать с аудита настроек — часто проблемы находятся именно здесь, а исправление не требует больших ресурсов.
- Протестировать в деле. Запустить пентест или симуляцию атаки, чтобы увидеть, как поведет себя инфраструктура в реальной ситуации.
- Сделать выводы и скорректировать. Устранить найденные проблемы и через некоторое время повторить цикл.