Konzeption und prototypische Realisierung eines Secure-Messaging-Systems unter Nutzung von eGK und HBA

Inhalt

Technische Architektur der für Signal benötigten Komponenten
Einführung
Komponenten

Einführung

Diese prototypische Realisierung beschreibt den Entwurf und die Konzeption eines vollständigen Secure-Messaging-Systems, wobei die Authentizität der Kommunikationspartner mithilfe der elektronischen Gesundheitskarte (eGK) und des Heilberufsausweises (HBA) sichergestellt wird und die Kommunikationsinhalte verschlüsselt übertragen werden. Dieses System ermöglicht es Patienten, direkt per Chat mit einem Arzt zu kommunizieren und/oder Dokumente und Daten auszutauschen. Erforderlich sind ein Internetzugang und eine ununterbrochene Online-Verfügbarkeit aller Teilnehmer während der Kommunikation.

Nutzung von docker / docker-compose

Alle Bausteine der prototypischen Realisierung werden in Form von docker Containern realisiert. Dieser Ansatz ermöglicht ein einfaches Deployment in verschiedenen Betriebsumgebungen, angefangen von Entwicklerarbeitsplätzen, über klassische Server im Rechenzentrum bis hin zu modernen Cloudinfrastrukturen. Weiterführende Informationen zu docker finden sich unter https://www.docker.com/. Für die Orchestrierung der verschiedenen Container wird docker-compose genutzt.

Quelltext / Build-Artefakte

Der Quelltext der entwickelten Komponenten sowie alle weiteren Artefakte, die für den Aufbau einer lauffähigen Umgebung benötigt werden (Beispielkonfiguration, build und deployment Skripte für docker etc.) sind nach Projektabschluss im git-Repository des Fraunhofer FOKUS zu finden. Eine Übersicht aller verfügbaren Artefakte findet sich hier.

Komponenten

Die nachfolgenden Abschnitte beschreiben die konkrete Realisierung der durch die technische Architektur vorgegebenen Lösungskomponenten. Die Abbildung der jeweiligen Komponenten bzw. deren funktionaler Bestandteile erfolgt dabei über separate Lösungsbausteine, die als individuelle docker-Container realisiert werden.

Die folgende Abbildung bietet einen Überblick über die für die prototypische Realisierung genutzten Lösungsbausteine:

Jedes Rechteck repräsentiert einen docker Container und besteht aus Angaben zum Containernamen, zur genutzten Software (Angabe in eckigen Klammern), zum Port, über den Dienste für andere Container im selben logischen Netz bereitgestellt werden sowie zum Port über den der entsprechende Dienst über das Netzwerkinterface des Hosts erreicht werden kann (fett gedruckt). Die einzelnen Containern sind dabei verschiedenen logischen Schichten zugeordnet:

Frontend Services: Dienste die von den Clientsystemenen direkt genutzt werden. Dies schließt Dienste mit ein, die über einen Reverse Proxy zugänglich gemacht werden. Backend Services: Dienste die von anderen Diensten der Infrastruktur (aber niemals direkt von den Clients) genutzt werden. Data Layer: Die Data Layer umfasst Dienste, die die Persistierung von Daten der Backend- oder Frontend-Services umsetzen. Da es sich beim Deployment lediglich um eine prototypische Realisierung handelt, wurde davon abgesehen entsprechende Dienste umzusetzen. Es wird jeweils eine in die jeweiligen Lösungen (keycloak, hapi-fhir ) integrierte Lösung zur Speicherung verwendet, die im selben Container läuft.

Signal-Server

Der Signal-Server ist der Kern des Secure-Messaging-Systems. Er basiert auf der Implementierung des non-profit und open-source Signal, wurde jedoch an die Anforderungen des aktuellen Projekts angepasst. Der Singal-Server bietet Patienten und Ärzten die Möglichkeit an, sicher miteinander zu kommunizieren und der Identität ihres Kommunikationspartners zu vertrauen.

Die Hauptfunktionen des Servers bestehen darin, die Nachrichten der Nutzer zu verteilen, die Benutzerprofile zu verwalten, und den Datenverkehr zur Registrierung und Authentifizierung an den Identity Provider weiterzuleiten und somit die Identitäten der Benutzer zu verifizieren.

Ausgestaltung

Konfigurierbarkeit

Das Projekt bietet die Möglichkeit wesentliche Parameter des Signal-Servers über die Umgebungsvariablen des Docker Conatainers zu steuern. Dazu gehören

• ADMIN_SERVER_PORT: Port über den der Dienst durch den Administartor konfigurierbar ist
  

• ADMIN_SERVER_TYPE: Protokoll mit dessen Hilfe der Administrator mit dem Server kommunizieren kann
  

• APN_BUNDLE_ID: Eindeutige ID die jede IOS App besitzt -> com.secret.signalTest
  
• APN_PUSH_CERTIFICATE: Zertifikat das es Drittanbietern ermöglicht Push-Nachrichtigungen an iOS-Benutzer zu senden
  

• APN_PUSH_KEY: wird dazu benutzt um Push-Nachrichten an Apple Geräte zu senden. APN (Apple Push Notification)
  

• APP_SERVER_PORT: Port über den der Signal-Server Dienst erreichbar ist -> ‘9002’
  

• APP_SERVER_TYPE: Protokoll mit dessen Hilfe eine Kommunikation mit dem Server stattfindet -> http
  

• FCM_API_KEY: Schlüssel um die Firebase Cloud Messaging API zu nutzen. FCM (Firebase Cloud Messaging)
  

• FCM_SENDER_ID: Ein eindeutiger numerischer Wert, der bei der Erstellung eines Firebase-Projekts erstellt wird
  

• MINIO_ATTACHMENTS_ACCESS_KEY: Eine weltweit eindeutige Benutzerkennung
  
• MINIO_ATTACHMENTS_ACCESS_SECRET: geheimer Zugriffsschlüssel im wesentlichen ein Passwort
  
• MINIO_ATTACHMENTS_BUCKET: Definiert den Pfad zum MinIO Bucket(Datenspeicher) Attachments -> bucket-for-attachments
  
• MINIO_ATTACHMENTS_ENDPOINT: Definiert den Pfad zur MinIO’s öffentlicher Cloud-Speicherressource -> ‘https://movi-signal-evaluation.apps.osc.fokus.fraunhofer.de’
  
• MINIO_PROFILES_ACCESS_KEY: Eine weltweit eindeutige Benutzerkennung
  
• MINIO_PROFILES_BUCKET: Definiert den Pfad zum MinIO Bucket(Datenspeicher) Profiles -> bucket-for-profiles
  
• MINIO_PROFILES_ENDPOINT: Definiert den Pfad zur MinIO’s öffentlicher Cloud-Speicherressource -> ‘https://movi-signal-evaluation.apps.osc.fokus.fraunhofer.de’
  
• MINIO_PROFILES_REGION: Definiert die Region in der die Daten gehostet werden -> eu-west-1
  

• MINIO_PROFILES_SECRET: Geheimer Zugriffsschlüssel im wesentlichen ein Passwort
  

• OIDC_JWK_URL: URL über der der OpenID Server seine Metadaten veröffenlicht -> https://movi-keycloak.apps.osc.fokus.fraunhofer.de/auth/realms/MOVI/protocol/openid-connect/certs
  
• OIDC_JWT_CLIENTID: Eindeute Benutzer ID zur authentifizierung über OpenID
  

• OIDC_JWT_ISSUER: Identifiziert den OpenID Provider -> ‘https://movi-keycloak.apps.osc.fokus.fraunhofer.de/auth/realms/MOVI’
  

• POSTGRES_DATABASE_DRIVER_CLASS: Bevor eine Verbindung mit der Datenbank hergestellt werden kann wird ein Treiber benötigt -> org.postgresql.Drive
  
• POSTGRES_DATABASE_PASSWORD: Passwort für die Postgress Datenbank Accounts
  
• POSTGRES_DATABASE_URL:URL zu der Postgres Account Datenbank -> ‘jdbc:postgresql://signal-postgres:5432/accountdb’
  
• POSTGRES_DATABASE_USER: Benutzername für Postgress Account Datenbank -> postgres
  
• POSTGRES_MESSAGE_STORE_DRIVER_CLASS: bevor eine Verbindung mit der Datenbank hergestellt werden kann wird ein Treiber benötigt -> org.postgresql.Drive
  
• POSTGRES_MESSAGE_STORE_PASSWORD: Passwort für die Postgress Datenbank Message
  
• POSTGRES_MESSAGE_STORE_URL: URL zu der Postgres Message Datenbank -> ‘jdbc:postgresql://signal-postgres:5432/messagedb’
  

• POSTGRES_MESSAGE_STORE_USER: Benutzername für Postgress Message Store Datenbank -> postgres
  

• PUSH_QUEUE_SIZE: Größe mit der Push Events gequeuet werden-> ‘1024’
  

• REDIS_CACHE_REPLICA: Kopie des Redis Cache zur Ausfallsicherheit -> ‘redis://redis:6379/2’
  
• REDIS_CACHE_URL: Redis Hauptchache -> ‘redis://redis:6379/1’
  
• REDIS_DIRECTORY_REPLICA: Kopie des Redis Directory zur Ausfallsicherheit -> ‘redis://redis:6379/6’
  
• REDIS_DIRECTORY_URL: Redis Root Directory -> ‘redis://redis:6379/5’
  
• REDIS_MESSAGE_CACHE_REPLICA: Kopie des Redis Message-Cache zur Ausfallsicherheit -> ‘redis://redis:6379/4’
  
• REDIS_MESSAGE_CACHE_URL: Redis Cache für Nachrichten -> ‘redis://redis:6379/3’
  
• REDIS_PUSH_SCHEDULER_REPLICA: Kopie des Redis Directory zur Ausfallsicherheit -> ‘redis://redis:6379/8’
  
• REDIS_PUSH_SCHEDULER_URL: Organisiert Push-Events -> ‘redis://redis:6379/7’
  

MinIO

MinIO ist ein mit Amazon S3 kompatibler Cloud-Storage-Server. Als Objektspeicher kann MinIO unstrukturierte Daten wie Fotos, Videos, Log-Dateien, Backups und Container-Bilder speichern und ist gleichzeitig performant, skalierbar und leichtgewichtig.

Die Funktion von MinIO besteht darin, Benutzerprofilinformationen (wie Name, Profilbild usw.) und die zwischen den Benutzern versandten Dokumente (verschlüsselt) zu speichern.

Ausgestaltung

Konfigurierbarkeit

• MINIO_ACCESS_KEY: Eine weltweit eindeutige Benutzerkennung
  
• MINIO_SECRET_KEY: Geheimer Zugriffsschlüssel im wesentlichen ein Passwort
  

PostgreSQL

Postgres ist ein relationales Open-Source Datenbank-Managementsystem, bei dem die Erweiterbarkeit und die Einhaltung technischer Standards im Vordergrund stehen. Es ist für eine Reihe von Workloads ausgelegt, von einzelnen Computern bis hin zu Data Warehouses oder Webdiensten mit vielen gleichzeitigen Nutzern.

Im Signal-Server speichert die Postgres-Datenbank die Benutzernamen und die Geschichte der Benutzernachrichten.

Konfigurierbarkeit

• POSTGRESQL_ADMIN_PASSWORD: Passwort für das Administratorkonto

Redis

Redis (Remote Dictionary Server) ist ein Open-Source Datenbank-Verwaltungssystem, das mit NoSQL-Datenbanken arbeitet und Datenstrukturen vom Typ “key-value” verwendet. Das System kann gleichzeitig als Speicher und Cache betrachtet werden, was Redis sehr mächtig und effizient macht. Das bedeutet, Daten werden immer aus dem Hauptspeicher des Computers gelesen und modifiziert, aber gleichzeitig in einem ungeeigneten Format für den Zugriff von „random access“ Daten auf der Festplatte gespeichert. Dies ermöglicht es, die Daten nach dem Neustart des Systems im Speicher wiederherzustellen.

Im Signal-Server wird Redis zum Zweck der Datenbankverwaltung, aber hauptsächlich für das Caching der Nachrichten verwendet. Aufgrund der Art des Datenbankdesigns passt Redis am besten für Nachrichtenwarteschlangen-Anwendungen wie Signal.

Firebase Cloud Messaging

Firebase Cloud Messaging (FCM) ist ein plattformübergreifendes Messaging-System, mit dem man Nachrichten zuverlässig und bis zu einer bestimmten Nachrichtenmenge pro Monat kostenlos übermitteln kann. Beispielsweise kann man eine Client-App benachrichtigen, dass neue E-Mails oder andere Daten zur Synchronisierung verfügbar sind.

Im Signal Server wird FCM verwendet, um Push-Nachrichten zu versenden. Die Push-Nachrichten werden sofort auf dem Smartphonebildschirm angezeigt und dienen zur Information über ein Ereignis, z.B. den Erhalt einer neuen Nachricht.

Reverse Proxy

Der Reverse Proxy leitet Anfragen von beliebigen Clients an die jeweiligen Dienste im Backend weiter. In diesem Zusammenhang kann er eine Reihe von weiteren Aufgaben übernehmen:

• Zentrale Terminierung von TLS-Verbindungen: Die TLS-Verbindung mit dem Client wird bereits am Reverse Proxy terminiert. Dies ermöglicht den Einsatz speziell gehärteter und auf Performance zugeschnittener Lösungen. Eine Härtung des TLS-Stacks der geschützten Dienste ist dann nur noch in geringerem Umfang erforderlich.
• Load Balancing: Sofern erforderlich kann der Reverese Proxy auch in der Rolle eines Load Balancers agieren und Anfragen gleichmäßig über verschiedene Dienstinstanzen hinweg verteilen.
• Fallback: Sofern erforderlich kann der Reverse Proxy ausgefallene oder gestörte Dienstinstanzen erkennen und den Datenverkehr auf Backup-Systeme umleiten.
• URL-Rewriting: Sofern erforderlich kann der Reverse Proxy angefragte URLs umschreiben und somit z.B. an die Anforderung der maskierten Backenddienste anpassen.
• Sicherheit: Speziell erweiterte Varianten eines Reverse Proxies können als Web Application Firewall (WAF) fungieren und den eingehenden und ausgehenden Datenverkehr bezüglich bestimmter Angriffe analysieren. Andere Erweiterungen erlauben die enge Verzahnung mit Identity Providern, um Clients/Nutzer zu authentifizieren und ggf. auch zu autorisieren.