DMZ в гибридной инфраструктуре: новая граница безопасности

Демилитаризованная зона (DMZ) — это основа основ сетевой безопасности в корпоративных инфраструктурах. Но с переходом к микросервисам, контейнерам и гибридным моделям, роль DMZ изменилась — теперь это не просто буфер между внутренней сетью и интернетом, а динамичный, сложно сегментированный периметр с новыми вызовами. Cyber Media разбирает, как современные компании выстраивают архитектуру DMZ, минимизируют поверхность атаки и предотвращают lateral movement внутри зоны.

Что такое DMZ сегодня: от классики к гибридной архитектуре

Классическая модель DMZ выглядит просто: внешний и внутренний файрволы, зона с публичными сервисами. Простая фильтрация по портам, изоляция от внутренней сети — и вроде бы все под контролем.

Но сегодня такой подход не выдерживает реалий гибридных инфраструктур и микросервисов. Сервисы развернуты и в облаке, и on-prem. Они масштабируются динамически, обмениваются данными друг с другом по десяткам внутренних API. Статические правила больше не работают.

DMZ больше не ограничена одним сегментом с жесткими ACL. Теперь это логическая структура, состоящая из множества зон с разной степенью доверия. Изоляция работает не только на сетевом уровне, но и на уровне приложений, контейнеров, микросервисов и API.

Вместо простого «входа с улицы» — теперь это сложная зона взаимодействия: с обратными прокси, API-шлюзами, фильтрацией на уровне L7, сервис-мешами и системой сквозного мониторинга.

Такое усложнение и распределенность инфраструктуры требуют иного подхода к доверию. Стало очевидно, что нельзя полагаться на один периметр — каждый компонент должен быть защищен сам по себе. Именно отсюда возникает философия Zero Trust.

В ней вроде бы нет места для «пограничных зон»: доверия нет нигде, проверять нужно все. Но на практике DMZ отлично встраивается в Zero Trust-подход — просто меняется ее роль. Современная DMZ:

• изолирует и сегментирует доступ к критичным сервисам;
• обеспечивает контроль и аудит трафика на границе;
• позволяет локализовать инциденты до конкретной зоны или сервиса;
• работает как наблюдательная и фильтрующая прослойка перед основными компонентами инфраструктуры.

Сегодня DMZ не просто сетевой периметр, а слой наблюдаемости, изоляции и политики доступа, необходимый для того, чтобы Zero Trust действительно работал. Особенно в гибридных и контейнеризированных средах, где границы становятся все более размытыми.

DMZ и микросервисы: новая логика сегментации

Микросервисы полностью меняют картину. Если раньше DMZ была «воротами» для ограниченного числа приложений, то теперь она становится транспортным узлом, через который проходят сотни независимых компонентов. Каждый микросервис может иметь собственный API, базу, зависимости — и при этом динамически запускаться, масштабироваться или мигрировать между кластерами.

Главная сложность: традиционная DMZ просто не рассчитана на такой уровень динамики. Списки разрешенных IP и портов перестают быть эффективными. Вместо статической фильтрации нужны гибкие, контекстные правила и механизм, который видит не просто трафик, а кто, куда и зачем идет.

Альберт Маннанов

Руководитель продукта Solar NGFW ГК «Солар»

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

Важнейшими элементами здесь выступают сетевые политики, которые, как и межсетевой экран, блокируют нелегитимные перемещения. Основная цель — это разделение трафика на публичный (Ingress), внутренний (East-West) и управляющий (Control Plane). Кроме того, встроенные средства сетевых политик не всегда удобно использовать и не хватает, поэтому их расширяют такие решения, как Project Calico и Cilium.

При этом для защиты и дальнейшей работы с инцидентами необходимо использовать IPS + SOAR, централизованный сбор логов с привязкой к сервисам. А из средств защиты и потребуются компоненты ограничения доступа к сервисам — только после аутентификации и авторизации.

Также необходимо контролировать доступ к облачной инфраструктуре — здесь уже используются классические методы контроля с помощью межсетевых экранов как на границе, так и в ядре сети. А также механизмы нулевого доверия Zero Trust Network Access при применении NGFW, агентов на рабочих станциях и других компонентов для защиты корпоративной сети.

Чтобы удержать контроль в условиях гибридной среды, где часть микросервисов живет в облаке, а часть — on-prem, стоит опираться на следующие принципы:

• Сегментируйте по функциям, а не по IP. Неважно, где физически расположен сервис — важно, к какому классу доверия он относится. Например, сервисы авторизации, биллинга и аналитики должны обрабатываться в разных зонах с разными правилами.
• Используйте микросегментацию на уровне L7. Файрвол уровня IP не видит, какие данные ходят внутри API-запросов. L7-фильтрация позволяет отсеивать подозрительную активность на уровне бизнес-логики.
• Отдельный ingress — отдельная зона доверия. Входной трафик из интернета и из внутренних систем должен обрабатываться разными компонентами, с разными правилами.

Такая структура позволяет точно настраивать политику доступа и вовремя отсекать подозрительную активность — не на всей инфраструктуре, а в конкретной зоне.

Подходы к размещению микросервисов в on-prem и облаке

В гибридных инфраструктурах DMZ — это не одно место, а логически распределенная система. Разумная стратегия — разграничить зону доступа к внешним API и зону выполнения критичных сервисов. Например:

• В облаке можно разместить фронтовые микросервисы — интерфейс, публичные API, балансировщики.
• On-prem — чувствительные компоненты: базы, биллинг, внутренние API.

Трафик между ними проходит через строго контролируемые шлюзы — с логированием, аутентификацией и политиками доступа на уровне сервисов.

Применение Service Mesh и sidecar-проксей

Сервис-меши, например, Istio, Linkerd, становятся незаменимыми для организации сегментации и безопасности внутри DMZ. Они позволяют:

• реализовать централизованное управление политиками трафика;
• внедрять TLS между микросервисами по умолчанию;
• внедрять правила rate limiting, retries, circuit breakers без изменения кода;
• мониторить East-West трафик и аномалии в поведении.

Sidecar-прокси в этом случае действуют как охранники у каждого сервиса. Они принимают весь трафик, проверяют его, шифруют, логируют и только потом пропускают внутрь контейнера.

Общие сервисы: риски при совместном использовании DNS и NTP

На первый взгляд идея общих служб кажется разумной: зачем плодить сущности, если можно использовать единый DNS-сервер и один NTP — и для DMZ, и для внутренней сети? Но в реальности такой подход создает опасные точки пересечения между зонами с разным уровнем доверия. Любой сервис, доступный одновременно из доверенной сети и из DMZ, становится потенциальным мостом для атак.

Скомпрометированный хост в DMZ может использовать общий DNS для туннелирования данных или C2-связи, а через общий NTP — попытаться дестабилизировать инфраструктуру, подменив время. Эти службы редко воспринимаются как «опасные», и злоумышленники охотно этим пользуются.

DNS — типичный пример: он может стать каналом для передачи данных, особенно если включены recursive lookup или wildcard-запросы. А если DMZ имеет доступ к тем же зонам, что и внутренняя сеть, атакующий получает удобный инструмент разведки: можно подбирать записи, выявлять внутренние сервисы и строить карту инфраструктуры.

Павел Карасев

Бизнес-партнер компании «Компьютерные технологии»

Многие забывают, что такие простые, «технические» сервисы, как DNS и NTP, тоже могут быть векторами атаки. Особенно когда одни и те же серверы используются и в DMZ, и во внутренней сети. Это как передавать письмо через незапечатанный конверт — можно и подменить, и подсмотреть.

Лучше всего — держать разные DNS-серверы: одни отвечают за DMZ, другие — за внутреннюю сеть. Никакого кэширования между ними. Если DNS общий — хотя бы внедрите DNSSEC и разделите зоны. С NTP все то же самое: лучше, если внутри свои сервера, а для DMZ — отдельный источник синхронизации. И, конечно, никакого широкого доступа по UDP.

NTP, кажущийся безобидным, способен привести к хаосу. Скомпрометированный сервер времени может «сломать» логирование, истечь срок действия сертификатов, сбить расписание задач cron. В ряде случаев это вызывает DoS и выводит из строя системы мониторинга или аутентификации.

И, наконец, оба сервиса — DNS и NTP — при неправильной настройке могут быть использованы как отражатели в amplification-атаках. Их можно эксплуатировать и извне, и изнутри — если злоумышленник уже закрепился в DMZ.

Ирина Дмитриев

Аналитик лаборатории исследований кибербезопасности компании «Газинформсервис»

Рекомендуется разделять DNS-зоны строго по периметру: DMZ — своя зона, внутренняя сеть — своя, исключая наличие общих резолверов; внутренние DNS-сервера не должны быть доступны из DMZ даже через форвардинг. Для NTP разделять на уровни взаимодействия: DMZ синхронизируется с внешними источниками, внутренняя сеть — от доверенного локального сервера. В то же время межзонная синхронизация NTP — только через строго фильтрованные ACL и без возможности транзитных соединений.

Стоит рассмотреть отключение зоны-трансфера или разрешить ее только по IP и с TSIG-подписью — иначе конфигурация публикуется наружу.

Обязательно сделать алерты на подозрительные запросы к DNS и NTP — всплески или неожиданные обращения к зонам могут сигнализировать о попытке атаки. И главное — не ставить «временно» общий сервер DNS/NTP — он быстро станет уязвимой поверхностью для атаки.

Чтобы не дать этим «базовым» службам стать уязвимым звеном, важно применять четкие архитектурные меры.

Такие меры могут показаться мелочами, но именно на них строится первая фаза сложных атак: от разведки до скрытого управления. DMZ не должна быть «почти внутренней сетью» — она должна быть отдельным, строго контролируемым сегментом, где даже привычные сервисы не работают по-старому.

Контроль East-West трафика в контейнерной DMZ

Контроль East-West трафика в контейнерной DMZ — это не просто «еще одна галочка» в чек-листе. Это настоящий вызов. В отличие от классической модели, где можно было отлавливать пакеты на периметре, в контейнерной среде весь трафик живет внутри — от пода к поду, от сервиса к сервису. И именно там чаще всего прячется злоумышленник после первичного доступа.

Контейнеры общаются друг с другом быстро, часто, и динамично. Один скомпрометированный под — и злоумышленник начинает двигаться по среде. Тихо, незаметно, по горизонтали. Чтобы это остановить, нужна не просто видимость, а жесткий контроль.

Кирилл Бочкарев

Архитектор инфраструктуры информационной безопасности, «Инфосистемы Джет»

Для того чтобы эффективно обеспечить контроль East-West-трафика, рекомендуем использовать Kubernetes Network Policies в сочетании с инструментами, которые позволят в автоматическом режиме определить маршруты трафика для корректной настройки политик. Это могут быть как платные инструменты, входящие в состав Container-security-решений, так и Open-Souce-инструменты. Специализированные решения Container security в подобных сценариях также позволят выявлять аномалии, определять изменения, которые в сетевые политики необходимо внести, а также передавать информацию в SIEM-системы в нужном формате для определения возможных инцидентов ИБ.

• Сервис-меши. Задают строгие политики доступа между сервисами, обеспечивают mTLS, трассировку запросов и централизованный контроль над взаимодействиями.
• Поведенческий анализ. Позволяет не просто видеть трафик, но и понимать его. Кто и как себя ведет? Что выглядит подозрительно? Если под, который раньше ходил только в Redis, внезапно лезет в API другого сервиса — это сигнал.
• Интеграция с SIEM и XDR. Дает возможность склеивать сетевые события с логами Kubernetes, правами доступа, активностью пользователя. Только так можно поймать сложные цепочки атак.

Контейнерная DMZ — это не граница, это живая, быстро меняющаяся среда. Здесь нет «одной точки входа» — здесь есть 100 маленьких дверей. И если вы не контролируете, кто в какую заходит, атака станет вопросом времени. Поэтому East-West трафик — это не фон. Это поле боя.

Практические сценарии и архитектурные шаблоны

DMZ — это не только про железо на периметре. В гибридной инфраструктуре она становится логическим слоем, который тянется от облаков до он-према, от куберов до лямбд. И чем сложнее архитектура, тем важнее четкий, продуманный шаблон. Без него легко получить «DMZ на соплях» — где сервисы живут на доверии, а атаки — на интуиции.

На практике это может быть:

• Обратный прокси в облаке. Принимает трафик снаружи, проверяет, фильтрует, и только потом пускает внутрь. Можно добавить WAF, TLS-терминацию, проверку токенов. Особенно полезно, когда API живет в облаке, а бизнес-логика — на земле.
• API-шлюзы. Работают как брандмауэр для микросервисов. Валидируют схемы запросов, контролируют версии, ограничивают скорость, логируют каждый вызов. Это must-have, если у вас более одного внешнего API.
• Сегментирующие файрволы. Разделяют зону DMZ от внутренней сети. Не по IP, а по роли, тегам, поведению. Только строгое правило: «этот сервис может говорить только с этим, и только вот так».

К примеру, в Яндексе DMZ-уровень реализован в облаке через балансировщики и прокси с фильтрацией на уровне WAF. Внутренние сервисы сегментированы с помощью тегов и политик, что ограничивает нежелательное взаимодействие. Для обнаружения аномалий используется поведенческий анализ, а безопасность усиливается собственными IDS/IPS и анти-DDoS-фильтрами.

Суть в том, что DMZ сегодня — это не только про «держать зло наружу». Это про контроль входов и выходов, даже если все внутри. Правильный шаблон архитектуры задает рамки и не дает хаосу стать нормой. А хаос, как мы знаем, — любимая среда атакующего.

Заключение

Построить DMZ, которая выдержит вызовы 2025 года — задача комплексная, где важна каждая деталь. Прежде всего, уделите максимум внимания сегментации и изоляции: разделяйте зоны с четкими политиками доступа, используйте forwarding-only DNS, прокси для NTP и строгие firewall-правила. Не забывайте про микросегментацию внутри DMZ, особенно если у вас контейнеры и микросервисы — здесь на помощь приходят сервис-меши и eBPF.

Логирование и мониторинг — ваш постоянный сторож. Важно настроить сбор и корреляцию событий, отслеживать аномалии трафика и поведения сервисов, интегрировать эти данные с SIEM и XDR-системами. Так, вы сможете быстро выявлять и локализовать инциденты.

Наконец, архитектурные решения должны подкрепляться операционными процессами и четкими политиками безопасности. Регулярные обновления, контроль доступа, аудит и обучение персонала — все это создает надежный щит вокруг вашей DMZ, позволяя ей эффективно работать даже в условиях постоянно меняющихся угроз.