Verbessern des Nachrichtenflusses mit MTA-STS (2024)

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. Eingehender Schutz 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.

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:

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 folgende TXT-Eintrag ist ein Beispiel, bei dem die MTA-STS-Unterstützung erklärt wird:

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

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: STSv1mode: enforcemx: *.mail.protection.outlook.commax_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 (*.mail.protection.outlook.com) verweist, und dasselbe Zertifikat wird von allen Exchange Online Kunden gemeinsam genutzt. Exchange Online erlaubt nur einem organization, E-Mails für eine bestimmte Domäne zu empfangen, sodass die Verwendung eines Wildcards die Sicherheit nicht beeinträchtigt. Dies ist jedoch bei anderen E-Mail-Diensten 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 können. 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

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 als serverlosen Code mit Azure Functions 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 Ihre eigenen "mta-sts" ausgeben. 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

1. Erstellen Sie eine Azure DevOps-organization, oder verwenden Sie eine bereits vorhandene organization. In diesem Beispiel wird eine organization namens "ContosoCorporation" verwendet, um die MTA-STS-Richtlinie zu hosten.

2. Klonen Sie in Repositorydateien >Ihr Repository in einer beliebigen IDE, die Sie bevorzugen. In diesem Beispiel wird das Repository in Visual Studio geklont.

3. 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 können 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 Standard-Branch zu pushen.

   See Also

   MTA-STS (Strict Transport Security)

4. 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

5. 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.

6. Wechseln Sie zu Pipelines > Create Pipelines > 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.

7. Nachdem der Auftrag erfolgreich abgeschlossen wurde, können Sie die Bereitstellung über die Azure-Portal überprüfen, indem Sie zu Azure Static Web App > Environment > Browser wechseln. Der Inhalt der index.html Datei muss angezeigt werden.

8. 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.

9. Überprüfen Sie, ob Ihre MTA-STS-Richtlinie veröffentlicht wird: https://mta-sts.[Ihre Domäne]/.well-known/mta-sts.txt.

10. 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).

11. 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

1. 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]

2. 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.

3. Binden Sie Ihre "mta-sts. [Ihre Domäne]" in die Funktions-App.

4. Fügen Sie in App-Datei die folgende Erweiterung zu host.json Ihrer Funktions-App hinzu, um routePrefix zu entfernen. Diese Ergänzung ist erforderlich, um die /api aus der Funktions-URL zu entfernen.

    "extensions": {"http": { "routePrefix": "" }}

5. 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

6. 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 erhalten 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.

7. Bearbeiten Sie in Integration > HTTP (req) den Trigger in die folgenden Werte:

   • Routenvorlage: .well-known/mta-sts.txt
   • Ausgewählte HTTP-Methoden: GET

8. Überprüfen Sie, ob Ihre MTA-STS-Richtlinie veröffentlicht wurde: https://mta-sts.[Ihre Domäne]/.well-known/mta-sts.txt.

9. 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).

10. 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.