Интеграция брандмауэра Azure Stack Hub

Мы рекомендуем использовать для защиты Azure Stack Hub аппаратный брандмауэр. Брандмауэры могут помочь в защите от распределенных атак, например отказ в обслуживании (DDOS), обнаружение вторжений и проверка содержимого. Тем не менее они могут ограничивать пропускную способность для служб хранилища Azure, например для больших двоичных объектов, таблиц и очередей.

Если используется автономный режим развертывания, необходимо опубликовать конечную точку службы федерации Active Directory. Дополнительные сведения см. в статье об удостоверениях для интеграции центра обработки данных.

Конечные точки Azure Resource Manager (для администратора), портала администрирования и Key Vault (для администратора) необязательно публиковать для внешнего доступа. Например, для снижения уязвимости поставщик услуг может выполнять функции администрирования Azure Stack Hub только из локальной сети, но не из Интернета.

В крупной организации внешняя сеть может являться корпоративной. В таком случае публикация конечных точек требуется для управления Azure Stack Hub из корпоративной сети.

Преобразование сетевых адресов

Преобразование сетевых адресов (NAT) является рекомендуемым методом, который обеспечивает доступ виртуальной машины развертывания к внешним ресурсам и Интернету во время развертывания, а также доступ к виртуальным машинам консоли аварийного восстановления или привилегированной конечной точке во время регистрации и устранения неполадок.

NAT также может быть альтернативой общедоступным IP-адресам во внешней сети или общедоступным виртуальным IP-адресам. Однако делать это не рекомендуется, так как это ограничивает возможности взаимодействия с пользователем клиента и увеличивает сложность. Возможен один вариант: NAT типа "1 к 1", при котором по-прежнему требуется один общедоступный IP-адрес для каждого IP-адреса пользователя в пуле. Другой вариант — "многие к 1", при котором для каждого виртуального IP-адреса пользователя требуется правило NAT для всех портов, которые может применять пользователь.

Ниже приведены некоторые недостатки использования NAT для общедоступных виртуальных IP-адресов.

  • NAT повышает издержки на управление правилами брандмауэра, так как пользователи самостоятельно контролируют свои конечные точки и правила публикации в программно-определяемом сетевом стеке (SDN). Для публикации виртуальных IP-адресов и для обновления списка портов пользователям придется обращаться к оператору Azure Stack Hub.
  • Использование NAT ухудшает взаимодействие с пользователем, но дает оператору полный контроль над публикацией запросов.
  • Для гибридных облачных сценариев с Azure следует учитывать, что Azure не поддерживает настройку VPN-туннеля к конечной точке, использующей NAT.

Перехват SSL

Сейчас рекомендуется отключать любой перехват SSL (например, разгрузку расшифровки) для всего трафика Azure Stack Hub. Если это будет реализовано в следующих обновлениях, мы предоставим инструкции по включению перехвата SSL для Azure Stack Hub.

Использование граничного брандмауэра

При пограничном развертывании Azure Stack Hub развертывается непосредственно за пограничным маршрутизатором или брандмауэром. В этих сценариях брандмауэр может располагаться над границей (сценарий 1), где он поддерживает конфигурации "активный — активный" и "активный — пассивный". Он также может выступать в роли пограничного устройства (сценарий 2), поддерживая только конфигурацию "активный — активный" и полагаясь на ECMP с маршрутизацией BGP или статической маршрутизацией для отработки отказа.

Для пула общедоступных виртуальных IP-адресов из внешней сети во время развертывания указываются общедоступные маршрутизируемые IP-адреса. В пограничном сценарии не рекомендуется использовать общедоступные маршрутизируемые IP-адреса в какой-либо другой сети в целях безопасности. Этот сценарий позволяет пользователю работать в полностью контролируемой облачной среде как в обычном общедоступном облаке типа Azure.

Пример пограничного брандмауэра Azure Stack Hub

Сценарий с брандмауэром в сети периметра или корпоративной интрасети

В случае развертывания в корпоративной интрасети или сети периметра Azure Stack Hub развертывается в брандмауэре с несколькими зонами или между пограничным брандмауэром и брандмауэром внутренней корпоративной сети. Затем его трафик распределяется между защищенной сетью периметра и незащищенными зонами, как описано ниже.

  • Защищенная зона. Это внутренняя сеть, использующая внутренние или корпоративные маршрутизируемые IP-адреса. Защищенную сеть можно разделить или предоставить ей исходящий доступ к Интернету через NAT в брандмауэре. Как правило, она доступна везде внутри центра обработки данных через внутреннюю сеть. Все сети Azure Stack Hub должны находиться в безопасной зоне, за исключением пула общедоступных виртуальных IP-адресов из внешней сети.
  • Зона периметра. Сеть периметра — это сеть, в которой обычно развертываются внешние приложения или приложения с выходом в Интернет, например веб-серверы. Обычно она отслеживается брандмауэром, чтобы избежать атак DDoS и вторжений (взлома), но в ней разрешено получение указанного входящего трафика из Интернета. В сети периметра должен размещаться только пул общедоступных виртуальных IP-адресов из внешней сети Azure Stack Hub.
  • Незащищенная зона. Это внешняя сеть, Интернет. Не рекомендуется развертывать Azure Stack Hub в незащищенной зоне.

Пример сети периметра Azure Stack Hub

Подробнее

Ознакомьтесь с дополнительными сведениями о портах и протоколах, используемых конечными точками Azure Stack Hub.

Дальнейшие действия

Требования к PKI Azure Stack Hub