Поверхность атаки облака

В облаке поставщик защищает инфраструктуру, а клиент отвечает за конфигурацию, идентификацию и данные. Большинство утечек происходит на стороне клиента.

• Поставщик устанавливает исправления для гипервизоров и обеспечивает физическую безопасность.
• Клиент отвечает за политики IAM, разрешения хранилищ и сетевые правила.
• Основной риск связан с неправильной настройкой, а не с компрометацией поставщика.

В облаке нет традиционной сетевой границы. Доступ регулируется с помощью IAM: пользователей, ролей, политик и ключей. Утечка ключа доступа может быть столь же опасной, как кража пароля администратора домена.

• Политики IAM предоставляют разрешения на действия с ресурсами.
• Роли позволяют службам и пользователям получать временные учетные данные.
• Идентичности с избыточными разрешениями — основной вектор повышения привилегий.

Учетные данные облачных сред постоянно становятся доступными посторонним. К распространенным источникам относятся:

• Ключи доступа, добавленные в общедоступные репозитории Git.
• Ключи, зашитые в мобильные приложения, журналы CI или образы контейнеров.
• Подделка запросов на стороне сервера (SSRF), достигающая службы метаданных.
• Слишком широкое распространение ключей с длительным сроком действия вместо краткосрочных ролей.

Каждый облачный экземпляр предоставляет конечную точку метаданных, которая может выдавать временные учётные данные роли. Уязвимость SSRF или RCE на VM, имеющей к ней доступ, часто позволяет получить роль экземпляра.

• AWS IMDS находится по адресу 169.254.169.254.
• IMDSv1 не требует ничего, кроме запроса, и тривиально используется через SSRF.
• IMDSv2 требует токен сессии (PUT, затем GET), что предотвращает многие атаки SSRF.

Объектное хранилище (S3, GCS, Azure Blob) регулярно становится источником утечек данных.

• Бакеты с публичным чтением раскрывают конфиденциальные файлы.
• Бакеты с публичной записью позволяют изменять содержимое или размещать вредоносные программы.
• Слишком широкие политики бакетов или списки контроля доступа предоставляют аутентифицированным пользователям доступ.
• Предварительно подписанные URL с длительным сроком действия раскрывают постоянный доступ.

Облачные средства контроля сети (группы безопасности, NSG, правила брандмауэра) легко открыть слишком широко.

• Базы данных или порты администрирования доступны из 0.0.0.0/0.
• Плоскости управления (API Kubernetes, RDP, SSH) доступны из интернета.
• Внутренние сервисы неявно доверяют VPC и не используют аутентификацию.

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

• Роль выполнения Lambda может иметь слишком много разрешений.
• Переменные окружения часто содержат секреты, доступные для чтения после компрометации.
• Неправильная настройка источника событий может позволить недоверенным данным запускать привилегированные функции.

Различайте эти две поверхности атаки:

• Плоскость управления: облачный программный интерфейс (создание ресурсов, изменение IAM, чтение конфигураций). Её компрометация затрагивает весь аккаунт.
• Плоскость данных: сами рабочие нагрузки (приложения, VM, контейнеры).

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

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

• Роли между аккаунтами со слабыми политиками доверия позволяют перемещаться между средами.
• Проблемой замешанного заместителя в роли интеграции со сторонним сервисом можно злоупотребить.
• Роли уровня организации (например, OrganizationAccountAccessRole) особенно ценны для атакующего.

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

• CloudTrail / журнал действий / журналы аудита фиксируют вызовы плоскости управления.
• Атакующие могут отключить журналы аудита или остановить доставку журналов.
• GuardDuty / Security Command Center / Defender выявляют аномалии.

Отключение журналирования само по себе является событием с высокой информативностью, о котором следует оповещать.

Тесты облачных систем на проникновение требуют знания требований провайдера и соответствующего разрешения. Некоторые действия (отказ в обслуживании, определённые виды сканирования) нарушают условия провайдера. Всегда подтверждайте владение аккаунтом, согласовывайте радиус воздействия и сначала отдавайте предпочтение перечислению данных только для чтения.

Используйте выделенный аккаунт для тестирования или ресурсы с понятными метками и никогда не обращайтесь к ресурсам за пределами задокументированных границ.

Проверьте, насколько хорошо вы понимаете поверхность атаки в облаке.

Вы составили карту поверхности атаки в облаке.

• Неправильные настройки на стороне клиента — главный источник рисков облака.
• Идентичность — это периметр; утёкшие ключи и роли — основные векторы атаки.
• Служба метаданных связывает уязвимости плоскости данных с облачными учётными данными.
• Неправильные настройки хранилищ, сети и журналирования дополняют эту поверхность атаки.

Далее: перечисление облачных ресурсов для поиска этих проблем.