Retention und Aufbewahrungsrichtlinien

1) Grundsätze

1. Purpose & Minimization. Wir speichern genau das und genau so viel, wie die Verarbeitungszwecke benötigen.
2. Policy as Code. Rethenschen ist eine ausführbare Richtlinie, kein PDF.
3. Defense in Depth. TTL/ILM + Verschlüsselung + Audits + Legal Hold.
4. Reversibility & Proof. Die Löschung ist nachweisbar: Aktionsprotokolle, Krypto-Shredding, Compliance-Bericht.
5. Cost & Carbon Aware. Retenschen berücksichtigt den $/GB-Monat und den CO2-Fußabdruck des Speichers/egress.

2) Datenklassifizierung und „Retenschen-Karte“

• Operational (OLTP): Aufträge, Zahlungen, Sitzungen.
• Analytisch (DWH/Termine): Ereignisse, Log-Fakten, Schnitte.
• Personal (PII/Finanzen/Gesundheit): erfordern besondere Fristen und Rechte der Themen.
• Technisch: Protokolle, Metriken, Traces, CI-Artefakte.
• Dokumente/Medien: WORM/Archiv/Legasi.

Legen Sie für jede Klasse fest: Eigentümer, Zweck, Rechtsrahmen, Zeitrahmen, Schutzniveau, aktuelle und Zielspeicher.

3) ILM: Daten-Lebenszyklus

1. Ingest (hot) → NVMe/SSD, hohe Anforderungsrate.

2. Warm → seltener gelesen, Kompression, Säulenformate.

3. Cold/Archive → Objekt/Band, langer Zugriff.

4. Purge/Delete → garantierte Löschung (inkl. Replikate/Backups).

yaml dataset: events_main owner: analytics purpose: "product analytics"
classification: "pseudonymized"
lifecycle:
- phase: hot; duration: 7d; storage: nvme; format: row
- phase: warm; duration: 90d; storage: ssd; format: parquet; compress: zstd
- phase: cold; duration: 365d; storage: object; glacier: true
- phase: purge; duration: 0d privacy:
pii: false dp_delete_window: 30d # SLA on personal deletions if ligaments appear

4) Richtlinien als Code (nützliche Sketche)

4. 1 Admission-Richtlinie (erforderliche Tags/TTL)

yaml policy: require-retention-tags deny_if_missing: [owner, purpose, classification, retention]
default_retention:
logs:  "30d"
traces: "7d"
metrics:"90d"

4. 2 Gate in CI/CD (Rego) - Verbot von Deploys ohne Retenschen

rego package policy. retention deny[msg] {
some d input. datasets[d].retention == ""
msg:= sprintf("Retention missing for dataset %s", [d])
}

4. 3 S3/Objekt (Lifecycle-Fragment)

yaml
Rules:
- ID: logs-ttl
Filter: { Prefix: "logs/" }
Transitions:
- { Days: 7, StorageClass: STANDARD_IA }
- { Days: 30, StorageClass: GLACIER }
Expiration: { Days: 180 }
NoncurrentVersionExpiration: { NoncurrentDays: 30 }

5) Retention in Threads und Warteschlangen

• `retention. ms`/`retention. bytes'- Fensterretention.
• Compaction (`cleanup. policy = compact') - Speichern Sie den letzten Wert des Schlüssels.
• Tiered Storage - Wir führen den „Schwanz“ in den kalten Schießstand.
• DLQ ist eine separate Retention und TTL.

properties cleanup. policy=delete,compact retention. ms = 604800000 # 7d for tail removal
min. cleanable. dirty. ratio=0. 5 segment. ms=86400000

• Identifizieren Sie die Retention der Schlüsseltopes ≈ das Replikations-/Neuberechnungsgeschäftsfenster.
• Bei Veranstaltungen ist die Abrechnung/Auditierung eine separate lange Retention oder WORM.

6) Datenbanken und Retenschen

• Partitionierung nach Datum/Bereich, Detach & Drop von alten Parties.
• Felder mit Datum - Indizes für TTL-Abfragen.
• Zeittabellen (systemversioniert) + Polisi Purge von älteren Versionen.

sql
-- Monthly instalments
CREATE TABLE audit_events (id bigserial, occurred_at timestamptz, payload jsonb) PARTITION BY RANGE (occurred_at);
-- Cleaning over 365 days
DELETE FROM audit_events WHERE occurred_at < now() - interval '365 days';
VACUUM (FULL, ANALYZE) audit_events;

• TTL auf Schlüsselebene (MongoDB TTL Index, Redis' EXPIRE', Cassandra TTL).
• Downsampling für Metriken (rohe 7d → 90d Aggregats → lange 365d).
• Retention-Richtlinien in TSDB (Influx/ClickHouse Materialized Views mit Dedup/Aggregation).

7) Protokolle, Metriken, Traces

Protokolle: Felder einschränken, PD maskieren, TTL 7-30d, Archiv 90-180d.
Metriken: rohe Hochfrequenz - 7-14d; downsample (5m/1h) — 90–365д.
Traces: Tail-Sampling und Speicherung von „interessanten“ (Bugs/Tails) länger.

yaml observability:
logs:  { ttl: "30d", archive: "90d", pii_mask: true }
metrics: { raw: "14d", rollup_5m: "90d", rollup_1h: "365d" }
traces: { sample: "tail-10%", ttl: "7d", error_ttl: "30d" }

8) Entfernung: Arten und Garantien

Logisch (soft-delete): Markieren eines Eintrags; bequem für die Wiederherstellung, passt nicht zum „Recht auf Löschung“.
Physisch (hard-delete): tatsächliche Löschung von Daten/Versionen/Replikaten.
Kryptographisch (crypto-erasure): Löschen/Ersetzen von Verschlüsselungsschlüsseln, danach werden die Daten nicht wiederhergestellt.
Kaskadierend: End-to-End-Entfernung von Ableitungen (Caches, Indizes, Analysen).

request → locate subject data (index by subject_id) → revoke tokens & unsubscribe jobs → delete in OLTP → purge caches → enqueue erasure in DWH/lakes → crypto-shred keys (per-tenant/per-dataset) → emit audit proof (receipt)

9) Recht auf Löschung, Legal Hold und eDiscovery

Recht auf Löschung/Berichtigung: SLA der Ausführung (z. B. ≤30 Tage), verfolgbare Aktivitäten, Quittungen.
Legal Hold: bei rechtlicher Anfrage - Einfrieren der Löschung für bestimmte Sätze/Schlüssel; Prioritätspolitik gegenüber TTL.
eDiscovery: Datenkatalog, Volltext-/Attributsuche nach Artefakten, Export in konsistenten Formaten.

yaml legal_hold:
dataset: payments scope: ["txn_id:123", "user:42"]
from: "2025-10-31"
until: "2026-03-31"
reason: "regulatory investigation"

10) Backups vs Archive vs WORM

Backups - für die Wiederherstellung von Verlust/Verderb; kurze Retention, schnelle RTO.
Archive - Langzeitspeicherung für Audit/Analyse, billig, langer Zugriff.
WORM - unveränderliche Medien für Compliance (Finanzen/Reporting); „write-once, read-many“ -Richtlinien.

• Zählen Sie das Backup nicht als „Archiv für die Jahrhunderte“.
• Wiederherstellungsproben (DR-Tage), Zeit- und Vollständigkeitsbericht.
• Verzeichnis der Backups mit Retenschen, Verschlüsselung und Schlüssel getrennt vom Speicher.

11) Privatsphäre und Anonymisierung

Pseudonymisierung: verzögerte PII-Bindung über Schlüsseltabelle (ermöglicht crypto-erasure durch Schlüssel).
Anonymisierung: irreversible Techniken (k-Anonymität, Rauschen, Verallgemeinerung); Dokumentieren Sie die Methode, das Risiko einer erneuten Identifizierung und das Verfallsdatum.

12) Compliance Monitoring und Reporting

Kontrollpanels: Anteil der Datasets mit gültigem Retenschen, Volumina nach ILM-Phasen, Löschfehler.
Alerts: Überschreitung des Zielvolumens in einem heißen Strich, „hängende“ Löschungen, auslaufende Legal Hold.
Berichte: monatliche Löschprüfung (Anzahl der Anfragen, durchschnittliche Laufzeit, Ausfälle), Ausdruck von Krypto-Shredding.

13) Integration in Prozesse: Gates und Revue

Design-Gate: Das neue Dataset kommt ohne' owner/purpose/retention 'nicht durch die Revue.
Release-Gate: Migrationen, die das Retenschen ohne Eigentümer/Begründung erhöhen, werden blockiert.
Cost-Gate: Volumen in hot/warm übersteigt Budget - Auslöser für ILM-Straffung.
Security-Gate: Verbot der Aufnahme von PD in Logs/Trails ohne Maskierung und TTL.

14) Anti-Muster

„Wir behalten alles für immer - plötzlich wird es nützlich sein“.
Hartcodierte TTLs in Anwendungen, die nicht in Richtlinien übernommen wurden.
PD in Logs und Traces ohne Maskierung/TTL/Löschung.
Unvollständige Löschung (links im Cache/DWH/Backups).
Kein Legal Hold - Datenlöschung unter Untersuchung.
Ein gemeinsamer Verschlüsselungsschlüssel für alles - es ist unmöglich, Punkt „crypto-erase“.
Null Beobachtbarkeit: „Wir glauben, dass wir gelöscht haben“, aber es gibt keine Beweise.

15) Checkliste des Architekten

1. Gibt es für jedes Dataset einen Owner, eine Purpose, eine Classification, eine Retention, eine Storage Tier?
2. Werden ILM/TTL-Richtlinien als Code deklariert und automatisch angewendet?
3. PDs werden in Logs/Traces maskiert; außerhalb der „weißen“ Sets verboten?
4. Gibt es persönliche Löschprozesse (SLA, Audit, Quittungen)?
5. Crypto-erasure möglich (per tenant/per dataset keys, KMS/rotation)?
6. Backups: Zeitplan, Verschlüsselung, Wiederherstellungstests, einzelne Schlüssel?
7. Legal Hold/eDiscovery: unterstützt, gegen TTL durchgesetzt, Aktionsprotokolle geführt?
8. Kafka/queues: retention/compaction/tiering gesetzt, hat DLQ separate Richtlinien?
9. Sind Metriken und Alerts für die Einhaltung von Retenschen und Volumina für Schießstände eingerichtet?
10. Die Reviews und Gates in SDLC blockieren Artefakte ohne Retenschen?

16) Mini-Rezepte

16. 1 ClickHouse: „cut the tail“ ist älter als 180 Tage

sql
ALTER TABLE events DELETE WHERE event_date < today() - 180;
OPTIMIZE TABLE events FINAL;

16. 2 Redis: TTL и lazy-purge

bash
SET session:123 value EX 3600
CONFIG SET maxmemory-policy allkeys-lru

16. 3 Tail-Sampling für Trails

yaml tail_sampling:
policies:
- name: keep-errors-and-slow latency_threshold_ms: 500 status_codes: ["5xx"]
rate_limit_per_min: 5000 default_ttl: "7d"

16. 4 Crypto-erasure (Idee)

keys:
dataset: users_pii key_id: kms://pii/users/tenant-42 erase(user_id=42):
rotate_or_destroy (key_id) # inability to restore former purge_indexes blocks ("user _ id = 42")
audit("crypto-erasure", user_id)

Schlussfolgerung

Aufbewahrungsrichtlinien sind das „Skelett“ Ihrer Datenplattform: Sie beschreiben, wie viele verschiedene Datenklassen leben, wo sie sich in jedem Moment befinden, wie sie im Laufe der Zeit billiger werden und wann sie spurlos verschwinden - legal, transparent und überprüfbar. Machen Sie retenschen Politik als Code, verbinden Sie ILM mit Sicherheit und Kosten, integrieren Sie Beobachtbarkeit und Gates - und Sie erhalten ein System, das gleichzeitig effizient, konform und bereit für Wachstum ist.