Какие три функции шлюзов информационной безопасности (SWG) были в фокусе наиболее часто в рамках пилотных проектов этого года? Как проводится демонстрация функциональности и с какими проблемами можно столкнуться? Какие дополнительные возможности обеспечат явное преимущество Secure Web Gateway? О чём следует позаботиться до старта пилотного проекта? Отвечаем на эти вопросы на примере Solar webProxy.
Введение
После ухода зарубежных вендоров из России у многих заказчиков, которые использовали их решения, появился ряд проблем. Так, заказчики систем класса SWG столкнулись с невозможностью получить обновления для категоризатора из облака. Это связано с тем, что у многих западных решений базы категоризатора не хранятся локально, а доступны только через обращение в облако. Таким образом, пропала возможность настраивать правила политики информационной безопасности, разграничивающие доступ пользователей к ресурсам: правила политик фильтрации работают только при доступности облачного категоризатора.
Рынок охватили опасения, что оставшиеся работоспособными функции решений западных вендоров могут быть так же заблокированы в любой момент. Всё это заставило заказчиков задуматься о переходе на отечественные SWG-решения. Опираясь на опыт «пилотов» в крупных банках, торговых сетях электроники и других крупных компаниях, расскажем, что наиболее важно для заказчиков в рамках пилотного проекта SWG.
Требования заказчиков к «пилоту» Secure Web Gateway
Выбирая отечественное SWG-решение, заказчикам крайне важно на практике убедиться, что по функциональности оно будет практически идентичным решению западного вендора, которым они привыкли пользоваться. Пилотные проекты этого года показали, что наибольшее внимание компании уделяют тестированию:
- переноса политик фильтрации;
- реализации отказоустойчивой конфигурации (характерно для заказчиков, у которых более 2 тысяч пользователей);
- интеграции с другими средствами защиты информации, а именно — с системами предотвращения утечек (DLP) и управления сведениями и событиями по безопасности (SIEM).
Перенос политик фильтрации
Заказчики хотят убедиться на практике, что с новым продуктом у них будет возможность сохранить все политики фильтрации, накопленные за годы использования решения зарубежного вендора. Автоматизация этого процесса осложнена отсутствием отраслевого стандарта, в результате чего каждое решение имеет свой формат хранения и выгрузки данных. Кроме того, за годы эксплуатации решения зарубежного вендора заказчики создают множество правил, которые на момент проведения пилотного проекта теряют актуальность или дублируются.
Инженеры Solar webProxy, которые ведут техническое сопровождение заказчика, анализируют весь перечень политик фильтрации и предоставляют рекомендации по их актуализации и оптимизации. Отдельно формируется перечень типовых правил, который инженер переносит в Solar webProxy совместно со специалистами заказчика, попутно консультируя их. Попутно зачастую переносится и сформировавшийся у заказчика список ресурсов, на который эти правила распространяются. На основе всех перенесённых правил заказчик может настраивать доступ пользователей к ресурсам, используя группы из Active Directory.
Рисунок 1. Настройка правил в интерфейсе Solar webProxy
Отказоустойчивость и балансировка трафика
Главная цель демонстрации продукта в отказоустойчивой конфигурации — подтвердить, что у пользователей не возникнет проблем с доступом к интернету при отключении одного из узлов кластера.
Отказоустойчивая конфигурация в Solar webProxy реализуется за счёт технологии виртуальной маршрутизации (Virtual Router Redundancy Protocol, VRRP) или присвоения виртуального IP-адреса (Virtual IP, VIP), что позволяет объединить несколько маршрутизаторов в один виртуальный с общим IP-адресом. Для реализации отказоустойчивого кластера Solar webProxy наши инженеры совместно с специалистами заказчика разворачивают его в двух центрах обработки данных. Мастер-узел и два фильтрующих узла располагаются в одном ЦОДе, а ещё два фильтрующих узла — в другом. Далее настраиваются виртуальные IP-адреса, а узлы объединяются в кластер.
В момент работоспособности всех узлов заказчик видит, что виртуальный IP-адрес присвоен мастер-узлу. Затем узлы в одном ЦОДе отключаются. В этот момент заказчик видит, что виртуальный IP-адрес присвоен узлам в другом ЦОДе. Далее работоспособность всех узлов восстанавливается, и заказчик видит, что виртуальный IP-адрес вновь присвоен мастер-узлу.
Часто нас спрашивают, каким образом можно реализовать отказоустойчивость мастер-узла, который отвечает за доступность веб-интерфейса Solar webProxy. Мы предлагаем резервирование средствами виртуализации (например, создание образа) или выгрузку и сохранение изменённых конфигурационных файлов с помощью скриптов. В случае невосстанавливаемой потери мастер-узла это позволит развернуть его и загрузить всю необходимую конфигурацию. Весь процесс в таком случае занимает максимум 30 минут. Если мастер-узел упадёт, это никак не повлияет на доступность интернета у пользователей. В такой ситуации потеряется только доступ к веб-интерфейсу продукта.
Совместно с демонстрацией отказоустойчивой конфигурации наши инженеры настраивают балансировку трафика. Она реализуется при помощи встроенного в продукт балансировщика HAProxy, который управляет потоками данных в прозрачном режиме и позволяет увеличить производительность Solar webProxy за счёт параллельной обработки запросов на нескольких узлах кластера. Также балансировщик контролирует работоспособность серверов фильтрации и автоматически отключает узлы от процесса обработки запросов в случае их недоступности. Настройки HAProxy доступны из интерфейса.
Рисунок 2. Схема работы Solar webProxy при использовании VRRP
Интеграция с DLP и SIEM
Наличие интеграционных возможностей важно, так как чаще всего заказчики используют комплекс решений, обеспечивающих информационную безопасность, а именно — DLP-системы, SIEM-системы, антивирусы и песочницы. В Solar webProxy реализованы возможности интеграции со всеми вышеперечисленными классами решений. Однако именно в рамках пилотных проектов наиболее часто компании просят продемонстрировать интеграцию с DLP- и SIEM-системами.
В Solar webProxy для интеграции с DLP-системами реализована возможность передавать трафик по протоколу ICAP, для интеграции с SIEM-системами — по протоколу Syslog. Таким образом, для демонстрации интеграционных возможностей наши инженеры настраивают передачу трафика из Solar webProxy в используемое заказчиком решение по этим протоколам.
Интеграция с SIEM-системами зачастую проходит гладко — в первую очередь из-за простоты настройки взаимодействия. Когда речь заходит о DLP, наши инженеры сталкиваются с различными проблемами, обусловленными недостаточной подготовленностью на стороне заказчика. Этот вид интеграции не так прост с точки зрения настройки и требует отладки интеграционного взаимодействия, в том числе на стороне DLP-системы заказчика.
Поэтому для тестирования интеграции с DLP-системой заказчику нужно заранее подготовить интеграционные вводные, определить необходимые данные для настройки передачи ICAP-трафика, учитывая инфраструктурные особенности, согласовать доступы, уведомить всех отвечающих за интегрируемые системы специалистов и т. п.
Дополнительные функциональные возможности, которые отмечают заказчики
Кроме уже описанных в статье функциональных возможностей, во время пилотных тестирований заказчики отмечают в продукте ряд преимуществ:
- Интеграция со сторонним прокси-сервером по протоколу ICAP
Наличие такой интеграционной возможности обеспечивает более плавную миграцию с одного решения на другое, позволяет минимизировать изменения в структуре и логике сети, требующиеся даже при изучении решения, а также сокращает спектр работ, которые напрямую не связаны с настройкой самого SWG-решения.
- Лицензионная политика
Лицензионная политика Solar webProxy не накладывает ограничений на используемое количество узлов системы. Продукт можно развернуть на бесконечном количестве виртуальных машин, серверов. Такой подход позволяет заказчику организовать необходимое ему количество узлов системы без дополнительных затрат.
- Понятный интерфейс и удобное управление
Все отчёты формируются в виде графиков. Стандартное представление — это таймлайн с распределением запросов по времени. Помимо этого, можно настроить статистику по нагрузке, по самым популярным источникам или категориям ресурсов. Система позволяет строить подробные отчёты с широким набором параметров. Отчёты интерактивны: можно динамически перестраивать их, изменяя диапазон времени прямо на графиках, а также оперативно переходить к просмотру детальной информации.
Выводы
Мы рекомендуем выделить наиболее важные для вас функции SWG-решений, чтобы выбрать то, которое наилучшим образом будет отвечать вашим требованиям. Опираясь на конкретные потребности, можно провести ранжирование функциональных и нефункциональных возможностей. По этому перечню будет легче оценить рассматриваемые продукты, понять, отвечают ли они важным для вас требованиям. И, конечно, лучше всего определить перечень требований до старта пилотных проектов, а не в процессе их проведения. Такой подход сразу даст чёткую картину достаточности возможностей продукта, а команде вендора позволит понимать, что для вас приоритетно.
Вместе с тем следует внимательно относиться к изучению руководства для пользователя. Зачастую ошибки, с которыми заказчики сталкиваются в рамках пилотных проектов, обусловлены невнимательностью. Это может быть разметка дискового пространства, не соответствующая требуемой в документации, использование нерекомендуемой в документации версии операционной системы, неправильно выписанный файл таблицы ключей (keytab).
Наконец, важно отметить, что проведение пилотного проекта помогает определиться с выбором SWG-решения, но не позволяет провести его полноценное внедрение.
