DMARC und Verschlüsselung lösen verschiedene E-Mail-Risiken. DMARC hilft einem empfangenden System bei der Beurteilung, ob eine Domäne über einen ausgerichteten, authentifizierten Pfad verwendet wird. Die Verschlüsselung schützt Nachrichtendaten über einen Transport-Hop hinweg oder, bei einem anderen Design, zwischen Nachrichtenendpunkten. Keine Steuerung versorgt automatisch die andere.
Diese Unterscheidung ist wichtig, da dieselbe Nachricht gut authentifiziert werden kann und dennoch ohne die von Ihnen beabsichtigte Transportsicherung übertragen werden kann. Eine Nachricht kann auch über eine verschlüsselte Verbindung übertragen werden und dabei eine Absenderdomäne beanspruchen, die über keine abgestimmte Authentifizierung verfügt.
Beginnen Sie mit der Schutzfrage
Fragen Sie, was geschützt werden muss, bevor Sie das Steuerelement auswählen:
- Schutzfrage: Ist eine vorbeigehende authentifizierte Domäne mit der Domäne in „From“ abgeglichen?; Relevanter Mechanismus: DMARC mit SPF oder DKIM; Was nicht festgestellt wird: Vertraulichkeit, Absicht des Absenders oder sichere Inhalte
- Schutzfrage: Wurde die Nachricht von einem Inhaber eines privaten DKIM -Schlüssels für die d=-Domäne signiert?; Relevanter Mechanismus: DKIM ; Was dadurch nicht festgestellt wird: Menschliche Identität, Geheimhaltung oder Posteingangsplatzierung
- Schutzfrage: War dieser SMTP -Zustellhop erforderlich, um akzeptables TLS zu verwenden?; Relevanter Mechanismus: MTA-STS oder eine andere Transportrichtlinie; Was es nicht herstellt: End-to-End-Vertraulichkeit oder From-Domain Ausrichtung
- Schutzfrage: Kann ein Empfänger Inhalte entschlüsseln, die für diesen Empfänger bestimmt sind?; Relevanter Mechanismus: Verschlüsselung auf Nachrichtenebene; Was nicht festgestellt wird: DMARC Ausrichtung, sofern nicht separat konfiguriert
Diese Matrix beschreibt Kontrollgrenzen, kein Produktranking. Eine vollständige Architektur kann mehr als einen Mechanismus verwenden, da die Bedrohungen nicht austauschbar sind.
Folgen Sie einem synthetischen Nachrichtenpfad
Stellen Sie sich eine fiktive Rechnung vor, die von billing@shop.example.com per direkter SMTP Zustellung an accounts@buyer.example.org gesendet wird. Der Versanddienst verwendet eine Umschlagdomäne unter bounce.mailer.example.net und signiert mit d=shop.example.com. Gehen Sie von einer geltenden DMARC Richtlinie und abgeschlossenen Identitätsprüfungen aus. In diesem synthetischen Szenario ist das Senden MTA Erkennt und ruft eine gültige MTA-STS -Richtlinie im Erzwingungsmodus für die empfangende Domäne buyer.example.org von https://mta-sts.buyer.example.org/.well-known/mta-sts.txt. Es prüft, ob das ausgewählte Ziel, mx1.buyer.example.org , mit der Richtlinie übereinstimmt, stellt dann eine Verbindung her und handelt TLS aus, wobei das MX Zertifikat validiert wird, bevor die Nachricht übertragen wird.
Unter RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2 Und RFC 8461 §5, würden die hypothetischen Kontrollen diese Aussagen stützen:
- DKIM kann einen ausgerichteten Weiterleitungspfad bereitstellen, da die Signatur überprüft wird und ihre d=-Domäne in diesem Beispiel mit der From-Domäne übereinstimmt.
- DMARC kann auf Nachrichtenebene über diesen ausgerichteten DKIM Pfad weitergeleitet werden.
- Der empfangende SMTP Hop verwendete TLS gemäß der veröffentlichten Transportrichtlinie der Empfängerdomäne, vorausgesetzt, die Richtlinie war gültig, aktuell und korrekt angewendet.
- Keine dieser Tatsachen beweist, dass die Rechnung echt ist, dass das Konto des Absenders nicht kompromittiert wurde oder dass jede vorherige und spätere Kopie der Nachricht verschlüsselt bleibt.
Ändern Sie nun nur die Signaturdomäne in d=mailer.example.net. DKIM könnte immer noch bestehen, aber diese nicht verwandte Domain würde nicht mit shop.example.com übereinstimmen. Ein TLS-geschützter Zustellungs-Hop behebt diesen Ausrichtungsfehler nicht.
Halten Sie DKIM Signatur und -Verschlüsselung getrennt
Unter RFC 6376 §3.7DKIM wendet eine kryptografische Signatur auf ausgewählte Nachrichtendaten an. Der Verifizierer verwendet einen öffentlichen Schlüssel, der für die veröffentlicht wurde Wähler und d= Domäne. Die Signatur liefert Hinweise auf den signierten Inhalt und die signierende Domäne. Es verbirgt die Botschaft nicht.
Die Verschlüsselung hat einen anderen Zweck. Unter RFC 3207 §6SMTP TLS schützt Daten auf einer ausgehandelten Verbindung zwischen Systemen, nicht auf dem vollständigen End-to-End-Nachrichtenpfad. MTA-STS kann eine empfangende Domäne eine Richtlinie veröffentlichen, die konforme Absender bei der Validierung TLS Zustellung an ihre MX Hosts verwenden können. TLS Berichterstellung kann aggregiertes Feedback zu Transportfehlern liefern RFC 8460 §4.1, RFC 8460 §4.2 Und RFC 8460 §4.3. Diese Kontrollen wandeln SMTP Mail nicht in ein Ende-zu-Ende-verschlüsseltes Objekt um.
Die Verschlüsselung auf Nachrichtenebene ist eine weitere Ebene, dargestellt durch S/MIME in RFC 8551 §1 Und RFC 8551 §3.3. Es kann Inhalte schützen, sodass nur vorgesehene Endpunkte mit geeigneten Schlüsseln sie lesen können, aber Schlüsselverteilung und Zertifikatsverarbeitung wie z RFC 8551 §4 Gegenstand. Empfängerfähigkeit, Wiederherstellung und Archivzugriff erfordern ebenfalls eine explizite betriebliche Gestaltung. DMARC bleibt eine separate Bewertung der sichtbaren Absenderdomäne und der ausgerichteten Authentifizierung.
Definieren Sie jede Vertrauensentscheidung
Ein nützlicher Entwurfsdatensatz nennt für jedes Steuerelement vier Dinge:
- Steuerung: DMARC ; Identität oder Vermögenswert: Domäne in Von; Vertrauensanker: DNS Richtlinie plus abgestimmtes SPF oder DKIM Ergebnis; Zu bewahrende Nachweise: Ergebnis des vertrauenswürdigen Empfängers und geltende Richtlinie
- Kontrolle: DKIM ; Identität oder Vermögenswert: Signierende Domäne und Selektor; Vertrauensanker: Öffentlicher DNS -Schlüssel; Zu bewahrende Nachweise: Unterschrift, Prüfergebnis und Schlüsselaufzeichnung
- Steuerung: MTA-STS ; Identität oder Vermögenswert: Empfangende Domäne und MX Transport; Vertrauensanker: DNS Erkennung plus HTTPS-Richtlinie; Zu speichernde Nachweise: Richtlinien-ID, abgerufene Richtlinie und Lieferergebnis
- Steuerung: Nachrichtenverschlüsselung; Identität oder Vermögenswert: Empfänger- oder Endpunktschlüssel; Vertrauensanker: Ausgewähltes Schlüssel- und Zertifikat-Vertrauensmodell; Zu bewahrende Nachweise: Verschlüsselungsstatus, Empfängerzuordnung und Schlüssellebenszyklus
Übersetzen Sie diese nicht in ein einziges grünes Abzeichen. Jede Antwort hat eine engere Bedeutung und einen anderen Fehlermodus.
Ordnen Sie Kontrollen Bedrohungen zu
DMARC kann die unbefugte Nutzung einer geschützten From-Domäne für teilnehmende Empfänger leichter identifizieren und handhaben. Es verhindert nicht, dass ein legitimes Konto missbraucht wird, überprüft nicht, ob eine Zahlungsanforderung wahr ist, und verschlüsselt gespeicherte E-Mails nicht.
TLS kann die Gefährdung durch passives Abfangen bei einem geschützten Hop verringern. Die Absenderdomäne wird nicht authentifiziert. Ein System, das TLS mit dem falschen oder nicht vertrauenswürdigen Ziel aushandelt, hat nicht die gleiche Sicherheit wie eine durch Richtlinien erzwungene, validierte Verbindung.
Abhängig von ihrem Design kann die Nachrichtenverschlüsselung Inhalte über die Transportsitzung hinaus schützen. Es allein schafft keine DMARC Anpassung, autorisiert keine Geschäftstransaktion und eliminiert keine Endpunktkompromittierung.
Erstellen Sie Beweise, ohne zu viel zu beanspruchen
Erfassen Sie für die Identität eine repräsentative empfangene Nachricht und zeichnen Sie den Absender, die Umschlagidentität, jede DKIM -d=-Domäne, Rohauthentifizierungsergebnisse, Ausrichtung und DMARC Disposition auf. Behalten Sie für den Transport die MTA-STS Richtlinie, MX Bereich und TLS Berichtsnachweis bei. Dokumentieren Sie für die Nachrichtenverschlüsselung, wer über Schlüssel verfügt, wie Empfänger registriert werden, was passiert, wenn ein Schlüssel verloren geht und welche Systeme auf Klartext zugreifen können.
Ein Labortest sollte als Test gekennzeichnet sein. Es beweist nicht, dass sich jeder Produktionsweg gleich verhält. Validieren Sie Dienste mit geringem Volumen, Weiterleitungsrouten, Backup- MX Hosts und mobilen oder Archivzugriff dort, wo sie das Kontrollziel beeinträchtigen.
Weisen Sie separate Eigentümer und Wiederherstellungsrouten zu
E-Mail-Vorgänge verfügen häufig über Authentifizierung und SMTP Transport. Die Sicherheitsarchitektur kann über Richtlinien, Bedrohungsabdeckung und Verschlüsselungsstandards verfügen. Anwendungsteams besitzen die Senderouten, die Geschäftspost generieren. Rechts- und Aufzeichnungsteams können die Anforderungen an die Aufbewahrung von Inhalten und die Wiederherstellung von Schlüsseln beeinflussen.
Geben Sie jedem Steuerelement einen Eskalationsauslöser. Eine Ausrichtungsregression betrifft den Absendereigentum und die E-Mail-Vorgänge. Ein TLS Richtlinienfehler betrifft Transport- und DNS Besitzer. Ein verlorener Nachrichtenverschlüsselungsschlüssel gelangt in den Wiederherstellungsprozess der Schlüsselverwaltung. Eine generische „E-Mail-Sicherheits“-Warteschlange verbirgt die zu treffende Entscheidung.
Machen Sie die Kaufentscheidung klar
Schreiben Sie vor der Genehmigung eines Projekts einen Satz für das gewünschte Ergebnis. „Reduzieren Sie die unbefugte Nutzung unserer Absenderdomänen“ weist auf DMARC und eine angepasste Authentifizierung hin. „Akzeptables TLS für die Zustellung an unsere Domain erforderlich“ weist auf die Transportrichtlinie hin. „Nachrichteninhalte außerhalb genehmigter Endpunkte unlesbar halten“ erfordert ein Nachrichtenverschlüsselungsdesign.
Diese Ergebnisse können nebeneinander bestehen. Die wichtige Entscheidung besteht darin, den fehlenden Schutz zu finanzieren, anstatt davon auszugehen, dass ein bekanntes Akronym für E-Mail-Sicherheit gleichzeitig Identität, Vertraulichkeit und Geschäftslegitimität abdeckt.
Halten Sie die Schlussfolgerung innerhalb der Beweise
Behalten Sie für die Rechnungsfixierung die erfolgreiche DKIM Ausrichtung und den validierten SMTP Hop in verschiedenen Beweisfeldern bei. Wenn sich nur d= zur nicht verwandten Anbieterdomäne ändert, während SPF nicht ausgerichtet bleibt, erstellt TLS immer noch keine ausgerichtete Identität. Bei dem hier beschriebenen Richtlinienabruf, TLS Aushandlung und der Signaturüberprüfung handelt es sich um angenommene Lehreingaben und nicht um durchgeführte Netzwerk- oder Nachrichtentests.