Мне кажется, многие компании переоценивают зрелость своей cloud security.

У них есть CSPM, сканирование конфигураций, централизованный SIEM, резервное копирование и формально заведённый break-glass аккаунт.

Но это ещё не означает, что компания способна пережить компрометацию cloud control plane.

Control plane — это слой, через который можно изменить IAM, сеть, ключи, logging, security services и конфигурацию множества workloads.

Именно здесь возникает один из самых неприятных конфликтов облачной архитектуры: централизация повышает эффективность, но одновременно создаёт огромный blast radius.

Один привилегированный субъект может получить возможность изменить тысячи ресурсов. Ещё хуже — если он способен изменить и сами ресурсы, и средства, которые должны зафиксировать его действия.

Поэтому я не считаю включённые audit logs достаточным контролем.

Нужно проверять, кто может: - остановить сбор событий; - изменить место их хранения; - удалить архив; - отключить security service; - изменить federation; - выдать новую привилегию; - использовать management API в обход обычного интерфейса.

Microsoft в разборе атаки Storm-2949 показала, как компрометация identities может перейти в использование штатных облачных административных операций против Key Vault, Storage, SQL и VM. (Microsoft)

То есть атакующий может не «взламывать» серверы в привычном смысле. Он действует как администратор, используя доверенные функции платформы. Отсюда моя позиция: cloud control plane необходимо выделять в отдельный Tier-0 контур.

Туда входят не только tenant administrators, но и federation trust, signing keys, service principals, CI/CD identities, management APIs, организационные политики, logging destinations и emergency access.

Особенно внимательно я бы проверял break-glass процедуру.

Если аварийный пароль хранится в системе, использующей тот же IdP, если MFA зависит от корпоративного устройства и если сценарий ни разу не тестировался, то аварийного доступа фактически нет.

Есть только документ, создающий ощущение контроля.

Зрелая модель должна отвечать на три вопроса:

Кто может массово изменить облачную среду?

Кто независимо заметит такое изменение?

Как компания вернёт контроль, если основной identity layer больше нельзя считать доверенным?

Резервные копии возвращают данные. Но они не возвращают административный суверенитет над облаком.

Интересно, сколько компаний сегодня действительно тестируют восстановление control plane, а не только восстановление приложений?