# Encryption Mastery: Schlüsselverwaltung und Strategie

TL;DR / Management Summary Verschlüsselung ist nur so gut wie das Management der Schlüssel. Wer den Schlüssel neben den Tresor legt (z.B. SSH-Keys unverschlüsselt auf dem Server), hat keine Sicherheit gewonnen. Ein Senior Admin unterscheidet zwischen Data-at-Rest (Disk), Data-in-Transit (TLS) und Data-in-Use (RAM) und nutzt dedizierte Key Management Systeme (KMS) wie HashiCorp Vault oder AWS KMS, um den Lebenszyklus von Geheimnissen zu steuern.

# 1. Einführung & Architektur

Die drei Zustände von Daten.

1. Data-at-Rest: Daten auf Festplatten (Schutz durch LUKS, Artikel 320).
2. Data-in-Transit: Daten auf der Leitung (Schutz durch TLS/VPN).
3. Data-in-Use: Daten im RAM (Schutz durch Enclaves/TEE - Fortgeschritten).

# Das KMS-Prinzip (Mermaid)

graph TD
    A[Application / Admin] -->|1. Authenticate| B[KMS: Vault / Cloud KMS]
    B -->|2. Verify Identity / Policy| B
    B -->|3. Provide Temporary Key| A
    A -->|4. Decrypt Data| C[Encrypted Database / File]
    subgraph "Storage of Master Key"
        B --- D[HSM: Hardware Security Module]
        B --- E[Shamir's Secret Sharing: Multi-Person]
    end

# 2. Secrets Management: Wo liegen die Passwörter?

Weg von Umgebungsvariablen.

Viele Admins speichern API-Keys in Umgebungsvariablen (export API_KEY=...).

• Risiko: Diese Keys sind in /proc/ und in jedem ps aux Output sichtbar.
• Lösung: Nutzen Sie Secrets Engines.

# Beispiel: HashiCorp Vault CLI

# Authentifizierung via LDAP/GitHub
vault login

# Geheimnis sicher abrufen (landet nie auf der Disk)
DB_PASS=$(vault kv get -field=password secret/mysql/prod)

# 3. Shamir’s Secret Sharing

Das Vier-Augen-Prinzip.

Für den “Master Key” einer Infrastruktur sollte keine Einzelperson die volle Macht haben.

• Der Key wird in $n$ Teile (Shares) zerlegt.
• Man braucht $k$ Teile (z.B. 3 von 5), um den Key wiederherzustellen.
• Einsatz: Unsealing von Vault-Servern oder Root-CA Re-Keying.

# 4. Day-2 Operations: Key Rotation

Schlüssel wertlos machen.

Ein kompromittierter Schlüssel ist wertlos, wenn er morgen ohnehin abläuft.

• Automation: Nutzen Sie dynamische Secrets (z.B. Vault generiert ein MySQL-Passwort, das nur 1 Stunde gültig ist).
• Rotation: Erneuern Sie SSL-Zertifikate (Artikel 322) und SSH-Keys (Artikel 302) mindestens einmal im Jahr.

# 5. Troubleshooting & “War Stories”

Wenn die Sicherheit blockiert.

# Story 1: “Der hängende Boot nach KMS-Ausfall”

Symptom: Hunderte Cloud-Instanzen starten nach einem Netzwerk-Ausfall nicht mehr. Ursache: Die Server nutzen Cloud-KMS zur Entschlüsselung der Root-Platte. Da das KMS nicht erreichbar war, konnten die Server den Schlüssel nicht abrufen. Lösung: Nutzen Sie Region-redundante KMS Endpunkte und halten Sie lokale “Emergency Break-Glass” Keys in einem physischen Safe bereit.

# Story 2: “Das Git-Leak Desaster”

Symptom: Die AWS-Rechnung steigt plötzlich auf 10.000€ durch unautorisierte Mining-Instanzen. Ursache: Ein Entwickler hat einen API-Key versehentlich in ein öffentliches GitHub-Repo gepusht. Bots haben den Key in Sekunden gefunden. Lösung: Nutzen Sie Tools wie trufflehog oder gitleaks in Ihrer CI/CD-Pipeline, um Commits vor dem Push auf Geheimnisse zu scannen. Widerrufen Sie geleakte Keys sofort!

# 6. Fazit & Empfehlung

• Zentralisierung: Nutzen Sie ein KMS für das gesamte Unternehmen.
• Minimalismus: Geben Sie Applikationen nur Zugriff auf exakt die Keys, die sie brauchen (Identity-based Access).
• Wahl: Nutzen Sie Hardware-Token (YubiKey) für Admin-Zertifikate und Cloud-KMS für automatisierte Skalierung.

# Anhang: Cheatsheet