MFA-tenesta nede: avgjer VPN-tilgang før ho sviktar

VPN-tilgang stoppar, og varselet seier at andrefaktor-tenesta ikkje er tilgjengeleg. Om nokon framleis kan kopla til, er eit policy-spørsmål som skulle vore svara før avbrotet, ikkje under det. Ein utilgjengeleg verifikator er ikkje prov på at ein faktor er bestått, og ei avvist utfordring er ikkje same hending som ei utilgjengeleg. Runboka nedanfor gjer den skilnaden om til ein skriven regel du kan teste.

Trinn 1: nemn dei tre utfalla kvar for seg

Skriv ned tre tilstandar og nekt å slå dei saman: primær autentisering mislukkast, andrefaktor-utfordringa vart avvist eller gjekk ut, og MFA-tenesta svara aldri. Kvar har ein annan eigar, ei anna logglinje og eit anna rett svar. Éi generisk timeout-melding skjuler kva du er i, og den uklarleiken er det som gjer eit avbrot til ein diskusjon. Nemn tilstandane i runboka før du treng dei.

Ei avvising betyr at verifikatoren svara og sa nei, noko som er eit policyresultat og ikkje eit tilgjengelegheitsproblem. Eit utløpt forsøk betyr at utfordringa fanst og ingen fullførte ho i tide. Ei utilgjengeleg teneste betyr at spørsmålet aldri vart svara. Berre den tredje er eit avbrot.

Trinn 2: les feilmodusen proxyen faktisk brukar

Finn innstillinga som styrer åtferda når tenesta ikkje kan kontaktast, og les ho frå den køyrande konfigurasjonen i staden for frå ein mal. I RADIUS-proxyen til Duo er dei dokumenterte failmode-verdiane safe og secure, der safe berre tillèt eit forsøk når primær autentisering lukkast, og secure avviser forsøket under den føresetnaden.

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

Namnet safe skildrar eit tilgjengelegheitsval, ikkje ein garanti for at kvar tillaten sesjon hadde ein fersk andre faktor. Den setninga høyrer heime i risikoregisteret, fordi det er nettopp den avveginga innstillinga gjer. Ikkje generaliser verdien til ein annan leverandør, ein annan integrasjon eller ein annan proxy-modus; les dokumentasjonen til det produktet for hans eigen ekvivalent. Ein konfigurasjon kopiert frå eit leverandørdøme utan denne forståinga er ei overrasking som ventar på neste avbrot.

Stopp om ingen kan seie kva modus som er aktiv. Resten av runboka heng på det svaret.

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

Tilpass timeouten og åtferda ved nye forsøk hos gatewayen til autentiseringsflyten han driv. Ukoordinerte nye forsøk lagar fleire førespurnader, forvirrar forsøksparkopling og gjer at loggen ikkje kan seie kva resultat som høyrer til kva innlogging. Ein svært lang timeout er ikkje ein tilgjengelegheitsdesign; det er ei lengre venting på det same svaret.

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

Den eigen timeouten til førespurnaden hos proxyen er ei separat grense: ein autentiseringsførespurnad som vert send og aldri fullført, vert avvist, og den avvisinga er ikkje eit avbrot å falle tilbake frå. Handsame ei avvising, ei ufullstendig utfordring og ei utilgjengeleg teneste som tre ulike inngangar til avgjerdsbordet ditt. Gjer deretter bordet eksplisitt: kva tilstand slepp inn, kva tilstand held att, og kva tilstand vert eskalert til eit menneske.

Om to komponentar begge prøver på nytt, rett først eigarskapet til dei nye forsøka. Dupliserte førespurnader er eit symptom på to eigarar, ikkje på ei treg teneste.

Trinn 4: styr naudtilgang separat

Om naudtilgang er naudsynt, gje han eige omfang, identitet, autorisasjon og revisjonsspor. Stille deaktivering av MFA for alle brukarar er ikkje ein naudprosedyre; det er ei varig svekking med ei hending festa til. Tryggleikseigaren godkjenner tilgangsregelen, synlegheita og eskaleringsvegen på førehand.

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

Test heile matrisa i eit ikkje-produksjonsmiljø: primær feil, medvite avvising, utløp av utfordringa og utilgjengelegheit av tenesta. For kvar av dei, registrer tilgangsresultatet og grunnen som vart logga. Ikkje lag eit produksjonsavbrot for å oppdage den konfigurerte åtferda, og ikkje test naudvegen for første gong under hendinga han vart skriven for. Ein gjenopprettingsprosedyre som aldri har køyrt, er eit dokument, ikkje ein kontroll.

Runboka sluttar når dei tre tilstandane er namngjevne, feilmodusen er lesen frå det køyrande systemet, nye forsøk har éin eigar, og naudtilgang har sin eigen godkjenning og gjennomgang. Føreseleleg handheving pluss ein kjend gjenopprettingsveg er resultatet som er verdt å dokumentere.