E-Mail-Verschlüsselung im Gesundheitswesen: TLS, S/MIME, Portal – und wo KIM bleibt

In Krankenhäusern, Praxisverbünden und Pflegeeinrichtungen ist E-Mail trotz aller Fachverfahren ein zentraler Kommunikationsweg. Mit Laboren, Zuweisern, Kostenträgern, Dienstleistern, Behörden und Patienten. Die Inhalte sind Gesundheitsdaten im Sinne von Art. 9 DSGVO und unterliegen in vielen Fällen der Schweigepflicht nach § 203 StGB.

Gleichzeitig hat sich mit KIM ein eigener Kanal in der Telematikinfrastruktur etabliert. Die Frage ist deshalb nicht mehr «verschlüsseln ja oder nein», sondern: Welcher Weg für welche Mail? Dieser Artikel ordnet die Optionen ein und zeigt, wie sie sich mit Exchange Online und einem Mail-Gateway umsetzen lassen. Er ersetzt keine Rechtsberatung. Die Bewertung des Risikos trifft Ihre Organisation mit dem Datenschutzbeauftragten.

Der Massstab: die Orientierungshilfe der Datenschutzkonferenz

Die Datenschutzkonferenz hat in ihrer Orientierungshilfe zur Übermittlung personenbezogener Daten per E-Mail einen risikobasierten Massstab beschrieben. Vereinfacht:

• Normales Risiko: Eine obligatorische Transportverschlüsselung ist sicherzustellen. Opportunistisches TLS, das bei Bedarf auf Klartext zurückfällt, genügt dafür nicht.
• Hohes Risiko: Regelmässig Ende-zu-Ende-Verschlüsselung und zusätzlich qualifizierte Transportverschlüsselung, etwa mit DANE.

Gesundheitsdaten werden häufig dem hohen Risiko zugeordnet. In der Praxis lässt sich Ende-zu-Ende-Verschlüsselung aber nicht mit jedem Empfänger umsetzen. Deshalb braucht es eine abgestufte Lösung, die für jede Gruppe von Empfängern dokumentiert, welcher Weg gilt und warum.

Die Wege im Überblick

TLS: Pflichtprogramm, aber nicht das Ende

Exchange Online verwendet ausgehend und eingehend standardmässig TLS, sofern die Gegenseite es anbietet. Zertifikatsprüfung und Pflicht zur Verschlüsselung gelten dabei nicht. Für feste Partner erzwingen Sie TLS mit Zertifikatsprüfung über einen Connector:

# Ausgehend: TLS mit Zertifikatsprüfung zu einem Partner erzwingen
New-OutboundConnector -Name "TLS erzwungen - Labor" -ConnectorType Partner `
  -RecipientDomains "labor-beispiel.de" -UseMXRecord $true `
  -TlsSettings DomainValidation -TlsDomain "*.labor-beispiel.de"
# Eingehend: Mails dieses Partners nur über TLS annehmen
New-InboundConnector -Name "TLS Pflicht - Labor" -ConnectorType Partner `
  -SenderDomains "labor-beispiel.de" -RequireTls $true

Kann die Gegenseite kein gültiges TLS, wird die Mail nicht zugestellt und der Absender erhält eine Unzustellbarkeitsmeldung. Das ist gewollt, muss aber vorher mit dem Partner getestet werden.

Für die qualifizierte Transportverschlüsselung gibt es zwei Standards. Exchange Online prüft ausgehend automatisch DANE und MTA-STS der Empfängerdomain. Eingehend unterstützt Exchange Online DANE mit DNSSEC, das allerdings nur greift, wenn der MX auf Exchange Online zeigt. Sitzt ein Mail-Gateway davor, ist es der annehmende Server, und es kommt auf dessen Unterstützung für DANE und MTA-STS an. Diese Frage gehört in jede Gateway-Auswahl.

S/MIME und PGP: echte Inhaltsverschlüsselung, mit Nebenwirkungen

S/MIME und OpenPGP verschlüsseln den Inhalt. Nur wer den passenden privaten Schlüssel hat, kann lesen. Das ist der stärkste Schutz und zugleich der mit den meisten betrieblichen Folgen:

• Virenschutz: Ein verschlüsselter Anhang lässt sich unterwegs nicht prüfen.
• Archiv: Eine verschlüsselte Mail im Archiv ist nur lesbar, solange der Schlüssel verfügbar ist. Nach zehn Jahren Aufbewahrung ist das eine ernsthafte Frage.
• Vertretung und Funktionspostfächer: Mails an ein Sekretariat oder eine Station müssen mehrere Personen lesen können.
• Schlüsselverwaltung: Zertifikate laufen ab, Mitarbeitende scheiden aus, Partner wechseln Zertifikate.

Deshalb setzen viele Einrichtungen auf Gateway-Verschlüsselung: Das Mail-Gateway verschlüsselt ausgehend und entschlüsselt eingehend zentral, verwaltet die Schlüssel und archiviert die entschlüsselte Fassung. Suiten wie Hornetsecurity 365 Total Protection bringen das mit, einschliesslich automatischer Wahl zwischen S/MIME und PGP je Empfänger. Ehrlich bleiben sollte man bei der Bezeichnung: Das ist Gateway-zu-Gateway- bzw. Gateway-zu-Empfänger-Verschlüsselung. Zwischen Gateway und Postfach schützt TLS.

Portal- und Push-Verschlüsselung: für alle ohne Zertifikat

Patientinnen und Patienten haben kein S/MIME-Zertifikat. Für sie gibt es zwei Muster:

• Pull: Der Empfänger erhält eine Benachrichtigung und liest die Nachricht in einem Webportal. Beispiele sind Microsoft Purview Message Encryption, bei der externe Empfänger ohne Outlook einen zeitlich begrenzten Link mit Einmalcode erhalten, oder das Websafe-Portal von Hornetsecurity.
• Push: Die Nachricht kommt als verschlüsselter Anhang, etwa als kennwortgeschütztes PDF oder HTML-Container.

Worauf Sie achten sollten:

• Kennwortweg: Wie erhält der Empfänger sein Kennwort? Ein Kennwort in derselben Mail ist kein Schutz. Bewährt haben sich ein separat vereinbartes Kennwort oder ein Einmalcode.
• Antworten: Kann der Empfänger verschlüsselt antworten? Sonst kommt die Rückfrage mit Diagnose im Klartext.
• Aufbewahrung im Portal: Wie lange bleiben Nachrichten abrufbar, und wo liegen sie?
• Phishing-Ähnlichkeit: Benachrichtigungen mit «Klicken Sie hier, um Ihre Nachricht zu lesen» sehen aus wie Phishing. Einheitliches Erscheinungsbild, eigene Absenderdomain und ein Hinweis auf der Website helfen.
• Barrierefreiheit: Das Portal muss auch mit Screenreader und auf dem Smartphone bedienbar sein.

Für Purview Message Encryption steuern Sie die Anmeldeoptionen für externe Empfänger per PowerShell, zum Beispiel ob Einmalcodes erlaubt sind:

Get-OMEConfiguration | Format-List Identity, OTPEnabled, SocialIdSignIn
Set-OMEConfiguration -Identity "OME Configuration" -OTPEnabled $true

KIM: eigener Kanal, nicht Teil von Exchange Online

KIM, Kommunikation im Medizinwesen, ist der E-Mail-Dienst der Telematikinfrastruktur. Nachrichten werden Ende-zu-Ende verschlüsselt und signiert, die Identitäten stammen aus der TI, etwa der Institutionskarte SMC-B. Empfänger findet man über den Verzeichnisdienst der TI. Mit KIM 1.5 sind Anhänge bis 500 MB möglich.

Für die Planung wichtig: KIM ist kein Zusatz zu Exchange Online, sondern ein geschlossener Kanal. Nachrichten laufen über das KIM-Clientmodul und die TI-Anbindung, nicht über Ihren MX und nicht über das Mail-Gateway. Angebunden wird typischerweise das KIS oder ein Mailclient mit eigenem Konto. Daraus folgen drei Konsequenzen:

• KIM ersetzt nicht die übrige Verschlüsselung. Patienten, viele Dienstleister und Partner ausserhalb der TI erreichen Sie darüber nicht.
• KIM-Nachrichten sind nicht automatisch im Mail-Archiv. Klären Sie, wo sie revisionssicher abgelegt werden, im KIS oder in einem eigenen Archivprozess.
• Zuständigkeiten trennen. KIM-Postfächer, Clientmodul und Konnektor bzw. TI-Gateway gehören in die Betriebsdokumentation, mit klarer Verantwortung. Sonst fällt der Kanal bei einem Kartentausch aus, ohne dass es jemand merkt.

Entscheidungsmatrix: welcher Weg für wen

Umsetzung im Betrieb

Die beste Methode nützt nichts, wenn Anwender im Alltag selbst entscheiden müssen. Bewährt hat sich eine Kombination aus Automatik und klaren Ausnahmen:

1. Regeln nach Empfänger: Für bekannte Partner greift automatisch der festgelegte Weg, unabhängig davon, was der Anwender tut.
2. Regeln nach Inhalt: Erkennt eine DLP-Regel oder das Gateway schutzwürdige Inhalte an Externe ohne festen Weg, wird die Mail ins Portal umgeleitet statt im Klartext versendet.
3. Bewusster Auslöser: Ein Schlüsselwort im Betreff oder eine Schaltfläche in Outlook erzwingt die Verschlüsselung im Einzelfall.
4. Nachweis: Das Gateway bzw. Exchange Online protokolliert, welche Mail wie versendet wurde. In Exchange Online liefert Get-MailDetailEncryptionReport Details zu verschlüsselten Nachrichten.

Achten Sie auf die Reihenfolge der Verarbeitung: Signaturen und Disclaimer müssen vor der Verschlüsselung und vor der DKIM-Signatur eingefügt werden, das Archiv erfasst die entschlüsselte Fassung. Wie ein Gateway vor Exchange Online sauber angebunden wird, steht im Artikel Mail-Gateway vor Exchange Online.

Fazit

E-Mail-Verschlüsselung im Gesundheitswesen ist keine Produktfrage, sondern eine Zuordnung: TLS als durchgesetzte Grundlage für alles, Inhaltsverschlüsselung für feste Partner, ein Portal für alle ohne Zertifikat und KIM für die Kommunikation innerhalb der Telematikinfrastruktur. Wer diese Zuordnung dokumentiert und technisch erzwingt, erfüllt den Massstab der Aufsicht und entlastet die Mitarbeitenden. Mehr dazu auf unseren Seiten zur E-Mail-Verschlüsselung und zu Microsoft 365 im Gesundheitswesen.

Nils Lappenbusch

Founder & Technology Architect, Lappenbusch

Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung. Microsoft-365-Mandate übernehmen wir derzeit nur in Deutschland.

Kontakt aufnehmen