מדיניות שימור ושמירה

1) עקרונות

1. מזעור תכלית. אנחנו מאחסנים בדיוק את זה ובדיוק כמו שאנחנו צריכים למטרות עיבוד.
2. מדיניות כקוד. שימור הוא מדיניות הניתנת להפעלה, לא PDF.
3. הגנה בעומק. TTL/ILM + הצפנה + ביקורת + Ligal Hold.
4. ההוכחה ההופכית. מחיקה ניתנת לאימות: יומני פעולה, גריסת קריפטו, דו "ח ציות.
5. מודעות עלות ופחמן. שימור לוקח בחשבון $/GB-חודש וטביעת רגל פחמן של אחסון/יציאה.

2) סיווג נתונים ו ”מפת רטנשן”

• הזמנות, תשלומים, הפעלות.
• אנליטי (DWH/Dates): אירועים, עובדות רישום, פרוסות.
• אישי (PII/Finance/Health): דורש מונחים מיוחדים וזכויות של נושאים.
• יומנים, מדדים, שבילים, חפצי מודיע.
• מסמכים/מדיה: תולעת/ארכיון/לגאסי.

לכל כיתה, קבע: בעלים, מטרה, מסגרת משפטית, תאריכים, רמת הגנה, אחסון נוכחי ומטרה.

3) מחזור חיים של נתוני ILM

1. Innight (חם) # NVMe/SSD, שיעור בקשה גבוה.

2. Love # פחות קריאה, דחיסה, תבניות עמודות.

3. Cold/Archive = אובייקט/סרט, גישה ארוכה.

4. טיהור/מחיקה * מחיקה מובטחת (כולל העתקים/גיבויים).

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) מדיניות כקוד (סקיצות שימושיות)

4. 1 מדיניות כניסה (תגיות נדרשות/TTL)

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

4. 2 שער ב CI/CD (Rego) - איסור פריסה ללא חזרה

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

4. 3 S3/object (שבר של מחזור חיים)

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) שימור בחוטים ובתורים

• "המצאה מחדש. שמירת גב '/'. ביטים - שימור חלונות.
• דחיפה ("לנקות. מדיניות = compact ') - לאחסן את ערך המפתח האחרון.
• אחסון מסודר - אנחנו לוקחים את ”הזנב” למטווח ירי קר.
• DLQ הוא שמירה נפרדת ו-TTL.

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

• הגדר את שמירת נושא המפתח לחלון עסקי ההילוך החוזר/חישוב מחדש.
• לאירועי חיוב/ביקורת, שימור ארוך נפרד או תולעת.

6) מסדי נתונים ושימור

• מחלקים לפי טווח/תאריך, מנתקים צדדים ישנים.
• שדות תאריך - אינדקסים לבקשות TTL.
• טבלאות זמן (מבוססות מערכת) + מדיניות טיהור של גרסאות ישנות יותר.

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 ברמת המפתח (מדד MongodB TTL, Redis 'EXPIRE', Cassandra TTL).
• Downsampling for metrics (גלם 7d = aggregates 90d = long 365d).
• מדיניות השמירה ב-TSDB (Impution/Clickhouse Materialized Views עם dedup/aggregation).

7) בולי עץ, מדדים, שבילים

יומנים: מגביל שדות, מסכת PD, TTL 7-30d, ארכיון 90-180d.
מדדים: תדר גבוה גולמי - 7-14d; downsample (5 m/1h) - 90-365.
שבילים: דגימת זנב ושמירה על ”מעניין” (חרקים/זנבות) ארוך יותר.

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) הסרה: סוגים ואחריות

לוגי (רך-למחוק): סימון שיא; נוח להתאוששות, לא מתאים ל ”זכות למחוק”.
מחיקה ממשית של נתונים/גרסאות/העתקים.
Cryptographic (מחיקת הצפנה): למחוק/להחליף את מפתחות ההצפנה, שלאחריהם המידע לא ישוחזר.
מחיקה מקצה לקצה של נגזרות (מטמונים, אינדקסים, אנליטיקה).

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) זכות הסרה, אחיזה משפטית ודיסקברי

זכות למחוק/נכון: SLA של ביצוע (לדוגמה, 30 יום), פעולות מאותתות, קבלות.
Hold חוקי: על בקשה חוקית - הקפאת מחיקה עבור סטים/מפתחות מוגדרים; מדיניות עדיפות על טי-טי-אל.
eDiscovery: קטלוג נתונים, חיפוש חפצים בטקסט מלא/מאפיין, יצוא בפורמטים עקביים.

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

10) גיבויים נגד ארכיונים נגד תולעת

גיבויים - להתאושש מאובדן/נזק; חזרה קצרה, RTO מהיר.
ארכיונים - שימור ארוך טווח לביקורת/אנליטיקה, גישה זולה וארוכה.
תולעת - מדיה בלתי ניתנת לשינוי לציות (מימון/דיווח); ”לכתוב פעם אחת, לקרוא הרבה” מדיניות.

• אל תחשיב את הגיבוי כ ”ארכיון במשך מאות שנים”.
• חזרות התאוששות (ימי ד ”ר), דו” ח זמן ושלמות.
• ספרייה של גיבויים עם אחסון, הצפנה ומפתחות בנפרד מהמחסן.

11) פרטיות ואנונימיות

Aliasing: PII עיכב קשירה באמצעות טבלת מפתח (מאפשרת מחיקת הצפנה באמצעות מפתח).
אנונימיות: טכניקות בלתי הפיכות (k-אנונימיות, רעש, הכללה); שיטת מסמך, סיכון לזיהוי מחדש ותאריך פקיעה.

12) מעקב ודיווח צייתName

לוחות בקרה: פרופורציה של נתונים עם שמירה תקפה, כרכים על ידי שלבי ILM, שגיאות מחיקה.
התראות: עולה על נפח היעד בלוח המחוונים החם, ”תלוי” מחיקות פג תוקף משפטי Hold.
דיווחים: ביקורת מחיקה חודשית (מספר בקשות, טווח ממוצע, כשלים), תדפיס גריסת קריפטו.

13) שילוב בתהליכים: שערים וביקורות

עיצוב-שער: הנתונים החדשים לא מקבלים סקירה ללא ”בעלים/מטרה/שימור”.
שחרור שער: הגירה המגבירה את השמירה ללא בעלים/הצדקה חסומה.
עלות-שער: נפח בחום/חם עולה על התקציב - הדק עבור הידוק ILM.
אבטחה-שער: איסור על הכללה של PD ביומנים/שבילים ללא הסוואה ו TTL.

14) אנטי דפוסים

”אנחנו שומרים הכל לנצח - זה פתאום יהיה שימושי”.
טי-טי-אל מקודד ביישומים שלא ניתנים במדיניות.
PD ברישומים ועקבות ללא מיסוך/TTL/מחיקה.
מחיקה לא שלמה (שמאלה במטמון/DWH/גיבויים).
מחיקת נתונים תחת חקירה.
מפתח הצפנה נפוץ לכל דבר - זה בלתי אפשרי להצביע ”למחוק”.
אפס יכולת תצפית: ”אנחנו מאמינים שהסרנו”, אבל אין ראיות.

15) רשימת אדריכלים

1. לכל נתונים יש בעלים, מטרה, סיווג, שימור, אחסון?
2. האם מדיניות ILM/TTL מוכרזת כקוד ומופעלת באופן אוטומטי?
3. PD מוסווים ברישומים/רצועות; נאסר מחוץ לסטים ”לבנים”?
4. האם יש תהליכי מחיקה אישיים (SLA, ביקורת חשבונות, קבלות)?
5. מחיקת הצפנה אפשרית (לכל דייר/פר נתונים, KMS/rotation)?
6. גיבויים: לוח זמנים, הצפנה, בדיקות התאוששות, מפתחות אישיים?
7. Hold/eDiscovery: נתמך, גובר על TTL, רישומי פעילות נשמרים?
8. קפקא/תורים: שמירה/קומפוזיציה/הדרכה, ל-DLQ יש מדיניות נפרדת?
9. מדדים והתראות עבור ציות עם רטנשן וכרכים על גלריות ירי מוגדרים?
10. האם ביקורות ושערים ב-SDLC חוסמים חפצים ללא Retenschen?

16) מתכונים קטנים

16. 1 Clickhouse: ”לחתוך את הזנב” מעל 180 ימים

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

16. 2 רדיס: TTL עצלן-טיהור

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

16. דגימת זנב 3 עבור שבילים

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 מחיקה מוצפנת (רעיון)

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)

סיכום

מדיניות השמירה היא ה ”שלד” של פלטפורמת המידע שלכם: הם מתארים כמה זמן חיים כיתות שונות של נתונים, איפה הם נמצאים בכל רגע, איך הם נהיים זולים יותר עם הזמן, וכשהם נעלמים ללא עקבות - באופן חוקי, שקוף ומאומת. הפוך את שמירת מדיניות כמו קוד, לחבר ILM עם אבטחה ועלות, לאפשר תצפית ושערים - ואתה מקבל מערכת שהיא גם יעילה, צייתנית ומוכנה לגדול.