Wie Spun deine Daten verschlüsselt, von der WhatsApp-Verschlüsselung bis zu Gruppenanrufen
Ehrliche Details, Szenario für Szenario, zur WhatsApp-Verschlüsselung, zu Anrufen und zu gespeicherten Daten: was Ende-zu-Ende verschlüsselt ist, was nur bei der Übertragung verschlüsselt ist und was Spun lesen können muss, damit das Produkt funktioniert.
Auf einen Blick
Verschlüsselung nach Szenario
Hier findest du jede Art von Daten, mit der Spun arbeitet, und wie genau sie geschützt ist. Wir markieren E2EE nur dann mit Ja, wenn kein System von Spun den Inhalt lesen kann.
| Szenario | E2EE | Hinweise |
|---|---|---|
1:1-Sprachanruf (Spun → Spun) DTLS-SRTP (WebRTC) | Ja | Reines Peer-to-Peer-WebRTC. Die Schlüssel werden zwischen den beiden Endpunkten ausgehandelt, Spun besitzt sie nie. |
1:1-Videoanruf (Spun → Spun) DTLS-SRTP (WebRTC) | Ja | Wie bei Sprachanrufen. TURN-Relays sehen nur verschlüsselte Pakete, wenn eine direkte P2P-Verbindung fehlschlägt. |
Gruppenanruf (3 oder mehr Teilnehmende) TLS 1.2+ zur SFU, DTLS-SRTP für Medien | Nein | Die SFU von LiveKit Cloud entschlüsselt die Medien, um sie an die anderen Teilnehmenden weiterzuleiten. Das ist die Standardarchitektur einer SFU. |
Übersetzungsraum (P2P-Modus, höchstens 2 Teilnehmende) DTLS-SRTP (WebRTC) | Ja | Wechselt zur SFU, wenn eine dritte Person beitritt (siehe Zeile oben). |
Übersetzungsraum (SFU-Modus, 3 oder mehr Teilnehmende) TLS 1.2+ zur SFU | Nein | Die SFU von LiveKit hat Zugriff auf die Medien, um sie zu übersetzen und neu abzumischen. |
WhatsApp-Nachrichten (innerhalb von WhatsApp) Signal Protocol (Meta) | Teilweise | WhatsApp selbst ist zwischen den Beteiligten Ende-zu-Ende verschlüsselt. Sobald aber dein Gateway-Anbieter deine eingehenden Nachrichten in deinem Auftrag empfängt, sehen das Gateway und Spun den Klartext. So funktioniert der Posteingang. |
WhatsApp-Nachrichten (in Spun) TLS 1.2+ | Nein | Notwendig für die Anzeige im Posteingang, die Suche, KI-Funktionen und Automatisierungen. |
Spun Chat und Teamnachrichten TLS 1.2+ | Nein | Im Ruhezustand im Klartext, damit Nachrichten durchsuchbar sind und von den KI-Funktionen verarbeitet werden können, die du aktivierst. |
Medienanhänge (Bilder, Videos, Dokumente) TLS 1.2+ (Cloudflare R2 + S3 SigV4) | Nein | R2 verwaltet die Schlüssel. Spun signiert kurzlebige URLs, um den Zugriff je Organisation zu steuern. |
Zahlungskartendaten TLS 1.2+ direkt zu Stripe | Teilweise | Stripe Elements erfasst die Kartendaten direkt im Browser, sie erreichen nie die Server von Spun. Wir erhalten nur eine opake Kunden-ID. |
KI-Prompts und -Ausgaben TLS 1.2+ zum KI-Anbieter | Nein | Werden per TLS an OpenAI, AssemblyAI usw. gesendet. Die Schwärzung personenbezogener Daten entfernt (wenn aktiviert) sensible Felder vor der Übertragung. |
Datenbank-Backups TLS 1.2+ | Nein | Standardverschlüsselung für verwaltete Backups. |
E2EE = Ende-zu-Ende verschlüsselt. „Ja“ bedeutet, dass selbst Spun die Daten nicht lesen kann. „Teilweise“ bedeutet Ende-zu-Ende verschlüsselt innerhalb eines Drittanbieters (Stripe, WhatsApp), aber für Spun sichtbar, soweit wir die Daten verarbeiten.
Bei der Übertragung
Alles, was zwischen deinem Browser, unseren Servern und unseren Unterauftragsverarbeitern übertragen wird, ist per TLS verschlüsselt.
TLS 1.2+ auf jeder Verbindung
Der gesamte Datenverkehr Browser ↔ Spun, Spun ↔ WhatsApp-Gateway, Spun ↔ OpenAI / AssemblyAI / Deepgram / Sarvam / Azure und Spun ↔ Stripe ist per TLS verschlüsselt. Ältere Protokollversionen sind am Load Balancer deaktiviert.
Cloudflare als vorgelagerte Edge
Cloudflare terminiert TLS an der Edge und verschlüsselt die Verbindung zum Ursprungsserver erneut. Origin-Zertifikate binden die Anfragen an unsere Hetzner-Server. WAF und DDoS-Schutz sind immer aktiv.
Kurzlebige signierte URLs
Mediendownloads verwenden vorsignierte S3-SigV4-URLs, die auf ein einzelnes Objekt beschränkt sind und eine feste Ablaufzeit haben. Selbst eine nach außen gelangte URL funktioniert nach ihrem Ablauf nicht mehr.
Im Ruhezustand
Gespeicherte Daten sind per Row-Level-Security von PostgreSQL je Organisation isoliert, und Medien sind nur über signierte, auf ein einzelnes Objekt beschränkte URLs erreichbar.
PostgreSQL mit Row-Level-Security
Jede Tabelle mit Mandantendaten hat Richtlinien für die Row-Level-Security (RLS) von PostgreSQL, die die Mandantentrennung zwischen Organisationen durchsetzen. Selbst eine Abfrage, der versehentlich ein Organisationsfilter fehlt, wird auf Datenbankebene abgewiesen.
Zuerst Deutschland, dazu eine Zelle in den USA
Die primäre Zelle - Control Plane (Steuerungsebene), Anwendungsserver, PostgreSQL und Redis - läuft bei Hetzner in Nürnberg (Deutschland, EU). Eine zweite Zelle läuft in Manassas, Virginia. Jede Organisation ist genau einer Zelle zugeordnet, und jede neue Organisation wird in der EU-Zelle angelegt.
Cloudflare R2 für Medien
Bilder, Videos, Audiodateien und Dokumente werden in Cloudflare R2 gespeichert. Der Zugriff erfolgt nie über eine öffentliche Bucket-Adresse, sondern nur über eine signierte URL, die auf ein einzelnes Objekt beschränkt ist.
Sprach- und Videoanrufe
Was echtes E2EE ist, was nicht, und warum. Wir bewerben Gruppenanrufe nicht als Ende-zu-Ende verschlüsselt, weil sie es nicht sind.
1:1-Sprache und -Video: echtes E2EE
Wenn sich zwei Spun-Nutzer gegenseitig anrufen, werden Audio und Video mit DTLS-SRTP Ende-zu-Ende zwischen den beiden Browsern verschlüsselt. Der Server von Spun leitet nur die SDP-Signalisierung weiter. Selbst wenn Cloudflare TURN als Relay einspringen muss (symmetrische NATs, Firewalls), sieht es nur verschlüsselte Pakete.
Gruppenanrufe (3 oder mehr): bei der Übertragung verschlüsselt, nicht E2EE
Gruppenanrufe mit Audio oder Video und Übersetzungsräume mit mehreren Teilnehmenden nutzen LiveKit Cloud als SFU (Selective Forwarding Unit). Die Medien werden zwischen jedem Client und der SFU mit DTLS-SRTP verschlüsselt, doch die SFU entschlüsselt sie beim Empfang, um sie an die anderen Teilnehmenden weiterzuleiten. Das ist die Standardarchitektur einer SFU und nicht Ende-zu-Ende verschlüsselt.
Übersetzungsräume: wenn möglich zuerst P2P
Übersetzungsräume versuchen zuerst P2P (E2EE), solange nur zwei Teilnehmende anwesend sind, und wechseln zur SFU, wenn eine dritte Person beitritt oder die Geräte für P2P zu eingeschränkt sind. Der Verbindungsmodus ist in der Anrufoberfläche sichtbar.
Warum wir für Gruppenanrufe kein vollständiges E2EE behaupten
LiveKit unterstützt einen optionalen Modus für Ende-zu-Ende-Verschlüsselung (über die Encoded Insertable Streams API), der die Medien sogar vor der SFU schützt. Er ist für Gruppenanrufe in Spun derzeit nicht aktiviert: Dafür braucht es einen Mechanismus für den Schlüsselaustausch zwischen den Teilnehmenden und eine geprüfte Browser- und Codec-Kompatibilität für jeden unterstützten Client.
Wenn E2EE für ganze Gruppenanrufe für dich eine Anforderung ist, schreib uns an [email protected]: Es steht auf der Roadmap, und wir teilen dir den aktuellen Stand mit.
Zahlungen und Identität
Die sensibelsten Daten werden von spezialisierten Dienstleistern verarbeitet, sodass Spun sie nie sieht oder speichert.
Kartendaten gehen direkt an Stripe
Stripe Elements erfasst Kartennummern, CVCs und Ablaufdaten in einem iframe, das sie direkt an Stripe sendet und die Server von Spun vollständig umgeht. Wir erhalten nur eine opake Kunden- bzw. Zahlungsmethoden-ID. Stripe ist nach PCI-DSS Level 1 zertifiziert.
Passwörter werden mit Argon2 gehasht
Konten mit E-Mail und Passwort verwenden Argon2id mit einem eigenen Salt pro Nutzer. Wir speichern oder protokollieren keine Passwörter im Klartext. Bei der Anmeldung mit Google wird die Authentifizierung vollständig an Google übergeben: Für diese Konten existiert in Spun nie ein Passwort.
API-Schlüssel und Webhooks signiert
Alle Webhook-Payloads von Drittanbietern (WhatsApp, Stripe, Webhooks von Erweiterungen) sind mit HMAC-SHA256 signiert und werden serverseitig geprüft. API-Tokens für Erweiterungen sind kurzlebige JWTs (RS256) mit einem veröffentlichten JWKS-Endpunkt.
WhatsApp-Nachrichten: die Grenzen von E2EE
Das E2EE von WhatsApp schützt Nachrichten, solange sie sich in der Infrastruktur von WhatsApp befinden. Sobald dein Gateway-Anbieter eine Nachricht in deinem Auftrag empfängt, sieht das Gateway den Klartext. Das gilt für jeden Anbieter der WhatsApp Business API: So funktionieren geschäftliche Posteingänge.
Weitere Fragen?
Für konkrete technische Details (Cipher Suites, Zertifizierungsstellen, Richtlinie zur Schlüsselrotation usw.) oder um die Beantwortung eines Sicherheitsfragebogens anzufragen, schreib an [email protected].