Solar webProxy для снижения рисков в крупных инфраструктурах
ГК «Солар» выпустила новую версию своей SWG-системы – Solar webProxy 4.5.3. Обновление помогает крупным компаниям снизить риски от ручного администрирования веб-доступа: временные правила завершаются автоматически, изменения защищены от перезаписи, а взаимодействие с песочницами становится более производительным и гибким. Администраторы также получают более прозрачное управление применением политик на разных узлах распределенной инфраструктуры.
Как поясняют в «Солар», в крупных компаниях веб-доступ становится отдельным операционным процессом. Подразделениям, подрядчикам, стажерам и временным исполнителям нужен доступ с разным уровнем прав и ограниченным сроком действия, а сами политики часто администрируются несколькими специалистами. Когда пользователей много, а механизмы проверки многослойные, возрастает риск рутинных ошибок: временное разрешение может остаться активным после завершения проекта, изменения – потеряться при параллельной правке, а избыточные привилегии – сохраниться дольше необходимого срока.
Дополнительная сложность возникает в территориально распределенных организациях, где веб-доступ управляется централизованно, а единые политики распространяются на несколько площадок. При поэтапном обновлении инфраструктуры администраторам важно понимать, какие настройки будут применены на узлах разных версий и где могут возникнуть ограничения. Раньше для этого требовалась более тщательная синхронизация версий узла централизованного управления и подключенных площадок. В Solar webProxy 4.5.3 эти риски снижены на уровне продукта: система помогает контролировать срок действия правил, защищает изменения от перезаписи и поддерживает работу централизованного управления с площадками более ранних версий в рамках совместимости.
Один из частых операционных рисков – временные разрешения, которые продолжают действовать после завершения проекта, аудита, пилота или работ с подрядчиком, такие правила требуют дополнительного контроля. В Solar webProxy 4.5.3 для правил доступа можно задать дату и время начала и окончания действия. Возможность доступна для правил SOCKS5, контентной фильтрации и инспекции пакетов. Фиксированные даты можно сочетать с циклическим расписанием – например, разрешить доступ только в рабочие часы на время проекта. Текущий статус правила отображается в интерфейсе, а параметры действия правила передаются в событиях CEF и SIEM. Администратор видит, какие правила еще действуют, а какие уже завершены.
Еще один риск связан с командным администрированием. В крупных компаниях правилами политик могут управлять несколько администраторов, поэтому сложнее вручную контролировать параллельные изменения. Когда несколько администраторов одновременно меняют одну политику или связанные с ней элементы, часть изменений может быть потеряна или применена некорректно. В версии 4.5.3 Solar webProxy берет этот контроль на себя: система определяет, что объект уже редактируется другим специалистом. На время конфликта операции, которые могут привести к перезаписи, блокируются, а интерфейс показывает предупреждение и имя пользователя, который вносит изменения. Это помогает применять настройки последовательно.
При внешней проверке файлов через песочницы и другие системы анализа администраторы раньше не могли точно исключать из проверки служебные файлы, которые не требуют анализа в песочнице, например элементы дизайна страниц. Такой поток создавал дополнительную нагрузку на внешние системы проверки. В Solar webProxy 4.5.3 настройки определения файлов, передаваемых на ICAP-проверку, стали гибче. Администраторы могут точнее выбирать, какие объекты направлять во внешние системы анализа, в том числе для файлов неопределенного типа. Это помогает снизить лишнюю нагрузку на песочницы.
Кроме того, в новой версии расширены настройки обработки ответа ICAP-сервера. Администратор может продолжить работу с файлом как обычно, заблокировать его при модификации или показать пользователю ответ ICAP-сервера, включая страницу блокировки и дополнительные сведения.
При аутентификации раньше для пользователя или сервиса можно было указать только один сервер Basic-аутентификации. Если такой сервер становился недоступным, у пользователей могли возникнуть проблемы с выходом в интернет: доступ блокировался, а нагрузка на администраторов и ИТ-службу возрастала. В Solar webProxy 4.5.3 для таких сценариев добавлена возможность указать параметры резервного сервера. Если основной сервер не отвечает или возвращает техническую ошибку, система автоматически обращается к резервному источнику.
Ошибки самой учетной записи, например, неверный пароль или блокировка пользователя, переключения не вызывают. В кластерной инсталляции каждый узел выбирает рабочий источник независимо, а события переключения фиксируются в журнале аутентификации.
Обновление продукта в распределенной инфраструктуре часто проходит поэтапно: часть узлов уже работает на новой версии, часть остается на предыдущей. В такой ситуации важно заранее понимать, какие настройки будут применены на разных площадках, а какие потребуют обновления версии. Solar MultiProxy теперь учитывает версию каждого узла при применении групповой политики. Система передает только совместимые настройки, предупреждает, какие возможности будут недоступны на более старых версиях, и не распространяет политику на неподдерживаемые версии. Статусы версий и количество узлов отображаются в интерфейсе. В рамках релиза 4.5.3 применение централизованных политик поддерживается для подключенных серверов управления на версиях 4.4.0 и 4.5.0. Это позволяет вести обновление поэтапно и сохранять контроль над статусом применения политик на разных узлах.
Вместе эти изменения снижают объем ручного контроля в процессах, которые раньше требовали постоянного внимания администратора. Это касается управления временными доступами, командной работы с политиками, передачи файлов во внешние системы анализа, резервной аутентификации и поэтапного обновления распределенной инфраструктуры.