MFA-tjenesten nede: beslut VPN-adgang, før den svigter

VPN-adgang stopper, og alarmen siger, at andenfaktor-tjenesten er utilgængelig. Om nogen stadig kan forbinde, er et politikspørgsmål, som skulle være besvaret før afbrydelsen, ikke under den. En utilgængelig verifier er ikke bevis for, at en faktor er bestået, og en afvist udfordring er ikke samme hændelse som en utilgængelig. Proceduren nedenfor gør den forskel til en skriftlig regel, du kan teste.

Trin 1: navngiv de tre udfald hver for sig

Skriv tre tilstande ned, og afvis at slå dem sammen: den primære godkendelse mislykkedes, andenfaktor-udfordringen blev afvist eller timede ud, og MFA-tjenesten svarede aldrig. Hver har en anden ejer, en anden loglinje og et andet korrekt svar. Én generisk timeout-besked skjuler, hvilken du er i, og den uklarhed er det, der gør en afbrydelse til en diskussion. Navngiv tilstandene i proceduren, før du får brug for dem.

En afvisning betyder, at verifieren svarede og sagde nej, hvilket er et politikresultat og ikke et tilgængelighedsproblem. Et udløbet forsøg betyder, at udfordringen fandtes, og at ingen gennemførte den i tide. En utilgængelig tjeneste betyder, at spørgsmålet aldrig blev besvaret. Kun den tredje er en afbrydelse.

Trin 2: læs den fejltilstand, proxyen faktisk bruger

Find den indstilling, der styrer adfærden, når tjenesten ikke kan kontaktes, og læs den fra den kørende konfiguration i stedet for fra en skabelon. I Duos RADIUS-proxy er de dokumenterede failmode-værdier safe og secure, hvor safe kun tillader et forsøg, når den primære godkendelse lykkes, og secure afviser forsøget under den betingelse.

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

Navnet safe beskriver et tilgængelighedsvalg, ikke en garanti for, at hver tilladt session havde en frisk anden faktor. Den sætning hører i risikoregistret, fordi det er præcis den afvejning, indstillingen gør. Generalisér ikke værdien til en anden udbyder, en anden integration eller en anden proxy-tilstand; læs det produkts dokumentation for dets egen ækvivalent. En konfiguration kopieret fra et leverandøreksempel uden den forståelse er en overraskelse, der venter på den næste afbrydelse.

Stop, hvis ingen kan sige, hvilken tilstand der er aktiv. Resten af proceduren afhænger af det svar.

Trin 3: få gentagne forsøg til at passe til flowet

Tilpas gatewayens timeout og adfærd ved gentagne forsøg til det godkendelsesflow, den driver. Ukoordinerede gentagne forsøg skaber flere prompter, forvirrer forsøgsparring og efterlader loggen ude af stand til at sige, hvilket resultat der hører til hvilket login. En meget lang timeout er ikke et tilgængelighedsdesign; det er en længere ventetid på det samme svar.

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

Proxyens egen anmodningstimeout er en separat grænse: en godkendelsesanmodning, der udstedes og aldrig fuldføres, afvises, og den afvisning er ikke en afbrydelse at falde tilbage fra. Behandl en afvisning, en uafsluttet udfordring og en utilgængelig tjeneste som tre forskellige input til din beslutningstabel. Gør derefter tabellen eksplicit: hvilken tilstand tillader, hvilken tilstand holder, og hvilken tilstand eskalerer til et menneske.

Hvis to komponenter begge gentager forsøget, skal du først rette ejerskabet af gentagelserne. Dublerede prompter er et symptom på to ejere, ikke på en langsom tjeneste.

Trin 4: styr nødadgang separat

Hvis nødadgang er påkrævet, skal den have sit eget omfang, sin egen identitet, autorisation og revisionsspor. Stille deaktivering af MFA for alle brugere er ikke en nødprocedure; det er en permanent svækkelse med en hændelse hæftet på. Sikkerhedsejeren godkender adgangsreglen, synligheden og eskaleringsvejen på forhånd.

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

Test hele matricen i et ikke-produktionsmiljø: primær fejl, bevidst afvisning, udfordringsudløb og tjenesteutilgængelighed. For hver enkelt skal du registrere adgangsresultatet og den begrundelse, der blev logget. Opret ikke en produktionsafbrydelse for at opdage den konfigurerede adfærd, og test ikke nødvejen for første gang under den hændelse, den blev skrevet til. En gendannelsesprocedure, der aldrig er kørt, er et dokument, ikke en kontrol.

Proceduren slutter, når de tre tilstande er navngivet, fejltilstanden er læst fra det kørende system, gentagne forsøg har én ejer, og nødadgang har sin egen godkendelse og gennemgang. Forudsigelig håndhævelse plus en kendt gendannelsesvej er det resultat, der er værd at dokumentere.