Servizio MFA giù: decidete l’accesso VPN prima del guasto

L’accesso VPN si ferma e l’avviso dice che il servizio di secondo fattore è irraggiungibile. Se qualcuno possa ancora connettersi è una questione di politica che andava decisa prima del guasto, non durante. Un verificatore non disponibile non è prova che un fattore sia passato, e una sfida respinta non è lo stesso evento di una irraggiungibile. Il runbook qui sotto trasforma quella distinzione in una regola scritta che potete testare.

Passo 1: nominate i tre esiti separatamente

Scrivete tre stati e rifiutate di fonderli: l’autenticazione primaria è fallita, la sfida del secondo fattore è stata negata o è scaduta, e il servizio MFA non ha mai risposto. Ognuno ha un proprietario diverso, una riga di log diversa e una risposta corretta diversa. Un solo messaggio generico di timeout nasconde in quale vi trovate, e proprio quell’ambiguità trasforma un guasto in una discussione. Nominate gli stati nel runbook prima di averne bisogno.

Un rifiuto significa che il verificatore ha risposto e ha detto no, che è un esito di politica e non un problema di disponibilità. Un tentativo scaduto significa che la sfida esisteva e nessuno l’ha completata in tempo. Un servizio irraggiungibile significa che la domanda non ha mai ricevuto risposta. Solo il terzo è un guasto.

Passo 2: leggete la modalità di guasto che il proxy usa davvero

Trovate l’impostazione che governa il comportamento quando il servizio non è contattabile e leggetela dalla configurazione in esecuzione, non da un modello. Nel proxy RADIUS di Duo, i valori documentati di failmode sono safe e secure, con safe che consente un tentativo solo quando l’autenticazione primaria riesce e secure che respinge il tentativo in quella condizione.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

Il nome safe descrive una scelta di disponibilità, non la garanzia che ogni sessione ammessa abbia avuto un secondo fattore recente. Quella frase appartiene al registro dei rischi, perché è esattamente lo scambio che l’impostazione fa. Non generalizzate il valore a un altro fornitore, un’altra integrazione o un’altra modalità del proxy; leggete la documentazione di quel prodotto per il suo equivalente. Una configurazione copiata da un esempio del fornitore senza questa comprensione è una sorpresa in attesa del prossimo guasto.

Fermatevi se nessuno sa dire quale modalità è attiva. Il resto del runbook dipende da quella risposta.

Passo 3: allineate i tentativi al flusso

Allineate il timeout e il comportamento dei tentativi del gateway al flusso di autenticazione che guida. Tentativi non coordinati creano più richieste, confondono l’accoppiamento dei tentativi e lasciano il log incapace di dire quale risultato appartiene a quale accesso. Un timeout molto lungo non è un progetto di disponibilità; è un’attesa più lunga per la stessa risposta.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

Il timeout proprio della richiesta del proxy è un limite separato: una richiesta di autenticazione emessa e mai completata viene respinta, e quel rifiuto non è un guasto da cui ripiegare. Trattate un rifiuto, una sfida incompiuta e un servizio irraggiungibile come tre input diversi nella vostra tabella di decisione. Poi rendete la tabella esplicita: quale stato ammette, quale stato trattiene e quale stato scala a una persona.

Se due componenti ritentano entrambi, correggete prima la proprietà dei tentativi. Le richieste duplicate sono il sintomo di due proprietari, non di un servizio lento.

Passo 4: governate l’accesso di emergenza a parte

Se serve un accesso di emergenza, dategli un proprio ambito, identità, autorizzazione e traccia di audit. Disattivare MFA in silenzio per tutti gli utenti non è una procedura di emergenza; è un indebolimento permanente con un incidente allegato. Il proprietario della sicurezza approva in anticipo la regola di ammissione, la visibilità e il percorso di escalation.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Provate l’intera matrice in un ambiente non di produzione: guasto primario, rifiuto deliberato, scadenza della sfida e indisponibilità del servizio. Per ciascuno, registrate l’esito di ammissione e il motivo annotato. Non create un guasto di produzione per scoprire il comportamento configurato e non provate il percorso di emergenza per la prima volta durante l’incidente per cui è stato scritto. Una procedura di ripristino mai eseguita è un documento, non un controllo.

Il runbook termina quando i tre stati sono nominati, la modalità di guasto è letta dal sistema in esecuzione, i tentativi hanno un solo proprietario e l’accesso di emergenza ha la propria approvazione e revisione. Un’applicazione prevedibile più un percorso di ripristino noto è l’esito che vale la pena documentare.