СЗПДн. Проектирование. Как централизованно управлять криптошлюзами С-терра?
Есть два замечательных производителя
СЗИ: Cisco Systems предлагает комплекс решений для создания защищенной
сети без границ, но не имеет Российской криптографии; С-терра СиЭсПи –
предлагает широкую линейки средств построения VPN включающих Российскую криптографию, но не производит других
средств защиты. В маркетинговых материалах этих двух производителей говорится о
тесной интеграции друг с другом.
Так получилось, что в одном проекте по
защите ПДе планировалось использование и интеграция решений этих двух производителей.
Один из вопросов, который необходимо было решить при проектировании
– определить, как будут управляться сетевые средства защиты информации.
Приоритетным вариантом являлось использование
централизованной системы управления. Причин использовать именно его несколько:
·
Визуализации всех сетевых средств защиты на графической
консоли
·
Гибкая ролевая модель управления
·
Иерархия и наследование политик (глобальные, общие
и локальные политики/объекты)
·
Централизованное управление событиями сетевой
безопасности (сбор, просмотр и более быстрое реагирование)
·
Централизованное управление состоянием сетевых
средства защиты (общее состояние, загрузка процессора, памяти, интерфейсов и т.п.)
·
Централизованное управление версиями сетевых
средств защиты (резервное копирование, обновление)
·
Централизованная отчетность о работе сетевых
средств защиты
Для комплекса решений Cisco Systems предлагается система управления Cisco Security Manager. Для управления решений С-терра СиЭсПи одним из основных вариантов предлагается так-же использоваться Cisco Security Manager. Это подтверждается в маркетинговой информации двух производителей:
·
С-Терра СиЭсПи. Обзор продуктовой линейки 2012
Отлично. Начинаем проектировать и
интегрировать криптошлюзы С-терра СиЭсПи с Cisco Security Manager (CSM). При детальном изучении документации
и тестировании получаем следующее:
1) Базовые настройки (IP-адресация, импортирование сертификата, настройка NTP) обязательно выполняются
вручную, через SSH.
Применение на данном этапе CSM невозможно.
2) Построение Site-to-site IPSec VPN в конфигурации
Hub-and-Spoke с резервированием шлюза как в нашей ситуации, официально не
поддерживается:
“В
топологии Hub and Spoke VPN не поддерживается вариант конфигурации с
резервированием шлюза”
3) Построение Remote Access VPN, не предоставляется возможным,
поскольку:
“Рекомендуется
не использовать сценарии, в которых настройка CSP VPN Gate выполняется как
через CSM, так и вручную. Если потребность в таком сценарии существует, то надо
стараться задавать вручную только те команды, которые CSM не использует в
процессе настраивания CSP VPN Gate.
Следует
учитывать, что при отгрузке конфигурации, CSM может изменить или удалить
некоторые из команд, которые существовали в изначально импортированной
конфигурации, например ip local pool или crypto isakmp policy. Для примера,
рассмотрим, почему создание политики безопасности шлюза через CSM для работы с
мобильными клиентами невозможно. Порядок действий, который приводит к данному
ограничению, следующий:
шлюз
добавлен в CSM для работы по одной из топологий при помощи CSM проведена
централизованная настройка шлюзов по одной из топологий – FullMesh, Hub and
Spoke, Point to Point затем, например, по SSH отредактировать конфигурацию
одного из шлюзов для работы с мобильными клиентами – создать пул адресов,
привязать к криптокарте, создать identity и др. после загрузки на шлюз
созданной конфигурации через CSM, работа с мобильными клиентами будет
невозможна в созданной топологии.
Причина
состоит в том, что все пулы адресов, не привязанные к команде crypto isakmp
client configuration address-pool local, CSM удаляет”.
4) Поскольку CSM имеет ряд ограничений по работе с конфигурацией С-терра
(затирание части конфига после загрузки), что может поставить под угрозу работу
криптошлюзов из-за затирания команд:
“3.
Возможны некоторые проблемы с восстановлением конфигурации. В некоторых случаях
изменение или удаление существующих команд может быть безвозвратным: даже если
в CSM удалить изменения, внесенные в конфигурацию, например, удалить VPN
Topology, первоначальная конфигурация (которая была до Deploy) может не
восстановиться в полном объеме. Более того, возможны ситуации, когда какие-то
элементы конфигурации могут быть испорчены именно при отмене изменений,
сделанных в CSM. Например:
в
первоначальной конфигурации была настройка crypto isakmp identity dn
в CSM, в
VPN Global Setings выставлена настройка Identity – Distinguished Name
в
прогружаемой из CSM конфигурации команда crypto isakmp identity отсутствует
если потом
удалить VPN Topology и снова прогрузить конфигурацию, то будет прописана
команда crypto isakmp identity address (значение по умолчанию), что отличается
от того, что было в первоначальной конфигурации.
CSP VPN
Gate не поддерживает функциональность Rollback, позволяющую вернуться к
конфигурациям, которые были загружены в устройство ранее”
5) Нет возможности копировать и
обновлять образы средств защиты
6) Нет возможности детального мониторинга состояния средств защиты
От производителя получен комментарий,
что CSM может
использоваться для создания простых политик site-to-site, hub-and-spoke
и быстрого разворачивания однотипных конфигураций. То есть делается базовая
преднастройка, далее одна политика распространяется на все устройства с помощью
CSM, далее идет только
конфигурация устройств через SSH а CSM больше не используется.
Данный вариант использования Cisco Security Manager
с
моей точки зрения не соответствует приведенным в начале статьи целям (для
которых он будет использоваться при управлении решениями Cisco Systems) и для управления устройствами С-терра её использовать не стоит.
В определенной степени исправить
ситуацию может недавно вышедшая система централизованного управления С-Терра КП.
Посмотрим какие функции в сравнении с CSM выполняются:
·
Визуализация - нет
·
Гибкая ролевая модель управления - нет
·
Иерархия и наследование политик - частично, есть визарды для настройки политик и шаблоны политик
·
Централизованное управление событиями сетевой
безопасности (сбор, просмотр и более быстрое реагирование) - да
·
Централизованное управление состоянием сетевых
средства защиты (общее состояние, загрузка процессора, памяти, интерфейсов и т.п.)
– частично, только общее состояние
·
Централизованное управление версиями сетевых
средств защиты (резервное копирование, обновление) – частично, обновление сертификатов,
ключей
·
Централизованная отчетность о работе сетевых
средств защиты - нет
Как видим что и тут поставленных целей мы не достигнем.
Коллеги, буду признателен если вы
поделитесь, как управляете большим количеством С-терра и удалось ли подружить с
CSM?
PS: Если не рассматривать вопросы интеграции, то тут у меня существенных
проблем с приведенными выше производителями не возникало поэтому – никаких претензий.
Проблемы только с интеграцией.
Комментарии
Недавно проводили внедрение S-terra в количестве порядка 200 устройств (шлюзы, модули и клиенты). Во время разворачивания использовали S-terra KP, для мониторинга по SNMP - систему HP OpenView, имеющуюся у заказчика.
CSM, безусловно, удобен, когда сеть развернута на Cisco, однако, это не дешевая управлялка, а КП стоит 150 т. за безлимитную версию. Так же, CSM не учитывает некоторую специфику российского VPN (например, отсутствие функции autoenroll, которая явно противоречит стандартной процедуре выпуска сертификатов в коммерческих компаниях).
В процессе внедрения пользовались техподдержкой S-terra. Производитель заявил о поддержке 10 тысяч устройств. Так же был дан комментарий, что S-terra KP в первую очередь позиционируется как система централизованного управления, а для мониторинга статистики предлагается использовать готовые решения на рынке (те же HP Open View, Arcsight, ну или, на худой конец, бесплатные SNMP-менеджеры, вроде Nagios).
Единая система для разворачивания, управления и мониторинга, конечно, классная штука. Но в условиях разношерстных сетей на разных вендорах, это вряд ли достижимо.
Интересует ещё - насколько трудоемко будет вносить изменения в настройки всех шлюзов через С-терра КП.
Например поменяются адресации локальных сетей или поменяются адреса всех шлюзов.