Vien CSR dar nėra registracija: ką turi patikrinti VPN CA

Sertifikato pasirašymo prašyme yra viešasis raktas ir prašomas subjektas, pasirašyti atitinkamu privačiuoju raktu. Šis parašas įrodo, kad prašytojas turi raktą. Jis neįrodo, kad prašytojas turi teisę į prašomą vardą, įrenginį ar VPN vaidmenį, o elgtis su prašymu taip, tarsi jis tai įrodytų, yra būtent tai, kaip pagalbos tarnybos bilietas tampa prieigos suteikimu.

Du registracijos modelius verta palyginti pagal tai, ką jie susieja, o ne pagal tai, kokiu protokolu jie kalba.

Prašymas teigia vardą, bet jo neįrodo

Skaitykite prašymą pagal tai, kas jame iš tikrųjų yra: viešasis raktas, prašytojo pasirinktas subjektas ir savarankiškas parašas abiem. Šioje struktūroje nieko nėra, kas nurodytų jūsų inventorizaciją, paskyrų katalogą ar patvirtinimo eigą. Subjektas kaip cn=finance-laptop yra eilutė, kurią kas nors įvedė. Kol išdavimo procesas netikrina šios eilutės pagal pasitikimą keliantį įrašą, sertifikatas yra teiginys su pridėtu parašu. Šis skirtumas yra visa priežastis, kodėl egzistuoja registracijos procesas.

Pasekmė svarbi operatyviai. Sertifikatų institucijai niekada nereikia kliento privataus rakto sertifikatui išduoti, o procesas, kuris jo prašo, supainiojo pasirašymą su raktų saugojimu. Laikykite generavimą galiniame taške ir siųskite tik viešąją pusę.

Palyginkite modelius pagal tai, ką jie susieja

Rankinis pasirašymas susieja tai, ką operatorius atsimena patikrinti. Automatizuota registracijos paslauga susieja autentifikuotą prašymą su sprendimu, kurį paslauga gali įgyvendinti, o RFC 7030 aprašo vieną tokį projektą, kai klientas autentifikuojasi prieš grąžinant sertifikatą. Skirtumas, kuris išlaiko auditą, nėra automatizavimas; tai, ar tapatybės patikra vyksta išdavimo kelyje, ar šalia jo.

Abu modeliai vis tiek turi atsakyti į tuos pačius tris klausimus. Kas prašo, kokiame įrenginyje ar vaidmenyje ir kiek laiko. Bilietų sistema, kuri užrašo atsakymus, atlieka tikrą darbą; eilė, kurioje kas nors žiūri į bendrą vardą, ne, kad ir kaip kruopščiai sertifikatas vėliau būtų suformatuotas.

Modelį rinkitės pagal numatomą registracijų skaičių ir įrenginių kaitą. Keli serveriai per metus išgyvena rankinę peržiūrą su rašytiniu kontroliniu sąrašu. Nešiojamųjų kompiuterių parkas neišgyvena.

Fiksuokite gyvavimo ciklą nuo pirmo išdavimo

Išdavimo momentu saugokite sertifikato identifikatorių, savininką, numatomą naudojimą, galiojimą ir šalinimo kelią, o ne pirmo incidento metu. Numatomas naudojimas priklauso pačiam sertifikatui per išplėstinį rakto naudojimą, ir įrašas turi su tuo sutikti. Klientų autentifikavimui sukurtas sertifikatas neturi būti neatskiriamas nuo skirto serveriui.

Suplanuokite atnaujinimą ir pamesto įrenginio panaikinimą prieš išduodami dešimtą profilį. Padalinyje bendrinamas sertifikatas tikslinį pašalinimą paverčia sutrikimu, ir šį sprendimą dabar peržiūrėti daug pigiau nei penktadienio incidento metu.

Patikrinkite išduotą sertifikatą, tada prieigą

Po registracijos patikrinkite, kas buvo išduota, ir patvirtinkite, kad tai susiję su laukiama institucija. Dvi komandos apima dažnas klaidas: sertifikatą su netinkamu naudojimu ir grandinę, kuri veikia tik todėl, kad klientas sukonfigūruotas ignoruoti validavimą.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

Tada testuokite prieigą, o ne artefaktą. Sertifikatas nustato tapatybę, o politika vis dar sprendžia, kurias paslaugas ši tapatybė gali pasiekti. Patikrinkite abu, nes teisingas artefaktas su per plačia politika vis tiek nepraeina peržiūros. Patvirtinkite, kad klientas autentifikuojasi ir gauna tik numatytus maršrutus ar išteklius. Užrašykite, ką pastebėjote, o ne ką profilis turėjo daryti.

Profilis, kuris veikia dėl neteisingos priežasties, pavyzdžiui, sutampantis bendras vardas ir jokios tapatybės patikros, veiks ir toliau po to, kai bus pašalinta kontrolė, kurią manėte turįs.