Утечка Capital One: облако не виновато, виновата конфигурация
В июле 2019 года Capital One потерял данные более 100 миллионов клиентов. Разбираю, что произошло и почему главный урок не про облако, а про управление доступом.
В конце июля 2019 года стало известно об утечке данных в Capital One - одном из крупнейших банков США. Атакующая использовала неправильно настроенный брандмауэр веб-приложения в облачной инфраструктуре, чтобы получить временные учётные данные через уязвимость SSRF. Дальше - доступ к данным более 100 миллионов клиентов в Северной Америке. Сумма штрафов и компенсаций в итоге составила сотни миллионов долларов.
Первая реакция в профессиональном сообществе была предсказуемой: "облако небезопасно", "данные нельзя доверять публичным провайдерам". Я считаю эту интерпретацию неверной и вредной - она уводит внимание от реального вопроса.
Что произошло на самом деле
Техническая цепочка выглядела примерно так: неправильно настроенный межсетевой экран позволил отправить запрос к внутреннему сервису метаданных облачной инфраструктуры. Этот сервис вернул временные токены с избыточными правами. Через эти токены атакующая получила доступ к данным в хранилище.
Ни один из этих шагов не является специфической "уязвимостью облака" в смысле программного дефекта провайдера. Это последовательность ошибок конфигурации и управления доступом:
- межсетевой экран был настроен неправильно,
- роль, которой были выданы токены, имела избыточные права,
- права доступа не проверялись на соответствие принципу минимальных привилегий.
Тот же набор ошибок в локальной инфраструктуре привёл бы к тому же результату.
Почему это важно для российских компаний
Инцидент Capital One произошёл в американском банке с серьёзными требованиями к безопасности и внушительными бюджетами на ИБ. Если это случается там, вопрос о состоянии конфигураций в компаниях со значительно более скромными ресурсами становится очень конкретным.
В 2019 году значительная часть российского бизнеса активно переносит инфраструктуру и данные в облако. Скорость переноса часто опережает понимание модели ответственности. Провайдер отвечает за безопасность физической инфраструктуры. За конфигурацию сервисов, управление доступом, права ролей - отвечает клиент.
Это принципиальное разделение, которое нередко упускается при принятии решений.
Три слоя, на которые стоит смотреть
Первый - сетевая конфигурация. Кто проверяет правила межсетевого экрана, политики сетевого доступа? Есть ли понимание, какие запросы должны проходить, а какие нет? Делается ли это систематически или только при первоначальной настройке?
Второй - роли и права. В облачной модели права задаются через роли, которые назначаются сервисам и пользователям. Избыточные права - классическая проблема: при настройке дают "с запасом", потом не пересматривают. Это называется privilege creep, и это одна из самых частых причин того, что компрометация одного элемента инфраструктуры разрастается до большой утечки.
Третий - мониторинг аномалий. Деятельность атакующего в капитал-уановском инциденте выглядела как нестандартные запросы к сервису метаданных. Такие аномалии в принципе поддаются обнаружению - если настроен мониторинг и есть кто-то, кто читает его результаты.
Вопросы, которые стоит задать
Если вы переносите данные в облако или уже работаете там, несколько практических вопросов:
- Кто в вашей команде отвечает за аудит конфигурации облачных сервисов?
- Проверялись ли роли и права на избыточность хотя бы раз после первоначальной настройки?
- Настроен ли мониторинг необычных обращений к критичным данным?
- Кто и как узнает, если произойдёт нечто похожее?
Переход в облако не делает инфраструктуру автоматически безопасной. Он меняет характер работы по безопасности - с физической охраны на управление конфигурациями и доступом. Это требует других компетенций, и их нужно строить осознанно.