MFA-dienst plat: beslis VPN-toegang voordat het misgaat
Een onbereikbare tweedefactor-dienst is geen afgewezen uitdaging. Documenteer de toegangsregel, het gedrag bij herhalingen en wie noodtoegang mag gebruiken.
VPN-toegang stopt, en de melding zegt dat de tweedefactor-dienst onbereikbaar is. Of iemand nog kan verbinden is een beleidsvraag die vóór de storing beantwoord had moeten zijn, niet tijdens. Een niet-beschikbare verificator is geen bewijs dat een factor is geslaagd, en een afgewezen uitdaging is niet dezelfde gebeurtenis als een onbereikbare. De runbook hieronder maakt dat onderscheid tot een geschreven regel die u kunt testen.
Stap 1: benoem de drie uitkomsten apart
Schrijf drie toestanden op en weiger ze samen te voegen: primaire authenticatie mislukt, de tweedefactor-uitdaging geweigerd of verlopen, en de MFA-dienst heeft nooit geantwoord. Elk heeft een andere eigenaar, een andere logregel en een andere juiste reactie. Eén algemene time-outmelding verbergt in welke u zit, en juist die dubbelzinnigheid maakt van een storing een discussie. Benoem de toestanden in de runbook voordat u ze nodig hebt.
Een weigering betekent dat de verificator antwoordde en nee zei, wat een beleidsuitkomst is en geen beschikbaarheidsprobleem. Een verlopen poging betekent dat de uitdaging bestond en niemand die op tijd afmaakte. Een onbereikbare dienst betekent dat de vraag helemaal niet beantwoord werd. Alleen de derde is een storing.
Stap 2: lees de storingsmodus die de proxy echt gebruikt
Zoek de instelling die het gedrag bepaalt wanneer de dienst niet bereikbaar is, en lees die uit de draaiende configuratie in plaats van uit een sjabloon. In de RADIUS-proxy van Duo zijn de gedocumenteerde failmode-waarden safe en secure, waarbij safe een poging alleen toestaat als de primaire authenticatie slaagt, en secure de poging in die situatie weigert.
radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager
De naam safe beschrijft een beschikbaarheidskeuze, niet een garantie dat elke toegelaten sessie een verse tweede factor had. Die zin hoort in het risicoregister, want het is precies de ruil die de instelling maakt. Generaliseer de waarde niet naar een andere leverancier, een andere integratie of een andere proxymodus; lees de documentatie van dat product voor zijn eigen equivalent. Een configuratie die uit een leveranciersvoorbeeld is gekopieerd zonder dit begrip is een verrassing die op de volgende storing wacht.
Stop als niemand kan zeggen welke modus actief is. De rest van de runbook hangt van dat antwoord af.
Stap 3: laat herhalingen bij de flow passen
Lijn de time-out en het gedrag bij herhalingen van de gateway af op de authenticatieflow die hij aanstuurt. Ongecoördineerde herhalingen zorgen voor meerdere prompts, verwarren het koppelen van pogingen en laten het log niet kunnen zeggen welk resultaat bij welke login hoort. Een zeer lange time-out is geen beschikbaarheidsontwerp; het is langer wachten op hetzelfde antwoord.
ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log
De eigen time-out van de aanvraag bij de proxy is een aparte grens: een authenticatieaanvraag die wordt uitgevaardigd en nooit wordt afgerond, wordt geweigerd, en die weigering is geen storing om op terug te vallen. Behandel een weigering, een onvoltooide uitdaging en een onbereikbare dienst als drie verschillende invoeren voor uw beslisstabel. Maak de tabel daarna expliciet: welke toestand toelaat, welke toestand tegenhoudt en welke toestand naar een mens escaleert.
Als twee componenten allebei herhalen, herstel dan eerst het eigenaarschap van de herhalingen. Dubbele prompts zijn een symptoom van twee eigenaren, niet van een trage dienst.
Stap 4: beheer noodtoegang apart
Als noodtoegang nodig is, geef die dan een eigen scope, identiteit, autorisatie en auditspoor. MFA stil uitschakelen voor alle gebruikers is geen noodprocedure; het is een blijvende verzwakking met een incident eraan vast. De security-eigenaar keurt de toegangsregel, de zichtbaarheid en het escalatiepad vooraf goed.
grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy
Test de hele matrix in een niet-productieomgeving: primaire fout, bewuste weigering, verlopen van de uitdaging en onbeschikbaarheid van de dienst. Leg voor elk de toegangsuitkomst en de gelogde reden vast. Veroorzaak geen productiestoring om het geconfigureerde gedrag te ontdekken, en test het noodpad niet voor het eerst tijdens het incident waarvoor het is geschreven. Een herstelprocedure die nooit is gedraaid is een document, geen controle.
De runbook eindigt wanneer de drie toestanden zijn benoemd, de storingsmodus uit het draaiende systeem is gelezen, herhalingen één eigenaar hebben en noodtoegang zijn eigen goedkeuring en beoordeling heeft. Voorspelbare handhaving plus een bekend herstelpad is de uitkomst die het waard is om te documenteren.