MFA-diens af: besluit vooraf oor VPN-toelating
’n Onbereikbare tweede-faktor-diens is nie ’n verwerpte uitdaging nie. Dokumenteer die toelatingsreël, die herpogingsgedrag en wie noodtoegang mag gebruik.
VPN-toelating stop, en die waarskuwing sê die tweede-faktor-diens is onbereikbaar. Of enigiemand nog kan koppel, is ’n beleidsvraag wat voor die onderbreking beantwoord moes gewees het, nie tydens dit nie. ’n Onbeskikbare verifieerder is nie bewys dat ’n faktor geslaag het nie, en ’n verwerpte uitdaging is nie dieselfde gebeurtenis as ’n onbereikbare een nie. Die runbook hieronder verander daardie onderskeid in ’n geskrewe reël wat jy kan toets.
Stap 1: benoem die drie uitkomste afsonderlik
Skryf drie toestande neer en weier om hulle saam te gooi: primêre verifikasie het misluk, die tweede-faktor-uitdaging is geweier of het tyd uitgeloop, en die MFA-diens het nooit geantwoord nie. Elkeen het ’n ander eienaar, ’n ander logreël en ’n ander korrekte reaksie. ’n Enkele generiese tydsverloopboodskap verberg in watter een jy is, en daardie dubbelsinnigheid is wat ’n onderbreking in ’n argument verander. Benoem die toestande in die runbook voordat jy hulle nodig het.
’n Weiering beteken die verifieerder het geantwoord en nee gesê, wat ’n beleidsuitkoms is eerder as ’n beskikbaarheidsprobleem. ’n Verval poging beteken die uitdaging het bestaan en niemand het dit betyds voltooi nie. ’n Onbereikbare diens beteken die vraag is glad nie beantwoord nie. Net die derde een is ’n onderbreking.
Stap 2: lees die foutmodus wat die proxy werklik gebruik
Vind die instelling wat gedrag beheer wanneer die diens nie gekontak kan word nie, en lees dit uit die lopende konfigurasie eerder as uit ’n sjabloon. In Duo se RADIUS-proxy is die gedokumenteerde failmode-waardes safe en secure, waar safe ’n poging net toelaat wanneer primêre verifikasie slaag, en secure die poging in daardie toestand verwerp.
radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager
Die naam safe beskryf ’n beskikbaarheidskeuse, nie ’n waarborg dat elke toegelate sessie ’n nuwe tweede faktor gehad het nie. Daardie sin hoort in die risikoregister, want dit is die presiese ruil wat die instelling maak. Moenie die waarde veralgemeen na ’n ander verskaffer, ’n ander integrasie of ’n ander proxymodus nie; lees daardie produk se dokumentasie vir sy eie ekwivalent. ’n Konfigurasie wat uit ’n verskaffer-voorbeeld gekopieer is sonder hierdie begrip, is ’n verrassing wat op die volgende onderbreking wag.
Stop as niemand kan sê watter modus aktief is nie. Die res van die runbook hang van daardie antwoord af.
Stap 3: laat herpogings by die vloei pas
Belyn die gateway se tydsverloop en herpogingsgedrag met die verifikasievloei wat dit aandryf. Ongekoördineerde herpogings skep veelvuldige vrae, verwar poging-passing en laat die log nie weet watter resultaat by watter aanmelding hoort nie. ’n Baie lang tydsverloop is nie ’n beskikbaarheidsontwerp nie; dit is ’n langer wag vir dieselfde antwoord.
ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log
Die proxy se eie versoek-tydsverloop is ’n aparte beperking: ’n verifikasieversoek wat uitgereik en nooit voltooi word nie, word verwerp, en daardie verwerping is nie ’n onderbreking om van terug te val nie. Behandel ’n weiering, ’n onvoltooide uitdaging en ’n onbereikbare diens as drie verskillende insette tot jou besluitstabel. Maak dan die tabel eksplisiet: watter toestand laat toe, watter toestand hou, en watter toestand eskaleer na ’n mens.
As twee komponente albei herprobeer, regstel eers die eienaarskap van herpogings. Dubbele vrae is ’n simptoom van twee eienaars, nie van ’n stadige diens nie.
Stap 4: regeer noodtoegang afsonderlik
As noodtoegang vereis word, gee dit sy eie omvang, identiteit, magtiging en ouditspoor. Om MFA vir alle gebruikers stilweg te deaktiveer, is nie ’n noodprosedure nie; dit is ’n permanente verswakking met ’n voorval daaraan gekoppel. Die sekuriteitseienaar keur die toelatingsreël, die sigbaarheid en die eskalasiepad vooraf goed.
grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy
Toets die hele matriks in ’n nie-produksie-omgewing: primêre mislukking, doelbewuste weiering, uitdaging-verval en diens-onbeskikbaarheid. Vir elkeen, teken die toelatingsresultaat en die rede wat gelog is aan. Moenie ’n produksie-onderbreking skep om die gekonfigureerde gedrag te ontdek nie, en moenie die noodpad vir die eerste keer tydens die voorval waarvoor dit geskryf is, toets nie. ’n Herstelprosedure wat nog nooit geloop het nie, is ’n dokument, nie ’n beheer nie.
Die runbook eindig wanneer die drie toestande benoem is, die foutmodus uit die lopende stelsel gelees is, herpogings een eienaar het, en noodtoegang sy eie goedkeuring en hersiening het. Voorspelbare handhawing plus ’n bekende herstelpad is die uitkoms wat die moeite werd is om te dokumenteer.