Verbessern des Nachrichtenflusses mit MTA-STS

Artikel
08/18/2023

Unterstützung des SMTP MTA Strict Transport Security (MTA-STS)-Standards wird zu Exchange Online hinzugefügt. Der Standard wurde entwickelt, um sicherzustellen, dass TLS immer für Verbindungen zwischen E-Mail-Servern verwendet wird. Es bietet für sendende Server auch die Möglichkeit zu überprüfen, ob der empfangende Server über ein vertrauenswürdiges Zertifikat verfügt. Wenn entweder TLS nicht angeboten wird oder das Zertifikat ungültig ist, verweigert der Absender die Zustellung von Nachrichten. Diese neuen Überprüfungen verbessern die allgemeine Sicherheit von SMTP und schützen vor Man-in-the-Middle-Angriffen.

MTA-STS kann in zwei Szenarien unterteilt werden: Eingehender und ausgehender Schutz. Der Schutz für eingehenden Datenverkehr deckt den Schutz von Domänen ab, die in Exchange Online mit MTA-STS gehostet werden. Der Schutz für ausgehenden Datenverkehr deckt die MTA-STS-Überprüfungen ab, die von Exchange Online beim Senden von E-Mails an MTA-STS-geschützte Domänen durchgeführt werden.

Tipp

Wenn Sie kein E5-Kunde sind, verwenden Sie die 90-tägige Testversion von Microsoft Purview-Lösungen, um zu erfahren, wie zusätzliche Purview-Funktionen Ihre Organisation bei der Verwaltung von Datensicherheits- und Complianceanforderungen unterstützen können. Starten Sie jetzt im Testhub für Microsoft Purview-Complianceportal. Erfahren Sie mehr über Anmelde- und Testbedingungen.

Ausgehender Schutz

Alle Nachrichten, die von Exchange Online ausgehend an MTA-STS-geschützte Empfänger gesendet werden, werden mit diesen zusätzlichen Sicherheitsüberprüfungen überprüft, die durch den MTA-STS-Standard festgelegt sind. Administratoren müssen nichts tun, um sie anzuwenden. Bei unserer ausgehenden Implementierung werden die Wünsche der Empfängerdomänenbesitzer durch ihre MTA-STS-Richtlinie geachtet. MTA-STS ist Teil der Sicherheitsinfrastruktur von Exchange Online und daher immer aktiviert (wie andere grundlegende SMTP-Features).

Ausgehender MTA-STS kann verhindern, dass E-Mails in Abhängigkeit von den Ergebnissen der MTA-STS-Überprüfung für die Zieldomäne übermittelt werden. Wenn die Domäne nicht sicher ist und die MTA-STS-Richtlinie auf Erzwingen festgelegt ist, kann ein NDR mit einem der folgenden Fehlercodes an den Absender zurückgegeben werden:

Fehlercode	Beschreibung	Mögliche Ursache	Weitere Informationen
5.4.8	Fehler bei MTA-STS-Überprüfung bei MX-Hosts von "{domain}"	Der MX-Zielhost war nicht der gemäß der STS-Richtlinie der Domäne erwartete Host.	Dieser Fehler weist in der Regel auf ein Problem mit der MTA-STS-Richtlinie der Zieldomäne hin, die den MX-Host nicht enthält. Weitere Informationen zu MTA-STS finden Sie unter https://datatracker.ietf.org/doc/html/rfc8461.
5.7.5	Fehler bei der MTA-STS-Überprüfung des Remotezertifikats. Ursache: {validityStatus}	Das Zertifikat des Ziel-E-Mail-Servers muss mit einer vertrauenswürdigen Stammzertifizierungsstelle verkettet werden, und der allgemeine Name oder alternativer Antragstellername muss einen Eintrag für den Hostnamen in der STS-Richtlinie enthalten.	Dieser Fehler weist in der Regel auf ein Problem mit dem Zertifikat des Ziel-E-Mail-Servers hin. Weitere Informationen zu MTA-STS finden Sie unter https://datatracker.ietf.org/doc/html/rfc8461.

Eingehender Schutz

Domänenbesitzer können Maßnahmen ergreifen, um E-Mails zu schützen, die mit MTA-STS an ihre Domänen gesendet werden, wenn ihr MX-Eintrag auf Exchange Online verweist. Wenn Ihr MX-Eintrag auf einen zwischengeschalteten Drittanbieterdienst verweist, müssen Sie überprüfen, ob die MTA-STS-Anforderungen von ihnen erfüllt werden, und dann deren Anweisungen befolgen.

Nachdem MTA-STS für Ihre Domäne eingerichtet wurde, werden von allen Nachrichten, die von Absendern gesendet werden, welche MTA-STS unterstützen, die vom Standard festgelegten Überprüfungen durchgeführt, um eine sichere Verbindung zu gewährleisten. Wenn Sie eine E-Mail von einem Absender erhalten, der MTA-STS nicht unterstützt, wird die E-Mail weiterhin ohne zusätzlichen Schutz zugestellt. Ebenso gibt es keine Unterbrechungen bei Nachrichten, wenn Sie MTA-STS noch nicht verwenden, der Absender ihn jedoch unterstützt. Das einzige Szenario, bei dem Nachrichten nicht übermittelt werden, ist, wenn beide Seiten MTA-STS verwenden und die MTA-STS-Prüfung fehlschlägt.

So übernehmen Sie MTA-STS

MTA-STS ermöglicht einer Domäne, die Unterstützung für TLS zu erklären und den erwarteten MX-Eintrag und das Zielzertifikat zu übermitteln. Es gibt auch an, was ein sendenden Server tun muss, wenn ein Problem vorliegt. Diese Kommunikation erfolgt über eine Kombination aus einem DNS TXT-Eintrag und einer Richtliniendatei, die als HTTPS-Webseite veröffentlicht wird. Die HTTPS-geschützte Richtlinie führt einen weiteren Sicherheitsschutz ein, den Angreifer überwinden müssen.

Der MTA-STS TXT-Eintrag einer Domäne gibt die MTA-STS-Unterstützung für einen Absender an, nach dem die HTTPS-basierte MTA-STS-Richtlinie der Domäne vom Absender abgerufen wird. Der TXT-Eintrag sollte v=STSv1 enthalten; bis STSv2 unterstützt wird, und die ID für die Richtlinie. Die ID MUSS für den Domänenbesitzer und die Richtlinie eindeutig sein, da eine Änderung der ID den Absendern signalisiert, dass sie die Richtlinie erneut abrufen müssen. Die ID muss nicht global eindeutig sein. Machen Sie sich keine Gedanken über die Richtlinien-IDs anderer Domänenbesitzer. Nachdem MTA-STS-Richtlinien aktualisiert wurden, müssen Sie die ID aktualisieren. Andernfalls verwenden Absender weiterhin zwischengespeicherte Richtlinien für Ihre Domäne, bis die max_age der zwischengespeicherten Richtlinie abläuft.

Ein wiederholbares Muster zum Festlegen einer eindeutigen ID ist die Verwendung der UTC-Zeit als solche:
id=<yyyymmddhh0000>Z;

Der folgende TXT-Eintrag ist ein Beispiel, das die Unterstützung für MTA-STS deklariert. Die ID wurde auf 8 Uhr 1. Januar 2022 UTC-Zeit festgelegt:

_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20220101080000Z;

Die MTA-STS-Richtlinie einer Domäne muss sich unter einer vordefinierten URL befinden, die von der Webinfrastruktur der Domäne gehostet wird. Die Syntax lautet https://mta-sts.<domain name>/.well-known/mta-sts.txt. Die Microsoft.com-Richtlinie finden Sie beispielsweise unter: https://mta-sts.microsoft.com/.well-known/mta-sts.txt.

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Jeder Kunde, dessen MX-Einträge direkt auf Exchange Online verweisen, kann in seiner eigenen Richtlinie dieselben Werte angeben, die in https://mta-sts.microsoft.com/.well-known/mta-sts.txtangezeigt werden. Die eindeutig erforderlichen Informationen in der Richtlinie sind der MX-Eintrag, der auf Exchange Online verweist (*.mail.protection.outlook.com), und dasselbe Zertifikat wird von allen Exchange Online-Kunden gemeinsam genutzt. Exchange Online erlaubt nur einer Organisation den Empfang von E-Mails für eine bestimmte Domäne, sodass die Verwendung eines Wildcards die Sicherheit nicht schwächt. Bei anderen E-Mail-Diensten ist dies jedoch möglicherweise nicht der Fall. Es ist möglich, Ihre Richtlinie im Testmodus zu veröffentlichen, um sicherzustellen, dass sie gültig ist, bevor Sie sie in den Erzwingungsmodus ändern. Es gibt Validierungstools von Drittanbietern, die Ihre Konfiguration überprüfen können.

Diese Richtlinien sind nicht etwas, das Exchange Online im Namen von Kunden hosten kann. Daher müssen Kunden die STS-Richtlinie ihrer Domäne mit den von ihnen bevorzugten Diensten konfigurieren. Azure-Dienste können problemlos für das Richtlinienhosting verwendet werden, und es gibt eine exemplarische Vorgehensweise für die Konfiguration weiter unten in diesem Artikel. Die Richtlinie muss durch HTTPS mit einem Zertifikat für die Subdomain mta-sts.<domain name> geschützt werden.

Sobald der DNS TXT-Eintrag erstellt wurde und die Richtliniendatei unter der erforderlichen HTTPS-URL verfügbar ist, wird die Domäne durch MTA-STS geschützt. Details zu MTA-STS sind in RFC 8461 verfügbar.

Konfigurieren eingehender MTA-STS mit Azure-Diensten

Hinweis

Diese Konfigurationsflows wurden entwickelt, um Microsoft Exchange Online-Kunden beim Hosten ihrer MTA-STS-Richtlinie mithilfe von Azure-Ressourcen zu unterstützen. Bei diesem Konfigurationsablauf wird davon ausgegangen, dass Sie ein Exchange Online-Kunde sind, der über die Funktionsweise von MTA-STS und seine Anforderungen informiert ist. Weitere Informationen zum Protokoll, das über dieses Thema hinausgeht, finden Sie unter RFC8461.

Es gibt zwei Azure-Ressourcen, die zum Hosten der MTA-STS-Richtlinie verwendet werden können: Azure Static Web App und Azure Functions. Obwohl in diesem Artikel beschrieben wird, wie Sie die Richtlinie mit beiden Ressourcen bereitstellen, ist die empfohlene Methode Azure Static Web App , da sie für das Hosten statischer Seiten wie der STS-Richtlinie konzipiert ist. Azure vereinfacht die Konfiguration, indem standardmäßig ein TLS-Zertifikat für die MTA-STS-Webseite bereitgestellt wird, ohne dass eine weitere Konfiguration erforderlich ist. Wenn Sie Azure Static Web App nicht verwenden können, können Sie Ihre Richtlinie auch mit Azure Functions als serverlosen Code hosten. Dieser Ansatz ist nicht die bevorzugte Methode, da Azure Functions ein Feature ist, das für andere Szenarien entwickelt wurde und im Gegensatz zu Azure Static Web Apps kein TLS-Zertifikat automatisch ausgibt. Die Verwendung von Azure Functions für MTA-STS erfordert daher, dass Sie Ihr eigenes "mta-sts. [Ihre Domäne]"-Zertifikat, und binden Sie es an die Funktion.

Unabhängig davon, welchen Ansatz Sie gewählt haben, empfehlen wir Ihnen, zu überprüfen, ob Ihre Richtlinie ordnungsgemäß konfiguriert wurde und ob die Antwortzeit akzeptabel ist – timeout pro RFC-Leitfaden beträgt 60 Sekunden.

Diese Konfigurationsflows sollen nur technische Informationen zu Azure-Features bereitstellen, die zum Hosten der MTA-STS-Richtlinie verwendet werden können, und stellen keine Informationen zu den Gebühren oder Kosten von Azure-Features bereit. Wenn Sie die Kosten von Azure-Features kennen möchten, verwenden Sie den Azure-Preisrechner.

Option 1 (EMPFOHLEN): Azure Static Web App

Erstellen Sie eine Azure DevOps-Organisation, oder verwenden Sie eine organisation, die bereits vorhanden ist. In diesem Beispiel wird eine Organisation namens "ContosoCorporation" verwendet, um die MTA-STS-Richtlinie zu hosten.
Klonen Sie in Repositorydateien >Ihr Repository in einer beliebigen IDE, die Sie bevorzugen. In diesem Beispiel wird das Repository in Visual Studio geklont.
Nachdem das Repository geklont wurde, erstellen Sie den Ordnerpfad home\.well-known\. Erstellen Sie dann die folgenden Dateien:
- Datei 1: home.well-known\mta-sts.txt
  
  Hinweis
  
  Mit dieser Konfiguration kann nur Exchange Online Nachrichten im Namen Ihrer Domäne empfangen. Wenn Sie mehrere E-Mail-Anbieter verwenden, müssen Sie auch auf MX-Hosts für die Domänen dieser anderen Anbieter verweisen. In allen MTA-STS-Szenarien dürfen nicht Als MX-Präfixe oder "*" verwendet werden. Die folgenden Einstellungen gelten nur für Exchange Online und dürfen NICHT als allgemeine Anleitung für die Konfiguration von MTA-STS verwendet werden.
  1. Geben Sie den folgenden Text in die mta-sts.txt Datei ein:
```
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800
```
    Hinweis
    
    Es wird empfohlen, den Richtlinienmodus zunächst als Test festzulegen. Aktualisieren Sie dann am Ende der Konfiguration und nachdem Sie überprüft haben, dass die Richtlinie wie erwartet funktioniert, die mta-sts.txt Datei so, dass der Modus erzwungen wird.
    
    Die Datei darf nur den Inhalt enthalten, wie im folgenden Screenshot gezeigt:
- Datei 2: home\index.html
  1. Erstellen Sie eine index.html Datei, und geben Sie den folgenden Code ein:
```
<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8">
<title>MTA-STS</title>
</head>

<body>
<h1>MTA-STS Static Website index</h1>
</body>

</html>
```
    Die Datei darf nur den Inhalt enthalten, wie im folgenden Screenshot gezeigt:
    
    Nachdem der Ordnerpfad und die Dateien erstellt wurden, vergessen Sie nicht, die Änderungen zu committen und in Ihren Mainbranch zu pushen.
Erstellen Sie eine neue statische Azure-Web-App mit der folgenden Konfiguration:
- Name: MTA-STS-StaticWebApp
- Plantyp: Standard
- Bereitstellungsdetails: Azure DevOps
- Organisation: ContosoCorporation
- Projekt: MTA-STS_Project
- Repository: MTA-STS_Project
- Branch: master
- Buildvoreinstellungen: Angular
- App-Speicherort: /home
Sobald die Erstellung der statischen Web-App abgeschlossen und die Ressource bereitgestellt wurde, wechseln Sie zu Übersicht > Bereitstellungstoken verwalten. Kopieren Sie dann das Token, wie es im nächsten Schritt verwendet wird.
Wechseln Sie zu Pipelines > Erstellen einer Pipeline > Azure Repos Git > MTA-STS_Project, und führen Sie die folgenden Teilaufgaben aus:
1. Wechseln Sie zu Variablen > Neue Variable , und geben Sie Folgendes ein:
  1. Name: Token
  2. Wert: (Fügen Sie das Token ein, das Sie zuvor in Schritt 5 kopiert haben)
2. Nachdem die Variable gespeichert wurde, kehren Sie zu Überprüfen Ihrer Pipeline-YAML zurück, fügen Sie den folgenden yml ein, speichern Sie sie, und führen Sie sie aus:
```
trigger:
- main

pool:
vmImage: ubuntu-latest

steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp@0
inputs:
 app_location: '/home'
 azure_static_web_apps_api_token: $(token)
```
  Wenn in Azure DevOps während der Bereitstellung der Fehler Keine gehostete Parallelität wurde erworben oder gewährt auftritt, fordern Sie entweder über dieses Formular an, oder implementieren Sie eine Konfiguration über Organisationseinstellungen > Parallele Aufträge > , die microsoft gehostet werden > , ändern > Bezahlte parallele Aufträge , sodass "Kostenpflichtige parallele Aufträge" zulässig sind.
Nachdem der Auftrag erfolgreich abgeschlossen wurde, können Sie die Bereitstellung über das Azure-Portal überprüfen, indem Sie zu Azure Static Web App > Environment > Browser wechseln. Der Inhalt der index.html Datei muss angezeigt werden.
Fügen Sie Ihre Vanity-Domäne unter Benutzerdefinierte Domänen > von Azure Static Web App > hinzu Hinzufügen. Sie müssen einen CNAME-Eintrag über Ihren DNS-Anbieter (z. B. GoDaddy) erstellen, um zu überprüfen, ob die Zone Zu Ihnen gehört. Sobald die Überprüfung abgeschlossen ist, stellt Azure ein Zertifikat aus und bindet es automatisch an Ihre Static Web App.
Überprüfen Sie, ob Ihre MTA-STS-Richtlinie veröffentlicht wird: https://mta-sts.[Ihre Domäne]/.well-known/mta-sts.txt.
Erstellen Sie den MTA-STS TXT-DNS-Eintrag über Ihren DNS-Anbieter. Das Format lautet wie folgt:
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Hinweis

Ein Beispiel für einen MTA-STS TXT-Eintrag finden Sie unter How To Adopt MTA-STS (Vorgehensweise: Einführen von MTA-STS).
Sobald der TXT-Eintrag im DNS verfügbar ist, überprüfen Sie Ihre MTA-STS-Konfiguration. Nachdem die Konfiguration erfolgreich überprüft wurde, aktualisieren Sie die mta-sts.txt Datei so, dass der Richtlinienmodus erzwungen wird. Aktualisieren Sie dann Ihre Richtlinien-ID im TXT-Eintrag.

Option 2: Azure-Funktion

Erstellen Sie eine neue Azure-Funktions-App mit der folgenden Konfiguration:
- Name der Funktions-App: [Als Ihre Wahl]
- Veröffentlichen: Code
- Runtimestapel: .NET
- Version: 6
- Betriebssystem: Windows
- Plantyp: [Nach Wahl]
Fügen Sie der Funktions-App Ihre benutzerdefinierte Domäne hinzu. Sie müssen einen CNAME-Eintrag erstellen, um zu überprüfen, ob die Domäne Zu Ihnen gehört.
Binden Sie Ihre "mta-sts. [Ihre Domäne]" in die Funktions-App.
Fügen Sie in App-Datei die folgende Erweiterung zum host.json Ihrer Funktions-App hinzu, um routePrefix zu beseitigen. Diese Ergänzung ist erforderlich, um die /api aus der Funktions-URL zu entfernen.
```
"extensions": {
  "http": {
    "routePrefix": ""
  }
}
```
Navigieren Sie in Ihrer Funktions-App zu Funktionen > Erstellen und konfigurieren Sie die folgenden Parameter:

Hinweis

Obwohl in diesem Beispiel die Funktionsentwicklung über das Portal beschrieben wird, können Sie VS Code oder ein anderes bevorzugtes Tool verwenden.
- Entwicklungsumgebung: [Nach Wahl; in diesem Beispiel wird "Im Portal entwickeln" verwendet]
- Vorlage auswählen: HTTP-Trigger
- Neue Funktion: [Nach Wahl]
- Autorisierungsstufe: Anonym
Nachdem die Funktion erstellt wurde, öffnen Sie Code + Test , und entwickeln Sie in C# eine einfache asynchrone HTTP-Antwort, die Ihre MTA-STS-Richtlinie ist. Das folgende Beispiel zeigt an, dass Exchange Online E-Mails empfangen soll:

Hinweis

Es wird empfohlen, den Richtlinienmodus zunächst als Test festzulegen. Aktualisieren Sie dann am Ende der Konfiguration und nachdem Sie überprüft haben, dass die Richtlinie wie erwartet funktioniert, die mta-sts.txt Datei so, dass der Modus erzwungen wird.
Bearbeiten Sie in Integration > HTTP (req) den Trigger in die folgenden Werte:
- Routenvorlage: .well-known/mta-sts.txt
- Ausgewählte HTTP-Methoden: GET
Überprüfen Sie, ob Ihre MTA-STS-Richtlinie veröffentlicht wurde: https://mta-sts.[Ihre Domäne]/.well-known/mta-sts.txt.
Erstellen Sie den DNS-Eintrag MTA-STS TXT über Ihren DNS-Anbieter im folgenden Format:
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Hinweis

Ein Beispiel für einen MTA-STS TXT-Eintrag finden Sie unter How To Adopt MTA-STS (Vorgehensweise: Einführen von MTA-STS).
Sobald der TXT-Eintrag im DNS verfügbar ist, überprüfen Sie Ihre MTA-STS-Konfiguration. Nachdem die Konfiguration erfolgreich überprüft wurde, aktualisieren Sie die mta-sts.txt Datei so, dass der Richtlinienmodus erzwungen wird. Aktualisieren Sie dann Ihre Richtlinien-ID im TXT-Eintrag.