Миграция с зарубежного SWG на Solar webProxy: как перейти на российское решение без остановки веб-доступа

Замена зарубежного шлюза веб-безопасности затрагивает фильтрацию веб-трафика, аутентификацию пользователей, HTTPS-инспекцию, контроль файлов, логи и интеграции со смежными системами. Поэтому переход лучше строить как управляемый проект с пилотом и возможностью отката. Основной контур продолжает работать, пока новый проверяется на ограниченной группе пользователей. Это позволяет сохранить веб-доступ и выявить несовместимости до массового переключения.

Почему бизнес переходит с зарубежных SWG на российские решения

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

К технологическим причинам добавляется регуляторный и закупочный контекст. Он различается в зависимости от отрасли, типа информационной системы и применимых нормативных актов, поэтому говорить об обязательной замене зарубежных решений для всех организаций было бы некорректно. Однако в ряде регулируемых и закупочных сценариев значение имеют технологическая независимость, доступность российской поддержки, включение продукта в Реестр отечественного программного обеспечения и наличие сертификации ФСТЭК России.

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

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

Для информационных систем, подпадающих под приказ ФСТЭК России № 117, этот подход особенно актуален. Веб-доступ, использование внешних сервисов, удаленная работа и мониторинг входят в общий управляемый контур защиты, поэтому связанные с ними требования разумно учитывать еще при проектировании целевой архитектуры. Конкретный набор мер при этом зависит от характеристик самой системы и применимых к ней нормативных требований.

Оцените веб-контур с учетом требований ФСТЭК России № 117. Получите практический гайд о веб-доступе, удаленной работе и использовании сервисов искусственного интеллекта.

Скачать гайд

Основные риски при миграции SWG

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

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

Не менее важно проверить маршрутизацию и внешние интеграции. PAC определяет, какие запросы идут через прокси, а WPAD помогает клиенту найти PAC-файл, ICAPInternet Content Adaptation Protocol — протокол взаимодействия прокси с внешними средствами анализа и обработки контента. используется для взаимодействия со средствами анализа контента, а SIEMSecurity Information and Event Management — система централизованного сбора, корреляции и анализа событий информационной безопасности. получает события для мониторинга. До переключения также нужно определить сценарий отказа, проверить нагрузку на каналы и учесть филиальную архитектуру.

Критичные риски миграции:

• Потеря правил, исключений и пользовательских списков.
• Ошибки настройки TLS/SSL-инспекции и сертификатов.
• Нарушение работы интеграций с DLP, антивирусами, песочницами и SIEM.
• Некорректная работа PAC/WPADмеханизмы автоматического выбора и обнаружения прокси-сервера для клиентских устройств., прозрачного перенаправления трафика или клиентского агента.
• Отсутствие проверенного сценария возврата на старый контур.

Переключение должно быть обратимым

Безопасная миграция начинается не с отключения старого SWG, а с параллельной проверки нового контура. Пока политики, сертификаты, интеграции и журналы не подтверждены на реальном трафике, у команды должен оставаться понятный и протестированный путь возврата.

Эксперты Solar webProxy

Особенности зарубежных SWG, которые нужно учесть

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

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

При аудите действующего веб-контура стоит проверить:

• URL-категории, пользовательские списки и исключения из политик.
• Пользователей и группы из корпоративных каталогов, интеграцию с AD/LDAP, методы аутентификации и привязку политик.
• PAC/WPAD, настройки проксирования, использование клиентского агента и прозрачного перенаправления трафика.
• Исключения из TLS/SSL-инспекции, сертификаты и цепочки доверия.
• Форматы журналов и отчетов, передачу событий по Syslog и интеграции с DLP, антивирусами и песочницами по ICAP.
• Сценарии Reverse Proxy, схему работы филиалов и поведение системы при отказе отдельных узлов.

Переходите на новый SWG поэтапно

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

Запросить пилот

Что предлагает Solar webProxy как альтернатива

Solar webProxyроссийское SWG-решение для управления интернет-доступом, защиты от веб-угроз и контроля действий пользователей в сети. — российская система класса Secure Web Gateway для управления интернет-доступом и защиты веб-трафика. URL- и веб-фильтрация строятся на категоризации webCat, пользовательских списках и политиках для пользователей и групп. Система поддерживает HTTPS-инспекцию с исключениями, поэтому при миграции можно сохранить привычные сценарии контроля доступа и отдельно проверить их на пилотной группе.

Для защиты и контроля веб-трафика Solar webProxy использует несколько механизмов:

• TI-фиды Solar 4RAYS для выявления веб-угроз.
• Подключение антивирусов и песочниц по ICAP.
• Контроль передачи файлов и архивов, а также проверку по ключевым словам.
• Интеграцию с DLP для контроля передаваемых данных.
• Передачу событий в SIEM по Syslog.
• Журналы, Dashboard и «Досье пользователя» для анализа действий и сверки работы политик в новом контуре.

Core-модуль обрабатывает HTTP, HTTPS, FTP over HTTP и SOCKS5; фильтрация FTP через HTTP-прокси поддерживается в пассивном режиме на явном прокси. Для крупных и распределенных инфраструктур предусмотрены масштабирование, отказоустойчивость и MultiProxy, который позволяет централизованно управлять политиками в филиалах. Интеграция с AD/LDAP помогает сохранить привязку правил к пользователям и группам, а API — автоматизировать работу с политиками и объектами системы.

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

Пошаговый план миграции на Solar webProxy

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

Шаг 1. Аудит текущей инфраструктуры

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

Шаг 2. Развертывание Solar webProxy в тестовом режиме

На этом этапе зарубежный SWG продолжает обслуживать основной поток, а Solar webProxy подключается к пилотной группе. Продукт поддерживает явный и прозрачный режимы проксирования, WCCP и Endpoint Agent, который перенаправляет трафик конечной станции на прокси.

Шаг 3. Перенос политик фильтрации

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

Шаг 4. Настройка TLS/SSL-инспекции и исключений

Далее настраивают TLS/SSL-инспекцию, сертификаты и исключения. Solar webProxy поддерживает фильтрацию HTTPS с подменой и без подмены сертификата, а слой «Вскрытие HTTPS» позволяет задавать правила и исключения для расшифровки трафика.

Шаг 5. Интеграция с внешними системами

После базовых политик восстанавливают связи со смежными средствами защиты. Решение от Solar нативно интегрируется с Solar Dozor, передает трафик во внешние DLP, антивирусы и песочницы по ICAP, а события — в SIEM по Syslog.

Шаг 6. Пилотное внедрение

Пилот должен показывать не только то, открываются ли нужные сайты, но и то, насколько корректно работает весь новый веб-контур. В ходе проверки стоит оценить:

• Доступность необходимых сайтов, облачных платформ и ИИ-сервисов.
• Корректность применения политик и HTTPS-инспекции.
• Загрузку и выгрузку файлов, включая работу с архивами.
• Передачу событий в SIEM и интеграции с DLP, антивирусами и песочницами.
• Контроль исходящих запросов, файлов и входящих ответов при работе с ИИ-сервисами с учетом настроек HTTPS-инспекции и возможностей фильтрации конкретного сервиса.
• Полноту журналов и отчетов, корректность определения пользователей и данных в «Досье пользователя».
• Производительность системы под реальной нагрузкой.
• Соответствие событий и срабатываний политик в старом и новом контурах.
• Возможность вернуть пилотную группу на прежний маршрут при нештатной ситуации.

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

Шаг 7. Поэтапный перевод сотрудников

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

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

Шаг 8. Вывод зарубежного SWG после подтверждения стабильности

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

Убедитесь в стабильности нового веб-контура

Начните с пилотного сегмента, проверьте политики, SSL/TLS-инспекцию, интеграции и журналы, а затем расширяйте новый контур по мере подтверждения его стабильности.

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

Преимущества Solar webProxy при миграции

Для CISO ключевая задача — сохранить управляемость веб-безопасности во время и после перехода. Solar webProxy дает для этого инструменты централизованного контроля и анализа:

• Управление политиками веб-доступа.
• Мониторинг активности пользователей.
• Журналы и отчетность по событиям.
• Досье пользователя» для анализа действий и расследований.

Для CIO важна возможность встроить новый SWG в существующую ИТ/ИБ-инфраструктуру и масштабировать его по мере развития компании. В Solar webProxy для этого предусмотрены:

• Интеграции с корпоративными системами и средствами защиты.
• Горизонтальное масштабирование и балансировка нагрузки.
• Отказоустойчивая архитектура.
• MultiProxy для централизованного управления политиками в распределенной инфраструктуре.

Для администратора важны инструменты повседневной эксплуатации и интеграции с уже используемыми сервисами. Solar webProxy поддерживает:

• Интеграцию с AD/LDAP и различные методы аутентификации.
• ICAP для взаимодействия с внешними средствами анализа контента.
• Передачу событий в SIEM по Syslog.
• API, журналы и отчеты для настройки и контроля работы системы.

Для руководства и закупок значение имеет не только функциональность, но и соответствие продукта применимым требованиям к российскому ПО и средствам защиты. В этом отношении Solar webProxy предлагает:

• Включение в Единый реестр отечественного ПО.
• Техническую поддержку на русском языке от вендора.
• Сертифицированную версию с сертификатом ФСТЭК России № 4784 на межсетевой экран типа «Б» по четвертому уровню доверия. Применимость сертификата проверяют для выбранной версии и исполнения.
• Возможность учитывать продукт в проектах, где предъявляются соответствующие требования к применяемым средствам защиты.

Не откладывайте миграцию до последнего

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

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

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