HIN Mail im Schweizer Gesundheitswesen

In Deutschland haben Anwälte mit beA ihr eigenes Mailsystem. Im deutschen Gesundheitswesen gibt es KIM Fachdienst und daher verwundert es mich nicht, dass die Schweizer mit HIN ein ähnliches System haben, welches von der Health Info Net AG betrieben wird. Was bedeutet dies für Schweizer Firmen mit medizinischem Kommunikationsbedarf? Durch eine Problemstellung bei Kunden in der Schweiz, die ein HIN-Gateway mit Exchange OnPremises und Exchange Online betreiben, durfte ich hier etwas hinter die Kulissen schauen.

Kliniken, Ärzte und Externe

HIN wurde schon 1996 auf Initiative der Verbindung der Schweizer Ärztinnen und Ärzte (FMH) gestartet und wird von Behörden, Rechtspraktikern und wohl mehr als 90% aller Akteure des schweizerischen Gesundheitssystems genutzt. So werden Arztbriefe und andere Gesundheitsdaten per SMTP zwischen den Teilnehmern übertragen. Das muss natürlich "sicher" erfolgen und dazu kommt SMIME zum Einsatz. Nun habe ich schon auf anderen Seiten geschrieben, dass SMIME zwar sicher aber für viele Anwender einfach nicht  handhabbar ist. Jeder Teilnehmer braucht ein SMIME-Zertifikat mit privatem Schlüssel und die öffentlichen Schlüssel der Empfänger. Das geht nur mit einer passender Infrastruktur. Die wird in der Schweiz durch die Firma HIN (https://www.hin.ch/de/). Sie stellt die zentrale Plattform für eine sichere Kommunikation bereit. Nach meinem Wissensstand sind drei Anwender zu betrachten:

  • Einzelpersonen und kleine medizinische Einrichtungen
    Die HIN stellt mit dem Produkt "HIN-Mail" zentral gehostete Postfächer für diesen Anwendungsfall für ca. 380 CHF/Jahr bereit. Der Arzt kann das Postfach per Webbrowser oder einem IMAP4-Client nutzen. Die Verschlüsselung übernimmt dabei der Service im Backend. Die Anwender haben entweder eine Adresse in der Form <userpart>@hin.ch oder können auch ihre eigene Domain mitbringen.
  • Größere Einrichtungen mit eigenem Gateway
    Über ein HIN-Gateway kann eine Firma alle externen Mails automatisch selbst per SMIME verschlüsseln und entschlüsseln. So haben die Mitarbeiter nur genau ein eigenen Firmenpostfach und die Firma erspart sich eine Doppelpflege von Postfächern beim Provider HIN.
  • Externe Teilnehmer
    Ein HIN-Teilnehmer kann auch Mails z.B. an eine deutsche Adresse senden und eine Verschlüsselung anfordern. In dem Fall wird die Mail auf einem Webserver von HIN für den Abruf durch den Empfänger nach entsprechender Authentifizierung bereit gehalten.

Als Transport kommt dabei klassisches SMTP und SMIME zum Einsatz, d.h. die Mailserver lösen einfach den MX-Record auf und senden ihre Mails per SMTP. Wer ein HIN.CH-Postfach nutzt, muss nicht viel machen, denn das Backend "kennt" ja alle Domains und Postfächer, die ebenfalls ein HIN.CH-Postfach haben. Bei Firmen mit eine eigenen Gateway prüft das Gateway einfach die Domain, ob sie "HIN-enabled" ist. Das können Sie als interessierter Leser auch selbst machen, da HIN auf ihrer Webseite eine Abfrage einer Domain erlaubt.

Im Hintergrund wird über eine einfache URL ein "True/False" zurückgegeben, so dass Sie die Prüfung auch einfach per PowerShell automatisieren könnten.

Invoke-Restmethod "https://www.hin.ch/__api.cfm?_action=api.public.domainchecker&domain=hin.ch"

Das bringt ihnen aber nicht viel, denn an die öffentlichen Schlüssel der Teilnehmer kommen Sie so nicht.

HIN bietet aber noch mehr, z.B. ein Datenaustauschbereich etc., was ich hier aber nicht weiter beschreibe.

HIN-Gateway

Interessanter ist das HIN-Gateway, welches für Firmen die Anbindung ihres Firmenpostfachs an HIN erlaubt. HIN hat die Konfiguration und Anbindung ausführlich beschrieben. So sieht die Standardinstallation vor, dass das HIN-Gateway zwischen Internet und eigenem Mailserver konfiguriert wird:

Die Problematik ist hier, dass wohl niemand das Gateway als "Eingangsserver" veröffentlichen möchte, sondern davor zumindest ein Spamfilter stehen sollte, der aber die verschlüsselten Mails dann nicht auf Malware prüfen kann. Umgekehrt könnte das Gateway zwar die Mails schon verschlüsseln aber der nachgeschaltete Spamfilter könnte die Mail dann nicht mehr ablehnen. Zudem müsste das HIN Gateway auch ganz viel noch nicht abgelehnten Spam überflüssigerweise verarbeiten. Das sind aber technische Feinheiten.

Interessanter ist hier eher, dass das HIN Gateway eine Verbindung zum HIN-Backend hat, aus dem es sich die Information bezieht, welche Domain ebenfalls ein HIN-Gateway oder Postfach bezieht. Das erinnert mich etwas an das DoI-Netzwerk der deutschen Städte und und Gemeinden, die ebenfalls eine Domainliste mit Mailservern verteilt, die über das interne Netzwerk erreicht werden können. Hier stellt das HIN-Backend aber auch die SMIME-Zertifikate bereit.

Die ausgehende Mail wird vom Gateway anhand der Domain des Empfängers geprüft, ob diese ein HIN-Teilnehmer ist und daher die Mail verschlüsselt werden muss. Trifft dies zu, besorgt das Gateway vom HIN-Backend das Zertifikat, verschlüsselt die Mail und sendet sie dann aber über das normale Internet und den MX-Record an das Zielsystem.

Eingehende Mails kommen beim HIN-Gateway an und wenn diese verschlüsselt sind, kann das HIN-Gateway anhand der lokal vorhandenen Schlüssel die Mails entschlüsseln und ans eigene Mailsystem weitergeben.

Der Mitarbeiter mit einem für HIN aktivierten Postfach merkt idealerweise nichts, denn er arbeitet einfach mit seinem gewohnten Mail-Programm. Wenn ein Anwender nicht mit einem Gateway arbeitet, dann kann er seine Mail in einem bei HIN gehosteten Postfach per Browser (https://webmail.hin.ch/) lesen und schreiben oder per IMAP4/SMTP arbeiten.

HIN Mail Global

Aktuell bin ich als deutscher Teilnehmer natürlich kein HIN-Mitglied und die Schweiz ist zwar in vielen Beziehungen auch mit der EU verbunden aber wenn mein Kontakt einer Schweizer Klinik mit eine "Vertrauliche Mail" sendet, landen in meinem Posteingang folgende Mail:

Natürlich habe ich mir zuerst den SMTP-Header in einem Text-Editor angeschaut:

Warum der ausgehende Server 193.247.208.67 (mx3.hin.ch) so lange gewartet hat, kann ich nicht sagen. Viel interessanter finde ich aber, dass die internen Header des Kundenservers und dessen lokalen Gateways nicht sichtbar sind. Das HIN-Gateway vor Ort muss eine Logik haben, um vertrauliche Mails von HIN-Absendern an externe Partner immer zum Portal von "hin.ch" zu senden.

Die Benachrichtigungsmails kommt aber nicht von einer hin.ch-Adresse und auch nicht vom HIN-Gateway sondern von einer IP-Adresse der Hin. Dies bedeutet natürlich, dass alle HIN-Mitglieder auch immer die IP-Adresse der HIN im SPF-Record mit eintragen müssen und damit der HIN quasi erlauben, im Namen des Kunden zu spreche. Da bleibt zu hoffen, dass HIN ihre Systeme dauerhaft sicher betreibt. Ich hätte mir eher ein einen Absender "info@hib-global.de im Auftrag von user@hin-teilnehmer" gewünscht.

 

Die eigentliche Information steht in der Anlage "Secure-email.html", die ich mir auch in einem Text-Editor angezeigt habe.

Sie sehen ein HTML-Formular, in dem als versteckte Parameter der Empfänger und Absender aber auch weitere Felder die "Secmail0" etc. zu sehen sind. Über die CSS-Kennzeichnung erkennen Fachleute, dass HIN im Dezember 2024 auf das GINA-Verfahren der Schweizer Firma SeppMail setzt.

HIN-Gateway und Microsoft 365

Anfangs habe ich geschrieben, dass meine Tätigkeiten für die Schweizer Auftraggeber mit der Nutzung von Exchange Online verbunden waren. Durch den Umzug von Postfächern in die Cloud wird es immer offensichtlicher, dass ein OnPremises-Gateway eigentlich falsch aussieht. Wenn der MX-Record zu Exchange Online verweist, dann ist der Umweg über OnPremises ineffektiv.

 

Meines Wissens gibt es aber noch kein HIN-Gateway als "Cloud Service" der Health Info Net AG oder als VM in Azure Warehouse.

Das ist etwas komisch, denn HIN und das HIN-Gateway bauen eigentlich auf dem Stack von SEPPMail auf. Ich habe aber keine Informationen gefunden, das die SEPPMail.cloud eine HIN-Funktion übernehmen könnte.

Als Kunde können Sie natürlich z.B. in Azure oder auf einer anderen Plattform eine "virtuelle Maschine" kaufen und dort das HIN-Gateway selbst installieren und auf eigene Kosten und in eigener Verwaltung betreiben. Wenn Sie ihr HIN-Gateway in Exchange Online integrieren wollen, dann erfolgt dies am besten überpassende Connectoren und Transportregeln, z.B.:

  • Mails aus dem Internet mit "X-HIN-Encrypted:True" zum Transportconnector zum HIN-Gateway umleiten, außer sie waren schon beim eigenen HIN-Gateway.
    Das HIN-Gateway kennt eine "Exchange Online" Unterstützung, indem es das Zertifikat bzw. IP-Adressen und die TenantID prüfen kann, so dass nur ihr Tenant dieses nutzen kann. Denken Sie dran: Rein technisch ist ein HIN-Gateway auch von anderen Tenants erreichbar.
  • Mails in das Internet immer zum HIN-Gateway rerouten, außer es war schon dort
    So kann das Gateway anhand der Zieldomain entscheiden, ob die Mails verschlüsselt werden muss oder unverschlüsselt zu Exchange Online zurückgeroutet wird. Exchange Online braucht dann einen Inbound OnPremises-Connector, um die MAils vom HIN-Gateway wieder anzunehmen und ins Internet zu senden.

Das ist eine stark vereinfachte Beschreibung. Für die "Erkennung", dass eine Mail schon einmal durch das eigene HIN-Gateway geroutet wurde, sollten Sie einen eigenen Header addieren und bei Übertragungen zum Internet entfernen. Interessant finde ich, dass das HIN Gateway schon für Exchange Online entsprechende Einstellungen erlaubt:


Quelle: Kunde mit anonymisierten Daten.

Sie können hier die SMTP-Domains ihres Tenant hinterlegen, die das HIN Gateway dann aus dem Feld X-OriginatorOrg auswertet, um ausgehende Mails nur von ihrem Tenant zuzulassen. Zusätzlich können Sie auch die TenantID hinterlegen, die im SMTP-Header "X-MS-Exchange-CrossTenant-Id" (Siehe auch X-MS-Exchange-Organization-AuthAs) durch Exchange Online übermittelt wird. Beachten Sie dazu auch folgende weitere Seiten:

Wenn Sie nun die Dokumentation der SEPPMail-Appliance auf folgender Seite anschauen und die Bilder vergleichen, dann ist das schon mehr als eine Ähnlichkeit:

Ich würde mal behaupten, dass das HIN-Gateway eigentlich eine SEPPMail Appliance mit reduzierter Funktion ist.

Mit dem richtigen Verständnis ist es aber schon heute möglich, dass eine Firma mit medizinischem Kommunikationsbedarf in der Schweiz seine Postfächer zu 100% in Exchange Online betreibt.

Ob irgendwann auch andere SMIME/PGP-Gateway die Funktionen von HIN, z.B. die Abfrage und Veröffentlichung von Zertifikaten nutzen können und damit Kunden auch andere Gateway-Produkte einsetzen können, konnte ich noch nicht verifizieren.

Dokumentation ausbaufähig

Im Dialog mit dem Kunden haben wir uns die Funktionsweise erschlossen aber natürlich auch die Dokumentation (Stand Dez 2024) herangezogen. Dabei ist uns aufgefallen, dass Sie wohl etwas "Liebe" bei der Qualitätssicherung brauchen könnte. Die Verweise im Inhaltsverzeichnis der Hauptdokumentation verweisen auf nicht existente Kapitel. Die Beschreibung in dem gesonderten Dokument zu Office 365 ist anscheinend eine Mischung von Alt und Neu ist. Hier ein paar Beispiele:

  • Ungültiges Format einer IP-Adresse
  • Credentials im Beispiel, die hier gesetzt aber nirgendwo anders abgeprüft werden. Auch ist die Musterregel "deaktiviert" und warum setzt man die Absenderdomain nicht auf "Internal"?
  • X-HIN-Encrypted
    Um nur die durch HIN verschlüsselten Mails durch das Gateway zu routen, wird eine Steuerung über den Header "X-Hin-Encrypted" empfohlen

Sie können sich gerne ein eigenes Bild über die Dokumentation machen. Aber so ist es natürlich nicht überraschend, dass die ein oder andere Klinik bei der Einrichtung auf Probleme stößt oder nicht alle Sonderfälle korrekt konfiguriert hat.

Dokumentation zum Gateway
https://download.hin.ch/gw/hin-gateway.zip

Vielleicht sollte die Dokumentation einfach als Webseiten bereitgestellt werden, so dass sie schnell aktualisiert werden kann. Die Qualitätssicherung kann sicher noch einmal darüber schauen.

Kein SMIME außerhalb von HIN?

Sowohl das HIN-Gateway als auch ein bei HIN gehostetes Postfächer nutzen SMIME und Zertifikate. All meine Mails von Net at Work sind ebenfalls per SMIME signiert und wir stellen unsere Zertifikate auch über verschiedene Keyservices, z.B. https://openkeys.de/ bereit. Allerdings scheinen die SMIME-Zertifikate von HIN nicht extern verfügbar zu sein und das HIN-Gateway lernt auch keine SMIME-Zertifikate von eingehenden signierten Mails.

Ich habe nur über Suchmaschinen einen Link auf einen "HIN-Konnector" gefunden, der eine Verbindung zur Appliance von SEPPMail erstellt.

Im Grunde ist es ja verständlich, dass eine Kommunikationsplattform im Gesundheitswesen auch durch eine "geschlossene Umgebung" viele Angriffsmöglichkeiten von Vorneherein ausschließt. Dass es eine gewisse Verbindung zwischen HIN und SEPPMail geben dürfte, konnten Sie schon bei der Analyse der Mail über "HIN Mail Global" sehen. Aber auch andere Hersteller, und damit meine ich nicht nur NoSpamProxy, können SMIME.

Sobald ich Neuigkeiten habe, werde ich diesen Abschnitt erweitern.

Weitere Links