Sicherheit und Compliance

Authentifizierung

• Access-Token sind kurzlebige JWTs (15 Minuten), die am API-Gateway geprüft werden; Refresh-Token gelten 30 Tage bei Inaktivität und höchstens 90 Tage, werden bei jeder Verwendung rotiert und in einem HttpOnly-, Secure- und SameSite-Cookie gespeichert. Die Wiederverwendung eines rotierten Refresh-Tokens widerruft die gesamte Kette.
• Signaturschlüssel werden alle 90 Tage mit einer Überlappung rotiert; öffentliche Schlüssel werden unter /.well-known/jwks.json veröffentlicht.
• Berechtigungen sind nicht in Token eingebettet: Sie werden bei jeder Anfrage gelesen, sodass eine Rollenänderung sofort wirkt und jede Sitzung zentral widerrufen werden kann.
• Die Zwei-Faktor-Authentifizierung (TOTP) kann optional, für Inhaber und Administratoren verpflichtend oder für alle verpflichtend sein. Single Sign-On mit Google Workspace und Apple ist in jedem Tarif verfügbar. SAML 2.0, Passkeys und SCIM-Provisionierung sind geplant und noch nicht verfügbar.
• API-Schlüssel werden einmal angezeigt, als SHA-256-Hash gespeichert, aus einem geschlossenen Katalog mit Scopes versehen, durch die Berechtigungen ihres Inhabers begrenzt und sind sofort widerrufbar. Siehe Authentifizierung.
• Die Anmeldung ist pro IP und pro E-Mail-Adresse in der Rate begrenzt; zehn Fehlversuche sperren das Konto für 30 Minuten; Fehlversuche von einer IP-Adresse werden gezählt und protokolliert, sperren diese Adresse aber standardmäßig nicht. Jede Anmeldung, jeder Fehlversuch, jede Aktualisierung, jede Berechtigungsänderung und jede Administratoraktion wird im Audit-Log erfasst.

Mandantentrennung

Jede Zeile in jedem Dienst trägt das Konto, zu dem sie gehört, und jede Abfrage wird automatisch danach gefiltert; das Abschalten des Filters erfordert einen ausdrücklichen, freigegebenen Aufruf, der nur für mandantenübergreifende Vorgänge des Personals verwendet wird und durch Tests abgedeckt ist. Rollen pro Website fügen zusätzlich einen Website-Filter hinzu. Eine Anfrage nach der Ressource eines anderen Kontos antwortet mit 404, nie mit 403, damit IDs nicht durchprobiert werden können. Jeder schreibende Endpunkt verwendet eine strikte Allowlist für Felder. Für jeden neuen Endpunkt ist ein kontoübergreifender Zugriffstest Pflicht.

Der Header X-Account-Id wird bei jeder Anfrage mit dem Token abgeglichen, sodass ein Client-Fehler oder ein wiederverwendetes Token nie unbemerkt einen anderen Mandanten lesen kann.

Verschlüsselung

TLS 1.2 oder neuer für jeden öffentlichen Endpunkt, gegenseitiges TLS zwischen Diensten, TLS zu jedem Datenspeicher, verschlüsselte Volumes im Ruhezustand und Envelope-Verschlüsselung pro Konto für sensible Felder. Öffentliche Zertifikate werden automatisch ausgestellt und erneuert; interne Zertifikate sind kurzlebig.

Geheimnisse

Alle Geheimnisse, einschließlich Ihrer BYOK-Anbieterschlüssel und Webhook-Geheimnisse, liegen verschlüsselt, pro Dienst begrenzt und auditiert in einem eigenen Secrets Manager. Nichts davon steht in der Versionsverwaltung (durch einen Scan vor jedem Commit erzwungen) oder in Container-Images (in der CI geprüft). Entwickler haben standardmäßig keinen Zugriff auf Produktionsgeheimnisse; Notfallzugriff erfordert zwei Freigaben, ist kurzlebig und wird in einem Kanal protokolliert, der nicht stummgeschaltet werden kann.

Webhooks

Ausgehende Zustellungen werden mit HMAC-SHA256 über Zeitstempel und unveränderten Body signiert, tragen eine Nonce und eine Ereignis-ID, werden außerhalb eines Fensters von fünf Minuten abgelehnt und mit Backoff bis in eine Dead-Letter-Queue wiederholt. Geheimnisse werden mit einem Überlappungsfenster rotiert und lassen sich sofort widerrufen. Eingehende Webhooks von Anbietern werden mit dem Verfahren des jeweiligen Anbieters verifiziert, bevor irgendetwas verarbeitet wird. Details: Webhooks.

Rate Limiting

Vier Ebenen: DDoS- und Bot-Schutz im Edge-Netzwerk, Limits pro IP am Reverse Proxy, Token-Buckets pro Konto und pro Identität am API-Gateway sowie fachliche Limits innerhalb der Dienste. Die Limits stehen im API-Überblick.

Audit

Jede Änderung wird in ein nur anfügbares, hashverkettetes Audit-Log mit zwei Aufbewahrungsklassen geschrieben: allgemeine Ereignisse und Compliance-Ereignisse (Betroffenenanfragen, Datenschutzverletzungen, Unterauftragsverarbeiter und KYC-Einträge). Die Klasse wird beim Schreiben eines Eintrags festgelegt; das Log kann von niemandem bearbeitet oder gelöscht werden, und eine automatische Bereinigung nach Klassen ist noch nicht in Betrieb. Inhaber und Administratoren können es filtern und exportieren. Passwörter, Token und Schlüssel werden nie protokolliert; die Protokollierungsschicht schwärzt bekannte sensible Schlüssel.

Datenschutz

• Betroffenenanfragen nach DSGVO, UK-DSGVO, CCPA und LGPD (Auskunft, Export, Löschung) werden in der Compliance-Konsole mit Fristen entgegengenommen und nachverfolgt. Die Löschung führen RolChat-Mitarbeitende durch, und die Anfrage wird erst geschlossen, wenn diese sie bestätigen; eine automatische Löschung über alle Module hinweg gibt es noch nicht.
• Datenresidenz: Die Daten werden in der EU gespeichert. Die Region wird bei der Registrierung nicht nach Land gewählt; die Regionseinstellung in den Kontoeinstellungen wird nur erfasst und verschiebt noch keine Daten.
• Aufbewahrung nach Tarif: 1, 2 oder 3 Jahre. Das Löschen einer Konversation oder eines Kontakts blendet sie nur bis zum Ende dieser Frist aus; das Löschen eines Kontos ist eine Anfrage mit 30 Tagen Bedenkzeit zum Widerruf, danach löschen Mitarbeitende die Daten; ein nicht bezahltes Konto wird 90 Tage aufbewahrt und dann gelöscht. Die automatische Bereinigung, die diese Fristen durchsetzt, wird gerade eingeführt.
• Ein Auftragsverarbeitungsvertrag, die Liste der Unterauftragsverarbeiter, die Datenschutzrichtlinie und die Cookie-Richtlinie sind auf rolchat.com veröffentlicht; der Auftragsverarbeitungsvertrag wird bei der Registrierung akzeptiert.
• Meldung von Datenschutzverletzungen innerhalb von 72 Stunden gemäß Artikel 33 DSGVO.

Schwachstellenmanagement

Abhängigkeiten werden laufend überwacht; Lock-Dateien werden eingecheckt; Basis-Images sind per Digest fixiert; CI-Actions sind per Commit fixiert. Ab der Beta ist jährlich ein Penetrationstest durch Dritte angesetzt, der die API, das Widget und die öffentlichen Seiten abdeckt, dazu ein internes Szenario mit angenommenem Einbruch. Mit der allgemeinen Verfügbarkeit folgt ein privates Bug-Bounty-Programm. Melden Sie Sicherheitsprobleme an security@rolchat.com.

Verfügbarkeit

Die Plattform läuft auf mehreren Knoten mit automatischem Failover für zustandslose Dienste und verwalteter Replikation für Datenbanken. Die Verfügbarkeitsziele pro Tarif sind in Ihrem Vertrag festgelegt.

Reaktion auf Sicherheitsvorfälle

Runbooks für jeden Dienst, eine Rufbereitschaft, ein externer Pager, der auch funktioniert, wenn unsere eigene Infrastruktur ausfällt, und Pflichten zur Benachrichtigung von Kunden, die fest im Prozess verankert sind.