MFA-Dienst ausgefallen: VPN-Zugang vorher entscheiden

Der VPN-Zugang stoppt, und der Alarm meldet, dass der Zweitfaktor-Dienst nicht erreichbar ist. Ob sich noch jemand verbinden kann, ist eine Richtlinienfrage, die vor dem Ausfall hätte beantwortet werden müssen, nicht währenddessen. Ein nicht verfügbarer Verifier ist kein Beweis dafür, dass ein Faktor bestanden wurde, und eine abgelehnte Challenge ist nicht dasselbe Ereignis wie eine unerreichbare. Das Runbook unten macht aus dieser Unterscheidung eine schriftliche Regel, die Sie testen können.

Schritt 1: benennen Sie die drei Ergebnisse getrennt

Schreiben Sie drei Zustände auf und weigern Sie sich, sie zusammenzufassen: primäre Authentifizierung fehlgeschlagen, die Zweitfaktor-Challenge abgelehnt oder abgelaufen, und der MFA-Dienst hat nie geantwortet. Jeder hat einen anderen Verantwortlichen, eine andere Logzeile und eine andere richtige Reaktion. Eine einzige allgemeine Timeout-Meldung verbirgt, in welchem Sie sich befinden, und genau diese Unklarheit macht aus einem Ausfall eine Diskussion. Benennen Sie die Zustände im Runbook, bevor Sie sie brauchen.

Eine Ablehnung bedeutet, dass der Verifier geantwortet und Nein gesagt hat, was ein Richtlinienergebnis und kein Verfügbarkeitsproblem ist. Ein abgelaufener Versuch bedeutet, dass die Challenge existierte und niemand sie rechtzeitig abgeschlossen hat. Ein nicht erreichbarer Dienst bedeutet, dass die Frage überhaupt nie beantwortet wurde. Nur der dritte Fall ist ein Ausfall.

Schritt 2: lesen Sie den Fehlermodus, den der Proxy tatsächlich nutzt

Finden Sie die Einstellung, die das Verhalten steuert, wenn der Dienst nicht kontaktiert werden kann, und lesen Sie sie aus der laufenden Konfiguration statt aus einer Vorlage. Im RADIUS-Proxy von Duo sind die dokumentierten failmode-Werte safe und secure, wobei safe einen Versuch nur zulässt, wenn die primäre Authentifizierung gelingt, und secure den Versuch unter dieser Bedingung ablehnt.

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

Der Name safe beschreibt eine Verfügbarkeitsentscheidung, keine Garantie, dass jede zugelassene Sitzung einen frischen zweiten Faktor hatte. Dieser Satz gehört ins Risikoregister, denn er ist genau der Kompromiss, den die Einstellung eingeht. Verallgemeinern Sie den Wert nicht auf einen anderen Anbieter, eine andere Integration oder einen anderen Proxy-Modus; lesen Sie die Dokumentation dieses Produkts für sein eigenes Äquivalent. Eine aus einem Herstellerbeispiel kopierte Konfiguration ohne dieses Verständnis ist eine Überraschung, die auf den nächsten Ausfall wartet.

Halten Sie an, wenn niemand sagen kann, welcher Modus aktiv ist. Der Rest des Runbooks hängt von dieser Antwort ab.

Schritt 3: Wiederholungen an den Ablauf anpassen

Gleichen Sie Timeout und Wiederholungsverhalten des Gateways auf den Authentifizierungsablauf ab, den es steuert. Unkoordinierte Wiederholungen erzeugen mehrere Abfragen, verwirren die Zuordnung der Versuche und lassen das Log nicht sagen, welches Ergebnis zu welchem Login gehört. Ein sehr langer Timeout ist kein Verfügbarkeitsdesign; er ist eine längere Wartezeit auf dieselbe Antwort.

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

Der eigene Anforderungs-Timeout des Proxys ist eine separate Grenze: eine Authentifizierungsanforderung, die ausgestellt und nie abgeschlossen wird, wird abgelehnt, und diese Ablehnung ist kein Ausfall, von dem man zurückfällt. Behandeln Sie eine Ablehnung, eine unvollendete Challenge und einen nicht erreichbaren Dienst als drei verschiedene Eingaben in Ihre Entscheidungstabelle. Machen Sie die Tabelle dann explizit: welcher Zustand lässt zu, welcher Zustand hält, und welcher Zustand eskaliert an einen Menschen.

Wenn zwei Komponenten beide wiederholen, korrigieren Sie zuerst die Zuständigkeit für Wiederholungen. Doppelte Abfragen sind ein Symptom zweier Verantwortlicher, nicht eines langsamen Dienstes.

Schritt 4: Notfallzugang separat regeln

Wenn Notfallzugang erforderlich ist, geben Sie ihm eigenen Umfang, eigene Identität, Autorisierung und Audit-Trail. MFA für alle Nutzer still abzuschalten ist kein Notfallverfahren; es ist eine dauerhafte Schwächung mit einem Vorfall daran. Der Sicherheitsverantwortliche genehmigt die Zugangsregel, die Sichtbarkeit und den Eskalationsweg im Voraus.

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

Testen Sie die gesamte Matrix in einer Nicht-Produktionsumgebung: Primärausfall, absichtliche Ablehnung, Ablauf der Challenge und Nichtverfügbarkeit des Dienstes. Halten Sie für jeden Fall das Zugangsergebnis und den protokollierten Grund fest. Erzeugen Sie keinen Produktionsausfall, um das konfigurierte Verhalten zu entdecken, und testen Sie den Notfallweg nicht zum ersten Mal während des Vorfalls, für den er geschrieben wurde. Ein Wiederherstellungsverfahren, das nie gelaufen ist, ist ein Dokument, keine Kontrolle.

Das Runbook endet, wenn die drei Zustände benannt sind, der Fehlermodus aus dem laufenden System gelesen wurde, Wiederholungen einen Verantwortlichen haben und Notfallzugang seine eigene Genehmigung und Überprüfung hat. Vorhersehbare Durchsetzung plus ein bekannter Wiederherstellungsweg ist das Ergebnis, das es wert ist, dokumentiert zu werden.