Dedykowane sieciowanie HSM platformy Azure

Dedykowany moduł HSM platformy Azure wymaga niezawodnej, bezpiecznej infrastruktury sieciowej we wszystkich scenariuszach wdrażania. Niezależnie od tego, czy łączenie się z chmury platformy Azure ze środowiskiem lokalnym, implementowanie aplikacji rozproszonych lub ustanawianie konfiguracji wysokiej dostępności, niezbędne jest kompleksowe zabezpieczenia. Sieć platformy Azure zapewnia zabezpieczenia za pośrednictwem czterech krytycznych obszarów sieci, które wymagają starannego planowania i implementacji.

• Tworzenie urządzeń HSM wewnątrz sieci wirtualnej na platformie Azure
• Łączenie lokalne z zasobami opartymi na chmurze na potrzeby konfiguracji i zarządzania urządzeniami HSM
• Tworzenie i łączenie sieci wirtualnych na potrzeby łączenia zasobów aplikacji i urządzeń HSM
• Łączenie sieci wirtualnych między regionami na potrzeby komunikacji międzyoperacyjnej, a także włączanie scenariuszy wysokiej dostępności

Sieć wirtualna dla dedykowanych modułów HSM

Dedykowane moduły HSM są zintegrowane z siecią wirtualną i umieszczane we własnej sieci prywatnej klientów na platformie Azure. Umożliwia to dostęp do urządzeń z maszyn wirtualnych lub zasobów obliczeniowych w sieci wirtualnej.
Aby uzyskać więcej informacji na temat integrowania usług platformy Azure z siecią wirtualną i oferowanych przez nią funkcji, zobacz Dokumentację sieci wirtualnej dla usług platformy Azure .

Sieci wirtualne

Klienci muszą utworzyć sieć wirtualną na platformie Azure przed aprowizowaniem lub użyć tej, która już istnieje w subskrypcji klientów. Sieć wirtualna definiuje obwód zabezpieczeń dedykowanego urządzenia HSM. Aby uzyskać więcej informacji na temat tworzenia sieci wirtualnych, zobacz dokumentację sieci wirtualnej.

Subnets

Podsieci dzielą sieć wirtualną na oddzielne przestrzenie adresowe używane przez zasoby platformy Azure, które są w nich umieszczone. Dedykowane moduły HSM są wdrażane w podsieci w sieci wirtualnej. Każde dedykowane urządzenie HSM wdrożone w podsieci klienta otrzymuje prywatny adres IP z tej podsieci.

Podsieć, w której wdrożono urządzenie HSM, musi być jawnie delegowana do usługi: Microsoft.HardwareSecurityModules/dedicatedHSMs. Daje to pewne uprawnienia do usługi HSM na potrzeby wdrażania w podsieci. Delegowanie do dedykowanych modułów HSM wymusza pewne ograniczenia polityki w podsieci. Obecnie Grupy zabezpieczeń sieci (NSG) i trasy definiowane przez użytkownika (UDR) nie są obsługiwane w podsieciach delegowanych. W związku z tym po delegowaniu podsieci do dedykowanych modułów HSM można jej użyć tylko do wdrażania zasobów modułu HSM. Wdrażanie jakichkolwiek innych zasobów klienta w podsieci kończy się niepowodzeniem. Nie ma wymagań dotyczących rozmiaru podsieci dla dedykowanego modułu HSM, jednak każde urządzenie HSM zużywa jeden prywatny adres IP. Dlatego należy upewnić się, że podsieć jest wystarczająco duża, aby pomieścić tyle urządzeń HSM, ile jest wymaganych do wdrożenia.

Brama usługi ExpressRoute

Wymaganie bieżącej architektury to konfiguracja bramy usługi ExpressRoute w podsieci klientów, w której należy umieścić urządzenie HSM, aby umożliwić integrację urządzenia HSM z platformą Azure. Bramy usługi ExpressRoute nie można używać do łączenia lokalizacji lokalnych z urządzeniami HSM klientów na platformie Azure.

Łączenie lokalnej infrastruktury IT z platformą Azure

Podczas tworzenia zasobów opartych na chmurze ustanawianie połączenia prywatnego z powrotem do lokalnych zasobów IT jest typowym wymaganiem. W przypadku wdrożeń dedykowanego modułu HSM platformy Azure takie połączenia obsługują przede wszystkim oprogramowanie klienckie HSM dla konfiguracji urządzenia, operacji tworzenia kopii zapasowych i pobierania dzienników z modułów HSM na potrzeby analizy.

Podczas wybierania opcji łączności charakter połączenia reprezentuje kluczowy punkt decyzyjny. Sieć VPN typu lokacja-lokacja zapewnia największą elastyczność, zwłaszcza gdy wiele zasobów lokalnych wymaga bezpiecznej komunikacji z zasobami chmury platformy Azure, w tym z modułami HSM. Zaimplementowanie sieci VPN typu lokacja-lokacja wymaga od organizacji wdrożenia urządzenia sieci VPN w celu ułatwienia połączenia. Alternatywnie połączenia sieci VPN typu punkt-lokacja działają dobrze, gdy istnieje tylko jeden lokalny punkt końcowy, taki jak stacja robocza administracyjna.

Aby uzyskać więcej informacji na temat opcji łączności, zobacz Opcje planowania usługi VPN Gateway.

Uwaga / Notatka

Usługa ExpressRoute nie jest opcją połączenia z zasobami lokalnymi. Należy również zauważyć, że brama ExpressRoute używana w tym kontekście nie służy do połączeń z infrastrukturą lokalną.

Sieć VPN typu punkt-lokacja

Wirtualna sieć prywatna typu punkt-lokacja to najprostsza forma bezpiecznego połączenia z pojedynczym punktem końcowym lokalnie. Może to być istotne, jeśli masz tylko jedną stację roboczą administracyjną dla dedykowanych modułów HSM opartych na platformie Azure.

VPN między lokalizacjami

Wirtualna sieć prywatna typu lokacja-lokacja umożliwia bezpieczną komunikację między dedykowanymi modułami HSM opartymi na platformie Azure i lokalną infrastrukturą IT. Organizacje często implementują takie połączenia przy zachowaniu lokalnej infrastruktury kopii zapasowej dla modułów HSM, ponieważ bezpieczny tunel obsługuje niezbędne transfery danych na potrzeby operacji tworzenia kopii zapasowych między obydwoma środowiskami.

Łączenie sieci wirtualnych

Typowa architektura wdrażania dedykowanego modułu HSM rozpoczyna się od jednej sieci wirtualnej i odpowiedniej podsieci, w której są tworzone i aprowidowane urządzenia HSM. W tym samym regionie może istnieć więcej sieci wirtualnych i podsieci dla składników aplikacji, które korzystają z dedykowanego modułu HSM. Aby umożliwić komunikację między tymi sieciami, używamy peeringu sieci wirtualnych.

Peerowanie sieci wirtualnej

Jeśli w regionie istnieje wiele sieci wirtualnych, które muszą wzajemnie uzyskiwać dostęp do swoich zasobów, Virtual Network Peering tworzy bezpieczne kanały komunikacyjne między nimi. Komunikacja równorzędna sieci wirtualnych zapewnia nie tylko bezpieczną komunikację, ale także zapewnia połączenia o małych opóźnieniach i wysokiej przepustowości między zasobami na platformie Azure.

Łączenie między regionami platformy Azure

Urządzenia HSM mają możliwość przekierowywania ruchu do alternatywnego modułu HSM za pośrednictwem bibliotek oprogramowania. Przekierowywanie ruchu jest przydatne w przypadku awarii urządzeń lub utraty dostępu do urządzenia. Scenariusze awarii na poziomie regionalnym można ograniczyć, wdrażając moduły HSM w innych regionach i umożliwiając komunikację między sieciami wirtualnymi w różnych regionach.

Wysoka dostępność między regionami przy użyciu bramy sieci VPN

W przypadku globalnie rozproszonych aplikacji lub scenariuszy przełączania awaryjnego o wysokiej dostępności w regionach wymagane jest połączenie sieci wirtualnych między regionami. Dzięki dedykowanemu modułowi HSM platformy Azure wysoką dostępność można osiągnąć przy użyciu bramy sieci VPN, która zapewnia bezpieczny tunel między dwiema sieciami wirtualnymi. Aby uzyskać więcej informacji na temat połączeń między sieciami wirtualnymi przy użyciu usługi VPN Gateway, zobacz artykuł zatytułowany Co to jest usługa VPN Gateway?

Uwaga / Notatka

Globalne połączenie równorzędne sieci wirtualnych (Vnet peering) nie jest obecnie dostępne w scenariuszach łączności między regionami z dedykowanymi modułami HSM. Zamiast tego należy użyć bramy sieci VPN.

Ograniczenia dotyczące sieci

Uwaga / Notatka

Ograniczenia związane z korzystaniem z delegowania podsieci w dedykowanej usłudze HSM powinny być brane pod uwagę podczas projektowania docelowej architektury sieci dla implementacji HSM. Użycie delegowania podsieci oznacza, że dedykowane moduły HSM nie obsługują sieciowych grup zabezpieczeń (NSG), tras zdefiniowanych przez użytkownika (UDR) oraz globalnej komunikacji równorzędnej wirtualnych sieci (VNet Peering). Poniższe sekcje zawierają pomoc dotyczącą alternatywnych technik osiągnięcia tego samego lub podobnego wyniku dla tych możliwości.

Ograniczenia zabezpieczeń sieci

Karta interfejsu sieciowego (NIC) modułu HSM znajdująca się w dedykowanej sieci wirtualnej modułu HSM nie może korzystać z sieciowych grup zabezpieczeń ani tras zdefiniowanych przez użytkownika ze względu na wymagania dotyczące delegowania podsieci. Spowoduje to utworzenie ważnego zagadnienia zabezpieczeń: nie można zaimplementować zasad domyślnej odmowy bezpośrednio z perspektywy sieci VNet dedykowanego modułu HSM. Zamiast tego zabezpieczenia muszą być implementowane przez jawne zezwolenie na dostęp z określonych segmentów sieci do usługi dedykowanego modułu HSM za pomocą alternatywnych metod.

Dodanie rozwiązania serwera proxy Wirtualnych Urządzeń Sieciowych (WUS) umożliwia również logiczne umieszczenie zapory sieciowej WUS w koncentratorze tranzytowym/DMZ przed interfejsem sieciowym HSM, zapewniając w ten sposób wymaganą alternatywę dla sieciowych grup zabezpieczeń i tras zdefiniowanych przez użytkownika.

Architektura rozwiązania

Ten projekt sieci wymaga następujących elementów:

1. Tranzytowe lub centrum sieci wirtualnej DMZ z warstwą urządzeń Wirtualnej Sieciowej Przełącznicy, pełniącą funkcję serwera proxy. Idealnie obecne są dwa lub więcej urządzeń NVA.
2. Obwód usługi ExpressRoute z włączonym prywatnym peeringiem i połączeniem z VNet centrum tranzytowego.
3. Komunikacja równorzędna sieci wirtualnych między siecią VNet koncentratora tranzytowego a dedykowaną siecią VNet HSM.
4. Zaporę NVA lub Zaporę Azure można wdrożyć w centrum sieci jako opcję, oferując usługi DMZ.
5. Dodatkowe sieci VNet powiązane z obciążeniem mogą być połączone z siecią VNet w centrum. Klient Gemalto może uzyskać dostęp do dedykowanej usługi HSM za pośrednictwem sieci wirtualnej koncentratora.

Ponieważ dodanie rozwiązania serwera proxy NVA pozwala również na logiczne umieszczenie zapory NVA w centrum tranzytowym DMZ przed interfejsem sieciowym HSM, zapewniając w ten sposób wymagane zasady odmowy domyślnej. W naszym przykładzie używamy usługi Azure Firewall do tego celu i potrzebujemy następujących elementów:

1. Usługa Azure Firewall wdrożona w podsieci "AzureFirewallSubnet" w sieci wirtualnej koncentratora DMZ
2. Tabela routingu z trasą zdefiniowaną przez użytkownika, która kieruje ruch do prywatnego punktu końcowego Azure ILB przez Azure Firewall. Ta tabela routingu jest stosowana do podsieci GatewaySubnet, w której znajduje się brama wirtualna usługi ExpressRoute klienta.
3. Reguły zabezpieczeń sieci w usłudze AzureFirewall umożliwiają przekazywanie między zaufanym zakresem źródłowym a prywatnym punktem końcowym Azure IBL, nasłuchującym na porcie TCP 1792. Ta logika zabezpieczeń dodaje niezbędne zasady odmowy domyślnej względem dedykowanej usługi HSM. Oznacza to, że tylko zaufane zakresy źródłowych adresów IP są dozwolone w dedykowanej usłudze HSM. Wszystkie inne zakresy są porzucane.
4. Tabela routingu z trasą zdefiniowaną przez użytkownika, która kieruje ruch skierowany do środowiska lokalnego do Azure Firewall. Ta tabela routingu jest stosowana do podsieci serwera proxy NVA.
5. Sieciowa grupa zabezpieczeń zastosowana do podsieci serwera proxy NVA, aby ufać tylko zakresowi adresów podsieci Azure Firewall jako źródła oraz zezwalać na przekazywanie ruchu jedynie do adresu IP interfejsu sieciowego HSM przez port TCP 1792.

Uwaga / Notatka

Ponieważ warstwa proxy NVA będzie wykonywać SNAT na adresie IP klienta podczas przekazywania go do karty sieciowej HSM, żadne trasy zdefiniowane przez użytkownika nie są wymagane między siecią wirtualną HSM a siecią wirtualną węzła DMZ.

Alternatywa dla tras zdefiniowanych przez użytkownika

Wymienione rozwiązanie warstwy NVA działa jako alternatywa dla tras zdefiniowanych przez użytkownika. Należy pamiętać o kilku ważnych kwestiach.

1. Translacja adresów sieciowych powinna być skonfigurowana na urządzeniu NVA, aby umożliwić prawidłowe kierowanie ruchu powrotnego.
2. Klienci powinni wyłączyć sprawdzanie adresu IP klienta w konfiguracji HSM Luna, aby używać VNA dla NAT. Poniższe polecenia służą jako przykład.

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)

1. Wdróż UDR dla ruchu przychodzącego do warstwy wirtualnego urządzenia sieciowego (NVA).
2. Zgodnie z projektem podsieci HSM nie będą inicjować żądania połączenia wychodzącego do warstwy platformy.

Alternatywa dla korzystania z globalnego peeringu VNET

Istnieje kilka architektur, których można użyć jako alternatywy dla Global VNet peering.

1. Użyj połączenia bramy sieci VPN Vnet-do-Vnet
2. Połącz sieć wirtualną HSM z inną siecią wirtualną z obwodem ER. Działa to najlepiej, gdy wymagana jest bezpośrednia lokalna ścieżka lub VPN VNET.

Moduł HSM z bezpośrednią łącznością usługi ExpressRoute

Następne kroki

• Często zadawane pytania
• Możliwości obsługi
• Wysoka dostępność
• Zabezpieczenia fizyczne
• Nadzorowanie
• Architektura wdrażania