SWG vs NGFW: почему веб-контроль не должен жить только на межсетевом экране

Корпоративный интернет давно перестал быть набором разрешенных и запрещенных сайтов. Сотрудники работают в SaaS, облачных хранилищах, веб-почте, мессенджерах и ИИ-сервисах. Разрешить сотруднику нужный веб-сервис не значит разрешить любые действия внутри него. Отдельный слой веб-контроля становится особенно важен там, где компании нужно сохранить доступ к рабочим сервисам. Но при этом детально управлять рисками, расследовать действия пользователей и масштабировать веб-защиту независимо от сетевого периметра.

Что такое NGFW и какие функции он выполняет

NGFW, или Next-Generation Firewall, — это развитие классического межсетевого экрана. Обычный межсетевой экран контролирует соединения по IP-адресам, протоколам и портам, а современный межсетевой экран дополнительно распознает приложения и выявляет сетевые угрозы. Такой межсетевой экран остается одним из основных элементов защиты периметра.

Также он обычно совмещает сетевые политики, NAT, VPN, маршрутизацию, IPS/IDS и контроль приложений. Может фильтровать сайты по URL и категориям. Поэтому вопрос не в том, способен ли NGFW выполнять веб-контроль, а в том, насколько целесообразно нагружать его глубоким анализом всего пользовательского веб-трафика.

Основные задачи Next-Generation Firewall:

• Защита периметра. Контроль исходящих и входящих сетевых соединений.
• IPS/IDS. Обнаружение и пресечение сетевых атак.
• VPN, NAT и маршрутизация. Управление защищенными соединениями.
• Контроль приложений. Классификация приложений с последующим применением правил защиты.
• Базовая веб-фильтрация. Ограничение доступа к категориям ресурсов и URL.

Ограничения NGFW как единственного слоя веб-контроля

Корпоративная веб-нагрузка постоянно растет: сотрудники используют SaaS, облачные хранилища, браузерные мессенджеры, ИИ-сервисы и активно обмениваются файлами. Большая часть такого трафика передается по HTTPS. Для применения контентных и других политик, требующих анализа содержимого HTTPS-трафика, соответствующие соединения необходимо расшифровывать. Такая инспекция, проверка файлов и подробное журналирование требуют дополнительных вычислительных ресурсов.

Если такой анализ выполняет NGFW, то SSL/TLS-инспекция, категоризация ресурсов, антивирусная проверка и подробное журналирование работают на одном устройстве с IPS и маршрутизацией. Производительность NGFW зависит не только от объема проходящего трафика, но и от количества включенных функций безопасности. При глубокой SSL/TLS-инспекции пропускная способность NGFW может заметно снижаться, причем величина снижения зависит от конкретной платформы, набора включенных проверок и профиля трафика, поэтому реальное влияние инспекции важно оценивать в конкретной инфраструктуре.

Ограничения проявляются сразу на трех уровнях:

1. Производительность. Веб-инспекция, проверка файлов и журналирование используют те же вычислительные ресурсы платформы, что и IPS, VPN и другие сетевые функции.
2. Масштабирование. При росте числа HTTPS-сессий и глубины веб-проверок может потребоваться дополнительный запас производительности платформы, хотя рост нагрузки связан прежде всего с пользовательским веб-трафиком.
3. Видимость. Сетевых событий не всегда достаточно, чтобы понять, какой URL открыл пользователь, какой файл загрузил или выгрузил, каким облачным или ИИ-сервисом воспользовался.

Если существенная часть нагрузки связана именно с веб-инспекцией, усиливать весь периметровый комплекс не всегда рационально. Компания может оптимизировать состав проверок, перераспределить функции между узлами, усилить NGFW или вынести специализированные веб-задачи в отдельный SWG-слой. Последний вариант позволяет развивать веб-контроль как самостоятельную часть архитектуры — со своими политиками, интеграциями, журналированием и ресурсами.

Разделяйте функции, сохраняйте устойчивость

Сетевой периметр и пользовательский веб-канал требуют разного подхода к анализу трафика. Если обработку HTTP(S), проверку файлов и детальное журналирование вынести в специализированный шлюз, это может высвободить часть ресурсов NGFW для VPN, IPS и маршрутизации — в зависимости от архитектуры и оставшихся на нем проверок. ИБ при этом получает более подробную картину действий пользователей и архитектуру, которую проще масштабировать по мере роста веб-нагрузки.

Екатерина Черкасова

PMM Solar webProxy

Что такое SWG и какие функции он берет на себя

SWG (Secure Web Gateway) — специализированное решение для защиты интернет-доступа. Шлюз обрабатывает трафик между пользователями и внешними сервисами: проверяет содержимое запросов и ответов, управляет доступом и анализирует данные.

В основе такого решения обычно работает прокси-сервер, через который направляются веб-запросы сотрудников. Но возможности SWG этим не ограничиваются: платформа определяет категории ресурсов, проверяет зашифрованный трафик, учитывает пользователя и его действия, а также собирает данные для анализа. Поэтому Secure Web Gateway — это полноценный защитный слой, а не просто посредник между браузером и интернетом.

В зависимости от конкретной реализации SWG может контролировать HTTPS-трафик на уровне отдельных веб-действий: какой ресурс открыл пользователь, что загрузил или выгрузил, с каким SaaS, облачным или ИИ-сервисом работал. Это помогает применять более точные правила и позволяет вынести часть ресурсоемких веб-проверок с NGFW на отдельный шлюз, снижая нагрузку на него в зависимости от выбранной архитектуры и набора проверок.

Основные функции SWG:

• Категоризация ресурсов. Разделение сайтов и сервисов по категориям для применения правил доступа.
• Инспекция зашифрованного трафика. Проверка выбранных HTTPS-соединений и передаваемого содержимого.
• Контроль файлов. Анализ выгрузок и загрузок с учетом политик безопасности.
• Контроль SaaS и ИИ-сервисов. Контроль доступа и действий пользователей в веб-приложениях в пределах возможностей конкретной реализации.
• Журналирование и аналитика. Сохранение контекста событий для расследований.

В результате SWG дает ИБ не только сведения о самом соединении, но и контекст веб-сессии: пользователя, категорию ресурса, выполненное действие, переданный файл и сработавшую политику. Это позволяет точнее управлять интернет-доступом и разбирать спорные или потенциально опасные действия.

Проверьте, как SWG усилит безопасность организации. Узнайте, какие механизмы веб-прокси, антивирусной проверки, категоризации и контроля можно вынести в специализированный слой.

Скачать презентацию

Ключевые отличия SWG от NGFW: почему специализированный SWG глубже контролирует веб-трафик

В задачах корпоративного веб-контроля SWG работает глубже, потому что пользовательский веб-трафик для него является основным объектом анализа и управления. Решение позволяет строить политики с учетом контекста веб-сессии: ресурса и его категории, HTTP(S)-запросов и ответов, передаваемого контента и файлов, а также действий пользователя внутри веб-канала. NGFW в первую очередь специализируется на контроле сетевого взаимодействия, приложений и защите периметра. Поэтому в сценариях, где требуется детальный контроль действий пользователей, содержимого и передачи данных через веб, специализированный SWG дает более глубокий уровень управления веб-доступом.

Именно поэтому NGFW и SWG нельзя сравнивать только по наличию отдельных функций. Важно, насколько глубоко система позволяет управлять самим веб-взаимодействием пользователя. Для SWG это основная задача продукта: политики строятся вокруг веб-сессии, запросов и ответов, контента, файлов и действий пользователя. Для NGFW основная предметная область — сетевое взаимодействие и защита периметра.

У специализированного SWG есть и архитектурное преимущество. HTTP(S)-инспекция, категоризация, контентные и файловые проверки, подробное журналирование и связанные с ними интеграции выполняются в отдельном веб-слое и не обязаны конкурировать за те же ресурсы с IPS, VPN, NAT, маршрутизацией и другими функциями NGFW. Поэтому при росте пользовательского HTTPS-трафика можно независимо масштабировать именно веб-контроль, а не усиливать всю периметровую платформу.

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

Когда компании стоит рассматривать отдельный SWG

Отдельный SWG особенно оправдан, когда веб-доступ становится самостоятельной задачей ИБ и эксплуатации. На практике это видно по нескольким признакам:

• Нужно различать действия пользователей внутри разрешенных веб-сервисов.
• SaaS, облака и ИИ становятся значимым рабочим каналом и требуют отдельных политик.
• К веб-трафику нужно подключать DLP, антивирусы, песочницы и другие профильные средства проверки.
• Для расследований недостаточно общего сетевого события — нужен подробный контекст веб-сессии.
• Веб-политики и филиальные сценарии требуют самостоятельного цикла управления.
• Обработку пользовательского интернет-трафика нужно масштабировать независимо от NGFW.

Наличие действующего NGFW при этом не отменяет потребность в SWG: вопрос не в замене межсетевого экрана, а в глубине и самостоятельности веб-контроля.

Когда NGFW может быть не оптимален как единственный слой веб-контроля

Полезнее спрашивать не «умеет ли межсетевой экран фильтровать сайты», а «какой ценой он делает это при рабочем наборе проверок». Если значительная часть интернета — HTTP(S), а SSL/TLS-инспекция включена для большого потока, нагрузка смещается в веб-анализ. Тогда паспортная пропускная способность NGFW перестает быть достаточным ориентиром без замеров в реальной конфигурации.

До закупки стоит провести диагностику в часы пик. Важно смотреть не только на скорость канала, но и на число пользователей, активные HTTPS-сессии и состав включенных проверок. Тогда решение о выделенном SWG можно связать с измеримым узким местом, а не с формальным сравнением классов продуктов. Проверьте:

• Долю HTTP/HTTPS. Какую часть интернет-трафика занимает пользовательский веб.
• Загрузку процессора и задержки. Как меняются ресурсы и задержки после включения инспекции.
• Фактическую пропускную способность. Какой поток обрабатывается одновременно с IPS, VPN и веб-проверками.
• Качество журналов. Можно ли восстановить действия пользователя с файлами, облаками и ИИ.
• Распределенность. Есть ли филиалы, локальные выходы и разные политики доступа.

Когда отдельное масштабирование SWG может быть рациональнее усиления NGFW под веб-нагрузку

Если дополнительная нагрузка возникает именно из-за веб-трафика, усиливать весь периметровый комплекс не всегда рационально. Масштабирование SWG позволяет добавлять вычислительные ресурсы именно там, где они нужны: на узлах, которые выполняют инспекцию и фильтрацию. Это помогает избежать замены или апгрейда NGFW только из-за роста пользовательского HTTPS.

Так компания может масштабировать веб-контроль независимо от VPN или IPS. Новые SWG-узлы можно подключать по мере роста числа пользователей, филиалов или объема трафика, распределяя обработку между ними. Такой подход позволяет направлять ресурсы на расширение конкретного веб-слоя, а не на усиление всей периметровой платформы; фактический экономический эффект зависит от архитектуры, лицензирования и требований к отказоустойчивости.

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

Сценарии совместной работы

Совместное использование решений особенно актуально, когда действующий NGFW справляется с задачами периметра, но компании требуется более глубокий контроль пользовательского интернет-трафика. В этом случае менять уже работающий сетевой комплекс не нужно: веб-фильтрацию, инспекцию HTTP(S), проверку файлов и подробное журналирование можно перенести на SWG. Такая схема позволяет вынести часть ресурсоемких веб-проверок с NGFW и развивать веб-защиту независимо от сетевого периметра; фактический эффект по нагрузке зависит от архитектуры и распределения функций между решениями.

Еще один сценарий связан с действиями пользователей, которые трудно детально восстановить только по сетевым событиям. Это загрузка файлов в облачные хранилища, работа с ИИ-сервисами, отправка данных через веб-формы, использование WebSocket, SOCKS5 и других способов обмена данными. При наличии поддержки соответствующих протоколов и механизмов анализа SWG позволяет применять к таким действиям отдельные политики и сохранять необходимый контекст для последующего анализа.

Совместная схема востребована, когда необходимо:

• Перенести веб-проверки с NGFW. Выполнять инспекцию, категоризацию, проверку файлов и детальное журналирование на специализированном шлюзе.
• Контролировать облачные и ИИ-сервисы. Отслеживать передачу данных и применять политики к конкретным действиям пользователей.
• Подключить дополнительные средства защиты. Передавать контент на DLP, антивирусы и песочницы, а события — в SIEMSIEM (Security Information and Event Management) — система централизованного сбора и анализа событий информационной безопасности и установления корреляции между ними..
• Управлять распределенной инфраструктурой. Централизованно задавать политики для филиалов с возможностью локальной настройки.
• Повысить доказательность событий. Сохранять сведения о ресурсах, файлах и действиях, необходимые для мониторинга и расследований.

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

Как Solar webProxy решает задачи SWG

Детализация веб-политик. Solar webProxySolar webProxy — российское SWG-решение для управления интернет-доступом, защиты от веб-угроз и контроля действий пользователей в сети. позволяет учитывать параметры HTTP(S)-трафика: запросы и ответы, методы, типы контента, загрузки и выгрузки. За счет этого правила можно применять не только к ресурсу или его категории целиком, но и к отдельным действиям пользователя в веб-канале.

Контроль приложений и ресурсов. DPI уровня L7 помогает распознавать поддерживаемые протоколы и приложения, webCat — учитывать категории веб-ресурсов, а Solar TI Feeds — сведения об актуальных угрозах. Это дает возможность строить политики с учетом не только адреса ресурса, но и контекста его использования и потенциального риска.

Интеграции и расследования. По ICAPICAP (Internet Content Adaptation Protocol) — протокол интеграции прокси-систем с внешними средствами контентной проверки, например DLP, антивирусами и песочницами. контент можно передавать во внешние средства проверки, включая DLP-системы, антивирусы и песочницы. Есть интеграция с Solar Dozor, а события можно отправлять в SIEM по Syslog. Отчеты, журналы и «Досье» помогают связать веб-события с конкретным сотрудником и восстановить последовательность его действий — то есть использовать веб-контекст не только для блокировки, но и для последующего анализа инцидента.
Контроль современных веб-сценариев. При работе с ИИ-сервисами Solar webProxy позволяет применять политики к HTTP(S)-запросам и ответам и учитывать передаваемый контент и файлы в пределах поддерживаемых механизмов фильтрации. Дополнительно реализованы обработка запароленных архивов, история изменений политик, временные правила и расширенные возможности ICAP-проверок. Это помогает не просто закрывать доступ к нужным бизнесу сервисам, а точнее управлять допустимыми действиями в веб-канале.
Зрелость решения. Solar webProxy регулярно развивается, имеет сертификат ФСТЭК России и рассчитан на эксплуатацию в корпоративных, в том числе распределенных и высоконагруженных, инфраструктурах. Для компании это важно не меньше, чем отдельные функции: веб-шлюз становится критичным элементом доступа в интернет, поэтому при выборе SWG нужно оценивать не только глубину политик, но и зрелость продукта, масштабируемость и готовность к промышленной эксплуатации.

Совместное использование SWG и NGFW и выгоды для бизнеса

Совместная архитектура позволяет сохранить действующий сетевой периметр и добавить к нему специализированный слой веб-защиты. SWG и NGFW работают в одной схеме, но администрируются в соответствии со своими задачами: сетевые политики остаются на NGFW, а правила интернет-доступа и анализа веб-сессий — на SWG. За счет этого каждый компонент используется по своему основному назначению.

Solar webProxy можно подключить в явном или прозрачном режиме. В первом случае веб-трафик пользователей направляется непосредственно на прокси, во втором — перенаправляется на шлюз, как правило, без изменения прокси-настроек на рабочих станциях; при этом схема требует соответствующей настройки сетевой инфраструктуры и имеет ограничения для отдельных функций. Это дает возможность встроить решение в существующую инфраструктуру и выбрать схему с учетом ее топологии и требований к эксплуатации.

Практическая ценность такого разделения различается в зависимости от роли:

• Для администратора. Отдельный контур веб-политик, журналов и интеграций упрощает сопровождение пользовательского веб-доступа и позволяет развивать его без постоянной перестройки сетевого периметра.
• Для CISO. Более детальный контроль веб-канала помогает сохранять доступ к нужным SaaS, облачным и ИИ-сервисам, одновременно ограничивая рискованные действия и сохраняя контекст для расследований.
• Для CIO. Веб-слой можно развивать и масштабировать отдельно от NGFW, не усиливая всю периметровую платформу только из-за роста пользовательского интернет-трафика.
• Для закупок и финансов. Можно отдельно оценить стоимость развития веб-контроля и сопоставить ее с вариантом усиления всей периметровой платформы с учетом лицензирования, производительности и отказоустойчивости.

Вынесите веб-контроль в отдельный слой

Добавьте к существующему NGFW специализированный слой веб-контроля. Solar webProxy позволяет детальнее управлять интернет-доступом и действиями пользователей в веб-канале, подключать профильные средства защиты и независимо масштабировать обработку пользовательского веб-трафика — без замены действующего сетевого периметра.

Запросить консультацию

Как выбрать архитектуру без лишнего апгрейда

Выбор стоит начинать не с замены оборудования, а с оценки текущей нагрузки. В часы пик измерьте загрузку процессора, задержки, фактическую пропускную способность, количество зашифрованных сессий и влияние веб-проверок на IPS и VPN. Отдельно проверьте, достаточно ли журналов, чтобы восстановить действия пользователей в интернете.

Затем сравните два варианта: усилить NGFW или вынести глубокий анализ веб-трафика в отдельный SWG-слой. Если основной рост нагрузки связан с HTTPS, SaaS, облачными и ИИ-сервисами, второй подход позволяет развивать именно веб-защиту, не меняя периметровую платформу без необходимости. Такое сравнение помогает выбрать архитектуру исходя из реальной нагрузки и стоимости ее дальнейшего роста.

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

Часто задаваемые вопросы