Иногда на стадии пилотного внедрения заказчик хочет убедиться не только в функциональности, но и в надёжности продукта. Когда речь идёт о решении для контроля веб-трафика в крупной организации, подтвердить второе на практике можно только работой в «боевых» условиях. Однажды «пилот» Solar webProxy стал полноценным внедрением — так мы доказали его надёжность.
- Введение
- Какие требования были у заказчика
- Как решали задачу с параллельной работой двух систем
- Как мы добивались отказоустойчивости
- Итоги «пилота» и несколько слов о полноценном внедрении
- Выводы
Введение
Solar webProxy — шлюз веб-безопасности (Secure Web Gateway, SWG), предназначенный для работы на прикладном уровне (L7). Он контролирует доступ к веб-ресурсам и защищает от веб-угроз эффективнее, чем традиционные межсетевые экраны. Отсутствие привязки к аппаратным платформам и встроенный балансировщик нагрузки позволяют легко масштабировать Solar webProxy без снижения отказоустойчивости системы. На одном из пилотных проектов внедрения решения команде пришлось демонстрировать бесперебойную работу продукта на более чем 3000 рабочих станций, по сути, масштабировав его на всю компанию. Ниже делимся опытом, как нам это удалось и что в итоге получил заказчик.
Какие требования были у заказчика
Условия задачи, которая перед нами стояла, были следующими. Потенциальный заказчик, работающий в сфере жизнеобеспечения населения, до этого использовал решение зарубежного вендора для контроля доступа к веб-ресурсам и с учётом курса на импортозамещение хотел перейти на отечественное ПО. Учитывая критическую значимость большинства процессов, заказчику было важно получить систему, которая не уступает предыдущей и по функциональности, и по отказоустойчивости. Если первое можно показать на стандартной пилотной инсталляции, к которой мы подключаем несколько десятков пользователей, то для демонстрации надёжности пришлось идти на нестандартный шаг — распространить «пилот» на всю организацию, а это более трёх тысяч рабочих станций, одновременно выходящих в интернет. При этом из-за критической значимости процессов заказчику было нужно, чтобы обе системы — прежняя и наша — работали параллельно, чтобы в случае каких-то проблем можно было быстро переключить всех пользователей обратно.
Как решали задачу с параллельной работой двух систем
Мы подключили всех сотрудников к пилотной инсталляции Solar webProxy, и весь веб-трафик организации пошёл через нашу систему. SWG-решение, которое было у заказчика изначально, работало в режиме подстраховки. Нам было нужно обеспечить маршрутизацию пользователей так, чтобы быстро переключать их между системами, если это понадобится.
Изначально была идея использовать для маршрутизации пользователей балансировщик HAProxy. Он интегрирован в Solar webProxy с поддержкой всех протоколов. По умолчанию балансировщик скрывает пользователя, то есть подменяет IP-адрес рабочей станции своим IP-адресом. Но если использовать протокол send-proxy, источник запроса остаётся известным и тогда SWG-система может авторизовать пользователя. Проблема была в том, что шлюз веб-безопасности, который был у заказчика до нас, этот протокол не поддерживал.
Пришлось искать другое решение. Мы не стали, например, делать балансировку через DNS-сервер, потому что нас не устроила скорость переключения между инсталляциями. К тому же перед нами стояла задача продемонстрировать надёжность нашего решения и обеспечить быстрый откат, если что-то пойдёт не так. Поэтому мы решили распределять пользователей между системами с помощью стандартного средства определения параметров прокси-сервера, которое есть в Windows. С помощью групповых политик включаем в настройках прокси на рабочей станции «Определять параметры автоматически» и «Использовать сценарий настройки». Поднимаем сервер с файлом сценария и указываем его адрес в соответствующем поле.
Рисунок 1. Используем стандартные средства определения параметров прокси-сервера
В соответствии с этим сценарием пользователь направлялся в нашу систему. Если бы возникли проблемы, администратору было бы достаточно внести изменения в сценарий, и веб-трафик пользователей пошёл бы через старую систему.
Как мы добивались отказоустойчивости
Мы не смогли использовать балансировщик HAProxy для изначальной маршрутизации пользователей, но он помогает решить задачу связанную с отказоустойчивостью нашего решения. Пользователи сначала попадают на встроенный в нашу систему HAProxy, а балансировщик распределяет нагрузку между узлами нашей системы. При этом, благодаря тому что Solar webProxy поддерживает протокол send-proxy, система знает, от кого именно идёт запрос, и может применять механизмы безопасности, которые обеспечивают контроль доступа сотрудников к веб-ресурсам, — аутентификацию и авторизацию.
При выходе из строя любого фильтрующего узла балансировщик это понимает и не отправит туда пользователей, то есть перерыва в доступе к интернету для них не будет. Кроме того, удобно проводить регламентные работы, попеременно отключая узлы, то есть не прерывая доступ в Сеть и контроль трафика.
HAProxy — сам по себе весьма мощный инструмент с точки зрения повышения отказоустойчивости системы. Он используется в таких крупных сервисах, как Dropbox, Instagram и др., для которых надёжность — крайне принципиальный момент. HAProxy позволяет организовывать кластеры, в том числе горячего резервирования, что повышает уровень его собственной отказоустойчивости. В отличие от балансировки с помощью DNS-сервера HAProxy действительно распределяет нагрузку равномерно либо именно так, как пропишешь в настройках.
Чтобы использовать возможности балансировщика и при этом сохранить простоту настройки Solar webProxy, HAProxy интегрирован в нашу систему. Благодаря этому администратору не нужно забираться в конфигурационные файлы балансировщика. Вся настройка осуществляется через наш веб-интерфейс. Достаточно просто выбрать для одного из серверов роль «Балансировщик» и направить на него трафик. Дальше он всё сделает сам.
Рисунок 2. Настройка балансировки в интерфейсе Solar webProxy
При этом можно отслеживать балансировку, видеть на графиках нагрузку каждого узла. Благодаря тому что мы интегрируем сторонние решения в наши продукты и обеспечиваем настройку всей функциональности из единого веб-интерфейса, снижаются требования к компетенциям администраторов. Для изменения тех или иных настроек офицерам безопасности не приходится привлекать высококвалифицированных ИТ-специалистов, которые умеют работать с конфигурационными файлами.
Итоги «пилота» и несколько слов о полноценном внедрении
Заказчик остался доволен как функциональностью нашей системы, так и уровнем отказоустойчивости, который мы продемонстрировали. Пилотная инсталляция проработала дольше, чем это бывает обычно, и всё это время выполняла роль основного SWG-решения в компании.
В течение небольшого времени приходилось, по сути, выступать в качестве второй линии техподдержки. Сотрудники заказчика обращались к собственным ИТ-специалистам с теми или иными проблемами, связанными с доступом к интернету. Последние собирали эти заявки и пересылали нам. Мы разбирались с каждым конкретным случаем и сообщали, что нужно сделать, чтобы решить проблему. Такая ситуация возникла из-за того, что когда переводишь на новую систему всю организацию, сразу обнаруживается много разных нюансов. Кто-то использует специфическое оборудование, для которого нужно настроить исключения, кто-то — специфический софт. С одной стороны, одномоментно разбираться со множеством кейсов трудозатратно. Зато это позволило решить большинство таких мелких проблем ещё до полноценного внедрения.
В распоряжении команды внедрения оказалась готовая политика. То есть не пришлось тратить время на её создание или перенос из прежней системы и адаптацию под наше решение. Кроме того, благодаря такому «пилоту» заказчик один раз уже прошёл шаги по заведению всех пользователей в системе, по созданию сертификата для вскрытия трафика и т. д. Соответственно, все эти этапы при внедрении заняли меньше времени. У нас уже было понимание объёмов трафика и нагрузки. Это позволило нам заранее проработать архитектуру и выдвинуть технические требования к серверам, на которых разворачивалась наша система.
Полноценная инсталляция отличается от пилотной в первую очередь масштабами — теперь серверы развёрнуты в двух ЦОДах заказчика. Чтобы балансировать трафик между ними, мы сделали систему из двух HAProxy, которые балансируются между собой с помощью виртуального IP. Уровень отказоустойчивости нашей системы благодаря этому стал ещё выше. Даже если у заказчика «отвалится» канал с основным ЦОДом и всё пойдёт через резервный, мы продолжим обрабатывать трафик без перерыва. Благодаря тому что HAProxy интегрирован в наш продукт, мы можем предложить заказчику готовое решение для такой ситуации без дополнительных затрат с его стороны.
Рисунок 3. Балансировка трафика в двух ЦОДах
Выводы
Если подытожить, то «пилот», который распространяется сразу на всю организацию, — история, конечно, весьма трудозатратная. Однако если всё сделать правильно, то можно не только убедить заказчика в том, что «надо брать», но и облегчить жизнь команде внедрения. Мы получили большой опыт и теперь знаем, как действовать в подобных ситуациях.
