AWS Client VPN: vilken CA bör utfärda klientcertifikat?

Certifikatfrågan på AWS Client VPN ställs som en produktfråga, och det är egentligen en driftfråga. Vilken som helst av de tre vanliga uppsättningarna håller en fungerande tunnel igång: en befintlig organisatorisk CA, en dedikerad egen driftad utfärdare eller AWS Private CA. De skiljer sig i vem som godkänner en enhet, vem som håller signeringsnyckeln och vem som svarar när en bärbar dator försvinner vid en olämplig tidpunkt. Välj alternativet vars ägare du kan namnge.

AWS kräver inte Private CA för certifikatbaserad autentisering. Att placera ett servercertifikat i ACM är ett driftsättningssteg, inte en registreringsprocess.

De tre villkoren som avgör

Tre villkor skiljer alternativen tydligt: om det redan finns en godkänd enhetsregistrering, om du kan driva en signeringsnyckel med säkerhetskopior och en namngiven ägare, och hur en återkallelse når slutpunkten. Varje ligger nära ett ja eller nej, och det första nejet avgör oftast arkitekturen.

Arbeta igenom dem i ordning. Att hoppa rakt till en kostnadsjämförelse är hur team hamnar med en hanterad CA och ingen som vet vem som utfärdar nästa laptopcertifikat.

Villkor ett: finns registreringen redan?

Om din organisation redan driver en CA med en godkänd väg för enhetsregistrering är utfärdande av Client VPN-klientcertifikat därifrån den kortaste vägen. Godkännandena, processen och tillgångsregistren finns redan. En dedikerad underordnad utfärdare under den hierarkin är oftast bättre än den allmänna utfärdande CA:n, eftersom den ger VPN:en sin egen förtroendegräns och sin egen återkallelselista. Håll den listan separat från resten av hierarkin så att en VPN-incident inte tvingar fram en ändring i hela PKI:t.

Finns ingen sådan process är den verkliga frågan om ni vill bygga en. En CA är lätt att starta och dyrt att äga dåligt.

Villkor två: kan ni driva en signeringsnyckel?

En egen driftad utfärdare fungerar med den dokumenterade importmodellen, och EasyRSA eller ett litet internt verktyg kan ta fram materialet. Att köra kommandot är inte den svåra delen. Den svåra delen är offline-säkerhetskopior av signeringsnyckeln, en återställningsväg som någon faktiskt har testat, en ägare som inte är på semester, och en regel att nyckeln aldrig hamnar i ett klientpaket eller en konfigurationsexport. Skriv ned det som en procedur innan det första certifikatet utfärdas, inte efter den första incidenten.

AWS Private CA flyttar den förvaringen till en hanterad tjänst. Det flyttar inte registreringspolicyn, godkännandesteget eller leveransen av certifikatet till enheten.

Villkor tre: hur kommer återkallelsen fram?

Client VPN använder en återkallelselista för klientcertifikat som ni importerar till slutpunkten, enligt guiden för certifikatets livscykel. Att publicera en CRL någon annanstans i er PKI knuffar inte in den i tjänsten. Importen är en separat, schemalagd åtgärd, och en utgången lista stoppar anslutningar i stället för att försämras tyst. Lägg förnyelsen på samma kalender som certifikaten själva.

Det gör förnyelse till en övervakningspost med en ägare, inte en uppgift som blir klar vid lansering. Återkalla ett testcertifikat från början till slut innan ni verkligen behöver mekanismen.

Vad inget av alternativen tar bort

Varje alternativ kräver fortfarande ett eget klientcertifikat och en egen nyckel per oberoende hanterad enhet. En guide som delar ut en enda identitet till alla är en genväg i guiden, och den gör också selektiv återkallelse omöjlig.

Importerade servercertifikat i ACM har ingen hanterad förnyelse, så ägaren måste skaffa ersättningen, importera den igen och sedan bekräfta att slutpunkten har tagit den i bruk. Att förnya servercertifikatet förnyar inte klientuppgifterna som redan ligger på bärbara datorer. Det är separata livscykler med separata kalendrar.

Kontrollera nyckeltyperna och tilläggen som tjänsten accepterar innan ni utfärdar något. Att en CA stöder en algoritm betyder inte att slutpunkten accepterar den.

Före lansering, kör en förnyelse och en borttagning av en klient genom arbetsflödet ni valde, och skriv ned vilken autentiseringsuppgift som ändrades, vilken slutpunktsinställning som ändrades och vad som hände med den aktiva sessionen. Om övningen slutar utan en tydlig ägare är valet av utfärdare inte klart.