Azure Dedikált HSM-hálózatkezelés
Az Azure Dedikált HSM-hez rendkívül biztonságos hálózati környezet szükséges. Ez igaz akár az Azure-felhőből az ügyfél informatikai környezetére (helyszíni), elosztott alkalmazások használatával, akár magas rendelkezésre állású forgatókönyvek esetén. Az Azure Networking ezt biztosítja, és négy különböző területet kell kezelni.
- HSM-eszközök létrehozása a virtuális hálózaton (VNet) belül az Azure-ban
- Helyszíni csatlakoztatás felhőalapú erőforrásokhoz a HSM-eszközök konfigurálásához és kezeléséhez
- Virtuális hálózatok létrehozása és csatlakoztatása alkalmazáserőforrásokhoz és HSM-eszközökhöz
- Virtuális hálózatok összekapcsolása régiók között az interkommunikáció érdekében, valamint a magas rendelkezésre állású forgatókönyvek engedélyezése
Virtuális hálózat dedikált HSM-ekhez
A dedikált HSM-ek integrálva vannak egy virtuális hálózatba, és az ügyfelek saját magánhálózatába kerülnek az Azure-ban. Ez lehetővé teszi az eszközök elérését a virtuális hálózaton lévő virtuális gépekről vagy számítási erőforrásokból.
Az Azure-szolgáltatások virtuális hálózatba való integrálásáról és az általa nyújtott képességekről az Azure-szolgáltatások dokumentációjában talál további információt.
Virtuális hálózatok
Dedikált HSM-eszköz kiépítése előtt az ügyfeleknek először létre kell hozniuk egy virtuális hálózatot az Azure-ban, vagy olyant kell használniuk, amely már létezik az ügyfelek előfizetésében. A virtuális hálózat határozza meg a dedikált HSM-eszköz biztonsági szegélyét. A virtuális hálózatok létrehozásával kapcsolatos további információkért tekintse meg a virtuális hálózat dokumentációját.
Alhálózatok
Az alhálózat külön címtartományokra bontja a virtuális hálózatot, amelyeket azok az Azure-erőforrások használhatnak, amelyeket beléjük helyez. A dedikált HSM-eket a rendszer a virtuális hálózat egy alhálózatán helyezi üzembe. Minden dedikált HSM-eszköz, amely az ügyfél alhálózatán van üzembe helyezve, erről az alhálózatról kap egy privát IP-címet. A HSM-eszköz üzembe helyezésének alhálózatát explicit módon delegálni kell a szolgáltatásba: Microsoft.HardwareSecurityModules/dedicatedHSMs. Ez bizonyos engedélyeket ad a HSM szolgáltatásnak az alhálózatba való üzembe helyezéshez. A dedikált HSM-ekre való delegálás bizonyos szabályzatkorlátozásokat vezet be az alhálózatra. A hálózati biztonsági csoportok (NSG-k) és a felhasználó által megadott útvonalak (UDR-ek) jelenleg nem támogatottak a delegált alhálózatokon. Ennek eredményeképpen, ha egy alhálózat dedikált HSM-ekhez van delegálva, csak HSM-erőforrások üzembe helyezésére használható. A többi ügyfélerőforrás alhálózatba való üzembe helyezése sikertelen lesz. Nem követelmény, hogy a dedikált HSM alhálózata mekkora vagy kicsi legyen, azonban minden HSM-eszköz egy privát IP-címet fog használni, ezért gondoskodni kell arról, hogy az alhálózat elég nagy legyen ahhoz, hogy az üzembe helyezéshez szükséges számú HSM-eszközt elférjen.
ExpressRoute-átjáró
A jelenlegi architektúra egyik követelménye egy ExpressRoute-átjáró konfigurálása az ügyfelek alhálózatán, ahol HSM-eszközt kell elhelyezni a HSM-eszköz Azure-ba való integrálásának engedélyezéséhez. Ez az ExpressRoute-átjáró nem használható helyszíni helyek azure-beli HSM-eszközökhöz való csatlakoztatásához.
Helyszíni informatikai eszköz csatlakoztatása az Azure-hoz
Felhőalapú erőforrások létrehozásakor ez egy tipikus követelmény a helyszíni informatikai erőforrásokhoz való privát kapcsolathoz. Dedikált HSM esetén ez elsősorban a HSM-ügyfélszoftver feladata lesz a HSM-eszközök konfigurálásához, valamint olyan tevékenységekhez, mint a biztonsági mentések és a naplók lekérése a HSM-ekből elemzés céljából. Itt a legfontosabb döntési pont a kapcsolat jellege, mivel vannak lehetőségek. A legrugalmasabb megoldás a helyek közötti VPN, mivel valószínűleg több helyszíni erőforrás is lesz, amelyek biztonságos kommunikációt igényelnek az Azure-felhőben lévő erőforrásokkal (beleértve a HSM-eket is). Ehhez az ügyfélszervezetnek VPN-eszközzel kell rendelkeznie a kapcsolat megkönnyítéséhez. Pont–hely VPN-kapcsolat akkor használható, ha csak egyetlen helyszíni végpont, például egyetlen felügyeleti munkaállomás található. A csatlakozási lehetőségekről további információt a VPN Gateway tervezési lehetőségei között talál.
Feljegyzés
Az ExpressRoute jelenleg nem használható helyszíni erőforrásokhoz való csatlakozásra. Azt is meg kell jegyezni, hogy a fent leírt ExpressRoute-átjáró nem a helyszíni infrastruktúrához való csatlakozásra szolgál.
Pont–hely VPN
A pont–hely virtuális magánhálózat az egyetlen helyszíni végponttal létesített biztonságos kapcsolat legegyszerűbb formája. Ez akkor lehet fontos, ha csak egyetlen felügyeleti munkaállomást kíván használni az Azure-alapú dedikált HSM-ekhez.
Helyek közötti VPN
A helyek közötti virtuális magánhálózat biztonságos kommunikációt tesz lehetővé az Azure-alapú dedikált HSM-ek és a helyszíni it-k között. Ennek egyik oka, hogy rendelkezik egy biztonsági mentési létesítménysel a HSM helyszíni példányához, és kapcsolatra van szüksége a kettő között a biztonsági mentés futtatásához.
Virtuális hálózatok csatlakoztatása
A dedikált HSM tipikus üzembehelyezési architektúrája egyetlen virtuális hálózattal és a hozzájuk tartozó alhálózattal kezdődik, amelyben a HSM-eszközök létrejönnek és kiépülnek. Ugyanebben a régióban további virtuális hálózatok és alhálózatok is lehetnek az alkalmazás-összetevők számára, amelyek a dedikált HSM-et használják. A hálózatok közötti kommunikáció engedélyezéséhez a virtuális hálózatok közötti társviszony-létesítést használjuk.
Virtuális hálózati társviszony
Ha egy régióban több virtuális hálózatnak is hozzá kell férnie egymás erőforrásaihoz, a virtuális hálózatok közötti társviszony-létesítéssel biztonságos kommunikációs csatornák hozhatók létre közöttük. A virtuális hálózatok közötti társviszony-létesítés nem csak biztonságos kommunikációt biztosít, hanem alacsony késést és nagy sávszélességű kapcsolatokat is biztosít az Azure-beli erőforrások között.
Csatlakozás azure-régiók között
A HSM-eszközök szoftverkódtárakon keresztül képesek átirányítani a forgalmat egy másik HSM-hez. A forgalom átirányítása akkor hasznos, ha az eszközök meghibásodnak, vagy az eszközhöz való hozzáférés elveszik. A regionális szintű meghibásodási forgatókönyvek a HSM más régiókban való üzembe helyezésével és a régiók közötti virtuális hálózatok közötti kommunikáció engedélyezésével csökkenthetők.
Régiók közötti HA VPN-átjáró használatával
Globálisan elosztott alkalmazások vagy magas rendelkezésre állású regionális feladatátvételi forgatókönyvek esetén a virtuális hálózatokat régiók között kell csatlakoztatni. Az Azure Dedikált HSM-sel magas rendelkezésre állás érhető el egy VPN Gateway használatával, amely biztonságos alagutat biztosít a két virtuális hálózat között. További információ a VPN Gatewayt használó virtuális hálózatok közötti kapcsolatokról: Mi az a VPN Gateway?
Feljegyzés
A globális virtuális hálózatok közötti társviszony-létesítés jelenleg nem érhető el a dedikált HSM-ekkel rendelkező régiók közötti kapcsolati forgatókönyvekben, helyette VPN-átjárót kell használni.
Hálózatkezelési korlátozások
Feljegyzés
Az alhálózat-delegálást használó dedikált HSM-szolgáltatás korlátozása olyan korlátozásokat vezet be, amelyeket figyelembe kell venni a HSM-üzemelő példány célhálózati architektúrájának tervezésekor. Az alhálózat-delegálás használata azt jelenti, hogy a dedikált HSM nem támogatja az NSG-ket, az UDR-eket és a globális virtuális hálózatok közötti társviszony-létesítést. Az alábbi szakaszok segítséget nyújtanak az alternatív technikákkal, hogy azonos vagy hasonló eredményt érjenek el ezekhez a képességekhez.
A dedikált HSM virtuális hálózaton található HSM hálózati adapter nem használhat hálózati biztonsági csoportokat vagy felhasználó által megadott útvonalakat. Ez azt jelenti, hogy nem lehet alapértelmezett megtagadási szabályzatokat beállítani a dedikált HSM virtuális hálózat szempontjából, és hogy más hálózati szegmenseknek engedélyezni kell a dedikált HSM szolgáltatáshoz való hozzáférést.
A hálózati virtuális berendezések (NVA) proxymegoldásának hozzáadása azt is lehetővé teszi, hogy az átviteli/DMZ-központ NVA-tűzfala logikailag a HSM hálózati adaptere elé kerüljön, így biztosítva a szükséges alternatívát az NSG-k és az UDR-ek helyett.
Megoldásarchitektúra
Ehhez a hálózattervezéshez a következő elemek szükségesek:
- Egy NVA-proxyszinttel rendelkező tranzit- vagy DMZ Hub virtuális hálózat. Ideális esetben két vagy több NVA van jelen.
- Egy ExpressRoute-kapcsolatcsoport, amelyen engedélyezve van a privát társviszony-létesítés és a kapcsolat a tranzitközpont virtuális hálózatával.
- Virtuális hálózatok közötti társviszony a tranzitközpont virtuális hálózata és a dedikált HSM virtuális hálózat között.
- Az NVA-tűzfal vagy az Azure Firewall lehetőségként DMZ-szolgáltatásokat kínálhat a központban.
- További küllős számítási feladatok virtuális hálózatai társviszonyban hozhatók létre a központi virtuális hálózattal. A Gemalto-ügyfél a központi virtuális hálózaton keresztül érheti el a dedikált HSM szolgáltatást.
Mivel az NVA-proxymegoldás hozzáadása azt is lehetővé teszi, hogy a tranzit/DMZ hub NVA-tűzfala logikailag a HSM hálózati adapter elé kerüljön, így biztosítva a szükséges alapértelmezett megtagadási házirendeket. A példánkban ehhez az Azure Firewallt fogjuk használni, és a következő elemekre lesz szükség:
- A DMZ hub virtuális hálózatában az "AzureFirewallSubnet" alhálózatban üzembe helyezett Azure Firewall
- Útválasztási táblázat egy UDR-vel, amely az Azure ILB privát végpontja felé haladó forgalmat irányítja az Azure Firewallba. Ez az útválasztási tábla arra a GatewaySubnetre lesz alkalmazva, ahol az ügyfél ExpressRoute virtuális átjárója található
- Az AzureFirewallon belüli hálózati biztonsági szabályok, amelyek lehetővé teszik a megbízható forrástartomány és az Azure IBL privát végpontja közötti továbbítást az 1792-s TCP-porton. Ez a biztonsági logika hozzáadja a szükséges "alapértelmezett megtagadási" szabályzatot a dedikált HSM szolgáltatáshoz. Ez azt jelenti, hogy csak megbízható forrás IP-tartományok lesznek engedélyezve a dedikált HSM szolgáltatásban. Az összes többi tartomány el lesz dobva.
- Útválasztási táblázat egy UDR-vel, amely a helyszíni forgalom felé irányítja az Azure Firewallba. Ez az útválasztási tábla az NVA-proxy alhálózatra lesz alkalmazva.
- A proxy NVA alhálózatára alkalmazott NSG csak az Azure Firewall alhálózati tartományát megbízhatónak minősíti forrásként, és csak az 1792-as TCP-porton keresztül engedélyezi a HSM hálózati adapter IP-címére való továbbítást.
Feljegyzés
Mivel az NVA-proxyszint az ügyfél IP-címét fogja SNAT-ként kezelni a HSM hálózati adapter felé történő továbbításkor, a HSM virtuális hálózat és a DMZ hub virtuális hálózata között nincs szükség UDR-ekre.
Alternatív megoldás az UDR-ek helyett
A fent említett NVA-szintű megoldás az UDR-ek alternatívaként működik. Van néhány fontos megjegyzés.
- A hálózati címfordítást úgy kell konfigurálni az NVA-n, hogy a visszatérési forgalom megfelelően legyen irányítva.
- Az ügyfeleknek le kell tiltania az ügyfél ip-ellenőrzését a Luna HSM konfigurációjában a VNA nat-hoz való használatához. Példaként az alábbi parancsok szolgálnak.
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)
- Az NVA-rétegbe irányuló bejövő forgalom UDR-einek üzembe helyezése.
- Terv szerint a HSM-alhálózatok nem kezdeményeznek kimenő kapcsolatkérést a platformszintre.
Alternatív megoldás a globális virtuális hálózatok közötti társviszony-létesítés használatára
A globális virtuális hálózatok közötti társviszony-létesítés alternatívaként számos architektúra használható.
- Virtuális hálózatok közötti VPN Gateway-kapcsolat használata
- Csatlakoztassa a HSM virtuális hálózatot egy másik virtuális hálózathoz egy ER-kapcsolatcsoporttal. Ez akkor működik a legjobban, ha közvetlen helyszíni elérési útra vagy VPN-alapú virtuális hálózatra van szükség.
HSM közvetlen Express Route-kapcsolattal
