Jemand verliert ein Telefon, und das Ticket kommt als „VPN kaputt“ an. Diese Einordnung ist doppelt falsch: Das Konto existiert noch, und das Gateway vertraut dem Identitätsanbieter weiterhin, sodass der einzige defekte Teil ein Faktor ist, den die Person nicht mehr besitzt. Behandeln Sie es als Wiederherstellung und nicht als Ausfall: Prüfen Sie den Antragsteller, registrieren Sie einen Ersatz, ziehen Sie die verlorene Methode zurück und beweisen Sie dann, dass das Konto funktioniert. All das setzt voraus, dass der Plan vor dem Verlust geschrieben wurde, denn ihn während des Anrufs zu erfinden ist der Weg, auf dem MFA am Ende für alle abgeschaltet wird.

Schritt 1: Lesen Sie die registrierten Faktoren aus einem Datensatz, nicht aus dem Gedächtnis

Die erste Frage ist nicht, welches Gerät verloren ging, sondern was das Konto sonst noch nutzen kann. Ein Konto kann ein Passwort plus Push, einen zeitbasierten Code, einen Hardwareschlüssel und gedruckte Wiederherstellungscodes tragen, und einen davon zu verlieren ist ein ganz anderes Ereignis als den einzigen zu verlieren. Lesen Sie die Methodenliste aus dem Identitätssystem, statt den Benutzer zu bitten, sie sich zu merken, und in einem Microsoft-Entra-Mandanten ist die Abfrage eine Zeile:

Get-MgUserAuthenticationMethod -UserId [email protected]

Schreiben Sie dann den Wiederherstellungsdatensatz, solange das Konto noch funktioniert: Kontobezeichner, registrierte Faktoren, wo die Wiederherstellungscodes liegen, wer den Antragsteller unabhängig prüfen kann und welche Systeme das Konto erreicht. Bewahren Sie ihn in dem geschützten Inventar auf, das das Team bereits verwendet, niemals in einer Notiz, die auch aktive Codes enthält. Diese fünf Felder machen aus einem panischen Anruf eine Checkliste, und die NIST-Leitlinie zum Lebenszyklus von Authenticatoren behandelt Wiederherstellung als Teil des Nachweises und nicht als Ausnahme davon.

Erfassen Sie den Prüfkanal als eigenes Feld, denn genau diesen Teil lassen die Leute aus. Eine Telefonnummer, die am Konto hängt, ist kein unabhängiger Kanal, wenn die fragende Person auch das Telefon kontrolliert.

Schritt 2: Prüfen Sie den Antragsteller abseits des gestörten Pfads

Führen Sie die Identitätsprüfung über einen Kanal durch, der nicht von der VPN, dem Postfach oder dem verlorenen Gerät abhängt. Ein Rückruf auf eine Nummer aus dem HR-Datensatz oder eine persönliche Prüfung bei einer Führungskraft, die bereits im Verzeichnis steht, funktionieren beide; eine Chatnachricht vom Konto in Wiederherstellung funktioniert nicht. Die Prüfung betrifft die Person, nicht ihre Fähigkeit, Fragen zum Konto zu beantworten, weil Kontodetails durchsickern. Protokollieren Sie, wer die Anfrage geprüft hat und wann, da der nächste Prüfer beides wissen will.

Wenn die Anfrage mit Dringlichkeit und Druck kommt, die Prüfung zu überspringen, ist das der Moment, langsamer zu werden. Wiederherstellungsbetrug sieht genau wie ein hilfsbereiter Kollege in Eile aus.

Schritt 3: Registrieren Sie den Ersatz und ziehen Sie dann den alten Faktor zurück

Registrieren Sie den neuen Authenticator über den normalen Registrierungsablauf, niemals über eine administrative Umgehung. Entfernen Sie dann die verlorene Methode ausdrücklich, denn die Registrierung eines Ersatzes lässt den bisherigen Authenticator autorisiert, bis jemand ihn zurückzieht. Wenn das alte Gerät in fremden Händen sein könnte, behandeln Sie die Entfernung als dringend und folgen Sie dem Vorfallprozess statt dem Wiederherstellungsprozess. Widerrufen Sie bestehende Sitzungen im selben Durchgang, da eine vor der Änderung erstellte Sitzung sie überleben kann:

Revoke-MgUserSignInSession -UserId [email protected]

Den Faktor für alle anderen zu entfernen oder die Zertifikatsprüfungen des Gateways zu lockern, tauscht die Wiederherstellung einer Person gegen einen Ausfall, der die gesamte Bereitstellung trifft. Halten Sie die Änderung auf das einzelne Konto begrenzt und eskalieren Sie, wenn die Beweise auf eine breitere Kompromittierung deuten. Notieren Sie im Ticket, welcher Faktor zurückgezogen wurde und welcher ihn ersetzt hat.

Schritt 4: Beweisen Sie, dass das Konto in beide Richtungen funktioniert

Melden Sie sich einmal mit dem neuen Faktor über einen unterstützten Client an, und bestätigen Sie dann, dass das Konto noch die Ressourcen erreicht, die es vor dem Verlust erreichte. Testen Sie eine Ressource, die den Tunnel braucht, und eine, die ihn nicht braucht, damit ein Fehler auf die richtige Schicht zeigt. Versuchen Sie eine Anmeldung mit dem zurückgezogenen Faktor, und erwarten Sie eine Ablehnung statt einer Aufforderung, was beweist, dass die Entfernung gewirkt hat. Eine Aufforderung, die von einem bestehenden registrierten Gerät scheitert ist ein Aufforderungsproblem, kein Grund, alles neu zu registrieren.

Bitten Sie dann den Benutzer, dieselbe Anmeldung ohne Anleitung durchzuführen. Ihr erfolgreicher Test beweist die Konfiguration; sein Versuch beweist die Übergabe.

Schließen Sie das Ticket mit dem Zeitstempel der erfolgreichen Anmeldung und dem Namen des jetzt verwendeten Faktors. Aktualisieren Sie den Wiederherstellungsdatensatz im selben Durchgang, damit der nächste Verlust von einem genauen Inventar ausgeht statt von einem veralteten.

Schritt 5: Beseitigen Sie die Bedingung, die dies schmerzhaft machte

Jeder Wiederherstellungsanruf ist ein Beleg über das Registrierungsdesign. Hatte das Konto genau einen Faktor, verlangen Sie einen zweiten für alle in dieser Gruppe. Lagen die Wiederherstellungscodes auf dem verlorenen Laptop, ändern Sie, wo sie liegen. Brauchte die Prüfung eine Führungskraft im Urlaub, benennen Sie eine Vertretung. Jede Korrektur kostet einen Nachmittag und beseitigt die schlimmste Stunde des nächsten Vorfalls.

Lesen Sie dann den Datensatz aus Schritt eins gegen die Realität erneut. Listet er die Faktoren, die tatsächlich existieren, und erreicht der Prüfkanal noch einen Menschen? Ein Betriebshandbuch, das niemand aktualisiert, verfällt zu einem Dokument, das Leute während des Anrufs ignorieren, für den es geschrieben wurde.

Ähnliche Artikel