Viens CSR vēl nav reģistrācija: kas VPN CA ir jāpārbauda

Sertifikāta parakstīšanas pieprasījums satur publisko atslēgu un pieprasīto subject, kas parakstīts ar atbilstošo privāto atslēgu. Šis paraksts pierāda, ka pieprasītājam ir atslēga. Tas nepierāda, ka pieprasītājam ir tiesības uz pieprasīto vārdu, ierīci vai VPN lomu, un izturēties pret pieprasījumu tā, it kā tas to pierādītu, ir tieši tas, kā palīdzības dienesta biļete kļūst par piekļuves piešķiršanu.

Divi reģistrācijas modeļi ir pelnījuši salīdzinājumu pēc tā, ko tie saista, nevis pēc tā, ar kādu protokolu tie runā.

Pieprasījums apgalvo vārdu, tas to nepierāda

Lasiet pieprasījumu pēc tā, kas tajā patiešām ir: publiskā atslēga, pieprasītāja izvēlēts subject un pašparaksts uz abiem. Šajā struktūrā nekas neatsaucas uz jūsu inventarizāciju, kontu direktoriju vai apstiprināšanas plūsmu. Subject, piemēram, cn=finance-laptop, ir virkne, ko kāds ierakstījis. Kamēr izsniegšanas process nepārbauda šo virkni pret uzticamu ierakstu, sertifikāts ir apgalvojums ar pievienotu parakstu. Šī atšķirība ir viss iemesls, kāpēc reģistrācijas process pastāv.

Sekas ir svarīgas operatīvi. Sertifikācijas iestādei nekad nav vajadzīga klienta privātā atslēga, lai izsniegtu sertifikātu, un plūsma, kas to pieprasa, ir sajaucusi parakstīšanu ar atslēgu glabāšanu. Turiet ģenerēšanu galapunktā un sūtiet tikai publisko pusi.

Salīdziniet modeļus pēc tā, ko tie saista

Manuāla parakstīšana saista to, ko operators atceras pārbaudīt. Automatizēts reģistrācijas pakalpojums saista autentificētu pieprasījumu ar lēmumu, ko pakalpojums var piemērot, un RFC 7030 apraksta vienu šādu dizainu, kur klients autentificējas pirms sertifikāta atgriešanas. Atšķirība, kas pārdzīvo auditu, nav automatizācija; tā ir, vai identitātes pārbaude notiek izsniegšanas ceļā vai tam blakus.

Abiem modeļiem joprojām jāatbild uz tiem pašiem trim jautājumiem. Kas jautā, kurā ierīcē vai lomā un uz cik ilgu laiku. Biļešu sistēma, kas ieraksta atbildes, dara īstu darbu; rinda, kurā kāds skatās uz vispārēju vārdu, to nedara, lai cik rūpīgi sertifikāts vēlāk tiktu formatēts.

Izvēlieties modeli pēc gaidāmo reģistrāciju skaita un ierīču mainības. Daži serveri gadā iztur manuālu pārskatīšanu ar rakstisku kontrolsarakstu. Klēpjdatoru parks neiztur.

Fiksējiet dzīves ciklu no pirmās izsniegšanas

Glabājiet sertifikāta identifikatoru, īpašnieku, paredzēto lietojumu, derīguma termiņu un noņemšanas ceļu izsniegšanas brīdī, nevis pirmajā incidentā. Paredzētais lietojums pieder pašam sertifikātam, izmantojot paplašinātu atslēgas lietojumu, un ierakstam tam jāatbilst. Klientu autentifikācijai izsniegts sertifikāts nedrīkst būt neatšķirams no serverim paredzēta.

Plānojiet atjaunošanu un pazaudētas ierīces atsaukšanu pirms desmitā profila izsniegšanas. Nodaļā kopīgots sertifikāts mērķētu noņemšanu pārvērš pārtraukumā, un šo lēmumu tagad pārskatīt ir daudz lētāk nekā piektdienas incidenta laikā.

Pārbaudiet izsniegto sertifikātu, tad piekļuvi

Pēc reģistrācijas pārbaudiet, kas tika izsniegts, un apstipriniet, ka tas ķēdējas līdz gaidītajai iestādei. Divas komandas sedz biežākās kļūdas: sertifikātu ar nepareizu lietojumu un ķēdi, kas darbojas tikai tāpēc, ka klients ir konfigurēts ignorēt validāciju.

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

Pēc tam testējiet piekļuvi, nevis artefaktu. Sertifikāts nosaka identitāti, un politika joprojām izlemj, kurus pakalpojumus šī identitāte var sasniegt. Pārbaudiet abus, jo pareizs artefakts ar pārāk plašu politiku arī neiztur pārskatīšanu. Apstipriniet, ka klients autentificējas un saņem tikai paredzētos maršrutus vai resursus. Pierakstiet to, ko novērojāt, nevis to, kas profilam bija jādara.

Profils, kas darbojas nepareiza iemesla dēļ, piemēram, atbilstošs vispārējs vārds un nekāda identitātes pārbaude, turpinās darboties arī pēc tam, kad kontrole, kura jums, jūsuprāt, bija, tiks noņemta.