Saklama ve alıkoyma politikaları

1) İlkeler

1. Amaç ve Küçültme. Tam olarak bunu ve tam olarak işlem amaçları için ihtiyaç duyduğumuz kadarını saklıyoruz.
2. Kod olarak politika. Tutma, PDF değil yürütülebilir bir ilkedir.
3. Derinlikte savunma. TTL/ILM + şifreleme + denetimler + Yasal Bekletme.
4. Tersinirlik ve Kanıt. Silme doğrulanabilir: eylem günlükleri, kripto parçalama, uyumluluk raporu.
5. Maliyet ve Karbon Farkındalığı. Saklama, $/GB aylık ve depolama/çıkış karbon ayak izini dikkate alır.

2) Veri sınıflandırması ve "Retenschen haritası"

• Operasyonel (OLTP): siparişler, ödemeler, oturumlar.
• Analitik (DWH/tarihler): olaylar, günlük bilgileri, dilimler.
• Kişisel (PII/finans/sağlık): Konuların özel şartlarını ve haklarını gerektirir.
• Teknik: günlükler, metrikler, izler, CI eserleri.
• Belgeler/medya: WORM/arşiv/legasi.

Her sınıf için şunları belirleyin: sahip, amaç, yasal çerçeve, tarihler, koruma düzeyi, geçerli ve hedef depolama.

3) ILM Veri Yaşam Döngüsü

1. Ingest (sıcak) - NVMe/SSD, yüksek istek oranı.

2. Sıcak - daha az sıklıkla okuma, sıkıştırma, sütun formatları.

3. Soğuk/Arşiv - nesne/bant, uzun erişim.

4. Temizleme/Silme - garantili silme (replikalar/yedeklemeler dahil).

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) Kod olarak politikalar (kullanışlı eskizler)

4. 1 Kabul politikası (gerekli etiketler/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) - Retansiyon olmadan dağıtım yasağı

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

4. 3 S3/object (yaşam döngüsü parçası)

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) Konu ve kuyruklarda tutma

• 'retention. ms'/' tutma. bayt '- pencere tutma.
• Sıkıştırma ('temizleme. policy = compact ') - son anahtar değerini saklayın.
• Katmanlı Depolama - "kuyruk'u soğuk bir çekim galerisine götürüyoruz.
• DLQ ayrı bir saklama ve TTL'dir.

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

• Yeniden oynatma/yeniden hesaplama iş penceresi ≈ anahtar konu tutma tanımlayın.
• Faturalandırma/denetim etkinlikleri için ayrı bir uzun saklama veya WORM.

6) Veritabanları ve saklama

• Tarihe/aralığa göre bölümleme, eski partileri ayırın ve bırakın.
• Tarih alanları - TTL istekleri için endeksler.
• Geçici tablolar (sistem sürümlü) + eski sürümlerin temizleme ilkeleri.

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;

• Anahtar seviyesinde TTL (MongoDB TTL index, Redis 'EXPIRE', Cassandra TTL).
• Metrikler için altörnekleme (ham 7d, 90d, uzun 365d toplar).
• TSDB'de saklama politikaları (Etki/ClickHouse, dedup/aggregation ile Materyalize Görünümler).

7) Günlükler, metrikler, izler

Günlükler: limit alanları, maske PD, TTL 7-30d, arşiv 90-180d.
Metrikler: ham yüksek frekanslı - 7-14d; Alt örnek (5m/1h) - 90- 365д.
Yollar: kuyruk örnekleme ve "ilginç" (bugs/tails) daha uzun tutma.

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) Kaldırma: türleri ve garantileri

Mantıksal (soft-delete): bir kaydı işaretleme; Kurtarma için uygun, "silme hakkı'na uymuyor.
Fiziksel (sabit silme) - verilerin/sürümlerin/kopyaların gerçek olarak silinmesi.
Kriptografik (kripto silme): Şifreleme anahtarlarını silin/değiştirin, ardından veriler geri yüklenmez.
Cascade: Türevlerin uçtan uca silinmesi (önbellekler, indeksler, analizler).

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) Kaldırma, Yasal Tutma ve e-Keşif Hakkı

Silme/düzeltme hakkı: Yürütmenin SLA'sı (örneğin, ≤30 gün), izlenen eylemler, makbuzlar.
Yasal Bekletme: yasal talep üzerine - belirtilen setler/anahtarlar için silme dondurma; TTL'ye göre öncelikli politika.
eDiscovery: veri kataloğu, tam metin/nitelik artifact araması, tutarlı formatlarda dışa aktarma.

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

10) Yedeklemeler vs arşivler vs WORM

Yedeklemeler - kayıp/hasardan kurtulmak için; Kısa retansiyon, hızlı RTO.
Arşivler - denetim/analitik için uzun süreli saklama, ucuz, uzun erişim.
WORM - uyumluluk için değişmez medya (finans/raporlama); "Bir kez yaz, çok oku" politikaları.

• Yedeklemeyi "yüzyıllarca arşiv'olarak saymayın.
• Kurtarma provaları (DR günleri), zaman ve bütünlük raporu.
• Saklama, şifreleme ve anahtarların depodan ayrı olduğu yedekleme dizini.

11) Gizlilik ve anonimleştirme

Aliasing: PII, anahtar tablosu üzerinden gecikmeli bağlanma (anahtarla kripto silinmesine izin verir).
Anonimleştirme: geri dönüşü olmayan teknikler (k-anonimlik, gürültü, genelleme); Belge yöntemi, yeniden tanımlama riski ve son kullanma tarihi.

12) Uyumluluk izleme ve raporlama

Kontrol panelleri: Geçerli tutma özelliğine sahip veri kümelerinin oranı, ILM aşamalarına göre hacimler, silme hataları.
Uyarılar: Sıcak çizgideki hedef hacmi aşan, Yasal Bekletme süresi dolan "asılı" silme işlemleri.
Raporlar: aylık silme denetimi (istek sayısı, ortalama vade, arızalar), kripto parçalama çıktısı.

13) Süreçlere entegrasyon: kapılar ve incelemeler

Design-gate: Yeni veri kümesi 'sahibi/amacı/tutma' olmadan bir inceleme almaz.
Release-gate: Sahibi/gerekçesi olmadan elde tutmayı artıran geçişler engellenir.
Maliyet kapısı: sıcak/ılık hacim bütçeyi aşıyor - ILM sıkılaştırma için tetikleyici.
Güvenlik kapısı: Kılık değiştirmeden ve TTL olmadan günlüklere/parkurlara PD dahil edilmesinin yasaklanması.

14) Anti-desenler

"Her şeyi sonsuza dek saklıyoruz - aniden işe yarayacak".
Poliçelerde işlenmeyen uygulamalarda sabit kodlu TTL'ler.
PD günlüklerde ve izlerde maskeleme/TTL/silme olmadan.
Eksik silme (sol önbellek/DWH/yedekleme).
Yasal Tutma Eksikliği - soruşturma altında veri silme.
Her şey için ortak bir şifreleme anahtarı - "kripto silme'yi işaret etmek imkansızdır.
Sıfır gözlemlenebilirlik: "Kaldırdığımıza inanıyoruz", ancak kanıt yok.

15) Mimar kontrol listesi

1. Her veri kümesi için bir sahip, amaç, sınıflandırma, saklama, depolama katmanı var mı?
2. İLM/TTL poliçeleri kod olarak ilan edilip otomatik olarak uygulanıyor mu?
3. PD'ler günlüklerde/izlerde maskelenir; "Beyaz" setlerin dışında yasaklanmış mı?
4. Kişisel silme işlemleri var mı (SLA, denetim, makbuzlar)?
5. Kripto silme mümkün mü (kiracı başına/veri kümesi anahtarları başına, KMS/rotasyon)?
6. Yedeklemeler: zamanlama, şifreleme, kurtarma testleri, bireysel anahtarlar?
7. Legal Hold/eDiscovery: Desteklenen, TTL'ye üstün gelen, faaliyet kayıtları tutulan?
8. Kafka/kuyruklar: belirli tutma/sıkıştırma/katmanlama, DLQ'nun ayrı politikaları var mı?
9. Retenschen ile uyumluluk için metrikler ve uyarılar ve çekim galerilerindeki hacimler yapılandırıldı mı?
10. SDLC'deki incelemeler ve kapılar Retenschen olmadan eserleri engelliyor mu?

16) Mini tarifler

16. 1 ClickHouse: 180 gün boyunca 'Kuyruğu kes'

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

16. 2 Redis: TTL и tembel-tasfiye

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

16. 3 Yollar için kuyruk örnekleme

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 Kripto silme (fikir)

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)

Sonuç

Saklama politikaları, veri platformunuzun "iskeleti'dir: farklı veri sınıflarının ne kadar süre yaşadığını, her an nerede olduklarını, zaman içinde nasıl daha ucuz olduklarını ve iz bırakmadan kaybolduklarında - yasal, şeffaf ve doğrulanabilir şekilde - açıklar. Saklamayı kod gibi bir politika haline getirin, ILM'yi güvenlik ve maliyetle bağlayın, gözlemlenebilirliği ve kapıları etkinleştirin - hem etkili, uyumlu hem de büyümeye hazır bir sistem elde edersiniz.