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

Ключевые нововведения версии 4.5.3

Срок действия правил и исключений: без ручного отключения

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

В Solar webProxy 4.5.3 для правил и исключений можно задать дату и время начала и окончания действия. Параметр доступен в правилах доступа SOCKS5, контентной фильтрации и инспекции пакетов. В заданный момент правило начинает работать, а по окончании срока автоматически перестает применяться. В интерфейсе отображается текущий статус правила, а границы периода передаются в событиях CEF и SIEM.

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

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

Одновременная работа с политикой: защита от перезаписи изменений

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

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

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

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

ICAP-проверки: файлы неопределённого типа и управление ответом сервера

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

В версии 4.5.3 доработана логика отбора файлов для передачи на ICAP-сервер, в том числе файлов неопределенного типа. Кроме того, в правиле появился параметр «Обработка ответа»: администратор может продолжить текущую обработку, блокировать файл при модификации или передать пользователю ответ ICAP-сервера.

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

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

Basic-аутентификация: автоматическое переключение между серверами.

Если Solar webProxy использует несколько серверов AD, LDAP или LDAPS для Basic-аутентификации, недоступность выбранного сервера может увеличить время обработки запросов и затронуть доступ пользователей в интернет. Ручное переключение в такой ситуации увеличивает время восстановления.

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

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

• Аутентификация продолжает работать при недоступности одного из серверов-источников.
• Не требуется вручную менять активный сервер после сбоя.
• В кластерной инсталляции каждая нода выбирает доступный сервер независимо.
• События переключения можно отслеживать в журнале сервера аутентификации.

Solar MultiProxy: контроль распространения политики на узлы разных версий

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

В версии 4.5.3 Solar MultiProxy учитывает версии управляемых узлов при распространении групповой политики. Для поддерживаемых версий система формирует совместимую редакцию политики, предупреждает, какой функционал не будет передан на более старые узлы, и не распространяет политику на неподдерживаемые версии. Статусы версий и их количество отображаются в интерфейсе.

Важно: В рамках текущего релиза 4.5.3 поддерживается распространение политик для подключенных серверов управления на версиях 4.4.0 и 4.5.0

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

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

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

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