Sicherheitspraktiken

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

Was	Wie
Konto-API-Schlüssel (Anthropic, OpenAI-kompatibel, SMTP)	AES-256-GCM, MASTER_ENCRYPTION_KEY
Benutzerpasswort-Hashes	bcrypt (cost 12)
IMAP / E-Mail-Kanal-Anmeldedaten	AES-256-GCM, MASTER_ENCRYPTION_KEY
Datenbankdateien auf der Festplatte	Sensible Felder werden vor der Speicherung auf Anwendungsebene verschlüsselt (AES-256-GCM, mandantenspezifische AAD, Schlüssel in HashiCorp Vault).

• Alle öffentlichen Endpunkte ausschließlich über HTTPS; HTTP wird auf HTTPS umgeleitet (Apache HSTS-Header).
• Unterstützte TLS-Versionen: TLS 1.2 und 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 Konto-Datenbanken:

Element	Häufigkeit	Aufbewahrungsdauer	Standort
Platform-DB (einstein_saas_platform)	Täglich, nachts (UTC, automatisiert)	7 Tage lokal; verschlüsselte Kopie in Frankreich bis zu 3 Wochen	Lokales Volume + verschlüsseltes Offsite-Replikat
Konto-DBs (einstein_saas_tenant_*)	Täglich, nachts (UTC, automatisiert)	7 Tage lokal; verschlüsselte Kopie in Frankreich bis zu 3 Wochen	Lokales Volume + verschlüsseltes Offsite-Replikat
Hochgeladene Dateien / Dokumentenspeicher	Täglich, nachts (UTC, automatisiert)	Verschlüsselte Kopie in Frankreich, etwa einen Monat	Lokales Volume + verschlüsseltes Offsite-Replikat

Backups laufen pro Datenbank über mysqldump --single-transaction, werden komprimiert und age-verschlüsselt gespeichert, täglich erneut verschlüsselt in ein Rechenzentrum in Frankreich kopiert, an einem anderen Ort als unsere Server, 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 einzelne Berechtigungen pro Bereich. Die Plattform prüft Berechtigungen serverseitig.

4.2 Zwei-Faktor-Authentifizierung

• 2FA über eine Authenticator-App (TOTP, RFC 6238 — zum Beispiel Google Authenticator oder Authy) oder über einen Code per E-Mail. Jeder Benutzer aktiviert sie selbst in den Kontoeinstellungen.
• Ist 2FA aktiviert, fragt die Plattform bei jeder Anmeldung nach dem zweiten Schritt.
• Wiederherstellungscodes gibt es nicht. Wer den Code per E-Mail wählt, braucht keine separate App.

4.3 Konto-Isolierung

Authentifizierung erfordert einen Konto-Kontext (Slug-basierte Anmeldung). Sitzungs-Token sind auf ein einzelnes Konto beschränkt. Kontoübergreifender Ressourcenzugriff wird auf Anwendungsebene durch obligatorische tenant_id-Filter in den Datenbankabfragen 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 zwei Jahre aufbewahrt und danach automatisch gelöscht, auch wenn das Konto früher beendet wurde. Der Nachweis, dass eine Löschanfrage ausgeführt wurde, wird nach 12 Monaten automatisch gelöscht. Das Log ist auf Anwendungsebene nur erweiterbar (append-only).

Audit-Einträge werden vom regulären Datenbankbenutzer der Anwendung geschrieben. Ein separater Insert-Only-Datenbankbenutzer ist nur für das Audit-Log der Reseller-API eingerichtet.

6.1 CVE-Überwachung

Composer-Abhängigkeiten prüfen wir mit composer audit. Kritische Schwachstellen in Laufzeitabhängigkeiten behandeln wir vorrangig.

6.2 Patch-Zyklus

• Betriebssystem-Sicherheitsupdates: täglich automatisch installiert (unattended-upgrades).
• PHP-Runtime: PHP 8.5, mit Sicherheitsupdates aktuell gehalten.
• 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 (Datenbank), Frankreich (Dateien und Backups)
Webserver	Apache 2.4 (mod_rewrite, mod_ssl)
Runtime	PHP 8.5
Datenbank	MySQL / MariaDB (platform + per-tenant)
Cache / Sitzungen	Redis (loopback, password-protected)
Grenzüberschreitende Datenübertragungen	Die KI-Verarbeitung kann außerhalb der EU stattfinden, zum Beispiel in den Vereinigten Staaten, es sei denn, EU-only ist aktiv (ab Plus). Welche KI-Anbieter wir nutzen, teilen wir Ihnen auf Anfrage mit.