---
term: 'Datenverschlüsselung im Ruhezustand und bei der Übertragung'
seoTitle: 'Verschlüsselung im Ruhezustand vs. Übertragung: TLS, AES-256'
headline: 'Was ist Datenverschlüsselung im Ruhezustand und bei der Übertragung?'
slug: datenverschluesselung
category: auth-security
shortDefinition: '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.'
relatedTerms:
  - data-layer-vs-application-layer-security
  - row-level-security
  - api-key-security
  - tenant-isolation
contrastsWith:
  - data-layer-vs-application-layer-security
aboutTerms:
  - 'Encryption at Rest'
  - 'Encryption in Transit'
  - 'TLS'
  - 'Key Management'
faq:
  - question: 'Was ist Verschlüsselung im Ruhezustand?'
    answer: 'Das Verschlüsseln gespeicherter Daten – Festplatten, Datenbanken, Backups, Objektspeicher –, sodass jeder, der das Speichermedium ohne die Schlüssel erlangt, nur Geheimtext in den Händen hält. Der Standard ist AES-256; geschützt wird gegen gestohlene Hardware, abgeflossene Backups und kompromittierte Speicherschichten.'
  - question: 'Was ist Verschlüsselung bei der Übertragung?'
    answer: 'Das Verschlüsseln von Daten, während sie Netzwerke durchqueren, sodass abgefangener Verkehr unlesbar bleibt – die Aufgabe von TLS, also genau das, was das S in HTTPS liefert. Es schützt gegen Mithören und Man-in-the-Middle-Angriffe auf jedem Hop zwischen Client und Server.'
  - question: 'Was unterscheidet Verschlüsselung im Ruhezustand von Verschlüsselung bei der Übertragung?'
    answer: 'Verschiedene Datenzustände, verschiedene Bedrohungen. Im Ruhezustand werden gespeicherte Kopien gegen den Diebstahl von Medien und Backups verteidigt; bei der Übertragung werden bewegte Daten gegen Mithören verteidigt. Sie ergänzen einander, sie ersetzen einander nicht – jedes ernsthafte Sicherheitsframework erwartet beides, weil jede Maßnahme Angriffe stoppt, die die andere nicht sieht.'
  - question: 'Ist HTTPS dasselbe wie TLS?'
    answer: 'HTTPS ist HTTP, das über TLS transportiert wird – das kryptografische Protokoll, das die Verbindung absichert. TLS 1.3 ist aktuell: schnellere Handshakes, schwache Cipher entfernt, Forward Secrecy verpflichtend. Die Versionen 1.0 und 1.1 sind formal abgekündigt und sollten deaktiviert werden.'
  - question: 'Was ist AES-256?'
    answer: 'Der Advanced Encryption Standard mit einem 256-Bit-Schlüssel – eine symmetrische Blockchiffre, standardisiert vom NIST, gegen Brute Force praktisch immun und die De-facto-Wahl für Daten im Ruhezustand. In der Praxis wollen Sie einen authentifizierten Modus wie AES-GCM, der Manipulation erkennt und nicht nur den Inhalt verbirgt.'
  - question: 'Was ist der Unterschied zwischen symmetrischer und asymmetrischer Verschlüsselung?'
    answer: 'Symmetrisch nutzt einen gemeinsamen Schlüssel in beide Richtungen – schnell, richtig für große Datenmengen (AES). Asymmetrisch nutzt ein Paar aus öffentlichem und privatem Schlüssel – langsamer, richtig für Schlüsselaustausch, Zertifikate und Signaturen. TLS nutzt beides: Ein asymmetrischer Handshake einigt sich auf einen symmetrischen Session-Schlüssel, der dann den eigentlichen Verkehr verschlüsselt.'
  - question: 'Wie unterscheidet sich Ende-zu-Ende-Verschlüsselung von Verschlüsselung bei der Übertragung?'
    answer: 'Durch den Vertrauensbereich. TLS schützt jeden einzelnen Hop, aber der Server entschlüsselt und kann alles lesen. Ende-zu-Ende-Verschlüsselung bedeutet, dass nur die kommunizierenden Benutzer die Schlüssel halten – der Betreiber des Dienstes selbst kann die Inhalte nicht lesen. E2EE schützt vor dem Server; TLS schützt den Weg dorthin.'
  - question: 'Schützt Verschlüsselung im Ruhezustand vor Hackern?'
    answer: 'Nur vor einer bestimmten Sorte: vor denen, die an den Speicher gelangen – gestohlene Laufwerke, abgeflossene Backups, falsch konfigurierte Buckets. Ein Angreifer, der die Anwendung kompromittiert oder Zugangsdaten stiehlt, liest die Daten ungehindert, weil die App legitim entschlüsselt. Verschlüsselung ist keine Zugriffskontrolle; sie ergänzt ACLs, sie ersetzt sie nie.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'NIST FIPS 197 — Advanced Encryption Standard (AES)'
    url: 'https://csrc.nist.gov/pubs/fips/197/final'
  - name: 'RFC 8446 — TLS 1.3'
    url: 'https://datatracker.ietf.org/doc/html/rfc8446'
  - name: 'NIST SP 800-57 — Key Management Recommendations'
    url: 'https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final'
  - name: 'OWASP Cryptographic Storage Cheat Sheet'
    url: 'https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html'
  - name: 'Encryption — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Encryption'
cta:
  title: 'Standardmäßig verschlüsselt, über Ihren ganzen Stack'
  text: 'Back4app liefert jede API, jede Datei und jede Live Query über TLS aus und speichert Daten und Backups verschlüsselt – Ihnen bleibt die Policy: ausschließlich gehashte Passwörter (eingebaut), Verschlüsselung auf Feldebene für das wirklich Sensible und ACLs für den Zugriff.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-26'
translationKey: data-encryption-at-rest-transit
---

**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](https://csrc.nist.gov/pubs/fips/197/final) 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

| Frage | Antwort |
| --- | --- |
| Im Ruhezustand | AES-256 auf Platten, Datenbanken, Backups – gegen gestohlene Medien |
| Bei der Übertragung | TLS 1.2+ auf jeder Verbindung – gegen Mithören und MITM |
| Der blinde Fleck | Keines von beidem stoppt eine kompromittierte App – Verschlüsselung ist keine Zugriffskontrolle |
| Das eigentliche Problem | Schlüsselverwaltung – Schlüssel neben den Daten sind Theater |
| Der Irrtum, der weg muss | Passwörter werden *gehasht* (bcrypt/argon2), nie verschlüsselt |

## 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:

```text
             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:**

```javascript
// 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
// Flutter / Dart — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, 'ada@example.com');
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
```

**Swift:**

```swift
// 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
```

**Kotlin:**

```kotlin
// 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](https://datatracker.ietf.org/doc/html/rfc8446) 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:

| Schicht | Wie | Schlägt | Berührt nicht |
| --- | --- | --- | --- |
| Vollverschlüsselung (LUKS/dm-crypt) | Das OS verschlüsselt das Volume | Gestohlene/ausgemusterte Hardware | Jeden auf dem laufenden System |
| Transparent (TDE) | Die Datenbank verschlüsselt Dateien beim Schreiben | Gestohlene Datendateien und Backups | Jeden mit Datenbank-Zugangsdaten |
| Feld-/Spaltenebene | Bestimmte Spalten verschlüsselt, die App hält die Schlüssel | Neugierige DBAs, breitere DB-Einbrüche | Die Kompromittierung der App selbst |
| Anwendungsebene | Verschlüsselt, *bevor* die Daten den Speicher erreichen | Alles unterhalb der App | Die App und ihren Schlüsselspeicher |

```mermaid
flowchart LR
  accTitle: Envelope Encryption hält Schlüssel getrennt von den Daten
  accDescr: Anwendungsdaten werden mit einem Datenschlüssel verschlüsselt. Der Datenschlüssel wird seinerseits von einem Schlüsselverschlüsselungsschlüssel verschlüsselt, der in einem Schlüsselverwaltungsdienst oder einem Hardware-Sicherheitsmodul liegt. Eine gestohlene Datenbank enthält damit Geheimtext und umhüllte Schlüssel, aber nichts, was sich ohne den separat bewachten Schlüsseldienst entschlüsseln ließe.
  D["Daten"] -->|"AES-256-GCM"| C["Geheimtext<br/>in der Datenbank"]
  DEK["Datenschlüssel (DEK)"] -->|"verschlüsselt"| D
  KEK["Schlüsselverschlüsselungsschlüssel (KEK)"] -->|"umhüllt"| DEK
  KMS["Schlüsseldienst / HSM<br/>getrenntes System, auditiert"] -->|"hält"| KEK
  T["Dieb mit der Datenbank"] -.->|"bekommt Geheimtext +<br/>umhüllte Schlüssel – nichts öffnet sich"| C
```

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

| | Verschlüsselung | Hashing |
| --- | --- | --- |
| Umkehrbar | Ja – mit dem Schlüssel | Nein – von Entwurf wegen |
| Richtig für | Daten, die Sie zurücklesen müssen | Passwörter, Integritätsprüfungen |
| Standards | AES-256-GCM | bcrypt, scrypt, argon2 (langsam + gesalzen) |
| Das Versagen | Schlüssel verlieren oder offenlegen | Schnelle ungesalzene Hashes (MD5, blankes SHA-256) |

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

| Situation | Greifen Sie zu |
| --- | --- |
| Beliebige Daten, beliebige App | TLS überall + At-Rest-Verschlüsselung der Plattform – die Untergrenze |
| Albtraum gestohlener Backups | Verschlüsselte Backups + Schlüssel anderswo gelagert |
| Sensible Spalten (Gesundheit, Ausweise) | Verschlüsselung auf Feld-/Anwendungsebene, Schlüssel in Umgebungsvariablen oder KMS |
| "Nicht einmal wir sollten es lesen" | Ende-zu-Ende-Verschlüsselung – die Produktkosten akzeptieren |
| Passwörter | Hashing (bcrypt/argon2) – niemals Verschlüsselung |
| Sorge um Zugriff, nicht um Diebstahl | [ACLs und zeilenbasierte Sicherheit](/glossary/de/zeilenbasierte-sicherheit-rls/) – Verschlüsselung hilft nicht |

## Grenzen und Trade-offs

- **Verschlüsselung ist keine Zugriffskontrolle.** Der Punkt der [geschichteten Sicherheit](/glossary/de/datenschicht-vs-anwendungsschicht-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](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) 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](/glossary/de/api-schluessel-sicherheit/), angewandt auf Daten. Dann das Stück, das Verschlüsselung nicht leisten kann: [ACLs und Klassenberechtigungen](/glossary/de/zugriffskontrolllisten-acl/) regeln, wer was liest, denn der Schutz, der einen Angreifer mit gültigen Zugangsdaten stoppt, war nie die Kryptografie – es war die Autorisierung.