Varmenneallekirjoituspyyntö sisältää julkisen avaimen ja pyydetyn subjektin, allekirjoitettuna vastaavalla yksityisavaimella. Tämä allekirjoitus todistaa, että pyytäjällä on avain. Se ei todista, että pyytäjällä on oikeus pyytämäänsä nimeen, laitteeseen tai VPN-rooliin, ja pyynnön kohteleminen ikään kuin se todistaisi sen on juuri se, miten tukipalvelun tiketti muuttuu pääsyn myöntämiseksi.

Kahta rekisteröintimallia kannattaa verrata sen mukaan, mitä ne sitovat, ei sen mukaan, mitä protokollaa ne puhuvat.

Pyyntö väittää nimeä, se ei todista sitä

Lue pyyntö sen mukaan, mitä siinä todella on: julkinen avain, pyytäjän valitsema subjekti ja allekirjoitus molempien yli. Mikään tuossa rakenteessa ei viittaa laiteluetteloosi, tilihakemistoosi tai hyväksyntäprosessiisi. Subjekti kuten cn=finance-laptop on merkkijono, jonka joku kirjoitti. Kunnes myöntöprosessi tarkistaa tuon merkkijonon luotettua tietuetta vastaan, varmenne on väite, johon on liitetty allekirjoitus. Tämä ero on koko syy siihen, miksi rekisteröintiprosessi on olemassa.

Seurauksella on operationaalista merkitystä. Varmentaja ei koskaan tarvitse asiakkaan yksityisavainta varmenteen myöntämiseen, ja prosessi, joka pyytää sitä, on sekoittanut allekirjoittamisen avainten säilytykseen. Pidä luonti päätepisteessä ja lähetä vain julkinen puoli.

Vertaa malleja sen mukaan, mitä ne sitovat

Manuaalinen allekirjoittaminen sitoo sen, mitä operaattori muistaa tarkistaa. Automatisoitu rekisteröintipalvelu sitoo todennetun pyynnön päätökseen, jonka palvelu voi panna täytäntöön, ja RFC 7030 kuvaa yhden tällaisen mallin, jossa asiakas todennetaan ennen varmenteen palauttamista. Auditoinnin kestävä ero ei ole automaatio; vaan se, tapahtuuko identiteetin tarkistus myöntöpolun sisällä vai sen vieressä.

Molempien mallien on silti vastattava samoihin kolmeen kysymykseen. Kuka kysyy, millä laitteella tai roolissa ja kuinka pitkäksi ajaksi. Tikettijärjestelmä, joka tallentaa vastaukset, tekee todellista työtä; jono, jossa joku katsoo yleisnimeä, ei tee, riippumatta siitä, kuinka huolellisesti varmenne myöhemmin muotoillaan.

Valitse malli odottamiesi rekisteröintien määrän ja laitteiden vaihtuvuuden mukaan. Muutama palvelin vuodessa selviää manuaalisesta tarkistuksesta kirjallisella tarkistuslistalla. Kannettavien laitteiden laivasto ei selviä.

Kirjaa elinkaari ensimmäisestä myönnöstä

Tallenna varmenteen tunniste, omistaja, aiottu käyttö, vanheneminen ja poistopolku myöntöhetkellä, ei ensimmäisessä incidentissä. Aiotun käytön kuuluu olla varmenteessa itsessään laajennetun avainkäytön kautta, ja tietueen on oltava sen mukainen. Asiakastodennukseen luotua varmennetta ei pitäisi voida erottaa palvelimelle tarkoitetusta.

Suunnittele uusiminen ja kadonneen laitteen mitätöinti ennen kuin myönnät kymmenennen profiilin. Osaston kesken jaettu varmenne muuttaa kohdistetun poiston katkokseksi, ja päätöksen uudelleenkäsittely nyt on paljon halvempaa kuin perjantain incidentin aikana.

Tarkista myönnetty varmenne ja sitten pääsy

Rekisteröinnin jälkeen tarkista, mitä myönnettiin, ja varmista, että se ketjuuntuu odottamaasi tahoon. Kaksi komentoa kattaa tavalliset virheet: väärällä käytöllä varustettu varmenne ja ketju, joka toimii vain siksi, että asiakas on määritetty jättämään validointi huomiotta.

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

Testaa sitten pääsyä, ei artefaktia. Varmenne vahvistaa identiteetin, ja käytäntö päättää edelleen, mihin palveluihin tämä identiteetti voi päästä. Tarkista molemmat, koska oikea artefakti liian laajan käytännön kanssa epäonnistuu silti tarkistuksessa. Varmista, että asiakas todennetaan ja saa vain aiotut reitit tai resurssit. Kirjaa se, mitä havaitsit, ei sitä, mitä profiilin olisi pitänyt tehdä.

Profiili, joka toimii väärästä syystä, kuten täsmäävä yleisnimi ja identiteetin tarkistuksen puuttuminen, toimii edelleen sen jälkeen, kun luulemasi valvonta on poistettu.

Aiheeseen liittyvät artikkelit