S/MIME vs. Microsoft 365 Purview (Praxisleitfaden)
Einordnung: Was „verschlüsselte E-Mail“ in Outlook wirklich bedeutet
Viele Anwender sagen „Outlook verschlüsseln“ und meinen damit irgendeine Form von „sicher senden“. Technisch ist das zu unscharf. In der Praxis existieren drei Schutzniveaus, die häufig verwechselt werden:
Transportverschlüsselung (TLS)
Schützt die Verbindung zwischen Mailservern. Der Inhalt ist während des Transports gegen „Mitlesen unterwegs“ besser geschützt, liegt aber auf beteiligten Systemen typischerweise weiterhin im Klartext vor (oder kann dort entschlüsselt werden).
Inhaltsverschlüsselung (Nachrichten- und Rechteverwaltung)
Der Inhalt (Body und Anhänge) wird so geschützt, dass er auch außerhalb des Transportwegs nur für berechtigte Identitäten lesbar ist.
In Microsoft 365 ist das typischerweise Microsoft Purview Message Encryption (Weiterentwicklung von OME/IRM).
Ende-zu-Ende-Verschlüsselung (E2EE) mit S/MIME oder OpenPGP
Der Inhalt wird beim Sender verschlüsselt und kann ausschließlich beim Empfänger entschlüsselt werden. Das Schlüsselmaterial liegt idealerweise nicht zentral auf dem Mailserver.
Das BSI ordnet S/MIME typischerweise dem Behörden- und Unternehmensumfeld zu, OpenPGP eher dem privaten Umfeld.
Wichtig (oft übersehen):
Bei OpenPGP und S/MIME bleiben klassische Mail-Metadaten (z. B. Absender, Empfänger, Betreff, Zeitstempel, Routing-Header) in der Regel nicht vollständig verschlüsselt. Ein vertraulicher Betreff verrät also bereits Informationen.
Inhaltsverzeichnis
- Welche E-Mails verschlüsseln?
- Senden verschlüsselter E-Mails: Methodenüberblick & Entscheidungshilfe
- Verschlüsselte E-Mail in Outlook senden (Microsoft Purview)
- Verschlüsselte E-Mail öffnen (Microsoft Purview)
- Verschlüsselte E-Mail per S/MIME versenden (Outlook)
- Verschlüsselte E-Mail per S/MIME öffnen (Outlook)
- Problemlösung (typische Fehlerbilder)
- Extra-Tipps (Betrieb, Governance, Rollout)
- Grenzen im Zusammenspiel mit Genese (EWS-Archivierung & Verschlüsselung)
1) Welche E-Mails sollte man in Outlook verschlüsseln – und warum?
1.1 Der Kern: E-Mail ist ohne Inhaltsverschlüsselung eine „Postkarte“
Unverschlüsselte Nachrichten können – abhängig von Transportweg, beteiligten Systemen oder Fehlkonfigurationen – von Unbefugten eingesehen werden.
Im Unternehmenskontext wird das schnell zu einem Compliance- und Haftungsthema (DSGVO, Geheimnisschutz, Vertrags- und Berufsrecht).
Echte Ende-zu-Ende-Verschlüsselung stellt sicher, dass Inhalte bereits beim Versand geschützt und erst beim Empfänger wieder lesbar sind.
1.2 Praxisnahe Kategorisierung
Typische Inhalte, die verschlüsselt werden sollten:
- Personenbezogene Daten Personalakten, Gehälter, Bewerbungen, Gesundheitsdaten
- Verträge & Verhandlungen Vertragsentwürfe, NDAs, M&A-Unterlagen, Preislisten
- Finanzdaten Bankverbindungen, Zahlungspläne, Rechnungsdetails
- IP & Legal Schriftsätze, Gutachten, Abmahnungen, Strategiepapiere
- Zugangsdaten & Secrets Passwörter, Tokens, Admin-Informationen
Merksatz:
Alles, was man nicht auf eine Postkarte schreiben würde, sollte verschlüsselt oder über einen sicheren Datenraum geteilt werden.
2) Methoden zum Senden verschlüsselter E-Mails in Outlook
Outlook wird typischerweise genutzt in Kombination mit:
- Exchange Online (Microsoft 365)
- Exchange On-Premises
- hybriden Umgebungen
Dafür haben sich zwei Verfahren etabliert.
2.1 S/MIME – klassische Ende-zu-Ende-Verschlüsselung
Prinzip:
- Jeder Nutzer besitzt ein Zertifikat (Public/Private Key).
- Der Sender verschlüsselt mit dem öffentlichen Schlüssel des Empfängers.
- Nur der Empfänger kann mit seinem privaten Schlüssel entschlüsseln.
Eigenschaften:
- Sehr starke E2EE-Logik
- Hoher Betriebsaufwand (Zertifikate, Geräte, Erneuerung)
- In Web- und Mobile-Clients eingeschränkt nutzbar
2.2 Microsoft Purview Message Encryption
Prinzip:
- Verschlüsselung wird serverseitig in Microsoft 365 angewendet.
- Zugriff ist an die Identität des Empfängers gebunden.
- Sehr gut geeignet für externe Empfänger ohne Zertifikate.
Wichtige Rahmenbedingungen:
- Bestandteil bestimmter Microsoft-365-Lizenzen
- Max. Nachrichten- und Anhangsgröße meist 25 MB
- Rechte wie „Nicht weiterleiten“ möglich
2.3 Entscheidungshilfe
- Regelmäßige externe Kommunikation: → Purview als Standard
- Strenge E2EE-Anforderungen / Behördenkommunikation: → S/MIME
- Gemischte Anforderungen: → Purview als Default, S/MIME für definierte Partner
3) Verschlüsselte E-Mail in Outlook senden (Microsoft Purview)
3.1 Voraussetzungen
- Geeignete Microsoft-365-Lizenz oder AIP Plan 1
- Purview/IRM im Tenant aktiviert
- Beachtung des Größenlimits (typisch 25 MB)
3.2 Outlook Desktop
- Neue E-Mail erstellen
- Optionen → Verschlüsseln
- Variante wählen (z. B. Encrypt oder Do Not Forward)
- Senden
Praxis-Tipp:
Sensitivity Labels kombinieren Klassifikation, Verschlüsselung und Nutzungsrechte und reduzieren Fehlbedienung.
3.3 Outlook im Web
Die Funktion ist identisch, aber abhängig von Tenant-, Policy- und Lizenzkonfiguration.
4) Verschlüsselte E-Mail öffnen (Microsoft Purview)
4.1 Interne Empfänger
In der Regel nahtlos: Der Inhalt wird direkt im Postfach angezeigt.
4.2 Externe Empfänger
Typischer Ablauf:
- Benachrichtigungs-Mail erhalten
- Klick auf „Nachricht lesen“
- Anmeldung oder Einmalcode
- Lesen und Antworten im sicheren Web-Portal
5) Verschlüsselte E-Mail per S/MIME versenden
5.1 Voraussetzungen
- Gültiges S/MIME-Zertifikat je Nutzer
- Import des Zertifikats inkl. Private Key
- Austausch der Zertifikate mit Kommunikationspartnern
5.2 Versand (vereinfacht)
- Zertifikat aktivieren
- Neue E-Mail → Optionen → Verschlüsseln → S/MIME
- Senden
Wichtig:
Geht der Private Key verloren, ist die Nachricht nicht mehr entschlüsselbar.
6) S/MIME-verschlüsselte E-Mails öffnen
- Outlook Desktop: automatisch bei vorhandenem Zertifikat
- Outlook im Web: nur mit installiertem S/MIME-Control/Extension
7) Typische Fehlerbilder
„Verschlüsseln“-Button fehlt
- Falsche Lizenz
- IRM/Purview nicht aktiviert
- Sensitivity Labels nicht publiziert
Externer Empfänger kann Mail nicht öffnen
- Authentifizierungsprobleme
- Blockierte Portal-Links
S/MIME: Nachricht nicht lesbar
- Private Key fehlt
- Zertifikat abgelaufen oder widerrufen
- Kein S/MIME-Control im Browser
8) Extra-Tipps für Betrieb & Governance
- Sensitivity Labels statt manueller Klicks
- Keine vertraulichen Inhalte im Betreff
- Große Dateien lieber per sicherem Link teilen
- Klar definieren, welche Inhalte archiviert werden müssen
9) Grenzen im Zusammenspiel mit Genese (EWS-Archivierung)
9.1 S/MIME und serverseitige Archivierung
S/MIME ist konsequent Ende-zu-Ende gedacht.
Ohne Private Key kann der Server den Inhalt nicht entschlüsseln.
Konsequenz für Genese (EWS):
- Verschlüsselte E-Mails können gespeichert werden
- Inhalte können serverseitig nicht im Klartext indexiert oder ausgewertet werden
9.2 Purview-verschlüsselte Mails
Auch hier hängt die Lesbarkeit an Identitäten und Rights-Management.
Ein EWS-Dienst kann Inhalte nicht automatisch entschlüsseln.
9.3 Praktische Leitlinie
- Serverseitige Ablage: nur verschlüsselt möglich
- Klartext-Archivierung: oft nur clientseitig über Outlook realisierbar
- Alternative: Dokumente im Datenraum, E-Mail enthält nur den Link
Fazit
- Microsoft Purview Message Encryption ist der wirtschaftlichste Standard für viele Unternehmen.
- S/MIME bleibt erste Wahl für echte Ende-zu-Ende-Anforderungen.
- Für Genese gilt klar: Verschlüsselte Inhalte können gespeichert, aber ohne Schlüssel nicht serverseitig entschlüsselt werden.
Entscheidend ist daher nicht nur die Technik, sondern ein sauber abgestimmtes Zusammenspiel aus Security, Compliance und Archivierungsstrategie.
Top comments (0)