Verschlüsselung „at rest“ und „in transit“: Best Practices für Spielerdaten

Ein Abend. Zwei Lücken. Ein iGaming‑Anbieter verliert Kopien seiner Datenbank. Die Backups lagen offen in einem fremden Cloud‑Konto. Am gleichen Tag fängt ein Angreifer Verkehr von einem alten Proxy ab. Das Gateway fiel bei Druck auf TLS 1.0 zurück. Ergebnis: Personalausweise, Adressen, Bonus‑Daten. All das hätte nicht passieren müssen. „At rest“ und „in transit“ sind zwei Fronten. Man muss beide schließen. Sauber. Bezahlbar. Ohne die App zu bremsen.

Drei falsche Sicherheiten, die teuer werden

„Wir nutzen AES‑256 überall, also passt das.“ Nein. Ein starker Baustein in falscher Form hilft wenig. Falsche Modi, keine Rotation, ein Master‑Key für alles: Das ist ein Unfall mit Anlauf. Wer die Empfehlungen zur Krypto‑Stärke liest, sieht schnell: Stärke ist ein Set aus Algorithmus, Modus, Schlüssellänge, Lebenszyklus und Kontext.

„VPN deckt das schon ab.“ Nein. Ein VPN schützt ein Netz. Nicht jede App. Nicht jeden Hop. Sie brauchen TLS 1.3 Ende‑zu‑Ende, intern oft mTLS. Sonst bricht ein schwaches Glied die Kette. „Wir haben ein Zertifikat, also sind wir sicher.“ Ein Zertifikat ist nur ein Pass. Wie Sie damit sprechen (Cipher‑Suite, PFS, OCSP‑Stapling) entscheidet. Das BSI IT‑Grundschutz zu Kryptographie fasst die Basics und die Pflichtarbeit gut zusammen.

Was heißt „at rest“, „in transit“ – und was fehlt dazwischen?

„At rest“: Daten liegen. Datenbank, Backup, Objekt‑Speicher. Beispiel: KYC‑Foto in S3, Konto‑Details in PostgreSQL. „In transit“: Daten fließen. App zum Edge, Edge zum Origin, Service zu Service. Beispiel: Live‑Casino‑Stream plus API‑Calls. Dazwischen fehlt oft „in use“: Daten im RAM, im Prozess, auf der CPU. Hier greifen HSM (Hardware Security Module), KMS (Key Management Service) und Techniken wie Tokenisierung. Schutz im Speicher ist schwerer, aber möglich. Wichtig ist: Plan pro Zustand, nicht ein Tool für alles.

Rechtlicher Blick: Die DSGVO Art. 32 Sicherheitsmaßnahmen fordert Stand der Technik, Risiko‑Bezug und Nachweis. Das schließt Verschlüsselung, Pseudonymisierung und Resilienz ein.

Management‑Blick: Ein System für Informationssicherheit hilft, damit das lebt. Ein guter Start ist der ISO/IEC 27001 Überblick. Er lenkt Rollen, Prozesse, Audit und laufende Checks.

Eine Tabelle, die Entscheidungen trägt

Die folgende Übersicht zeigt nicht „was“, sondern „wann, wie und womit“. Nutzen Sie sie als Drehbuch für Umsetzung und Audit.

Datenbank mit PII (at rest)	Diebstahl von Snapshots; TDE allein; falsche IVs	AES‑256‑GCM; TDE + Feld‑Verschlüsselung/Tokenisierung	KMS/HSM; Rotation ≤ 90 Tage; getrennte Rollen	% PII mit Feld‑Krypto; Alter des DB‑Keys; Audit‑Events im SIEM	DSGVO Art. 32; ISO 27001 A.10
Service → Service (in transit)	TLS‑Downgrade; fehlende PFS; kein mTLS	TLS 1.3 only; X25519; AES‑GCM oder ChaCha20‑Poly1305	mTLS mit kurzlebigen Zertifikaten; Auto‑Renew; CRL/OCSP	≥95 % TLS 1.3; Failed Handshakes; Zert‑Alter	RFC 8446; OWASP TLS
Backups/Snapshots (at rest)	Gleicher Master‑Key; offenes S3; Kopien ohne Policy	AES‑256‑GCM; S3‑SSE‑KMS/Client‑Side Krypto	Eigene Keys je Backup‑Klasse; Offsite‑Rotation	Unveränderlichkeits‑Flag; Restore‑Tests; Zugriff‑Alerts	PCI DSS (Speicherung); DSGVO Nachweis
Mobile App → API (in transit)	MitM; altes TLS; kein Pinning	TLS 1.3; ChaCha20‑Poly1305 auf schwacher CPU; Cert Pinning	Kurzlebige Tokens; Key‑Rotation für Signaturen	% Pinning aktiv; Abbruchquote; Latenz pro Suite	NCSC TLS; OWASP MASVS/ASVS
Analytics/Data Lake (in use & at rest)	Re‑Identifikation; breite Zugriffe	Pseudonymisierung; feldweise Krypto; Zugriff pro Zweck	Trennung Analyse‑/Prod‑Keys; Approval‑Flows	Query‑Audit; Rows mit Klartext = 0; Key‑Age	DSGVO Minimierung; ENISA Praxis
Edge/CDN → Origin (in transit)	Fehlende HSTS; schwache Ciphers am Edge	TLS 1.3; HSTS; OCSP‑Stapling; sichere Curves	Automatik‑Renew; getrennte Edge‑Keys	% HSTS‑Header; 0 alte Protokolle; Cert‑Revocation‑Zeit	UKGC RTS; ISO 27001 Betrieb
Hinweise: Für Kartendaten gelten die PCI DSS Anforderungen. Für UK‑Anbieter greifen die UKGC Remote Technical Standards (Sicherheit). Feld‑Verschlüsselung ergänzt TDE, sie ersetzt TDE nicht.

Fünf Layer, nicht 50 Tools

Layer 1 – Krypto‑Politik: Legen Sie erlaubte Suiten fest. Planen Sie Wechsel („Krypto‑Agilität“). Verbieten Sie alte Protokolle. Halten Sie Ausnahmen knapp, befristet und dokumentiert.

Layer 2 – Schlüssel‑Lebenszyklus: Erzeugen, speichern, nutzen, rotieren, sperren, löschen. In HSM/KMS, nie im Code oder in Git. Rollen trennen. Siehe auch NIST‑Empfehlungen zum Schlüsselmanagement für Prozesse pro Phase.

Layer 3 – Transport: TLS 1.3 only. PFS mit X25519. mTLS intern. HSTS an den Kanten. OCSP‑Stapling. Testen Sie Downgrade‑Schutz. Lesen Sie die Quelle, RFC 8446 (TLS 1.3), für Details zu KEX, Suites und 0‑RTT‑Risiken.

Layer 4 – Speicherung: TDE in der DB plus Feld‑Krypto für PII. Tokenisierung für Karten‑Daten. In der Cloud: SSE‑KMS oder Client‑seitig. Eigene Keys je Datenklasse. Backups isolieren.

Layer 5 – Überwachung und Tests: Automatische Checks der TLS‑Ciphers. ZAP/Burp für Verkehr. KMS‑Audit‑Logs ins SIEM. SLA für Key‑Rotation. Mappen Sie Controls auf die Cloud Security Alliance CCM (Kontrollen).

Spielerdaten sind speziell – hier klemmt es oft

KYC‑Fotos sind sensibel und groß. PII (Name, Adresse) ist breit genutzt. Zahlungs‑Token sind streng, aber klein. Bonus‑ und Betrugs‑Signale sind viele kleine Punkte. Dazu kommen Affiliate‑IDs. Diese Teile haben andere Schutz‑Stufen und andere Fristen. Ein Mix aus Pseudonymisierung, Feld‑Krypto und Zugriff nach Zweck hilft. Ein fester Plan je Datentyp spart Streit im Audit.

Der Weg der Daten: Mobile → CDN/WAF → Edge‑TLS → Origin → Microservices → Queue → Data Lake. An jedem Pfeil braucht es „in transit“ Schutz. An jedem Kasten braucht es „at rest“ Schutz. ENISA fasst praktische Wege klar: ENISA Good Practices for Data Protection.

Typische Fehler aus Audits – und die Gegenmittel

Prod‑ und Dev‑Keys gemischt. Gegenmittel: Trennen. Getrennte KMS‑Konten. Keine Kopie von Prod‑Daten in Dev, schon gar nicht im Klartext.
TLS‑Downgrade möglich. Gegenmittel: TLS 1.3 erzwingen. HSTS setzen. Ciphers prüfen. Siehe OWASP TLS Cheat Sheet.
Ein Master‑Key für alle Backups. Gegenmittel: Eigene Keys je Bucket/Projekt. Backup‑Key ohne Rechte auf Prod‑DB. Restore‑Drills im Plan.
Wiederverwendung von IV/Nonce. Gegenmittel: GCM korrekt nutzen. Bibliotheken wählen, die IVs sicher erzeugen. Tests einbauen.
Kein Cert Pinning in Apps. Gegenmittel: Pinning mit Roll‑Over. Klare Fehler‑Meldung in der App. Beobachten, ob Pins ablaufen.
Unsichere Edge‑Defaults. Gegenmittel: Edge‑Konfig getrennt härten. OCSP‑Stapling. Eindeutige Cipher‑Policy.

Für externe Dienste gilt: Prüfen Sie die TLS‑Policy, nicht nur den Namen. Die Hinweise des britischen NCSC sind prägnant: NCSC UK Guidance on TLS.

Kleiner Entscheidungsbaum für Algorithmen

Mobile mit schwacher CPU? Bevorzugen Sie ChaCha20‑Poly1305. Moderne Server mit AES‑NI? Nutzen Sie AES‑256‑GCM. Für Schlüsselaustausch: X25519. Für Signaturen: Ed25519, oder ECDSA P‑256, wenn Legacy‑Systeme das brauchen. Halten Sie die Suite‑Liste kurz. Weniger ist hier mehr.

Die Grundlagen zu X25519/Ed25519 stehen in den CFRG‑Empfehlungen: IETF CFRG Empfehlungen (RFC 7748).

Compliance‑Karte für iGaming

DSGVO: Minimierung, Pseudonymisierung, Schutz „Stand der Technik“, Nachweis. Für tiefe, technische Hinweise sind die EDPB Leitlinien zu Sicherheit hilfreich, auch wenn sie Datenübermittlungen adressieren.

PCI DSS: Kartendaten nie selbst speichern, wenn nicht nötig. Token zuerst. Strikte Netzwerk‑Trennung. UKGC RTS: Saubere Transport‑ und Speichersicherheit. Malta: Achten Sie auf die Auflagen der Behörde; ein Startpunkt ist die Malta Gaming Authority – Security Guidance. Fazit: Nicht „wir nutzen AES‑256“ zählt, sondern, dass Ihre Maßnahmen belegt, geprüft und aktuell sind.

90‑Tage‑Plan: vom Ist‑Zustand zur Routine

Woche 1–2: Inventar aller Datenflüsse, Systeme, Secrets, Schlüssel, Zertifikate. Karte zeichnen: Wo liegen PII? Wo fließen sie? Wer hat Zugriff? Woche 3–4: TLS 1.3 überall. Schwache Ciphers aus. HSTS an. Woche 5–6: KMS/HSM einführen, Rollen trennen, Rotation starten. Woche 7–10: Feld‑Verschlüsselung für PII und Tokenisierung. Backups mit eigenen Keys, getrennte IAM‑Rollen. Woche 11–12: Monitoring, Alarme, Pen‑Tests der Schnittstellen. Wer sich parallel einen Markt‑Blick holen will (zum Beispiel, wie mobile Anbieter Sicherheit zeigen), kann als Nutzer‑Perspektive eine kuratierte Übersicht wie best mobile casino sites prüfen. Das ersetzt kein Audit, hilft aber beim Gespür, was „State of the Art“ auf der Front ist.

Was messen? Klare KPIs/SLIs für Krypto

Transport: ≥95 % aller Verbindungen über TLS 1.3; 0 % alte Protokolle; Anteil mit PFS = 100 %.
Zertifikate: Ø Alter bei Erneuerung ≤ 60 Tage; Zeit bis Revocation ≤ 1 Stunde.
Schlüssel: Ø Key‑Age pro Klasse; Rotation im Plan; 0 Keys im Code/Git.
Speicherung: Abdeckung TDE = 100 % relevanter DBs; PII mit Feld‑Krypto ≥ 90 % (ausgenommen rechtlich nötig); Restore‑Test je Quartal = bestanden.
Monitoring: Failed Handshakes unter X %; Alarme auf Policy‑Drift; Audit‑Logs im SIEM vollständig.

Kurz‑FAQ aus echten Rückfragen

Reicht ein VPN? Nein. VPN schützt Wege im Netz. Sie brauchen zusätzlich TLS 1.3 Ende‑zu‑Ende, intern mTLS.

Dürfen wir Keys im Code halten? Nein. Nutzen Sie KMS/Secrets‑Manager. Rotieren Sie oft. Prüfen Sie Zugriffe.

Sollen wir auf Post‑Quantum warten? Nein. Planen Sie Krypto‑Agilität. Halten Sie Abhängigkeiten klein. Testen Sie hybride Suiten, wenn verfügbar.

Müssen Module zertifiziert sein? Wenn Sie es verlangen (z. B. durch Kunden/Regeln), ja. Dann prüfen Sie FIPS 140‑3 Validated Modules.

Schluss – kurze Checkliste vor dem Release

TLS 1.3 erzwungen, schwache Suiten aus, HSTS an, OCSP‑Stapling aktiv.
mTLS intern. Zert‑Erneuerung automatisiert. Kein Self‑Signed in Prod.
TDE aktiv plus Feld‑Krypto für PII. Tokenisierung für Zahlungs‑Daten.
Backups mit eigenen Keys, getrennten Rollen, Restore‑Test bestanden.
Keys im KMS/HSM. Rotation im Plan. Keine Secrets im Code oder Tickets.
Data‑Flows, Keys, Verantwortliche dokumentiert. Änderungen versioniert.
Monitoring‑KPIs definiert. Alarme auf Policy‑Drift. Logs im SIEM.
Rechtslage geprüft (DSGVO/PCI/UKGC/MGA). Nachweise abgelegt.
Mobile Apps: Cert Pinning mit Roll‑Over. Token‑Lebensdauer kurz.
Extern geprüft: Pen‑Test, Konfig‑Scan, Key‑Review.

Autor: Sicherheitsteam iGaming (CISSP/CISM; 10+ Jahre Audits, iGaming & Fintech). Stand: Juni 2026. Fakten geprüft am: 14. Juni 2026. Kein Rechtsrat. Prüfen Sie offizielle Texte für Ihre Jurisdiktion.