Retention y políticas de retención

1) Principios

1. Purpose & Minimization. Almacenamos exactamente lo que necesitan los objetivos de procesamiento.
2. Policy as Code. Retenshen es una política ejecutable, no un PDF.
3. Defense in Depth. TTL/ILM + cifrado + auditorías + Legal Hold.
4. Reversibility & Proof. La eliminación es verificable: registros de acciones, crypto-shredding, informe de cumplimiento.
5. Cost & Carbon Aware. Retenshen tiene en cuenta $/GB-mes y la huella de carbono de almacenamiento/egress.

2) Clasificación de datos y «mapa Retenshen»

• Operaciones (OLTP): pedidos, pagos, sesiones.
• Analítica (DWH/fechas): eventos, hechos de registro, cortes.
• Personal (PII/finanzas/salud): requiere plazos especiales y derechos de las entidades.
• Técnicos: logs, métricas, tracks, artefactos CI.
• Documentos/medios: WORM/archivo/legasi.

Para cada clase, establezca: propietario, objetivo, marco legal, plazos, nivel de protección, almacenamiento actual y de destino.

3) ILM: ciclo de vida de los datos

1. Ingest (hot) → NVMe/SSD, alta frecuencia de consulta.

2. Warm → menos comúnmente leído, compresión, formatos de columna.

3. Cold/Archive → objeto/cinta, acceso largo.

4. Purge/Delete → eliminación garantizada (réplicas/backups incluidos).

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) Políticas como código (sketches útiles)

4. 1 Política de administración (etiquetas obligatorias/TTL)

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

4. 2 Puerta en CI/CD (Rego) - Prohibición de la deploya sin retencionar

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

4. 3 S3/objeto (fragmento 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) Retention en subprocesos y colas

• `retention. ms`/`retention. bytes 'es un retoque de ventana.
• Compaction (`cleanup. policy = compact '): almacena el último valor de clave.
• Tiered Storage - Llevamos la «cola» a un tiro frío.
• DLQ es un retoque independiente y TTL.

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

• Identifique la retransmisión de los tops clave ≈ la ventana de réplica/conversión de negocios.
• Para eventos, facturación/auditoría: Retinga larga separada o WORM.

6) Bases de datos y retensores

• Partición por fecha/rango, detach & drop de lotes antiguos.
• Campos con fecha: índices para solicitudes TTL.
• Tablas temporales (system-versioned) + polisi purge de versiones antiguas.

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 a nivel de clave (índice TTL de MongoDB, Redis 'EXPIRE', Cassandra TTL).
• Downsampling para métricas (7d crudos → agregados 90d → 365d largos).
• Políticas de retención en TSDB (Influx/ClickHouse Materialized Views con dedoup/agregación).

7) Registros, métricas, tracks

Registros: limitar los campos, enmascarar el PD, TTL 7-30d, archivo 90-180d.
Métricas: de alta frecuencia cruda - 7-14d; downsample (5m/1h) — 90–365д.
Tracks: tail-sampling y almacenamiento de «interesantes» (errores/colas) durante más tiempo.

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) Eliminación: tipos y garantías

Booleano (soft-delete): marca de registro; conveniente para la recuperación, no es adecuado para el «derecho de eliminación».
Físico (hard-delete): eliminación real de datos/versiones/réplicas.
Criptográfico (crypto-erasure): elimina/reemplaza las claves de cifrado, después de lo cual los datos no se recuperan.
En cascada: eliminación de derivaciones de extremo a extremo (cachés, índices, analíticas).

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) Derecho de eliminación, Legal Hold y eDiscovery

Derecho de eliminación/rectificación: SLA de ejecución (por ejemplo, ≤30 días), actividades rastreables, recibos.
Legal Hold: si se solicita legalmente, congelar la eliminación de los conjuntos/claves especificados; política de prioridad sobre TTL.
eDiscovery: directorio de datos, búsqueda de texto completo/atributos por artefactos, exportación en formatos consistentes.

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 archivos vs WORM

Backups - para la recuperación de pérdida/daño; retiro corto, RTO rápido.
Archivos - almacenamiento a largo plazo para auditoría/análisis, acceso barato, largo.
WORM: medios inmutables para el cumplimiento (finanzas/informes); políticas de «escritura-once, read-many».

• No cuente el respaldo como «archivo por siglos».
• Ensayos de recuperación (DR-days), informe de tiempo y plenitud.
• Directorio de backups con retenchen, encriptación y claves separadas del almacenamiento.

11) Privacidad y anonimato

Pseudonimización: enlace PII diferido a través de la tabla de claves (permite crypto-erasure por clave).
Anonimización: técnicas irreversibles (k-anonimato, ruido, generalización); documentar el método, el riesgo de reidentificación y la fecha de caducidad.

12) Monitoreo de cumplimiento e informes

Paneles de control: proporción de datasets con retoque válido, volúmenes por fase de ILM, errores de eliminación.
Alertas: superando el volumen objetivo en el guión caliente, eliminaciones «suspendidas» que expiran por el Legal Hold.
Informes: auditoría mensual de la eliminación (solicitudes colas, plazo medio, fallas), impresión crypto-schredding.

13) Integración en procesos: gates y rugidos

Diseño-puerta: el nuevo dataset no pasa rugido sin 'owner/purpose/retention'.
Release-gate: migraciones que aumentan la retencion sin propietario/justificación - bloqueadas.
Costa-puerta: el volumen en hot/warm excede el presupuesto - el disparador en ILM-apriete.
Seguridad-puerta: prohibición de incluir PD en registros/tracks sin enmascarar y TTL.

14) Anti-patrones

«Guardamos todo para siempre - de repente será útil».
TTL codificadas con rigor en aplicaciones que no están incluidas en la política.
PD en logs y tries sin enmascarar/TTL/borrar.
Eliminación incompleta (dejada en caché/DWH/backups).
La ausencia de Legal Hold es el borrado de datos bajo investigación.
Una clave de cifrado compartida para todo: no se puede «borrar» de forma puntual.
Nula observabilidad: «creemos que hemos eliminado», pero no hay pruebas.

15) Check-list del arquitecto

1. Para cada dataset hay un owner, purpose, classification, retention, storage tier?
2. ¿Las directivas ILM/TTL se declaran como código y se aplican automáticamente?
3. Los PD se enmascaran en los logs/tries; ¿Prohibido fuera de los conjuntos «blancos»?
4. ¿Hay procesos de eliminación personal (SLA, auditoría, recibos)?
5. Crypto-erasure es posible (llaves per-tenant/per-dataset, KMS/rotation)?
6. Backups: ¿horarios, cifrado, pruebas de recuperación, claves individuales?
7. Legal Hold/eDiscovery: ¿soportado, preponderante sobre TTL, los registros de actividad en curso?
8. Kafka/colas: ¿se ha configurado Retingtion/Compaction/Tiering, DLQ tiene directivas separadas?
9. ¿Las métricas y alertas para cumplir con el retensor y los volúmenes por tiras están personalizados?
10. ¿Los rugidos y las gatitas en el SDLC bloquean los artefactos sin retoque?

16) Mini recetas

16. 1 ClickHouse: «corta la cola» más de 180 días

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 para pistas

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 (idea)

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)

Las políticas de retención son el «esqueleto» de su plataforma de datos: describen cuánto viven las diferentes clases de datos, dónde están en cada momento, qué tan baratos son con el tiempo y cuándo desaparecen sin rastro - legal, transparente y verificable. Haga política de retoque como código, conecte ILM con seguridad y costo, active la observabilidad y las puertas, y obtendrá un sistema que sea a la vez eficiente, complaciente y listo para crecer.