A Wähler Der Monitor kann Ihnen mitteilen, dass sich die Verifizierungsdaten geändert haben oder verschwunden sind. Es kann nicht festgestellt werden, dass ein Dienst noch sendet, dass sein privater Schlüssel mit dem veröffentlichten Schlüssel übereinstimmt oder dass seine Nachrichten ausgerichtet ankommen DKIM. Erstellen Sie separate Prüfungen für die veröffentlichte Konfiguration und das beobachtete Nachrichtenverhalten.
Beginnen Sie mit bekannten Versandrouten
Erstellen Sie ein Inventar aus der Konfiguration autorisierter Absender und repräsentativ empfangenen Nachrichten. Zeichnen Sie für jede Route den Geschäftsinhaber, die D-Domäne, den Selektor, den DNS Besitzer, den erwarteten TXT oder auf CNAME Vereinbarung, letzte beobachtete Signaturzeit und Lebenszyklusstatus. Gehen Sie nicht davon aus, dass durch das Erraten gemeinsamer Selektoren jeder Unterzeichner entdeckt wird. DKIM stellt den Selektor in jeder Signatur bereit, anstatt einen vollständigen DNS Aufzählungsdienst zu definieren.
Für eine Signatur mit s=invoice2 und d=brand.example, sehen Sie sich unter invoice2._domainkey.brand.example “ an RFC 6376 §3.6.2.1. Folgen Sie einem erwarteten CNAME zu seinen Verifizierungsdaten. Speichern Sie einen Beobachtungszeitstempel und einen Public-Key-Fingerabdruck, damit eine Änderung mit einer genehmigten Rotation verglichen werden kann. Sammeln Sie niemals private Schlüssel im Überwachungssystem.
Trennen Sie die Ergebnisse des Monitors
Eine fehlende Antwort, DNS Timeout, ein widerrufener Schlüssel und ein geänderter Schlüssel sind unterschiedliche Ereignisse. RFC 6376 §6.1.2 unterscheidet einen Schlüsselabfragefehler von einem fehlenden Schlüssel, und ein leerer p-Wert stellt einen Widerruf unter dar RFC 6376 §3.6.1. Erfassen Sie Reaktionsdetails, anstatt jeden Fehler in einen allgemeinen Ausfall umzuwandeln.
Ein vorhandener Schlüssel benötigt noch Syntax- und Algorithmusprüfungen. RFC 8301 §3.1 verbietet die Signierung und Verifizierung von rsa-sha1; RFC 8301 §3.2 aktualisiert die RSA-Größenanforderungen: Unterzeichner müssen mindestens 1024 Bit verwenden und sollten mindestens 2048 verwenden. Der Produktsupport und die aktuelle kryptografische Richtlinie der Organisation können strenger sein. Eine Änderung des Fingerabdrucks allein kann nicht Aufschluss darüber geben, ob eine Rotation autorisiert wurde.
Fügen Sie eine Live-Beweisschleife hinzu
Senden Sie kontrollierte Nachrichten über alle wichtigen Produktionswege an ein Postfach, dessen Rohnachricht und vertrauenswürdiges Authentifizierungsergebnis Sie überprüfen können. Notieren Sie die beobachteten d und s, das Verifizierungsergebnis und Ausrichtung mit Von. Üben Sie die Nachrichtenvarianten aus, die sich auf die nachgelagerte Verarbeitung auswirken könnten, z. B. HTML und Anhänge.
Illustrativer Monitor: DNS stellt weiterhin Rechnung2 bereit, aber eine neue Nachricht enthält „Nein“. DKIM-Signature. Die Veröffentlichungsprüfung ist erfolgreich, während die Signaturprüfung fehlschlägt. In einem anderen Fall existiert die Signatur, ist aber vorhanden Körper-Hash schlägt nach einer Änderung der Gateway-Fußzeile fehl. Keiner der Vorfälle wird dadurch gelöst, dass der DNS Eintrag für fehlerfrei erklärt wird. Dabei handelt es sich um synthetische Testfälle, nicht um gemessene Servicevorfälle.
Auch synthetische Tests haben Grenzen. Eine tägliche Untersuchung beweist nicht jede Nachricht zwischen den durchgeführten Untersuchungen. Kombinieren Sie es mit Empfängerberichten und Vorfallbeweisen und berücksichtigen Sie dabei den Umfang und die Verzögerung der Berichterstattung.
Leiten Sie umsetzbare Warnungen weiter
Hängen Sie Warnungen an eine Route und einen Besitzer an. Unterdrücken Sie nur ein explizit genehmigtes Wartungsfenster, bewahren Sie den Ereignisverlauf auf und bestätigen Sie den neuen Unterzeichner nach der Rotation mit neuer E-Mail. Eskalieren Sie unerwartete Schlüsseländerungen als mögliche Sicherheitsereignisse, ohne allein aufgrund einer Änderung eine Gefährdung zu erklären.
Entfernen Sie veraltete Bestandszeilen bewusst. Ein alter öffentlicher Schlüssel kann für die verzögerte Nachrichtenüberprüfung bestehen bleiben, auch wenn die Neusignierung gestoppt wurde. Unterscheiden Sie diesen geplanten Zustand von einer verlassenen Delegation. Das Dashboard sollte angeben, was wann und mit welcher Methode beobachtet wurde, damit DNS Zustand nie als Beweis für Live-Signierung getarnt wird.
Reproduzieren Sie die Warnungsentscheidung
Verwenden Sie vier synthetische Sonden, um die Alarmebenen getrennt zu halten. Eine Signatur mit d=brand.example und s=invoice2 wird invoice2._domainkey.brand.example zugeordnet. Wenn der öffentliche Schlüssel vorhanden ist, das bereitgestellte Empfängerergebnis jedoch ein Body-Hash-Fehler ist, lösen Sie eine Meldungsüberprüfungswarnung aus. Wenn der Schlüssel fehlt, lösen Sie eine Warnung wegen fehlendem Schlüssel aus. Wenn der erwartete Datensatz vorhanden ist, die Nachricht jedoch keine Signatur aufweist, lösen Sie eine Warnung wegen fehlender Signatur aus. Ein vorhandener Schlüssel und ein angegebenes bestandenes Ergebnis führen zu keiner Warnung für diese Sonde allein.
Bei diesen vier Entscheidungen handelt es sich um ein anschauliches Entscheidungsmodell mit erfundenen DNS Zuständen und bereitgestellten Empfängerergebnissen. Für diese Überprüfung wurde keine Live DNS Abfrage, kein Signierungstest oder keine kryptografische Überprüfung durchgeführt. Um den Monitor in Betrieb zu nehmen, ersetzen Sie ihn durch veraltete öffentliche Antworten und Rohnachrichten mit Ergebnissen von Ihrer vertrauenswürdigen Empfangsgrenze. Bewahren Sie diese verknüpften Beweise auf, bevor Sie eine Route als betriebsverifiziert bezeichnen.
Beweise für die nächste Entscheidung erforderlich
Behalten Sie für eine Body-Hash-Warnung das bereitgestellte Ergebnis bei und untersuchen Sie die Body-Darstellung, die C/L-Einstellungen, den BH-Wert und das Implementierungsverhalten. Eine Nichtübereinstimmung allein beweist nicht, dass der Inhalt vom Gateway geändert wurde. Markieren Sie eine Route ohne neue Sonde als unbeobachtet, auch wenn der Schlüssel vorhanden ist. Notieren Sie separat, ob die Ausrichtung überprüft wurde, da DKIM Durchgang allein kein ausgerichteter Durchlauf ist.