⚖ TOMs – flowgeist KITA

TOMs – flowgeist KITA

v1.2 · 08.08.2026

TOMs – flowgeist KITA

Version 1.2 · Stand: 08.08.2026
flowgeist ZERO flowgeist KITA flowgeist TOOL CombiJornada DIRIGENT

Technische und organisatorische Maßnahmen (TOMs) – flowgeist KITA

Stand: 22.09.2026 Version: 1.4 Geltungsbereich: Art. 32 DSGVO, Art. 28 Abs. 3 lit. c DSGVO

1. Zutrittskontrolle

Die physische Zugangskontrolle zu den Servern und IT-Systemen, auf denen personenbezogene Daten verarbeitet werden, wird durch den Hosting-Anbieter Hetzner Online GmbH sichergestellt.

Maßnahmen:

  • Rechenzentrum Falkenstein: Die Server werden im Rechenzentrum Falkenstein (Deutschland) von Hetzner Online GmbH betrieben.
  • 24/7 Sicherheitspersonal: Das Rechenzentrum ist rund um die Uhr mit Sicherheitspersonal besetzt.
  • Zugangskontrolle: Der Zugang zum Rechenzentrum ist durch mehrstufige Zugangskontrollen (Chipkarte, PIN, biometrische Verfahren) gesichert.
  • Besucher-Protokollierung: Alle Zugänge und Besuche werden protokolliert und sind nachvollziehbar.
  • Videoüberwachung: Die Außen- und Innenbereiche des Rechenzentrums sind videoüberwacht.
  • Zutrittsprotokollierung: Sämtliche Zutritte zu sensiblen Bereichen werden lückenlos protokolliert und archiviert.

2. Zugriffskontrolle

Die Zugriffskontrolle stellt sicher, dass nur autorisierte Personen Zugang zu personenbezogenen Daten erhalten und dass Berechtigungen nach dem Prinzip der minimalen Rechtevergabe (Least Privilege) erteilt werden.

Maßnahmen:

  • MFA/TOTP: Die mehrstufige Authentifizierung (Multi-Factor Authentication) mittels Time-based One-Time Password (TOTP) ist für Support- und Administrations-Konten verpflichtend. Für alle weiteren Nutzerkonten kann sie je Mandant (Kita-Träger) aktiviert oder systemweit erzwungen werden; sobald sie für ein Konto aktiviert ist, ist der zweite Faktor bei der Anmeldung zwingend erforderlich.
  • RBAC (Role-Based Access Control): Die Zugriffskontrolle erfolgt rollenbasiert. Jeder Nutzerrolle werden definierte Rechte zugeordnet, die nur die für die Aufgabenerfüllung notwendigen Berechtigungen umfassen.
  • Least Privilege: Berechtigungen werden nach dem Prinzip der minimalen Rechtevergabe erteilt. Nutzer erhalten nur die Zugriffsrechte, die für die Ausübung ihrer Tätigkeit zwingend erforderlich sind.
  • JWT (JSON Web Token): Zugriffstokens haben eine Gültigkeit von 15 Minuten. Nach Ablauf wird ein neues Token durch Refresh-Token-Rotation ausgestellt.
  • Refresh-Token-Rotation: Bei jeder Token-Erneuerung wird ein neuer Refresh-Token ausgestellt, der vorherige wird ungültig. Dies minimiert das Risiko eines Token-Missbrauchs.
  • Argon2id: Passwörter werden mit dem Argon2id-Algorithmus gehasht. Die Parameter sind: m=64MiB (Speicher), t=3 (Iterationen), p=4 (Parallelität). Dies bietet einen hohen Schutz gegen Brute-Force- und Rainbow-Table-Angriffe.
  • Rate-Limiting bei Fehlversuchen: Wiederholte fehlgeschlagene Anmeldeversuche werden durch ein Redis-basiertes Rate-Limiting gedrosselt (Anmeldung, Token-Erneuerung, CSRF- und Support-Endpunkte). Dadurch werden automatisierte Brute-Force-Angriffe wirksam erschwert.

3. Übertragungskontrolle

Die Übertragungskontrolle stellt sicher, dass personenbezogene Daten bei der Übertragung vor unbefugtem Zugriff, Manipulation und Verlust geschützt sind.

Maßnahmen:

  • TLS 1.2/1.3: Sämtliche Datenübertragungen zwischen Client und Server erfolgen verschlüsselt über TLS 1.2/1.3 (Transport Layer Security). Ältere Protokollversionen (TLS 1.1 und niedriger) werden nicht unterstützt.
  • HSTS (HTTP Strict Transport Security): Der Server sendet HSTS-Header, um sicherzustellen, dass Browser ausschließlich über HTTPS-Verbindungen kommunizieren.
  • Let’s Encrypt mit Auto-Rotation: SSL/TLS-Zertifikate werden durch Let’s Encrypt ausgestellt und automatisch rotiert, um eine durchgehende Verschlüsselung sicherzustellen.
  • Zertifikats-Pinning: Wo anwendbar, wird Certificate Pinning eingesetzt, um Man-in-the-Middle-Angriffe zu verhindern.

4. Eingabekontrolle

Die Eingabekontrolle stellt sicher, dass alle Eingaben und Änderungen an personenbezogenen Daten nachvollziehbar protokolliert werden, um im Falle einer Datenschutzverletzung die Ursache aufklären zu können.

Maßnahmen:

  • Audit-Trail (ISO 27001 A.12.4): Sämtliche sicherheitsrelevanten Zugriffe und Änderungen werden lückenlos protokolliert gemäß der Norm ISO 27001, Kontrollmaßnahme A.12.4 (Ereignisprotokollierung).
  • Manipulationsgeschützte Audit-Logs: Die Audit-Logs werden als verkettete Hash-Chain (SHA-256, jeweils prevHash/hash pro Eintrag) gespeichert. Nachträgliche Veränderungen einzelner Einträge sind dadurch erkennbar (tamper-evident). Eine zusätzliche WORM-Ablage auf Speicherebene ist vorgesehen (geplant).
  • Log-Inhalt: Jeder Log-Eintrag enthält mindestens folgende Informationen:
    • Timestamp (Zeitstempel der Aktion)
    • User-ID (Identifikation des Nutzers)
    • Tenant-ID (Identifikation des Mandanten/Kita-Trägers)
    • Aktion (durchgeführte Operation, z.B. CREATE, READ, UPDATE, DELETE)
    • Ressource (betroffenes Datenobjekt)
    • IP-Adresse (des anfragenden Clients)
    • User-Agent (Browser-/Client-Identifikation)
  • Log-Aufbewahrung: Audit-Logs werden 10 Jahre aufbewahrt und anschließend gelöscht. Die endgültige Löschung (Purge) erfolgt automatisiert nach Ablauf der Aufbewahrungsfrist; eine vorzeitige Löschung ist nur im Vier-Augen-Verfahren mit dokumentierter Genehmigung möglich.

5. Auftragskontrolle

Die Auftragskontrolle stellt sicher, dass personenbezogene Daten nur im Rahmen der erteilten Weisungen und dieses Auftragsverarbeitungsvertrages verarbeitet werden.

Maßnahmen:

  • Verarbeitung nur im Rahmen des AVV: Die Verarbeitung personenbezogener Daten erfolgt ausschließlich auf Weisung des Verantwortlichen und im Rahmen des abgeschlossenen Auftragsverarbeitungsvertrages.
  • Keine Weitergabe ohne Genehmigung: Eine Weitergabe von Daten an Dritte erfolgt nicht ohne vorherige Genehmigung des Verantwortlichen.
  • Weisungsdokumentation: Alle Weisungen des Verantwortlichen werden dokumentiert und nachvollziehbar archiviert.
  • Vertragsbindung des Personals: Alle mit der Verarbeitung betrauten Personen sind vertraglich zur Vertraulichkeit verpflichtet.

6. Verfügbarkeitskontrolle

Die Verfügbarkeitskontrolle stellt sicher, dass personenbezogene Daten vor versehentlicher Zerstörung oder Verlust geschützt sind und die Plattform jederzeit verfügbar ist.

Maßnahmen:

  • Tägliche Backups: Vollständige PostgreSQL-Dumps werden täglich automatisiert erstellt (Cronjob, 02:30 UTC), mit GPG (RSA-4096) verschlüsselt und per verschlüsselter Übertragung auf eine separate Hetzner Storage Box (Offsite) hochgeladen. Zusätzlich werden infrastrukturseitige Snapshots über Hetzner Cloud Backup erstellt.
  • Backup-Verschlüsselung: Offsite-Backups werden mit GPG (RSA-4096) verschlüsselt gespeichert; die Server-Volumes sind zudem mit AES-256 (LUKS) verschlüsselt.
  • 30 Tage Aufbewahrung: Backups werden 30 Tage aufbewahrt (lokal und im Offsite-Storage).
  • RTO 8h (Recovery Time Objective): Die Wiederherstellungszeit nach einem Ausfall beträgt maximal 8 Stunden.
  • RPO 24h (Recovery Point Objective): Der maximale Datenverlust im Falle eines Ausfalls beträgt maximal 24 Stunden (entspricht dem letzten erfolgreichen Backup).
  • Redis als Cache: Redis wird mit Passwort-Schutz und Persistenz (AOF) eingesetzt. Redis speichert Session-Daten und Cache-Daten. Redis-Daten enthalten keine Gesundheitsdaten (Art. 9 DSGVO). Bei einem Redis-Ausfall gehen lediglich Cache- und Session-Daten verloren, die aus der PostgreSQL-Datenbank neu aufgebaut werden können.

7. Trennungskontrolle

Die Trennungskontrolle stellt sicher, dass personenbezogene Daten unterschiedlicher Mandanten (Kita-Träger) strikt getrennt verarbeitet werden.

Maßnahmen:

  • Multi-Tenant mit Tenant-Isolation auf DB-Ebene: Die Daten verschiedener Mandanten (Kita-Träger) werden auf Datenbankebene strikt getrennt. Jeder Mandant hat einen isolierten Datenbereich, auf den andere Mandanten keinen Zugriff haben.
  • JWT-Claims tenant-scoped: Die JWT-Zugriffstokens enthalten tenant-spezifische Claims, die sicherstellen, dass ein Nutzer nur auf die Daten seines Mandanten zugreifen kann.
  • Keine Mandantendaten in Redis: Redis speichert ausschließlich Rate-Limit-Zähler und Feature-Flags — keine personenbezogenen Mandantendaten und keine Gesundheitsdaten. Eine mandantenbezogene Trennung in Redis ist daher nicht erforderlich; die Trennung erfolgt vollständig auf PostgreSQL-Ebene (Row-Level-Security).
  • Mandantenprüfung bei jeder Abfrage: Jede Datenbankabfrage wird auf Mandantenzugehörigkeit geprüft.

8. Verschlüsselung

Die Verschlüsselung stellt sicher, dass personenbezogene Daten sowohl bei der Übertragung als auch im Ruhezustand geschützt sind.

Maßnahmen:

  • AES-256 at rest: Alle auf den Server-Volumes gespeicherten Daten werden mit AES-256 (Advanced Encryption Standard, 256-Bit-Schlüssellänge, LUKS) verschlüsselt; Offsite-Backups werden zusätzlich mit GPG (RSA-4096) verschlüsselt.
  • TLS 1.2/1.3 in transit: Sämtliche Datenübertragungen erfolgen verschlüsselt über TLS 1.2/1.3 (Transport Layer Security).
  • Anwendungsverschlüsselung für Gesundheitsdaten: Gesundheitsdaten (Art. 9 DSGVO) werden zusätzlich zur Datenbankverschlüsselung auf Anwendungsebene verschlüsselt (siehe auch Abschnitt 12).

9. Pseudonymisierung

Die Pseudonymisierung stellt sicher, dass personenbezogene Daten in Audit-Logs und bei der langfristigen Speicherung so verarbeitet werden, dass sie ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können.

Maßnahmen:

  • Pseudonyme Kennungen in Audit-Logs: In Audit-Logs werden Nutzer ausschließlich über ihre interne User-ID (UUID) referenziert. E-Mail-Adressen und Namen werden in den Audit-Logs gar nicht erst gespeichert — eine Zuordnung zu natürlichen Personen ist nur über die separate Nutzerverwaltung möglich.
  • Namen entfernt/gehasht nach Aufbewahrungsfrist: Nach Ablauf der gesetzlichen Aufbewahrungsfristen werden Namen und andere identifizierende Merkmale entfernt oder durch Hash-Werte ersetzt, sofern eine weitere Speicherung zu statistischen oder Nachweiszwecken erforderlich ist.

10. Regelmäßige Überprüfung

Die regelmäßige Überprüfung stellt sicher, dass die technischen und organisatorischen Maßnahmen kontinuierlich an den aktuellen Stand der Technik und an neue Bedrohungslagen angepasst werden.

Maßnahmen:

  • Jährlicher TOM-Review: Die technischen und organisatorischen Maßnahmen werden jährlich überprüft und bei Bedarf angepasst.
  • Penetrationstests alle 24 Monate: Es werden regelmäßig Penetrationstests durchgeführt, um Schwachstellen in der Plattform zu identifizieren und zu beheben. Die Tests finden alle 24 Monate statt.
  • Vulnerability-Scans quartalsweise: Vierteljährlich werden automatisierte Vulnerability-Scans durchgeführt, um bekannte Schwachstellen in Abhängigkeiten und Systemkomponenten zu erkennen.
  • ISO 27001 angestrebt: Die Zertifizierung nach ISO 27001 wird angestrebt. Die Maßnahmen sind bereits an den Anforderungen der ISO 27001 ausgerichtet.

11. Unter-Auftragsverarbeiter

Als Unter-Auftragsverarbeiter im Sinne des Art. 28 Abs. 2 DSGVO werden eingesetzt:

Unter-AuftragsverarbeiterStandortZweckDrittstaatenbezugAVV
Hetzner Online GmbHDeutschland (Falkenstein)Hosting, Datenbank, Backup, E-Mail-Versand (Transaktions-E-Mails über Hetzner-Mailserver)Keine DrittstaatenJa (Art. 28 Abs. 4 DSGVO)
RustDesk (Open Source)Deutschland (selbst-gehostet)Fernwartung der Server-InfrastrukturKeine DrittstaatenJa (Art. 28 Abs. 4 DSGVO)

Hetzner Online GmbH: Hosting-Anbieter mit ISO 27001 zertifiziertem Rechenzentrum in Falkenstein, Deutschland. Keine Drittstaatenübermittlung. AVV gemäß Art. 28 Abs. 4 DSGVO abgeschlossen.

RustDesk: Selbst-gehostete RustDesk-Server-Instanz auf der Hetzner-Infrastruktur für die Fernwartung der Produktionsserver durch autorisierte Administratoren. RustDesk wird ausschließlich für administrative Zwecke eingesetzt und erhält keinen Zugriff auf produktive Datenbankinhalte. Die RustDesk-Server-Instanz ist integraler Bestandteil der Server-Infrastruktur.

E-Mail-Versand: Transaktions-E-Mails (Passwort-Reset, Einladungen, Benachrichtigungen) werden über den Hetzner-Mailserver versendet (SMTP, Deutschland). Es erfolgt keine Drittstaatenübermittlung.

Eine Datenübermittlung in Drittstaaten findet nicht statt.

12. Besonderheiten bei Kinder- und Gesundheitsdaten

Aufgrund der Verarbeitung besonderer Kategorien personenbezogener Daten gemäß Art. 9 DSGVO (Gesundheitsdaten) und der Verarbeitung von Daten minderjähriger Personen (Kinder) werden zusätzliche Maßnahmen ergriffen, die über die Standard-TOMs hinausgehen.

Maßnahmen:

  • Verschärfte Zugriffskontrolle für Gesundheitsdaten: Der Zugriff auf Gesundheitsdaten erfolgt über ein separates RBAC-Modul (Role-Based Access Control). Nur Nutzer mit der spezifischen Berechtigung „Gesundheitsdaten-Zugriff” können auf diese Daten zugreifen. Die Standard-Berechtigungen für Kita-Verwaltung reichen nicht aus. Hinweis: Die spezifische RBAC-Rolle „Gesundheitsdaten-Zugriff” ist in der aktuellen Implementierung über allgemeine Rollen (Administrator, Pädagogische Leitung) abgebildet. Eine dedizierte Rolle mit Zweck- und Rechtfertigungs-Protokollierung ist für die nächste Phase geplant.
  • Zusätzliche Audit-Log-Ebene für Zugriff auf Art. 9-Daten: Jeder Zugriff auf Gesundheitsdaten wird auf einer zusätzlichen Audit-Log-Ebene protokolliert. Diese Protokollierung umfasst zusätzlich zu den Standard-Log-Informationen:
    • Zweck des Zugriffs (Behandlung, Notfall, Dokumentation)
    • Art der Aktion (Lesezugriff, Änderung, Export)
    • Rechtfertigung (Einwilligung liegt vor, Notfallsituation) Hinweis: Die erweiterte Audit-Log-Ebene mit Zweck und Rechtfertigung ist für die nächste Phase geplant. Aktuell werden Art. 9-Zugriffe in den allgemeinen Audit-Logs protokolliert.
  • Verschlüsselung der Gesundheitsdaten-Felder auf Anwendungsebene: Gesundheitsdaten werden zusätzlich zur Datenbankverschlüsselung (AES-256 at rest) auf Anwendungsebene verschlüsselt. Dies bedeutet, dass die Felder, die Gesundheitsdaten enthalten, vor dem Schreiben in die Datenbank mit einem separaten Schlüssel verschlüsselt werden. Bei einem unbefugten direkten Zugriff auf die Datenbank wären die Gesundheitsdaten auch bei Kenntnis des Datenbank-Verschlüsselungsschlüssels nicht lesbar. Hinweis: Die Feld-Level-Verschlüsselung für Gesundheitsdaten ist für die nächste Phase geplant. Aktuell erfolgt der Schutz über Datenbank-Verschlüsselung (LUKS at-rest) und RBAC.

13. Änderungshistorie

VersionDatumWesentliche Änderungen
1.008.08.2026Erstfassung
1.129.08.2026Korrektur der Sub-Prozessor-Liste (Aufnahme RustDesk, Postmark/ActiveCampaign); Redis-Persistenz korrigiert (AOF aktiviert); Art. 9-Maßnahmen mit Implementierungs-Status dokumentiert
1.222.09.2026Code-/Server-Abgleich: Postmark als Unter-Auftragsverarbeiter entfernt — E-Mail-Versand erfolgt über den Hetzner-Mailserver (SMTP, Deutschland); keine Drittstaatenübermittlung; WORM-Claim auf tamper-evidente Hash-Chain präzisiert
1.322.09.2026Code-Abgleich (Rest): MFA-Pflicht auf Support-/Administrations-Konten + per-Mandant aktivierbar präzisiert; „Konto-Sperrung” durch Redis-basiertes Rate-Limiting ersetzt (kein Lockout implementiert); Audit-Log-Aufbewahrung von 3 auf 10 Jahre korrigiert (Code-Default); Redis-Namespace-Isolation entfernt (keine Mandantendaten in Redis); E-Mail-Hash-Claim ersetzt durch pseudonyme UUID-Referenzierung in Audit-Logs
1.422.09.2026Server-Verifikation: Backup-Pipeline konkretisiert (täglich 02:30 UTC, pg_dump + GPG RSA-4096, Offsite Hetzner Storage Box, 30 Tage Retention); Redis-AOF bestätigt (appendonly yes, appendfsync everysec); MFA_REQUIRED nicht gesetzt (MFA konditional)
1.322.09.2026Code-Abgleich (Rest): MFA-Pflicht auf Support-/Administrations-Konten + per-Mandant aktivierbar präzisiert; „Konto-Sperrung” durch Redis-basiertes Rate-Limiting ersetzt (kein Lockout implementiert); Audit-Log-Aufbewahrung von 3 auf 10 Jahre korrigiert (Code-Default); Redis-Namespace-Isolation entfernt (keine Mandantendaten in Redis); E-Mail-Hash-Claim ersetzt durch pseudonyme UUID-Referenzierung in Audit-Logs

© 2026 flowgeist – Ralf Carsjens · Alle Rechte vorbehalten