Technische und organisatorische Maßnahmen.

SilentChat betreibt keine eigene Hardware. Die Anwendung läuft auf gemieteten Servern der Hetzner Online GmbH in Falkenstein (Vogtland); für die physische Sicherung der Rechenzentren gilt deren Zertifizierung und deren Auftragsverarbeitungsvertrag.

Der Zugang zu den Servern erfolgt ausschließlich über SSH mit Schlüsseldatei; Passwort-Anmeldung ist abgeschaltet.

Anmeldung mit E-Mail und Passwort. Passwörter werden mit Argon2id gehasht und nie im Klartext gespeichert oder protokolliert.

Ergänzend: Zwei-Faktor-Authentisierung (TOTP) mit Wiederherstellungscodes, Anmeldung ohne Passwort per Einmal-Link, sowie SAML 2.0 und OpenID Connect für Unternehmenskunden.

Anmeldeversuche sind ratenbegrenzt (5 Versuche je Minute und IP). Sitzungen lassen sich zentral widerrufen — ein gesperrtes Konto verliert seinen Zugriff sofort und nicht erst mit Ablauf des Tokens.

SilentChat ist mandantenfähig. Die Trennung wird in der Datenbankschicht erzwungen, nicht erst in der Oberfläche: Jede Abfrage trägt die Mandantenkennung als Filter, dafür gibt es wiederverwendbare Scopes statt handgeschriebener Bedingungen.

Innerhalb eines Mandanten gilt ein Rollen- und Rechtemodell (Inhaber, Administrator, Agent, weitere), das serverseitig geprüft wird. Die Oberfläche blendet nur aus — sie entscheidet nichts.

Auch der Zwischenspeicher trennt: Schlüssel tragen die Mandantenkennung als Präfix.

Auf dem Transportweg: ausschließlich TLS. Die Zertifikatslaufzeiten werden automatisch überwacht.

Bei Sicherungen: Datenbank- und Dateisicherungen werden vor dem Verlassen des Servers mit age verschlüsselt (moderner Ersatz für GPG). Der private Schlüssel liegt nicht auf dem gesicherten Rechner. Die Übertragung an den externen Speicher erfolgt über SFTP.

Ausgehende Verbindungen: Adressen, die aus Nutzereingaben stammen (etwa beim Einlesen einer Webseite in die Wissensdatenbank), laufen über einen Filter gegen serverseitige Anfragefälschung — interne Netze sind gesperrt.

Jede administrative Handlung wird im Prüfprotokoll des Mandanten festgehalten: wer, wann, was, von welcher Adresse. Das schließt Rollenänderungen, Löschungen, Einladungen und den Wechsel des KI-Anbieters ein.

Auf Anbieterseite wird zusätzlich jeder KI-Aufruf protokolliert — mit Modell, Zweck, Verbrauch und Kosten.

Die Datenbank wird per Zeitplan gesichert, Dateien einmal täglich. Beide Sicherungen werden verschlüsselt und auf 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. Die Ziel- und Wiederanlaufzeiten stehen im Notfallhandbuch.

Daten verschiedener Mandanten liegen in denselben Tabellen, getrennt über die Mandantenkennung (siehe Nr. 3). Zusätzlich sind Testumgebung und Produktivbetrieb vollständig getrennte Installationen mit eigenen Datenbanken.

Einziger KI-Anbieter ist IONOS mit Verarbeitung in Deutschland. Die Spracherkennung für Sprachnachrichten läuft in einem eigenen Container auf unserem Server — Aufnahmen verlassen die Maschine nicht.

Anbieter mit Sitz in den USA sind technisch gesperrt: Die Anwendung bindet sie nicht an, und die Sperre lässt sich nicht über die Verwaltungsoberfläche aufheben.

Für den Ernstfall gibt es einen zentralen Notaus, der sämtliche KI-Aufrufe sofort unterbindet. Zusätzlich greifen Kostenobergrenzen je Mandant und für die gesamte Installation.

Die Anwendung antwortet auf einen Zustandsendpunkt, der Datenbank, Zwischenspeicher, Hintergrundarbeiter und Spracherkennung einzeln ausweist. Verbindungsabbrüche zu Datenbank und Zwischenspeicher werden mit Wiederholungen abgefangen.

Für Wartungsarbeiten gibt es einen Wartungsmodus, der Besuchern eine Meldung zeigt, statt Fehler zu produzieren.

Vor jeder Auslieferung läuft eine automatisierte Prüfkette: Übersetzungen, Zugriffspfade, Sicherheits-Kopfzeilen, Datenbank-Migrationen, Oberflächenprüfungen im Browser sowie Einheiten- und Integrationstests gegen eine echte Datenbank.

Abhängigkeiten werden auf bekannte Schwachstellen geprüft; kritische Meldungen werden sofort behoben.

Diese Angaben gehören zu einer belastbaren Risikoabwägung dazu:

• Keine Wiederherstellung auf einen beliebigen Zeitpunkt (kein WAL-Archiv, kein PITR). Der mögliche Datenverlust entspricht dem Abstand zwischen zwei Sicherungen, nicht Minuten. Bewusste Entscheidung, im Notfallhandbuch begründet.
• Keine Rufbereitschaft rund um die Uhr. SilentChat wird von einem kleinen Team betrieben; Reaktionszeiten außerhalb der Geschäftszeiten sind nicht zugesichert.
• Keine Zertifizierung nach ISO 27001 und kein SOC-2-Bericht.
• Keine getrennte Datenbank je Mandant. Die Trennung erfolgt logisch (Nr. 3 und 7).

Fragen und Prüfungsanfragen an dsb@silentchat.de. Wesentliche Änderungen an dieser Anlage kündigen wir Auftraggebern mindestens 30 Tage vorher an.