You Inherited a Cloud Mess. Where Do You Start?

Вы только что взяли под контроль облачный аккаунт (или десять), который кто-то другой создавал в течение трёх лет без документации, с постоянно меняющейся командой подрядчиков и Slack-каналом #aws-help, который не активен с 2022 года. Это одна из самых частых ситуаций в работе облачной безопасности, и она некомфортна, потому что вы ответственны за что-то, что не можете пока объяснить.

Вот как перейти от нулевой видимости к защищённой позиции без лишних усилий.

Перестаньте гадать и сначала получите инвентаризацию

Вы не можете защитить то, что не видите. Прежде чем трогать хоть одну IAM политику, проведите инвентаризацию:

• AWS: aws organizations list-accounts для просмотра полной структуры аккаунтов, затем Steampipe или AWS Config aggregators для извлечения ресурсов со всех аккаунтов в один квериуемый вид.
• Azure: Resource Graph запросы (az graph query) через подписки, так как модель Azure tenant/subscription легко скрывает разрастание.
• GCP: gcloud asset search-all-resources на уровне организации.

Соотнесите это с данными биллинга. Биллинг не врёт о том, что работает, даже когда теги и документация обманывают. Если вы видите траты на сервис, о котором никто не упоминал при адаптации, это ваша первая находка.

Найдите, кто может что делать, прежде чем искать, что сломано

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

Запустите AWS IAM Access Analyzer или инструменты в стиле iam-lint для флагирования неиспользуемых разрешений за последние 90 дней. На практике унаследованные аккаунты почти всегда имеют минимум одного IAM пользователя с долгоживущими access key, которые должны были быть