Politique de rétention et de rétention

1) Principes

1. Purpose & Minimization. Nous gardons exactement le nombre et le nombre de cibles de traitement nécessaires.
2. Policy as Code. Retenshen est une politique exécutable, pas un PDF.
3. Defense in Depth. TTL/ILM + cryptage + audits + Legal Hold.
4. Reversibility & Proof. La suppression est vérifiable : logs d'action, crypto-shredding, rapport de conformité.
5. Cost & Carbon Aware. Retenshen prend en compte $/Go-mes et l'empreinte carbone de stockage/egress.

2) Classification des données et « carte Rettenschen »

• Opérations (OLTP) : commandes, paiements, sessions.
• Analytique (DWH/dates) : événements, journal des faits, tranches.
• Personal (PII/finance/santé) : exigent des délais et des droits spéciaux pour les sujets.
• Technique : logs, métriques, trajets, artefacts CI.
• Documents/médias : WORM/archives/legasi.

Pour chaque classe, définissez : le propriétaire, l'objectif, le cadre juridique, le calendrier, le niveau de protection, le stockage actuel et ciblé.

3) ILM : cycle de vie des données

1. Ingest (hot) → NVMe/SSD, taux de requête élevé.

2. Warm → moins lisible, compressions, formats de colonne.

3. Cold/Archive → objet/bande, accès long.

4. Purge/Delete → suppression garantie (y compris les répliques/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) Politiques comme code (sketches utiles)

4. 1 Politique d'admission (tags obligatoires/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) - Interdiction du dépravage sans retenchène

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

4. 3 S3/objet (fragment lifecycle)

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) Retraite dans les flux et files d'attente

• `retention. ms`/`retention. bytes 'est un rebord de fenêtre.
• Compaction (`cleanup. policy = compact ') - stocker la dernière valeur de clé.
• Tiered Storage - Emmenez la « queue » dans un tir froid.
• DLQ est un Retenshen séparé et TTL.

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

• Identifiez le retenschen des repères clés ≈ la fenêtre d'affaires du repli/recalculage.
• Pour les événements, la facturation/l'audit est un long retenschen séparé ou WORM.

6) Bases de données et Retenshen

• Lot par date/plage, detach & drop des anciens lots.
• Champs avec date - Index pour les requêtes TTL.
• Tables temporelles (system-versioned) + policy purge des anciennes versions.

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 au niveau des clés (indice MongoDB TTL, Redis 'EXPIRE', Cassandra TTL).
• Downsampling pour métriques (crus 7d → aggrégats 90d → longs 365d).
• Politiques de rétention dans TSDB (Influx/ClickHouse Materialized Views avec déduplication/agrégation).

7) Logs, métriques, tracés

Logs : limiter les champs, masquer le PD, TTL 7-30d, archive 90-180d.
Métriques : bruts haute fréquence - 7-14d ; downsample (5m/1h) — 90–365д.
Tracés : tail-sampling et stockage « intéressant » (erreurs/queues) plus longtemps.

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) Suppression : types et garanties

Booléen (soft-delete) : marquage de l'enregistrement ; commode pour la récupération, ne convient pas au « droit d'effacement ».
Physique (hard-delete) : effacement réel des données/versions/répliques.
Cryptographique (crypto-erasure) : supprime/remplace les clés de cryptage, après quoi les données ne sont pas restaurées.
En cascade : suppression de bout en bout des dérivations (caches, index, analytique).

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) Droit de suppression, Legal Hold et eDiscovery

Droit de suppression/correction : SLA d'exécution (par exemple, ≤30 jours), activités tracées, reçus.
Legal Hold : en cas de demande légale, le gel de la suppression pour les jeux/clés spécifiés ; une politique de priorité sur la TTL.
eDiscovery : catalogue de données, recherche en texte intégral/attribut sur les artefacts, exportation dans des formats cohérents.

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

10) Backaps vs archives vs WORM

Backaps - pour récupérer de la perte/détérioration ; RTO court, rapide.
Archives - stockage à long terme pour l'audit/analyse, bon marché, accès long.
WORM - supports immuables pour la conformité (finances/rapports) ; les politiques « write-once, read-many ».

• Ne comptez pas sur le backup comme « archives pour les siècles ».
• Répétitions de récupération (DR-days), compte rendu du temps et de l'exhaustivité.
• Répertoire de backaps avec retentchen, cryptage et clés séparés du stockage.

11) La vie privée et l'anonymat

Pseudonyme : référence PII différée via une table de clés (permet la crypto-érasure par clé).
Anonymisation : techniques irréversibles (k-anonymat, bruit, généralisation) ; documenter la méthode, le risque de réidentification et la date d'expiration.

12) Suivi de la conformité et rapports

Checkpoints : proportion de datacets avec rétenchen validé, volumes par phases ILM, erreurs de suppression.
Alerts : dépassement du volume cible en tirets chauds, suppressions « suspendues », expiration de Legal Hold.
Rapports : vérification mensuelle de la suppression (colle dans les demandes, durée moyenne, échecs), impression crypto-shredding.

13) Intégration dans les processus : Gates et rhubarbe

Design-gate : le nouveau datacet ne passe pas de rhubarbe sans 'owner/purpose/retentation'.
Release-gate : les migrations qui augmentent la rétention sans propriétaire/justification sont bloquées.
Cost-gate : le volume en hot/warm dépasse le budget - déclencheur sur le durcissement ILM.
Security-gate : Interdiction d'inclure le PD dans les logs/trajets sans camouflage et TTL.

14) Anti-modèles

« Gardons tout pour toujours, tout d'un coup, ça sera utile ».
Les TTL codées rigidement dans les annexes qui ne sont pas incluses dans la politique.
PD dans les logs et les trajets sans masquage/TTL/suppression.
Suppression incomplète (laissée dans le cache/DWH/backaps).
L'absence de Legal Hold est l'effacement des données sous enquête.
Une clé de cryptage partagée sur tout - impossible de « crypto-effacer » ponctuellement.
Zéro observabilité : « nous croyons avoir été supprimés », mais il n'y a aucune preuve.

15) Chèque de l'architecte

1. Pour chaque datacet, y a-t-il un owner, un purpose, une classification, une retraite, un storage tier ?
2. Les politiques ILM/TTL sont-elles déclarées en tant que code et appliquées automatiquement ?
3. Les PD sont masqués dans les logs/remorques ; interdit en dehors des ensembles « blancs » ?
4. Y a-t-il des processus de suppression personnelle (SLA, audit, reçus) ?
5. Crypto-erasure possible (clés per-tenant/per-datacet, KMS/rotation) ?
6. Backups : planning, cryptage, tests de récupération, clés individuelles ?
7. Legal Hold/eDiscovery : sont maintenus, l'emportent sur TTL, les journaux d'actions sont en cours ?
8. Kafka/files d'attente : Retenshen/compaction/tiering, DLQ a-t-il des politiques distinctes ?
9. Les métriques et les alertes pour le respect du rétenschen et les volumes sont-ils personnalisés ?
10. Revew et les gates du SDLC bloquent-ils les artefacts sans retenchen ?

16) Mini recettes

16. 1 ClickHouse : « couper la queue » plus de 180 jours

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 pour les sentiers

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-érasure (idée)

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)

Conclusion

Les politiques de stockage sont le « squelette » de votre plate-forme de données : elles décrivent combien vivent différentes classes de données, où elles se trouvent à chaque instant, comment elles deviennent bon marché avec le temps et quand elles disparaissent sans trace - légalement, de manière transparente et vérifiable. Faites de la politique en tant que code, connectez l'ILM à la sécurité et au coût, activez l'observation et les jeux - et vous obtiendrez un système à la fois efficace, cohérent et prêt à grandir.