СЗПДн. Проектирование. Как централизованно управлять криптошлюзами С-терра?


Есть два замечательных производителя СЗИ: 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: Если не рассматривать вопросы интеграции, то тут у меня существенных проблем с приведенными выше производителями не возникало поэтому – никаких претензий.  Проблемы только с интеграцией.

Комментарии

Bonny написал(а)…
Этот комментарий был удален автором.
Bonny написал(а)…
Добрый день!
Недавно проводили внедрение 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).
Единая система для разворачивания, управления и мониторинга, конечно, классная штука. Но в условиях разношерстных сетей на разных вендорах, это вряд ли достижимо.
Сергей Борисов написал(а)…
Возможно так и надо - использовать С-терра КП + хорошую систему мониторинга.

Интересует ещё - насколько трудоемко будет вносить изменения в настройки всех шлюзов через С-терра КП.
Например поменяются адресации локальных сетей или поменяются адреса всех шлюзов.
Сергей Борисов написал(а)…
Этот комментарий был удален автором.

Популярные сообщения из этого блога

СКЗИ. НПА. Некоторые вопросы применения криптографии

Модель угроз безопасности клиента финансовой организации

КИИ. Категорирование объектов, часть 3