Sicherheitspraktiken

Sensible Felder, die in der Plattformdatenbank gespeichert werden, werden vor dem Schreiben auf die Festplatte mit AES-256-GCM verschlüsselt.

Was	Wie
Tenant API-Schlüssel (Anthropic, OpenAI-kompatibel, SMTP)	AES-256-GCM, MASTER_ENCRYPTION_KEY
Benutzerpasswort-Hashes	bcrypt (cost 12)
BYOD-Verbindungszeichenfolgen	AES-256-GCM, MASTER_ENCRYPTION_KEY
IMAP / E-Mail-Kanal-Anmeldedaten	AES-256-GCM, MASTER_ENCRYPTION_KEY
Datenbankdateien auf der Festplatte	MySQL InnoDB Tablespace auf verschlüsseltem Volume TODO: confirm full-disk encryption status with ops

• Alle öffentlichen Endpunkte ausschließlich über HTTPS; HTTP wird auf HTTPS umgeleitet (Apache HSTS-Header).
• Minimale TLS-Version: TLS 1.3 (TLS 1.0 / 1.1 deaktiviert).
• Widget widget.js wird mit Access-Control-Allow-Origin: * bereitgestellt, aber die Chat-API-Endpunkte validieren widget_key + origin-Allowlist.
• Interne Service-Aufrufe (Redis, MySQL auf localhost) kommunizieren über die Loopback-Schnittstelle. Keine unverschlüsselten Daten verlassen den Host.

Der folgende Backup-Plan gilt für die Platform-Datenbank und Tenant-Datenbanken:

Element	Häufigkeit	Aufbewahrungsdauer	Standort
Platform-DB (einstein_saas_platform)	Täglich, nachts (UTC, automatisiert)	7 tägliche Backups (rollierend)	Lokales Volume + verschlüsseltes Offsite-Replikat
Tenant-DBs (einstein_saas_tenant_*)	Täglich, nachts (UTC, automatisiert)	7 tägliche Backups (rollierend)	Lokales Volume + verschlüsseltes Offsite-Replikat
Hochgeladene Dateien / Dokumentenspeicher	Täglich, nachts (UTC, automatisiert)	7 tägliche Backups (rollierend)	Lokales Volume + verschlüsseltes Offsite-Replikat

Backups laufen pro Datenbank über mysqldump --single-transaction, werden komprimiert und age-verschlüsselt gespeichert, auf ein separates Offsite-Volume repliziert, und jeder Lauf wird auf einen nicht leeren Dump geprüft und mit Erfolgs-/Fehlerstatus protokolliert.

Backup-Archive werden im Ruhezustand mit age (X25519 / ChaCha20-Poly1305) verschlüsselt; der Entschlüsselungsschlüssel wird getrennt von den Archiven aufbewahrt. Mit Spaltenverschlüsselung (AES-256-GCM) geschützte Felder bleiben in jedem Archiv verschlüsselt. Die Wiederherstellbarkeit wird durch einen automatisierten monatlichen Restore-Test überprüft.

4.1 Rollenbasierte Zugriffskontrolle (RBAC)

Jedem portal-Benutzer wird eine Rolle zugewiesen. Rollen enthalten granulare Berechtigungen (51+ einzelne Flags). Die Plattform erzwingt Berechtigungsprüfungen serverseitig auf jedem API-Endpoint.

4.2 Zwei-Faktor-Authentifizierung

• 2FA via TOTP (RFC 6238 — Google Authenticator, Authy, etc.) ist obligatorisch für die Owner-Rolle und wird bei der Anmeldung erzwungen.
• Kontoinhaber können 2FA für alle Teamkollegen über das Einstellungspanel erzwingen.
• Sicherungs-Wiederherstellungscodes werden bei der Registrierung generiert und müssen vom Benutzer sicher gespeichert werden.

4.3 Tenant-Isolierung

Authentifizierung erfordert einen Tenant-Kontext (Slug-basierte Anmeldung). Sitzungs-Token sind auf einen einzelnen Tenant beschränkt. Cross-Tenant-Ressourcenzugriff wird auf Anwendungsebene durch obligatorische tenant_id-Filter bei allen Abfragen verhindert.

Bedeutende Aktionen auf Plattform-Ressourcen werden in der Tabelle audit_log (Plattform-Datenbank) aufgezeichnet. Jeder Eintrag enthält:

• Akteur: Benutzer-ID, Rolle und Tenant-ID.
• Aktion: Verb (erstellen, aktualisieren, löschen, anmelden, exportieren, …).
• Ressource: Entitätstyp und ID.
• Metadaten: geänderte Feldnamen und alte/neue Werte (sensible Felder redigiert).
• Zeitstempel: gespeichert in UTC (ISO 8601).
• IP-Adresse: Quell-IP der Anfrage.

Audit-Log-Einträge werden 2 Jahre lang aufbewahrt. Das Log ist auf Anwendungsebene nur Append-Only.

Ein dedizierter Insert-Only-Datenbankbenutzer (einstein_audit_writer) wird für Audit-Schreibvorgänge verwendet, um Änderungen oder Löschungen von Log-Einträgen durch den Anwendungsdbbenutzer zu verhindern.

6.1 CVE-Überwachung

Composer-Abhängigkeiten werden bei jedem Deployment-Durchlauf über composer audit überwacht. Kritische CVEs in Runtime-Abhängigkeiten führen zu einem Out-of-Band-Patch innerhalb von 72 Stunden nach Veröffentlichung. TODO: confirm SLA with ops

6.2 Patch-Zyklus

• OS-Sicherheitspatches: angewendet während des wöchentlichen Wartungsfensters. TODO: confirm window day/time with ops
• PHP-Runtime: auf der neuesten stabilen Minor-Version des aktiven Branches (derzeit PHP 8.2.x).
• Webserver: Apache 2.4.x — auf dem neuesten Stand mit Sicherheitsupdates der Distribution.

6.3 Verantwortungsvolle Offenlegung

Externe Sicherheitsforscher werden eingeladen, Schwachstellen gemäß unserer koordinierten Offenlegungsrichtlinie zu melden. Lesen Sie die Richtlinie zur verantwortungsvollen Offenlegung →

Komponente	Detail
Hosting-Region	EU — Niederlande
Produktionsserver	dev01-aionized (Ubuntu)
Webserver	Apache 2.4 (mod_rewrite, mod_ssl)
Runtime	PHP 8.2+
Datenbank	MySQL / MariaDB (platform + per-tenant)
Cache / Sitzungen	Redis (loopback, password-protected)
Grenzüberschreitende Datenübertragungen	Standardmäßig keine. Optionale Cloud-AI-Aufrufe (Anthropic/OpenAI-kompatibel) sind an Benutzerzustimmung gebunden und werden durch Standardvertragsklauseln abgedeckt.