Dedykowana sieć modułu HSM platformy Azure

Dedykowany moduł HSM platformy Azure wymaga wysoce bezpiecznego środowiska sieciowego. Dotyczy to zarówno chmury platformy Azure, jak i środowiska IT klienta (lokalnie), przy użyciu aplikacji rozproszonych lub scenariuszy wysokiej dostępności. Usługa Azure Networking udostępnia tę funkcję i istnieją cztery odrębne obszary, które należy rozwiązać.

• 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 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

Przed aprowizowaniem dedykowanego urządzenia HSM klienci najpierw będą musieli utworzyć sieć wirtualną na platformie Azure lub użyć urządzenia, który 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.

Podsieci

Podsieci dzielą sieć wirtualną na oddzielne przestrzenie adresowe, z których mogą korzystać umieszczone w nich zasoby platformy Azure. Dedykowane moduły HSM są wdrażane w podsieci w sieci wirtualnej. Każde dedykowane urządzenie HSM wdrożone w podsieci klienta otrzyma prywatny adres IP z tej podsieci. Podsieć, w której wdrażane jest 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 nakłada pewne ograniczenia zasad w podsieci. Sieciowe grupy zabezpieczeń i trasy zdefiniowane przez użytkownika nie są obecnie 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. Wdrożenie innych zasobów klienta w podsieci zakończy się niepowodzeniem. Nie wymaga to, jak duża lub mała podsieć dedykowanego modułu HSM powinna być, jednak każde urządzenie HSM będzie zużywać jeden prywatny adres IP, dlatego należy zapewnić, ż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. Tej 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 jest to typowe wymaganie dotyczące połączenia prywatnego z lokalnymi zasobami IT. W przypadku dedykowanego modułu HSM będzie to głównie przeznaczone dla oprogramowania klienckiego HSM do konfigurowania urządzeń HSM, a także działań, takich jak kopie zapasowe i ściąganie dzienników z modułów HSM na potrzeby analizy. Kluczowym punktem decyzyjnym jest charakter połączenia, ponieważ istnieją opcje. Najbardziej elastyczną opcją jest sieć VPN typu lokacja-lokacja, ponieważ prawdopodobnie będzie wiele zasobów lokalnych, które wymagają bezpiecznej komunikacji z zasobami (w tym modułami HSM) w chmurze platformy Azure. Wymaga to od organizacji klienta posiadania urządzenia sieci VPN w celu ułatwienia połączenia. Połączenie sieci VPN typu punkt-lokacja może być używane, jeśli istnieje tylko jeden punkt końcowy w środowisku lokalnym, taki jak pojedyncza stacja robocza administracyjna. Aby uzyskać więcej informacji na temat opcji łączności, zobacz Opcje planowania usługi VPN Gateway.

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 zamierzasz mieć tylko jedną stację roboczą administracyjną dla dedykowanych modułów HSM opartych na platformie Azure.

Międzylokacyjna sieć VPN

Wirtualna sieć prywatna typu lokacja-lokacja umożliwia bezpieczną komunikację między dedykowanymi modułami HSM opartymi na platformie Azure i lokalnymi jednostkami IT. Przyczyną tego jest posiadanie infrastruktury kopii zapasowej dla lokalnego modułu HSM i wymaga połączenia między nimi w celu uruchomienia kopii zapasowej.

Łączenie sieci wirtualnych

Typowa architektura wdrażania dedykowanego modułu HSM rozpocznie się od jednej sieci wirtualnej i odpowiedniej podsieci, w której są tworzone i aprowidowane urządzenia HSM. W tym samym regionie mogą istnieć dodatkowe sieci wirtualne i podsieci dla składników aplikacji, które będą korzystać z dedykowanego modułu HSM. Aby umożliwić komunikację między tymi sieciami, używamy komunikacji równorzędnej sieci wirtualnych.

Komunikacja równorzędna sieci wirtualnej

Jeśli istnieje wiele sieci wirtualnych w regionie, które muszą uzyskiwać dostęp do zasobów, komunikacja równorzędna sieci wirtualnych może służyć do tworzenia bezpiecznych kanałów komunikacyjnych 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 świadczenia usługi 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 trybu failover o wysokiej dostępności wymagane jest łą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?

Ograniczenia dotyczące sieci

Karta sieciowa modułu HSM, która znajduje się w dedykowanej sieci wirtualnej modułu HSM, nie może używać sieciowych grup zabezpieczeń ani tras zdefiniowanych przez użytkownika. Oznacza to, że nie można ustawić zasad odmowy domyślnej z punktu widzenia dedykowanej sieci wirtualnej modułu HSM i że inne segmenty sieci muszą być dozwolone, aby uzyskać dostęp do dedykowanej usługi HSM.

Dodanie rozwiązania serwera proxy wirtualnego urządzenia sieciowego (WUS) umożliwia również logiczne umieszczenie zapory urządzenia WUS w koncentratorze tranzytowym/DMZ przed kartą sieciową 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. Tranzyt lub sieć wirtualna centrum DMZ z warstwą serwera proxy urządzenia WUS. W idealnym przypadku znajdują się co najmniej dwa urządzenia WUS.
2. Obwód usługi ExpressRoute z włączoną prywatną komunikacją równorzędną i połączeniem z siecią wirtualną koncentratora tranzytowego.
3. Komunikacja równorzędna sieci wirtualnych między siecią wirtualną koncentratora tranzytowego a dedykowaną siecią wirtualną HSM.
4. Zaporę urządzenia WUS lub usługę Azure Firewall można wdrożyć w centrum jako opcję.
5. Dodatkowe sieci wirtualne będące szprychami obciążenia mogą być równorzędne z siecią wirtualną piasty. Klient Gemalto może uzyskać dostęp do dedykowanej usługi HSM za pośrednictwem sieci wirtualnej koncentratora.

Ponieważ dodanie rozwiązania serwera proxy urządzenia WUS umożliwia również logiczne umieszczenie zapory urządzenia WUS w centrum tranzytowym/DMZ przed kartą sieciową HSM, zapewniając w ten sposób wymagane zasady odmowy domyślnej. W naszym przykładzie użyjemy usługi Azure Firewall do tego celu i będą potrzebne następujące elementy:

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 modułu równoważenia obciążenia platformy Azure do usługi Azure Firewall. Ta tabela routingu zostanie zastosowana 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 IBL platformy Azure nasłuchując na porcie TCP 1792. Ta logika zabezpieczeń doda niezbędne zasady odmowy domyślnej względem dedykowanej usługi HSM. Oznacza to, że tylko zaufane zakresy źródłowych adresów IP będą dozwolone w dedykowanej usłudze HSM. Wszystkie inne zakresy zostaną porzucone.
4. Tabela routingu z trasą zdefiniowaną przez użytkownika kierująca ruch kierowany do lokalnego ruchu do usługi Azure Firewall. Ta tabela routingu zostanie zastosowana do podsieci serwera proxy urządzenia WUS.
5. Sieciowa grupa zabezpieczeń zastosowana do podsieci wirtualnego urządzenia sieciowego serwera proxy w celu zaufania tylko zakresowi podsieci usługi Azure Firewall jako źródła i zezwala na przekazywanie tylko do adresu IP karty sieciowej modułu HSM za pośrednictwem portu TCP 1792.

Alternatywa dla tras zdefiniowanych przez użytkownika

Rozwiązanie warstwy urządzenia WUS wymienione powyżej 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 w urządzeniu WUS, aby umożliwić prawidłowe kierowanie ruchu powrotnego.
2. Klienci powinni wyłączyć sprawdzanie adresu IP klienta w konfiguracji modułu HSM Luna, aby używać sieci VNA dla translatora adresów sieciowych. 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)

3. Wdrażanie tras zdefiniowanych przez użytkownika dla ruchu przychodzącego do warstwy urządzenia WUS.
4. Zgodnie z projektem podsieci HSM nie będą inicjować żądania połączenia wychodzącego do warstwy platformy.

Alternatywa dla korzystania z globalnej komunikacji równorzędnej sieci wirtualnych

Istnieje kilka architektur, których można użyć jako alternatywy dla globalnej komunikacji równorzędnej sieci wirtualnych.

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

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

Następne kroki

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