Integracja zapory sieciowej Azure Stack Hub

Zaleca się użycie urządzenia zapory w celu zabezpieczenia usługi Azure Stack Hub. Zapory mogą pomóc w obronie przed atakami typu "rozproszona odmowa usługi", wykrywaniem nieautoryzowanego dostępu i inspekcją zawartości. Jednak mogą one również stać się wąskim gardłem przepustowości dla usług Azure Storage, takich jak obiekty blob, tabele i kolejki.

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

Punkty końcowe usługi Azure Resource Manager (administrator), portal administratora i punkty końcowe usługi Key Vault (administrator) nie muszą wymagać publikowania zewnętrznego. Na przykład jako dostawca usług można ograniczyć obszar ataków, administrowając usługą Azure Stack Hub tylko 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, aby obsługiwać usługę Azure Stack Hub z sieci firmowej.

Translacja adresów sieciowych

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

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

Niektóre z wad używania NAT dla publicznych adresów VIP to:

• NAT wprowadza dodatkowe obciążenie w zarządzaniu regułami zapory, ponieważ użytkownicy kontrolują własne punkty końcowe i własne reguły dostępu w stosie sieci zdefiniowanej przez oprogramowanie (SDN). Użytkownicy muszą skontaktować się z operatorem usługi Azure Stack Hub, aby opublikować adresy VIP i zaktualizować listę portów.
• Chociaż użycie translatora adresów sieciowych ogranicza doświadczenie użytkownika, zapewnia pełną kontrolę operatorowi nad żądaniami 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 wszelkiego przechwytywania SSL (na przykład odciążania odszyfrowywania) we wszystkich ruchach usługi Azure Stack Hub. Jeśli przechwytywanie SSL będzie obsługiwane w przyszłych aktualizacjach, zostaną dostarczone wskazówki na temat jego włączenia 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 może znajdować się powyżej granicy (Scenariusz 1), gdzie obsługuje zarówno konfiguracje zapory sieciowej aktywne-aktywne, jak i aktywne-pasywne, lub działać jako urządzenie graniczne (Scenariusz 2), gdzie obsługuje tylko konfigurację zapory sieciowej aktywne-aktywne, opierając się na wielodrożności o takim samym koszcie (ECMP) z użyciem BGP lub routingu statycznego dla trybu failover.

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

Scenariusz zapory sieci intranetowej lub obwodowej przedsiębiorstwa

W przypadku wdrożenia intranetowego lub obwodowego 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, jak opisano poniżej:

• Strefa bezpieczeństwa: jest to sieć wewnętrzna, która używa wewnętrznych lub firmowych routowalnych adresów IP. Bezpieczna sieć może być podzielona, mieć dostęp wychodzący z internetu za pomocą NAT w zaporze, i jest zwykle dostępna z dowolnego miejsca w 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 VIP sieci zewnętrznej.
• strefa obwodowa. Sieć obwodowa to miejsce, gdzie zazwyczaj wdrażane są aplikacje zewnętrzne lub skierowane na internet, takie jak serwery internetowe. Zwykle jest on monitorowany przez zaporę, aby uniknąć ataków, takich jak atak 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 jest zalecane do wdrożenia usługi Azure Stack Hub w niezabezpieczonej strefie.

Dowiedz się więcej

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 klucza publicznego usługi Azure Stack Hub