CSPM и управление постуром

Что CSPM на самом деле делает

Cloud Security Posture Management механически — вещь неэффектная: он принимает read-only IAM-роль в каждом твоём облачном аккаунте, вызывает describe/list-API (DescribeSecurityGroups, GetBucketPolicy, ListAttachedRolePolicies и сотни других), нормализует ответы в граф ресурсов и их связей и проверяет этот граф по библиотеке правил. Правило — это просто предикат над состоянием ресурса: «S3-бакет, чья эффективная политика или ACL даёт * на чтение» или «ingress security group с CIDR 0.0.0.0/0 на порт базы данных». Когда ресурс совпадает — это находка.

Единственное свойство, которое отличает CSPM от IaC-сканирования, — это где он смотрит. IaC-скан читает твой намеренный конфиг — Terraform-план, до apply. CSPM читает фактический конфиг — ресурс в том виде, в каком он существует в облаке прямо сейчас, после каждого клика в консоли, вызова SDK, события автоскейлинга и внепланового изменения от команд, которые никогда не трогали твой репозиторий. Гейт пайплайна — это контрольный пункт на одной дороге в прод; CSPM — спутник над всей страной, и большую часть страны твой пайплайн никогда не асфальтировал.

Поэтому CSPM по сути — дисциплина непрерывного мониторинга, а не разовый аудит. Руководство NIST по непрерывному мониторингу формулирует ту же идею для любой системы: состояние безопасности деградирует в тот момент, когда ты перестаёшь за ним следить, поэтому переоценку делают на постоянной основе, а не в точке времени. Облачный аккаунт, который был чист в 9 утра, к 3 часам дня — уже другой объект безопасности: кто-то задеплоил, кто-то кликнул, чья-то Lambda приняла более широкую роль. Задача CSPM — продолжать перечитывать.

Двое часов: обход и поток событий

Серьёзный CSPM работает на двух каденциях, и понимание разницы — это то, что отделяет «у нас есть инструмент» от «у нас есть покрытие». Периодический обход перечитывает каждый ресурс в каждом аккаунте на фиксированном интервале — скажем, каждые несколько часов. Это гарантия полноты: даже ресурс, созданный процессом, о котором ты не знаешь, в итоге будет перечислен и проверен, потому что обход не зависит от того, сообщили ли ему о чём-либо. Его слабость — задержка. Если обход идёт каждые 6 часов, бакет, сделанный публичным в 12:05, может быть отмечен только к 18:00 — шестичасовое окно экспозиции, которым scanner-as-a-service, ползающий по облачным диапазонам, с радостью воспользуется.

Событийный путь закрывает это окно. Облачный провайдер эмитит событие изменения конфига (правила AWS Config, EventBridge на вызов ModifyDB/PutBucketAcl, фиды GCP Asset Inventory), и CSPM переоценивает только этот один изменённый ресурс за секунды. Он быстрый и дешёвый, потому что инкрементальный. Его слабость — обратная слабости обхода: он видит только те изменения, на которые подписан, в регионах и аккаунтах, где проводка событий реально настроена, — а эта проводка ломается молча. Нужны оба. Обход — твой пол (всё в итоге увидено); поток событий — твой потолок (то, за чем ты следишь, видится быстро).

Дрейф, масштаб и почему «находка» — это не «риск»

Две силы превращают CSPM из аккуратного линтера в трудную инженерную задачу: дрейф и масштаб.

Дрейф — это медленное расхождение между тем, что говорит твой IaC, и тем, что реально задеплоено. Даже в дисциплинированной команде кто-то горячим фиксом правит security group в 2 ночи во время инцидента и забывает перенести правку обратно в Terraform; следующий apply либо откатывает его фикс (ломая прод), либо кто-то добавляет ignore, и ресурс теперь навсегда вне гейта. CSPM — это то, как ты видишь дрейф: он сообщает живое состояние, которое твой код больше не описывает. Но увидеть — это лишь половина цикла. Вторая половина — примирить: либо втянуть изменение обратно в IaC, либо формально его принять. Дрейф, который ты видишь, но никогда не разрешаешь, просто становится вечной находкой, которую все приучаются проматывать.

Масштаб — убийца в энтерпрайзе. CSPM, наведённый на 300 аккаунтов с дефолтным набором правил, в первый же день вернёт десятки тысяч находок. Большинство — реальные-но-нерелевантные: «у S3-бакета нет логирования доступа» на бакете с публичными маркетинговыми картинками, «security group разрешает весь ICMP» внутри приватной подсети. Если ты маршрутизируешь их все, ты построил пожарный шланг алертов, который никто не читает, и единственная находка, которая важна, — боевая база данных, открытая в интернет, — тонет. Зрелый навык в CSPM — не запуск скана, а триаж: ранжируй по радиусу поражения (достижим ли ресурс из интернета? хранит ли чувствительные данные? даёт ли привилегии?), подавляй с зафиксированной причиной, а не молча игнорируй, и маршрутизируй человеку только верхний слой — тому, у кого есть контекст это починить. Находка — это факт; риск — это находка, оценённая против достижимости и ущерба. Смешивать их — это и есть то, как команды тонут.

Как зрелый инженер встраивает это

CSPM не заменяет IaC-гейт — он стоит за ним как эшелонированная защита. Гейт останавливает мисконфиг, который ты пишешь в коде, до того как он уйдёт в прод; CSPM ловит мисконфиг, который приходит любым другим путём. Зрелый инженер подключает оба, затем связывает вывод CSPM с реальным процессом: дедуплицирует находки, чтобы одна корневая причина не была 400 алертами, оценивает по радиусу поражения, авто-маршрутизирует критический слой в трекер владеющей команды с достаточным контекстом, чтобы действовать, подавляет остальное с аудит-следом и скармливает повторяющиеся паттерны обратно в policy-as-code, чтобы тот же класс мисконфига ловился до apply в следующий раз. Конечное состояние — не «мы гоняем сканер». Это замкнутый цикл: предотврати в пайплайне, обнаружь то, что проскользнуло, в облаке, примири дрейф в код и со временем сожми повторяющиеся категории.