Expiry by Design: Implementieren Sie globale TTLs für Ihre SaaS-Daten, bevor es die Aufsichtsbehörden vorschreiben

OneDrive hat Dateien gerade ein Ablaufdatum verpasst. Das ist kein Feature – das ist ein Eingeständnis: Die Daten, die Sie behalten, sind die Daten, die Sie verlieren werden. Nach 1.000+ Vorfällen und immer längeren Offenlegungslatenzen ist das Horten von Kundendaten keine neutrale Entscheidung mehr, sondern eine Haftung. Wenn Ihr SaaS noch auf „soft delete“ und unbegrenzte Backups baut, sind Sie nur eine Vorladung, eine Ransomware-Crew oder einen fehlkonfigurierten Bucket von einem vermeidbaren Incident entfernt.

Dieser Beitrag ist ein CTO-Playbook für Expiry by Design: globale Time-to-Live-(TTL)-Policies mit Lösch-SLOs, Legal Holds und prüfbaren Belegen – über alle Stores hinweg, die Sie berühren: OLTP, Blob, Search, Analytics, Logs, Backups und Vendoren. Sie erhalten einen 30-60-90-Tage-Plan und konkrete Implementierungshinweise für Postgres, S3, Elasticsearch, Kafka, BigQuery/Snowflake und Backup-Systeme – plus die Trade-offs, die Sie als Engineering Leader adressieren müssen.

Warum Expiry by Design jetzt

• Breaches reißen nicht ab, Offenlegungen verzögern sich. Öffentliche Übersichten zeigen langsamere statt schnellere Offenlegungen. Das bedeutet: mehr veraltete Daten, länger exponiert. Der einzige Weg, den Blast Radius zu verkleinern, ist: weniger speichern, kürzer speichern.
• Vendoren gehen voran. Microsofts OneDrive mit Dateiexpiry ist ein Signal: Kunden erwarten Retention-Kontrollen. Wenn Ihre App da nicht mithält, verlieren Sie Deals an sicherheitsaffine Wettbewerber.
• Regulierer haben das Regelwerk geschrieben. DSGVO Art. 5(1)(e) (Speicherbegrenzung) und Art. 17 (Löschung), Brazils LGPD Arts. 15–16 und Landesdatenschutzgesetze sind deckungsgleich: Behalten Sie nur, was nötig ist, nur so lange wie nötig – und belegen Sie es.
• KI erhöht die Kosten des Hortens. Kontextfenster und Vektorspeicher verteilen sensible Texte/Bilder überall. Selbst mit „Lockdown Modes“ ist die sicherste Verteidigung, die Daten gar nicht erst zu haben.

Der Entscheidungsrahmen: fünf harte Entscheidungen

Bevor Sie eine Zeile Code schreiben, brauchen Sie präzise Antworten auf Folgendes:

1) Objektklassen und Standard-Aufbewahrungsfristen

Jedes Byte wird einer Objektklasse mit einer Standard-TTL zugeordnet. Starten Sie mit einer einfachen Taxonomie und justieren Sie später:

• Betriebsereignisse/Metriken: 7–30 Tage
• Produkt-Logs/Traces: 14–60 Tage
• Nachrichten/Kommentare von Endnutzern: 90–365 Tage
• Datei-Attachments/Uploads: 90–365 Tage
• Transaktionsdaten (Bestellungen, Rechnungen): gem. Vertrag/Steuerrecht (oft 3–7 Jahre)
• Audit-/Sicherheits-Logs: 365–730 Tage (oder gem. SOC2/ISO-Zeitleiste)

Machen Sie dies zu mandantenbezogenen, planabhängigen Defaults. KMU akzeptieren meist 90–180 Tage; Enterprise wird 7 Jahre und Legal Hold verlangen. Bepreisen Sie das entsprechend.

2) Lösch-SLOs und Ihr „Expiry-Budget“

Verpflichten Sie sich intern auf eine SLO, wie schnell Daten verschwinden, nachdem sie löschreif sind:

• p95 time-to-hard-delete: unter 6 Stunden
• p99 time-to-hard-delete: unter 24 Stunden
• Backups kryptografisch geschreddert: unter 7 Tagen (oder Ihre Backup-SLA)

Veröffentlichen Sie dies in Ihrer DPA. Wenn Sie es noch nicht einhalten können, setzen Sie ein Anfangsziel und instrumentieren Sie die Lücken. Das wird Ihr „Expiry-Budget“.

3) Source of Truth: das Tombstone Ledger

Policy ohne System of Record driftet. Erstellen Sie ein append-only Tombstone Ledger mit object_id, object_type, tenant_id, created_at, expiry_at, legal_hold_flag, reason_code. Lösch-Worker über alle Stores abonnieren dieses Ledger und agieren idempotent. Das Ledger ist Ihr Audit-Trail und Ihr Beleg-Generator.

4) Legal Holds und Ausnahmen

Engineers hassen Ausnahmen; Regulierer lieben sie. Sie brauchen ein legal_hold_flag, das Expiry überall stoppt. Anbindung an Ihr Ticketing/GC-Workflow. Holds müssen befristet sein und in der Produkt-UI sichtbar. Jede Ausnahme kostet; tracken Sie sie.

5) Kundenzusagen

Stellen Sie Aufbewahrungseinstellungen pro Objektklasse in der App bereit. Zeigen Sie anstehende Löschungen an, erlauben Sie Opt-down (kürzere TTL) und planabhängiges Opt-up (längere TTL). Senden Sie Löschbelege mit Objektanzahlen, p95/p99-Zeiten und Abdeckung über Stores. Das ist heute ein Wettbewerbsvorteil in RFPs.

Die Architektur: Policy in Code gießen

Implementieren Sie ein einfaches, langlebiges Muster:

• Retention-Policy-Service: Bewertet Policies und schreibt (object_id, expiry_at) ins Tombstone Ledger, wenn Daten erstellt oder aktualisiert werden. Bewertet bei Zugriff neu, wenn Sie TTLs nach last accessed nutzen.
• Tombstone Ledger: Append-only-Tabelle (z. B. Postgres, nach Monat partitioniert) oder Event-Stream (Kafka). Unveränderliche, signierte Einträge.
• Deletion Orchestrator: Konsumiert Tombstones, fächert zu storespezifischen Workern aus, trackt storeweise SLOs und erzeugt Belege.
• Store-Worker: Postgres-, S3-, Elasticsearch-, Kafka-, BigQuery/Snowflake-, CDN- und Backup-Worker. Idempotent, retry-fähig, mit Dead-Letter-Queues.
• Metrics + Audits: Länge des Lösch-Backlogs, p95/p99 time-to-delete pro Store, % Abdeckung pro Objektklasse, Legal-Hold-Zahlen und Stichproben-Audits (Abwesenheit belegen).

Implementierung, Store für Store

Postgres (OLTP)

• Schema: Fügen Sie expiry_at und tombstoned_at zu löschbaren Tabellen hinzu. Vermeiden Sie Cascades mit Überraschungslöschungen; löschen Sie Kinder explizit zuerst.
• Partitionierung: Partitionieren Sie nach expiry_at oder created_at. Expiry via Partition-Drop ist O(1) und vermeidet Vacuum-Stürme. Wenn Partitionieren nach Expiry schwer ist, pflegen Sie eine separate, partitionierte „Shadow“-Tabelle mit zu löschenden IDs.
• Worker: Batch-Deletes in kleinen Chunks (z. B. 1–5k Zeilen), um Locks kurz zu halten. Nutzen Sie DELETE ... USING mit Join auf eine Temp-Tabelle berechtigter IDs. Überwachen Sie Bloat; lassen Sie Autovacuum auf heißen Tabellen aggressiv laufen.
• Fremdschlüssel: Wenn Eltern länger als Kinder bleiben müssen, invertieren Sie die Beziehung: Kind referenziert Eltern, aber das Kind kann ohne ON DELETE RESTRICT-Deadlocks entfernt werden.

Object Storage (S3/GCS)

• Lifecycle: Nutzen Sie S3-Lifecycle-Regeln, um Objekte zu expiren bei expiry_at. Bei Versioning setzen Sie auch NoncurrentVersionExpiration und entfernen Löschmarkierungen regelmäßig.
• Multipart-Uploads: Lassen Sie unvollständige Multipart-Uploads ablaufen (häufiges Leck). Aktivieren Sie AbortIncompleteMultipartUpload bei 7 Tagen.
• Verschlüsselung: Mandantenspezifische KMS-Schlüssel erlauben Kryptoshredding von Backups durch Schlüsselentzug. Schlüssel mindestens jährlich rotieren.
• CDN: Auf Delete purgen. Setzen Sie Cache-Control max-age unter Ihre kürzeste TTL, außer der Inhalt ist unveränderlich.

Search (Elasticsearch/OpenSearch)

• ILM (Index Lifecycle Management): Roll-over nach Größe/Zeit, dann bei TTL löschen. Für gemischt-mandantige Indizes nach Zeit partitionieren, um Löschen günstig zu machen.
• Deletes: Dokumente per ID aus dem Tombstone-Feed hart löschen, um „Ghost Hits“ in der Warm-Phase zu vermeiden.
• Fallstrick: Snapshots behalten gelöschte Segmente; richten Sie Snapshot-Retention an Ihrer Backup-SLO aus.

Events/Logs (Kafka/Pulsar)

• Retention: Setzen Sie retention.ms pro Topic. Für Topics mit nutzergenerierten Payloads bevorzugen Sie Log-Compaction + kurze Retention oder verschlüsseln Sie am Producer mit mandantenspezifischen Schlüsseln.
• DLQs: Dead-Letter-Queues müssen die kürzest gültige TTL erben; sie sind ein häufiger Dark-Data-Sumpf.

Analytics (BigQuery/Snowflake)

• Partitionierung: Partitionieren Sie Tabellen nach event_date und cluster by tenant_id. Nutzen Sie table TTLs (BigQuery) oder geplantes DROP PARTITION (Snowflake), um Expiry durchzusetzen.
• Materialized Views: Nur über aktuelle Partitionen neu berechnen. Backfill-Jobs dürfen abgelaufene Daten nicht wiederbeleben.
• Model-Trainingssets: Tracken Sie die Herkunft. Wenn Ihre TTL eine Trainingskohorte invalidiert, loggen und retrainen Sie. Besser, als der Rechtsabteilung zu erklären, warum Sie Daten genutzt haben, deren Löschung Sie zugesagt hatten.

Backups

• Gestufte Aufbewahrung: Hot-Backups (7–14 Tage), Warm (30 Tage), kein Cold – außer vertraglich gefordert. Standardmäßig verkürzen.
• Kryptoshredding: Pro Mandant oder Bucket verschlüsseln. Wenn ein Objekt abläuft, seinen Schlüssel an der Backup-SLO-Grenze zur Entziehung vormerken.
• Restore-Disziplin: Restores dürfen keine abgelaufenen Daten reintroduzieren. Nach Restore einen Post-Restore-Expiry-Job laufen lassen, bevor das System live geht.

Verifikation: nicht nur löschen – Abwesenheit beweisen

• Belege: Für jeden Mandanten monatlich Belege ausstellen: abgelaufene Objekte, p95/p99-Löschzeiten, abgedeckte Stores, Ausnahmen (Holds). Das gewinnt RFPs.
• Zufällige Audits: Monatlich 100 abgelaufene IDs stichprobenartig ziehen und aus jedem Store und Analytics-System abrufen versuchen. Es darf nichts zurückkommen. Bei Treffern alarmieren.
• Vendor-Attestierungen: Für kritische Vendoren (z. B. Observability, Support-SaaS, LLM-Provider mit Dateispeicher) SOC/ISO-Reports mit Löschkontrollen einfordern; DPA-Sprache ergänzen, die TTLs und Nachweise binnen 10 Geschäftstagen verlangt.

Was es spart: Kosten und Blast Radius

Framen Sie Expiry nicht nur als Compliance. Es geht auch um Kosten und Uptime.

• S3-Kostenbeispiel: Ein SaaS im Mid-Stage mit 400 TB auf S3 Standard zahlt grob 400.000 GB × $0,023 = $9.200/Monat. Wenn 60% der Attachments älter als 180 Tage nie wieder zugegriffen werden (typisch), entfernt eine 180-Tage-TTL plus Deletes ~240 TB und spart ~$5.520/Monat – vor Request- und Replikationsersparnissen.
• Search und Analytics: Kleinere Indizes und Partitionen bedeuten weniger Nodes, schnellere Queries und günstigere Cluster. 20–40% Infra-Reduktion nach aggressiven TTLs ist nicht ungewöhnlich.
• Incident-Blast-Radius: Wenn ein Angreifer bei T0 landet, existiert alles älter als Ihre TTL nicht mehr zum Exfiltrieren. Das ist die einzige garantierte „Mitigation“.

Trade-offs, die Sie verantworten müssen

• Produkterwartungen: Kunden, die „ein Ticket von 2018 wieder öffnen“ lieben, werden sich beschweren. Bieten Sie Exporte und planabhängige verlängerte Aufbewahrung – aber fallen Sie nicht zur Unsterblichkeit zurück.
• ML-Nutzen vs. Privacy: Kurze TTLs reduzieren historische Trainingsdaten. Kontern Sie mit Sampling, synthetischer Augmentation oder rollierenden Fenstern.
• Komplexität: Cross-Store-Löschorchestrierung ist echte Engineering-Arbeit. Aber sie ist begrenzt und testbar – im Gegensatz zur Haftung, alles für immer zu behalten.

30–60–90 Tage: Ausliefern, ohne sich zu verzetteln

Days 0–30: Bestandsaufnahme und Bausteine

• Inventar: Objektklassen und Stores erfassen (OLTP, Blob, Search, Analytics, Logs, Backups, CDN, LLM/Vectorspeicher, Support-Tools). Rechnen Sie mit 12–20 materiellen Senken in einem typischen SaaS.
• Defaults: Mandantenfähige TTL-Defaults wählen (z. B. 90 Tage Nachrichten/Dateien, 365 Tage Audit, 30 Tage Logs). Schreiben Sie sie in Ihre DPA.
• Tombstone Ledger: In Postgres bauen, monatlich partitioniert. Schreib-Hooks in Codepfade einfügen, die Daten erstellen/ändern.
• Legal Hold: API und UI zum Setzen/Lösen von Holds pro Mandant/Objektklasse mit Ablauf und Begründungen erstellen.
• S3 + Postgres implementieren: Lifecycle-Regeln, Postgres-Batch-Delete-Worker und erste Belege shippen. Interne SLOs setzen (p95: 6h; p99: 24h).

Days 31–60: Erweitern und instrumentieren

• Search + Analytics: ILM auf Indizes anwenden. Analytics-Tabellen nach Datum partitionieren, TTL-Skripte hinzufügen. Queries blocken, die abgelaufene Partitionen umfassen – außer explizit erlaubt.
• Logs/Event-Busse: Kafka/Pulsar-Retention angleichen. Sicherstellen, dass DLQs TTLs erben. Kein PII mehr in Logs shippen ohne definierte TTL.
• Metriken + Alerts: Dashboards für Lösch-Backlog, time-to-delete pro Store, Legal-Hold-Zahlen und Audit-Fehlschläge. Bei p99-Verletzungen pagern.
• Customer UI: Retention-Kontrollen pro Objektklasse und monatliche Belege bereitstellen. Support schulen für „Wo ist meine 2 Jahre alte Datei hin?“

Days 61–90: Den Kreis schließen

• Backups: Retention verkürzen. Kryptoshredding mit mandantenspezifischen Schlüsseln implementieren. Validieren, dass Restore-Pipelines abgelaufene Daten nicht wieder einführen.
• Vendoren: DPAs um TTL- und Attestierungsanforderungen ergänzen. Vendoren tauschen, die nicht mitziehen.
• Chaos-Löschung: Vierteljährliche Übung: einen Mandanten wählen, ein Mass-Expiry-Ereignis simulieren und End-to-End-Löschung innerhalb der SLOs verifizieren.
• Roadmap: Pro Objektklasse last_accessed-Tracking hinzufügen, um von festen TTLs zu aktivitätsbasierten TTLs zu wechseln – wo angemessen.

Häufige Fallstricke (und wie man sie umgeht)

• Soft Delete ist kein Delete. Wenn die Zeile lebt und Indizes sie referenzieren, können Nutzer sie weiterhin indirekt sehen (Counts, Suchtreffer). Soft Delete nur als Übergangszustand; Hard Delete zeitnah einplanen.
• Geisterkopien in Caches. CDN- und Anwendungscaches überleben Daten oft. Binden Sie Cache-TTLs an Ihre kürzeste Daten-TTL und purgen Sie auf Tombstones.
• Search-Reindex belebt Daten wieder. Reindex-Jobs, die alte Snapshots lesen, bringen abgelaufene Dokumente zurück. Reindex nur auf Live-Partitionen scopen.
• Unbegrenzte Exporte. CSV-Exporte, die in S3-„exports/“-Buckets liegen, werden zu einem neuen Dark-Data-Lake. Machen Sie Exporte zu ablaufenden Objekten mit kurzer TTL (7–30 Tage).
• Observability-Sprawl. Ihre APM- und Log-Vendoren speichern oft versehentlich PII. Am Source scrubben, aggressiv maskieren und Vendor-TTLs vertraglich durchsetzen.
• LLM/Vectorspeicher. Wenn Sie User-Content für RAG einbetten, ist die Vektor-DB eine neue Kopie. Machen Sie Vektoren zu First-Class-Objekten mit TTLs und löschen Sie sie gekoppelt an den Tombstone des Originals.

Einordnung in die heutige KI-Risikohaltung

Sogar führende Modellanbieter führen „Lockdown Modes“ ein, um Daten einzuhegen und den Prompt-Injection-Blast-Radius zu reduzieren. Das ist nötig, aber nicht hinreichend. Ein Prompt kann keine Daten leaken, die Sie bereits gelöscht haben. Expiry by Design ist die günstigste und verlässlichste Leitplanke für KI-Features, weil es den Kontext schrumpft, der überhaupt exponiert werden könnte.

Wie „gut“ in Produktion aussieht

• Abdeckung: 100% der Objektklassen sind TTL-gemappt, mit Legal-Hold-Support.
• Latenz: p95 time-to-hard-delete unter 6 Stunden über jeden Store, auditierbar.
• Belege: Mandanten können Löschbelege abrufen und mit einem Klick einen Policy-Report für Auditoren exportieren.
• Backups: Kryptoshred innerhalb von 7 Tagen; Restores führen abgelaufene Daten nicht wieder ein.
• Vendoren: DPAs mit TTL-Klauseln und jährlichen Attestierungen; Red Flags werden an Procurement eskaliert.

So staffen Sie es

Sie brauchen keine neue Plattform. Sie brauchen ein kleines, senioriges Pod – 1 Staff Backend, 1 Infra/SRE, 1 Data Engineer, 0,5 Product/GC – das Ledger, Worker und Vendor-Ausrichtung besitzt. Für US-Teams bietet ein Nearshore-Pod in Brazil 6–8 Stunden Overlap und unserer Erfahrung nach 20–30% niedrigere TCO für diese artige, plumbingschwere, cross-systemische Arbeit. Der Schlüssel ist, ihnen die Autorität zu geben, „nein“ zu unsterblichen Features zu sagen.

Fazit

OneDrives Expiry-Toggle und der nie endende Breach-Ticker sagen dasselbe: Löschung ist jetzt ein Produkt-Requirement. Sie können es mit Ledger, SLOs und Belegen kodifizieren – oder weiter Zinseszins auf Daten zahlen, die Sie nicht brauchen. Shippen Sie Expiry by Design in einem Quartal und machen Sie den nächsten Incident messbar kleiner, bevor er beginnt.

Wichtigste Erkenntnisse

• Standard-TTLs pro Objektklasse definieren, mit planabhängigen Verlängerungen und Legal Holds.
• Tombstone Ledger und Lösch-Orchestrator implementieren; p95/p99 time-to-delete messen.
• Expiry in Postgres, S3, Search, Analytics, Logs, Backups, CDN und bei Vendoren durchsetzen.
• Abwesenheit belegen: Löschbelege senden, Stichproben-Audits durchführen und Vendor-Attestierungen verlangen.
• Mit Trade-offs rechnen: Manche Features und ML-Nutzen schrumpfen; Ihr Risiko und Ihre Kosten auch.