AWS Client VPN: který CA má vydávat klientské certifikáty?

Otázka certifikátů u AWS Client VPN se klade jako otázka produktu, ale ve skutečnosti je to otázka provozu. Každé ze tří obvyklých řešení udrží funkční tunel: stávající organizační CA, vyhrazený vlastní vydavatel nebo AWS Private CA. Liší se v tom, kdo schvaluje zařízení, kdo drží podpisový klíč a kdo odpovídá, když se notebook ztratí v nevhodnou hodinu. Vyberte možnost, jejíhož vlastníka dokážete pojmenovat.

AWS pro ověřování certifikáty Private CA nevyžaduje. Umístění serverového certifikátu do ACM je krok nasazení, nikoli proces registrace.

Tři podmínky, které to rozhodnou

Tři podmínky možnosti jasně oddělují: zda už existuje schválený proces registrace zařízení, zda dokážete provozovat podpisový klíč se zálohami a jmenovaným vlastníkem, a jak se odvolání dostane ke koncovému bodu. Každá je blízko ano nebo ne a první ne obvykle rozhodne architekturu.

Projděte je popořadě. Skok rovnou k porovnání nákladů je způsob, jak týmy skončí s řízeným CA a nikým, kdo ví, kdo vydá další certifikát pro notebook.

Podmínka první: existuje registrace už teď?

Pokud vaše organizace už provozuje CA se schválenou cestou registrace zařízení, vydávání klientských certifikátů Client VPN z něj je nejkratší cesta. Schválení, proces i evidence aktiv už tam jsou. Vyhrazený podřízený vydavatel v této hierarchii je obvykle lepší než CA pro všeobecné použití, protože dává VPN vlastní hranici důvěry a vlastní seznam odvolání. Udržujte tento seznam oddělený od zbytku hierarchie, aby incident VPN nevynutil změnu v celém PKI.

Pokud takový proces neexistuje, skutečná otázka je, zda ho chcete postavit. CA se snadno začíná a draze se špatně vlastní.

Podmínka druhá: dokážete provozovat podpisový klíč?

Vlastní vydavatel funguje s dokumentovaným modelem importu a EasyRSA nebo malý interní nástroj může materiál vytvořit. Spuštění příkazu není ta těžká část. Těžká část jsou offline zálohy podpisového klíče, cesta obnovy, kterou někdo skutečně vyzkoušel, vlastník, který není na dovolené, a pravidlo, že klíč nikdy neskončí v klientském balíčku ani v exportu konfigurace. Zapište to jako postup před vydáním prvního certifikátu, ne po prvním incidentu.

AWS Private CA přesouvá toto držení do spravované služby. Nepřesouvá politiku registrace, krok schválení ani doručení certifikátu do zařízení.

Podmínka třetí: jak přichází odvolání?

Client VPN spotřebovává seznam odvolaných klientských certifikátů, který importujete do koncového bodu, jak popisuje průvodce životním cyklem certifikátů. Publikování CRL jinde ve vašem PKI ho do služby neprotlačí. Import je samostatná, plánovaná operace a prošlý seznam zastaví spojení, místo aby tiše degradoval. Dejte obnovu do stejného kalendáře jako samotné certifikáty.

Tím se z obnovy stává položka monitoringu s vlastníkem, ne úkol, který dokončíte při spuštění. Odvolejte jeden testovací certifikát od začátku do konce, než mechanismus budete opravdu potřebovat.

Co žádná z možností neodstraní

Každá možnost stále potřebuje jeden samostatný klientský certifikát a klíč pro každé nezávisle spravované zařízení. Návod, který rozdá jednu identitu všem, je zkratka v návodu a také znemožňuje selektivní odvolání.

Importované serverové certifikáty v ACM nemají spravovanou obnovu, takže vlastník musí získat náhradu, znovu ji importovat a potom potvrdit, že ji koncový bod převzal. Obnova serverového certifikátu neobnovuje klientské přihlašovací údaje, které už leží na noteboocích. To jsou oddělené životní cykly s oddělenými kalendáři.

Před vydáním čehokoli zkontrolujte typy klíčů a rozšíření, které služba přijímá. To, že CA podporuje algoritmus, neznamená, že ho koncový bod přijme.

Před spuštěním proveďte jedno obnovení a jedno odebrání klienta zvoleným pracovním postupem a zapište, které přihlašovací údaje se změnily, které nastavení koncového bodu se změnilo a co se stalo s aktivní relací. Pokud to cvičení skončí bez jasného vlastníka, volba vydavatele není hotová.