AWS Client VPN: hvilken CA bør utstede klientsertifikater?
En eksisterende CA, en selvdriftet utsteder og AWS Private CA fordeler arbeidet ulikt. Bestem hvem som godkjenner, fornyer og tilbakekaller klientsertifikater før lansering.
Sertifikatspørsmålet på AWS Client VPN stilles som et produktspørsmål, og det er egentlig et driftsmessig spørsmål. Enhver av de tre vanlige oppsettene vil holde en fungerende tunnel i gang: en eksisterende organisatorisk CA, en dedikert selvdriftet utsteder eller AWS Private CA. De skiller seg i hvem som godkjenner en enhet, hvem som holder signeringsnøkkelen, og hvem som svarer når en bærbar PC forsvinner på et uheldig tidspunkt. Velg alternativet hvis eier du kan navngi.
AWS krever ikke Private CA for sertifikatbasert autentisering. Å plassere et serversertifikat i ACM er et utrullingssteg, ikke en registreringsprosess.
De tre betingelsene som avgjør
Tre betingelser skiller alternativene rent: om det allerede finnes en godkjent enhetsregistrering, om du kan drifte en signeringsnøkkel med sikkerhetskopier og en navngitt eier, og hvordan en tilbakekalling når endepunktet. Hver er nær et ja eller nei, og det første neiet avgjør vanligvis arkitekturen.
Ta dem i rekkefølge. Å hoppe rett til en kostnadssammenligning er hvordan team ender med en administrert CA og ingen som vet hvem som utsteder det neste laptopsertifikatet.
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
Betingelse én: finnes registreringen allerede?
Hvis organisasjonen din allerede driver en CA med en godkjent vei for enhetsregistrering, er utstedelse av klientsertifikater for Client VPN derfra den korteste veien. Godkjenningene, prosessen og aktivregistrene er allerede der. En dedikert underordnet utsteder under det hierarkiet er vanligvis bedre enn den generelle utstedende CA, fordi den gir VPN-en sin egen tillitsgrense og sin egen tilbakekallingsliste. Hold den listen atskilt fra resten av hierarkiet slik at en VPN-hendelse ikke tvinger frem en endring i hele PKI-et.
Finnes ikke en slik prosess, er det egentlige spørsmålet om dere vil bygge en. En CA er lett å starte og dyrt å eie dårlig.
Betingelse to: kan dere drifte en signeringsnøkkel?
En selvdriftet utsteder fungerer med den dokumenterte importmodellen, og EasyRSA eller et lite internt verktøy kan produsere materialet. Å kjøre kommandoen er ikke den vanskelige delen. Den vanskelige delen er offline sikkerhetskopier av signeringsnøkkelen, en gjenopprettingsvei noen faktisk har testet, en eier som ikke er på ferie, og en regel om at nøkkelen aldri havner i en klientpakke eller en konfigurasjonseksport. Skriv det ned som en prosedyre før det første sertifikatet utstedes, ikke etter den første hendelsen.
AWS Private CA flytter den oppbevaringen til en administrert tjeneste. Det flytter ikke registreringspolicyen, godkjenningstrinnet eller leveringen av sertifikatet til enheten.
Betingelse tre: hvordan kommer tilbakekallingen frem?
Client VPN bruker en tilbakekallingsliste for klientsertifikater som dere importerer til endepunktet, slik det er beskrevet i veiledningen for sertifikatets livssyklus. Å publisere en CRL andre steder i PKI-et deres skyver den ikke inn i tjenesten. Importen er en separat, planlagt operasjon, og en utløpt liste stopper tilkoblinger i stedet for å forringes stille. Legg fornyelsen på samme kalender som sertifikatene selv.
Det gjør fornyelse til et overvåkningselement med en eier, ikke en oppgave dere fullfører ved lansering. Tilbakekall ett testsertifikat fra ende til annen før dere virkelig trenger mekanismen.
Hva ingen av alternativene fjerner
Hvert alternativ krever fortsatt ett eget klientsertifikat og en egen nøkkel per uavhengig administrert enhet. En veiledning som deler ut én identitet til alle, er en snarvei i veiledningen, og den gjør også selektiv tilbakekalling umulig.
Importerte serversertifikater i ACM har ingen administrert fornyelse, så eieren må skaffe erstatningen, importere den på nytt og deretter bekrefte at endepunktet har tatt den i bruk. Å fornye serversertifikatet fornyer ikke klientopplysningene som allerede ligger på bærbare PC-er. Det er separate livssykluser med separate kalendere.
Sjekk nøkkeltypene og utvidelsene tjenesten godtar før dere utsteder noe. At en CA støtter en algoritme betyr ikke at endepunktet godtar den.
Før lansering, kjør én fornyelse og én fjerning av en klient gjennom arbeidsflyten dere valgte, og skriv ned hvilke legitimasjoner som endret seg, hvilken endepunktinnstilling som endret seg og hva som skjedde med den aktive økten. Hvis øvelsen ender uten en klar eier, er valget av utsteder ikke ferdig.