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 zapewnia to i istnieją cztery odrębne obszary, które należy rozwiązać.

• Tworzenie urządzeń HSM wewnątrz Virtual Network (VNet) 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 w celu komunikacji między nimi, a także umożliwienie scenariuszy wysokiej dostępności

Sieć wirtualna dla dedykowanych modułów HSM

Dedykowane moduły HSM są zintegrowane z Virtual Network 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ć Virtual Network na platformie Azure lub użyć go, który już istnieje w subskrypcji klientów. Sieć wirtualna definiuje obwód zabezpieczeń dla 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 User-Defined (UDR) nie są obecnie obsługiwane w podsieciach delegowanych. W związku z tym po delegowaniu podsieci do dedykowanych modułów HSM można go używać 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 jest podsieć dedykowanego modułu HSM, jednak każde urządzenie HSM będzie używać jednego prywatnego adresu IP, dlatego należy się upewnić, ż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 lokalnego 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, taki jak pojedyncza stacja robocza administracyjna. Aby uzyskać więcej informacji na temat opcji łączności, zobacz VPN Gateway opcje planowania.

Uwaga

Obecnie usługa ExpressRoute nie jest opcją połączenia z zasobami lokalnymi. Należy również zauważyć, że brama usługi ExpressRoute używana zgodnie z powyższym opisem nie jest przeznaczona dla 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 zamierzasz mieć tylko jedną stację roboczą administracyjną dla dedykowanych modułów HSM opartych na platformie Azure.

Sieć VPN typu lokacja-lokacja

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

Łączenie sieci wirtualnych

Typowa architektura wdrażania dedykowanego modułu HSM rozpoczyna się od jednej sieci wirtualnej i odpowiedniej podsieci, w której tworzone i aprowizowane są 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 Virtual Network komunikacji równorzędnej.

Komunikacja równorzędna sieci wirtualnej

Jeśli istnieje wiele sieci wirtualnych w regionie, które wymagają dostępu do zasobów innych, Virtual Network komunikację równorzędną można 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 małe opóźnienia i połączenia o 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, jeśli urządzenia nie powiedzą się lub utracą dostęp 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 aplikacji rozproszonych globalnie lub dla regionalnych scenariuszy trybu failover o wysokiej dostępności wymagane jest łączenie sieci wirtualnych między regionami. Dzięki dedykowanemu modułowi HSM platformy Azure można osiągnąć wysoką dostępność przy użyciu VPN Gateway, który zapewnia bezpieczny tunel między dwiema sieciami wirtualnymi. Aby uzyskać więcej informacji na temat połączeń między sieciami wirtualnymi przy użyciu VPN Gateway, zobacz artykuł zatytułowany Co to jest VPN Gateway?

Uwaga

Globalna komunikacja równorzędna sieci wirtualnych nie jest dostępna w scenariuszach łączności między regionami z dedykowanymi modułami HSM w tej chwili, a zamiast tego należy użyć bramy sieci VPN.

Ograniczenia dotyczące sieci

Uwaga

Ograniczenie dedykowanej usługi HSM korzystającej z delegowania podsieci jest nakładane na ograniczenia, które należy wziąć pod uwagę podczas projektowania docelowej architektury sieci dla wdrożenia modułu HSM. Użycie delegowania podsieci oznacza, że sieciowe grupy zabezpieczeń, trasy zdefiniowane przez użytkownika i globalna komunikacja równorzędna sieci wirtualnych nie są obsługiwane w przypadku dedykowanego modułu HSM. W poniższych sekcjach przedstawiono pomoc dotyczącą alternatywnych technik w celu osiągnięcia tego samego lub podobnego wyniku dla tych możliwości.

Karta sieciowa 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 (NVA) 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. Sieć wirtualna koncentratora DMZ z warstwą serwera proxy urządzenia WUS. W idealnym przypadku znajdują się dwa lub więcej urządzeń 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ą modułu HSM.
4. Zapora urządzenia WUS lub Azure Firewall można wdrożyć usługi DMZ 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 Azure Firewall w tym celu i będą potrzebne następujące elementy:

1. Azure Firewall wdrożona w podsieci "AzureFirewallSubnet" w sieci wirtualnej koncentratora DMZ
2. Tabela routingu z trasą zdefiniowaną przez użytkownika kierująca ruch do prywatnego punktu końcowego modułu równoważenia obciążenia platformy Azure do 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 usługi Azure IBL nasłuchujący na porcie TCP 1792. Ta logika zabezpieczeń spowoduje dodanie niezbędnych zasad "odmowy domyślnej" względem dedykowanej usługi HSM. Oznacza to, że tylko zaufane źródłowe zakresy 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 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 w celu zaufania tylko zakresowi podsieci Azure Firewall jako źródła i zezwalaniu tylko na przekazywanie dalej do adresu IP karty sieciowej modułu HSM za pośrednictwem portu TCP 1792.

Uwaga

Ponieważ warstwa serwera proxy urządzenia WUS będzie SNAT adres IP klienta, gdy przekazuje do karty sieciowej modułu HSM, między siecią wirtualną modułu HSM a siecią wirtualną koncentratora DMZ nie są wymagane żadne trasy zdefiniowane przez użytkownika.

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 na urządzeniu WUS w celu umożliwienia prawidłowego kierowania ruchu powrotnego.
2. Klienci powinni wyłączyć konfigurację modułu HSM luna ip zaewidencjonowania klienta w celu używania sieci wirtualnej 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 VPN Gateway między sieciami wirtualnymi
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