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) ist in jedem Tarif verfügbar – Kunden können Modell-Traffic über ihren eigenen Anbieterschlüssel leiten, der niemals in der Protokollausgabe von Syncanix erscheint.

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.

Sicherheit agentischer KI und Schutz vor Prompt-Injection

Das Chat-Widget und der mandantenbezogene MCP-Server sind den OWASP Top 10 für agentische Anwendungen 2026 (ASI01–ASI10) zugeordnet. Der primäre Angreifer, gegen den wir entwerfen, sind nicht vertrauenswürdige Inhalte, die das Modell erreichen — eine in einem abgerufenen Dokument, einem Tool-Ergebnis oder dem Seitenkontext versteckte Prompt-Injection —, die versuchen, den Agenten zu kapern, Daten zu exfiltrieren oder den Nutzer zu täuschen.

Für Risiken der Injection-Klasse ist unsere veröffentlichte Haltung ehrlich: gemindert und gemessen, niemals „beseitigt“. Die deterministischen Kontrollen unten sind im Code verifiziert und bedingen jedes Deployment; modellverhaltensbedingte Restrisiken wie eine neuartige Jailbreak-Formulierung werden nachverfolgt und laufend im Red-Teaming geprüft.

Die Kontrollen, die diese Haltung stützen:

• Eine ausfallsichere Eingabe-Firewall prüft jeden nicht vertrauenswürdigen Kanal vor dem Modelllauf und weist Jailbreak- und System-Prompt-Override-Versuche ab — in allen sechs unterstützten Sprachen, sodass ein Sprachwechsel sie nicht umgeht.
• Inhalte, die das Modell nicht selbst erstellt hat (abgerufene Dokumente, Tool-Ergebnisse, Seitenkontext), gelten als nicht vertrauenswürdig: eine daraus abgeleitete Aktion kann niemals ohne eine neue, ausdrückliche Bestätigung schreiben, löschen oder umleiten.
• Ein Filter zur Verhinderung von Datenverlust schwärzt Geheimnisse und personenbezogene Daten aus der Modellausgabe, bevor sie die Plattform verlässt.
• Eine kuratierte gegnerische Red-Team-Suite läuft bei jeder Änderung und blockiert das Deployment, wenn ein bekannter Angriff durchkommt — oder wenn eine legitime Nachricht übermäßig blockiert wird.

Das vollständige bereinigte Bedrohungsmodell und die Ergebnisse der gegnerischen Evaluierung — die OWASP-Agentic-Top-10-Zuordnung samt unserer Red-Team-Methodik — sind für Sicherheitsteams auf Anfrage erhältlich unter admin@syncanix.com unter gegenseitiger Geheimhaltungsvereinbarung.

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 3 Werktagen und Triage innerhalb von 7 Tagen. 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.