Due controlli di accesso non sono due fattori: VPN e RADIUS

Aggiungere un secondo backend di autenticazione a un gateway VPN sembra aggiungere un secondo fattore. Di solito aggiunge un secondo controllo, che è un oggetto diverso con modi di guasto diversi. Se entrambi debbano riuscire, cosa dimostra ciascuno e cosa succede quando uno non è disponibile sono tre decisioni separate. Sbagliatele e il gateway finisce più severo nella dimostrazione e più debole durante un’interruzione.

Che cosa dimostra davvero un secondo backend

Una ricerca nell’account locale dimostra che un nome esiste in un database e che una password vi corrispondeva. Uno scambio RADIUS dimostra che un server RADIUS ha restituito Access-Accept per gli attributi ricevuti. Nessuna delle due affermazioni menziona un tipo di fattore, perché entrambi verificano una conoscenza. E la guida all’identità digitale del NIST conta tipi di fattore distinti e i loro autenticatori, non server o richieste.

Esiste una progettazione legittima in cui partecipano entrambi i sistemi. Un servizio centrale può autenticare la persona mentre il gateway verifica in modo indipendente se quell’account ha diritto a questo tunnel. È autorizzazione accanto all’autenticazione, e chiamarla due fattori confonde un controllo di politica con una prova di possesso.

RADIUS può portare un vero secondo fattore quando precede qualcosa che ne verifica uno, come un’approvazione push o un token hardware. La busta non dice quali autenticatori abbia mostrato l’utente, quindi leggete la politica del backend invece dell’etichetta del gateway.

AND, OR e la riserva sono prodotti diversi

Prima di confrontare le implementazioni, decidete cosa significa entrambi nella vostra esigenza. Una politica AND richiede che ogni controllo nominato passi, una politica OR accetta quello che riesce, e una riserva prova il secondo solo in condizioni di guasto dichiarate. Questi tre si comportano in modo opposto durante un’interruzione, e di solito solo uno è ciò che la revisione intendeva.

Aggiungere due voci di backend a una schermata di configurazione non rivela quale politica applichi il prodotto. Alcuni gateway concatenano i plugin in ordine e si fermano al primo rifiuto, che è AND solo quando ogni plugin è obbligatorio. Altri trattano l’account locale come una sostituzione, il che trasforma un’interruzione centrale in un bypass. La risposta affidabile è un test negativo documentato per ogni percorso, eseguito sulla build che distribuite.

La riserva merita il maggiore sospetto, perché esiste per continuare a funzionare quando qualcosa è rotto. Una riserva che accetta una password locale ogni volta che RADIUS non è raggiungibile ha trasformato una politica centrale in una seconda porta più debole.

Il doppio controllo di OpenVPN è un caso concreto

OpenVPN comunitario 2.6 richiede sia un certificato client sia lo script auth-user-pass-verify configurato quando entrambi sono abilitati. È un AND documentato tra la verifica del certificato e uno script di credenziali, e sono davvero due controlli. Non è però automaticamente due tipi di fattore, dato che lo script può validare solo una password.

La combinazione lascia aperta anche la questione dell’associazione. Un certificato identifica di solito un dispositivo mentre le credenziali identificano una persona, e nulla nel flusso predefinito richiede che entrambi si riferiscano allo stesso principale. Decidete quali coppie sono ammesse, poi imponete quella mappa dentro lo script di verifica o in un passaggio di autorizzazione successivo.

La modalità solo certificato è un unico controllo, sostenuto da una chiave che può avere o non avere un PIN. Un PIN trasforma la stessa credenziale in conoscenza più possesso solo se la chiave non può essere usata senza di esso. Lasciare quella chiave non cifrata sul disco riduce la seconda parte a un permesso di file.

I produttori di appliance costruiscono il proprio impianto, spesso un modulo PAM o un plugin RADIUS dietro una console web. Il comportamento della comunità è un riferimento su come sono i doppi controlli, non una descrizione di come un’appliance li combini.

Verificate la combinazione sul vostro gateway

Leggete la configurazione prima di fidarvi del riepilogo della console. Le righe che decidono la politica sono la modalità del certificato, lo script delle credenziali e l’ordine dei plugin.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

Il grep mostra se serve un certificato e quale script viene eseguito dopo, e l’ordine conta più di quanto suggeriscano i nomi. Il dump del certificato dà l’identità che il gateway vedrà, inclusi il CN e il numero di serie necessari per la mappa di associazione. Il test RADIUS è il caso negativo: una password errata deve produrre Access-Reject, e una corretta Access-Accept. Se una credenziale rifiutata produce comunque una sessione, lo script non è affatto sul percorso di autenticazione.

Poi eseguite il caso di interruzione su un’istanza di laboratorio: fermate il backend obbligatorio e collegatevi con credenziali valide. Il risultato atteso è un rifiuto, e qualsiasi altra cosa è la politica di riserva che nessuno ha documentato.

Scrivete il requisito come casi negativi

Un requisito utilizzabile nomina le prove, gli account autorizzati a presentarle e il risultato quando manca un verificatore. Indica anche l’accoppiamento consentito tra identità del dispositivo e identità della persona. È più preciso dei nomi di prodotto sull’ordine d’acquisto, ed è verificabile.

L’accettazione dovrebbe includere quattro rifiuti: un account locale non idoneo, una prova obbligatoria mancante, un secondo fattore non valido e un backend obbligatorio irraggiungibile. Ogni rifiuto ha bisogno di una riga di log che lo distingua dagli altri, altrimenti il prossimo incidente inizia con congetture. Registrate quale componente ha preso ogni decisione, perché gateway, server RADIUS e directory si accuseranno a vicenda.

Ripetete i quattro rifiuti dopo ogni modifica di plugin o firmware. Sono economici, e la politica che proteggono è la parte che un attaccante sonda per prima.