Статья
NGFW сегодня:
шифрованный трафик, HTTP/3, Zero Trust и переход на отечественные решения
шифрованный трафик, HTTP/3, Zero Trust и переход на отечественные решения
Мир сетевой безопасности резко изменился: трафик шифруется по умолчанию, на первый план вышли HTTP/2−3 и QUIC, растут атаки через учетные записи и эксплуатацию уязвимостей, заметно прибавил вектор DNS. Классический DPI теряет видимость, поэтому организации смещаются к телеметрии по метаданным, выборочной расшифровке, East-West-контролю и микросегментации, а сам межсетевой экран становится частью связки с принципами Zero Trust и сервисными моделями SASE/SSE.
Мы поговорили с Виктором Гуровым, руководителем направления информационной безопасности Ideco, о том, как меняется функционал NGFW в условиях TLS 1.3 и ECH, где проходит граница между глубокой инспекцией и производительностью, какие ошибки чаще всего допускают при сегментации, как встроить NGFW в DevOps/CI/CD без замедления релизов, с какими «подводными камнями» сталкиваются при миграции с импортных продуктов на отечественные, какие требования 187-ФЗ и приказа ФСТЭК № 239 сильнее всего влияют на архитектуру, как выстроить мониторинг с пользой для SOC и как масштабировать защиту для высоконагруженных сетей.
Какие векторы атак сильнее всего повлияли на развитие современных межсетевых экранов за последние годы?
За последние годы ключевое влияние на развитие современных межсетевых экранов оказали два фактора: массовое шифрование трафика «по умолчанию» и смена протокольного ландшафта (HTTP/2−3, QUIC), что усложнило анализ потоков и заставило вендоров искать новые подходы к видимости данных. Одновременно усилились идентификационные атаки и вымогательство: злоумышленники чаще используют эксплуатацию уязвимостей и компрометацию учётных записей как основные пути проникновения в инфраструктуру. Это привело к усилению IPS, контекстно-идентификационных политик, средств East-West-контроля и развитию телеметрии с элементами NDR, основанной на анализе метаданных зашифрованного трафика.
Отдельного внимания заслуживает рост атак на уровне DNS, которые стали важным вектором как для доставки вредоносного кода, так и для скрытого управления ботнетами и утечек данных. Это подтолкнуло производителей NGFW к внедрению модулей DNS-фильтрации, анализу доменных паттернов и интеграции с TI-фидами. При этом, хотя суммы выплат по вымогательству в 2024 году начали снижаться, общая активность остается высокой, что усиливает актуальность сетевой сегментации и быстрого отсечения lateral movement внутри инфраструктуры.
Как изменился подход к расшифровке и анализу зашифрованного трафика в условиях массового перехода на TLS 1.3 и ECH?
C переходом на TLS 1.3 изменилась сама экономика видимости: после ServerHello практически весь хэндшейк шифруется, повсеместно используется PFS на базе (EC) DHE, и классическое пассивное расшифрование трафика «по ключу сервера» больше не работает — без участия одной из сторон MITM невозможен технически и юридически рискован. Поэтому предприятия перешли к выборочному расшифрованию через прокси-терминаторы (selective decryption) на доверенных доменах/категориях и к методам анализа без расшифровки — от Encrypted Traffic Analytics до TLS-фингерпринтинга JA3/JA3S как опоры для детектов и триажа. Появление ECH, которое шифрует чувствительные поля ClientHello и скрывает SNI, ещё сильнее ограничило политики «по домену без расшифровки» и заставило полагаться на проксирование либо на метаданные/поведение.
Где проходит оптимальная граница между глубокой инспекцией трафика и производительностью сети?
Граница между глубокой инспекцией и производительностью сегодня проходит по принципу «метаданные везде, расшифровка точечно». Для массового пользовательского и микро-сервисного трафика разумно опираться на L7-контекст без тотального MITM: сигнатуры приложений, поведенческие/статистические признаки шифрованных потоков, TLS/QUIC-фингерпринты и политики «по личности» (user/device). QUIC и HTTP/3, шифруя всё поверх UDP, объективно сокращают возможности DPI и усложняют наблюдаемость; на практике SLA держат горизонтальным масштабированием и кластерами, добавляя расшифровку только для ограниченных категорий трафика с высоким риском или юридической необходимостью.
Какие ошибки компании чаще всего допускают при проектировании сетевой сегментации и разграничения доступа?
Чаще всего при проектировании сегментации и разграничения доступа компании ошибаются в двух зонах: сохраняют «плоскую» сеть с чрезмерно широкими правилами any-any между зонами и недооценивают микросегментацию на уровне рабочих нагрузок и Pod'ов. Для Kubernetes это усугубляется отсутствием или номинальным использованием NetworkPolicy и admission-контроля: по умолчанию трафик между Pod’ами открыт, и без политик изоляции достигается легко. Актуальные руководства NSA/CISA прямо подчеркивают необходимость сетевой изоляции, политики «наименьших привилегий» и вынесенного логирования, иначе латеральное перемещение остаётся беспрепятственным.
Как меняется типовой функционал NGFW на фоне роста облачной архитектуры и концепции Zero Trust?
Типовой функционал NGFW в облачную эпоху смещается в сторону сервисной модели и принципов Zero Trust: SASE/SSE объединяют SWG, CASB, ZTNA и FWaaS как облачные сервисы, а "классический" межсетевой экран становится элементом цепочки принудительного прохождения трафика, где решения опираются на идентичность субъекта и контекст запроса. Базовым нормативом для архитектуры выступает NIST SP 800−207, а на практике это означает identity-aware-правила, микросегментацию и поддержку современных протоколов (включая HTTP/3/QUIC) с анализом шифрованного трафика без тотального MITM.
Насколько реально интегрировать NGFW в процессы DevOps/CI/CD, чтобы защитить сервисы без замедления релизов?
Интеграция NGFW в процессы DevOps и CI/CD на российском рынке становится всё более реальной благодаря использованию API-подхода и инфраструктурной автоматизации без привязки к зарубежным провайдерам. Современные отечественные NGFW поддерживают REST-API и JSON-шаблоны конфигураций, что позволяет описывать политики и сегменты как код, хранить их в системах контроля версий (GitLab, Gitea) и применять транзакционно вместе с инфраструктурными изменениями. Для кластеров и контейнерных сред реализуется интеграция с Kubernetes CRD-объектами и вебхуками в пайплайне, которые автоматически проверяют корректность политик безопасности до деплоя. Наблюдаемость и тестируемость обеспечиваются через встроенные метрики и экспорт NetFlow/IPFIX в системы мониторинга (Prometheus, Grafana). Такой подход позволяет встроить NGFW в цикл CI/CD без замедления релизов, сохраняя при этом контроль и согласованность политик между разработкой, тестированием и продом.
Как организации подходят к миграции с импортных решений на отечественные NGFW: что чаще всего становится «подводным камнем»?
При миграции с импортных решений на отечественные NGFW «узкими местами» становятся неполная конвертация правил, различия в моделях объектов и App-ID, несовпадение форматов логов/интеграций с SIEM/SOAR, а также необходимость переобучения команды. Кроме того, часть функциональности приходится добирать несколькими продуктами, что усложняет эксплуатацию гибридной инфраструктуры; рынок ещё консолидируется, и зрелость продуктов неравномерна. Всё это накладывается на требования отечественной сертификации, что влияет на схемы включения и доступные криптомеханизмы. Практический опыт внедрений в российской прессе и блоге-кейсы подтверждают как технические, так и организационные риски — от ручных правок при конвертации до разницы в зонировании и "широких" правилах, которые нужно переразложить на отечественной платформе.
Какие требования регуляторов сильнее всего влияют на архитектуру NGFW сегодня?
Регуляторные требования, сильнее всего влияющие на архитектуру NGFW в России, — это 187-ФЗ о безопасности КИИ и обновлённый Приказ ФСТЭК № 239 (ред. 28.08.2024), предписывающие меры защиты, категорирование, контроль трафика и жизненный цикл безопасности для значимых объектов. Дополнительно требования ФСБ к СКЗИ и сертификации диктуют выбор криптосредств и способы их включения, что практически определяет возможности дешифрования и протоколы удалённого доступа. В совокупности это требует опоры на сертифицированные компоненты и корректной схемы размещения NGFW в контуре КИИ.
Как выстраивать мониторинг и реагирование на инциденты на базе NGFW, чтобы он давал реальную ценность для SOC?
Чтобы мониторинг и реагирование на базе NGFW давали реальную ценность для SOC, важно не ограничиваться «логом сработки», а системно вывозить телеметрию: трафик / угрозы / URL / DNS / дешифрование / HTTP2−3 / QUIC-атрибуты, идентичности пользователей и контейнерный контекст. Эти события должны нормализоваться и обогащаться в SIEM/NDR, включая TLS-фингерпринты JA3/JA3S, которые поддерживают как open-source (Zeek), так и коммерческие экосистемы и TI-фиды. Для оркестрации эффективны динамические адрес-группы и External Dynamic Lists, позволяющие автоматически применять блокирующие политики по сигналу из TI/SOAR без ручного вмешательства.
Как меняются подходы к отказоустойчивости и масштабированию межсетевых экранов для высоконагруженных сетей?
Подходы к отказоустойчивости и масштабированию для высоконагруженных сетей смещаются от "пары актив/пассив" к горизонтальным HA-кластерам с синхронизацией сессий и ECMP, а в облаках — к паттернам с AWS Gateway Load Balancer для эластичного масштабирования виртуальных NGFW на ingress/east-west/outbound-пути. Для сверхвысоких скоростей значим аппаратный оффлоад на сетевых процессорах (например, NP7) и "hyperscale"-режимах: часть сессионной логики уходит в аппарат, уменьшается латентность, а наблюдаемость обеспечивается телеметрией по аппаратно установившимся сессиям. Эти паттерны детально описаны в документации вендоров и AWS-гайдах по GWLB.
Мы поговорили с Виктором Гуровым, руководителем направления информационной безопасности Ideco, о том, как меняется функционал NGFW в условиях TLS 1.3 и ECH, где проходит граница между глубокой инспекцией и производительностью, какие ошибки чаще всего допускают при сегментации, как встроить NGFW в DevOps/CI/CD без замедления релизов, с какими «подводными камнями» сталкиваются при миграции с импортных продуктов на отечественные, какие требования 187-ФЗ и приказа ФСТЭК № 239 сильнее всего влияют на архитектуру, как выстроить мониторинг с пользой для SOC и как масштабировать защиту для высоконагруженных сетей.
Какие векторы атак сильнее всего повлияли на развитие современных межсетевых экранов за последние годы?
За последние годы ключевое влияние на развитие современных межсетевых экранов оказали два фактора: массовое шифрование трафика «по умолчанию» и смена протокольного ландшафта (HTTP/2−3, QUIC), что усложнило анализ потоков и заставило вендоров искать новые подходы к видимости данных. Одновременно усилились идентификационные атаки и вымогательство: злоумышленники чаще используют эксплуатацию уязвимостей и компрометацию учётных записей как основные пути проникновения в инфраструктуру. Это привело к усилению IPS, контекстно-идентификационных политик, средств East-West-контроля и развитию телеметрии с элементами NDR, основанной на анализе метаданных зашифрованного трафика.
Отдельного внимания заслуживает рост атак на уровне DNS, которые стали важным вектором как для доставки вредоносного кода, так и для скрытого управления ботнетами и утечек данных. Это подтолкнуло производителей NGFW к внедрению модулей DNS-фильтрации, анализу доменных паттернов и интеграции с TI-фидами. При этом, хотя суммы выплат по вымогательству в 2024 году начали снижаться, общая активность остается высокой, что усиливает актуальность сетевой сегментации и быстрого отсечения lateral movement внутри инфраструктуры.
Как изменился подход к расшифровке и анализу зашифрованного трафика в условиях массового перехода на TLS 1.3 и ECH?
C переходом на TLS 1.3 изменилась сама экономика видимости: после ServerHello практически весь хэндшейк шифруется, повсеместно используется PFS на базе (EC) DHE, и классическое пассивное расшифрование трафика «по ключу сервера» больше не работает — без участия одной из сторон MITM невозможен технически и юридически рискован. Поэтому предприятия перешли к выборочному расшифрованию через прокси-терминаторы (selective decryption) на доверенных доменах/категориях и к методам анализа без расшифровки — от Encrypted Traffic Analytics до TLS-фингерпринтинга JA3/JA3S как опоры для детектов и триажа. Появление ECH, которое шифрует чувствительные поля ClientHello и скрывает SNI, ещё сильнее ограничило политики «по домену без расшифровки» и заставило полагаться на проксирование либо на метаданные/поведение.
Где проходит оптимальная граница между глубокой инспекцией трафика и производительностью сети?
Граница между глубокой инспекцией и производительностью сегодня проходит по принципу «метаданные везде, расшифровка точечно». Для массового пользовательского и микро-сервисного трафика разумно опираться на L7-контекст без тотального MITM: сигнатуры приложений, поведенческие/статистические признаки шифрованных потоков, TLS/QUIC-фингерпринты и политики «по личности» (user/device). QUIC и HTTP/3, шифруя всё поверх UDP, объективно сокращают возможности DPI и усложняют наблюдаемость; на практике SLA держат горизонтальным масштабированием и кластерами, добавляя расшифровку только для ограниченных категорий трафика с высоким риском или юридической необходимостью.
Какие ошибки компании чаще всего допускают при проектировании сетевой сегментации и разграничения доступа?
Чаще всего при проектировании сегментации и разграничения доступа компании ошибаются в двух зонах: сохраняют «плоскую» сеть с чрезмерно широкими правилами any-any между зонами и недооценивают микросегментацию на уровне рабочих нагрузок и Pod'ов. Для Kubernetes это усугубляется отсутствием или номинальным использованием NetworkPolicy и admission-контроля: по умолчанию трафик между Pod’ами открыт, и без политик изоляции достигается легко. Актуальные руководства NSA/CISA прямо подчеркивают необходимость сетевой изоляции, политики «наименьших привилегий» и вынесенного логирования, иначе латеральное перемещение остаётся беспрепятственным.
Как меняется типовой функционал NGFW на фоне роста облачной архитектуры и концепции Zero Trust?
Типовой функционал NGFW в облачную эпоху смещается в сторону сервисной модели и принципов Zero Trust: SASE/SSE объединяют SWG, CASB, ZTNA и FWaaS как облачные сервисы, а "классический" межсетевой экран становится элементом цепочки принудительного прохождения трафика, где решения опираются на идентичность субъекта и контекст запроса. Базовым нормативом для архитектуры выступает NIST SP 800−207, а на практике это означает identity-aware-правила, микросегментацию и поддержку современных протоколов (включая HTTP/3/QUIC) с анализом шифрованного трафика без тотального MITM.
Насколько реально интегрировать NGFW в процессы DevOps/CI/CD, чтобы защитить сервисы без замедления релизов?
Интеграция NGFW в процессы DevOps и CI/CD на российском рынке становится всё более реальной благодаря использованию API-подхода и инфраструктурной автоматизации без привязки к зарубежным провайдерам. Современные отечественные NGFW поддерживают REST-API и JSON-шаблоны конфигураций, что позволяет описывать политики и сегменты как код, хранить их в системах контроля версий (GitLab, Gitea) и применять транзакционно вместе с инфраструктурными изменениями. Для кластеров и контейнерных сред реализуется интеграция с Kubernetes CRD-объектами и вебхуками в пайплайне, которые автоматически проверяют корректность политик безопасности до деплоя. Наблюдаемость и тестируемость обеспечиваются через встроенные метрики и экспорт NetFlow/IPFIX в системы мониторинга (Prometheus, Grafana). Такой подход позволяет встроить NGFW в цикл CI/CD без замедления релизов, сохраняя при этом контроль и согласованность политик между разработкой, тестированием и продом.
Как организации подходят к миграции с импортных решений на отечественные NGFW: что чаще всего становится «подводным камнем»?
При миграции с импортных решений на отечественные NGFW «узкими местами» становятся неполная конвертация правил, различия в моделях объектов и App-ID, несовпадение форматов логов/интеграций с SIEM/SOAR, а также необходимость переобучения команды. Кроме того, часть функциональности приходится добирать несколькими продуктами, что усложняет эксплуатацию гибридной инфраструктуры; рынок ещё консолидируется, и зрелость продуктов неравномерна. Всё это накладывается на требования отечественной сертификации, что влияет на схемы включения и доступные криптомеханизмы. Практический опыт внедрений в российской прессе и блоге-кейсы подтверждают как технические, так и организационные риски — от ручных правок при конвертации до разницы в зонировании и "широких" правилах, которые нужно переразложить на отечественной платформе.
Какие требования регуляторов сильнее всего влияют на архитектуру NGFW сегодня?
Регуляторные требования, сильнее всего влияющие на архитектуру NGFW в России, — это 187-ФЗ о безопасности КИИ и обновлённый Приказ ФСТЭК № 239 (ред. 28.08.2024), предписывающие меры защиты, категорирование, контроль трафика и жизненный цикл безопасности для значимых объектов. Дополнительно требования ФСБ к СКЗИ и сертификации диктуют выбор криптосредств и способы их включения, что практически определяет возможности дешифрования и протоколы удалённого доступа. В совокупности это требует опоры на сертифицированные компоненты и корректной схемы размещения NGFW в контуре КИИ.
Как выстраивать мониторинг и реагирование на инциденты на базе NGFW, чтобы он давал реальную ценность для SOC?
Чтобы мониторинг и реагирование на базе NGFW давали реальную ценность для SOC, важно не ограничиваться «логом сработки», а системно вывозить телеметрию: трафик / угрозы / URL / DNS / дешифрование / HTTP2−3 / QUIC-атрибуты, идентичности пользователей и контейнерный контекст. Эти события должны нормализоваться и обогащаться в SIEM/NDR, включая TLS-фингерпринты JA3/JA3S, которые поддерживают как open-source (Zeek), так и коммерческие экосистемы и TI-фиды. Для оркестрации эффективны динамические адрес-группы и External Dynamic Lists, позволяющие автоматически применять блокирующие политики по сигналу из TI/SOAR без ручного вмешательства.
Как меняются подходы к отказоустойчивости и масштабированию межсетевых экранов для высоконагруженных сетей?
Подходы к отказоустойчивости и масштабированию для высоконагруженных сетей смещаются от "пары актив/пассив" к горизонтальным HA-кластерам с синхронизацией сессий и ECMP, а в облаках — к паттернам с AWS Gateway Load Balancer для эластичного масштабирования виртуальных NGFW на ingress/east-west/outbound-пути. Для сверхвысоких скоростей значим аппаратный оффлоад на сетевых процессорах (например, NP7) и "hyperscale"-режимах: часть сессионной логики уходит в аппарат, уменьшается латентность, а наблюдаемость обеспечивается телеметрией по аппаратно установившимся сессиям. Эти паттерны детально описаны в документации вендоров и AWS-гайдах по GWLB.
Другие публикации по теме