Mit der DSGVO sind nun viele Administratoren bei den Datenschutz-Audits aufgefordert, die Verschlüsselung von Daten über E-Mail zu beleuchten bzw. zu korrigieren.
Es gibt viele Wege Daten zu verschlüsseln, u.a.:
- Transportverschlüsselung
- Nachrichtenverschlüsselung
- Ende zu Ende
- Gateway-basiert
- PDF-Verschlüsselung
- …
- Verschlüsselter Datenzugriff mittels Portallösungen
Die Nachrichtenverschlüsselung wird heute überwiegend mittels S/MIME dargestellt. Outlook als Platzhirsch unter den Mail-Clients unterstützt dies nativ. Zusätzlich gibt es auch die PGP-Verschlüsselung als alternatives Verfahren. Diese ist allerdings häufig nur durch Addons in den Clients integrierbar. In der klassischen Ausführung spricht man hier von der Ende zu Ende-Verschlüsselung, da die Nachricht ab Versender bis Empfänger verschlüsselt bleibt. Insbesondere S/MIME ist vor Kurzem durch EFAIL (https://efail.de/) sehr in Verruf geraten. Zwar ist S/MIME an sich sicher, letztlich kann aber auf Basis des definierten Standards die nachträgliche Änderung außerhalb des verschlüsselten Inhalts nicht erkannt werden, was dem Angreifer ermöglicht den Quellcode der Mail zu erweitern. Dies wiederum kann dazu verwendet werden, den verschlüsselten Inhalt „auszulesen“. Ein empfohlener Workaround ist die Deaktivierung der aktiven Inhalte im Outlook-Client (siehe BSI-Artikel: https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2018/efail-schwachstellen_15052018.html). PGP war zunächst auch betroffen, hier gab es aber bereits weitergehende Standards, die nun in den meisten Clients integriert wurden und die Integrität der Nachricht sicherstellen.
Da für die Entschlüsselung der private Schlüssel im Client installiert sein muss und der öffentliche Schlüssel des Empfängers beim Versand lesbar sein muss, greifen viele Unternehmen auf Gateway-basierte Ver- bzw. Entschlüsselungslösungen zurück. Neben dem automatisierten Schlüsselmanagement kann man hier auch zentrale Vorgaben für die Verschlüsselung vornehmen und alternative Verschlüsselungsmöglichkeiten konfigurieren, sollte die primäre Verschlüsselungsaktion nicht genutzt werden können (z. B. öffentlicher Schlüssel des Empfängers nicht bekannt).
In so einem Fall bieten zentrale Gateways z. B. eine PDF-Verschlüsselung der Nachricht an oder eine Möglichkeit, die Nachricht über einen sicheren Weg von einem Webportal abzurufen und sogar hieraus direkt zu beantworten. Die Gateway-basierte Lösung bietet auch eine zuverlässige Möglichkeit, die Nachrichten als unverschlüsselte Nachricht einem Archivsystem zuzuführen. Die Transportverschlüsselung verschlüsselt nicht den Inhalt der einzelnen Nachricht, sondern den gesamten Inhalt der Verbindung. Hierbei wird zwischen einer echten Transportverschlüsselung und der STARTTLS-Verschlüsselung unterschieden. Bei der STARTTLS-basierten Verschlüsselung wird die Verbindung zum Zielserver zunächst unverschlüsselt aufgebaut, während der Kommunikation wird dann allerdings der Inhalt verschlüsselt übertragen. Die Transportverschlüsselung kann im Regelfall vom Benutzer nicht erzwungen werden, dies ist durch die Konfiguration des Quell- und Zielservers der Messagingkommunikation vorzunehmen. Sie hat den Charme, dass Sie mit geringen Anforderungen erfüllt werden kann: Die Server müssen TLS unterstützen (nach Möglichkeit nur aktuelle Verschlüsselungsalgorithmen und -protokolle) und es sollte ein öffentlich vertrauenswürdiges Zertifikat installiert sein. Letzteres stellt sicher, dass der ermittelte Zielserver auch tatsächlich der ist, den man ansprechen möchte. Unter Exchange kann man konfigurieren, dass „Opportunistic TLS“ verwendet wird, „Domainvalidated TLS“ oder sogar „Mutual TLS“ verwendet wird. (siehe: https://technet.microsoft.com/en-us/library/bb430753(v=exchg.150).aspx)
„Opportunistic TLS“ bedeutet:
Es wird zunächst eine TLS-Verbindung versucht. Schlägt diese fehl, wird stattdessen Klartext übertragen. Allerdings versucht Exchange, sofern vom Zielhost möglich, eine STARTTLS-basierte Kommunikation.
„Domainvalidated TLS“ bedeutet:
Der Quellserver prüft das Zertifikat des annehmenden Servers auf Validität (z. B. Vertrauenswürdigkeit, Sperrstatus, etc.)
„Mutual TLS“ bedeutet:
Quell- sowie Zielserver prüfen gegenseitig die Validität des jeweiligen Zertifikats.
Zusätzlich kann man auch die „unsichere“ TLS-Sicherheit ohne Prüfung der Vertrauensstellung konfigurieren. Das Problem hierbei ist, dass damit die Identität des Servers nicht bestätigt werden kann. Viele Mailserver verweigern die Kommunikation mit Servern, die ein selbstsigniertes Zertifikat oder ein von einer nicht öffentlichen PKI ausgestelltes Zertifikat verwenden.
Für die reguläre Kommunikation sollte man schon länger die Variante „Opportunistic TLS“ verwenden, da – Stand heute – noch nicht alle Kommunikationspartner verschlüsselte Verbindungen zu Ihren Mailservern konfiguriert haben. Für die Kommunikation mit wiederkehrenden Gesprächspartnern (z. B. Steuerberater, externer Personaldienstleister etc.) sollte man die „Domainvalidated TLS“-Variante wählen und erzwingen. Dies kann man unter Exchange Online Protection pro Empfängerdomäne konfigurieren. Perimeter-Mailgateways sollten diese Funktion auch besitzen. Zusätzlich sollte auf den extern erreichbaren Mailservern (sofern On-Premise solche betrieben werden) ein öffentlich vertrauenswürdiges Zertifikat gebunden werden.
- TLS erzwingen unter Exchange Online Protection funktioniert im Exchange Admin Center über „Nachrichtenfluss“ > „Connectors“ > „Ausgehende Connectors“.
Im neuen Fenster geben Sie oben einen Namen für den Connector an und tragen weiter unten unter „Verbindungssicherheit“ für „Empfängerzertifikat stimmt mit Domäne überein“ den im Zertifikat vom Empfänger hinterlegten Domain-Namen ein. Über verschiedene SMTP TLS-Tools im Internet können Sie den Namen des Zertifikats für die Zieldomäne ermitteln.
Wenn der Empfänger zwar ein TLS-Zertifikat verwendet, dieses aber selbstsigniert oder von einer nicht öffentlichen Zertifizierungsstelle ausgestellt wurde, kann stattdessen auch „Selbstsigniertes Zertifikat“ gewählt werden. Wenn Sie „Vertrauenswürdige Zertifizierungsstelle (CA)“ wählen, wird das Zertifikat grundsätzlich auf Validität geprüft, es wird aber nicht zusätzlich die Zertifikatsdomäne ausgewertet. In folgender Reihenfolge von sicher bis unsicher sollte der Connector getestet werden:
- Empfängerzertifikat stimmt mit Domäne überein
- Vertrauenswürdige Zertifizierungsstelle (CA)
- Selbstsigniertes Zertifikat
- Opportunistisches Zertifikat
Im Bereich „ausgehende Zustellung“ wird im Zweifel nichts geändert, es sei denn Ihr Kommunikationspartner liefert Ihnen den FQDN oder die IP-Adresse eines oder mehrerer dedizierter Mailserver für die Kommunikation. Standardmäßig ermittelt Exchange den zuständigen Mailserver mittels der in der Zieldomäne hinterlegten MX-Records.
Tragen Sie unter Empfängerdomänen die Zieldomänen ein (alles nach dem @-Zeichen in der E-Mail-Adresse). Verwendet Ihr Kommunikationspartner Subdomains wie z. B. extern.excite-consulting.de sollten Sie hier ein Wildcard für die Subdomains verwenden. Beispiel: *.excite-consulting.de
Klicken Sie abschließend auf Speichern und testen Sie die Änderung nach 10-15 Minuten. Es kann einige Zeit vergehen, bis die Einstellung auf allen Exchange-Servern in Exchange Online wirksam wird.
Ob die Kommunikation per TLS durchgeführt wurde, können Sie im „Security & Compliance“-Center über die Nachrichtenablaufverfolgung ermitteln:
Geben Sie in der nachfolgend dargestellten Suchmaske Ihre Domäne mit Wildcard vor dem @ an (1). Definieren Sie den Suchzeitraum (2) und wählen Sie unter Berichtstyp „Erweiterter Bericht“ (4).
Klicken Sie auf „Weiter“ und tragen Sie die Benachrichtigungs-E-Mail-Adresse bei Fertigstellung des E-Mail-Reports im Feld unter (1) an. Klicken Sie abschließend auf „Bericht vorbereiten“. Die Erstellung des Berichts dauert i. d. R. mehrere Stunden.
Sie können den Bericht nach der Fertigstellung im Nachrichtenverfolgungsmenü herunterladen. Es kann einen Augenblick dauern, bis der Downloaddialog angezeigt wird.
Der Report liegt im CSV-Format vor. Dieser lässt sich in Excel importieren und mittels der „Filter“-Funktion entsprechend filtern.
Filtern Sie die Spalte „Source“ nach „SMTP“, um nur den relevanten SMTP-Traffic auszuwählen.
In der Spalte „custom_data“ können Sie die Nachrichtenheader auswerten, die u.A. die verwendeten Verschlüsselungsalgorithmen beinhaltet. Unverschlüsselte Verbindungen können Sie über den folgenden Ausdruck im Filter anzeigen: „TLS=NONE“
Anhand der Spalten „sender_address“ bzw. „recipient_address“ lässt sich die Quelle bzw. das Ziel der E-Mail ermitteln. Ich habe bisher leider keinen einfacheren Weg gefunden, bzw. erarbeitet. Man kann mit ein bisschen Aufwand die Daten entsprechend automatisiert aufbereiten und so unsichere Kanäle ermitteln.
Eingehend lässt sich die Verschlüsselung beim Mailempfang natürlich auch erzwingen. Allerdings sollte dies mit dem entsprechenden Kommunikationspartner zuerst abgestimmt werden.
