AWS Client VPN: aling CA ang dapat mag-isyu ng mga sertipiko ng kliyente?

Ang tanong tungkol sa sertipiko sa AWS Client VPN ay itinatanong bilang tanong ng produkto, ngunit talagang tanong ito ng operasyon. Alinman sa tatlong karaniwang setup ay magpapanatili ng gumaganang tunnel: umiiral na CA ng organisasyon, dedikadong sariling pinamamahalaang issuer, o AWS Private CA. Nagkakaiba sila sa kung sino ang nag-aapruba ng device, sino ang may hawak ng susi ng lagda, at sino ang sasagot kapag nawala ang laptop sa hindi magandang oras. Piliin ang opsiyon na kayang pangalanan ang may-ari.

Hindi kailangan ng AWS ang Private CA para sa pagpapatotoo gamit ang sertipiko. Ang paglalagay ng sertipiko ng server sa ACM ay hakbang ng pag-deploy, hindi proseso ng pagpapatala.

Ang tatlong kundisyon na nagpapasya

Tatlong kundisyon ang malinaw na naghihiwalay sa mga opsiyon: kung may umiiral nang aprubadong proseso ng pagpapatala ng device, kung kaya mong pamahalaan ang susi ng lagda na may mga backup at pinangalanang may-ari, at kung paano umabot ang pagbawi sa endpoint. Bawat isa ay malapit sa oo o hindi, at ang unang hindi ang karaniwang nagpapasya sa arkitektura.

Isa-isahin ayon sa pagkakasunod-sunod. Ang tumalon agad sa paghahambing ng gastos ang dahilan kung bakit natatapos ang mga team na may pinamamahalaang CA at walang nakakaalam kung sino ang mag-isyu ng susunod na sertipiko ng laptop.

Unang kundisyon: may pagpapatala na ba?

Kung ang organisasyon mo ay nagpapatakbo na ng CA na may aprubadong landas ng pagpapatala ng device, ang pag-isyu ng mga sertipiko ng kliyente ng Client VPN mula roon ang pinakamaikling ruta. Nandiyan na ang mga apruba, proseso at talaan ng asset. Ang dedikadong subordinate issuer sa ilalim ng hierarchy na iyon ay karaniwang mas mabuti kaysa sa pangkalahatang nag-isyu na CA, dahil binibigyan nito ang VPN ng sariling hangganan ng tiwala at sariling listahan ng pagbawi. Panatilihing hiwalay ang listahang iyon sa iba pang bahagi ng hierarchy upang hindi pilitin ng isang insidente ng VPN ang pagbabago sa buong PKI.

Kung walang ganoong proseso, ang tunay na tanong ay kung gusto mong bumuo ng isa. Ang CA ay madaling simulan at mahal kung hindi maayos ang paghawak.

Ikalawang kundisyon: kaya mo bang pamahalaan ang susi ng lagda?

Ang sariling pinamamahalaang issuer ay gumagana sa dokumentadong modelo ng pag-import, at ang EasyRSA o maliit na panloob na tool ay makakagawa ng materyal. Ang pagpapatakbo ng utos ay hindi ang mahirap na bahagi. Ang mahirap na bahagi ay ang mga offline na backup ng susi ng lagda, landas ng pagbangon na aktuwal na sinubukan ng iba, may-aring wala sa bakasyon, at tuntuning hindi kailanman napupunta ang susi sa bundle ng kliyente o export ng configuration. Isulat ito bilang pamamaraan bago i-isyu ang unang sertipiko, hindi pagkatapos ng unang insidente.

Inililipat ng AWS Private CA ang pangangalagang iyon sa pinamamahalaang serbisyo. Hindi nito inililipat ang patakaran sa pagpapatala, ang hakbang ng apruba, o ang paghahatid ng sertipiko sa device.

Ikatlong kundisyon: paano dumarating ang pagbawi?

Gumagamit ang Client VPN ng listahan ng pagbawi ng mga sertipiko ng kliyente na ini-import mo sa endpoint, tulad ng inilarawan sa gabay sa siklo ng buhay ng sertipiko. Ang pag-publish ng CRL sa ibang lugar sa PKI mo ay hindi ito itinutulak sa serbisyo. Ang pag-import ay hiwalay at naka-iskedyul na operasyon, at ang nag-expire na listahan ay humihinto ng mga koneksiyon sa halip na tahimik na lumala. Ilagay ang pag-renew sa parehong kalendaryo ng mga sertipiko mismo.

Ginagawa nitong item ng pagmamanman na may may-ari ang pag-renew, hindi gawaing natatapos sa paglulunsad. Bawiin ang isang test na sertipiko mula simula hanggang dulo bago mo talagang kailanganin ang mekanismo.

Ang hindi inaalis ng alinmang opsiyon

Kailangan pa rin ng bawat opsiyon ang isang natatanging sertipiko at susi ng kliyente para sa bawat device na pinamamahalaang mag-isa. Ang tutorial na nagbabahagi ng isang pagkakakilanlan sa lahat ay shortcut ng tutorial, at ginagawa rin nitong imposible ang piling pagbawi.

Ang mga na-import na sertipiko ng server sa ACM ay walang pinamamahalaang pag-renew, kaya kailangang kunin ng may-ari ang kapalit, i-import itong muli, at pagkatapos ay kumpirmahin na pinagtibay ito ng endpoint. Ang pag-renew ng sertipiko ng server ay hindi nagre-renew ng mga kredensiyal ng kliyente na nasa mga laptop na. Iba ang mga siklo ng buhay na iyon na may iba't ibang kalendaryo.

Suriin ang mga uri ng susi at extension na tinatanggap ng serbisyo bago mag-isyu ng anuman. Ang pagsuporta ng CA sa isang algorithm ay hindi nangangahulugang tatanggapin ito ng endpoint.

Bago ang paglulunsad, magpatakbo ng isang pag-renew at isang pagtanggal ng kliyente sa napiling workflow, at itala kung aling kredensiyal ang nagbago, aling setting ng endpoint ang nagbago at ano ang nangyari sa aktibong sesyon. Kung matatapos ang pagsasanay na iyon na walang malinaw na may-ari, hindi pa tapos ang pagpili ng issuer.