СОИБ. Проектирование. Дизайн защищенных КСПД

Достаточно часто приходится проектировать защищенные КСПД или их сегменты. При этом стараюсь придерживаться лучших практик, таких как Cisco SAFE и т.п. (подборка у меня в блоге)

Как правило в них используются либо межсетевые экраны с функциями VPN либо маршрутизаторы с функциями VPN либо универсальные шлюзы безопасности с функциями VPN.  Но в российских реалиях эти практики приходится адаптировать. У нас два регулятора ФСТЭК и ФСБ со своими требованиями. Выполнить их в одном устройстве очень проблематично, о чем я уже писал в одной из предыдущих статей. Тем более что скоро завершаются продажи единственного сертифицированного ФСБ западного шлюза безопасности с функциями МЭ и VPN. Ещё одна российская реалия: из-за требований ФСБ приходится накладывать VPN поверх арендованных каналов.

Так что нам приходится использовать выделенные криптошлюзы, сертифицированные ФСБ. Куда лучше их приткнуть в общей схеме защищенной корпоративной сети? Такой вопрос часто задают Заказчики. У производителей нет ответа на этот вопрос. Если и приводятся схемы, то в них криптошлюзы, как сферические кони в вакууме - единственные сетевые устройства.

Давайте попробуем разобраться подробнее.

Рассмотрим ситуацию компании с двумя центральными офисами и множеством удаленных офисов. Для соответствия законодательству должны применяться сертифицированные средства защиты для всех каналов связи. Для высокой доступности используются арендованные корпоративные каналы связи (WAN) и подключения к сети Интернет. Для высокой доступности в центральных офисах должны использоваться кластеры сетевых устройств.  Локальные сегменты и сервисы рассматривать не будем, только Internet Edge (блок подключения к сети Интернет) и WAN Edge (блок подключения корпоративных каналов связи).

Посмотрим на схемы из лучших практик





Remote site




Где-то на этих схемах нужно разместить наши криптошлюзы.

Посмотрим на правильный порядок обработки WAN трафика из документа NG WAN. По хорошему сначала должен подключаться маршрутизатор (агрегация каналов, QoS), потом криптошлюз, потом маршрутизатор (mGRE, маршрутизация трафика). Хотя эти два маршрутизатора можно совместить в одном.


Получается такая схема WAN Edge с криптошлюзами



Internet Edge с криптошлюзами



Remote site с криптошлюзами




Если у нас много различных каналов связи и получается слишком много криптошлюзов на центральном узле, то можно совместить криптошлюзы WAN и  Inet. Такой дизайн также описан в лучших практиках







Комментарии

Unknown написал(а)…
В принципе все доступно и адекватно написано, что и следовало ожидать исходя из лучших практик, вот только применение решений на "ноге" через VLAN у многих представителей регулятора, да и проектировщиков, вызывает сомнения. Отчасти они оправданы. С формальной точки зрения в отечественных стандартах VLAN прослеживается косвенно, а как любят говорить компетентные органы - "покажите где это написано черным по белому". Хотя по факту вписать "в разрыв" просто невозможно.
Сергей Борисов написал(а)…
Когда у нас для межсетевого экранирования (в требуемых законом случаев) использовалась связка сертиф. МЭ и VLAN-ы на коммутаторах,
не встречал с этим особых проблем у представителей регулятора.

Криптошлюзы так вообще никаких проблем с VLAN не имеют. У нас есть требование - каналы выходящие за границы контролируемой территории должны шифроваться. Оно выполняется. То что происходит на контролируемой территории - уже не вопрос криптографии.

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

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

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

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