Nonprod, Exports, Caches und Schattenkopien

Prod-Purge ohne Side-Copy-Kontrolle ist eine Bühne. Die eigentliche Persistenz sitzt oft in Dev/Test-Refreshes, CSV-Exports, Notebook-Outputs, Ticket-Anhängen, Suchcaches und „kurzfristigen“ Shares.

zuverlässig in klassischer Tabellen-Lineage.

Lösung: Behandeln Sie Side Copies als First-Class Scope, nicht als Ausnahmen unterhalb der Wahrnehmungsschwelle.

In einem Satz: Behandeln Sie Side Copies als First-Class Scope, nicht als Ausnahmen unterhalb der Wahrnehmungsschwelle.

Problem

Schattenkopien entstehen ohne bösen Willen. Ein Engineer refreshed Nonprod aus Prod. Ein Analyst exportiert eine Population für Legal. Ein BI-Cache hält gestern. Ein Support-Ticket hängt den Screen mit Klartext. Ein Feature-Branch speichert Sample-Parquet im Object Store. Keines dieser Artefakte erscheint zuverlässig in klassischer Tabellen-Lineage.

Typische Ausfälle:

• Nicht-Produktion enthält unmaskierte personenbezogene Daten und überlebt den Produktion-Delete;
• Exports auf Partnerfreigaben/Drive haben kein Expiry und keinen verantwortliche Person;
• Caches und Search Indexes servieren gelöschte Keys weiter;
• Ticket- und Chat-Anhänge bleiben außerhalb des Auskunfts- und Löschrechte-Runs;
• „temporäre“ Sandboxes werden zu Dauerarchiven;
• Masking in Nicht-Produktion ist inkonsistent — Hash hier, Klartext dort.

Diese Serie setzt voraus, dass Scope, Strategie, Plattformpfad und Backup-Contract existieren (Teile 1–4). Klassifikation und Schutz: PII & Privacy Governance. Request-Betrieb: DSDR Governance. Lifecycle: Data Lifecycle & Retention. Hier geht es um Kopien neben dem Hot Path.

Verwandte Nachbarn:

• Backups, Snapshots und Time-Travel-Löschung — Recovery-Residuen;
• Warum Löschung ohne Umfang scheitert — Unknown-Copy-Flag;
• Serie: Löschung, die hält.

Side-Copy-Risiko zeigt sich so:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Prod warehouse     subject purged
Dev refresh        full clone from last Sunday
Analyst export     customer_4812.csv on team share
BI cache           dataset still serves row
Jira attachment    screenshot with email + phone

Fünf Speicherorte. Ein „Prod clean“. Löschung hält nicht.

Eine zweite Signatur ist Refresh Undelete: Nonprod-Jobs als periodischer Undelete. Eine dritte ist Export Amnesia: niemand inventarisiert Download-Pfade. Eine vierte ist Cache Denial: Teams behaupten „nur Cache“, als wäre Cache außerhalb von Privacy.

Side Copies sind oft die Stelle, an der gut gemeinte Self-Service-Kultur Governance bricht: schnelle Exports ohne Steward, Sandboxes ohne Expiry, „kurz kopieren für den Workshop“. Die Serie fordert keinen Stopp von Self-Service — sie fordert Inventory und Disposition, bevor der DSDR-Claim „gelöscht“ stehen darf.

Entscheidung

Behandeln Sie Side Copies als First-Class Scope, nicht als Ausnahmen unterhalb der Wahrnehmungsschwelle.

Drei Prinzipien:

1. Was Identifier halten kann, gehört ins Inventory. Nonprod, Export, Cache, Attachment, Notebook, Sandbox — gleiche Disziplin wie Warehouse-Tabellen.
2. Nonprod folgt denselben Lösch- oder Masking-Verträgen. Prod-Delete ohne Nonprod-Aktion ist ein bekannter Defect, kein Randfall.
3. Exports brauchen Owner, Zweck, Expiry. Dauerhafte Shares ohne Steward sind unkontrollierte Archive.

Praktische Steuerungen: Refresh-Pipelines mit Delete-/Mask-Hooks; Export-Register; Cache-TTL und Purge-APIs; Attachment-Scanning für DSDR-Cases; Verbot unmaskierter Prod-Clones ohne Freigabe.

Priorisieren Sie nach Klartext und Reichweite, nicht nach „offiziell vs. inoffiziell“. Ein Team-Share mit voller Adressliste ist oft riskanter als eine maskierte Dev-Tabelle. Caches sind keine Ausnahmeklasse: was Nutzer sehen oder exportieren können, fällt unter denselben Claim wie Warehouse-SQL. Wo Scanning von Tickets und Drives rechtlich oder organisatorisch eng ist, dokumentieren Sie den Kontrollersatz (z. B. Policy-Verbot von PII-Anhängen plus Stichproben) — Lücken im Inventory müssen sichtbar bleiben, nicht verschwinden.

Checkliste

Inventarisieren Sie Side Copies für den Pilot:

• listen Sie Nicht-Produktion-Umgebungen und Refresh-Quellen;
• prüfen Sie Masking-/Synthetic-Data-Status je Umgebung;
• erfassen Sie bekannte Export-Kanäle (BI download, SQL client, notebooks, ETL dumps);
• listen Sie Cache-Typen (BI, search, CDN, app);
• markieren Sie Collaboration-Stores (Drive, SharePoint, ticket attachments);
• flaggen Sie Sandboxes und Feature-Branch-Stores;
• ordnen Sie je Eintrag verantwortliche Person, Expiry, Disposition (delete, mask, expire, accept-risk);
• verdrahten Sie Nicht-Produktion- und Export-Steps an das Cross-Platform Runbook;
• priorisieren Sie nach Blast Radius und Klartext-Wahrscheinlichkeit;
• stoppen Sie, wenn die heißesten fünf Side-Copy-Klassen Owner und Aktion haben.

Artefakt

Erstellen Sie ein Side-Copy Inventory mit einer Zeile pro Kopienklasse oder konkretem Store.

Pflichtfelder:

• Copy-ID und Label;
• Klasse: nonprod, export, cache, attachment, notebook, sandbox, share, other;
• Quelle des Refresh/Exports;
• Masking-Status: masked, synthetic, cleartext, unknown;
• Owner und Steward;
• Identifier-Typen vorhanden;
• Expiry / TTL / letzte Nutzung;
• Disposition und Runbook-Step;
• Nachweis-Methode;
• Risk-Tags: cleartext-pii, refresh-undelete, no-owner, no-expiry;
• Status: inventoried, controlled, retired.

Ergebnisse: sichtbare Schattenlandschaft, weniger Refresh-Undeletes, steuerbare Exports und Caches.

Tools

Nonprod-Refresh-Orchestrierung. Masking-/Synthetic-Data-Tooling. DLP oder Share-Inventare für Exports. BI- und App-Cache-Admin. Ticket-/Drive-Suche nach Identifiern (Least Privilege, need-to-know). Katalog-Einträge für genehmigte Sandboxes.

Ressourcen

Interne Quellen: Nonprod-Refresh-Docs, Masking-Standards, Export-Policies, Cache-Runbooks, Collaboration-Retention, Incidents „found customer data on share“.

Nachbarn: PII & Privacy Governance, DSDR Governance, Data Lifecycle & Retention, Backups, Snapshots und Time-Travel-Löschung, Serie: Löschung, die hält.