Content-Autopilot für DACH-Coaches · EU-Hosted · DSGVO-konform
CastLoop
Anmelden
· Art. 32 DSGVO

Technisch-organisatorische Maßnahmen

Anlage 1 zum Auftragsverarbeitungsvertrag (AVV). Beschreibt die gemäß Art. 32 DSGVO implementierten Sicherheitsmaßnahmen.

Stand: April 2026. Diese TOM werden regelmäßig an den Stand der Technik angepasst. Wesentliche Änderungen werden dem Kunden mitgeteilt.

1. Vertraulichkeit

Der Auftragsverarbeiter betreibt ein Einzelunternehmen ohne zusätzliche Mitarbeiter mit Daten-Zugriff. Alle eingesetzten Subunternehmer (siehe AVV § 7) sind auf Vertraulichkeit verpflichtet. Die eigenen Endgeräte (Entwickler-Workstations) sind FileVault-verschlüsselt, durch Touch-ID und starke Passwörter gesichert sowie mit automatischer Bildschirmsperre versehen.

2. Pseudonymisierung (Art. 32 Abs. 1 lit. a DSGVO)

  • In Logs werden E-Mail-Adressen nicht im Klartext, sondern ausschließlich als tenant_id bzw. anonymisierte User-ID referenziert (pino-Log-Redaction).
  • IP-Adressen werden für Rate-Limiting über einen geheimen IP_HASH_SALT (HMAC-SHA-256) gehasht; die Original-IPs werden nicht persistent gespeichert.
  • IPv4 wird auf /32, IPv6 auf /64 normalisiert, um die Rückführbarkeit zusätzlich einzuschränken.

3. Verschlüsselung (Art. 32 Abs. 1 lit. a DSGVO)

3.1 Verschlüsselung in Transit

  • Alle Verbindungen: HTTPS / TLS 1.2+ (HSTS aktiviert).
  • SMTP-Verbindungen zu IONOS via STARTTLS, TLS 1.2+ erzwungen.
  • Datenbank-Verbindungen intern über UNIX-Socket oder TLS.

3.2 Verschlüsselung at rest

  • OAuth-Tokens (Social-Media): AES-256-GCM „Envelope Encryption" mit versionierten Schlüsseln (ENCRYPTION_KEY, ENCRYPTION_KEY_V2…V16). Format: v{N}:iv:tag:ct. Der AAD-Kontext ist an tenantId:socialAccountId:platform gebunden — Tampering am Row-Kontext lässt Decrypt scheitern.
  • Passwörter: Argon2id mit OWASP-2024-Parametern (m=19456 KiB, t=2, p=1). Legacy-bcrypt-Hashes werden beim Login erkannt und transparent auf Argon2id rehashed.
  • VM-Disk-Verschlüsselung: Die IONOS-Cloud-Infrastruktur bietet Disk-Verschlüsselung auf Provider-Ebene.
  • Secrets: .env-Dateien ausschließlich mit File-Permissions 0600, niemals im Git-Repo.

4. Zugangskontrolle (physisch / Infrastruktur)

  • Das Produktiv-System läuft in den IONOS-Rechenzentren in Deutschland (ISO 27001, ISO 22301 zertifiziert). Physischer Zugang ist Provider-seitig abgesichert (24/7-Sicherheitsdienst, Biometrie, Video-Überwachung).
  • SSH-Zugriff auf die Server: ausschließlich via Public-Key (kein Password-Login), über einen nicht-standardisierten SSH-Port (2222), mit Fail2ban gegen Brute-Force, und mit IdentitiesOnly=yes Enforcement.
  • Firewall (firewalld) beschränkt eingehende Verbindungen auf Port 2222 (SSH), 80 (HTTP-Redirect auf HTTPS) und 443 (HTTPS).
  • SELinux im Enforcing-Mode.

5. Zugriffskontrolle (Applikations-Ebene)

  • Authentifizierung: E-Mail + Passwort (Argon2id) oder SSO (Google / Microsoft / Apple). JWT-basierte Session-Tokens mit ES256-Signaturen und kid-Rotation (CURRENT + optional PREVIOUS Key-Slot für Zero-Downtime-Rotation).
  • Refresh-Token-Rotation: Family-basierte Rotation mit 10-Sekunden-Grace-Window in Redis; ≥3 Grace-Hits derselben alten Token-ID lösen theft_detected und Family-Revoke aus.
  • Multi-Tenant-Isolation via Postgres Row-Level-Security (RLS): App-Connections laufen unter der DB-Rolle castloop_app (ohne BYPASSRLS). Jede Transaktion setzt app.tenant_id per SET LOCAL. Migrations laufen unter castloop_migrator (mit BYPASSRLS). Selbst eine SQL-Injection kann nicht aus dem eigenen Tenant-Scope ausbrechen (Defense-in-Depth).
  • Rate-Limiting: Redis-Lua-Script (atomic Check+Increment) gegen Brute-Force und Abuse.
  • CSRF: SameSite-Strict-Cookies + CSRF-Tokens.
  • CSP: Content-Security-Policy mit Per-Request-Nonce und strict-dynamic, verhindert XSS.
  • SSH-Zugang auf Server: Nur einzelner Administrator (Inhaber).

6. Trennungskontrolle

  • Getrennte Datenbanken pro Projekt auf dem Shared-Server (eigene Postgres-DB castloop mit eigenem User castloop_user, kein Zugriff auf andere DBs).
  • Produktiv-, Staging- und Entwicklungs-Umgebungen sind voneinander getrennt; Produktiv-Secrets gelangen nie in Staging/Dev.
  • Mollie Key-Strict-Mode: In Production ausschließlich live_*-Keys, in Staging/Dev ausschließlich test_*-Keys — via zod superRefine erzwungen.

7. Integrität (Art. 32 Abs. 1 lit. b DSGVO)

  • RLS verhindert Cross-Tenant-Datenmanipulation (siehe 5).
  • Postgres Advisory Locks (Key 821912301) gated Drizzle-Migrations — zwei parallele Deploys können nicht gleichzeitig migrieren.
  • AAD-gebundene OAuth-Token-Verschlüsselung: Tampering am Row-Kontext lässt den Decrypt scheitern (Integritätsschutz via AES-GCM-Tag).
  • Mollie-Webhook-Idempotenz: Dedizierte mollie_webhook_events-Tabelle mit Idempotenz-Key (resource_id, payload_hash) (sha256 über canonical JSON).
  • Input-Validierung auf Client- und Server-Seite (zod-Schemas).

8. Verfügbarkeit

  • pm2 Auto-Restart: castloop-api, castloop-worker und castloop-app laufen unter pm2-Supervision und starten bei Crash automatisch neu.
  • Graceful Shutdown: SIGTERM/SIGINT drainen HTTP-Requests und BullMQ-Jobs; hart gecappt durch SHUTDOWN_TIMEOUT_MS.
  • Healthcheck-Endpoint für Monitoring.
  • VM-Snapshot-Backups: IONOS-provider-managed, täglich rotierend. Keine eigenständigen pg_dump-Backups — das Provider-Snapshot-Layer wird als ausreichend bewertet.

9. Belastbarkeit

  • Rate-Limiting schützt gegen Überlastung.
  • BullMQ mit Retry-Mechanismen (exponential backoff) für Clip-Rendering und Platform-Publish.
  • Mollie-Ingest Orphan-Sweeper (60s Intervall, 120s Grace, BullMQ-jobId=eventId-Dedupe) verhindert Payment-Drift bei ausgefallenen Webhooks.
  • Unabhängige ioredis-Connections für BullMQ vs. App-Code verhindern Key-Prefix-Kollisionen.

10. Wiederherstellbarkeit (Art. 32 Abs. 1 lit. c DSGVO)

  • Täglich rotierende VM-Snapshots (IONOS-managed).
  • Deployment via Git + rsync ermöglicht ein Rollback auf einen früheren Commit innerhalb weniger Minuten.
  • Idempotente, advisory-lock-gated Migrations erlauben sicheren Re-Run bei Teilausfällen.

11. Verfahren zur regelmäßigen Überprüfung

  • Dependency-Updates (npm audit, Dependabot) mindestens monatlich.
  • OS-Patches (AlmaLinux) mindestens monatlich.
  • Log-Monitoring: pino-Logs mit Redaction sensibler Felder (Passwörter, Tokens, JWTs, authorization/cookie-Header, API-Keys, DATABASE_URL, REDIS_URL, SMTP_PASS).
  • Jährliche interne TOM-Review, ggf. Anpassung an Stand der Technik.
  • Bei Bedarf / auf Kunden-Anfrage externes Penetration-Testing.

12. Auftragskontrolle

  • Schriftliche AVV-Verträge mit allen eingesetzten Subunternehmern (siehe AVV § 7), soweit diese datenschutzrechtlich als Auftragsverarbeiter einzustufen sind.
  • Dokumentierte Weisungswege: Kunden-Dashboard, AGB/AVV-Vertragswerk, formlose E-Mail an info@castloop.de.
  • Kein Einsatz weiterer Subunternehmer ohne 30-tägige Vorankündigung an den Kunden (siehe AVV § 7).

Stand: April 2026 · Version 1.0 · Anlage 1 zum AVV

← Zurück zum AVV Zur Startseite