Nur CSR ne estas aliĝo: kion VPN-CA devas kontroli

Petosubskribo de atestilo enhavas publikan ŝlosilon kaj petatan subjekton, subskribitajn per la kongrua privata ŝlosilo. Tiu subskribo pruvas, ke la petanto posedas la ŝlosilon. Ĝi ne pruvas, ke la petanto rajtas al la nomo, la aparato aŭ la VPN-rolo petata, kaj trakti ĝin kvazaŭ ĝi pruvus tion estas precize tio, kio igas helpdeskan bileton alirpermeso.

Indas kompari du aliĝmodelojn laŭ tio, kion ili ligas, ne laŭ tio, kiun protokolon ili parolas.

Peto asertas nomon, ĝi ne pruvas ĝin

Legu la peton laŭ tio, kion ĝi efektive enhavas: publika ŝlosilo, subjekto elektita de la petanto, kaj memsubskribo super ambaŭ. Nenio en tiu strukturo referencas vian inventaron, vian kontan dosierujon aŭ vian aproban fluon. Subjekto kiel cn=finance-laptop estas signoĉeno, kiun iu tajpis. Ĝis la eldona procezo kontrolos tiun signoĉenon kontraŭ registraĵo, kiun ĝi fidas, la atestilo estas aserto kun aldonita subskribo. Tiu distingo estas la tuta kialo, ke ekzistas aliĝprocezo.

La sekvo gravas operacie. Atestila aŭtoritato neniam bezonas la privatan ŝlosilon de la kliento por eldoni atestilon, kaj fluo, kiu petas unu, konfuzis subskribadon kun ŝlosilgardado. Tenu generadon ĉe la finpunkto kaj sendu nur la publikan duonon.

Komparu la modelojn laŭ tio, kion ili ligas

Manuala subskribado ligas tion, kion la operatoro memoras kontroli. Aŭtomatigita aliĝservo ligas aŭtentikigitan peton al decido, kiun la servo povas devigi, kaj RFC 7030 priskribas unu tian dezajnon, kie la kliento aŭtentikiĝas antaŭ ol atestilo estas redonita. La diferenco, kiu postvivas revizion, ne estas aŭtomatigo; ĝi estas ĉu la identkontrolo okazas ene de la eldonvojo aŭ apud ĝi.

Ambaŭ modeloj ankoraŭ devas respondi la samajn tri demandojn. Kiu demandas, sur kiu aparato aŭ rolo, kaj por kiom longe. Bileta sistemo, kiu registras la respondojn, faras veran laboron; vico, kie iu rigardas komunan nomon, ne faras, kiom ajn zorgeme la atestilo poste estas formatita.

Elektu la modelon laŭ la nombro de aliĝoj, kiujn vi atendas, kaj laŭ la ŝanĝiĝo de aparatoj. Kelkaj serviloj jare povas travivi manan revizion kun skriba kontrolilsto. Floto da tekkomputiloj ne povas.

Registru la vivociklon de la unua eldono

Konservu la identigilon de la atestilo, la posedanton, la celatan uzon, la finiĝon kaj la forigvojon en la momento de eldono, ne ĉe la unua incidento. La celata uzo apartenas al la atestilo mem per etendita ŝlosiluzo, kaj la registraĵo devas kongrui kun ĝi. Atestilo kreita por klienta aŭtentikigo ne devas esti nedistingebla de tiu por servilo.

Planu renovigon kaj revokon de perdita aparato antaŭ ol vi eldonos la dekan profilon. Atestilo dividita tra fako transformas celitan forigon en interrompon, kaj tiu decido estas multe pli malmultekosta revizii nun ol dum vendreda incidento.

Kontrolu la eldonitan atestilon, poste la aliron

Post aliĝo, ekzamenu kion oni eldonis kaj konfirmu, ke ĝi ĉeniras al la aŭtoritato, kiun vi atendas. Du komandoj kovras la oftajn erarojn: atestilo kun malĝusta uzo, kaj ĉeno, kiu funkcias nur ĉar la kliento estas agordita ignori validigon.

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

Poste testu la aliron anstataŭ la artefakton. Atestilo starigas identecon, kaj la politiko ankoraŭ decidas, kiujn servojn tiu identeco povas atingi. Kontrolu ambaŭ, ĉar ĝusta artefakto kun tro larĝa politiko ankaŭ malsukcesas revizion. Konfirmu, ke la kliento aŭtentikiĝas kaj ricevas nur la celatajn vojojn aŭ rimedojn. Notu tion, kion vi observis, ne tion, kion la profilo devintus fari.

Profilo, kiu funkcias pro la malĝusta kialo, ekzemple kongrua komuna nomo kaj neniu identkontrolo, daŭros funkcii post kiam la kontrolo, kiun vi pensis havi, estos forigita.