MFA-tjenesten nede: avgjør VPN-tilgang før den svikter

VPN-tilgang stopper, og varselet sier at andrefaktor-tjenesten ikke er tilgjengelig. Om noen fortsatt kan koble til, er et policy-spørsmål som skulle vært besvart før avbruddet, ikke under det. En utilgjengelig verifikator er ikke bevis for at en faktor er bestått, og en avvist utfordring er ikke samme hendelse som en utilgjengelig. Runbooken nedenfor gjør den forskjellen om til en skriftlig regel du kan teste.

Trinn 1: navngi de tre utfallene hver for seg

Skriv ned tre tilstander og nekt å slå dem sammen: primær autentisering mislyktes, andrefaktor-utfordringen ble avvist eller utløp, og MFA-tjenesten svarte aldri. Hver har en annen eier, en annen logglinje og et annet riktig svar. Én generisk timeout-melding skjuler hvilken du er i, og den uklarheten er det som gjør et avbrudd til en diskusjon. Navngi tilstandene i runbooken før du trenger dem.

En avvisning betyr at verifikatoren svarte og sa nei, noe som er et policyresultat og ikke et tilgjengelighetsproblem. Et utløpt forsøk betyr at utfordringen fantes og ingen fullførte den i tide. En utilgjengelig tjeneste betyr at spørsmålet aldri ble besvart. Bare den tredje er et avbrudd.

Trinn 2: les feilmodusen proxyen faktisk bruker

Finn innstillingen som styrer oppførselen når tjenesten ikke kan kontaktes, og les den fra den kjørende konfigurasjonen i stedet for fra en mal. I Duos RADIUS-proxy er de dokumenterte failmode-verdiene safe og secure, der safe bare tillater et forsøk når primær autentisering lykkes, og secure avviser forsøket under den betingelsen.

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

Navnet safe beskriver et tilgjengelighetsvalg, ikke en garanti for at hver tillatt sesjon hadde en fersk andre faktor. Den setningen hører hjemme i risikoregisteret, fordi det er nøyaktig den avveiningen innstillingen gjør. Ikke generaliser verdien til en annen leverandør, en annen integrasjon eller en annen proxy-modus; les dokumentasjonen til det produktet for dets egen ekvivalent. En konfigurasjon kopiert fra et leverandøreksempel uten denne forståelsen er en overraskelse som venter på neste avbrudd.

Stopp hvis ingen kan si hvilken modus som er aktiv. Resten av runbooken avhenger av det svaret.

Trinn 3: få nye forsøk til å passe til flyten

Tilpass gatewayens timeout og oppførsel ved nye forsøk til autentiseringsflyten den driver. Ukoordinerte nye forsøk lager flere forespørsler, forvirrer forsøksparkobling og gjør at loggen ikke kan si hvilket resultat som hører til hvilken innlogging. En svært lang timeout er ikke en tilgjengelighetsdesign; det er en lengre ventetid på det samme svaret.

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

Proxyens egen forespørselstimeout er en separat grense: en autentiseringsforespørsel som sendes og aldri fullføres, avvises, og den avvisningen er ikke et avbrudd å falle tilbake fra. Behandle en avvisning, en ufullstendig utfordring og en utilgjengelig tjeneste som tre ulike innganger til beslutningstabellen din. Gjør deretter tabellen eksplisitt: hvilken tilstand slipper inn, hvilken tilstand holder igjen, og hvilken tilstand eskaleres til et menneske.

Hvis to komponenter begge prøver på nytt, rett først eierskapet til nye forsøk. Dupliserte forespørsler er et symptom på to eiere, ikke på en treg tjeneste.

Trinn 4: styr nødtilgang separat

Hvis nødtilgang er nødvendig, gi den eget omfang, identitet, autorisasjon og revisjonsspor. Stille deaktivering av MFA for alle brukere er ikke en nødprosedyre; det er en varig svekkelse med en hendelse festet til. Sikkerhetseieren godkjenner tilgangsregelen, synligheten og eskaleringsveien på forhånd.

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

Test hele matrisen i et ikke-produksjonsmiljø: primær feil, bevisst avvisning, utløp av utfordringen og utilgjengelighet av tjenesten. For hver av dem, registrer tilgangsresultatet og grunnen som ble logget. Ikke lag et produksjonsavbrudd for å oppdage den konfigurerte oppførselen, og ikke test nødveien for første gang under hendelsen den ble skrevet for. En gjenopprettingsprosedyre som aldri har kjørt, er et dokument, ikke en kontroll.

Runbooken slutter når de tre tilstandene er navngitt, feilmodusen er lest fra det kjørende systemet, nye forsøk har én eier, og nødtilgang har sin egen godkjenning og gjennomgang. Forutsigbar håndhevelse pluss en kjent gjenopprettingsvei er resultatet som er verdt å dokumentere.