Kodetoken, smartkort eller FIDO-nøgle: hvad en VPN accepterer

Tre enheder med samme stik og samme nøglering deltager i tre ikke-relaterede udvekslinger. Én viser en kode, som en server kontrollerer, én signerer med en nøgle, der aldrig forlader enheden, og én godkender et browser-login gennem sin egen protokol. Derfor sammenligner spørgsmålet, om en VPN skal bruge certifikater eller hardwaretokens, et format med en enhedsklasse. Svaret afhænger af, hvilken af de tre du faktisk har købt.

Navngiv beviset før enheden

Et engangskodetoken frembringer en værdi, som en godkendelsestjeneste validerer gennem sin egen mekanisme. VPN kan nå den tjeneste via RADIUS eller en fødereret identitetsudbyder, og tokenet behøver aldrig at rumme noget, der tilhører selve tunnelen. Det beviser, at personen holder den enhed, der genererer koden. Det beviser intet om den maskine, koden blev tastet på.

Et token i form af et smartkort gemmer en privat nøgle og udfører signeringsoperationen på anmodning, og det er sådan en certifikatidentitet bevises uden at eksportere nøglen. Certifikatet ved siden af er offentligt materiale, og at udlevere det certifikat er en helt anden handling end at udlevere nøglen.

En FIDO-nøgle taler igen en tredje protokol. Et browserbaseret login kan bruge den hos identitetsudbyderen, men succes på det websted betyder ikke, at den samme nøgle vil dukke op gennem en VPN-klients smartkortgrænseflade.

Nogle enheder implementerer flere af disse applikationer side om side, og producentens dokumentation oplister netop derfor tilstandene hver for sig. Det er ikke bevis for, at hver nøgle på markedet understøtter hver tilstand.

Hardware beskytter nøglen, ikke politikken

En PIN-kode på en certifikatbaseret enhed godkender normalt lokal brug af nøglen, og det er ikke den adgangskode, VPN-kontosystemet kontrollerer. Vejledninger som NIST's vejledning om godkendere kalder den lokale indtastning for en aktiveringshemmelighed, adskilt fra godkenderen selv. Sikkerheden kommer fra hele designet, ikke fra antallet af prompter på skærmen.

Tilmelding, fornyelse og fjernelse bliver hos identitetsejeren uanset hvad. Nogen beslutter stadig, hvem der må tilmeldes, binder legitimationsoplysningen til den rigtige person og gør udskiftning mulig, når en enhed mistes. At købe en ny nøgle tilbagekalder ikke den gamle.

Beskriv login-ceremonien, før du vælger hardware: skriver brugeren en kode, låser en signeringsnøgle op, eller godkender vedkommende en browserprompt? Hvert svar indebærer en anden klient, en anden gateway-indstilling og et andet script til supporten.

Hvor forløbene skilles i praksis

Et kodetoken er det nemmeste at udrulle og det svageste mod en overbevisende efterligningsside, fordi en indtastet kode kan videresendes i realtid. En certifikatbaseret nøgle modstår den klasse af angreb og koster mere at drive, da udstedelse og tilbagekaldelse bliver en del af tjenesten. En FIDO-nøgle hører til web-login og afhænger helt af, om identitetsudbyderen understøtter den til denne applikation.

Blandede miljøer er almindelige, og de er ikke automatisk forkerte: et certifikat til tunnelen plus et kodetoken til den administrative konsol er en sammenhængende opdeling, forudsat at begge er tilmeldt den samme identitet. Det, der bryder, er en opdeling, som ingen har dokumenteret, hvor supporten ikke kan sige, hvilken faktor en bruger mangler.

Gør beslutningen konkret

Skriv ceremonien ned som en række trin, en rigtig bruger udfører, og kontroller derefter, at klienten, gatewayen og identitetsudbyderen alle understøtter den række. En uoverensstemmelse viser sig normalt i det sidste trin, hvor klienten slet ikke kan adressere enheden.

Bekræft derefter, hvad der sker, når enheden mistes, eller certifikatet udløber. Hvis svaret ikke er skrevet ned, har udrulningen et hul, som vil blive opdaget en mandag morgen.

pkcs11-tool --list-slots
pkcs11-tool --list-objects --type cert