Technische und organisatorische Maßnahmen

Diese Seite listet die technischen und organisatorischen Maßnahmen (TOMs) auf, die die ZentraLink-Plattform standardmäßig unterstützt. Die Liste spiegelt wider, was der Quellcode tatsächlich umsetzt; eigene physische und prozedurale Maßnahmen ergänzt der Operator.

Zutritts- und Zugangskontrolle

  • Selbst gehostete Bereitstellung auf operator-eigener Infrastruktur; physischer Zugang über die Richtlinien des Hosting-Anbieters (Hetzner / IONOS / On-Prem).
  • Passwort-Hashing mit Argon2id (memoryCost 19 MiB).
  • Zwei-Faktor-Authentifizierung per TOTP mit Einmal-Backup-Codes.
  • Serverseitige opake Session-Tokens, 14 Tage TTL, secure + httpOnly + sameSite Cookies.
  • Rollenbasierte Zugriffskontrolle (Owner, Admin, Supporter).

Zugriffskontrolle (Authorisierung)

  • Kontospezifischer Datenzugriff auf jeder API-Route.
  • Rollenbasierte Zugriffsprüfungen pro Route.
  • Konfigurierbare Approver-Rollen für DNS-Change-Requests.
  • Die Kontotrennung wird durch automatisierte Tests bei jedem Release verifiziert.

Pseudonymisierung / Datenminimierung

  • Das Audit-Log speichert User-ID + strukturierte Metadaten, keine rohen Payloads.
  • Login-Fingerprints werden als SHA-256-Hashes abgelegt (kein roher IP/UA).
  • Backup-Codes werden ausschließlich als Argon2id-Hashes abgelegt.

Verschlüsselung

  • TLS für alle Transportwege (operator-eigene Zertifikate, z. B. über Let's Encrypt).
  • Provider-API-Credentials, 2FA-Secrets und Konto-SMTP-Passwörter werden at-rest mit AES-256-GCM unter PLATFORM_ENCRYPTION_KEY verschlüsselt.
  • Für Single-Host-Installationen empfohlen: DB-Zugriff über Unix-Socket oder localhost-TCP.

Integrität

  • Jeder DNS-Write erzeugt eine DnsChange-Zeile + Audit-Event.
  • Pre- und Post-Execution-Snapshots werden vom Change-Request-Executor automatisch erzeugt.
  • Provider-Operationen melden Erfolg/Misserfolg pro Operation in den Change-Request zurück.

Verfügbarkeit

  • Standardisierte PostgreSQL-Backups über scripts/backup.sh (pg_dump).
  • systemd-überwachte Services mit automatischem Neustart bei Fehlern.
  • Healthcheck-Endpunkt unter /api/healthz erreichbar.
  • Cron-Worker hinter CRON_TOKEN Bearer-Auth isoliert, idempotente Schleifen.

Auditierbarkeit

  • AuditEvent-Zeilen für jede privilegierte Aktion (gefilterter Viewer unter /dashboard/audit).
  • CronRun-Zeilen für jeden geplanten Job-Aufruf.
  • MailMessage-Zeilen für jeden ausgehenden Mail-Versuch (QUEUED/SENT/FAILED).
  • DnsChange- und DnsChangeRequest-Zeilen bilden die vollständige DNS-Historie.

Lieferantenmanagement

  • Provider-Liste und Rollen sind auf der Seite /integrations dokumentiert.
  • Liste der Unterauftragsverarbeiter wird unter /subprocessors mit aktuellen Anbietern und deren Rolle im Datenfluss gepflegt.

Incident-Response

  • Statuspage wird aus der StatusIncident-Tabelle unter /status gerendert.
  • Sicherheits-Meldeadresse: security@zentralink.net (vom Operator pro Deployment überschreibbar).
  • Der Operator ist für fristgebundene Benachrichtigungsabläufe (Incident-Kommunikation) verantwortlich.