Technisch-organisatorische Maßnahmen

Verschlüsselung (Art. 32 Abs. 1 a)

• Transportverschlüsselung (TLS/HTTPS) für alle Verbindungen.
• Passwörter werden nur als Hash gespeichert (Authentifizierungsdienst).
• Optionale Zwei-Faktor-Authentifizierung (TOTP) für alle Rollen.

Zu ergänzen: Verschlüsselung im Ruhezustand hängt beim selbst betriebenen Server vom Hoster ab (Festplattenverschlüsselung) – bitte bestätigen. Ebenso Festplattenverschlüsselung der Endgeräte.

Vertraulichkeit & Zugriffskontrolle

• Rollenbasierte Zugriffssteuerung (Eltern, Fachkraft, Leitung, Träger).
• Zeilen-Sicherheit (Row Level Security) auf Datenbankebene: strikte Mandantentrennung je Träger/Kita.
• Zusätzliche Rollenprüfung in jedem schreibenden Vorgang, unabhängig von der Zeilen-Sicherheit (zwei Schichten statt einer).
• Datensparsame Sichtbarkeit sensibler Felder (z. B. Abwesenheits-Notizen nur für Leitung/Betroffene).
• Hochgeladene Dateien und Profilfotos sind nur über zeitlich begrenzte, personengebundene Links abrufbar – nicht über eine öffentliche Adresse.

Zu ergänzen: Organisatorisch: Zutrittskontrolle zu Räumen, Bildschirmsperren, Rechte-Vergabe-Prozess.

Sicherheit der Anmeldung

• Zwei-Faktor-Authentifizierung ist für Leitung und Träger-Administration verpflichtend; für alle übrigen Rollen möglich.
• Begrenzung fehlgeschlagener Anmeldeversuche je Konto und je Herkunft, um das Erraten von Passwörtern zu verhindern.
• Eine Passwortänderung setzt die Eingabe des bisherigen Passworts voraus – eine offen stehende Sitzung genügt nicht.
• Fehlermeldungen geben keine Auskunft darüber, ob es zu einer Adresse ein Konto gibt.

Zu ergänzen: Organisatorisch: Regeln zur Passwortlänge, Umgang mit gemeinsam genutzten Tablets, Verfahren bei Verlust des zweiten Faktors.

Integrität & Eingabekontrolle

• Serverseitige Validierung aller Eingaben; Prüfungen (Constraints) auf Datenbankebene.
• Aktivitätsprotokoll (Audit-Log) sicherheitsrelevanter Änderungen.
• Einwilligungs-Historie (Nachweis von Erteilung/Widerruf, Art. 7).

Verfügbarkeit & Wiederherstellbarkeit (Art. 32 Abs. 1 c)

• Betrieb auf einem angemieteten Server in Deutschland; Anwendung und Datenbank laufen dort gemeinsam.
• Wiederherstellbarkeit über Datenbank-Sicherungen des Trägers.
• Überwachung der Sicherungen: bleibt eine nächtliche Sicherung aus, wird die technische Betreuung benachrichtigt.

Zu ergänzen: Bei selbst betriebenem Server gibt es keine automatischen Sicherungen eines Datenbankanbieters und keine automatische Redundanz. Sicherungsturnus, Aufbewahrung, Wiederherstellungstests und Notfallplan muss der Träger festlegen und dokumentieren. Für eine verschlüsselte Zweitkopie außerhalb des Servers (auf einem Rechner der Einrichtung) steht eine Abhol-Automatisierung bereit (siehe docs/DEPLOY.md §6a) – sie muss vom Träger eingerichtet werden, bevor sie als Schutzmaßnahme gilt.

Datensparsamkeit & Löschung (Art. 5 / Art. 17)

• Automatisches Löschkonzept: abgelaufene Bewegungsdaten werden regelmäßig gelöscht (mit Löschprotokoll).
• Selbst-Datenexport (Art. 15/20) und Konto-Löschung auf Antrag (Art. 17).

Belastbarkeit & regelmäßige Überprüfung (Art. 32 Abs. 1 d)

• Automatisierte Tests (Typprüfung, Unit- und RLS-/Mandantentrennungs-Tests) in der Entwicklungspipeline.
• Sicherheitsüberprüfungen der Zugriffsregeln (RLS) inkl. Cross-Tenant-Regressionstests.
• Automatische Prüfung der eingesetzten Fremdbibliotheken auf gemeldete Sicherheitslücken bei jeder Änderung.
• Anlaufstelle für Meldungen zu Sicherheitslücken (security.txt nach RFC 9116), sobald die Kontaktadresse des Trägers hinterlegt ist.
• Automatische Überwachung von Systemzustand, Diensten und Sicherungen mit Alarmierung an die technische Betreuung (Speicherplatz, Container, Sicherheitsupdates, Alter der letzten Datensicherung).

Zu ergänzen: Turnus interner Überprüfungen und Verantwortlichkeiten festlegen. Die Überwachung erkennt keine Sicherheitslücken, deren Behebung ein kostenpflichtiges Erweiterungsprogramm des Betriebssystem-Herstellers voraussetzt (Ubuntu ESM); ob dieses aktiviert wird, entscheidet der Träger.