Распространённые ошибки настройки облака

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

Корзины S3 с общедоступным доступом на чтение раскрывают все хранящиеся в них данные в интернете. Злоумышленники сканируют открытые корзины с помощью таких инструментов, как GrayhatWarfare. Профилактика: включите блокировку общедоступного доступа S3 на уровне учетной записи, включите владение объектами S3 и регулярно проверяйте политики корзин.

Группы безопасности с адресом 0.0.0.0/0 на портах 22 (SSH), 3389 (RDP) или административных портах создают огромную поверхность атаки. Ограничивайте входящие правила конкретными диапазонами CIDR. Вместо открытого SSH используйте AWS Systems Manager Session Manager.

Случайное предоставление общедоступного доступа к снимкам RDS раскрывает все содержимое базы данных. Автоматические снимки по умолчанию являются закрытыми, но при ручном предоставлении доступа могут раскрыть конфиденциальные данные. Проверяйте видимость снимков с помощью describe-db-snapshots --include-public.

Разработчики добавляют ключи доступа AWS, пароли баз данных и токены API в репозитории Git. Злоумышленники сканируют GitHub/GitLab с помощью таких инструментов, как TruffleHog и GitLeaks. Профилактика: используйте менеджеры секретов, хуки git-secrets перед фиксацией изменений и сканирование секретов во всей организации.

Если CloudTrail не включен во всех регионах, вызовы API не записываются. Злоумышленники используют пробелы в журналировании, чтобы действовать незаметно. Включите CloudTrail во всей организации и отправляйте журналы в корзину S3 отдельной учетной записи безопасности с блокировкой объектов S3 для защиты от подделки.

IMDSv1 позволяет любому процессу на экземпляре EC2 запрашивать службу метаданных без аутентификации, что дает возможность проводить атаки SSRF и красть учетные данные экземпляра. Принудительно включите IMDSv2, требующий токен, на всех экземплярах, чтобы использовать аутентификацию с привязкой к сеансу.

Группы безопасности обычно разрешают весь исходящий трафик. Это позволяет извлекать данные и устанавливать связь с C2 из скомпрометированных экземпляров. Используйте фильтрацию исходящего трафика через группы безопасности, NACL или межсетевой экран, чтобы ограничить исходящие соединения известными адресатами.

Панели Kubernetes, кластеры Elasticsearch, экземпляры MongoDB и записные книжки Jupyter, оставленные доступными без аутентификации через общедоступные IP-адреса, регулярно взламывают. Каждый интерфейс управления должен требовать аутентификацию и быть ограничен на уровне сети.

Одних событий данных S3 и событий управления CloudTrail недостаточно для обнаружения операций на уровне объектов (GetObject, PutObject). Включите журналирование доступа к серверу S3 и события данных S3 в CloudTrail для конфиденциальных корзин, чтобы обнаруживать попытки извлечения данных.

Правила AWS Config с автоматическим устранением (через документы автоматизации SSM или Lambda) могут автоматически устранять нарушения: делать корзины закрытыми, закрывать правила групп безопасности или помещать учетные данные в карантин, сокращая время раскрытия с дней до минут.

Каков основной риск включенного IMDSv1 на экземплярах EC2?

Неправильные настройки облака — общедоступные корзины, слишком разрешительные группы безопасности, жестко заданные учетные данные и отсутствие журналов — наиболее распространенная причина утечек данных из облака. Автоматическое сканирование, принудительно применяемые защитные ограничения и непрерывный мониторинг — важнейшие меры защиты.