Fő szuverenitás, rendelkezésre állás, teljesítmény és méretezhetőség a felügyelt HSM-ben
A titkosítási kulcsok a modern számítógépes rendszerek biztonságának gyökerét képezik, akár a helyszínen, akár a felhőben. Ezért a biztonságos és megfelelő alkalmazások létrehozásához elengedhetetlen annak szabályozása, hogy kinek van jogosultsága ezekre a kulcsokra.
Az Azure-ban a felhőben történő kulcskezelés kulcsfontosságú szuverenitás. A kulcselkonvertitás azt jelenti, hogy az ügyfél szervezete teljes körűen és kizárólagosan szabályozhatja, hogy ki férhet hozzá a kulcsokhoz, és módosíthatja a kulcskezelési szabályzatokat, és hogy az Azure-szolgáltatások mire használhatják ezeket a kulcsokat. Miután ezeket a döntéseket az ügyfél hozta, a Microsoft személyzete technikai eszközökkel nem módosíthatja ezeket a döntéseket. A kulcskezelési szolgáltatás kódja addig hajtja végre az ügyfél döntéseit, amíg az ügyfél nem utasítja arra, hogy másképp tegyen, és a Microsoft személyzete nem tud beavatkozni.
Ugyanakkor meggyőződésünk, hogy a felhőben minden szolgáltatást teljes mértékben felügyelni kell. A szolgáltatásnak biztosítania kell a szükséges rendelkezésre állást, rugalmasságot, biztonságot és felhőbeli alapvető ígéreteket, amelyeket szolgáltatásiszint-szerződések (SLA-k) is alátámasztanak. A felügyelt szolgáltatás biztosításához a Microsoftnak ki kell javítania a kulcskezelő kiszolgálókat, frissítenie kell a hardveres biztonsági modul (HSM) belső vezérlőprogramját, meg kell javítania a hibás hardvereket, feladatátvételeket kell végrehajtania, és egyéb magas jogosultsági szintű műveleteket kell végrehajtania. Ahogy a legtöbb biztonsági szakember tudja, nehéz feladat megtagadni egy olyan személytől, aki magas jogosultsággal vagy fizikai hozzáféréssel rendelkezik a rendszeren belüli adatokhoz való hozzáféréshez.
Ez a cikk azt ismerteti, hogyan oldottuk meg ezt a problémát az Azure Key Vault felügyelt HSM szolgáltatásban, így az ügyfelek teljes kulcsú szuverenitást és teljes körűen felügyelt szolgáltatási SLA-kat is használhatnak a HSM-ekkel párosított bizalmas számítástechnikai technológia használatával.
Felügyelt HSM hardverkörnyezet
Az ügyfél felügyelt HSM-készlete bármely Azure-régióban biztonságos Azure-adatközpontban található. Három példány több kiszolgálón is el van osztva. Minden példány egy másik állványon van üzembe helyezve a redundancia biztosítása érdekében. Minden kiszolgáló rendelkezik egy FIPS 140-2 Level 3 ellenőrzött Marvell LiquidSecurity HSM-adapterrel több titkosítási maggal. A magok teljesen izolált HSM-partíciók létrehozására szolgálnak, beleértve a teljesen izolált hitelesítő adatokat, az adattárolást és a hozzáférés-vezérlést.
Az adatközpontban lévő példányok fizikai elkülönítése kritikus fontosságú annak biztosításához, hogy egyetlen összetevő (például az állvány felső kapcsolója vagy egy állvány energiagazdálkodási egysége) elvesztése ne befolyásolja a készlet összes példányát. Ezek a kiszolgálók az Azure Security HSM csapatának vannak szentelve. A kiszolgálók nincsenek megosztva más Azure-csapatokkal, és ezeken a kiszolgálókon nincsenek üzembe helyezve ügyfélterhelések. A fizikai hozzáférés-vezérlést, beleértve a zárolt állványokat is, a kiszolgálókhoz való jogosulatlan hozzáférés megakadályozására használják. Ezek a vezérlők megfelelnek a FedRAMP-High, a PCI, a SOC 1/2/3, az ISO 270x és más biztonsági és adatvédelmi szabványoknak, és az Azure megfelelőségi program részeként rendszeresen egymástól függetlenül ellenőrzik őket. A HSM-eknek fokozott fizikai biztonságuk van, amely a FIPS 140-2 3. szintű követelményeinek való megfelelés érdekében lett érvényesítve. A teljes felügyelt HSM-szolgáltatás a szabványos biztonságos Azure-platformra épül, beleértve a megbízható indítást is, amely védelmet nyújt a fejlett állandó fenyegetések ellen.
A HSM-adapterek több tucat izolált HSM-partíciót támogatnak. Az egyes kiszolgálókon való futtatás egy Node Service nevű vezérlőfolyamat. A Node Service átveszi az egyes adapterek tulajdonjogát, és telepíti az adapter tulajdonosának hitelesítő adatait, ebben az esetben a Microsoftot. A HSM úgy lett kialakítva, hogy az adapter tulajdonjoga ne biztosítsa a Microsoft számára az ügyfélpartíciókban tárolt adatokhoz való hozzáférést. Ez lehetővé teszi, hogy csak a Microsoft hozzon létre, méretezze át és törölje az ügyfélpartíciókat. Támogatja az ügyfél bármely partíciójának vak biztonsági mentését. Vak biztonsági mentés esetén a biztonsági mentést egy ügyfél által biztosított kulcs burkolja, amelyet a szolgáltatáskód csak az ügyfél tulajdonában lévő felügyelt HSM-példányon belül állíthat vissza, és amelynek tartalma nem olvasható a Microsoft által.
Felügyelt HSM-készlet architektúrája
Az 1. ábra egy HSM-készlet architektúráját mutatja be, amely három Linux rendszerű virtuális gépből áll, amelyek mindegyike egy HSM-kiszolgálón fut a saját adatközponti állványán a rendelkezésre állás támogatásához. A fontos összetevők a következők:
- A HSM hálóvezérlő (HFC) a szolgáltatás vezérlősíkja. A HFC automatikus javításokat és javításokat hajt a készlethez.
- FiPS 140-2 3. szintű titkosítási határ, amely minden ügyfél számára kizárólagos, beleértve három Intel Secure Guard-bővítményt (Intel SGX) bizalmas enklávét, amelyek mindegyike egy HSM-példányhoz csatlakozik. Ennek a határnak a gyökérkulcsait a rendszer a három HSM-ben hozza létre és tárolja. Ahogy a cikk későbbi részében ismertetjük, a Microsofthoz társított személyek nem férhetnek hozzá az ezen a határokon belül található adatokhoz. Csak az Intel SGX enklávéban (beleértve a Node Service-ügynököt) futó szolgáltatáskód rendelkezik hozzáféréssel, amely az ügyfél nevében jár el.
Megbízható végrehajtási környezet (T Enterprise kiadás)
A felügyelt HSM-készlet három szolgáltatáspéldányból áll. Minden szolgáltatáspéldány egy megbízható végrehajtási környezetként (T Enterprise kiadás) van implementálva, amely Intel SGX-képességeket és open Enclave SDK-t használ. A T Enterprise kiadás belüli végrehajtás biztosítja, hogy a szolgáltatást üzemeltető virtuális gépen vagy a virtuális gép gazdakiszolgálóján senki sem fér hozzá az ügyfél titkos kulcsaihoz, adataihoz vagy HSM-partícióihoz. Minden T Enterprise kiadás egy adott ügyfélnek van szentelve, és TLS-kezelést, kéréskezelést és hozzáférés-vezérlést futtat a HSM-partíción. A T Enterprise kiadás kívül nem találhatók hitelesítő adatok vagy ügyfélspecifikus adattitkosítási kulcsok, kivéve a biztonsági tartománycsomag részét. Ez a csomag egy ügyfél által megadott kulccsal van titkosítva, és a készlet első létrehozásakor tölt le.
A T Enterprise kiadás az igazolt TLS használatával kommunikálnak egymás között. Az igazolt TLS egyesíti az Intel SGX platform távoli igazolási képességeit a TLS 1.2-vel. Ez lehetővé teszi, hogy a T Enterprise kiadás felügyelt HSM-kódja csak az ugyanazon felügyelt HSM szolgáltatás kódaláíró kulccsal aláírt más kódra korlátozza a kommunikációt, hogy megelőzze a középen belüli támadásokat. A felügyelt HSM szolgáltatás kódaláíró kulcsát a Microsoft termékkiadási és biztonsági szolgáltatás tárolja (amely a Windows kódaláíró kulcs tárolására is használható). A kulcsot a felügyelt HSM-csapat vezérli. A változáskezelésre vonatkozó szabályozási és megfelelőségi kötelezettségeink részeként ezt a kulcsot semmilyen más Microsoft-csapat nem használhatja a kód aláírásához.
A T Enterprise kiadás-to-T Enterprise kiadás kommunikációhoz használt TLS-tanúsítványokat a T Enterprise kiadás szolgáltatáskódja állítja ki. A tanúsítványok egy platformjelentést tartalmaznak, amelyet az Intel SGX enklávéja hoz létre a kiszolgálón. A platformjelentés olyan kulcsokkal van aláírva, amelyek az Intel által a processzorba egyesített kulcsokból származnak a gyártás során. A jelentés azonosítja az Intel SGX-enklávéba a kódaláíró kulccsal és bináris kivonattal betöltött kódot. Ebből a platformjelentésből a szolgáltatáspéldányok megállapíthatják, hogy a társ a felügyelt HSM szolgáltatás kódaláíró kulcsával is alá van-e írva, és a platformjelentésen keresztüli titkosítási összefonódással azt is megállapíthatja, hogy az önkibocsátó tanúsítvány-aláíró kulcsot is létre kell hozni a T Enterprise kiadás belül, hogy megakadályozza a külső megszemélyesítést.
Rendelkezésre állási SLA-k teljes ügyfél által felügyelt kulcsvezérléssel
A magas rendelkezésre állás biztosítása érdekében a HFC szolgáltatás három készletet hoz létre az ügyfél által kiválasztott Azure-régióban.
Felügyelt HSM-készlet létrehozása
A felügyelt HSM-készletek magas rendelkezésre állási tulajdonságai az automatikusan felügyelt, háromszoros redundáns HSM-példányokból származnak, amelyek mindig szinkronban vannak (vagy többrégiós replikáció használata esetén mind a hat példány szinkronban tartásától). A készlet létrehozását a HFC szolgáltatás felügyeli, amely a készleteket az ügyfél által választott Azure-régióban elérhető hardverek között foglalja le.
Új készlet kérése esetén a HFC három kiszolgálót választ ki több állványon, amelyeken rendelkezésre áll hely a HSM-adaptereken, majd elkezdi létrehozni a készletet:
A HFC arra utasítja a Node Service-ügynököket a három T Enterprise kiadás mindegyikén, hogy egy paraméterkészlettel indítsa el a szolgáltatáskód új példányát. A paraméterek azonosítják az ügyfél Microsoft Entra-bérlőjét, mindhárom példány belső virtuális hálózati IP-címét és néhány egyéb szolgáltatáskonfigurációt. Egy partíció véletlenszerűen van hozzárendelve elsődlegesként.
A három példány elkezdődik. Minden példány csatlakozik egy partícióhoz a helyi HSM-adapteren, majd véletlenszerűen létrehozott felhasználónevek és hitelesítő adatok használatával nulláz és inicializálja a partíciót (hogy a partíciót ne férhesse hozzá egy emberi operátor vagy egy másik T Enterprise kiadás-példány).
Az elsődleges példány létrehoz egy partíciótulajdonosi főtanúsítványt a HSM-ben létrehozott titkos kulcs használatával. Ezzel a főtanúsítvánnyal létrehozza a készlet tulajdonjogát egy partíciószintű tanúsítvány aláírásával a HSM-partícióhoz. Az elsődleges egy adattitkosítási kulcsot is létrehoz, amely a szolgáltatáson belül inaktív összes ügyféladat védelmére szolgál. Kulcsanyagok esetében dupla burkolást használunk, mivel a HSM magát a kulcsanyagot is védi.
Ezt követően a tulajdonosi adatok szinkronizálódnak a két másodlagos példányra. Minden másodlagos kapcsolatba lép az elsődlegessel az igazolt TLS használatával. Az elsődleges a partíciótulajdonos főtanúsítványát a titkos kulccsal és az adattitkosítási kulccsal osztja meg. A másodfokok most már a partíció főtanúsítványával bocsátanak ki partíciótanúsítványt a saját HSM-partícióikra. A művelet befejezése után hSM-partíciókkal rendelkezik három különálló kiszolgálón, amelyek ugyanazon partíció főtanúsítványának tulajdonában vannak.
Az igazolt TLS-kapcsolaton keresztül az elsődleges HSM-partíció megosztja a másodlagosakkal a létrehozott adatburkoló kulcsot (amely a három HSM közötti üzenetek titkosítására szolgál) a HSM-szállító által biztosított biztonságos API használatával. A csere során a HSM-ek megerősítik, hogy ugyanazzal a partíciótulajdonosi tanúsítvánnyal rendelkeznek, majd egy Diffie-Hellman sémával titkosítják az üzeneteket, hogy a Microsoft szolgáltatáskódja ne tudja elolvasni őket. A szolgáltatáskód csak átlátszatlan blobok átvitelére képes a HSM-ek között.
Ezen a ponton mindhárom példány készen áll arra, hogy készletként legyen közzétéve az ügyfél virtuális hálózatán. Ugyanazzal a partíciótulajdonosi tanúsítvánnyal és titkos kulccsal, ugyanazzal az adattitkosítási kulccsal és egy közös adatburkoló kulccsal rendelkeznek. Azonban minden példány egyedi hitelesítő adatokkal rendelkezik a HSM-partíciókhoz. Most az utolsó lépések befejeződnek.
Minden példány létrehoz egy RSA-kulcspárt és egy tanúsítvány-aláírási kérést (CSR) a nyilvános elérésű TLS-tanúsítványhoz. A CSR-t a Microsoft nyilvános kulcsú infrastruktúra (PKI) rendszere egy Nyilvános Microsoft-gyökér használatával írja alá, és az eredményül kapott TLS-tanúsítványt a rendszer visszaadja a példánynak.
Mindhárom példány saját Intel SGX tömítőkulcsot szerez be a helyi CPU-ból. A kulcs a cpu saját egyedi kulcsával és a T Enterprise kiadás kódaláíró kulcsával jön létre.
A készlet egy egyedi készletkulcsot hoz létre az Intel SGX tömítőkulcsaiból, titkosítja az összes titkos kulcsát ezzel a készletkulcskal, majd a titkosított blobokat lemezre írja. Ezek a blobok csak úgy fejthetők vissza, ha ugyanazzal az Intel SGX tömítési kulccsal aláírják a kódot, amely ugyanazon a fizikai CPU-n fut. A titkos kódok az adott példányhoz vannak kötve.
A biztonságos rendszerindítási folyamat befejeződött. Ez a folyamat lehetővé tette a három redundáns HSM-készlet létrehozását és az ügyféladatok szuverenitásának titkosítási garanciájának létrehozását.
Rendelkezésre állási SLA-k fenntartása futtatókörnyezetben bizalmas szolgáltatásjavítással
A cikkben ismertetett készletlétrehozási történetből megtudhatja, hogy a felügyelt HSM szolgáltatás hogyan képes magas rendelkezésre állású SLA-kat biztosítani a szolgáltatás alapjául szolgáló kiszolgálók biztonságos felügyeletével. Tegyük fel, hogy egy kiszolgáló, egy HSM-adapter vagy akár az állvány tápegysége meghibásodik. A felügyelt HSM szolgáltatás célja, hogy a T Enterprise kiadás-n kívül minden ügyfél beavatkozása vagy titkos kódok felfedése nélkül három kifogástalan állapotú példányra gyógyítani lehessen a készletet. Ez a szolgáltatás bizalmas kezelésével érhető el.
Azzal kezdődik, hogy a HFC észleli, hogy mely készletek példányai voltak a sikertelen kiszolgálón. A HFC új, kifogástalan állapotú kiszolgálókat talál a készlet régiójában a cserepéldányok üzembe helyezéséhez. Elindítja az új példányokat, amelyeket a kezdeti üzembe helyezési lépés során pontosan másodlagosként kezel: inicializálja a HSM-et, megkeresi az elsődleges, biztonságosan kicserélt titkos kulcsokat az igazolt TLS-en keresztül, aláírja a HSM-et a tulajdonosi hierarchiába, majd lezárja a szolgáltatásadatokat az új CPU-ba. A szolgáltatás mostantól teljesen automatikusan és teljes mértékben bizalmasan gyógyul.
Vészhelyreállítás a biztonsági tartomány használatával
A biztonsági tartomány egy biztonságos blob, amely tartalmazza a HSM-partíció alapoktól való újraépítéséhez szükséges összes hitelesítő adatot: a partíció tulajdonoskulcsát, a partíció hitelesítő adatait, az adatburkoló kulcsot, valamint a HSM kezdeti biztonsági mentését. A szolgáltatás aktiválása előtt az ügyfélnek le kell töltenie a biztonsági tartományt a biztonságossá tételéhez szükséges RSA-titkosítási kulcsok készletével. A biztonsági tartomány adatai a T Enterprise kiadás-ból származnak, és egy generált szimmetrikus kulcs és a Shamir titkos megosztó algoritmusának implementációja védi, amely a kulcsmegosztásokat az ügyfél által megadott RSA nyilvános kulcsokra osztja fel az ügyfél által kiválasztott kvórumparaméterek szerint. A folyamat során a szolgáltatáskulcsok és a hitelesítő adatok soha nem jelennek meg egyszerű szövegben a T Enterprise kiadás-ben futó szolgáltatáskódon kívül. Csak az ügyfél tudja visszafejteni a biztonsági tartományt a helyreállítási forgatókönyv során, ha az RSA-kulcsok kvórumát jeleníti meg a T Enterprise kiadás.
A biztonsági tartományra csak akkor van szükség, ha valamilyen katasztrófa miatt egy teljes Azure-régió elveszik, és a Microsoft egyszerre elveszíti a készlet mindhárom példányát. Ha csak egy példány, vagy akár két példány is elveszik, akkor a bizalmas szolgáltatások helyreállítása három kifogástalan állapotú példányra, ügyfél beavatkozás nélkül, csendesen helyreáll. Ha a teljes régió elveszik, mivel az Intel SGX tömítőkulcsai egyediek az egyes processzorokban, a Microsoft nem tudja helyreállítani a HSM hitelesítő adatait és a partíció tulajdonosi kulcsait. Ezek csak a példányok környezetében léteznek.
Abban a rendkívül valószínűtlen esetben, amikor ez a katasztrófa bekövetkezik, az ügyfél helyreállíthatja a készlet korábbi állapotát és adatait egy új üres készlet létrehozásával, a biztonsági tartományba való injektálásával, majd az RSA-kulcs kvórumának bemutatásával bizonyíthatja a biztonsági tartomány tulajdonjogát. Ha egy ügyfél engedélyezte a többrégiós replikációt, az egyidejűleg tapasztalt mindkét régió még valószínűtlenebb katasztrófája teljes hibára lenne szükség, mielőtt az ügyfél beavatkozására lenne szükség a készlet biztonsági tartományból való helyreállításához.
A szolgáltatáshoz való hozzáférés szabályozása
A leírtaknak megfelelően a T Enterprise kiadás szolgáltatáskódja az egyetlen olyan entitás, amely hozzáfér magához a HSM-hez, mert a szükséges hitelesítő adatokat nem adja meg az ügyfélnek vagy bárki másnak. Ehelyett az ügyfél készlete a Microsoft Entra-példányhoz van kötve, és ezt használják hitelesítéshez és engedélyezéshez. A kezdeti üzembe helyezéskor az ügyfél kiválaszthatja az alkalmazottak egy kezdeti készletét a készlet Rendszergazda istrator szerepkörének hozzárendeléséhez. Ezek a személyek és az ügyfél Microsoft Entra-bérlői globális Rendszergazda istrator szerepkörében dolgozó alkalmazottak hozzáférés-vezérlési szabályzatokat állíthatnak be a készleten belül. A szolgáltatás minden hozzáférés-vezérlési szabályzatot ugyanabban az adatbázisban tárol, mint a maszkolt kulcsokat, amelyek szintén titkosítva vannak. Csak a T Enterprise kiadás szolgáltatáskódja rendelkezik hozzáféréssel ezekhez a hozzáférés-vezérlési szabályzatokhoz.
Summary
A felügyelt HSM-nek nincs szüksége arra, hogy az ügyfelek kompromisszumot tegyenek a rendelkezésre állás és a titkosítási kulcsok feletti vezérlés között élvonalbeli, hardveralapú, bizalmas enklávé technológiával. A jelen cikkben leírtak szerint ebben a megvalósításban egyetlen Microsoft-munkatárs vagy képviselő sem férhet hozzá az ügyfél által felügyelt kulcsanyagokhoz vagy a kapcsolódó titkos kódokhoz, még a felügyelt HSM-gazdagépekhez és HSM-ekhez való fizikai hozzáféréssel is. Ez a biztonság lehetővé tette ügyfeleink számára a pénzügyi szolgáltatások, a gyártás, a közszféra, a védelem és más vertikális területek területén, hogy teljes bizalommal felgyorsítsák a felhőbe való migrálásukat.