Сеть для выделенного устройства HSM Azure
Для выделенного устройства HSM Azure требуется высокий уровень безопасности сетевой инфраструктуры. Он требуется как в случае перехода из облака Azure в локальную ИТ-среду клиента, так и при использовании распределенных приложений или сценариев высокого уровня доступности. Сеть Azure предоставляет это, и есть четыре различные области, которые нужно рассмотреть.
- Создание устройств HSM внутри виртуальной сети (VNet) в Azure
- Подключение локальных ресурсов к облачным для настройки устройств HSM и управления ими
- Создание и подключение виртуальных сетей для подключения ресурсов приложений и устройств HSM
- Подключение виртуальных сетей в разных регионах для обмена данными, а также для реализации сценариев с высоким уровнем доступности
Виртуальная сеть для выделенных HSM
Выделенные HSM интегрированы в виртуальную сеть и помещаются в собственную частную сеть клиентов в Azure. Это обеспечивает доступ к устройствам с виртуальных машин или вычислительных ресурсов в виртуальной сети.
Дополнительные сведения об интеграции служб Azure в виртуальной сети и возможностях, которые она предоставляет, см. в статье Виртуальная сеть для служб Azure.
Виртуальные сети
Перед подготовкой выделенного устройства HSM клиенты сначала должны создать виртуальную сеть в Azure или использовать уже существующую в подписке клиентов. Виртуальная сеть определяет периметр безопасности для выделенного устройства HSM. Дополнительные сведения о создании виртуальных сетей см. в документации по виртуальным сетям.
Подсети
Подсети сегментируют виртуальную сеть на отдельные адресные пространства, которые применяются для размещения ресурсов Azure. Выделенные HSM развертываются в подсети в виртуальной сети. Каждое выделенное устройство HSM, которое развернуто в подсети клиента, будет получать частный IP-адрес из этой подсети. Подсеть, в которой развернуто устройство HSM, должна быть явно делегирована службе: Microsoft.HardwareSecurityModules/dedicatedHSMs. Это предоставляет определенные разрешения для службы HSM для развертывания в подсети. Делегирование выделенных HSM накладывает некоторые ограничения политики на подсеть. Группы безопасности сети (NSG) и определяемые пользователем маршруты (UDR) в настоящее время не поддерживаются в делегированных подсетях. После делегирования подсети для выделенных HSM она может использоваться только для развертывания ресурсов HSM. Развертывание любых других клиентских ресурсов в подсети не будет выполнено. Не существует требования относительно того, насколько велика или мала должна быть подсеть для выделенного устройства HSM, однако каждое устройство HSM будет использовать один частный IP-адрес, поэтому следует убедиться, что подсеть достаточно велика, чтобы поддерживать столько устройств HSM, сколько необходимо для развертывания.
Шлюз ExpressRoute
Требование для текущей архитектуры представляет собой конфигурацию шлюза ExpressRoute в подсети клиентов, где должно быть размещено устройство HSM для обеспечения интеграции устройства HSM в Azure. Этот шлюз ExpressRoute не может быть использован для подключения локальных расположений к клиентским устройствам HSM в Azure.
Подключение локальных ИТ к Azure
При создании облачных ресурсов типичным требованием является наличие частного подключения к локальным ИТ-ресурсам. В случае с выделенным устройством HSM это требование преимущественно распространяется на клиентское программное обеспечение HSM для настройки устройств HSM, а также на такие действия, как резервное копирование и извлечение журналов из HSM для анализа. В данном случае ключевым аспектом для принятия решения является характер подключения, так как возможны разные варианты. Самый гибкий вариант — VPN между сайтами. В этом случае может быть несколько локальных ресурсов, для которых требуется безопасный обмен данными с ресурсами (включая HSM) в облаке Azure. Для этого нужно, чтобы в организации клиента было VPN-устройство для подключения. VPN-подключение типа "точка — сеть" можно использовать при наличии только одной локальной конечной точки (например, одной рабочей станции администрирования). Дополнительные сведения о вариантах подключения см. в статье Параметры планирования VPN-шлюза.
Примечание
В настоящее время ExpressRoute не является вариантом подключения к локальным ресурсам. Следует также отметить, что шлюз ExpressRoute, используемый описанным выше способом, не предназначается для подключения к локальной инфраструктуре.
VPN-подключение типа "точка — сеть"
Виртуальная частная сеть типа "точка — сеть" — это самая простая форма безопасного подключения к одной локальной конечной точке. Это может быть важно в том случае, если вы планируете использовать только одну рабочую станцию администрирования для выделенных устройств HSM на базе Azure.
VPN-подключение "сеть-сеть"
Виртуальная частная сеть типа "сеть — сеть" обеспечивает безопасный обмен данными между выделенными устройствами HSM на платформе Azure и локальными ИТ-ресурсами. Причина этого заключается в наличии функции резервного копирования для локальных ресурсов HSM и необходимости подключения между ними для выполнения резервного копирования.
Подключение виртуальных сетей
Типичная архитектура развертывания для выделенного HSM запускается с одной виртуальной сетью и соответствующей подсетью, в которой создаются и подготавливаются устройства HSM. В том же регионе также могут быть дополнительные виртуальные сети и подсети для компонентов приложения, которые используют выделенное устройство HSM. Чтобы обеспечить обмен данными между этими сетями, мы используем пиринг между виртуальными сетями.
Пиринг между виртуальными сетями
При наличии нескольких виртуальных сетей в пределах региона, которым необходим доступ к ресурсам друг друга, пиринг между виртуальными сетями можно использовать для создания каналов безопасного обмена данными между ними. Пиринг между виртуальными сетями обеспечивает не только безопасные подключения, но и низкую задержку с высокой пропускной способностью соединений между ресурсами в Azure.
Подключение между регионами Azure
Устройства HSM могут с помощью библиотек программного обеспечения перенаправить трафик на альтернативное устройство HSM. Перенаправление трафика полезно в том случае, если устройства отказали или доступ к устройству потерян. Сценарии сбоя на региональном уровне можно смягчить, развертывая HSM в других регионах и включая обмен данными между виртуальными сетями в разных регионах.
Высокий уровень доступности с использованием VPN-шлюза для регионов
Для глобально распределенных приложений или сценариев региональной отработки отказа с обеспечением высокого уровня доступности необходимо подключить виртуальные сети, находящиеся в разных регионах. Благодаря выделенному устройству HSM Azure можно добиться высокого уровня доступности с помощью VPN-шлюза, обеспечивающего безопасный туннель между двумя виртуальными сетями. Дополнительные сведения о подключениях между виртуальными сетями с помощью VPN-шлюза см. в статье Что такое VPN-шлюз.
Примечание
На данный момент глобальный пиринг между виртуальными сетями недоступен в сценариях с возможностью межрегионального подключения с помощью выделенных HSM, вместо него следует использовать VPN-шлюз.
Ограничения сети
Примечание
Ограничение службы "Выделенное устройство HSM", использующей делегирование подсети, следует учитывать при проектировании целевой сетевой архитектуры для развертывания HSM. Использование делегирования подсети означает, что группы безопасности сети, определяемые пользователем маршруты и пиринг глобальной виртуальной сети не поддерживаются для Выделенного устройства HSM. В разделах ниже приводятся сведения об альтернативных методах, позволяющих добиться того же или аналогичного результата для этих возможностей.
Сетевой адаптер HSM, который находится в виртуальной сети Выделенного устройства HSM, не может использовать группы безопасности сети или определяемые пользователем маршруты. Это означает, что невозможно установить политики запрета по умолчанию с точки зрения виртуальной сети Выделенного устройства HSM и что другие сегменты сети должны быть разрешены для получения доступа к службе Выделенного устройства HSM.
Добавление решения прокси-сервера "Сетевые виртуальные модули" (NVA) также позволяет логически размещать брандмауэр NVA в транзитном или DMZ-хабе перед сетевым адаптером HSM, тем самым предоставляя необходимую альтернативу группам безопасности сети и определяемым пользователем маршрутам.
Архитектура решения
Для этой структуры сети требуются следующие элементы.
- Виртуальная сеть транзитного или DMZ-хаба с уровнем прокси-сервера NVA. В идеале должно быть два NVA или более.
- Канал ExpressRoute с включенным частным пирингом и подключением к виртуальной сети транзитного хаба.
- Пиринг виртуальной сети между виртуальной сетью транзитного хаба и виртуальной сетью Выделенного устройства HSM.
- В качестве варианта можно развернуть брандмауэр NVA или Брандмауэр Azure, предлагающий службы DMZ в хабе.
- Дополнительные периферийные виртуальные сети рабочих нагрузок можно с помощью пиринга соединить с виртуальной сетью хаба. Клиент Gemalto может получить доступ к службе Выделенного устройства HSM через виртуальную сеть хаба.
Добавление решения прокси-сервера NVA также позволяет логически размещать брандмауэр NVA в транзитном или DMZ-хабе перед сетевым адаптером HSM, тем самым предоставляя необходимые политики запрета по умолчанию. В нашем примере мы будем использовать Брандмауэр Azure для этой цели. Нам потребуются следующие элементы.
- Брандмауэр Azure, развернутый в подсети AzureFirewallSubnet в виртуальной сети хаба DMZ.
- Таблица маршрутизации с UDR, которая направляет трафик в частную конечную точку Azure ILB в Брандмауэр Azure. Эта таблица маршрутизации будет применена к GatewaySubnet, где размещен виртуальный шлюз ExpressRoute клиента.
- Правила сетевой безопасности в Брандмауэре Azure, чтобы разрешить перенаправление между доверенным исходным диапазоном и частной конечной точкой Azure IBL, прослушиваемой через TCP-порт 1792. Эта логика безопасности добавит необходимую политику "запретить по умолчанию" для службы Выделенного устройства HSM. Это означает, что службе Выделенного устройства HSM будут разрешены только доверенные диапазоны IP-адресов источника. Все остальные диапазоны будут удалены.
- Таблица маршрутизации с UDR, которая направляет трафик для локальной системы в Брандмауэр Azure. Эта таблица маршрутизации будет применена к подсети прокси-сервера NVA.
- NSG, применяемая к подсети NVA прокси-сервера, чтобы доверять только диапазону подсети Брандмауэра Azure в качестве источника и разрешить перенаправление только на IP-адрес сетевого адаптера HSM через TCP-порт 1792.
Примечание
Поскольку уровень прокси-сервера NVA использует SNAT для IP-адреса клиента, так как выполняется перенаправление на сетевой адаптер HSM, вам не нужны определяемые пользователем маршруты между виртуальной сетью HSM и виртуальной сетью хаба DMZ.
Альтернатива для определяемых пользователем маршрутов
Решение уровня NVA, упомянутое выше, работает в качестве альтернативы определяемым пользователем маршрутам. Необходимо учитывать важные моменты.
- В NVA должно быть настроено преобразование сетевых адресов, чтобы обеспечить правильную маршрутизацию трафика.
- Клиентам следует отключить синхронизацию IP-адреса клиента в конфигурации Luna HSM, чтобы использовать VNA для NAT. Ниже приведены примеры команд.
Disable:
[hsm01] lunash:>ntls ipcheck disable
NTLS client source IP validation disabled
Command Result : 0 (Success)
Show:
[hsm01] lunash:>ntls ipcheck show
NTLS client source IP validation : Disable
Command Result : 0 (Success)
- Разверните определяемые пользователем маршруты для входящего трафика на уровне NVA.
- Подсети HSM намерено не инициируют запрос на исходящее подключение к уровню платформы.
Альтернатива использованию глобального Пиринга виртуальных сетей
Существует несколько архитектур, которые можно использовать в качестве альтернативы глобального Пиринга виртуальных сетей.
- Используйте подключение между виртуальными сетями с использованием VPN-шлюза.
- Подключите HSM VNET к другой виртуальной сети с каналом ER. Это лучший вариант, если требуется прямой локальный путь или виртуальная частная сеть.
HSM с прямым подключением к Express Route
