⚖ TOMs – DIRIGENT

TOMs – DIRIGENT

v1.2 · 08.08.2026

TOMs – DIRIGENT

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

Technische und organisatorische Maßnahmen (TOMs) – DIRIGENT

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

1. Zutrittskontrolle

Maßnahmen, durch die unbefugte Personen am Zutritt zu datenverarbeitenden Räumlichkeiten gehindert werden:

  • Rechenzentrum: Die Server werden bei Hetzner Online GmbH in Falkenstein (Deutschland) betrieben. Das Rechenzentrum verfügt über eine mehrstufige physische Zugangskontrolle.
  • Zugangskontrolle am Rechenzentrum: Videoüberwachung rund um die Uhr, Personenschleuse mit Ausweis- und Biometriekontrolle, Zutrittsprotokollierung.
  • Server-Schrank: Physische Verriegelung der Server-Racks. Zugang nur für autorisiertes Hetzner-Personal.
  • Büroräume: Die Büroräume von flowgeist sind mit einem mechanischen Schließsystem ausgestattet. Zugang nur für autorisierte Personen.
  • Schlüsselverwaltung: Strikte Schlüsselverwaltung mit Dokumentation der Schlüsselausgabe und -rückgabe.
  • Besucherkontrolle: Besucher werden registriert und während des gesamten Aufenthalts begleitet.

2. Zugriffskontrolle

Maßnahmen, durch die verhindert wird, dass unbefugte Personen Datenverarbeitungssysteme nutzen und sich Zugang zu personenbezogenen Daten verschaffen:

  • Authentifizierung: Zugriff auf Systeme und Anwendungen erfordert eine starke Authentifizierung mittels Benutzername und Passwort. Passwörter werden mit Argon2id gehasht gespeichert (Memory 64 MiB, Iterationen 3, Parallelismus 4). Ältere bcrypt-Hashes werden beim nächsten erfolgreichen Login transparent auf Argon2id migriert.
  • Passwort-Richtlinien: Durchsetzung von Passwort-Richtlinien (Mindestlänge, Komplexität, Regelmäßiger Wechsel).
  • Mehrstufige Authentifizierung (MFA): Verfügbar für alle Nutzerkonten via TOTP (Time-based One-Time Password). Sobald MFA für ein Konto aktiviert ist, ist der zweite Faktor bei der Anmeldung zwingend erforderlich. Eine rollenbasierte MFA-Pflicht (z. B. für Administratoren) ist derzeit nicht technisch erzwungen und geplant.
  • Single Sign-On (SSO): Unterstützung von SSO zur zentralen Authentifizierung in B2B-Umgebungen.
  • Rollenbasierte Zugriffskontrolle (RBAC): Strikte rollenbasierte Zugriffskontrolle nach dem Least-Privilege-Prinzip. Benutzer erhalten nur die für ihre Rolle erforderlichen Rechte.
  • PKCE-Session mit HttpOnly-Cookies: PKCE (Proof Key for Code Exchange) mit server-seitiger Session-Verwaltung. Access- und Refresh-Tokens werden in HttpOnly-, Secure- (in Produktion), SameSite=strict-Cookies gespeichert. Refresh-Tokens werden server-seitig in Redis als SHA-256-Hash gespeichert.
  • Refresh-Token-Rotation: Bei jeder Token-Erneuerung wird ein neues Refresh-Token ausgestellt, um Token-Missbrauch zu verhindern.
  • Multi-Tenant-Isolation: Jeder Kunde (Tenant) erhält einen isolierten Datenbereich. Eine Datenfreigabe zwischen Tenants ist technisch durch PostgreSQL Row-Level-Security (RLS) eingeschränkt. FORCE ROW LEVEL SECURITY ist für die Tabellen bis Migration 68 aktiviert; für neuere Tabellen (ab Migration 69) ist RLS aktiviert, FORCE RLS steht aus und ist geplant.
  • Zugriffsprotokollierung: Alle Zugriffe auf Systeme und personenbezogene Daten werden protokolliert (Audit-Trail ausgerichtet an ISO 27001 A.12.4).
  • Session-Management: Automatisches Session-Timeout bei Inaktivität.
  • ThrottlerGuard: Globales Rate-Limiting zum Schutz vor Brute-Force-Angriffen und Missbrauch; wiederholte Anmeldeversuche werden gedrosselt. Eine automatische Konto-Sperrung (Lockout) ist derzeit nicht implementiert.

3. Übertragungskontrolle

Maßnahmen, durch die sichergestellt wird, dass personenbezogene Daten bei elektronischer Übertragung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können:

  • Transportverschlüsselung: Datenübertragungen erfolgen verschlüsselt mittels TLS 1.3 (Transport Layer Security). TLS 1.3 wird serverseitig als Mindestversion erzwungen; TLS 1.2 ist deaktiviert.
  • HTTPS: Die gesamte Web-Kommunikation erfolgt ausschließlich über HTTPS (HSTS aktiviert).
  • API-Verschlüsselung: Alle API-Endpunkte erfordern verschlüsselte Verbindungen (HTTPS/TLS 1.3).
  • CORS-Origin-Whitelist: In Production strikte CORS-Origin-Whitelist, kein Localhost-Fallback.
  • Swagger/OpenAPI deaktiviert: Swagger/OpenAPI-Dokumentation ist in Production deaktiviert (ISO 27001 A.13.1.1).
  • Zertifikatsverwaltung: Einsatz gültiger TLS-Zertifikate mit automatischer Erneuerung. Überwachung der Zertifikatsgültigkeit.
  • Datenbankverbindungen: Verbindungen zur PostgreSQL 18-Datenbank erfolgen in der Produktionsumgebung TLS-verschlüsselt (sslmode=verify-full).
  • Redis-Verbindungen: Redis-Verbindungen erfolgen derzeit unverschlüsselt (plain TCP). TLS für Redis ist geplant.
  • Backup-Übertragung: Backup-Übertragung ist verschlüsselt, sofern Backups übertragen werden.
  • WAF (Web Application Firewall): Alle API-Zugriffe werden über eine vorgeschaltete Web Application Firewall (ModSecurity v3 mit OWASP Core Rule Set v4) gefiltert, bevor sie das Backend erreichen.

4. Eingabekontrolle

Maßnahmen, durch die nachträglich überprüft und festgestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind:

  • Audit-Trail (ausgerichtet an ISO 27001 A.12.4): Protokollierung aller sicherheitsrelevanten Aktionen ausgerichtet an ISO 27001, einschließlich:
    • Zeitstempel
    • User-ID
    • Tenant-ID
    • Aktion (Erstellen, Lesen, Ändern, Löschen)
    • Ressource
    • IP-Adresse
    • User-Agent
    • Trace-IDs (OpenTelemetry W3C Trace Context)
  • Protokollierung von administrativen Aktionen: Alle administrativen Aktionen (Benutzerverwaltung, Rollenänderungen, Tenant-Konfiguration) werden protokolliert.
  • Override-Audit: manuelle Overrides in der Workflow Engine (Übergabe-Checklisten, Qualitätsgates) werden vollständig protokolliert.
  • Integritätsschutz der Protokolle: Audit-Logs werden als partitionierte, kryptographisch verkettete Hash-Chain gespeichert (SHA-256, sequence/prevHash/hash pro Eintrag). Nachträgliche Veränderungen einzelner Einträge sind dadurch erkennbar (tamper-evident). Die Löschung erfolgt über Partition-Detach nach Ablauf der Aufbewahrungsfrist.
  • Aufbewahrung der Protokolle: Audit-Logs werden partitioniert gespeichert und für 7 Jahre aufbewahrt (konfigurierbar).
  • Versionierung: Datenänderungen werden mit Versionsständen dokumentiert, sofern anwendbar.

5. Auftragskontrolle

Maßnahmen, durch die sichergestellt wird, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Verantwortlichen verarbeitet werden:

  • Vertragliche Bindung: Abschluss von Auftragsverarbeitungsverträgen (AVV) gemäß Art. 28 DSGVO mit allen Unterauftragsverarbeitern.
  • Weisungsbindung: Verarbeitung personenbezogener Daten ausschließlich nach dokumentierter Weisung des Verantwortlichen.
  • Unterauftragsverarbeiter-Kontrolle: Sorgfältige Auswahl und regelmäßige Überprüfung der Unterauftragsverarbeiter (Hetzner Online GmbH).
  • Vertragliche Verpflichtungen: Alle Mitarbeiter und Unterauftragsverarbeiter sind vertraglich zur Vertraulichkeit verpflichtet.
  • Dokumentation: Vollständige Dokumentation der Verarbeitungsvorgänge und Weisungen.
  • Keine externen Dienste (aktiv): Die Plattform nutzt aktuell keine aktiven externen KI-Dienste, Web-Analytics oder Payment-Dienste. Es existieren Adapter für Auth0/Keycloak, SuperOffice, Work4All, Jira, MS365/Graph (Booking/Calendar), AGE, Confluence, FAUST, Handelsregister, MS Dynamics 365, SAP S/4HANA. HTTP-Aufrufe an externe Dienste sind über *_USE_HTTP-Flags standardmäßig deaktiviert. Mock-Connectoren existieren für SharePoint und Leadinfo (beide Backlog). Geplante Integrationen: MS365 Booking und MS365 Graph Email-Notifications.

6. Verfügbarkeitskontrolle

Maßnahmen, durch die personenbezogene Daten vor zufälliger Zerstörung oder Verlust geschützt werden:

  • Backup-Strategie: Tägliche automatisierte Backups der PostgreSQL-Datenbank (pg_dump). Die Backups werden verschlüsselt (AES-256) auf ein separates Offsite-Storage-Backend repliziert (automatisiert via systemd-Timer). Zusätzlich werden infrastrukturseitige Snapshots über Hetzner bereitgestellt.
  • Backup-Aufbewahrung: Gestaffelte Aufbewahrungsfristen für die Offsite-Backups — tägliche Backups 7 Tage, wöchentliche 4 Wochen, monatliche 6 Monate.
  • Backup-Test: Regelmäßige Überprüfung der Backup-Wiederherstellung (Restore-Tests).
  • Redundanz: Einsatz redundanter Systemkomponenten zur Vermeidung von Single Points of Failure.
  • Monitoring: Kontinuierliches Monitoring der Systemverfügbarkeit und -leistung via OpenTelemetry, Loki, Tempo und Grafana (internes Observability). Automatische Alarmierung bei Störungen.
  • Hochverfügbarkeit: Die Infrastruktur bei Hetzner Online GmbH bietet redundante Stromversorgung, Kühlung und Netzwerkanbindungen.
  • Notfallplan: Dokumentierter Notfallplan (Disaster Recovery Plan) mit definierten Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO).
  • Fehlertoleranz: Automatischer Neustart bei Systemausfällen. Überwachung der Systemintegrität.
  • Outbox-Pattern: State-Change und Event werden in einer Transaktion geschrieben, um Datenkonsistenz und Verfügbarkeit sicherzustellen.

7. Trennungskontrolle

Maßnahmen, durch die sichergestellt wird, dass personenbezogene Daten, die zu unterschiedlichen Verarbeitungszwecken erhoben wurden, getrennt verarbeitet werden können:

  • Multi-Tenant-Isolation: Strikte logische Trennung der Daten zwischen verschiedenen Kunden (Tenants). Jeder Tenant erhält einen isolierten Datenbereich. Eine Datenfreigabe zwischen Tenants ist technisch ausgeschlossen.
  • PostgreSQL Row-Level-Security (RLS): Daten verschiedener Tenants werden in der PostgreSQL 18-Datenbank durch Row-Level-Security getrennt. In jeder Transaktion wird SET LOCAL app.tenant_id gesetzt. FORCE ROW LEVEL SECURITY ist für Tabellen bis Migration 68 aktiviert; für neuere Tabellen (ab Migration 69) ist RLS aktiviert, FORCE RLS steht aus und ist geplant.
  • Tenant-Context-Propagation: Der Tenant-Context wird via JWT-Claim propagiert und in jeder Transaktion konsistent angewendet.
  • Rollenbasierte Trennung: Funktionale Trennung durch RBAC. Daten für verschiedene Verarbeitungszwecke (z. B. Audit-Logs, Workflow-Daten, Notifications) werden getrennt gespeichert und verwaltet.
  • Umgebungstrennung: Strikte Trennung von Produktions-, Staging- und Entwicklungsumgebungen. Produktionsdaten werden nicht in Nicht-Produktionsumgebungen verwendet.
  • Log-Trennung: Audit-Logs werden getrennt von operativen Daten gespeichert, um eine manipulationssichere Aufbewahrung zu gewährleisten.
  • Modul-Isolation: NestJS modularer Monolith mit strikter Modul-Isolation. Kommunikation zwischen Modulen ausschließlich über interne API-Routes.

8. Verschlüsselung

Maßnahmen zur Gewährleistung der Vertraulichkeit und Integrität personenbezogener Daten durch Verschlüsselung:

  • Transportverschlüsselung: TLS 1.3 für Datenübertragungen (HTTPS, API). Datenbankverbindungen erfolgen in der Produktionsumgebung TLS-verschlüsselt (sslmode=verify-full); Redis-Verbindungen innerhalb des Docker-Netzwerks sind derzeit unverschlüsselt, TLS ist geplant.
  • Verschlüsselung at-rest: AES-256-Verschlüsselung für gespeicherte Daten (Datenbank, Dateisysteme). Offsite-Backups werden vor der Übertragung mit AES-256 verschlüsselt.
  • Passwort-Hashing: Passwörter werden mit Argon2id gespeichert (Memory 64 MiB, Iterationen 3, Parallelismus 4). Es werden keine Klartextpasswörter gespeichert. Ältere bcrypt-Hashes werden beim nächsten erfolgreichen Login transparent auf Argon2id migriert.
  • MFA-Secrets: TOTP-Secrets für die mehrstufige Authentifizierung werden verschlüsselt gespeichert.
  • Schlüsselverwaltung: Sichere Verwaltung der Verschlüsselungs-Schlüssel. Schlüssel werden getrennt von den verschlüsselten Daten gespeichert.

9. Pseudonymisierung

Maßnahmen zur Pseudonymisierung personenbezogener Daten:

  • Pseudonymisierung von Audit-Daten: IP-Adressen und sonstige identifizierende Felder in Audit-Logs werden nach Ablauf der Aufbewahrungsfrist vollständig gelöscht (Partition-Detach) — eine nachträgliche Pseudonymisierung einzelner Felder findet nicht statt.
  • Tenant-IDs: Die Zuordnung von Daten zu einem bestimmten Kunden erfolgt über pseudonyme Tenant-IDs, die keinen direkten Rückschluss auf die Identität des Kunden zulassen, ohne Zugriff auf die Zuordnungstabelle.
  • Trace-IDs: OpenTelemetry Trace-IDs ermöglichen eine pseudonyme Korrelation von Anfragen über Systemgrenzen hinweg, ohne personenbezogene Daten zu offenbaren.

10. Regelmäßige Überprüfung

Maßnahmen zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit der technischen und organisatorischen Maßnahmen:

  • Überprüfung der TOMs: Regelmäßige Überprüfung und Aktualisierung der technischen und organisatorischen Maßnahmen, mindestens jährlich.
  • ISO 27001: Die Plattform wurde mit dem Anspruch entwickelt, ISO 27001 zu erfüllen. Regelmäßige Überprüfung der Sicherheitskonfigurationen und Zugriffsrechte im Rahmen des ISMS.
  • Sicherheits-Audits: Regelmäßige Überprüfung der Sicherheitskonfigurationen und Zugriffsrechte.
  • Penetrationstests: Regelmäßige Durchführung von Penetrationstests und Sicherheitsüberprüfungen der Plattform.
  • Schwachstellen-Management: Kontinuierliche Überwachung und Behebung bekannter Schwachstellen (Vulnerability Management). Regelmäßige Updates und Patch-Management.
  • Incident-Response-Plan: Dokumentierter Prozess für die Reaktion auf Sicherheitsvorfälle. Definition von Verantwortlichkeiten und Eskalationswegen.
  • Mitarbeiter-Sensibilisierung: Regelmäßige Schulung und Sensibilisierung der Mitarbeiter in Bezug auf Datenschutz und Informationssicherheit.
  • Monitoring: Kontinuierliches Monitoring von Systemen und Netzwerken via OpenTelemetry/Loki/Tempo/Grafana zur Erkennung von Anomalien und potenziellen Sicherheitsvorfällen.
  • Protokoll-Auswertung: Regelmäßige Auswertung von Audit-Logs und Zugriffsprotokollen zur Erkennung von Missbrauch.

11. Unter-Auftragsverarbeiter

Die folgenden Unterauftragsverarbeiter werden im Rahmen der Verarbeitung personenbezogener Daten für DIRIGENT eingesetzt:

UnterauftragsverarbeiterStandortZweckDrittstaatenbezugAVVTOMs
Hetzner Online GmbHDeutschland (Falkenstein)Hosting, Datenbank (PostgreSQL 18), Redis, Backup, Observability (OpenTelemetry/Loki/Tempo/Grafana)Keine DrittstaatenJa (Art. 28 Abs. 4 DSGVO)Ja

Hetzner Online GmbH: Als Hosting-Anbieter verarbeitet Hetzner Online GmbH personenbezogene Daten in Deutschland (Falkenstein). Eine Übermittlung in Drittstaaten findet nicht statt. Das interne Observability-Stack (OpenTelemetry, Loki, Tempo, Grafana) läuft auf demselben Hetzner-Server, sodass keine Drittstaaten-Übermittlung erfolgt. Mit Hetzner ist ein Auftragsverarbeitungsvertrag gemäß Art. 28 Abs. 4 DSGVO abgeschlossen. Hetzner verfügt über eigene TOMs gemäß Art. 32 DSGVO, die das Schutzniveau für die Verarbeitung in Deutschland gewährleisten.

Keine weiteren aktiven externen Dienste: Die DIRIGENT-Plattform nutzt aktuell keine aktiven externen KI-Dienste, Web-Analytics, Payment-Dienste oder weiteren externen Dienste. Adapter für externe Systeme (Auth0/Keycloak, SuperOffice, Work4All, Jira, MS365/Graph, AGE, Confluence, FAUST, Handelsregister, MS Dynamics 365, SAP S/4HANA) existieren, HTTP-Aufrufe sind über *_USE_HTTP-Flags standardmäßig deaktiviert. Mock-Connectoren für SharePoint und Leadinfo (Backlog). Geplante Integrationen: MS365 Booking und MS365 Graph Email-Notifications. Diese erfolgen ausschließlich auf Basis gesonderter Auftragsverarbeitungsverträge. Die Liste der aktiven Unterauftragsverarbeiter ist vollständig.

12. Änderungshistorie

VersionDatumWesentliche Änderungen
1.014.08.2026Erstfassung der TOMs für DIRIGENT
1.129.08.2026Code-Abgleich: bcrypt statt Argon2id dokumentiert, PKCE-Session mit HttpOnly-Cookies korrigiert, FORCE RLS-Einschränkung dokumentiert, TLS 1.2/1.3 statt 1.3-only, DB-/Redis-TLS als geplant gekennzeichnet, WAF als nicht implementiert gekennzeichnet, WORM als konventionell gekennzeichnet, Backup-Automatisierung als geplant gekennzeichnet, externe Adapter und Mock-Connectoren dokumentiert
1.222.09.2026Code-Abgleich (Claims-Matrix): Argon2id als primärer Hash-Algorithmus verifiziert (bcrypt-Legacy-Migration beim Login); PostgreSQL 18 serverseitig verifiziert (pg18, 18.6); DB-Verbindungen TLS-verschlüsselt (sslmode=verify-full); Audit-Retention auf 7 Jahre korrigiert
1.322.09.2026Code-Abgleich (Rest): FORCE RLS bis Migration 68 aktualisiert; WORM/Hash-Chain als implementiert gehoben (partitionierte Audit-Tabelle, SHA-256 sequence/prevHash/hash); MFA-Pflicht präzisiert (verfügbar + enforced sobald aktiviert, Rollen-Pflicht geplant); Lockout-Claim durch ThrottlerGuard-Rate-Limiting ersetzt; IP-Pseudonymisierung durch Löschung via Partition-Detach ersetzt; Backup-Block auf verschlüsselte Offsite-Realität gehoben (systemd-Timer, Retention 7d/4w/6m); DB-TLS in §8 konsistent zu §3
1.422.09.2026Server-Verifikation: PostgreSQL 18 auf Produktivserver bestätigt (pg18, 18.6); kanonische Domain auf dirigent.flowgeist.de korrigiert (digitallydriven.flowgeist.de retired); WAF als implementiert gehoben (ModSecurity v3 + OWASP CRS v4); TLS 1.3-only serverseitig erzwungen

© 2026 flowgeist – Ralf Carsjens · Alle Rechte vorbehalten