Datenverschlüsselung im Unternehmen: Leitfaden für Kundenchats

Jede WhatsApp-Bestellung, jede Instagram-DM und jeder Telegram-Support-Chat hinterlässt Kundendaten: Telefonnummern, Lieferadressen, Chatverläufe und die Zugangstokens, die Ihre Kanäle verbinden. Datenverschlüsselung im Unternehmen verwandelt diese Daten in Geheimtext, den ohne Schlüssel niemand lesen kann, während sie durch Netzwerke wandern und während sie in Datenbanken und Backups liegen.

Kernaussagen

Datenverschlüsselung im Unternehmen hat zwei Ebenen: Die Transportverschlüsselung (TLS) schützt Daten in Bewegung, die Verschlüsselung ruhender Daten (meist AES) schützt gespeicherte Daten.
Kanal-Access-Tokens, API-Schlüssel und Webhook-Secrets sind Zugangsdaten. Ein abgeflossener Token kann Angreifern erlauben, im Namen Ihres Unternehmens zu handeln; verschlüsseln Sie ihn deshalb auf Feldebene.
Festplattenverschlüsselung schützt eine gestohlene Festplatte, nicht einen laufenden Server. Feldbasierte Verschlüsselung mit Schlüsseln außerhalb der Datenbank schützt diese Felder auch in einem abgeflossenen Dump.
AES-256-GCM ist authentifizierte Verschlüsselung: Sie verbirgt Daten und erkennt Manipulationen, und sie setzt voraus, dass eine Nonce nie mit demselben Schlüssel wiederverwendet wird.
Verschlüsselung hält niemanden auf, der entschlüsseln darf. Eine KI-Plattform für automatische Antworten muss Nachrichten lesen, um sie zu beantworten; Zugriffskontrolle und Aufbewahrung wiegen deshalb so schwer wie das gewählte Verfahren.

Was Datenverschlüsselung im Unternehmen in einem Chat-Betrieb abdecken muss

Ein Unternehmen, das über Chat verkauft, zum Beispiel über einen KI-Posteingang für WhatsApp, hat sein eigenes Dateninventar:

Zugangsdaten und Secrets. Access Tokens für Facebook-Seiten und WhatsApp Business, Telegram-Bot-Tokens, Schlüssel von KI-Anbietern, Schlüssel von Zahlungsanbietern und Webhook-Secrets.
Personenbezogene Kundendaten. Telefonnummern, E-Mail-Adressen, Lieferadressen und Kundennummern. Im Chat-Commerce ist die Telefonnummer oft die Identität der Kundin oder des Kunden.
Chatverläufe und Medien. Transkripte, Sprachnachrichten, Fotos und Rechnungen, die Kundinnen und Kunden schicken.
Passwörter der Mitarbeitenden. Diese gehören gehasht, nicht verschlüsselt (dazu unten mehr).
Geräte der Mitarbeitenden. Notebooks und Telefone, die den Posteingang öffnen oder Exporte enthalten. Aktivieren Sie FileVault oder BitLocker, Gerätesperren und Fernlöschung.
Kopien. Backups, CSV-Exporte, Logs und Staging-Datenbanken, die oft schlechter geschützt sind als die Produktion.

Eine einfache Regel, um Kundendaten zu verschlüsseln: Schützen Sie auf Feldebene alles, was Zugang gewährt oder eine Person identifiziert, und geben Sie jeder Kopie denselben Schutz wie dem Original.

Verschlüsselung ruhender Daten vs. Transportverschlüsselung

Transportverschlüsselung schützt Daten, während sie zwischen Browser, Ihrem Server und Drittanbieter-APIs unterwegs sind. Verschlüsselung ruhender Daten schützt Daten, die auf Festplatten, in Datenbanken und in Backups gespeichert sind.

Aspekt	Transportverschlüsselung	Verschlüsselung ruhender Daten
Schützt vor	Mitlesen, Manipulation, gefälschten Servern	Gestohlenen Festplatten, abgeflossenen Dumps, offenen Backups
Üblicher Standard	TLS 1.2 oder TLS 1.3	AES-256, oft AES-256-GCM
Wo sie greift	Browser zur Anwendung, Webhooks, API-Aufrufe	Festplatte, Datenbank, einzelne Felder, Backups
Deckt nicht ab	Daten nach der Ankunft und Entschlüsselung	Daten, die eine laufende Anwendung gerade verarbeitet

NIST SP 800-52 Rev. 2 verlangt von TLS-Servern der US-Bundesbehörden die Unterstützung von TLS 1.2 und bis Januar 2024 auch die von TLS 1.3. Das ist eine sinnvolle Grundlinie für jedes Unternehmen: TLS 1.2 und 1.3 zulassen, alles Ältere abschalten.

TLS schützt nur den Transportweg. Die WhatsApp Cloud API stellt Webhooks über HTTPS zu, und Metas Dokumentation erklärt, dass die Cloud API eingehende Nachrichten entschlüsselt und an das Unternehmen weiterleitet; aufbewahrt werden sie höchstens 30 Tage. Danach übernehmen Speicherung und Zugriffskontrollen.

Festplatten-, Datenbank- und feldbasierte Verschlüsselung

Die Verschlüsselung ruhender Daten gibt es in mehreren Schichten:

Festplatten- oder Volume-Verschlüsselung schützt eine gestohlene oder ausgemusterte Festplatte. Solange der Server läuft, entschlüsselt das Betriebssystem automatisch; wer also im Server sitzt, sieht Klartext.
Verschlüsselung der Datenbankdateien hat dieselbe Grenze: Wer die Datenbank abfragen darf, bekommt Klartext zurück.
Feldbasierte Verschlüsselung verschlüsselt einzelne Spalten, etwa einen Token oder eine Telefonnummer, bereits in der Anwendung, bevor sie in die Datenbank gelangen. Der Schlüssel liegt woanders, deshalb zeigt ein abgeflossener Dump oder ein kopiertes Backup für diese Felder nur Geheimtext.

Der Preis dafür ist die Suche: Auf einer verschlüsselten Spalte lässt sich kein normaler SQL-Filter ausführen. Praktikabel ist, die feldbasierte Verschlüsselung auf Secrets und besonders heikle Kontaktdaten zu beschränken. Teams, die Kundinnen und Kunden über Telefonnummer oder E-Mail finden müssen, können neben dem Geheimtext einen mit Schlüssel gebildeten Hash (einen Blind Index) speichern und darüber suchen.

AES-256-GCM: Schlüssellänge und Betriebsmodus

AES ist in FIPS 197 mit Schlüsseln von 128, 192 und 256 Bit definiert. AES-256 nutzt den längsten der drei.

Der Modus zählt genauso viel wie die Schlüssellänge. GCM (NIST SP 800-38D) ist authentifizierte Verschlüsselung: Es hält Daten vertraulich und erkennt, ob jemand den Geheimtext verändert hat. Verwenden Sie eine Nonce nie erneut mit demselben Schlüssel: Nonce-Wiederverwendung zerstört die Garantien von GCM. Lassen Sie deshalb eine gepflegte Bibliothek die Nonces erzeugen, und schreiben Sie niemals eigene Kryptografie.

Wie Sie API-Schlüssel und Access Tokens sicher speichern

Entscheiden Sie danach, ob Sie den Originalwert zurückbrauchen:

Verschlüsseln Sie Secrets, die Sie an andere senden müssen: Access Tokens für WhatsApp und Instagram, Telegram-Bot-Tokens, Schlüssel von KI-Anbietern und Zahlungsschlüssel. Nutzen Sie feldbasiertes AES-GCM mit einem Schlüssel außerhalb der Datenbank.
Hashen Sie Secrets, die Sie nur prüfen: Passwörter, Partner-API-Schlüssel und Einmalcodes. Ein Hash lässt sich nicht in den Originalwert zurückrechnen, kurze oder erratbare Werte aber durchprobieren; nehmen Sie deshalb für Passwörter ein langsames Verfahren wie Argon2id oder bcrypt und für Codes einen HMAC mit Schlüssel.
Halten Sie sie aus Logs heraus, ebenso aus Fehlermeldungen, Analysedaten und URLs.
Rechte eng fassen und rotieren. Fordern Sie nur die Berechtigungen an, die ein Token braucht, und tauschen Sie Tokens aus, wenn jemand mit Zugriff geht.

Die Verschlüsselung ruhender Daten schützt einen Token nicht, während er für einen API-Aufruf entschlüsselt im Arbeitsspeicher liegt. Server-Härtung und Least Privilege senken dieses Risiko.

Grundlagen der Schlüsselverwaltung

Verschlüsselung ist nur so stark wie der Ort, an dem der Schlüssel liegt. Der klassische Fehler ist ein Schlüssel direkt neben den Daten, in derselben Datenbank oder in einer eingecheckten Konfigurationsdatei.

Schlüssel von Daten trennen. Bewahren Sie Schlüssel in einem Secrets Manager, einem KMS oder in einer Serverkonfiguration auf, die die Datenbank nicht erreicht.
Nutzen Sie Envelope-Verschlüsselung, wenn es größer wird. Ein Hauptschlüssel verschlüsselt Datenschlüssel, seine Rotation bedeutet also nicht, alles neu zu verschlüsseln.
Leiten Sie zweckgebundene Schlüssel ab, mit einer Schlüsselableitungsfunktion wie HKDF.
Planen Sie Rotation und Wiederherstellung. Ein verlorener Schlüssel bedeutet verlorene Daten, auch in Backups.

Zugriffskontrolle und Least Privilege: Verschlüsselung allein genügt nicht

Verschlüsselung stoppt Menschen ohne Schlüssel, nicht Menschen oder Systeme, die entschlüsseln dürfen. Eine KI-Plattform für automatische Antworten muss die Nachricht einer Kundin lesen, um eine Antwort zu schreiben, ihre Server verarbeiten also lesbare Nachrichten.

Dieselbe Logik gilt weiter oben in der Kette. WhatsApps Security-Whitepaper betrachtet Chats mit Unternehmen, die die Cloud API nutzen, nicht als Ende-zu-Ende-verschlüsselt, weil die Nachrichten nicht direkt an einen Endpunkt zugestellt werden, den das Unternehmen kontrolliert. Lesen Sie WhatsApp Business Cloud API vs. Business App, bevor Sie sich für ein Setup entscheiden.

Die nächste Schicht dreht sich also darum, wer an die Daten kommt:

Zugriffskontrolle nach Least Privilege: Geben Sie jedem im Team die kleinste Rolle, die ausreicht. Wer Chats beantwortet, braucht keinen Zugriff auf die Abrechnung.
Starke Anmeldung: Ergänzen Sie einen zweiten Prüfschritt und beenden Sie Sitzungen beim Abmelden.
Mandantentrennung: Jede Anfrage sollte nachweisen, dass der Aufrufer zu diesem Unternehmen gehört.
Audit-Logs und Aufbewahrung: Protokollieren Sie privilegierte Aktionen und bewahren Sie Chatverläufe nur so lange auf, wie Sie sie brauchen.

Backups, Exporte und Aufbewahrung

Backups sind vollständige Kopien von Kundendaten, oft länger aufbewahrt und weniger beobachtet als die Produktion. Verschlüsseln Sie Backup-Dateien, beschränken Sie, wer sie herunterladen darf, testen Sie Wiederherstellungen einschließlich der Schlüsselrückgewinnung, und löschen Sie alte CSV-Exporte, die per E-Mail oder Chat geteilt wurden.

Verschlüsselung hat auch rechtliches Gewicht. Art. 32 DSGVO nennt Verschlüsselung als Sicherheitsmaßnahme, und nach Art. 34 Abs. 3 Buchst. a darf ein Verantwortlicher die Benachrichtigung betroffener Personen über eine Verletzung unterlassen, wenn Verschlüsselung die Daten für Unbefugte unverständlich gemacht hat. Die Pflicht aus Art. 33, die Aufsichtsbehörde binnen 72 Stunden nach Kenntnis einer Verletzung zu informieren, besteht davon unabhängig. Auch das PDPL in Saudi-Arabien und das KVKK in der Türkei setzen 72-Stunden-Fristen gegenüber der Behörde.

Das sind allgemeine Informationen, keine Rechtsberatung. Ob die DSGVO oder ein anderes Gesetz gilt und ob eine Ausnahme auf einen konkreten Vorfall passt, hängt von Ihrer Situation ab, ziehen Sie deshalb eine qualifizierte Anwältin oder einen qualifizierten Anwalt hinzu.

Fragen an jeden Chat- oder CRM-Anbieter

Bevor Sie Ihre Kanäle verbinden, nutzen Sie diese Sicherheitsfragen an Chatbot-Anbieter als schriftlichen Fragebogen:

Welche TLS-Versionen akzeptieren Ihre Endpunkte?
Welche Daten sind im Ruhezustand verschlüsselt, und auf welcher Ebene? Gehören Nachrichteninhalte dazu?
Sind Kanal-Tokens und API-Schlüssel auf Feldebene verschlüsselt, und wo liegt der Schlüssel?
Sind Backups verschlüsselt, und wer hat Zugriff darauf?
Können Ihre Mitarbeitenden unsere Konversationen lesen, und wird dieser Zugriff protokolliert?
Welche Rollen und Berechtigungen können wir für unser Team festlegen?
Wie sind unsere Daten von denen anderer Kunden getrennt?
Werden unsere Chats zum Training von KI-Modellen genutzt, von Ihnen oder Ihren KI-Anbietern?
Wer sind Ihre Unterauftragsverarbeiter, und wo werden die Daten gespeichert?
Unterzeichnen Sie einen AVV (DPA), und wie schnell werden Daten nach unserem Weggang gelöscht?

Seien Sie skeptisch bei Antworten wie „Verschlüsselung auf Militärniveau“ oder „alle Daten vollständig verschlüsselt“. Ein vertrauenswürdiger Anbieter nennt das Verfahren, die Ebene und die Lücken.

Was Raabt heute verschlüsselt und schützt

Jeder Punkt unten entspricht dem Stand von Raabts Code im September 2026.

Feldbasierte Verschlüsselung: Sensible Felder werden auf Anwendungsebene mit AES-256-GCM verschlüsselt. Neue Schreibvorgänge nutzen einen über HKDF-SHA256 abgeleiteten Schlüssel, ältere Werte werden damit beim nächsten Speichern neu verschlüsselt. Die Anwendung startet nicht ohne einen Schlüssel mit mindestens 32 Zeichen.
Was verschlüsselt wird: Zugangsdaten und Tokens (Kanal-Access-Tokens für Facebook, Instagram, WhatsApp und Telegram, API-Schlüssel von KI- und Zahlungsanbietern, Webhook-Secrets) sowie ausgewählte Kontaktdaten (Telefonnummern, E-Mail-Adressen und Lieferadressen von Kundinnen und Kunden).
Hashing: Passwörter nutzen Argon2id (19 MiB Speicher, 2 Iterationen), ältere bcrypt-Hashes werden bei der Anmeldung aktualisiert. Secrets von Partner-API-Schlüsseln werden ausschließlich als SHA-256-Hashes gespeichert.
Anmeldung: Anmeldungen mit E-Mail und Passwort verlangen einen Einmalcode an die E-Mail-Adresse der Nutzerin oder des Nutzers, bevor eine Sitzung ausgestellt wird (die Google-Anmeldung nutzt diesen Code nicht). Codes werden ausschließlich als HMAC-SHA256-Hashes gespeichert, laufen ab und funktionieren einmal.
Teamzugriff: vier Rollen (Owner, Admin, Agent, Viewer) mit Berechtigungen je Bereich. Der Zugriff auf die Abrechnung lässt sich nicht an Nicht-Owner delegieren.
Trennung: Unternehmens-Endpunkte prüfen, ob der Aufrufer aktives Mitglied dieses Unternehmens ist, und antworten andernfalls mit „nicht gefunden“.
Webhooks und Medien: Meta-Webhooks werden ohne gültige X-Hub-Signature-256-Signatur abgewiesen, Telegram-Webhooks verlangen ein Secret Token, und Anhänge werden nur über signierte, ablaufende URLs ausgeliefert.
Infrastruktur: Die Anwendung ist nicht direkt aus dem Internet erreichbar, öffentlicher Datenverkehr erreicht sie über einen Cloudflare Tunnel. Datenbank-Fehlerlogs enthalten nie Abfrageparameter, sodass Telefonnummern und E-Mail-Adressen nicht in diesen Logs landen.
Audit-Log für Plattform-Admins: Aktionen von Plattform-Admins werden in ein Append-only-Audit-Log geschrieben (wer, was, wann, IP, mit Vorher-Nachher-Stand und geschwärzten Secrets). Das ist kein Protokoll von Kundennachrichten.

Was Verschlüsselung hier nicht leisten kann: Ein KI-Posteingang muss Nachrichtentext lesen, um eine Antwort zu schreiben, Gesprächsinhalte werden auf dem Server also in lesbarer Form verarbeitet. Genau deshalb wiegen die Punkte oben zu Zugriffskontrolle, Aufbewahrung und Backups so schwer wie das Verfahren, für das Sie sich entscheiden.

Über Metas Callback ausgelöste Löschanfragen erhalten einen Bestätigungscode mit Statuslink auf unserer Seite zur Datenlöschung. Die Kontolöschung verlangt Ihr Passwort plus einen per E-Mail zugesandten Einmalcode, das Konto wird deaktiviert und seine E-Mail-Adresse anonymisiert.

Checkliste zur Datenverschlüsselung im Unternehmen: eine Reihenfolge für kleine Teams

Datenverschlüsselung für kleine Unternehmen funktioniert am besten in einer festen Reihenfolge, beginnend mit dem, was beim Abfluss den größten Schaden anrichtet:

Liefern Sie alles über HTTPS aus, ausschließlich mit TLS 1.2 oder 1.3.
Schalten Sie Festplattenverschlüsselung und Bildschirmsperren auf jedem Gerät ein, das Kundenchats öffnet.
Überführen Sie Tokens und API-Schlüssel in feldbasierte Verschlüsselung mit getrennten Schlüsseln.
Hashen Sie Passwörter mit Argon2id oder bcrypt und ergänzen Sie einen zweiten Anmeldeschritt.
Verschlüsseln Sie Telefonnummern, E-Mail-Adressen und Adressen Ihrer Kundinnen und Kunden.
Verschlüsseln Sie Backups, vergeben Sie Rollen nach Least Privilege und legen Sie Aufbewahrungsfristen für Chats fest.
Schicken Sie die Anbieterfragen an jedes Chat-, CRM- und KI-Tool, das Sie einsetzen.

Häufige Fragen

Welche Daten muss ein Unternehmen verschlüsseln?

Beginnen Sie mit allem, was Zugang gewährt oder eine Person identifiziert: Kanal-Tokens, API-Schlüssel, Webhook-Secrets sowie Telefonnummern, E-Mail-Adressen und Adressen Ihrer Kundschaft. Decken Sie danach Chatverläufe, Geräte der Mitarbeitenden und jedes Backup und jeden Export ab.

Was ist der Unterschied zwischen Transportverschlüsselung und Verschlüsselung ruhender Daten?

Die Transportverschlüsselung, meist TLS, schützt Daten auf dem Weg zwischen Geräten, Servern und APIs. Die Verschlüsselung ruhender Daten, meist AES, schützt gespeicherte Daten.

Reicht AES-256-Verschlüsselung, um Kundendaten zu schützen?

AES-256 ist stark, aber das Verfahren ist selten die Schwachstelle. Häufige Bruchstellen sind schlecht verwahrte Schlüssel, wiederverwendete Nonces, zu breiter Zugriff der Mitarbeitenden und ungeschützte Backups.

Wie speichert man API-Schlüssel und Zugangsdaten sicher?

Verschlüsseln Sie Tokens, die Sie wiederverwenden müssen, feldbasiert mit AES-GCM und halten Sie den Schlüssel außerhalb der Datenbank. Hashen Sie Secrets, die Sie nur prüfen, etwa Passwörter und Partner-API-Schlüssel.

Sind meine Daten auf dem Server geschützt, wenn ich HTTPS nutze?

Nein. HTTPS schützt Daten nur auf dem Transportweg. Auf dem Server hängt die Sicherheit von der Verschlüsselung ruhender Daten, der Zugriffskontrolle und dem Umgang mit Backups ab.

Welche Fragen sollte man einem Chatbot- oder CRM-Anbieter zur Datensicherheit stellen?

Fragen Sie, welche TLS-Versionen akzeptiert werden, was im Ruhezustand auf welcher Ebene verschlüsselt ist, wo die Schlüssel liegen, ob Zugriffe der Mitarbeitenden auf Chats protokolliert werden, wer die Unterauftragsverarbeiter sind und wo Daten gespeichert werden, ob Chats KI-Modelle trainieren und ob ein AVV mit Löschfrist unterzeichnet wird.

Bereit, Ihre Chats über einen KI-Posteingang laufen zu lassen, der Kanal-Tokens und ausgewählte Kontaktdaten Ihrer Kundschaft verschlüsselt? Kostenlos starten.