מדיניות שימור נתונים: התאמה ל-GDPR, ל-152-FZ ול-HIPAA

Data retention: היכן נשבר אחסון הנתונים האישיים

נתונים עודפים מופיעים לא בגלל זרימת משתמשים, אלא בגלל היעדר החלטה על תקופות שמירה. לוגים של האפליקציה, טבלאות טרנזקציות, ייצוא למעגל האנליטי, סנאפשוטים ועותקי גיבוי נכתבים על ידי שירותים שונים ונותרים מונחים עד שנגמר המקום בדיסק. פורמלית זהו אחסון של נתונים אישיים, בפועל — מזבלה ללא בעלים וללא תאריך.

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

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

הסיבה בדרך כלל אחת — מדיניות data retention לא תוכננה כחלק מסכימת הנתונים, היא הורכבה מלמעלה כשהרגולטור שאל את השאלה.

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

מה נותנת מדיניות אחסון נתונים אישיים מנוהלת

כאשר לכל מערך נתונים יש בעלים, תוחלת חיים וטריגר מחיקה, המאגר מפסיק להיות מזבלה "ליתר ביטחון". מדיניות שמירה (data retention) מתארת לא רק את התקופה עצמה, אלא גם מה קורה בתום התקופה: מחיקה בלתי הפיכה, אנונימיזציה או העברה לארכיון עם גישה מוגבלת. רק אחרי זה מינימיזציית הנתונים מפסיקה להיות הצהרה והופכת לכלל עובד.

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

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

השלישי — הסרת סיווג ההערות של הרגולטור. דרישות GDPR, 152-ФЗ ו-HIPAA נבדלות בפרטים, אך מתכנסות לנקודה אחת: יש להצדיק את תקופת השמירה, ולאשר את המחיקה. תקופות מאושרות יחד עם יומן מחיקות סוגרות את השאלה "מדוע הנתונים האלה עוד אצלנו" בלי לשכתב מערכות לפי כל קובץ כללים.

דרכי יישום מדיניות השמירה: השוואת גישות

בחירת השכבה קובעת אם הכלל יעבוד כשהשירות נכתב מחדש או כשהרשומה קשורה לעשרה טבלאות. עבור GDPR, 152-ФЗ ו-HIPAA חשוב לא עצם הגדרת הניקוי, אלא היכולת להוכיח: הבודק רואה שהרשומה נעלמה בזמן.

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

הטמעת data retention: שלבי עבודת ההנדסה

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

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

2. תיאום תקופות. לכל מערך נתונים קובעים תקופה ובסיס: דרישת החוק, תנאי החוזה, תוחלת החיים של החשבון, משיכת ההסכמה. מכנסים לטבלה אחת עם הפעולה בתום התקופה — למחוק, לאנונם או להעביר לארכיון.

3. תכנון הסכימה. מחליטים היכן חי הכלל: מדיניות מחזור חיים בצד האחסון, משימה לפי לוח זמנים, מחיקה מדורגת (cascade) ברמת האפליקציה, מיסוך. חושבים איך הכלל ישרוד החלפת סכימה ומעבר שירות.

4. הגדרת כללי המחיקה. כללים מנהלים כקוד במאגר: שינויים עוברים ריוויו, ולא מוזנים ידנית בפאנל. במקביל מפעילים יומן — מי, מתי ולפי איזה כלל מחק רשומה.

5. בדיקה במעגל בדיקות. ממלאים את ארגז החול בנתונים דומים ומריצים תרחישים: פקיעת תקופה, משיכת הסכמה, שחזור מגיבוי, הרצה חוזרת של הכלל. בודקים שהמחיקה לא פוגעת ברשומות קשורות ולא שוברת את הדיווח.

6. מסירה לתפעול. מוסרים לצוות התורנות תקנון, ניטור והתראות על כשל בכללים, סדר טיפול בבקשת נפגע נתונים. כעבור פרק זמן מוסכם חוזרים ומשווים את המדיניות לזרימות בפועל — הן משתנות מהר מהמסמך.

מה נשאר בידיכם לאחר הטמעת מדיניות השמירה

מדיניות שמירה אינה מסמך חתום אחד, אלא מארז ארטיפקטים שלפיו אפשר לבדוק את המערכת, להעביר לצוות אחר ולהראות לבודק. להלן — מה בדיוק נשאר בידיכם לאחר ההטמעה.

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

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

מקרה בוחן: הבאת האחסון לדרישות שלושה רגולטורים

הלקוח — שירות עם משתמשים באיחוד האירופי, ברוסיה ובארה"ב: לאותם נתונים בדיוק חלו דרישות GDPR, 152-ФЗ ו-HIPAA, ולמעשה התקופות נבדלו — במקום מסוים השמירה מוגבלת לתקופת החוזה, במקום אחר נקבע פרק זמן קבוע.

חלק מהנתונים חי ב-PostgreSQL, חלק — באחסון אובייקטים ובלוגים של אפליקציות, ולכל מערכת היו "כללים" משלה, המתוארים בוויקי.

בהתחלה שיעור הרשומות שפג תוקפן במערכים העיקריים עמד על 18–23%: סקריפטים של מחיקה קרסו על שורות קשורות, וחלק מהמשימות כובו בזמן תקלות ולא הוחזרו לפעולה. בקשת נפגע לגישה הוכנה ידנית — ייצוא משלוש מערכות, השוואה, — והתשובה ארכה 6–9 ימי עסקים. בדיקה מתוכננת של הרגולטור הניבה שבע הערות, ארבע מהן — בנוגע לתקופות שמירה ולהיעדר הוכחות מחיקה.

מה שינו

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

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

לאחר ההטמעה שיעור הרשומות שפג תוקפן — פחות מ-1%, והשארית מגיעה לתיקים שנויים במחלוקת עם תקופה פתוחה. התשובה לבקשת נפגע נאספת אוטומטית לפי מזהה ונכנסת ליום עסקים אחד. בדיקה חוזרת לא העלתה אף הערה בנוגע לאחסון: היומן מאשר גם את התקופה וגם את עובדת המחיקה.

במה נבדל GDPR מ-152-ФЗ ומ-HIPAA בתקופות שמירה

תשובה קצרה: לא GDPR, לא 152-ФЗ ולא HIPAA קובעים תקופת שמירה בימים. הם מגדירים ממה נגזרת התקופה — מטרת העיבוד, הבסיס המשפטי והחובה להפסיק את העיבוד כשהמטרה הושגה. לכן אותו ייצוא בדיוק חי זמן שונה במשטרים שונים, ונכון להשוות בין המשטרים לאורך ארבעה צירים.

המסקנה המעשית: תקופה אינה קבוע בקוד, אלא תכונה של קטגוריית נתונים. במדיניות השמירה (data retention) לכל קטגוריה יש תווית תקופה, לוח זמנים למחיקה אוטומטית ונתיב נפרד לבקשות נפגע — מחיקה לפי דרישה הולכת דרכו, ולא דרך עריכה ידנית של מסדים. יומן המחיקות נכתב מיד לאחסון בלתי ניתן לשינוי: הוא זה שסוגר את הבדיקה הראשונה.

שאלות טכניות בנוגע לתקופות שמירת נתונים

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

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

האם אפשר לא למחוק נתונים, אלא לאנונם?

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

מה עושים עם הצטברויות שנוצרו לפני המדיניות?

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

איך להשתכנע שהמדיניות אכן עובדת?

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

נדון במשימת אחסון הנתונים שלכם

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

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

לפי נתוני הפתיחה האלה מכינים ביקורת אחסון, לאחר מכן תוכנית עבודה וכללי רטנשן, בודקים אותם במעגל פיילוט ונשארים בליווי — יהיה צורך לחזור ולבחון את הכללים עם שינוי הרכב המערכות. תארו את המשימה בצורה נוחה, ונחזור עם הערכה ותוכנית.