Sicherheit und Datenschutz

Gespräche werden über WebRTC aufgebaut. WebRTC stellt Verschlüsselung nicht zur Wahl: Medien werden als SRTP mit Schlüsseln aus einem DTLS-Handshake übertragen. Ein unverschlüsselter WebRTC-Medienstrom lässt sich vom Browser gar nicht erst aufbauen.

• Die Schlüssel entstehen zwischen den beiden Browsern. Der Signalisierungsserver sieht kein Schlüsselmaterial.
• Wenn eine direkte (P2P-)Verbindung zustande kommt, berühren die Medien unsere Server nie.
• Es gibt keinen serverseitigen Medien-Mixer (SFU/MCU); der Strom wird nicht entschlüsselt und neu verschlüsselt.
• Es gibt KEINE Gesprächsaufzeichnung: weder browser- noch serverseitig ist eine Aufzeichnung in der Anwendung vorhanden, und für Medien ist kein Speicher definiert.
• Die Live-Verbindungsstatistik im Mitarbeiterpanel wird aus dem Bericht des Browsers selbst (RTCStatsReport) gelesen, und die verwendete Verschlüsselung ist während des gesamten Gesprächs sichtbar — das ist die Messung des Browsers, nicht unsere Behauptung.

Hinter symmetrischem NAT oder einer Unternehmens-Firewall ist eine direkte Verbindung nicht immer möglich. Dann werden die Medien über einen TURN-Server weitergeleitet.

• Das Relay KANN den Inhalt nicht öffnen: Da die DTLS-Schlüssel an den Endpunkten bleiben, leitet TURN nur verschlüsselte Pakete weiter.
• Der TURN-Server (coturn) läuft in unserer eigenen Infrastruktur; Medien werden keinem Relay-Dienst Dritter übergeben.
• TURN-Zugangsdaten sind nicht statisch: Sie werden pro Anfrage mit einem HMAC erzeugt und verfallen nach etwa 6 Stunden. Das gemeinsame Geheimnis bleibt auf dem Server und wird nie an den Client gesendet.
• Das Weiterleiten in private Netzbereiche (10/8, 172.16/12, 192.168/16, 169.254/16, 127/8) ist gesperrt — TURN lässt sich nicht in einen Proxy ins interne Netz verwandeln.
• Nutzer- und Gesamtkontingente für Sitzungen, eine Bandbreitenobergrenze und Nonce-Erneuerung sind aktiv; die Verwaltungsschnittstelle (CLI) ist deaktiviert.

Der Browser braucht STUN, um seine eigene öffentliche IP und Port zu erfahren. Diese Abfrage geht an unseren eigenen Server; beim Gesprächsaufbau geht keine Anfrage an einen Drittanbieter.

STUN dient nur der Adressermittlung: Es transportiert weder Medien noch Chat noch personenbezogene Daten. Früher wurden hier öffentliche Server Dritter genutzt; sie wurden entfernt, weil es möglich war.

• Der gesamte Signalisierungsverkehr läuft über TLS (HTTPS und WSS); der WebSocket-Server (Laravel Reverb) ist nicht direkt im Internet exponiert, sondern steht hinter einem TLS-terminierenden Reverse-Proxy.
• Verbindungsbeschreibungen (SDP) werden mit dem Sitzungsdatensatz gespeichert, damit die mobile App ein abgebrochenes Gespräch wiederherstellen kann. SDP enthält in der ICE-Kandidatenliste die lokalen und öffentlichen IP-Adressen beider Seiten; es unterliegt daher der IP-Aufbewahrungsfrist und wird zusammen mit der IP automatisch bereinigt.
• Besuchersitzungen werden mit einem nicht erratbaren Token authentifiziert; Signalisierungskanäle sind sitzungsspezifisch.

Der Ausdruck „Ende-zu-Ende verschlüsselt“ auf der Website bezieht sich auf Audio und Video. Das Folgende läuft über den Server, wird dort gespeichert und ist für uns lesbar — das müssen wir klar sagen:

• Chat-Nachrichten liegen als Klartext in der Datenbank (sie werden auf Anwendungsebene nicht zusätzlich verschlüsselt).
• Geteilte Dateien werden auf eine private Festplatte außerhalb des Web-Roots geschrieben; der Download funktioniert nur über einen signierten Link mit 30 Minuten Gültigkeit und danach nicht mehr.
• Umfrageantworten, Name/E-Mail/Telefon der Besucher und die Gesprächsdauer werden erfasst; das Kundenunternehmen sieht in seinem Panel die Daten der eigenen Räume.

Die Fristen stammen aus derselben Quelle wie die in den Rechtstexten erklärten; sie werden nicht in diese Seite getippt. Die Spalte „Wie“ nennt den geplanten Job, der die Löschung tatsächlich ausführt.

• Passwörter werden mit bcrypt gehasht; es wird nirgends ein Klartextpasswort gespeichert und niemand, auch nicht der Support, kann eines lesen.
• Zwei-Faktor-Authentifizierung (TOTP + Wiederherstellungscodes) kann für jedes Konto aktiviert werden; die Aktivierung erfordert eine Passwortbestätigung.
• Anmeldeversuche sind auf fünf Anfragen pro Minute je E-Mail und IP begrenzt.
• Berechtigungen sind rollenbasiert (Super-Admin / Admin / Mitarbeiter / Personal); Daten der Kundenunternehmen werden über die Organisations-ID getrennt und die Berechtigung wird bei jeder Anfrage geprüft.
• Das Sitzungscookie ist HttpOnly und SameSite-beschränkt und wird in der Produktion nur über HTTPS gesendet; eine inaktive Sitzung endet nach 120 Minuten.
• Administrative Vorgänge (wer, was, wann, Schweregrad) werden in die Systemhistorie geschrieben.

• Der gesamte Verkehr läuft über TLS; HSTS ist für ein Jahr aktiv und umfasst Subdomains.
• Antwort-Header: Content-Type-Sniffing deaktiviert (nosniff), Referrer eingeschränkt (strict-origin-when-cross-origin), Kamera-/Mikrofon-/Bildschirmfreigabe-Berechtigungen ausdrücklich definiert.
• Panel-Seiten lassen sich nur im eigenen Origin einbetten. Das Support-Gesprächs-Widget ist dagegen BEWUSST auf jeder Website einbettbar — die Einbindung in die Kundenwebsite verlangt das; deshalb ist das Widget separat und eng abgegrenzt.
• Bei Formularvorgängen greift CSRF-Schutz, bei öffentlichen Endpunkten eine Ratenbegrenzung.

Die aktuelle Liste der Unterauftragsverarbeiter, ihre Zwecke und Standorte stehen als Tabelle im Auftragsverarbeitungsvertrag; vor Aufnahme eines neuen Unterauftragsverarbeiters wird das Kundenunternehmen 30 Tage vorher informiert. Ein Teil unserer Serverinfrastruktur befindet sich in der Europäischen Union; die Verarbeitung in diesem Rahmen unterliegt den Vorschriften des KVKK zur Auslandsübermittlung.

Tabelle der Unterauftragsverarbeiter ansehen

Das ist der nützlichste Teil einer Sicherheitsseite. Folgendes behaupten wir nicht:

• Keine ISO-27001- oder SOC-2-Zertifizierung.
• Kein unabhängiger Penetrationstestbericht Dritter.
• Keine veröffentlichte Verfügbarkeitszusage und kein Standard-SLA; das wird im Unternehmensvertrag gesondert verhandelt.
• Kein vergütetes Programm zur Schwachstellenmeldung (Bug Bounty).
• Keine Ende-zu-Ende-Verschlüsselung für Chat und Dateien (oben im Detail).

Wenn Sie eine Schwachstelle gefunden haben, schreiben Sie uns bitte, bevor Sie sie veröffentlichen. Es genügt, im Kontaktformular das Thema „Schwachstellenmeldung“ zu wählen; wir antworten spätestens innerhalb von fünf Werktagen.

Maschinenlesbare Kontaktdaten werden unter /.well-known/security.txt veröffentlicht.

• Veri İşleme Sözleşmesi
• Aydınlatma Metni (KVKK)
• Gizlilik Politikası

Wenn Ihr Sicherheitsteam eine Fragenliste hat, beantworten wir sie direkt; zu Architektur, Datenfluss und Berechtigungen antworten wir schriftlich. Unternehmensgespräch starten