Защита облачной инфраструктуры, которую вы не создавали

Вам только что передали ключи от облачного аккаунта, который растет без присмотра уже три года. Никто не оставил документацию. В IAM 40 ролей с правами через wildcard, есть S3 buckets, которые никто не помнит создавшим, а последний человек, который разбирался в топологии сети, уехал из компании в 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 дает вам тот же вид.

Сличите с выставлением счетов. Все, что стоит денег, должно появиться в вашем инвентаре ресурсов; все в инвентаре с нулевой последней активностью — кандидаты на архивирование. Расхождения здесь обычно скрывают самое страшное — orphaned EC2 instances с публичными IP-адресами, забытые RDS snapshots без шифрования, load balancers указывающие в никуда.

Аудируйте IAM как место преступления

Вытащите все IAM policies и ищите "Action": "*" в сочетании с "Resource": "*". Эта комбинация не должна существовать кроме как в небольшом числе admin ролей для экстренного доступа, и даже в них должны быть MFA enforcement и CloudTrail alerting. Используйте IAM Access Analyzer чтобы найти роли, дающие доступ внешним аккаунтам — это отловит как намеренные cross-account trust relationships, так и ошибки от того, кто тестировал Terraform module на неправильном account ID.

Проверьте access keys старше 90 дней с помощью aws iam generate-credential-report. Унаследованные среды почти всегда имеют долгоживущие ключи, привязанные к service accounts, иногда захардкодированные в переменной окружения Lambda или в job Jenkins. Ротируйте их, но постепенно — убить ключ, от которого зависит ночной batch job в 2 часа ночи — это способ получить пейджер в первую неделю.

Найдите публичный доступ до того как это сделает злоумышленник

Запустите проверку сетевой доступности через ваши VPCs. Security groups с 0.0.0.0/0 на чем-либо кроме 80/443 нуждаются в обосновании, а не в предположении. Инструменты типа ScoutSuite или Prowler прожмут аккаунт в несколько минут и выдадут отчет, отсортированный по severity — начните с этого вместо того, чтобы собирать свой собственный checklist с нуля.

S3 buckets заслуживают особого внимания, потому что это классическая мина на унаследованных имущества. Проверьте как bucket policies так и account-level Block Public Access settings; кто-то мог отключить account default годы назад для одноразового статического сайта и никогда это не включал обратно. aws s3api list-buckets в сочетании с loop проверяющим get-bucket-acl и get-bucket-policy-status на каждом дает вам ясную картину менее чем за десять минут на большинстве аккаунтов.

Установите логирование прежде чем устанавливать доверие

Если CloudTrail, VPC Flow Logs или GuardDuty уже работают везде, включите их везде, прежде чем делать какие-либо другие изменения. Вам нужен записей того, что происходит с этого момента, и вам нужно это раньше, чем вы начнете удалять вещи, потому что удаление — это именно когда делаются ошибки и их приписывают новичку. Отправляйте логи в отдельный аккаунт или subscription если возможно, чтобы скомпрометированная workload не могла также стереть своё собственное доказательство.

Настройте GuardDuty или Azure Defender for Cloud с alerting направленным туда, где человек на самом деле проверяет — не в Slack channel с 400 непрочитанными сообщениями. Ценность detection tooling близка к нулю, если alerts попадают в пустоту.

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

Вы не поправите унаследованное имущество в одном спринте. Трируйте по blast radius: публичный data exposure первым, потом overprivileged identities, потом network segmentation, потом все остальное. Напишите что вы нашли и что вы изменили, даже в простом Google Doc, потому что следующий человек, который это унаследует от вас, заслуживает лучшего чем то, что получили вы.

Ожидайте возражений когда вы затянете security group и integration test разработчика начнет падать. Это нормально — это означает что аудит работает. Поговорите с командой, которая владеет workload прежде чем вы что-либо переворачиваете в production, и держите план rollback готовым на первые две недели.

Для большего о инструментах и рассуждениях за cloud audits, посмотрите на сегменты Korra Studio про IAM hardening и cloud detection engineering — оба хорошо сочетаются с workflow выше.