At Rest-Verschlüsselung

At Rest-Verschlüsselung

1) Warum es notwendig ist und was genau wir schützen

Definition. Verschlüsselung bei Rest ist der Schutz von Daten, die auf ein Medium geschrieben werden (Festplatten, Snapshots, Backups, Objekte, Protokolle, Speicher-Dumps), damit unbefugter Zugriff auf ein physisches Medium oder einen „rohen“ Speicher den Inhalt nicht preisgibt.

• Block-/Datei-Volumes, Objektspeicher, Datenbanken, Queues/Keyvelles, Cache-Dumps, Logs/Traces, Backups, Export/Import, Snapshots von VMs/Containern, Kernel/Prozess-Dumps, Swap/Swap.
• Multi-Leasing-Szenarien: Isolation zwischen Kunden/Projekten/Umgebungen.

Was wir nicht vollständig abdecken: Diebstahl von Sitzungen im Speicher, Angriffe auf einen Live-Prozess, Schwachstellen der Anwendung, kompromittierte Anmeldeinformationen. Dies erfordert Verschlüsselung „im Flug“, starke Authentifizierung/Autorisierung, Rechteminimierung und Überwachung (siehe verwandte Artikel: „Authentifizierung und Autorisierung“, „Signatur und Verifizierung von Anfragen“).

2) Bedrohungsmodell und Kontrollziele

• Verlust/Diebstahl von Medien (Festplatte, Band, USB, Entwicklergerät).
• Unbefugter Zugriff auf Backups/Snapshots/Logs.
• Missbrauch von Privilegien auf Plattform-/Hypervisor-/Storaj-Nod-Ebene.
• Überschneidung von Mietern bei Konfigurationsfehlern.
• „Vermüllte“ temporäre Dateien und Dumps, die in Artefakten und Bildern landen.

1. Vertraulichkeit der Daten auf dem Medium.

2. Kryptographische Isolierung von Mietern/Umgebungen.

3. Verwaltbarkeit der Schlüssel (Erstellung, Speicherung, Rotation, Widerruf).

4. Prüfbarkeit (wer und wann den Schlüssel verwendet hat).

5. Minimierung der betrieblichen Risiken bei Störfällen.

3) Grundprinzipien der Architektur

Wir verschlüsseln alles standardmäßig. Opt-out ist ohne Ausnahmen auf der Risikostufe verboten.
Schlüsselhierarchie (envelope encryption) Root/KEK → DEK (Data Encryption Keys) → DB-Objekte/Dateien/Seiten.
KMS/HSM als Vertrauensquelle. Die Generierung und Speicherung der KEK im KMS/HSM, die Umhüllungen/Schlüsselbereitstellungen erfolgen dort.
Per-tenant/per-dataset Schlüssel. Granularität für Isolations- und Rotationsanforderungen.
Aufgabenteilung. Plattformteams ≠ Eigentümer von Mieterschlüsseln; Mindestprivilegien (PoLP).
Crypto-agility. Möglichkeit, Algorithmen/Schlüssellängen sicher zu migrieren.
Rotation als Prozess, nicht als Ereignis. Schlüssel und Daten müssen einen „gleitenden“ Ersatz unterstützen.

4) Algorithmen und Verschlüsselungsmodi

Für Objekte/Dateien/Datensätze: AES-256-GCM oder AES-256-SIV (AEAD mit Authentifizierung).
Für Blockgeräte/Volumes: AES-XTS-256/512 (Schutz vor Blockumlagerungen; nicht AEAD - auf Dateiformaten mit MAC verwenden, wo Integrität wichtig ist).

• TDE (Transparent Data Encryption) движка: Oracle TDE, SQL Server TDE, MySQL/InnoDB TDE и пр.
• Feld/Zeile Kryptographie (FPE/deterministische Verschlüsselung) - für Suchmöglichkeiten/Joins auf verschlüsselten Feldern; umsichtig anzuwenden.
• Schlüsselgenerierung und -speicherung: KEK - in KMS/HSM; DEK - im App-Speicher kurz lebendig, bei Lagerung nur in gewickelter Form.

5) Schlüsselhierarchie und KMS/HSM

1. Root-Schlüssel (statutarisch, im HSM/KMS). Verlässt den HSM/KMS-Umfang nicht.

2. KEK (Key Encryption Key). Zum Projekt/Umfeld/Mieter. Verwaltet den DEK-Lebenszyklus.

3. DEK (Data Encryption Key). Pro Objekt/Datei/Tabelle/Segment. Kurzlebig, Rotation ohne Stopp.

• Alle Wrapper/Deployment-Vorgänge erfolgen über die KMS API mit Audit.
• Politiker: Wer kann den Schlüssel „benutzen“ ≠ wer kann den Schlüssel „kontrollieren“?
• Geo-Schlüsselverteilung: Pin-to-Region + Dual-Control für die Interregion.
• Ein „Dual-Check“ -Modell (zwei Operatoren) für risikoreiche Operationen ist möglich.
• Für die Isolierung einer starken Ebene - separate Schlüsselringe pro Mieter.

6) Rotation, Widerruf und Compliance

DEK-Rotation: transparent und dauerhaft (Rolling Re-Encryption auf Objekt-/Seitenebene).
KEK Rotation: periodisch (z.B. alle 6-12 Monate) + sofortiger Rückruf bei Verdacht auf Kompromittierung.
Entzug des Zugangs: über KMS-Richtlinien; Blockierung von Unwrap-Operationen = sofortige „Krypto-Zerstörbarkeit“ von Daten.
Prüfprotokolle: Wer, wann, mit welchen Rechten verwendete Schlüssel; getrennt zu speichern und auch zu verschlüsseln.
Vorschriften und Standards: Wir orientieren uns an den Anforderungen der Branche (z.B. DSGVO/PCI-Zulassungen/lokale Regulierungsbehörden), verwenden zertifizierte Kryptomodule (z.B. Einhaltung von Zertifizierungsstufen).

7) Muster nach Art der Speicherung

7. 1 Block-/Dateivolumes und VMs/Container

Vollplattenverschlüsselung (XTS) + Schlüsselverwaltung über KMS (Volume-Initialisierung beim Mounten).
Schützen Sie Swap, Crash-Dumps, TMP-Verzeichnisse, Container-Overlay-Ebenen, Images/AMI.
Snapshots/Snapshots - immer verschlüsselt mit den einzelnen DEKs.

7. 2 Objektspeicher

Envelope encryption: einzigartige DEK pro Objekt; Header/Metadaten - keine PII-Leaks.
Zugangskontrolle zum KMS-Schlüssel nach Mieter und Umgebung.
Server-Side-Verschlüsselung (SSE mit eigenem KMS) oder Client-Side (CSE) - Auswahl nach Vertrauensmodell.

7. 3 Datenbanken

TDE aktivieren, wo verfügbar; DB-Schlüssel über Plugin/Extension an KMS binden.
Für besonders sensible Bereiche - Anwendungsverschlüsselung (AEAD) vor dem Eintritt in die Datenbank.
Redo-/Transaktionsprotokolle, Archivprotokolle, Dumps - separat verschlüsseln, Schlüssel separat.

7. 4 Logs/Traces/Metriken

Logformat - keine sensiblen Standarddaten (Desinfektion).
Logarchive - einzelne Schlüssel und kurze Speicher-TTLs.
Der Zugriff auf das Lesen von Protokollen erfolgt über einen Proxy-Service mit A&A und Audit.

7. 5 Backups und Offline-Medien

Immer auf Kundenseite verschlüsseln, bevor auf Band/Cloud geschrieben wird.
Schlüssel separat aufbewahren (Out-of-Band), Escrow mit separater Steuerung.
Für Notfälle - Teilen Sie ein Geheimnis (z. B. m-of-n), um den Master-Zugriff wiederherzustellen.

8) Multi-Leasing (Multi-Tenant)

Schlüssel für den Mieter: KEK-per-tenant + DEK-per-dataset.
Isolierung durch Richtlinien: KMS-Namespaces, IAM-Grenzen, separate IDP-Rollen.
Löschung auf Kundenwunsch: „crypto-erase“ - KEK des Mieters zurückrufen und DEK vernichten.
Reporting für den Kunden: Compliance-Artefakte, Schlüsselzugriffsprotokolle, Rotationsbestätigung.

9) Leistung und Betrieb

Hardwarebeschleunigung (AES-NI/x86 ARMv8 Crypto Extensions)

Hot-Path-Profiling: Wir verschlüsseln an I/O-Grenzen, vermeiden doppelte Verschlüsselung unnötig.
KMS-Sitzungspools, Caching gewickelter DEKs im Speicher (mit TTL und Dump-Schutz).
SLO/Metriken: Unwrap-Latenz, Anteil an „transkribierten“ Objekten, KMS-Fehler, Geschwindigkeit der Backup-Verschlüsselung.

10) Implementierungsprozess (reference runbook)

Schritt 0 - Bestandsaufnahme der Daten. Katalogisieren Sie alle Speicher und Leckpfade (tmp, Dumps, Export, Analytics-Bakets).
Schritt 1 - Gestaltung der Schlüsselhierarchie. Wir definieren KEK/DEK Ebenen, Granularität, Regionen, Rollen.
Schritt 2 - Wählen Sie Modi/Bibliotheken. Zugelassene Algorithmen, Kryptobibliotheken, Versionsrichtlinien.
Schritt 3 - Integration mit KMS/HSM. Generation/Wrapper/Audit, IAM-Richtlinien, Geo-Pinning.
Schritt 4 - Verschlüsselung pro Datensatz. Aktivieren Sie standardmäßig die Migration vorhandener Daten über Background Reencripte.
Schritt 5 - Rotation und Notfallszenarien. Vorschriften, Tests „Schlüsselkompromise“, „KMS nicht verfügbar“.
Schritt 6 - Überwachung und Audit. Dashboards, Alerts, regelmäßige Compliance-Berichte.
Schritt 7 - Training und „Secure Coding“. Hydes für Ingenieure, Verbot der Ausgabe von Geheimnissen in Logs/Dumps.

11) Prüfung und Verifizierung

Krypto-Unit-Tests: AEAD-Korrektheit (Tag-Check), Fehlervalidierung bei Byteänderung.
Failure-Tests: KMS deaktivieren, veraltete Schlüsselversionen, KEK-Rückruf erzwingen.
Rot/Blau-Tests: Versuche, das „rohe“ Laufwerk/Snap-Shot/Backup zu lesen.
Kompatibilitätsprüfung: Migration von Algorithmen/Schlüssellängen (crypto-agility).
Zertifizierung von Bibliotheken: Verwenden Sie nur verifizierte Kryptomodule; Versionen erfassen.

12) Häufige Fehler und wie man sie vermeidet

Doppelte Verschlüsselung ohne Sinn. Zusätzliche Latenz und Komplexität. Halten Sie eine Schicht, die die gewünschte Granularität und Isolierung verleiht.
Speichern Sie die Schlüssel neben den Daten. Schlüssel - immer separat, unter einem anderen Zugangsmodell.
Vergessene Artefakte. Unverschlüsselte temporäre Dateien, CSV-Export, Support-Dumps. Aktivieren Sie die Steuerung in CI/CD und Data Loss Prevention.
Fehlende Rotation. Machen Sie die Rotation zu einem Teil der Pipeline/Cron und nicht zu einem manuellen Vorgang.
Protokolle mit sensiblen Daten. Geben Sie einen Vertrag für das Logformat und automatische Desinfektionsmittel ein.

13) Mini-Rezepte (Pseudocode)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) Checklisten

• Standardverschlüsselung auf allen Speichertypen aktiviert.
• Schlüsselhierarchie beschrieben und implementiert; Rollen und IAM-Richtlinien sind konfiguriert.
• KMS/HSM integriert, Key Operations Audit inklusive.
• Die Rotation von DEK/KEK ist automatisiert; Kompromittierungsszenarien erarbeitet.
• Backups, Snapshots, Logs und Dumps - verschlüsselt; Schlüssel werden separat gespeichert.
• Alerts für KMS-Fehler, AEAD-Tag-Abweichungen, Anteil unverschlüsselter Artefakte konfiguriert.
• KMS-Nichtverfügbarkeitstests und Schlüsselrückruf bestanden.

• Monatlicher Bericht über Schlüsselverwendung und Zugriffsversuche.
• Crypto-Agility-Plan und Fenster für eine schmerzlose Migration von Algorithmen.
• Periodisches Red-Team zum Extrahieren von Daten aus „rohen“ Medien.

15) Fragen und Antworten (FAQ)

F: Reicht die Volldiskettenverschlüsselung aus?
A: Für physische Risiken - ja, aber für die Isolierung von Mietern und flexible Rotation ist envelope mit DEK-on-object/set besser.

F: Was tun, wenn KEK kompromittiert wird?
A: Ziehen Sie KEK sofort in KMS zurück, veröffentlichen Sie ein neues, führen Sie Rewrap aller DEKs durch, überprüfen Sie die Protokolle und führen Sie RCAs durch.

F: Wie verschlüssle ich die Felder, nach denen ich suche?
A: Verwenden Sie deterministische Schemata oder FPEs nur bei strenger Risikobewertung (Musterlecks). Es ist besser, Abfragen so zu gestalten, dass sensible Felder keine indexierbare offene Ansicht benötigen.

F: Benötigen Sie einen separaten Befehl für die Schlüssel?
A: Der „Crypto/KMS-Operator“ wird als Rolle mit separaten Rechten und Prozeduren empfohlen.

• „Schlüsselmanagement und Rotation“
• „S2S-Authentifizierung“
• „Signieren und Verifizieren von Anfragen“
• „OAuth2/OpenID Connect im Kern“
• „Garantien für die Lieferung von Webhooks“