Codice token, smart card o chiave FIDO: cosa accetta una VPN

Tre dispositivi con lo stesso connettore e lo stesso anello portachiavi partecipano a tre scambi senza rapporto. Uno mostra un codice che un server verifica, uno firma con una chiave che non lascia mai il dispositivo, e uno approva un accesso dal browser tramite un protocollo proprio. Chiedere quindi se una VPN debba usare certificati o token hardware significa confrontare un formato con una classe di dispositivi. La risposta dipende da quale dei tre avete effettivamente acquistato.

Nominate la prova prima del dispositivo

Un token a codice monouso produce un valore che un servizio di autenticazione convalida con il proprio meccanismo. La VPN può raggiungere quel servizio tramite RADIUS o un provider di identità federato, e il token non deve mai custodire nulla che appartenga al tunnel stesso. Ciò che dimostra è che la persona possiede il dispositivo che genera il codice. Non dimostra nulla sul computer su cui il codice è stato digitato.

Un token in stile smart card memorizza una chiave privata ed esegue l’operazione di firma su richiesta, ed è così che un’identità di certificato viene provata senza esportare la chiave. Il certificato accanto è materiale pubblico, e consegnare quel certificato è un atto molto diverso dal consegnare la chiave.

Una chiave FIDO parla ancora un terzo protocollo. Un accesso dal browser può usarla presso il provider di identità, ma il successo su quel sito non significa che la stessa chiave comparirà tramite l’interfaccia smart card di un client VPN.

Alcuni dispositivi implementano diverse di queste applicazioni una accanto all’altra, e la documentazione del fornitore elenca le modalità separatamente proprio per questo. Non è prova che ogni chiave sul mercato supporti ogni modalità.

L’hardware protegge la chiave, non la politica

Un PIN su un dispositivo con certificato di solito autorizza l’uso locale della chiave, e non è la password che il sistema degli account VPN verifica. Linee guida come le linee guida NIST sugli autenticatori chiamano quell’immissione locale segreto di attivazione, distinto dall’autenticatore stesso. La garanzia viene dall’intero progetto, non dal numero di richieste sullo schermo.

Registrazione, rinnovo e rimozione restano comunque in capo al proprietario dell’identità. Qualcuno decide ancora chi può registrarsi, lega la credenziale alla persona giusta e rende possibile la sostituzione quando un dispositivo va perso. Comprare una nuova chiave non revoca quella vecchia.

Descrivete la cerimonia di accesso prima di scegliere l’hardware: l’utente digita un codice, sblocca una chiave di firma o approva una richiesta del browser? Ogni risposta implica un client diverso, un’impostazione di gateway diversa e un copione diverso per l’assistenza.

Dove i flussi divergono in pratica

Un token a codice è il più facile da distribuire e il più debole contro una pagina contraffatta convincente, perché un codice digitato può essere inoltrato in tempo reale. Una chiave con certificato resiste a quella classe di attacco e costa di più da gestire, poiché emissione e revoca diventano parte del servizio. Una chiave FIDO sta con l’accesso web e dipende interamente dal fatto che il provider di identità la supporti per questa applicazione.

Gli ambienti misti sono comuni e non sono automaticamente sbagliati: un certificato per il tunnel più un token a codice per la console amministrativa è una separazione coerente, purché entrambi siano registrati sulla stessa identità. Ciò che si rompe è una separazione che nessuno ha documentato, dove l’assistenza non sa dire quale fattore manchi a un utente.

Rendete la decisione concreta

Scrivete la cerimonia come una sequenza di passi che un utente reale esegue, poi verificate che il client, il gateway e il provider di identità supportino tutti quella sequenza. Un disallineamento compare di solito all’ultimo passo, dove il client non riesce affatto a indirizzare il dispositivo.

Poi confermate cosa succede quando il dispositivo va perso o il certificato scade. Se quella risposta non è scritta, il rollout ha una lacuna che verrà scoperta un lunedì mattina.

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