AWS Client VPN: melyik CA adja ki az ügyféltanúsítványokat?

Az AWS Client VPN tanúsítványkérdését termékkérdésként teszik fel, pedig valójában üzemeltetési kérdés. A három szokásos megoldás bármelyike működő alagutat tart fenn: egy meglévő szervezeti CA, egy dedikált saját üzemeltetésű kibocsátó vagy az AWS Private CA. Abban különböznek, ki hagyja jóvá az eszközt, kinél van az aláírókulcs, és ki válaszol, amikor egy laptop alkalmatlan órában tűnik el. Válassza azt a lehetőséget, amelynek felelősét meg tudja nevezni.

Az AWS nem írja elő a Private CA-t a tanúsítványalapú hitelesítéshez. A kiszolgálótanúsítvány ACM-be helyezése telepítési lépés, nem regisztrációs folyamat.

A három feltétel, amely eldönti

Három feltétel tisztán elválasztja a lehetőségeket: létezik-e már jóváhagyott eszközregisztrációs folyamat, tud-e aláírókulcsot üzemeltetni biztonsági mentésekkel és kijelölt felelőssel, és hogyan érkezik meg a visszavonás a végpontra. Mindegyik közel van az igenhez vagy a nemhez, és az első nem általában eldönti az architektúrát.

Sorrendben haladjon végig rajtuk. Az ugrás egyenesen a költség-összehasonlításra vezet oda, hogy a csapatok egy felügyelt CA-val maradnak, és senki nem tudja, ki adja ki a következő laptop-tanúsítványt.

Első feltétel: létezik-e már regisztráció?

Ha a szervezete már üzemeltet CA-t jóváhagyott eszközregisztrációs úttal, a Client VPN ügyféltanúsítványainak onnan történő kiadása a legrövidebb út. A jóváhagyások, a folyamat és az eszköznyilvántartás már ott van. Az adott hierarchia alatti dedikált alárendelt kibocsátó általában jobb, mint az általános célú kibocsátó CA, mert saját bizalmi határt és saját visszavonási listát ad a VPN-nek. Tartsa ezt a listát külön a hierarchia többi részétől, hogy egy VPN-esemény ne kényszerítsen a teljes PKI-ra kiterjedő változtatást.

Ha nincs ilyen folyamat, az igazi kérdés az, hogy akar-e egyet felépíteni. A CA-t könnyű elindítani, és drága rosszul birtokolni.

Második feltétel: tud-e aláírókulcsot üzemeltetni?

A saját üzemeltetésű kibocsátó a dokumentált importmodellel működik, és az EasyRSA vagy egy kis belső eszköz elő tudja állítani az anyagot. A parancs futtatása nem a nehéz rész. A nehéz rész az aláírókulcs offline biztonsági mentései, egy helyreállítási útvonal, amelyet valaki tényleg kipróbált, egy felelős, aki nincs szabadságon, és egy szabály, hogy a kulcs soha nem kerül ügyfélcsomagba vagy konfigurációexportba. Írja ezt le eljárásként az első tanúsítvány kiadása előtt, nem az első incidens után.

Az AWS Private CA felügyelt szolgáltatásba helyezi ezt a letétet. Nem helyezi át a regisztrációs szabályzatot, a jóváhagyási lépést vagy a tanúsítvány eszközre történő eljuttatását.

Harmadik feltétel: hogyan érkezik a visszavonás?

A Client VPN olyan ügyféltanúsítvány-visszavonási listát használ, amelyet Ön importál a végpontba, ahogy a tanúsítvány életciklus-útmutatójában le van írva. A CRL közzététele a PKI más helyén nem tolja be a szolgáltatásba. Az importálás külön, ütemezett művelet, és a lejárt lista leállítja a kapcsolatokat, ahelyett hogy csendben romlana. Tegye a megújítást ugyanarra a naptárra, mint magukat a tanúsítványokat.

Ettől a megújítás felelőssel rendelkező megfigyelési tétel lesz, nem az induláskor befejeződő feladat. Vonjon vissza egy teszttanúsítványt elejétől a végéig, mielőtt valóban szüksége lenne a mechanizmusra.

Amit egyik lehetőség sem szüntet meg

Minden lehetőséghez továbbra is külön ügyféltanúsítvány és kulcs kell minden önállóan felügyelt eszközhöz. Az az útmutató, amely egyetlen identitást oszt ki mindenkinek, útmutatói rövidítés, és a szelektív visszavonást is lehetetlenné teszi.

Az ACM-be importált kiszolgálótanúsítványokhoz nincs felügyelt megújítás, ezért a felelősnek be kell szereznie a cserét, újra kell importálnia, majd meg kell erősítenie, hogy a végpont átvette. A kiszolgálótanúsítvány megújítása nem újítja meg a laptopokon már meglévő ügyfél-hitelesítő adatokat. Ezek külön életciklusok, külön naptárakkal.

Ellenőrizze, milyen kulcstípusokat és kiterjesztéseket fogad el a szolgáltatás, mielőtt bármit kiadna. Az, hogy egy CA támogat egy algoritmust, nem jelenti azt, hogy a végpont elfogadja.

Az indulás előtt futtasson végig egy megújítást és egy ügyfél eltávolítását a választott munkafolyamaton, és írja le, melyik hitelesítő adat változott, melyik végpontbeállítás változott, és mi történt az aktív munkamenettel. Ha ez a gyakorlat világos felelős nélkül ér véget, a kibocsátó kiválasztása nem fejeződött be.