MFA-tjänsten ligger nere: besluta om VPN-åtkomst i förväg

VPN-åtkomsten stoppar, och larmet säger att andrafaktor-tjänsten inte går att nå. Om någon fortfarande kan ansluta är en policyfråga som borde ha besvarats före avbrottet, inte under det. En otillgänglig verifierare är inte bevis för att en faktor har godkänts, och en avvisad utmaning är inte samma händelse som en onåbar. Runbooken nedan gör den skillnaden till en skriftlig regel som du kan testa.

Steg 1: namnge de tre utfallen var för sig

Skriv ned tre tillstånd och vägra slå ihop dem: primär autentisering misslyckades, andrafaktor-utmaningen avvisades eller löpte ut, och MFA-tjänsten svarade aldrig. Varje har en annan ägare, en annan logglinje och ett annat korrekt svar. Ett enda generiskt tidsgränsmeddelande döljer vilket du befinner dig i, och den otydligheten är det som gör ett avbrott till en diskussion. Namnge tillstånden i runbooken innan du behöver dem.

En avvisning betyder att verifieraren svarade och sade nej, vilket är ett policyresultat och inte ett tillgänglighetsproblem. Ett utgånget försök betyder att utmaningen fanns och att ingen slutförde den i tid. En otillgänglig tjänst betyder att frågan aldrig besvarades. Bara det tredje är ett avbrott.

Steg 2: läs det felläge som proxyn faktiskt använder

Hitta inställningen som styr beteendet när tjänsten inte kan kontaktas, och läs den från den körande konfigurationen i stället för från en mall. I Duos RADIUS-proxy är de dokumenterade failmode-värdena safe och secure, där safe bara tillåter ett försök när primär autentisering lyckas, och secure avvisar försöket under det villkoret.

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

Namnet safe beskriver ett tillgänglighetsval, inte en garanti för att varje tillåten session hade en färsk andra faktor. Den meningen hör hemma i riskregistret, eftersom det är precis den avvägning inställningen gör. Generalisera inte värdet till en annan leverantör, en annan integration eller ett annat proxyläge; läs dokumentationen för den produkten för dess egen motsvarighet. En konfiguration kopierad från ett leverantörsexempel utan denna förståelse är en överraskning som väntar på nästa avbrott.

Stanna om ingen kan säga vilket läge som är aktivt. Resten av runbooken beror på det svaret.

Steg 3: få nya försök att passa flödet

Anpassa gatewayens tidsgräns och beteende vid nya försök till det autentiseringsflöde den driver. Okoordinerade nya försök skapar flera förfrågningar, förvirrar ihopkopplingen av försök och lämnar loggen oförmögen att säga vilket resultat som hör till vilken inloggning. En mycket lång tidsgräns är inte en tillgänglighetsdesign; det är en längre väntan på samma svar.

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

Proxyns egen tidsgräns för förfrågan är en separat gräns: en autentiseringsförfrågan som skickas och aldrig slutförs avvisas, och den avvisningen är inte ett avbrott att falla tillbaka från. Behandla en avvisning, en oavslutad utmaning och en otillgänglig tjänst som tre olika indata i din beslutstabell. Gör sedan tabellen explicit: vilket tillstånd släpper in, vilket tillstånd håller kvar och vilket tillstånd eskalerar till en människa.

Om två komponenter båda försöker igen, rätta först ägandet av de nya försöken. Dubblerade förfrågningar är ett symptom på två ägare, inte på en långsam tjänst.

Steg 4: hantera nödåtkomst separat

Om nödåtkomst krävs, ge den egen omfattning, identitet, auktorisering och granskningsspår. Att tyst stänga av MFA för alla användare är inte en nödprocedur; det är en bestående försvagning med en incident fäst vid sig. Säkerhetsägaren godkänner åtkomsten, synligheten och eskaleringsvägen i förväg.

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

Testa hela matrisen i en icke-produktionsmiljö: primärt fel, avsiktlig avvisning, utmaningens utgång och tjänstens otillgänglighet. Registrera för varje fall åtkomstresultatet och skälet som loggades. Skapa inte ett produktionsavbrott för att upptäcka det konfigurerade beteendet, och testa inte nödvägen för första gången under incidenten den skrevs för. En återställningsprocedur som aldrig har körts är ett dokument, inte en kontroll.

Runbooken slutar när de tre tillstånden är namngivna, felläget är läst från det körande systemet, nya försök har en ägare och nödåtkomst har sin egen godkännande och granskning. Förutsägbar efterlevnad plus en känd återställningsväg är resultatet som är värt att dokumentera.