Sicherheit als Default — nicht als Add-On.

Sämtliche Daten liegen auf Servern in Deutschland — gemietet bei der Hetzner Online GmbH in Falkenstein (Vogtland). Die verschlüsselten Sicherungen gehen an einen externen Speicher der STRATO AG, ebenfalls in Deutschland.

Die Anwendung läuft in getrennten Linux-Containern hinter einem Reverse Proxy. Datenbank und Zwischenspeicher haben keine nach außen veröffentlichten Ports — sie sind ausschließlich aus dem internen Container-Netz erreichbar.

Die KI läuft bei IONOS, mit Verarbeitung in Deutschland; andere KI-Anbieter setzen wir nicht ein. Die Spracherkennung für Sprachnachrichten läuft in einem eigenen Container auf unserer Maschine — Aufnahmen verlassen sie nicht.

Auf dem Transportweg: ausschließlich TLS. HSTS ist gesetzt; die Sicherheits-Kopfzeilen (u. a. Content-Security-Policy und Permissions-Policy) sind Teil der automatisierten Prüfkette und nicht dem Zufall überlassen. Die Restlaufzeit der Zertifikate wird überwacht.

Bei Sicherungen: Datenbank- und Dateisicherungen werden mit age verschlüsselt, bevor sie den Server verlassen. Der private Schlüssel liegt nicht auf der gesicherten Maschine. Die Übertragung erfolgt über SFTP.

Passwörter werden mit Argon2id gehasht und nie im Klartext gespeichert oder protokolliert. Zugangsdaten zu Fremdsystemen (etwa Webhook-Geheimnisse) liegen verschlüsselt in der Datenbank.

Eine Verschlüsselung der Datenträger auf Betriebssystemebene setzen wir derzeit nicht ein. Wir schreiben das hierhin, statt es wegzulassen.

SilentChat ist mandantenfähig. Die Trennung wird in der Datenbankschicht erzwungen und nicht erst in der Oberfläche: Jede Abfrage trägt die Mandantenkennung als Filter, dafür gibt es wiederverwendbare Scopes statt handgeschriebener Bedingungen — auch beim Zugriff über eine Kennung, wo ein nachträglicher Vergleich im Handler die typische Lücke wäre.

Auch der Zwischenspeicher trennt: Schlüssel tragen die Mandantenkennung als Präfix. Die Echtzeit-Verbindungen ebenso — ein Widget hört nur in seinem eigenen Gespräch mit.

Für die Zugriffspfade gibt es eine Abdeckungsprüfung, die vor jeder Auslieferung läuft. Gefundene Lücken sind dokumentiert und behoben, zuletzt ein mandantenübergreifender Schreibzugriff im Produkt-Board am 07.07.2026.

Anmeldung per E-Mail und Passwort, per Einmal-Link ohne Passwort, über Google, oder per SAML 2.0 und OpenID Connect für Unternehmenskunden. Zwei-Faktor-Authentisierung (TOTP) mit Wiederherstellungscodes und der Möglichkeit, einzelne Geräte als vertrauenswürdig zu merken.

Anmeldeversuche sind ratenbegrenzt. Auf den sicherheitskritischen Wegen ist die Bremse fail-closed: Fällt der Zwischenspeicher aus, wird abgewiesen statt durchgewunken — Erreichbarkeit ist dort nicht wichtiger als Missbrauchsschutz.

Innerhalb eines Mandanten gilt ein Rollen- und Rechtemodell mit acht vorgegebenen Rollen und eigenen Rollen ab den größeren Tarifen. Geprüft wird serverseitig; die Oberfläche blendet nur aus. Sitzungen lassen sich zentral widerrufen — ein gesperrtes Konto verliert seinen Zugriff sofort und nicht erst mit Ablauf seines Tokens.

Die Datenbank wird nach Zeitplan gesichert, Dateien einmal täglich. Beide Sicherungen werden verschlüsselt und an einen externen Speicher übertragen.

Aufbewahrung: 30 Tage rollierend — bewusst gleichlaufend mit der Löschfrist aus dem AVV, damit eine Löschung nicht in einer älteren Sicherung überdauert.

Die Wiederherstellung wurde geprobt, nicht nur beschrieben: Am 06.07.2026 wurden Datenbank und Dateien aus der externen Sicherung tatsächlich zurückgespielt.

Kein Point-in-Time-Recovery. Wir archivieren keine Transaktionsprotokolle. Der mögliche Datenverlust entspricht dem Abstand zwischen zwei Sicherungen, nicht Minuten. Das ist eine bewusste Entscheidung; die Abwägung steht im Notfallhandbuch.

Vor jeder Auslieferung läuft eine automatisierte Prüfkette gegen eine echte Datenbank in Containern: Einheiten- und Integrationstests, Oberflächenprüfungen im Browser, dazu eigene Prüfungen für Übersetzungen, Zugriffspfade, Sicherheits-Kopfzeilen und die Registrierung von Datenbank-Migrationen.

Abhängigkeiten werden auf bekannte Schwachstellen geprüft; kritische Meldungen werden sofort behoben und nicht auf ein Wartungsfenster geschoben.

Keine externe Sicherheitsprüfung. Ein Penetrationstest durch Dritte hat bisher nicht stattgefunden. Auch das steht hier, statt zu fehlen.

Für Datenschutzverletzungen gibt es ein schriftliches Vorgehen — von der Feststellung über die Bewertung bis zur Meldung an die Aufsichtsbehörde binnen 72 Stunden (Art. 33 DSGVO) und der Benachrichtigung Betroffener. Ebenso für den Ausfall der Infrastruktur und für aus dem Ruder laufende KI-Kosten.

Meldungen an security@silentchat.de. Wir antworten werktags.

Keine Rufbereitschaft rund um die Uhr. SilentChat wird von einem kleinen Team betrieben; Reaktionszeiten außerhalb der Geschäftszeiten sagen wir nicht zu.

Die Anwendung schreibt strukturierte Protokolle mit begrenzter Aufbewahrung und automatischer Rotation. Personenbezogene Daten gehören nicht hinein — E-Mail-Adressen und Namen werden vor dem Schreiben maskiert; Kennungen statt Klartext ist die Regel.

Ein Zustandsendpunkt weist Datenbank, Zwischenspeicher, Hintergrundarbeiter und Spracherkennung einzeln aus. Jeder KI-Aufruf wird mit Modell, Zweck, Verbrauch und Kosten protokolliert und ist im Verwaltungsbereich einsehbar; Kostenobergrenzen greifen je Mandant und für die gesamte Installation.

Jede administrative Handlung landet im Prüfprotokoll des Mandanten: wer, wann, was, von welcher Adresse.