Сегментация и файрволы

Радиус поражения: число, которое сегментация реально двигает

Начни с допущения, от которого зрелый инженер не отказывается: что-то будет скомпрометировано. CVE в зависимости, утёкшие учётки, SSRF, разворачивающийся внутрь, — рано или поздно один хост станет хостом атакующего. Остаётся единственный вопрос: как далеко дотянется этот плацдарм. Эта достижимая поверхность и есть радиус поражения (blast radius), и сегментация существует именно для того, чтобы его сокращать.

Плоская сеть — одна большая подсеть, где каждый хост может набрать любой другой по любому порту, — максимизирует радиус поражения по построению. Компрометация любого узла равна достижимости всех остальных. Ровно эта структура превращает локализованный баг веб-уровня в разгул латерального движения: пробой Target 2013 года начался с учёток, украденных у подрядчика по вентиляции, и дотянулся до сети точек продаж, потому что сегменты, которые должны были отделять доступ подрядчика от систем обработки карт, не были обеспечены. Урок обобщается: латеральное движение возможно только по путям, которые сеть разрешает, поэтому защита — разрешать меньше путей.

Сегментация режет это плоское пространство на зоны с контролируемыми переходами. Классический трёхуровневый разрез — web / app / data: веб-уровень принимает трафик из интернета на 443, app-уровень принимает трафик только от веб-уровня, а data-уровень принимает трафик только от app-уровня. Теперь скомпрометированный веб-сервер дотягивается до app-уровня по одному порту — не до базы, не до хранилища секретов, не до CI. Атакующему придётся найти вторую уязвимость на каждой границе, чтобы двигаться дальше, и каждая граница — это место, где ты можешь его обнаружить и остановить.

Слои обеспечения: файрволы, security groups, микросегментация

Граница зоны настолько реальна, насколько реальна штука, которая её обеспечивает. Работу делают три слоя на трёх разных уровнях гранулярности.

Сетевой файрвол стоит на границе подсети или периметра и фильтрует трафик по 5-кортежу (source IP, destination IP, source port, destination port, протокол). Несогласуемая позиция — default-deny: набор правил начинает с того, что отбрасывает всё, и ты явно разрешаешь только те потоки, которых требует архитектура. Файрвол с default-allow и парой блокирующих правил — это решето: он открывается в тот миг, когда появляется новый сервис, под который никто не написал блокирующее правило. Default-deny отказывает закрыто: поток, который никто не разрешил, просто не происходит.

Security groups (облачный нативный примитив — у AWS, GCP, Azure есть эквивалент) опускают этот фильтр до уровня инстанса и делают его на основе идентичности, а не IP. Вместо «allow 10.0.2.0/24 → 5432» ты пишешь «allow source-группа app-sg → группа db-sg на 5432». Правило ссылается на роли, а не на адреса, поэтому переживает автоскейлинг и смену IP, и оно stateful: разрешаешь входящий запрос — ответ пропускается автоматически. Security groups по своей природе deny-by-default: инстанс без входящего правила не принимает ничего.

Микросегментация доводит это до предела: политика на ворклоад, часто на сервис или под, обеспечиваемая независимо от того, где он запущен. В Kubernetes это NetworkPolicy (или authorization-политика service mesh), которая говорит: поды с меткой app=checkout могут принимать трафик только от подов с меткой app=gateway на 8080, а по умолчанию в namespace с любой политикой — запрет всего остального. Это структурное ядро zero trust (NIST SP 800-207): сетевое расположение запроса не даёт ему ничего, каждый поток авторизуется по собственной идентичности. Микросегментация — это то, что сжимает east-west радиус поражения с «весь namespace» до «единственный сосед, с которым этот сервис законно говорит».

Эшелонированная защита и где сегментация перестаёт помогать

Сегментация — это один слой эшелонированной защиты (defense in depth), а не вся защита. Она контролирует, кто до кого может дотянуться; она не проверяет, что они присылают, будучи допущенными. Если app-уровню разрешено запрашивать базу, а в приложении есть SQL-инъекция, файрвол пропустит вредоносный запрос насквозь — 5-кортеж в allowlist. Поэтому сегментацию надо сочетать с контролями на следующем слое внутрь (параметризованные запросы, аутентификация/авторизация на сервисе, валидация ввода) и слоем выше (WAF, TLS). Смысл эшелона в том, что отказ ни одного отдельного контроля не должен быть концом игры.

Две честные издержки не дают этому быть бесплатным. Операционная тяга: мелкозернистая политика — это масса правил, а правила дрейфуют: устаревший allow, который никто не убрал, становится ровно тем путём, который использует атакующий. Дисциплина — держать политику как код, ревьюить её и проверять на неиспользуемые allow. Сбой плохого исполнения: пересегментируй без хорошей наблюдаемости — и получишь загадочные аварии, где законный поток молча отброшен, команда не может отличить ошибку конфигурации от атаки и — хуже всего — под давлением кто-то «чинит» это, добавляя правило allow all, которое тихо снова уплощает сеть, которую ты сегментировал квартал.

Как читать политику по-зрелому

Когда ты ревьюишь дизайн сегментации, на самом деле ты задаёшь два вопроса. Первый: это default-deny? Если базовая линия — allow-с-исключениями, дизайн уже проигран: найди неявное правило any-any — и ты нашёл истинную достижимость всей сети. Второй: до чего дотягивается одна компрометация? Возьми самый открытый узел (уровень, смотрящий в интернет), считай его захваченным и проследи каждый поток, который ему разрешено сделать. Это множество и есть твой радиус поражения. Если в него входят база, хранилище секретов или CI — у тебя есть пути латерального движения, которые надо отрезать.