Ви успадкували безлад у хмарі. З чого почати?

Ви щойно перейняли хмарний акаунт (або десять), який хтось будував протягом трьох років без документації, з мінливим складом підрядників та каналом Slack під назвою #aws-help, який неактивний з 2022 року. Це одна з найпоширеніших ситуацій у роботі з безпеки хмари, і вона незручна, тому що ви відповідаєте за щось, що не можете ще пояснити.

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

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

Ви не можете захистити те, що не бачите. Перш ніж змінювати будь-яку IAM політику, виконайте інвентаризацію:

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

Перевірте це проти даних біллінгу. Біллінг не брехує про те, що запущено, навіть коли теги та документація брешуть. Якщо ви бачите видатки на сервіс, який ніхто не згадав під час адаптації, це ваша перша знахідка.

Знайдіть, хто може робити що, перш ніж шукати, що зламане

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

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