Accesul VPN se oprește, iar alerta spune că serviciul de al doilea factor este inaccesibil. Dacă cineva se mai poate conecta este o întrebare de politică la care trebuia răspuns înainte de întrerupere, nu în timpul ei. Un verificator indisponibil nu este dovada că un factor a trecut, iar o provocare respinsă nu este același eveniment cu una inaccesibilă. Ghidul de mai jos transformă această distincție într-o regulă scrisă pe care o puteți testa.

Pasul 1: numiți cele trei rezultate separat

Scrieți trei stări și refuzați să le contopiți: autentificarea primară a eșuat, provocarea celui de-al doilea factor a fost refuzată sau a expirat, iar serviciul MFA nu a răspuns niciodată. Fiecare are alt proprietar, altă linie de jurnal și alt răspuns corect. Un singur mesaj generic de depășire a timpului ascunde în care vă aflați, iar această ambiguitate este ce transformă o întrerupere într-o discuție. Numiți stările în ghid înainte de a avea nevoie de ele.

Un refuz înseamnă că verificatorul a răspuns și a spus nu, ceea ce este un rezultat de politică și nu o problemă de disponibilitate. O încercare expirată înseamnă că provocarea a existat și nimeni nu a finalizat-o la timp. Un serviciu inaccesibil înseamnă că întrebarea nu a primit niciun răspuns. Doar a treia este o întrerupere.

Pasul 2: citiți modul de eșec pe care proxy-ul îl folosește efectiv

Găsiți setarea care guvernează comportamentul când serviciul nu poate fi contactat și citiți-o din configurația în execuție, nu dintr-un șablon. În proxy-ul RADIUS al Duo, valorile documentate pentru failmode sunt safe și secure, unde safe permite o încercare doar când autentificarea primară reușește, iar secure respinge încercarea în acea condiție.

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

Numele safe descrie o alegere de disponibilitate, nu o garanție că fiecare sesiune admisă a avut un al doilea factor proaspăt. Acea propoziție aparține registrului de riscuri, pentru că este exact schimbul pe care îl face setarea. Nu generalizați valoarea la alt furnizor, altă integrare sau alt mod de proxy; citiți documentația acelui produs pentru echivalentul său. O configurație copiată dintr-un exemplu al furnizorului fără această înțelegere este o surpriză care așteaptă următoarea întrerupere.

Opriți-vă dacă nimeni nu poate spune care mod este activ. Restul ghidului depinde de acel răspuns.

Pasul 3: aliniați reîncercările la flux

Aliniați timpul de așteptare și comportamentul la reîncercare al gateway-ului cu fluxul de autentificare pe care îl conduce. Reîncercările necoordonate creează mai multe solicitări, încurcă potrivirea încercărilor și lasă jurnalul incapabil să spună care rezultat aparține cărei autentificări. Un timp de așteptare foarte lung nu este un proiect de disponibilitate; este o așteptare mai lungă pentru același răspuns.

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

Timpul de așteptare propriu al solicitării din proxy este o limită separată: o solicitare de autentificare emisă și niciodată finalizată este respinsă, iar acel refuz nu este o întrerupere din care să vă retrageți. Tratați un refuz, o provocare neterminată și un serviciu inaccesibil ca trei intrări diferite în tabelul de decizie. Apoi faceți tabelul explicit: care stare admite, care stare reține și care stare escaladează către o persoană.

Dacă două componente reîncearcă amândouă, corectați mai întâi proprietatea reîncercărilor. Solicitările duplicate sunt un simptom al doi proprietari, nu al unui serviciu lent.

Pasul 4: guvernați accesul de urgență separat

Dacă este necesar acces de urgență, dați-i propriul domeniu, identitate, autorizare și urmă de audit. Dezactivarea în tăcere a MFA pentru toți utilizatorii nu este o procedură de urgență; este o slăbire permanentă cu un incident atașat. Proprietarul securității aprobă în avans regula de admitere, vizibilitatea și calea de escaladare.

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

Testați întreaga matrice într-un mediu care nu este de producție: eșec primar, refuz deliberat, expirarea provocării și indisponibilitatea serviciului. Pentru fiecare, înregistrați rezultatul admiterii și motivul care a fost jurnalizat. Nu creați o întrerupere de producție pentru a descoperi comportamentul configurat și nu testați calea de urgență pentru prima dată în timpul incidentului pentru care a fost scrisă. O procedură de recuperare care nu a rulat niciodată este un document, nu un control.

Ghidul se termină când cele trei stări sunt numite, modul de eșec este citit din sistemul în execuție, reîncercările au un singur proprietar și accesul de urgență are propria aprobare și revizuire. Aplicarea previzibilă plus o cale de recuperare cunoscută este rezultatul care merită documentat.

Articole similare