Sicherheit

Produktionsumgebung

Die Produktion läuft in der EU (Frankfurt) unter einem dedizierten, vollständig isolierten Cloud-Konto, getrennt von jedem anderen Produkt. Rechenleistung, Netzwerk, Speicher, Geheimnisse und Protokollierung sind ausschließlich Syncanix zugeordnet. Die EU-Residenz ist im Code durchgesetzt – ein falsch konfiguriertes Deployment verweigert die Ausführung, wenn es zu einer Region außerhalb der EU aufgelöst wird.

Tenant-Isolation, mit Nachweisen

Die Daten jedes Tenants sind durch vier unabhängige Durchsetzungsebenen getrennt — jede einzelne genügt, um eine tenant-übergreifende Anfrage zu stoppen:

1. Grenze: Jede authentifizierte Anfrage muss sich zu einem Tenant auflösen, sonst wird sie am Rand abgewiesen.
2. Anfragekontext: Die Tenant-Identität wird an die Anfrage gebunden und in jede darunterliegende Ebene propagiert — nie von Hand durchgereicht.
3. Abfragen: Jeder Datenzugriff ist explizit auf den anfragenden Tenant begrenzt.
4. Datenbank: Row-Level-Security-Richtlinien auf jeder mandantenfähigen Tabelle erzwingen dieselbe Grenze in Postgres selbst — selbst eine hypothetisch übersehene Prüfung weiter oben kann sie nicht überschreiten.

Das ist getestet, nicht behauptet: Row-Level-Security wird durch eine Integrationssuite gegen eine echte Postgres-Datenbank bewiesen, und eine nächtliche Sondenmatrix versucht tenant-übergreifende Lese-, Schreib-, Log-, Secret- und Vektorsuche-Zugriffe — vor jedem Deploy muss jede Sonde bestehen. Sicherheitsprüfer können das vollständige Nachweispaket unter admin@syncanix.com anfordern.

Verschlüsselung

Alle Kundendaten werden im Ruhezustand mit AES-256 verschlüsselt. Jeder Datenspeicher – Datenbanken, Objektspeicher, angehängte Volumes und Protokolle – wird mit verwalteten Schlüsseln verschlüsselt, die in einem verwalteten Rhythmus rotiert werden.

Alle Daten bei der Übertragung verwenden mindestens TLS 1.3. Die Marketing-Website, das Kunden-Dashboard unter app.syncanix.com und der API-Endpunkt leiten alle HTTP auf HTTPS um und erzwingen HSTS mit einer max-age von zwei Jahren einschließlich Subdomains und mit preload. BYOK (Bring Your Own Key) wird auf der Enterprise-Stufe unterstützt – vom Kunden bereitgestellte Schlüssel werden für die Datenhülle des Kunden verwendet, ohne jemals in der Protokollausgabe von Syncanix zu erscheinen.

Identität und Authentifizierung

Die Authentifizierung des Dashboards wird von Auth0 übernommen. Jeder API-Endpunkt wird durch eine Auth-Schicht geschützt, die die JWT-Signatur gegen den JWKS-Endpunkt des Anbieters validiert, Audience und Issuer prüft und abgelaufene Token ablehnt. Der Schutz ist standardmäßig aktiviert; ein Endpunkt ist nur dann öffentlich, wenn er ausdrücklich so gekennzeichnet ist. Es gibt keinen Fehlermodus „Ich habe vergessen, die Authentifizierung hinzuzufügen“ – die Voreinstellung wird erzwungen.

Autorisierung

Berechtigungsprüfungen befinden sich in der Service-Schicht, nicht am API-Rand. Ein Service, der „Projekt Y bearbeiten“ beantwortet, überprüft, dass der Aufrufer mindestens die Rolle „Editor“ für Projekt Y besitzt, bevor er auf die Datenbank zugreift. Service-zu-Service-Aufrufe verwenden ein separates Authentifizierungsverfahren (signierte Umschläge oder plattformauthentifizierte Endpunkte) – niemals Benutzer-JWTs.

IAM und Least-Privilege

Jede Workload-Rolle trägt die kleinstmögliche Richtlinie. Richtlinien werden explizit geschrieben; keine Rolle verwendet breite Platzhalter. Wo die Ressourcenbegrenzung nicht aussagekräftig genug ist, begrenzen Richtlinien per Tag. In der CI gibt es keine langlebigen Zugriffsschlüssel – die Pipeline nimmt eine Rolle über OIDC an; die lokale Entwicklung verwendet kurzlebige Anmeldedaten.

Anwendungssicherheit

Jedes API-Argument und jeder Anfragetext wird vor Erreichen des Service-Codes über ein striktes Schema geparst. Datenbankabfragen sind vollständig parametrisiert – keine String-Interpolation von Benutzereingaben. Schreibvorgänge verwenden typisierte APIs, niemals rohe, aus Benutzereingaben gebildete Ausdrücke.

HTTP-Sicherheits-Header werden bei jeder an den Kunden gerichteten Antwort ausgeliefert:

• Content-Security-Policy mit einer strikten Zulassungsliste (Auth0, eigener Origin, keine Inline-Skripte).
• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload.
• X-Frame-Options: DENY (Schutz vor Clickjacking).
• X-Content-Type-Options: nosniff.
• Referrer-Policy: strict-origin-when-cross-origin.
• Permissions-Policy: Geolokalisierung, Mikrofon und Kamera werden standardmäßig allesamt verweigert.

CORS wird auf zwei unabhängigen Schichten durchgesetzt, jeweils mit einer expliziten Origin-Zulassungsliste. Eine Wildcard-Origin wird zur Build-Zeit abgelehnt – ein Produktions-Deployment ohne explizite Origins kann nicht fortgesetzt werden.

Geheimnisverwaltung

Produktionsgeheimnisse liegen in einem dedizierten Geheimnis-Manager unter einem umgebungsspezifischen Namespace. Nicht geheime Konfiguration liegt in einem separaten Parameter-Store. Geheimnisse werden den Workloads beim Start bereitgestellt – sie liegen niemals in der Versionsverwaltung. Datenbank-Anmeldedaten werden automatisch rotiert; Drittanbieter-Token (Paddle, Anthropic, OpenAI) werden manuell in einem vierteljährlichen Rhythmus rotiert.

Protokollierung und Audit

Protokolle sind strukturiertes JSON mit standardmäßig 14-tägiger Aufbewahrung. Jede Protokollzeile trägt eine Korrelations-ID (Request-ID), sodass der Ablauf eines einzelnen Benutzers durchgängig rekonstruiert werden kann. Eine Redaktionsliste maskiert die Felder token / password / secret / authorization automatisch; vollständige personenbezogene Daten gelangen niemals in den Logger. Authentifizierungsfehler erzeugen eine WARN-Zeile mit der Quell-IP und dem Grund – niemals mit dem Token-Inhalt.

Abhängigkeitshygiene

Automatisierte Abhängigkeitsaudits laufen in der CI; hohe oder kritische Hinweise lassen den Build scheitern. Renovate und Dependabot sind für das Abhängigkeitsmanifest und die Lockfile aktiviert. Jede neue Open-Source-Bibliothek durchläuft eine dokumentierte Prüfung vor der Übernahme (Sicherheit, Wartung, Lizenz, Lock-in, Performance).

Zertifizierungen und Audits

Die Sammlung von Nachweisen für SOC 2 Type I beginnt über Vanta im Monat nach dem kommerziellen Start von Syncanix, mit einem für Q3 2026 angestrebten Type-I-Bericht. SOC 2 Type II folgt nach etwa 9 Monaten. ISO-27001-Nachweise werden parallel erhoben (70-80 % Kontrollüberschneidung mit SOC 2) – Zertifizierung angestrebt für Q4 2026. Vollständiger Compliance-Status →

Incident Response

Die Meldung von Schwachstellen erfolgt an admin@syncanix.com – Eingangsbestätigung innerhalb von 24 Stunden und Triage innerhalb von 72 Stunden. Bestätigte Verstöße mit Kundenauswirkung werden den betroffenen Kunden innerhalb von 24 Stunden nach Bestätigung gemeldet, im Einklang mit der Verpflichtung aus Artikel 33 des DPA. Ein dokumentiertes Incident-Response-Runbook wird vierteljährlich geprobt.