Technische und organisatorische Maßnahmen (TOMs) – flowgeist DMS
Stand: 27.09.2026
Version: 1.0
Geltungsbereich: Art. 32 DSGVO, Auftragsverarbeitungsvertrag (AVV)
Diese technischen und organisatorischen Maßnahmen beschreiben die Sicherheitsvorkehrungen, die flowgeist zum Schutz personenbezogener Daten auf der flowgeist DMS Plattform trifft.
1. Zutrittskontrolle (physische Sicherheit)
| Maßnahme | Beschreibung |
|---|
| Rechenzentrum | Hetzner Online GmbH, Falkenstein (Deutschland). Physische Sicherheit durch den Rechenzentrumsbetreiber (Zutrittskontrollen, Videoüberwachung, Brandmeldeanlage). |
| Deployment-Modell | Single-Server Docker Deployment (vdps-prod-01). Keine physischen Geräte bei flowgeist. |
2. Zugangskontrolle (logische Sicherheit)
| Maßnahme | Beschreibung |
|---|
| Passwort-Hashing | scrypt mit OWASP-Parametern (N=16384, r=8, p=1, 128-bit Salt, 64-Byte Hash). Format: scrypt:N:r:p:saltB64:hashB64. |
| Authentifizierung | Keycloak 24 (OpenID Connect/OAuth2), JWT-Validierung via JWKS, Token-Refresh |
| Mehrfaktor-Authentifizierung | TOTP (RFC 6238, HMAC-SHA1, 30s-Fenster) für Benutzer verfügbar |
| RBAC | Rollenbasierte Zugriffskontrolle mit DmsRole-Enum + RolePermission-Tabelle (Berechtigungskatalog: module.resource.action, z. B. crm.customers.read, admin.tenants.manage). Permissions-Matrix: Employee→Admin, Admin→Admin+Feature-Flags, Owner→Owner. |
| Multi-Tenant-Isolation | Strikte Trennung der Mandantendaten auf Datenbankebene via PostgreSQL Row-Level-Security (Migrations V001__tenants.sql + V005__rls_policies.sql); tenant_id auf jeder Tabelle; Tenant-Context via Middleware |
| Session-Management | OIDC-Code-Flow via Keycloak; Session-TTL: 7d Access / 30d Refresh; rememberMe: 30d |
| Account-Lockout | Keycloak Brute-Force-Detection (für verwaltete Konten) |
| Support-Zugriff | Admin/Owner-Zugriff via Impersonation-Flow; spezifischer Claim-Check |
| Production Secret Management | Infisical — Runtime Secret Injection (keine Secrets im Code); .env.docker.dev nur für Dev |
3. Zugriffskontrolle (Datenzugriff)
| Maßnahme | Beschreibung |
|---|
| RLS-Policies | PostgreSQL Row-Level-Security auf allen Mandantentabellen (V005__rls_policies.sql); Session-Variable app.current_tenant |
| Berechtigungskatalog | dms_permission_catalog.csv + dms_role_matrix.csv; Permission-Check in Route-Middleware |
| API-Zugriffskontrolle | Auth-Middleware auf allen /v1/ Routes; Require-Role/Require-Permission Guards |
| Granulare Berechtigungen | Pro-Ressource Aktionen: read, write, delete, export |
4. Weitergabekontrolle (Datenübertragung)
| Maßnahme | Beschreibung |
|---|
| TLS | TLS 1.2 und 1.3 für alle Verbindungen (Nginx-Frontend, ssl_protocols TLSv1.2 TLSv1.3); Let’s Encrypt/certbot |
| Sicherheits-Header | HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy |
| API-Gateway | APISIX 3.9 (optional in Prod; direkte Nginx-Routes für Next.js-Proxy) |
| Webhook-Sicherheit | HMAC-SHA256 Signatur-Verifikation für eingehende Webhooks; Timestamp-Validation (Replay-Schutz) |
| File-Transfer-Hub | SFTP für ausgehende Dateiübertragungen (P14) |
| Secrets | Infisical; keine Secrets im Code |
5. Eingabekontrolle (Aufzeichnung)
| Maßnahme | Beschreibung |
|---|
| Audit-Trail | Protokollierung sicherheitsrelevanter Zugriffe und Aktionen (A.8.15); append-only audit_log-Tabelle (V004__audit_log.sql) — Triggers verhindern UPDATE/DELETE; der User kann seine eigenen Einträge nicht löschen/ändern |
| AI-Audit | Jeder Copilot/Agenten-Request wird im AI-Register protokolliert (ai_decision_audit): Input-Hash, Tool, Modell, Latenz, Kosten, PII-Flags, Policy-Denials; 7-Jahre-Retention (M18 Policy) |
| Observability | SigNoz + OpenTelemetry (self-hosted, keine Daten verlassen die Infrastruktur); OTLP-Traces, Logs, Metriken |
| Dokumentation | data-resilience-Modul: GoBD-Ausrichtung; Dokument-Versionierung via Mayan EDMS |
6. Auftragskontrolle
| Maßnahme | Beschreibung |
|---|
| Auftragsverarbeiter | Keine externen Unter-Auftragsverarbeiter über Hetzner (Hosting) hinaus; alle Plattform-Komponenten (PostgreSQL, Keycloak, MinIO, OpenSearch, ClickHouse, Kafka, Valkey, Temporal, Novu, Mayan EDMS, ERPNext, Kimai, APISIX, Infisical, SigNoz) sind eingebettete OSS auf der eigenen Hetzner-Infrastruktur |
| KI-Verarbeitung | Ausschließlich EU-residente Modelle (Azure OpenAI EU / selbst-gehostete Modelle wie Mistral/Llama); keine Übermittlung an öffentliche Modelle; AI-Register dokumentiert eingesetzte Systeme |
| Kundenkonfigurierte Integrationen | Integration-Hub-Connectoren (OEM, DAT/Schwacke, DATEV, PEPPOL, Banken, Lade-Netze) werden erst nach Kundenkonfiguration aktiv; kein automatischer Datenfluss |
| Doku | Rechtliche Dokumentation (Datenschutz, AVV) spiegelt den aktuellen Stand |
7. Verfügbarkeitskontrolle
| Maßnahme | Beschreibung |
|---|
| Backup | Restic für PostgreSQL, MinIO, Datenbank-Dumps (data-resilience-Modul); rclone als Transport-Schicht (verschiedene Remote-Targets konfigurierbar, z. B. S3, SFTP) |
| Recovery | Point-in-Time Recovery via PostgreSQL WAL; data-resilience-Modul mit Restore-Workflows |
| Infrastruktur | Hetzner Enterprise-Hardware; Single-Server Deployment mit allen Services als Docker-Container |
| Monitoring | SigNoz + OpenTelemetry (self-hosted): Traces, Logs, Metriken, Alerts |
8. Trennungsgebot (Mandantentrennung)
| Maßnahme | Beschreibung |
|---|
| Mandanten-Isolation | Strikte Trennung der Kundendaten auf Datenbankebene via PostgreSQL Row-Level-Security; tenant_id auf jeder Tabelle; app.current_tenant Session-Variable |
| Mandanten-Provisioning | Automatisiertes Tenant-Provisioning (V006__tenant_provisioning.sql); kein Shared-Schema ohne RLS |
| Mandanten-Übergreifende Daten | Nur globale, nicht-mandantenbezogene Tabellen (Permissions-Katalog, Feature-Flags) sind tenant-ungebunden |
| Storage-Trennung | MinIO/S3-kompatible Objektspeicherung mit mandantenbezogenem Pfadschema |
9. Organisatorische Maßnahmen
| Maßnahme | Beschreibung |
|---|
| Entwicklungsprozess | Code-Reviews, CI/CD-Pipeline, Modul-Isolation mit Anti-Corruption-Layer; AGENTS.md als Entwicklungsstandard |
| Zugangsmanagement | RBAC-Modell mit Berechtigungsmatrix; Team-Zuordnung via Keycloak-Gruppen |
| Dokumentation | Technische Dokumentation je Modul (docs/), Compliance-Log pro Änderung |
| Vertraulichkeit | Alle Mitarbeiter unterliegen Vertraulichkeitsverpflichtungen |
| Change-Management | Flyway-Migrationen (versioniert, append-only); Semantic Versioning |
| AI-Governance | AI-Register, PII-Filter, RAG-Guardrails, Human-in-the-Loop für Freigaben (EU-AI-Act-Ausrichtung: limited/minimal risk) |
10. Revision
| Version | Datum | Änderungen |
|---|
| 1.0 | 27.09.2026 | Erstfassung für flowgeist DMS — Code-verifiziert: scrypt-Hashing, Keycloak-Auth, TOTP, RLS-Tenant-Isolation, append-only audit_log, Restic-Backup, SigNoz, Infisical, APISIX, AI-Governance, Integration Hub |