AWS Client VPN: welke CA moet clientcertificaten uitgeven?
Een bestaande CA, een zelf beheerde uitgever en AWS Private CA verdelen het werk anders. Bepaal wie clientcertificaten goedkeurt, vernieuwt en intrekt voordat u begint.
De certificaatvraag bij AWS Client VPN wordt als productvraag gesteld, terwijl het in werkelijkheid een operationele vraag is. Elk van de drie gebruikelijke opstellingen houdt een werkende tunnel in de lucht: een bestaande organisatie-CA, een speciale zelf beheerde uitgever of AWS Private CA. Ze verschillen in wie een apparaat goedkeurt, wie de ondertekeningssleutel bewaart en wie antwoordt wanneer een laptop op een ongunstig uur verdwijnt. Kies de optie waarvan u de eigenaar kunt noemen.
AWS vereist geen Private CA voor verificatie met certificaten. Een servercertificaat in ACM plaatsen is een implementatiestap, geen registratieproces.
De drie voorwaarden die de keuze bepalen
Drie voorwaarden scheiden de opties duidelijk: of er al een goedgekeurd apparaatregistratieproces bestaat, of u een ondertekeningssleutel met back-ups en een benoemde eigenaar kunt beheren, en hoe een intrekking de endpoint bereikt. Elk ligt dicht bij ja of nee, en de eerste nee bepaalt meestal de architectuur.
Werk ze op volgorde af. Meteen naar een kostenvergelijking springen is hoe teams achterblijven met een beheerde CA en niemand die weet wie het volgende laptopcertificaat uitgeeft.
| 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 |
Eerste voorwaarde: bestaat de registratie al?
Als uw organisatie al een CA beheert met een goedgekeurd pad voor apparaatregistratie, is het uitgeven van Client VPN-clientcertificaten daaruit de kortste route. De goedkeuringen, het proces en de activaregistratie zijn er al. Een speciale ondergeschikte uitgever onder die hiërarchie is meestal beter dan de algemene uitgevende CA, omdat die de VPN een eigen vertrouwensgrens en een eigen intrekkingslijst geeft. Houd die lijst gescheiden van de rest van de hiërarchie, zodat een VPN-incident geen wijziging in de hele PKI afdwingt.
Bestaat zo'n proces niet, dan is de echte vraag of u er een wilt bouwen. Een CA is makkelijk te starten en duur om slecht te bezitten.
Tweede voorwaarde: kunt u een ondertekeningssleutel beheren?
Een zelf beheerde uitgever werkt met het gedocumenteerde importmodel, en EasyRSA of een klein intern hulpmiddel kan het materiaal produceren. Het commando uitvoeren is niet het moeilijke deel. Het moeilijke deel zijn offline back-ups van de ondertekeningssleutel, een herstelpad dat iemand echt heeft getest, een eigenaar die niet op vakantie is, en een regel dat de sleutel nooit in een clientbundel of een configuratie-export belandt. Schrijf dat als procedure op voordat het eerste certificaat wordt uitgegeven, niet na het eerste incident.
AWS Private CA verplaatst die bewaring naar een beheerde dienst. Het verplaatst niet het registratiebeleid, de goedkeuringsstap of de levering van het certificaat aan het apparaat.
Derde voorwaarde: hoe komt intrekking aan?
Client VPN gebruikt een intrekkingslijst voor clientcertificaten die u in de endpoint importeert, zoals beschreven in de handleiding over de levenscyclus van certificaten. Een CRL elders in uw PKI publiceren duwt die er niet in. De import is een aparte, geplande handeling, en een verlopen lijst stopt verbindingen in plaats van stilletjes te verslechteren. Zet de vernieuwing op dezelfde kalender als de certificaten zelf.
Daarmee wordt vernieuwing een monitoringitem met een eigenaar, geen taak die bij de lancering klaar is. Trek één testcertificaat van begin tot eind in voordat u het mechanisme echt nodig hebt.
Wat geen van de opties wegneemt
Elke optie vraagt nog steeds één afzonderlijk clientcertificaat en één sleutel per onafhankelijk beheerd apparaat. Een handleiding die één identiteit aan iedereen uitdeelt is een handleidingkorteroute, en maakt selectieve intrekking ook onmogelijk.
Geïmporteerde servercertificaten in ACM hebben geen beheerde vernieuwing, dus de eigenaar moet de vervanging regelen, opnieuw importeren en dan bevestigen dat de endpoint die heeft overgenomen. Het servercertificaat vernieuwen vernieuwt niet de clientreferenties die al op laptops staan. Dat zijn aparte levenscycli met aparte kalenders.
Controleer de sleuteltypen en extensies die de dienst accepteert voordat u iets uitgeeft. Dat een CA een algoritme ondersteunt betekent niet dat de endpoint het accepteert.
Voer voor de lancering één vernieuwing en één verwijdering van een client uit via de gekozen werkstroom, en noteer welke referentie veranderde, welke endpointinstelling veranderde en wat er met de actieve sessie gebeurde. Als die oefening zonder duidelijke eigenaar eindigt, is de keuze van uitgever niet afgerond.