Захист хмарної інфраструктури, яку ви не будували

Вам щойно передали доступ до облікового запису в хмарі, який розвивається без нагляду вже три роки. Ніхто не залишив документацію. IAM має 40 ролей з дикими правами доступу, є S3 бакети, які ніхто не пам'ятає створити, а останній, хто розумів топологію мережі, покинув компанію в 2022 році. Це трапляється набагато частіше, ніж визнають у описах вакансій, і перший місяць визначає тон для всього після цього.

Зробіть інвентаризацію перед тим, як щось торкати

Стримайтеся від бажання одразу почати все блокувати. Спочатку вам потрібна карта. Запустіть aws resourcegroupstaggingapi get-resources у кожному регіоні, не тільки в us-east-1 — команди люблять розгортати тестові ресурси в ap-southeast-2 і забувати про них. Поєднайте це з AWS Config, якщо він уже ввімкнено, або ввімкніть його зараз, якщо ні. На Azure, az resource list --output table перенесена в електронну таблицю добре працює для першого проходження. На GCP, gcloud asset search-all-resources Cloud Asset Inventory дає вам той самий вигляд.

Перехресно звіріть з виставленням рахунків. Все, що коштує грошей, має з'явитися у вашому інвентарі ресурсів; все в інвентарі з нульовою нещодавною активністю — кандидат на архівування. Розбіжності тут зазвичай там, де ховається страшне — зателефоновані EC2 екземпляри з публічними IP, забуті RDS снімки, які сидять без шифрування, балансувальники навантаження, які вказують на нічого.

Аудиту IAM так, ніби це місце злочину

Витягніть кожну IAM політику й шукайте "Action": "*" у поєднанні з "Resource": "*". Це поєднання не повинно існувати поза кількома ролями адміністратора на розбиття скла, і навіть ті повинні мати примусове MFA та CloudTrail сповіщення. Використовуйте IAM Access Analyzer, щоб знайти ролі, які надають доступ зовнішнім облікам — це ловить як навмисні міжаккаунтні відносини довіри, так і помилки від когось, хто тестував модуль Terraform проти неправильного ID облікового запису.

Перевірте ключі доступу старші за 90 днів за допомогою aws iam generate-credential-report. Успадковані маєтки майже завжди мають довгострокові ключі, подвязані до сервісних облікових записів, іноді жорстко запрограмовані в змінній середовища Lambda або в завданні Jenkins. Ротуйте їх, але поставте на сцену — вбивство ключа, від якого залежить нічна пакетна робота о 2 ранку — це як вас позиватимуть на першому тижні.

Знайдіть публічну експозицію перед нападником

Запустіть перевірку досяжності мережі в ваших VPC. Групи безпеки з 0.0.0.0/0 на будь-чому, крім 80/443, потребують обґрунтування, а не припущення. Інструменти на кшталт ScoutSuite або Prowler будуть жувати облік протягом хвилин і видавати звіт, ранжований за серйозністю — почніть з цього замість того, щоб будувати власний контрольний список з нуля.

S3 бакети заслуговують на особливу увагу, оскільки вони є класичною міною успадкованої маєтки. Перевірте як політики бакетів, так і налаштування Block Public Access рівня облікового запису; хтось міг вимкнути стандарт облікового запису роки тому для одноразового статичного сайту й ніколи його не вмикав. aws s3api list-buckets у поєднанні з циклом перевірки get-bucket-acl та get-bucket-policy-status на кожному дає вам чітку картину за менше ніж десять хвилин для більшості облікових записів.

Установіть логування перед тим, як установити довіру

Якщо CloudTrail, VPC Flow Logs або GuardDuty вже не запущені скрізь, ввімкніть їх зараз, перед тим, як ви внесете інші зміни. Вам потрібен запис того, що відбувається з цього моменту, і вам потрібен він перед тим, як ви почнете видаляти речі, оскільки видалення — це саме тоді, коли помилки трапляються й звинувачуються в новій людині. Надсилайте журнали на окремий облік або передплату, якщо це можливо, щоб скомпрометоване навантаження також не могло стерти власні докази.

Установіть GuardDuty або Azure Defender for Cloud з сповіщеннями, спрямованими туди, де людина насправді перевіряє — не в канал Slack із 400 непрочитаних повідомлень. Цінність інструментів виявлення близька до нуля, якщо сповіщення потрапляють у порожнечу.

Спочатку виправте найголосніші проблеми, документуйте все

Ви не виправите успадковану маєток за спринт. Тріаж за радіусом вибуху: спочатку публічна експозиція даних, потім надмірно привілейовані ідентичності, потім сегментація мережі, потім все решта. Запишіть те, що ви знайшли та що ви змінили, навіть у простому Google Doc, тому що наступна людина, яка успадкує це від вас, заслуговує на краще, ніж те, що ви отримали.

Очікуйте опору, коли ви затягуєте групу безпеки й тест інтеграції розробника починає не працювати. Це нормально — це означає, що аудит працює. Поговоріть з командою, яка володіє навантаженням, перед тим, як ви щось змінюєте в production, й тримайте план повернення у готівці на перші два тижні.

Для отримання більше інформації про інструменти й обґрунтування за хмарними аудитами, перевірте сегменти Korra Studio про укріплення IAM та інженерію виявлення в хмарі — обидва добре поєднуються з робочим процесом вище.