Uusi iPad liittyy tiimiin, ja nopein tapa on viedä olemassa oleva asiakasvarmennus ja asentaa se tabletille. Se toimii, kunnes joku lähtee, kadottaa laitteen tai pyytää tarkastuksen, joka kertoo, mikä laite yhdisti ja milloin. Päätös ei koske varmennustiedostoa vaan identiteettiä: voiko jokaisen laitteen valtuuttaa ja peruuttaa erikseen. Kustannus ja hallintatyö ratkaisevat vastauksen, ja molemmat ovat pienempiä kuin miltä näyttää.

Yhteinen myöntäjä, erilliset identiteetit

Jokainen laite voi luottaa samaan varmentajaan ja yhdistää samaan yhdyskäytävään, vaikka sillä on eri asiakasidentiteetti. Myöntäjä on luottamuksen ankkuri, kun taas identiteetti on avainpari, jonka subjektin palvelin kartoittaa käytäntöön. Juuri näiden kahden sekoittaminen saa jaetun varmennuksen tuntumaan vaarattomalta. Se pysyy vaarattomana vain siihen asti, kun jonkun on tiedettävä, mikä laite avasi istunnon.

Myöntäjän jakaminen säästää määritystyötä eikä muuta mitään laitekohtaisessa vastuussa. Identiteetin jakaminen puristaa jokaisen laitteen yhdeksi peruutettavaksi yksiköksi: yhden peruuttaminen peruuttaa kaikki, ja korvaavan valtuuttaminen valtuuttaa jokaisen koskaan tehdyn avaimen kopion. Tämä vaihtokauppa kannattaa tehdä nimenomaisesti sen sijaan, että kopioi tiedoston, koska se on perjantai-iltapäivänä nopeampaa.

Kun toinen varmennus maksaa liikaa

Laitekohtainen rekisteröinti maksaa yhden vaiheen: hallitun profiilin, SCEP-pyynnön tai opastetun tuonnin kertakäyttöisellä salasanalla. Se vaatii myös paikan sarjanumeroiden ja vanhenemispäivien seurantaan, osan, jonka useimmat käyttöönotot unohtavat, kunnes ensimmäinen varmennus vanhenee. Molemmat kustannukset ovat kertaluonteisia, ja molemmat pienenevät, kun rekisteröintivirta automatisoi ne.

Kustannus on todellinen taloudessa, jossa on kaksi tablettia ja yksi käyttäjä, jossa jaettu identiteetti on järkevä yhdellä lauseella dokumentoitu päätös. Se ei ole järkevä palvelussa, jossa pääsy on peruttava henkilökohtaisesti tai laitekohtaisesti, koska peruutustarina on koko syy käyttää varmenteita salasanan sijaan. Arvioi käyttöönottoa sen mukaan, kuinka usein laitteet vaihtavat omistajaa, ei sen mukaan, kuinka monta laitetta tänään on.

Rekisteröi laite, älä kopioi avainta

Nykyaikaiset alustat pitävät yksityiset avaimet suojatussa säilössä, ja jotkut merkitsevät ne suunnittelultaan ei-vietäviksi. Juuri tämä ominaisuus tekee kopioinnista mahdotonta alun alkaen, ja siksi kannettavalta tietokoneelta vietyä pakettia ei voi yksinkertaisesti tuoda uudelleen tabletille millään tuetulla tavalla. Yrittäminen tuottaa silti profiilin, joka asentuu puhtaasti ja sen jälkeen ei koskaan todista identiteettiä.

Käytä rekisteröintimenetelmää, jota käyttöönotto jo tukee: hallittu identiteettiprofiili, SCEP-palvelu tai tilipohjainen virta, joka myöntää laitteelle uuden avaimen. Varmentajan yksityisen avaimen jakelu puuttuvan identiteetin ratkaisemiseksi on toinen virhe, jonka vaikutusalue on paljon suurempi. Varmenneviranomainen myöntää tunnuksia, eikä sen koskaan pitäisi matkustaa päätepisteeseen.

Tarkista peruutus ennen kuin vastaat

Ennen kuin valitset jaetun vaihtoehdon, kuvaile, miltä peruutus näyttää pahimpana päivänä. Jos vastaus on yksi toimi, joka vaikuttaa useisiin laitteisiin, suunnittelu on jo päättänyt sinua vastaan.

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

Tarkastele materiaalia, joka sinulla todella on: onko yksityinen avain läsnä, mitä subjekti sanoo ja voiko sarjanumeron peruuttaa erikseen. Varmennustiedosto ilman avaintaan ei voi todentaa mitään, ja siksi jotkin kopioidut identiteetit epäonnistuvat ensimmäisessä yhteydessä.

Sovelluksen poistaminen tabletista ei ole peruutus, ja palvelin hyväksyy identiteetin edelleen, kunnes joku poistaa sen käytöstä. Kirjoita tämä lause runbookiin ennen ensimmäisen laitteen rekisteröintiä.

Aiheeseen liittyvät artikkelit