Treng ein iPad sitt eige VPN-klientsertifikat?

Ein ny iPad blir med i teamet, og den raskaste vegen er å eksportere det eksisterande klientsertifikatet og installere det på nettbrettet. Det fungerer til nokon sluttar, mistar ei eining eller ber om ein revisjon som viser kva eining som kopla til når. Avgjerda handlar ikkje om sertifikatfila, men om identitet: om kvar eining kan autoriserast og tilbakekallast for seg sjølv. Kostnad og administrasjonsarbeid avgjer svaret, og begge er mindre enn dei ser ut.

Felles utferdar, åtskilde identitetar

Kvar eining kan stole på same sertifikatstyresmakt og kople til same gateway medan ho har ein annan klientidentitet. Utferdaren er eit tillitsanker, medan identiteten er eit nøkkelpar som tenaren koplar subjektet til ein policy. Det er samanblandinga av dei to som får eit delt sertifikat til å kjennast ufarleg. Det blir verande ufarleg heilt til nokon må vite kva eining som opna ein sesjon.

Å dele utferdaren sparer konfigurasjonsarbeid og endrar ingenting i ansvaret per eining. Å dele identiteten samlar kvar eining i éi tilbakekallbar eining: tilbakekallar du éi, tilbakekallar du alle, og autoriserer du ein erstattar, autoriserer du kvar kopi av nøkkelen som nokon gong er laga. Den handelen er verdt å gjere eksplisitt i staden for å kopiere ei fil fordi det er raskare fredag ettermiddag.

Når eit ekstra sertifikat kostar for mykje

Registrering per eining kostar eitt trinn: ein administrert profil, ein SCEP-førespurnad eller ein rettleia import med eingongspassord. Det kostar også ein stad å spore serienummer og utløpsdatoar, den delen dei fleste utrullingar gløymer til det første sertifikatet går ut. Begge kostnadene er eingongs, og begge krympar når registreringsflyten automatiserer dei.

Kostnaden er reell for ein husstand med to nettbrett og éin brukar, der ein delt identitet er ei rimeleg avgjerd dokumentert i éi setning. Ho er ikkje rimeleg for ein teneste der tilgang må trekkjast tilbake per person eller per eining, fordi tilbakekallingshistoria er heile grunnen til å bruke sertifikat i staden for eit passord. Vurder utrullinga etter kor ofte einingar byter hender, ikkje etter kor mange einingar som finst i dag.

Registrer eininga, ikkje kopier nøkkelen

Moderne plattformer oppbevarer private nøklar i eit verna lager, og nokre merkjer dei som ikkje-eksporterbare ved design. Den eigenskapen er det som gjer kopiering umogleg i utgangspunktet, og det er også grunnen til at ein eksportert pakke frå ein berbar PC ikkje berre kan importerast på nytt på eit nettbrett på nokon støtta måte. Forsøk gir likevel ein profil som blir installert reint og deretter aldri autentiserer.

Bruk registreringsmetoden utrullinga allereie støttar: ein administrert identitetsprofil, ein SCEP-teneste eller ein kontobasert flyt som gjev ut ein ny nøkkel på eininga. Å distribuere den private nøkkelen til sertifikatstyresmakta for å løyse ein manglande identitet er ein annan feil med ein langt større radius. Styresmakta gjev ut legitimasjon og bør aldri reise til endepunktet.

Sjekk tilbakekallinga før du svarar

Før du vel det delte alternativet, skildre korleis tilbakekalling ser ut på den verste dagen. Om svaret er éi handling som påverkar fleire einingar, har designet allereie bestemt mot deg.

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

Undersøk materialet du faktisk har: om det finst ein privat nøkkel, kva subjektet seier og om serienummeret kan tilbakekallast individuelt. Ei sertifikatfil utan nøkkelen sin kan ikkje autentisere noko, og difor feilar nokre kopierte identitetar ved den første tilkoplinga.

Å slette ein app frå nettbrettet er ikkje tilbakekalling, og tenaren held fram med å godta identiteten til nokon deaktiverer han. Skriv den setninga i runbooken før den første eininga blir registrert.