Datenschutz & Sicherheit bei Nahbar

1. Verschlüsselung von Gesundheitsdaten

Krankheits-Freitexte werden vor dem Speichern auf Anwendungsebene verschlüsselt – mit AES im GCM-Modus (AES-128/192/256, abhängig von der Schlüssellänge) und einem zufälligen Initialisierungsvektor je Eintrag. Der Schlüssel stammt aus einer separat verwalteten Umgebungsvariablen und liegt nicht im Code. Verschlüsselte Werte tragen einen Versionspräfix, sodass das Verfahren später erweitert werden kann.

Verschlüsselt wird gezielt das Bemerkungsfeld von Abwesenheiten des Typs „Krankheit“; allgemeine Stammdaten sind davon nicht betroffen.

2. Sichere Passwortspeicherung

Anmeldepasswörter werden niemals im Klartext gespeichert, sondern als BCrypt-Hash mit Salt. Bei der Anmeldung wird ausschließlich der Hash verglichen.

3. Rollen- und Rechtekonzept (Need-to-know)

Der Zugriff ist rollenbasiert geregelt. Es gibt drei Rollen – Administration, Planung (Filialleitung) und Mitarbeitende. Schreibende und administrative Endpunkte sind den passenden Rollen vorbehalten; Planende sehen grundsätzlich nur Daten ihrer eigenen Filiale.

Gesundheitsdaten unterliegen einer zusätzlichen, eigenen Zugriffsprüfung: Krankheits-Details sind nur für die betroffene Person selbst oder für ausdrücklich dafür freigegebene Rollen sichtbar – die allgemeinen Admin- oder Planungsrechte genügen dafür nicht. Für nicht berechtigte Aufrufe wird das Bemerkungsfeld serverseitig entfernt.

4. Verschlüsselte Übertragung

Im Produktivbetrieb wird der Datenverkehr über einen vorgelagerten Reverse-Proxy ausschließlich per HTTPS (TLS 1.2 / 1.3) ausgeliefert, inklusive HSTS sowie gängiger Sicherheits-Header (u. a. gegen Clickjacking und MIME-Sniffing). Das Sitzungs-Token wird als HttpOnly-, Secure- und SameSite=Strict-Cookie gesetzt, ist also für JavaScript nicht auslesbar und wird nur über HTTPS übertragen.

5. Schutz vor unbefugten Anmeldeversuchen

Wiederholte Fehlanmeldungen führen nach einer konfigurierbaren Anzahl (Standard: 5 Versuche) zu einer temporären Sperre (Standard: 15 Minuten). Zusätzlich begrenzt ein Rate-Limit die Zahl der Anfragen pro Zeitfenster für Anmeldung und API.

6. Nachvollziehbarkeit (Audit-Log)

Sicherheits- und datenrelevante Änderungen werden in einem Audit-Log protokolliert. Die Einträge sind über das System nicht änderbar und durch eine fortlaufende Hash-Kette (SHA-256) miteinander verkettet, so dass nachträgliche Manipulationen erkennbar werden.

7. Datensparsamkeit und Löschung

Personenbezogene Daten werden nicht unbegrenzt aufbewahrt. Geplante Aufräum-Jobs löschen bzw. anonymisieren Daten nach konfigurierbaren Fristen – standardmäßig:

• Krankheits-Details nach 12 Monaten,
• Audit-Einträge nach 2 Jahren,
• deaktivierte Mitarbeitende nach 12 Monaten durch Anonymisierung der Stamm- und abhängigen Freitextdaten (Unterstützung des Lösch-/Anonymisierungsanspruchs).

8. Datensicherung (Backups)

Für den Produktivbetrieb existiert ein Backup-Mechanismus, der die Datenbank im komprimierten Format sichert, je Sicherung eine SHA-256-Prüfsumme und ein Manifest erzeugt und ältere Sicherungen nach einer konfigurierbaren Aufbewahrungsfrist (Standard: 14 Tage) entfernt. Die Sicherungsdateien werden mit eingeschränkten Dateirechten abgelegt.

9. Abgesicherte Produktivkonfiguration

Beim Start im Produktivprofil prüft die Anwendung, dass sicherheitskritische Werte gesetzt sind (u. a. Datenbankzugang, JWT-Geheimnis, Schlüssel für Gesundheitsdaten, CORS-Allowlist). Der mitgelieferte Demo-Schlüssel wird im Produktivbetrieb abgelehnt, und für CORS sind nur konkrete Ursprünge erlaubt – kein Platzhalter „*“. Ohne gültige Konfiguration startet die Anwendung nicht.

10. Trennung von Demo und Produktiv

Die Demo-Umgebung arbeitet ausschließlich mit Beispieldaten. Das Einspielen von Demo-Daten ist technisch auf Nicht-Produktiv-Profile und lokale Datenbanken beschränkt. Im Demo-Modus erzwingt der Server zudem einen Nur-Lese-Betrieb: Anmeldung und Navigation funktionieren vollständig, ändernde Aktionen werden serverseitig abgelehnt, damit die Beispieldaten unverändert bleiben.

11. Keine Tracker

Im Frontend werden keine Analyse- oder Marketing-Tracker eingesetzt.