Ein Backup bringt wenig, bis ein autorisierter Bediener die richtige Konfiguration wiederherstellen und nachweisen kann, dass sie funktioniert. Beim Testen der Notfallwiederherstellung sollte die Abhängigkeit geprüft werden, die fehlschlagen könnte, und nicht nur bestätigt werden, dass eine Datei heruntergeladen werden kann. Verwenden Sie eine kontrollierte Umgebung und ein schriftliches Änderungsprotokoll, damit eine Übung nicht zu einem vermeidbaren Produktionsausfall wird.
Definieren Sie den Rückforderungsanspruch eng
Wählen Sie die zu testende Komponente aus: DNS Richtlinie, DKIM Veröffentlichung öffentlicher Schlüssel, Signierungsdienst, Relay-Konfiguration oder Berichtssammlung. Nennen Sie die betroffenen Dienste und Identitäten. Schreiben Sie die Basislinie, den vorgeschlagenen Wiederherstellungsstatus, den Genehmiger, das Testfenster und die Stoppbedingungen. NIST SP 800-34 Rev. 1 behandelt Tests und Planwartung als Teile der Notfallplanung; Dieser Leitfaden wendet diesen Ansatz auf die Authentifizierungskonfiguration an.
Stellen Sie veraltete Autorisierungen nicht wieder her, nur weil sie in einem historischen Backup enthalten sind. Gleichen Sie das Wiederherstellungsziel mit dem aktuell genehmigten Absenderinventar, den widerrufenen Anmeldeinformationen und den Eigentümeränderungen ab. Ein Byte-perfektes altes SPF Eintrag kann einen eingestellten Dienst erneut autorisieren. Ein wiederhergestellter öffentlicher DKIM Eintrag kann einen verlorenen privaten Signaturschlüssel nicht wiederherstellen.
Geben Sie beobachtbare Abnahmetests an
Vergleichen Sie für eine DNS Wiederherstellung den genauen Besitzernamen, den Eintragstyp, den Wert und die relevante TTL mit dem genehmigten Ziel. Fragen Sie die Autorität und genehmigte rekursive Resolver ab und behalten Sie dabei Zeitstempel bei. Senden Sie zum Signieren kontrollierte Nachrichten über die tatsächlich wiederhergestellte Route und überprüfen Sie die Ergebnisse des vertrauenswürdigen Empfängers. Testen Sie kritisches Anwendungsverhalten und Authentifizierung. Die Aufnahme von Berichten erfordert separate Eingabe-, Parsing- und Abrufprüfungen.
Definieren Sie Rollback-Auslöser vor der Übung, z. B. eine unerwartete Autorisierung, ein fehlgeschlagenes kritisches Beispiel oder die Unfähigkeit, den Zielzustand zu bestätigen. Ein Trigger sollte einen Besitzer und eine ausführbare Aktion benennen. Die Wiederherstellung der Grundlinie ist nur dann sinnvoll, wenn diese Grundlinie weiterhin autorisiert und sicher ist. Eine kompromittierte oder übertragene Identität erfordert möglicherweise einen anderen Wiederherstellungsplan.
Geben Sie einen schriftlichen Wiederherstellungsfall an
Für den veranschaulichenden Plan RECOVERY-01 ist das genaue Ziel Zone brand.test, Eigentümer _dmarc.brand.test , Typ TXT , Wert v=DMARC1; p=none, TTL 300. Angenommen, der vorgeschlagene Vorfallstatus enthält fälschlicherweise v=DMARC1; p=reject. Hierbei handelt es sich um einen eingeschränkten Richtlinien-Datensatz-Vergleich, nicht um eine Empfehlung zur Abschwächung einer tatsächlichen Richtlinie oder um einen Beweis dafür, dass p=none das richtige Wiederherstellungsziel ist.
Der vorgeschlagene DNS Besitzer prüft die aktuelle Genehmigung, bevor er das genaue Ziel wiederherstellt. Die Akzeptanz erfordert maßgebliche und genehmigte rekursive Beobachtungen, datierte Ergebnisse vertrauenswürdiger Empfänger für kritische Routen und eine Bestätigung des Geschäftsinhabers. Es werden keine tatsächlichen Eigentümer, Genehmigungen, Zeitstempel, Hashes oder Beobachtungen angegeben. Wenn die Autorität übereinstimmt, während ein Resolver den vorherigen Wert beibehält, markieren Sie die Weitergabe als ungelöst und zeichnen Sie die verbleibende TTL auf, anstatt den globalen Abschluss zu deklarieren.
Ein nicht übereinstimmender Wert, eine unbeabsichtigte Autorität oder ein fehlgeschlagener kritischer Weg lösen einen Stopp und eine Überprüfung durch den Vorfalleigentümer aus. Stellen Sie einen früheren Zustand nur dann wieder her, wenn er ausdrücklich genehmigt und sicher bleibt. Andernfalls verwenden Sie ein separat autorisiertes Wiederherstellungsziel. Dabei handelt es sich um schriftlich erwartete Entscheidungen. Es wurde keine Konfigurationsänderung, kein Loopback-Resolver, keine öffentliche DNS Abfrage oder kein Nachrichtentest ausgeführt.
Erfassen Sie Mängel und wiederholen Sie den fehlgeschlagenen Teil
Behalten Sie das Original-Backup, das genehmigte Ziel, den genauen Unterschied, Beobachtungen, Nachrichtennachweise, die verstrichene Zeit und Bedienerentscheidungen bei. Hashing-Artefakte helfen bei der Identifizierung der überprüften Bytes, beweisen jedoch nicht, dass sie autorisiert waren. Bewahren Sie den Genehmigungsnachweis getrennt auf. Wenn der Test fehlschlägt, behalten Sie die fehlgeschlagene Ausgabe bei, anstatt den Übungsverlauf so umzuschreiben, dass er wie ein Erfolg aussieht.
Weisen Sie den Eigentümern Korrekturmaßnahmen zu und testen Sie die Bedingungen erneut. Unterscheiden Sie im Abschlussbericht zwischen einer erfolgreichen lokalen Wiederherstellung, einer erfolgreichen Provider-Wiederherstellung und einer erfolgreichen End-to-End-Anwendungswiederherstellung. Beanspruchen Sie nur die tatsächlich ausgeübte Schicht. Wiederholen Sie den entsprechenden Test nach wesentlichen Änderungen an DNS Hosting, -Signatur, -Anwendungen oder -Zugriffsvereinbarungen. Es geht um eine ausführbare Wiederherstellungsfunktion, nicht um eine vollständige Checkliste.