Integracja zapory usługi Azure Stack Hub

Zaleca się użycie urządzenia zapory w celu zabezpieczenia usługi Azure Stack Hub. Zapory mogą pomóc w ochronie przed atakami typu "rozproszona odmowa usługi" (DDOS), wykrywaniem włamań i inspekcją zawartości. Mogą one jednak stać się również wąskim gardłem przepływności dla usług magazynu platformy Azure, takich jak obiekty blob, tabele i kolejki.

Jeśli jest używany tryb wdrażania bez połączenia, należy opublikować punkt końcowy usług AD FS. Aby uzyskać więcej informacji, zobacz artykuł dotyczący tożsamości integracji centrum danych.

Punkty końcowe usługi Azure Resource Manager (administrator), portal administratora i Key Vault (administrator) nie muszą wymagać publikowania zewnętrznego. Na przykład jako dostawca usług można ograniczyć obszar ataków tylko przez administrowanie usługą Azure Stack Hub z poziomu sieci, a nie z Internetu.

W przypadku organizacji przedsiębiorstwa sieć zewnętrzna może być istniejącą siecią firmową. W tym scenariuszu należy opublikować punkty końcowe w celu obsługi usługi Azure Stack Hub z sieci firmowej.

Tłumaczenie adresów sieciowych

Translator adresów sieciowych (NAT) to zalecana metoda umożliwiająca maszynie wirtualnej wdrażania (DVM) uzyskiwanie dostępu do zasobów zewnętrznych i Internetu podczas wdrażania, a także maszyn wirtualnych konsoli odzyskiwania awaryjnego (ERCS) lub uprzywilejowanego punktu końcowego (PEP) podczas rejestracji i rozwiązywania problemów.

Translator adresów sieciowych może być również alternatywą dla publicznych adresów IP w sieci zewnętrznej lub publicznych adresów VIP. Nie zaleca się jednak tego robić, ponieważ ogranicza środowisko użytkownika dzierżawy i zwiększa złożoność. Jedną z opcji jest jeden do jednego translatora adresów sieciowych, który nadal wymaga jednego publicznego adresu IP na adres IP użytkownika w puli. Inną opcją jest wiele do jednego translatora adresów sieciowych, które wymagają reguły translatora adresów sieciowych na adres VIP użytkownika dla wszystkich portów, których może użyć użytkownik.

Niektóre wady używania translatora adresów sieciowych dla publicznego adresu VIP to:

• Translator adresów sieciowych dodaje nakład pracy podczas zarządzania regułami zapory, ponieważ użytkownicy kontrolują własne punkty końcowe i własne reguły publikowania w stosie sieci zdefiniowanej programowo . Użytkownicy muszą skontaktować się z operatorem usługi Azure Stack Hub, aby opublikować swoje adresy VIP i zaktualizować listę portów.
• Chociaż użycie translatora adresów sieciowych ogranicza środowisko użytkownika, zapewnia pełną kontrolę nad operatorem za pośrednictwem żądań publikowania.
• W przypadku scenariuszy chmury hybrydowej z platformą Azure należy wziąć pod uwagę, że platforma Azure nie obsługuje konfigurowania tunelu sieci VPN do punktu końcowego przy użyciu translatora adresów sieciowych.

Przechwytywanie protokołu SSL

Obecnie zaleca się wyłączenie dowolnego przechwytywania protokołu SSL (na przykład odszyfrowywania odciążania) dla całego ruchu usługi Azure Stack Hub. Jeśli jest ona obsługiwana w przyszłych aktualizacjach, wskazówki zostaną przedstawione na temat włączania przechwytywania protokołu SSL dla usługi Azure Stack Hub.

Scenariusz zapory edge

We wdrożeniu brzegowym usługa Azure Stack Hub jest wdrażana bezpośrednio za routerem brzegowym lub zaporą. W tych scenariuszach zapora jest obsługiwana w taki sposób, aby przekraczała obramowanie (scenariusz 1), w którym obsługuje zarówno konfiguracje zapory aktywne-aktywne, jak i aktywne-pasywne lub działające jako urządzenie graniczne (scenariusz 2), gdzie obsługuje tylko konfigurację zapory aktywne-aktywnej opartej na równoczesnej ścieżce (ECMP) z protokołem BGP lub routingiem statycznym dla trybu failover.

Publiczne routingowe adresy IP są określane dla publicznej puli adresów VIP z sieci zewnętrznej w czasie wdrażania. W scenariuszu brzegowym nie zaleca się używania publicznych adresów IP routingu w żadnej innej sieci na potrzeby zabezpieczeń. Ten scenariusz umożliwia użytkownikowi korzystanie z pełnego środowiska chmury sterowanej samodzielnie, tak jak w chmurze publicznej, takiej jak platforma Azure.

Scenariusz zapory sieci intranetowej lub obwodowej przedsiębiorstwa

We wdrożeniu intranetowym lub obwodowym przedsiębiorstwa usługa Azure Stack Hub jest wdrażana w wielostrefowej zaporze lub między zaporą brzegową a wewnętrzną, firmową zaporą sieciową. Ruch jest następnie dystrybuowany między bezpieczną siecią obwodową (lub DMZ) i niezabezpieczonymi strefami, zgodnie z poniższym opisem:

• Bezpieczna strefa: jest to sieć wewnętrzna, która używa wewnętrznych lub firmowych routingowych adresów IP. Bezpieczna sieć może być podzielona, mieć dostęp wychodzący z Internetu za pośrednictwem translatora adresów sieciowych w zaporze i jest zwykle dostępny z dowolnego miejsca wewnątrz centrum danych za pośrednictwem sieci wewnętrznej. Wszystkie sieci usługi Azure Stack Hub powinny znajdować się w bezpiecznej strefie z wyjątkiem publicznej puli adresów VIP sieci zewnętrznej.
• Strefa obwodowa. Sieć obwodowa jest miejscem, w którym zazwyczaj wdrażane są aplikacje zewnętrzne lub internetowe, takie jak serwery sieci Web. Zwykle jest on monitorowany przez zaporę, aby uniknąć ataków, takich jak DDoS i włamanie (hacking), jednocześnie zezwalając na określony ruch przychodzący z Internetu. Tylko publiczna pula adresów VIP sieci zewnętrznej usługi Azure Stack Hub powinna znajdować się w strefie DMZ.
• Niezabezpieczona strefa. Jest to sieć zewnętrzna, Internet. Nie zaleca się wdrażania usługi Azure Stack Hub w niezabezpieczonej strefie.

Więcej tutaj

Dowiedz się więcej o portach i protokołach używanych przez punkty końcowe usługi Azure Stack Hub.

Następne kroki

Wymagania dotyczące infrastruktury kluczy publicznych usługi Azure Stack Hub