Solar webProxy 4.5

Блокировка запароленных архивов и анализ содержимого

Архив остается одним из самых простых способов скрыть вредоносный файл или передать данные за пределы компании. В 2025 году до 45% вредоносов доставлялись через архивы, а часть цепочек определялась как обычные веб-загрузки в браузере. Поэтому контроля только почтовых вложений уже недостаточно: нужен анализ архивов прямо в веб- и FTP-канале.

В Solar webProxy 4.5 появились две ключевые возможности:

1. блокировка запароленных архивов,
2. распаковка архивов для проверки вложенных объектов по правилам политики в HTTP(S) и FTP.

Поддерживаются семейства архивов ZIP, 7Z, GZIP, TAR, RAR, ARJ, ISO, DEB, RPM, APK, JAR и SFX.

Что меняется на практике

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

История политик: стало проще менять правила и откатывать их назад

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

В Solar webProxy 4.5 появилась история сохраненных версий политики. В ней видно дату изменения, пользователя и комментарий. Нужную версию можно найти, скачать или восстановить. Глубина хранения истории настраивается.

Что меняется на практике

• Изменения в политике становятся прозрачными.
• Снижается риск долгого простоя из‑за неудачной правки.
• Проще и быстрее расследовать сбои после изменений.
• Можно безопасно вносить новые настройки, потому что всегда доступен возврат к рабочей версии.
• Команде легче сопровождать крупные и многослойные политики.

Категоризация ресурсов: пользовательские категории в филиалах и поддомены

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

А) Управление пользовательскими категориями из Solar MultiProxy

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

В версии 4.5 у модуля Solar MultiProxy в разделе «База категоризации» появились новые блоки:

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

Что меняется на практике

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

Б) Изменение логики косвенной категоризации

В Solar webProxy 4.5 доработали логику категоризации части публичных доменов. Теперь дочерние поддомены могут автоматически получать категорию родительского домена. Например, если gov.ru относится к категории «Государство и закон», то ved.gov.ru тоже будет определяться в этой категории. Раньше в таких случаях ее часто приходилось задавать вручную.

Что меняется на практике

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

Две учетные записи для безопасной эксплуатации системы

Раньше одна учетная запись с максимальными привилегиями использовалась и для управления операционной системой, и для работы компонентов Solar webProxy. Это создавало дополнительный риск: при ошибке потенциальное влияние на работу системы было выше.

В Solar webProxy 4.5 разделили роли и сократили число процессов, которым для работы нужны максимальные привилегии. Теперь используются две учетные записи: root — для установки, настройки и управления операционной системой; dozor — для работы и настройки Solar webProxy.

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

Что меняется на практике

• Ниже риск влияния лишних привилегий на устойчивость системы.
• Проще проходить внутренние проверки и согласования по эксплуатации системы.
• Выше соответствие требованиям ИБ к безопасной эксплуатации самого ПО.

Гибридная аутентификация: несколько способов на одном узле

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

В Solar webProxy 4.5 на одном узле можно одновременно использовать сразу несколько методов аутентификации по приоритету: Negotiate 🡪 Basic или Negotiate 🡪 NTLM 🡪 Basic. Это позволяет более гибко встраивать систему в существующую инфраструктуру и использовать тот вариант аутентификации, который поддерживает конкретное устройство, сервер или приложение.

Для компании это означает:

• более удобное внедрение Solar webProxy в смешанную среду;
• меньшее количество ручных настроек;
• более простое сопровождение доступа в крупных распределенных инфраструктурах.

Что меняется на практике

• Проще встраивать Solar webProxy в гибридную инфраструктуру.
• Не нужно дробить пользователей и системы на отдельные группы только из‑за разных способов аутентификации.
• Становится меньше списков исключений и ручных обходных настроек.
• Ниже риск ошибок при сопровождении сложной среды.
• Удобнее централизованно управлять политикой аутентификации.

Что еще улучшили в Solar webProxy 4.5