Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Рекомендуется использовать устройство брандмауэра для защиты Azure Stack Hub. Брандмауэры могут помочь в защите от распределенных атак, например отказ в обслуживании (DDOS), обнаружение вторжений и проверка содержимого. Тем не менее они могут ограничивать пропускную способность для служб хранилища Azure, например для больших двоичных объектов, таблиц и очередей.
Если используется автономный режим развертывания, необходимо опубликовать конечную точку службы федерации Active Directory. Дополнительные сведения см. в статье об удостоверении интеграции центра обработки данных.
Конечные точки Azure Resource Manager (для администратора), портала администрирования и Key Vault (для администратора) необязательно публиковать для внешнего доступа. Например, для снижения уязвимости поставщик услуг может выполнять функции администрирования Azure Stack Hub только из локальной сети, но не из Интернета.
В крупной организации внешняя сеть может являться корпоративной. В таком случае публикация конечных точек требуется для управления Azure Stack Hub из корпоративной сети.
Преобразование сетевых адресов
Преобразование сетевых адресов (NAT) — это рекомендуемый метод, позволяющий виртуальной машине развертывания (DVM) получать доступ к внешним ресурсам и Интернету во время развертывания, а также виртуальным машинам консоли аварийного восстановления (ERCS) или привилегированной конечной точке (PEP) во время регистрации и устранения неполадок.
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 развертывается в брандмауэре с несколькими зонами или между пограничным брандмауэром и брандмауэром внутренней корпоративной сети. Затем его трафик распределяется между защищенной сетью периметра и незащищенными зонами, как описано ниже.
- Защищенная зона. Это внутренняя сеть, использующая внутренние или корпоративные маршрутизируемые IP-адреса. Безопасная сеть может быть разделена, иметь исходящий доступ к Интернету через NAT в брандмауэре и обычно доступен из любого места внутри центра обработки данных через внутреннюю сеть. Все сети Azure Stack Hub должны находиться в безопасной зоне, за исключением пула общедоступных виртуальных IP-адресов из внешней сети.
- Зона периметра. Сеть периметра — это сеть, в которой обычно развертываются внешние приложения или приложения с выходом в Интернет, например веб-серверы. Обычно он отслеживается брандмауэром, чтобы избежать атак, таких как DDoS и вторжение (взлом), при этом разрешая указанный входящий трафик из Интернета. В сети периметра должен размещаться только пул общедоступных виртуальных IP-адресов из внешней сети Azure Stack Hub.
- Незащищенная зона. Это внешняя сеть, Интернет. Не рекомендуется развертывать Azure Stack Hub в незащищенной зоне.
Подробнее
Дополнительные сведения о портах и протоколах, используемых конечными точками Azure Stack Hub.