Har en iPad brug for sit eget VPN-klientcertifikat?

En ny iPad slutter sig til teamet, og den hurtigste vej er at eksportere det eksisterende klientcertifikat og installere det på tabletten. Det virker, indtil nogen forlader holdet, mister en enhed eller beder om en revision, der viser, hvilken enhed der koblede på hvornår. Beslutningen handler ikke om certifikatfilen, men om identitet: om hver enhed kan autoriseres og tilbagekaldes for sig selv. Omkostninger og administrationsarbejde afgør svaret, og begge er mindre, end de ser ud.

Fælles udsteder, adskilte identiteter

Hver enhed kan stole på samme certifikatmyndighed og forbinde til samme gateway, mens den har en anden klientidentitet. Udstederen er et tillidsanker, mens identiteten er et nøglepar, hvis subjekt serveren knytter til en politik. Det er sammenblandingen af de to, der får et delt certifikat til at føles harmløst. Det forbliver harmløst, indtil nogen skal vide, hvilken enhed der åbnede en session.

Delning af udstederen sparer konfigurationsarbejde og ændrer intet i ansvarligheden per enhed. Delning af identiteten samler hver enhed i én tilbagekaldelig enhed: tilbagekalder man én, tilbagekalder man alle, og autorisation af en erstatning autoriserer enhver kopi af nøglen, der nogensinde er lavet. Den byttehandel er værd at gøre eksplicit i stedet for at kopiere en fil, fordi det er hurtigere fredag eftermiddag.

Når et ekstra certifikat koster for meget

Registrering per enhed koster et trin: en administreret profil, en SCEP-anmodning eller en guidet import med en engangskode. Det koster også et sted at spore serienumre og udløbsdatoer, den del de fleste udrulninger glemmer, indtil det første certifikat udløber. Begge omkostninger er engangs, og begge skrumper, når registreringsforløbet automatiserer dem.

Omkostningen er reel for en husstand med to tablets og én bruger, hvor en delt identitet er en rimelig beslutning dokumenteret i én sætning. Den er ikke rimelig for en tjeneste, hvor adgang skal trækkes tilbage per person eller per enhed, fordi tilbagekaldelseshistorien er hele grunden til at bruge certifikater i stedet for en adgangskode. Vurdér udrulningen efter, hvor ofte enheder skifter hænder, ikke efter hvor mange enheder der findes i dag.

Registrér enheden, kopiér ikke nøglen

Moderne platforme opbevarer private nøgler i et beskyttet lager, og nogle markerer dem som ikke-eksporterbare ved design. Den egenskab er det, der gør kopiering umulig i første omgang, og det er også grunden til, at en eksporteret pakke fra en bærbar computer ikke bare kan genimporteres på en tablet på nogen understøttet måde. Forsøger man det alligevel, får man en profil, der installeres rent og derefter aldrig autentificerer.

Brug den registreringsmetode, som udrulningen allerede understøtter: en administreret identitetsprofil, en SCEP-tjeneste eller et kontobaseret forløb, der udsteder en ny nøgle på enheden. At distribuere certifikatmyndighedens private nøgle for at løse en manglende identitet er en anden fejl med en langt større radius. Myndigheden udsteder legitimationsoplysninger og bør aldrig rejse til endepunktet.

Kontrollér tilbagekaldelsen, før du svarer

Før du vælger den delte løsning, så beskriv, hvordan tilbagekaldelse ser ud på den værste dag. Hvis svaret er én handling, der påvirker flere enheder, har designet allerede besluttet imod dig.

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øg det materiale, du faktisk har: om der er en privat nøgle, hvad subjektet siger, og om serienummeret kan tilbagekaldes enkeltvis. En certifikatfil uden sin nøgle kan ikke autentificere noget, og det er derfor, nogle kopierede identiteter fejler ved den første forbindelse.

At slette en app fra tabletten er ikke tilbagekaldelse, og serveren bliver ved med at acceptere identiteten, indtil nogen deaktiverer den. Skriv den sætning i runbooken, før den første enhed registreres.