Partner HSM-hozzáférése VPN-en át: határozza meg a kulcsműveleteket

A partnernél valakinek egy kijelölt kulccsal alá kell írnia egy dokumentumot, és a kérés hálózati problémaként érkezik: el kell érniük a HSM-et. Ezt a mondatot egy meghatározatlan szolgáltatási szerződés tünetének tekintse, nem útvonalválasztási problémának, mert az eszközhöz érő alagút önmagában semmit nem ad. Három kapu áll a kérés mögött: elérhetőség, HSM-identitás és kulcspolitika, és mindegyiket más helyen, más csapat igazgatja. Írja le őket egyenként, különben útvonalat ad, mert a tanúsítványról szóló beszélgetés nehezebb volt.

Tartsa szem előtt a konkrét esetet: a partner egy megnevezett kulccsal aláírásra jóváhagyott dokumentumot küld be, és semmi mást. Minden lentebb ebből az egyetlen mondatból következik.

Az elérhetőség, az identitás és a kulcspolitika három kapu

A VPN-koncentrátor dönti el, ki nyithat alagutat, és mely címeket érintheti. A HSM maga dönti el, hogy az elé kerülő felhasználói rekordok közül melyik jelentkezhet be. A kulcspolitika ezután dönti el, hogy az a felhasználói rekord mit tehet egy adott kulccsal. Az első kapun való átjutás a másik kettőt pontosan úgy hagyja, ahogy volt, ezért bizonyít olyan keveset egy sikeres kézfogás, és ezért érheti el a partner az eszközt, mégis minden műveletnél elbukhat.

Rendeljen tulajdonost minden kapuhoz, mielőtt követelményeket ír. Ha a másodiknak nincs tulajdonosa, a szokásos eredmény az, hogy széles HSM-rendszergazda identitást osztanak ki, mert csak az az egyetlen hitelesítő adat működik.

Első kapu: a partnernek adott hálózati útvonal

Nevezze meg a jóváhagyott klienst vagy szolgáltatást, a szükséges célt, valamint a protokollt és portot, amelyen az a szolgáltatás figyel. Ezután korlátozza a VPN felőli hozzáférést erre a párra mindkét irányban, a visszaúttal együtt, hogy a politika egy olyan mondat legyen, amelyet vissza tud olvasni a partnernek. Az átjáró adminisztrációjának, a HSM kezelési felületeinek és a nem kapcsolódó belső rendszereknek a szokásos partnerhozzáférésen kívül kell lenniük, nem csupán az alapértelmezett útvonalon kívül.

A dedikált szegmens láthatóvá teszi ezeket az átkeléseket, de a szegmens neve semmit nem kényszerít ki. A forgalomnak át kell haladnia azon a kontrollon, amelyen ön szerint áthalad. A partner felőli kapcsolat engedélyezése az sem jelenti, hogy a partner minden gépe megbízható.

Második kapu: mi hitelesít valójában a HSM felé

A VPN-identitás és a HSM-identitás külön objektumok, kivéve, ha egy támogatott integráció szándékosan összekapcsolja őket. PKCS#11-klienssel az alkalmazás egy slot ellen jelentkezik be a partner hosztján valahol tárolt hitelesítő adattal, és a HSM ezt a bejelentkezést értékeli.

Az AWS CloudHSM hasznos hivatkozás, mert dokumentációja külön tartja a kettőt: a HSM-felhasználók különböznek az IAM-felhasználóktól, és a felhasználói típus határozza meg, mit tehet a fiók. A kripto tisztviselő felhasználókat és kulcsokat kezel, de nem ő az az identitás, amely a kriptográfiai műveleteket végzi, míg a kripto felhasználó használhat kulcsokat anélkül, hogy kezelni tudná őket. Ez a felosztás az a forma, amelyet ön más gyártó eszközén is szeretne, ahol a szerepkörök neve eltér majd.

Bármilyen identitást ad ki, annak eltávolíthatónak és olyan részletességgel visszakövethetőnek kell lennie, amilyenre később szüksége lesz. Egy megosztott operatív hitelesítő adat több partnernél éppen abban az incidensben nehezíti a körülhatárolást és az elszámoltathatóságot, amelyben mindkettő a legfontosabb.

Harmadik kapu: melyik kulcs, és melyik művelet

Az aláírás, a visszafejtés, a kulcsgenerálás, a kulcsbecsomagolás és a felhasználókezelés külön jogosultságok, és külön kell felsorolni őket. PKCS#11 fogalmakkal az olyan attribútumok, mint a CKA_SENSITIVE és a CKA_EXTRACTABLE írják le, hogy a kulcsanyag használható formában elhagyhatja-e a modult, és ezeket kulcsonként, nem eszközönként állítják be. Olvassa el a kulcson lévő tényleges politikát, ahelyett hogy a nem exportálhatóságra a hardver szóból vagy egy alagút jelenlétéből következtetne.

Aztán keresse meg az üzleti jóváhagyást. Ha csak jóváhagyott dokumentumokat lehet aláírni, melyik komponens állapítja meg ezt a jóváhagyást, mielőtt a kérés eléri a HSM-et? Az engedélyezett kérést elfogadó kriptográfiai felületnek fogalma sincs róla, hogy a dokumentumot átnézték-e, ezért ez az ellenőrzés az előtte álló szolgáltatásé.

Egy engedélyezett ügyfél, amelyet kompromittáltak, vissza is élhet a hitelesítő adata által jogszerűen engedélyezett műveletekkel anélkül, hogy valaha kinyerne egy privát kulcsot. A tárolt kulcsanyag védelme és a kulcshasználat szabályozása ezért két elfogadási feltétel, nem egy.

Az elutasítások az elfogadási teszt részét képezik

Fogadja el az engedélyezett aláírási kérést, és fogadja el az elutasításokat is: a nem engedélyezett identitást, a nem kapcsolódó kulcsot és a partner útvonaláról érkező kezelési műveletet. Rögzítse a hívót, a műveletet, a kulcs azonosítóját, az időpontot és az eredményt, a privát kulcsanyagot, a hitelesítő adatokat és a dokumentumok tartalmát pedig tartsa távol az általános diagnosztikai naplóktól.

Rendeljen tulajdonost a partner kilépéséhez, a partner oldalán gyanított kompromittálódáshoz, valamint a politikai változásokhoz és a helyreállításhoz. Az útvonal megváltoztatása nem állítja vissza a bizalmat egy esetleg már kompromittált hosztban, ezért a visszavonásnak a HSM-identitást is el kell érnie.

A befejezett VPN-kézfogás annak a feljegyzésnek a része. Nem helyettesíthet egyetlen HSM-specifikus eredményt sem.