AWS Client VPN: koji CA treba izdavati klijentske certifikate?

Pitanje certifikata na AWS Client VPN-u postavlja se kao pitanje proizvoda, a zapravo je operativno pitanje. Bilo koja od tri uobičajene postavke održat će funkcionalan tunel: postojeći organizacijski CA, namjenski vlastiti izdavač ili AWS Private CA. Razlikuju se po tome ko odobrava uređaj, ko drži ključ za potpisivanje i ko odgovara kada laptop nestane u nezgodan sat. Odaberite opciju čijeg vlasnika možete imenovati.

AWS ne zahtijeva Private CA za autentifikaciju certifikatima. Postavljanje serverskog certifikata u ACM je korak implementacije, a ne proces registracije.

Tri uslova koja odlučuju

Tri uslova čisto razdvajaju opcije: postoji li već odobren proces registracije uređaja, možete li voditi ključ za potpisivanje s rezervnim kopijama i imenovanim vlasnikom, i kako opoziv stiže do krajnje točke. Svaki je blizu da ili ne, a prvo ne obično odlučuje arhitekturu.

Prođite ih po redu. Skok ravno na poređenje troškova način je na koji timovi završe s upravljanim CA i nikim ko zna ko izdaje sljedeći certifikat za laptop.

Uslov prvi: postoji li registracija već?

Ako vaša organizacija već vodi CA s odobrenim putem registracije uređaja, izdavanje klijentskih certifikata za Client VPN iz njega najkraći je put. Odobrenja, proces i evidencija imovine već su tu. Namjenski podređeni izdavač u toj hijerarhiji obično je bolji od CA opće namjene, jer VPN-u daje vlastitu granicu povjerenja i vlastiti popis opoziva. Držite taj popis odvojen od ostatka hijerarhije kako VPN incident ne bi prisilio promjenu na razini cijelog PKI-ja.

Ako takav proces ne postoji, pravo je pitanje želite li ga izgraditi. CA je lako pokrenuti i skupo loše posjedovati.

Uslov drugi: možete li voditi ključ za potpisivanje?

Vlastiti izdavač radi s dokumentiranim modelom uvoza, a EasyRSA ili mali interni alat može proizvesti materijal. Pokretanje naredbe nije težak dio. Težak dio su offline rezervne kopije ključa za potpisivanje, put oporavka koji je neko stvarno testirao, vlasnik koji nije na odmoru i pravilo da ključ nikada ne završi u klijentskom paketu ili izvozu konfiguracije. Zapišite to kao proceduru prije nego što se izda prvi certifikat, a ne poslije prvog incidenta.

AWS Private CA premješta to čuvanje u upravljani servis. Ne premješta politiku registracije, korak odobravanja ni dostavu certifikata na uređaj.

Uslov treći: kako stiže opoziv?

Client VPN koristi popis opoziva klijentskih certifikata koji uvozite u krajnju točku, kako je opisano u vodiču kroz životni ciklus certifikata. Objavljivanje CRL-a negdje drugdje u vašem PKI-ju ne gura ga u servis. Uvoz je zasebna, zakazana operacija, a istekao popis zaustavlja veze umjesto da tiho degradira. Stavite obnavljanje na isti kalendar kao i same certifikate.

To obnavljanje čini stavkom nadzora s vlasnikom, a ne zadatkom koji završavate pri pokretanju. Opozvite jedan testni certifikat od početka do kraja prije nego što vam mehanizam zatreba zaista.

Što nijedna opcija ne uklanja

Svaka opcija i dalje traži jedan zaseban klijentski certifikat i ključ za svaki neovisno upravljani uređaj. Vodič koji svima dijeli jedan identitet je vodička prečica i ujedno čini selektivni opoziv nemogućim.

Uvezeni serverski certifikati u ACM-u nemaju upravljano obnavljanje, pa vlasnik mora nabaviti zamjenu, ponovno je uvesti i zatim potvrditi da ju je krajnja točka prihvatila. Obnavljanje serverskog certifikata ne obnavlja klijentske vjerodajnice koje već stoje na laptopima. To su odvojeni životni ciklusi s odvojenim kalendarima.

Provjerite vrste ključeva i proširenja koje servis prihvaća prije nego što bilo što izdate. To što CA podržava algoritam ne znači da će ga krajnja točka prihvatiti.

Prije pokretanja provedite jedno obnavljanje i jedno uklanjanje klijenta kroz odabrani tijek rada i zapišite koja se vjerodajnica promijenila, koja se postavka krajnje točke promijenila i što se dogodilo s aktivnom sesijom. Ako ta vježba završi bez jasnog vlasnika, izbor izdavača nije dovršen.