AWS Client VPN: kateri CA naj izdaja odjemalske certifikate?

Vprašanje certifikatov pri AWS Client VPN se postavlja kot vprašanje izdelka, v resnici pa je operativno vprašanje. Katera koli od treh običajnih nastavitev bo ohranila delujoč tunel: obstoječi organizacijski CA, namenski lastni izdajatelj ali AWS Private CA. Razlikujejo se po tem, kdo odobri napravo, kdo hrani podpisni ključ in kdo odgovori, ko prenosnik izgine ob neprimerni uri. Izberite možnost, katere lastnika lahko poimenujete.

AWS za preverjanje s certifikati ne zahteva Private CA. Namestitev strežniškega certifikata v ACM je korak uvajanja, ne postopek registracije.

Trije pogoji, ki to odločijo

Trije pogoji možnosti jasno ločijo: ali že obstaja odobren postopek registracije naprav, ali lahko vodite podpisni ključ z varnostnimi kopijami in imenovanim lastnikom, in kako preklic doseže končno točko. Vsak je blizu da ali ne, prvi ne pa običajno odloči arhitekturo.

Preglejte jih po vrsti. Skok naravnost na primerjavo stroškov je način, kako ekipe ostanejo z upravljanim CA in nikomer, ki bi vedel, kdo bo izdal naslednji certifikat za prenosnik.

Prvi pogoj: ali registracija že obstaja?

Če vaša organizacija že upravlja CA z odobreno potjo registracije naprav, je izdajanje odjemalskih certifikatov Client VPN iz njega najkrajša pot. Odobritve, postopek in evidenca sredstev so že tam. Namenski podrejeni izdajatelj v tej hierarhiji je običajno boljši od CA splošnega namena, ker daje VPN lastno mejo zaupanja in lasten seznam preklicov. Ta seznam hranite ločeno od preostale hierarhije, da incident VPN ne vsili spremembe v celem PKI.

Če takega postopka ni, je pravo vprašanje, ali ga želite zgraditi. CA je lahko začeti in drago slabo imeti.

Drugi pogoj: ali lahko vodite podpisni ključ?

Lastni izdajatelj deluje z dokumentiranim modelom uvoza, EasyRSA ali majhno notranje orodje pa lahko ustvari gradivo. Zagon ukaza ni težji del. Težji del so offline varnostne kopije podpisnega ključa, pot obnovitve, ki jo je nekdo resnično preizkusil, lastnik, ki ni na dopustu, in pravilo, da ključ nikoli ne konča v paketu odjemalca ali izvozu konfiguracije. To zapišite kot postopek pred izdajo prvega certifikata, ne po prvem incidentu.

AWS Private CA to hrambo premakne v upravljano storitev. Ne premakne politike registracije, koraka odobritve ali dostave certifikata v napravo.

Tretji pogoj: kako pride preklic?

Client VPN uporablja seznam preklicanih odjemalskih certifikatov, ki ga uvozite v končno točko, kot je opisano v vodniku po življenjskem ciklu certifikata. Objava CRL drugje v vašem PKI ga ne potisne v storitev. Uvoz je ločena, načrtovana operacija, potekel seznam pa ustavi povezave, namesto da bi se tiho slabšal. Obnovitev postavite v isti koledar kot certifikate.

Zato je obnovitev nadzorna postavka z lastnikom, ne naloga, ki se konča ob zagonu. Prekličite en preizkusni certifikat od začetka do konca, preden mehanizem resnično potrebujete.

Česa nobena možnost ne odpravi

Vsaka možnost še vedno potrebuje en ločen odjemalski certifikat in ključ za vsako neodvisno upravljano napravo. Vodnik, ki vsem razdeli eno identiteto, je bližnjica v vodniku in onemogoči tudi selektivni preklic.

Uvoženi strežniški certifikati v ACM nimajo upravljane obnovitve, zato mora lastnik pridobiti zamenjavo, jo znova uvoziti in nato potrditi, da jo je končna točka prevzela. Obnova strežniškega certifikata ne obnovi odjemalskih poverilnic, ki so že na prenosnikih. To so ločeni življenjski cikli z ločenimi koledarji.

Pred izdajo česar koli preverite vrste ključev in razširitve, ki jih storitev sprejema. To, da CA podpira algoritem, ne pomeni, da ga bo končna točka sprejela.

Pred zagonom izvedite eno obnovitev in eno odstranitev odjemalca po izbranem delovnem toku ter zapišite, katera poverilnica se je spremenila, katera nastavitev končne točke se je spremenila in kaj se je zgodilo z aktivno sejo. Če se ta vaja konča brez jasnega lastnika, izbira izdajatelja ni dokončana.