Polityka w zakresie zatrzymywania i zatrzymywania

1) Zasady

1. Cel i minimalizacja. Przechowujemy dokładnie to i dokładnie tyle, ile potrzebujemy do celów przetwarzania.
2. Polityka jako kodeks. Retencja jest polityką wykonywalną, a nie plikiem PDF.
3. Obrona w głębi. Szyfrowanie TTL/ILM + audyty + blokada prawna.
4. Odwracalność i dowód. Usunięcie jest weryfikowalne: dzienniki akcji, rozdrabnianie krypto, raport zgodności.
5. Koszt i świadomość emisji dwutlenku węgla. Zatrzymanie uwzględnia miesięczny $/GB i ślad węglowy składowania/wyjścia.

2) Klasyfikacja danych i „mapa Retenschen”

• Operacyjne (OLTP): zlecenia, płatności, sesje.
• Analityczne (DWH/daty): wydarzenia, fakty dziennika, plasterki.
• Osobiste (PII/finanse/zdrowie): wymagają specjalnych warunków i praw osób.
• Techniczne: dzienniki, metryki, trasy, CI artefakty.
• Dokumenty/media: WORM/archive/legasi.

Dla każdej klasy zestaw: właściciel, cel, ramy prawne, daty, poziom ochrony, bieżące i docelowe przechowywanie.

3) ILM Data Lifecycle

1. Ingest (gorący) → NVMe/SSD, wysoka szybkość żądania.

2. Ciepłe → rzadziej czytać, kompresja, formaty kolumn.

3. Cold/Archive → obiekt/taśma, długi dostęp.

4. Oczyścić/usunąć → gwarantowane usunięcie (w tym repliki/kopie zapasowe).

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) Polityka jako kod (przydatne szkice)

4. 1 Polityka przyjmowania (wymagane tagi/TTL)

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

4. 2 Brama w CI/CD (Rego) - zakaz rozmieszczenia bez retencji

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 cyklu życia)

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) Zatrzymanie w wątkach i kolejkach

• "zatrzymanie. zatrzymanie ms '/'. bajty '- retencja okien.
• Zagęszczenie ('oczyszczanie. policy = compact ') - przechowywać ostatnią wartość klucza.
• Magazyn wielopoziomowy - bierzemy „ogon” do zimnej galerii strzelaniny.
• DLQ jest osobnym retencją i TTL.

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

• Zdefiniuj klucz do zatrzymywania tematu, na którym znajduje się okno biznesowe powtórzenia/ponownego obliczenia.
• W przypadku zdarzeń związanych z fakturowaniem/audytem oddzielna długa retencja lub WORM.

6) Bazy danych i przechowywanie

• Podział według daty/zakresu, odłączyć i upuścić stare strony.
• Pola daty - indeksy dla żądań TTL.
• Tabele czasowe (w wersji systemowej) + zasady oczyszczania starszych wersji.

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 na poziomie kluczowym (indeks MongoDB TTL, Redis 'EXPIRE', Cassandra TTL).
• Downsampling do metryki (surowe 7d → kruszywa 90d → długi 365d).
• Zasady zachowania w TSDB (Wpływ/ClickHouse Zmaterializowane widoki z dedup/agregacja).

7) Kłody, mierniki, szlaki

Dzienniki: pola limitu, maska PD, TTL 7-30d, archiwum 90-180d.
Metryka: surowa wysoka częstotliwość - 7-14d; w dół (5m/1h) - 90-365z.
Szlaki: pobieranie próbek ogonowych i dłuższe „interesujące” (błędy/ogony).

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) Usuwanie: rodzaje i gwarancje

Logiczne (delete-soft): oznaczanie rekordu; wygodne do odzyskania, nie pasuje do „prawa do usunięcia”.
Fizyczne (hard-delete) - rzeczywiste usunięcie danych/wersji/replik.
Kryptograficzne (crypto-erasure): usunąć/zastąpić klucze szyfrujące, po których dane nie są przywracane.
Kaskada: końcowe usunięcie pochodnych (bufory, indeksy, analityka).

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) Prawo do usunięcia, legalnego przechowywania i odkrywania

Prawo do usunięcia/poprawności: SLA wykonania (na przykład ≤ 30 dni), śledzenie działań, paragony.
Legal Hold: na żądanie prawne - zamrożenie usunięcia dla określonych zestawów/kluczy; polityka priorytetowa w stosunku do TTL.
eDiscovery: katalog danych, wyszukiwanie artefaktów w pełnym tekście/atrybucie, eksport w spójnych formatach.

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

10) Kopie zapasowe vs archives vs WORM

Kopie zapasowe - do odzyskania po stracie/uszkodzeniu; krótkie retension, szybki RTO.
Archiwum - długoterminowa retencja audytu/analityki, tani, długi dostęp.
WORM - niezmienne media zgodności (finanse/sprawozdawczość); „napisz-raz, czytaj-wiele” polityki.

• Nie zaliczaj kopii zapasowej do „archiwum przez wieki”.
• Próby rekonwalescencji (DR days), raport czasu i kompletności.
• Katalog kopii zapasowych z zachowaniem, szyfrowaniem i klawiszami oddzielnie od pamięci masowej.

11) Prywatność i anonimizacja

Aliasing: PII opóźnione wiązanie za pomocą tabeli kluczy (pozwala na usunięcie krypto przez klucz).
Anonimizacja: nieodwracalne techniki (k-anonimowość, hałas, uogólnienie); Metoda dokumentu, ryzyko ponownej identyfikacji i data wygaśnięcia.

12) Monitorowanie i sprawozdawczość w zakresie zgodności

Panele sterowania: odsetek zbiorów danych z prawidłową retencją, woluminy według faz ILM, błędy usuwania.
Wpisy: przekraczające docelową objętość w gorącym kresce, „zawieszone” skreślenia wygasające Legal Hold.
Raporty: miesięczny audyt usuwania (liczba żądań, średni termin, awarie), wydruk crypto-rozdrabniający.

13) Integracja z procesami: bramy i przeglądy

Design-gate: Nowy zestaw danych nie otrzymuje recenzji bez „właściciela/celu/przechowywania”.
Brama uwolnienia: migracje zwiększające zatrzymanie bez właściciela/uzasadnienia są zablokowane.
Brama kosztowa: objętość w gorącym/ciepłym przekroczy budżet - wyzwalacz do dokręcania ILM.
Brama bezpieczeństwa: zakaz włączenia PD do dzienników/ścieżek bez przebrania i TTL.

14) Anty-wzory

„Trzymamy wszystko na zawsze - nagle się przyda”.
Hard-coded TTL w aplikacjach nie renderowanych w polityce.
PD w logach i śladach bez maskowania/TTL/usuwania.
Niekompletne usunięcie (pozostawione w pamięci podręcznej/DWH/kopie zapasowe).
Brak legalnego przechowywania - usuwanie danych w trakcie dochodzenia.
Jeden wspólny klucz szyfrujący do wszystkiego - niemożliwe jest wskazanie „crypto-erase”.
Zero obserwacji: „wierzymy, że usunięliśmy”, ale nie ma dowodów.

15) Lista kontrolna architekta

1. Dla każdego zbioru danych istnieje właściciel, cel, klasyfikacja, retencja, poziom pamięci masowej?
2. Czy zasady ILM/TTL są deklarowane jako kod i stosowane automatycznie?
3. PD są zamaskowane w logach/torach; zakazane na zewnątrz „białe” zestawy?
4. Czy istnieją procesy usuwania danych osobowych (SLA, audyt, wpływy)?
5. Crypto-erasure possible (per najemca/per dataset keys, KMS/rotation)?
6. Kopie zapasowe: harmonogram, szyfrowanie, testy odzyskiwania, poszczególne klucze?
7. Legal Hold/eDiscovery: Obsługiwane, dominują nad TTL, utrzymywane dzienniki aktywności?
8. Kafka/kolejki: określone zachowanie/zagęszczenie/szeregowanie, DLQ ma oddzielne zasady?
9. Metryki i wpisy dotyczące zgodności z Retenschen i woluminy na galeriach strzeleckich są skonfigurowane?
10. Czy recenzje i bramy w SDLC blokujące artefakty bez Retenschen?

16) Mini przepisy kulinarne

16. 1 ClickHouse: „Odciąć ogon” ponad 180 dni

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 Pobieranie próbek ogonowych dla szlaków

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)

Wnioski

Zasady retencji są „szkieletem” platformy danych: opisują, jak długo żyją różne klasy danych, gdzie są w każdej chwili, jak z czasem stają się tańsze i kiedy znikają bez śladu - legalnie, przejrzysto i weryfikowalnie. Zrób retencję jak kod, połączyć ILM z bezpieczeństwem i kosztami, umożliwić obserwację i bramy - a otrzymasz system, który jest zarówno skuteczny, zgodny i gotowy do rozwoju.