Was ist Datenverschlüsselung im Ruhezustand und bei der Übertragung?

Verschlüsselung im Ruhezustand ist ein Schutz, der gespeicherte Daten ohne Schlüssel unlesbar macht; Verschlüsselung bei der Übertragung schützt Daten im Netz. Daten existieren in drei Zuständen – im Ruhezustand auf dem Speicher, bei der Übertragung auf der Leitung und in Nutzung im Arbeitsspeicher –, und die ersten beiden sind die Grundpflicht jeder Anwendung: AES-256 für das, was liegt, TLS für das, was sich bewegt. Der dritte Zustand (geschützt durch Trusted Execution Environments und, an der Forschungsfront, homomorphe Verschlüsselung) ist real, für die meisten Anwendungsteams aber die Schicht von jemand anderem.

Das Wichtigste in Kürze

Die zwei Schutzmaßnahmen – und was jede wirklich stoppt

Die ehrliche Tabelle, die die bestplatzierten Seiten weglassen – samt der Spalte, auf die es am meisten ankommt:

             Standard         Deckt ab                  Stoppt                        Stoppt NICHT
Übertragung  TLS 1.2+/HTTPS   jeden Netzwerk-Hop        Lauschangriffe, MITM,         kompromittierte Endpoints –
                                                        Schnüffeln im Café            der Server liest alles mühelos
Ruhezustand  AES-256 (GCM)    Platten, DBs, Backups     gestohlene Platten, geleakte  gestohlene Zugangsdaten,
                                                        Backups, offene Buckets       SQL-Injection, App-Fehler
In Nutzung   TEEs             RAM bei der Verarbeitung  Auslesen des Speichers        – meist Sache der Plattform

Keine davon stoppt einen Angreifer, dem die App selbst vertraut. Die App hält die Schlüssel
und entschlüsselt auf Anfrage – Verschlüsselung ergänzt die Zugriffskontrolle, ersetzt sie nie.

Wie die Standardeinstellungen aus dem Anwendungscode aussehen:

// JavaScript / Node.js — Back4app JS SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret });
// On the wire: TLS 1.2+ (the https serverURL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Flutter / Dart — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// iOS / Swift — Back4app Swift SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
var user = User()
user.username = "ada"
user.password = secret
let signedUp = try await user.signup()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Android / Kotlin — Back4app Android SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.signUp()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

Wie TLS funktioniert, in einem Absatz

Der elegante Kniff: Asymmetrische Kryptografie ist langsam, braucht aber kein gemeinsames Geheimnis; symmetrische ist schnell, braucht aber eines. Also nutzt der TLS-Handshake das erste, um das zweite herzustellen – der Client prüft das Zertifikat des Servers (die Identitätsprüfung, die ein Abfangen erkennbar macht), beide Seiten einigen sich über einen asymmetrischen Schlüsselaustausch auf einen frischen Session-Schlüssel, und alles danach läuft über schnelle symmetrische Verschlüsselung. TLS 1.3 hat das Ganze gestrafft: ein Roundtrip statt zwei, alte Cipher und der RSA-Schlüsselaustausch entfernt, Forward Secrecy verpflichtend – aufgezeichneter Verkehr lässt sich also auch dann nicht nachträglich entschlüsseln, wenn der Langzeitschlüssel des Servers abfließt. Der mobile Zusatz, den die üblichen Quellen überspringen: Apps können erwartete Zertifikate zusätzlich pinnen und tauschen damit Widerstandsfähigkeit gegen bösartige Zertifizierungsstellen gegen operative Sorgfalt bei jeder Rotation.

Die At-Rest-Schichten: Festplatte vs. Datenbank vs. Feld vs. Anwendung

“Im Ruhezustand verschlüsselt” umfasst vier sehr unterschiedliche Versprechen – jedes davon schlägt einen anderen Angreifer:

Die Regel über die ganze Tabelle hinweg: Höhere Schichten schützen vor mehr und kosten mehr. Verschlüsselung auf Feldebene ist der ehrliche Trade-off – verschlüsselte Spalten lassen sich nicht normal indizieren oder durchsuchen (deterministische Verschlüsselung stellt Gleichheitsabfragen wieder her, um den Preis eines gewissen Informationsabflusses) –, weshalb sie dem wirklich Sensiblen vorbehalten bleibt: Gesundheitsdaten, Ausweisnummern, Geheimnisse. Und hier wohnt der klassische Prüfungsbefund: die verschlüsselte Datenbank, deren Backups unverschlüsselt hinausgehen.

Ende-zu-Ende-Verschlüsselung ist ein anderes Versprechen

TLS überall heißt weiterhin, dass der Server alles liest – er entschlüsselt jede Verbindung von Entwurf wegen. Ende-zu-Ende-Verschlüsselung verschiebt die Schlüssel zu den Benutzern: Nur Absender und Empfänger können entschlüsseln, und der Betreiber liefert Geheimtext aus, den er nicht öffnen kann. Das ist eine andere Produktentscheidung, keine strengere Einstellung: E2EE bedeutet keine serverseitige Suche, keine Inhaltsmoderation, keine Wiederherstellung, wenn Benutzer ihre Schlüssel verlieren. Die Bedrohungsmodelle schachteln sich sauber ineinander – TLS verteidigt den Weg, die Verschlüsselung im Ruhezustand den Speicher, E2EE gegen den Dienst selbst – und die meisten Anwendungen halten zu Recht bei den ersten beiden an, während Messaging- und Tresor-Produkte das dritte rechtfertigen.

Hashing vs. Verschlüsselung

Ein Hinweis räumt mit einem verbreiteten Irrtum auf: Passwörter werden gehasht, nie verschlüsselt. Niemand – auch der Server nicht – soll ein Passwort wiederherstellen können; die Anmeldung vergleicht Hashes. Passwörter zu verschlüsseln heißt, dass ein Schlüssel existiert, der sie alle entschlüsselt – genau die Katastrophe, die Hashing ausschließen soll.

Typische Anwendungsfälle

• Jede Web- und Mobile-App – TLS auf allen Verbindungen und verschlüsselter Speicher sind Grundausstattung, keine Features.
• Regulierte Daten – die DSGVO nennt Verschlüsselung eine geeignete technische Maßnahme (mit Erleichterungen bei der Meldepflicht), Gesundheitsvorschriften schreiben sie für Patientendaten vor, und Zahlungsstandards verlangen unlesbare Kartennummern im Ruhezustand und starke Kryptografie bei der Übertragung.
• Backups und Außerbetriebnahme – verschlüsselte Backups und Crypto-Shredding (den Schlüssel vernichten, und die Daten sterben überall) schließen das Kapitel der gestohlenen Kopie.
• Schutz von PII-Feldern – Verschlüsselung auf Anwendungsebene für die Spalten, deren Abfluss eine Schlagzeile ist und kein Vorfall.
• Mobile Clients in feindlichen Netzen – TLS plus Zertifikatsprüfung als die Verteidigung, die mit dem Benutzer reist.

Welche Schicht brauchen Sie? Entscheidungsmatrix

Grenzen und Trade-offs

• Verschlüsselung ist keine Zugriffskontrolle. Der Punkt der geschichteten Sicherheit in einer Zeile: Verschlüsselung im Ruhezustand ist für die laufende App transparent, also bleiben Berechtigungen – ACLs, CLPs, Zeilen-Policies – die Verteidigung gegen jeden Angreifer mit gültigen Zugangsdaten.
• Schlüsselverwaltung ist das eigentliche Projekt. Die Empfehlungen des NIST existieren, weil Erzeugung, Trennung, Rotation und Widerruf – nicht die Wahl des Algorithmus – die Stellen sind, an denen Deployments scheitern.
• Verschlüsselung auf Feldebene kämpft gegen die Datenbank. Keine Indizes, keine LIKE-Abfragen, heikle Migrationen; verschlüsseln Sie die Felder, die es brauchen, nicht das Schema.
• TLS endet am Terminator. Proxys und Load Balancer, die auf halbem Weg entschlüsseln, erzeugen wieder Klartext-Hops; interner Verkehr braucht dieselbe Disziplin wie der Rand.
• Compliance ≠ Sicherheit. Häkchen-Verschlüsselung mit Schlüsseln neben den Daten befriedigt Prüfer und sonst niemanden; die Spalte mit dem Bedrohungsmodell ist die, gegen die Sie entwerfen sollten.

Verschlüsselung mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Untergrenze liefert die Plattform: Jede REST-, GraphQL- und Live-Query-Verbindung läuft über TLS, und Daten wie Backups sind im Ruhezustand verschlüsselt – die beiden Basisschichten kommen als Standard statt als Projekt. Der verbleibende Anteil der Entwicklung ist genau das, was die Code-Tabs skizzieren: Passwörter werden von Back4app ab Werk mit bcrypt gehasht (nie gespeichert, nie wiederherstellbar – die Hashing-Regel strukturell durchgesetzt); wirklich sensible Felder bekommen Verschlüsselung auf Anwendungsebene in einem Cloud-Code-beforeSave, mit dem Schlüssel in der serverseitigen Konfiguration statt im Code, sodass Klartext den Speicher nie erreicht; und Geheimnisse bleiben aus Protokollen, URLs und Client-Bundles heraus – die Disziplin bei API-Schlüsseln, angewandt auf Daten. Dann das Stück, das Verschlüsselung nicht leisten kann: ACLs und Klassenberechtigungen regeln, wer was liest, denn der Schutz, der einen Angreifer mit gültigen Zugangsdaten stoppt, war nie die Kryptografie – es war die Autorisierung.