Politici de păstrare și păstrare

1) Principii

1. Scop & Minimizare. Stocăm exact acest lucru și exact atât cât avem nevoie în scopuri de prelucrare.
2. Politica ca cod. Retenția este o politică executabilă, nu un PDF.
3. Apărare în profunzime. TTL/ILM + criptare + audituri + Legal Hold.
4. Reversibilitate și dovadă. Ștergerea este verificabilă: jurnale de acțiune, mărunțire cripto, raport de conformitate.
5. Cost & Carbon Aware. Retenția ia în considerare $/GB-lună și amprenta de carbon de stocare/ieșire.

2) Clasificarea datelor și „Harta Retenschen”

• Operațional (OLTP): comenzi, plăți, sesiuni.
• Analitic (DWH/date): evenimente, log fapte, felii.
• Personal (PII/finanțe/sănătate): necesită termeni și drepturi speciale ale subiecților.
• Tehnic: busteni, metrici, trasee, artefacte CI.
• Documente/media: WORM/archive/legasi.

Pentru fiecare clasă, setați: proprietar, scop, cadru legal, date, nivel de protecție, stocare curentă și țintă.

3) Ciclul de viață al datelor ILM

1. Ingera (fierbinte) → NVMe/SSD, rata mare de solicitare.

2. Cald → mai rar citit, compresie, formate de coloane.

3. Rece/Arhiva → obiect/bandă, acces lung.

4. Purge/Ștergeți → ștergere garantată (inclusiv replici/copii de rezervă).

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) Politici ca cod (schițe utile)

4. 1 Politica de admitere (etichete necesare/TTL)

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

4. 2 Poarta în CI/CD (Rego) - interzicerea implementării fără retensiune

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

4. 3 S3/object (fragment din ciclul de viață)

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) Păstrarea în fire și cozi

• "retenţie. ms '/' retenție. bytes "- retenție fereastră.
• Compactare ("curățare. policy = compact ') - stochează ultima valoare cheie.
• Depozitare pe niveluri - ducem „coada” la o galerie de fotografiere rece.
• DLQ este o retenție separată și TTL.

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

• Definiți retenția subiectului cheie ≈ fereastra de reluare/recalculare a afacerii.
• Pentru evenimente de facturare/audit, o retenție lungă separată sau WORM.

6) Baze de date și retenție

• Partiționarea după dată/interval, detașarea și plasarea părților vechi.
• Câmpuri de date - indici pentru solicitări TTL.
• Tabele temporale (versiuni de sistem) + politici de epurare a versiunilor mai vechi.

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 la nivel cheie (indicele TTL MongoDB, Redis „EXPIRĂ”, Cassandra TTL).
• Sub-eşantionare pentru măsurători (brut 7d → agregate 90d → lung 365d).
• Politici de retenție în TSDB (Influence/ClickHouse Vizualizări materializate cu dedup/agregare).

7) Busteni, metrici, trasee

Jurnale: câmpuri limită, mască PD, TTL 7-30d, arhivă 90-180d.
Valori: brut de înaltă frecvență - 7-14d; downsample (5m/1h) - 90- 365д.
Trasee: prelevarea de probe și păstrarea „interesantă” (bug-uri/cozi) mai mult.

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) Îndepărtarea: tipuri și garanții

Logic (soft-delete): marcarea unei înregistrări; convenabil pentru recuperare, nu se potrivește cu „dreptul de a șterge”.
Fizic (hard-delete) - ștergerea efectivă a datelor/versiuni/replici.
Criptografic (cripto-ștergere): ștergeți/înlocuiți cheile de criptare, după care datele nu sunt restaurate.
Cascadă: ștergerea end-to-end a derivațiilor (cache-uri, indici, analitice).

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) Dreptul de a elimina, Legal Hold și eDiscovery

Dreptul de a șterge/corecta: SLA de execuție (de exemplu, ≤30 zile), acțiuni urmărite, chitanțe.
Legal Hold: la cerere legala - stergere congela pentru seturi/chei specificate; politica de prioritate față de TTL.
eDiscovery: catalog de date, căutare artefact full-text/atribut, export în formate consistente.

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

10) Backup-uri vs arhive vs WORM

Backup-uri - pentru a recupera din pierderi/daune; retensiune scurtă, RTO rapid.
Arhive - retenție pe termen lung pentru audit/analiză, acces ieftin, lung.
WORM - medii imuabile pentru conformitate (finanțare/raportare); „scrie-o dată, citeşte-multe” politici.

• Nu conta backup-ul ca o „arhivă de secole”.
• Repetiții de recuperare (zile DR), raport de timp și completitudine.
• Director de backup-uri cu retenție, criptare și chei separat de stocare.

11) Confidențialitate și anonimizare

Aliasing: PII întârziat de legare prin intermediul tabelului cheie (permite cripto-ștergere prin cheie).
Anonimizare: tehnici ireversibile (k-anonimat, zgomot, generalizare); Metoda documentului, riscul de reidentificare și data expirării.

12) Monitorizarea și raportarea conformității

Panouri de control: proporția de seturi de date cu retenție validă, volume de faze ILM, erori de ștergere.
Alerte: depășirea volumului țintă în liniuța fierbinte, „atârnă” ștergerile care expiră Legal Hold.
Rapoarte: audit lunar de ștergere (număr de cereri, termen mediu, eșecuri), imprimare cripto-mărunțire.

13) Integrarea în procese: porți și recenzii

Design-gate: Noul set de date nu primește o revizuire fără „proprietar/scop/retenție”.
Release-gate: migrațiile care cresc reținerea fără proprietar/justificare sunt blocate.
Cost-poarta: volumul în cald/cald depășește bugetul - declanșator pentru strângerea ILM.
Poarta de securitate: interzicerea includerii PD în bușteni/trasee fără deghizare și TTL.

14) Anti-modele

„Păstrăm totul pentru totdeauna - va veni brusc la îndemână”.
TTL-uri codate dur în aplicații care nu sunt redate în politici.
PD în jurnale și urme fără mascare/TTL/ștergere.
Ștergere incompletă (stânga în memoria cache/DWH/backup-uri).
Lipsa Legal Hold - ștergerea datelor în curs de investigare.
O cheie de criptare comună pentru tot - este imposibil să se indice „cripto-șterge”.
Observabilitate zero: „credem că am îndepărtat”, dar nu există dovezi.

15) Lista de verificare arhitect

1. Pentru fiecare set de date există un proprietar, scop, clasificare, păstrare, nivel de stocare?
2. Sunt politicile ILM/TTL declarate ca cod și aplicate automat?
3. PD-urile sunt mascate în jurnale/piste; interzis în afara seturilor „albe”?
4. Există procese de ștergere personale (SLA, audit, chitanțe)?
5. Cripto-ștergere posibilă (pe chiriaș/pe chei de seturi de date, KMS/rotație)?
6. Backup-uri: program, criptare, teste de recuperare, chei individuale?
7. Legal Hold/eDiscovery: Suportat, prevalează asupra TTL, jurnalele de activitate menținute?
8. Kafka/cozi: retenție/compactare/niveluri specificate, DLQ are politici separate?
9. Măsurători și alerte pentru respectarea Retenschen și volume pe galerii de fotografiere sunt configurate?
10. Sunt recenzii și porți în artefacte de blocare SDLC fără Retenschen?

16) Mini rețete

16. 1 ClickHouse: „Taie coada” peste 180 de zile

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

16. 2 Redis: TTL и leneș-purjare

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

16. 3 Prelevarea de probe pentru trasee

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 Ștergere cripto (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)

Concluzie

Politicile de retenție sunt „scheletul” platformei dvs. de date: ele descriu cât de mult trăiesc diferite clase de date, unde se află în fiecare moment, cum devin mai ieftine în timp și când dispar fără urmă - legal, transparent și verificabil. Asigurați-păstrarea unei politici precum codul, conectați ILM cu securitatea și costul, permiteți observabilitatea și porțile - și obțineți un sistem care este atât eficient, conform și gata să crească.