Zum Inhalt

Sicherheit

HERA legt großen Wert auf die Sicherheit von Zugängen und Daten. Diese Seite informiert Entscheider über die technischen Maßnahmen.

Datenschutz

Der Schutz der Daten der Organisation-Angehörigen ist ein fundamentaler Bestandteil der Implementierung von HERA. HERA stellt sicher, dass alle Anwenderinnen nur Zugriff auf die personenbezogenen Daten haben, die für ihre Aufgabe erforderlich sind. Der Zugriff auf Gesundheitsdaten ist auf wenige Rollen in HERA beschränkt.

Für die Verwendung von HERA wird ein Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO abgeschlossen. Es werden keine Daten an Dritte weitergegeben und der Zugriff auf die Infrastruktur ist beschränkt. Durch die verschlüsselte Speicherung hochsensibler Daten ist außerhalb der Anwendung kein Zugriff auf diese Informationen möglich.

Die Verarbeitung personenbezogener Daten erfolgt grundsätzlich auf Grundlage einer ausdrücklichen, jederzeit widerrufbaren Einwilligung der betroffenen Person. Eine ausführliche Beschreibung der Bausteine befindet sich im Abschnitt Einwilligungsmanagement auf dieser Seite sowie im operativen Kapitel Einwilligungsmanagement.

Einwilligungsmanagement

Das Einwilligungsmanagement ist als eigenständiger Baustein in HERA umgesetzt. Es bündelt die Funktionen, die einen rechtssicheren Umgang mit personenbezogenen Daten unterstützen.

Einwilligungs-Gate beim ersten Aufruf

Vor der ersten produktiven Nutzung muss jede Person ausdrücklich entscheiden, ob HERA ihre Daten verarbeiten und speichern darf. HERA leitet eine Person mit offenem Einwilligungsstatus automatisch auf eine Einwilligungs-Seite. Erst nach einer Entscheidung sind die regulären Funktionen erreichbar.

Die Einwilligung gliedert sich in zwei Ebenen:

  1. Generelle Einwilligung in die Verarbeitung und Speicherung der Daten zur Nutzung von HERA.
  2. Optionale Einwilligung pro Datenkategorie für die Übernahme bestimmter Daten aus THWin.

Die optionalen Datenkategorien sind:

Kategorie Inhalt
Ausbildungsstand Eigener Stand und Unterstützung der Führungskräfte bei der Ausbildungsplanung.
Belehrungen DGUV-Belehrungen, Bescheinigungen, Terminplanung und Hinweise zur Einsatzbefähigung.
Kontaktdaten aus der Mitgliederakte Telefon, E-Mail, Anschrift, Arbeitgeber, Bankverbindung.
Gesundheitsdaten Impfstatus, Untersuchungen, Terminplanung und Hinweise zur Einsatzbefähigung.

Folgen einer Ablehnung oder eines Widerrufs

  • Wer die generelle Einwilligung ablehnt, gibt damit den Verzicht auf eine Nutzung von HERA zu erkennen. Das Benutzerkonto wird gelöscht, der zugehörige Mitgliederdatensatz anonymisiert. Ein Hash über den Namen verhindert die versehentliche Wiederanlage durch Importe.
  • Wird eine optionale Einwilligung widerrufen, löst HERA automatisch die Datenminimierung für die betroffene Kategorie aus.
  • Sämtliche Vorgänge werden im Audit-Log dokumentiert.

Importe nur mit Einwilligung

Personenbezogene Importe verarbeiten ausschließlich Daten von Personen, für die zum Zeitpunkt des Imports eine passende Einwilligung vorliegt. Datensätze ohne passende Einwilligung werden übersprungen und im Importprotokoll vermerkt. Damit ist auch im laufenden Betrieb sichergestellt, dass nur Daten verarbeitet werden, für die eine Einwilligung vorliegt.

Betriebsmodi der Dienststelle

Der Dienststelle wählt aus zwei Betriebsmodi:

  • Manueller Betrieb (Standard für neue Dienststellen) – personenbezogene THWin-Importe sind ausgeblendet. Mitglieder werden über das Bewerbungsverfahren oder den reduzierten Mitgliederliste-Import aufgenommen.
  • THWin-Personaldaten – personenbezogene THWin-Importe stehen zusätzlich zur Verfügung.

Der Betriebsmodus wirkt unmittelbar auf die in den Importen sichtbaren Datentypen.

Datenminimierung als Verwaltungswerkzeug

Personen mit der Rolle Dienststellenadministration können personenbezogene Daten gezielt entfernen. Die Aktion erfolgt mit Vorschau, gezielter Auswahl und transaktional. Verfügbare Aktionen:

  • Berechtigungen und Anhänge
  • Gesundheitsdaten
  • Verschlüsselte THWin-Daten
  • Ausbildungsstand
  • Mitglieder ohne Positionierung

Anonymisierung soft-gelöschter Mitglieder

Soft-gelöschte Mitglieder werden nach einer Aufbewahrungsfrist von sieben Tagen durch einen täglichen Hintergrundjob endgültig anonymisiert.

Einwilligung entsperren

Personen, die der Nutzung widersprochen haben, sind anschließend gesperrt. Die Rolle Dienststellenadministration kann diese Sperre über ein eigenes Werkzeug aufheben, sofern die betroffene Person erneut entscheiden möchte. Die Aufhebung wird im Audit-Log dokumentiert.

Audit-Log

Alle Vorgänge im Einwilligungsmanagement werden im Audit-Log erfasst, einschließlich Einwilligung erteilt, abgelehnt, widerrufen, zurückgesetzt sowie ausgeführter Datenminimierungen.

Eine ausführliche Anleitung für die Verwaltung enthält das Kapitel Einwilligungsmanagement.

Login-Sicherheit

  • Benutzer können sich per Magic-Link anmelden: Nach Eingabe der E-Mail-Adresse erhalten sie einen zeitlich begrenzten Link zur Anmeldung.
  • Kein Passwort muss übertragen werden – reduziert Risiken durch Phishing und Passwort-Leaks.
  • Die Anforderung von Magic-Links ist rate-limitiert. HERA begrenzt die Anzahl der Anfragen pro IP-Adresse, pro E-Mail-Adresse und pro Kombination aus IP-Adresse und E-Mail-Adresse. Dadurch werden E-Mail-Fluten, automatisierte Missbrauchsversuche und Account-Enumeration erschwert.

Zwei-Faktor-Authentifizierung (2FA)

  • 2FA per TOTP (Time-based One-Time Password): Nutzer mit Rollen müssen ein Einmal-Passwort einrichten (z.B. mit Google Authenticator, Authy oder 1Password).
  • dienststellenweite Verpflichtung: Ein Dienststelle kann festlegen, dass alle Nutzer 2FA verwenden müssen.
  • TOTP-Verschlüsselung: Die TOTP-Geheimnisse werden verschlüsselt in der Datenbank gespeichert.
  • Begrenzte 2FA-Versuche: Die Verifikation von TOTP-Codes ist rate-limitiert. Nach zu vielen Fehlversuchen wird der laufende 2FA-Anmeldevorgang verworfen und muss neu gestartet werden.

Schutz vor Brute-Force-Angriffen

Passwortanmeldungen werden mit einem Sliding-Window-Rate-Limit geschützt. HERA zählt Anmeldeversuche getrennt nach IP-Adresse, E-Mail-Adresse sowie IP-E-Mail-Kombination. Dadurch bleiben einzelne Fehlversuche tolerierbar, während automatisiertes Durchprobieren von Passwörtern ausgebremst wird.

Passwort-Verschlüsselung

Die Speicherung von Passworten erfolgt mit einem bewährten Hashing-Verfahren (bcrypt).

Session-Sicherheit

Session- und Anmelde-Tokens werden durch HERA serverseitig verwaltet und zeitlich begrenzt. Die Browser-Cookies sind mit HttpOnly und SameSite=Lax versehen. Im Produktivbetrieb werden Session-Cookies zusätzlich als Secure markiert und verschlüsselt, sodass sie nur über HTTPS übertragen und vom Browser-JavaScript nicht gelesen werden können.

Persistente "Angemeldet bleiben"-Cookies sind ebenfalls HttpOnly, SameSite=Lax und im Produktivbetrieb Secure. Beim Abmelden werden serverseitige Sitzungstokens gelöscht und aktive LiveView-Verbindungen getrennt.

Transport- und Header-Sicherheit

Im Produktivbetrieb erzwingt HERA HTTPS und setzt HSTS, damit Browser nach dem ersten erfolgreichen HTTPS-Aufruf keine unverschlüsselten Verbindungen mehr verwenden. Der Betrieb hinter einem Reverse Proxy ist vorgesehen; weitergeleitete Client-IP-Header werden nur vertraut, wenn dies in der Betriebsumgebung explizit aktiviert wurde.

Die produktiven Signing- und Encryption-Salts müssen als Umgebungsvariablen gesetzt werden. HERA startet im Produktivbetrieb nicht mit bekannten Default-Salts für Session-, LiveView- oder Cookie-Verschlüsselung.

Content Security Policy (CSP)

HERA setzt für Browser-Seiten eine Content Security Policy. Die Standardrichtlinie erlaubt Ressourcen grundsätzlich nur aus der eigenen Anwendung ('self') und blockiert Plugins über object-src 'none'. Für Skripte wird pro Anfrage ein Nonce erzeugt; dadurch können notwendige eigene Inline-Skripte freigegeben werden, ohne pauschal unsafe-inline für JavaScript zu erlauben.

Die wichtigsten CSP-Direktiven sind:

  • default-src 'self' als restriktive Grundlage.
  • script-src 'self' mit pro Anfrage erzeugtem Nonce.
  • object-src 'none' und base-uri 'self'.
  • form-action 'self'.
  • frame-ancestors 'self' für reguläre Seiten.
  • connect-src 'self' ws: wss: für LiveView-Verbindungen.
  • img-src 'self' data: blob: für Bilder, Signaturen und lokale Vorschauen.
  • worker-src 'self' blob: für PDF- und Service-Worker.
  • style-src 'self' 'unsafe-inline', weil Phoenix LiveView und UI-Übergänge an einzelnen Stellen Inline-Styles benötigen.

Einbettbare Registrierungsseiten sind eine Ausnahme: Sie dürfen nur für den dafür vorgesehenen Embed-Modus in einem iframe angezeigt werden. Die erlaubten frame-ancestors werden im Betrieb konfiguriert und sind standardmäßig nicht global offen.

Datei- und Download-Sicherheit

Sensible Uploads werden nicht über den öffentlichen Static-File-Pfad ausgeliefert. Der Zugriff erfolgt über geschützte Controller, die Benutzer-, Organisations- und Rollenberechtigungen prüfen. Organisationsadministration erhält Zugriff nur auf Dateien der eigenen Organisation; globale Systemadministration bleibt davon getrennt.

Dokumentationsdateien unter /docs werden vor der Auslieferung normalisiert und auf das erlaubte Dokumentationsverzeichnis beschränkt. Dadurch können Pfad-Traversal-Angriffe wie ../ nicht aus dem Dokumentationsverzeichnis ausbrechen.

Datensicherheit

Die folgenden Daten werden verschlüsselt in der Datenbank gespeichert:

Kategorie Beispiele
Zugangsdaten TOTP-Geheimnisse (2FA)
Gesundheitsdaten Impfungen, medizinische Angaben
Persönliche Mitgliedsdaten Adressen, Kontaktdaten, Bankverbindungen, weitere sensible Felder

Technische Umsetzung

  • Sensible Felder werden mit AES-256-GCM verschlüsselt.
  • Die Verschlüsselung nutzt Plug.Crypto mit zeitstempelbasierten Mechanismen.

Schlüsselmanagement

Individuelle Schlüssel pro Anwendungsinstanz

  • Jede HERA-Instanz verwendet einen eigenen Anwendungsschlüssel (Salt, ENCRYPTION_SALT).
  • TOTP-Geheimnisse und andere anwendungsweite Daten werden damit verschlüsselt.

Individuelle Schlüssel pro Dienststelle

  • Jeder Dienststelle hat einen eigenen Verschlüsselungsschlüssel (organization_encryption_keys).
  • Persönliche und Gesundheitsdaten von Mitgliedern werden mit diesem organisationsspezifischen Schlüssel verschlüsselt.
  • Ein Schlüsselverlust bei einer Dienststelle betrifft nicht die Daten anderer Dienststellen.
  • Im Fall eins Schlüsselverlusts, können die Daten durch einen neuen Import aus THWin neu erfasst werden.

Hosting und Standort

  • Der Serverstandort befindet sich in Deutschland.
  • Der Sitz aller an der Bereitstellung beteiligten Dienstleister ist Deutschland.
  • Die Anwendung ist in einem Docker-Container isoliert.
  • Es werden keine externen Dienste für den Betrieb der Anwendung verwendet.

Die detaillierte Darstellung der Produktivumgebung, Kommunikationswege und Speicherorte befindet sich unter Architektur und Betrieb.