עמידה ב-152-FZ: היכן נשברת הגנת הנתונים האישיים
בדיקת עמידה טיפוסית ב-152-FZ מתחילה לא במסמכים, אלא בתשתית — ושם מוצאים את אותו הדבר. לוגים של גישה נכתבים, אך בלי תקופות שמירה ובלי הגנה מפני עריכה: ניתן לשנות או למחוק רשומה, ואין דרך להוכיח מי ומתי קרא את מסד הנתונים. ההרשאות למסדי נתונים ניתנות לקבוצות רחבות — «לזמן מה», «לצורכי דיבאג» — ונשארות בתוקף שנים.
גיבויים נמצאים באותו מאגר כמו נתוני העבודה, לעתים קרובות ללא הצפנה, ומפתחות הצפנת הנתונים — לצד הנתונים עצמם: השחזור נוח, אבל ההצפנה מפסיקה להגן על משהו. כל דליפת נתונים בסכימה כזו אינה נחקרת — אין דרך לאשר אם מישהו קרא את הגיבוי.
הסיבה בדרך כלל אחת: התשתית גדלה מהר יותר מהמדיניות. גישה ניתנת למשימה ולא נשללת, לוגים מופעלים בלי רוטציה, גיבויים נשמרים במקום המהיר ביותר, ומפתחות — במקום שממנו קל להשיג אותם בעת תקלה. הפרדת הרשאות והגנת נתונים אישיים נשארות ברמת הסכמות בעל-פה.
בודקים לא את קיומו של נוהל, אלא את יכולת השחזור: האם ניתן להוכיח את אי-שינוי הלוג לתקופה הנדרשת, האם הגיבוי משוחזר בלי גישה למתחם העבודה, האם הגישה נשללת ביום שבו העובד עוזב. נפרק כיצד זה נסגר — ממודל תפקידים והצפנה ועד תקופות שמירה ובקרת מפתחות.
מה נותן מתחם הגנת נתונים בנוי היטב בפועל
עמידה ב-152-FZ היא לא תיקיית מדיניות, אלא מאפיינים של התשתית שנבדקים במספרים. להלן מה בדיוק משתנה כאשר מתחם הגנת הנתונים מורכב.
הצפנה: היכן נסגר ערוץ הדליפה
הנתונים מוצפנים בשלושה מצבים: בדיסק, בגיבויים ובערוץ בין השירותים. המפתחות נשמרים במאגר נפרד עם רוטציה, והגישה אליהם ניתנת לשירותים לפי תפקידים, לא לאנשים — שיעור הנתונים בהצפנה מגיע ל-100%, וגיבוי של מסד נתונים שנקלע למקום הלא נכון נשאר אוסף חסר תועלת של בלוקים.
רישום לוגים: ממה נבנית תשתית הראיות
אירועי גישה, שינויי הרשאות ופעולות עם נתונים אישיים נכתבים ללוג בלתי ניתן לשינוי: גורם, זמן, אובייקט, תוצאה. תקופת שמירת הלוגים נקבעת במדיניות, ולא לפי האם מישהו ניקה דיסק ידנית — שליפה לפי אדם או תקופה מסוימים נאספת בדקות, והיקף הלוגים גדל באופן צפוי.
בקרת הגישה מתוארת בתפקידים ומאושרת בבדיקה תקופתית: דוח על מי מחזיק באילו הרשאות נאסף בשעות במקום שבועות של מעבר ידני בין מערכות. שחזור לאחר תקלה מתנהל לפי תרחיש מאומת — זמן החזרת השירות נמדד בעשרות דקות, וסוג התקלה «יש גיבוי אבל הוא לא משוחזר» נעלם לאחר תרגולים במתחם נפרד.
מצבי הצפנה ואחסון: השוואת גישות
בחירת מצב ההצפנה קובעת לא את חוזק האלגוריתם, אלא את גבול האמון: היכן נמצא המפתח ומי מורשה לגשת אליו. להלן ארבע אפשרויות שביניהן בוחרים בעת עיבוד נתונים אישיים.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| הצפנה בצד האפליקציה | הנתונים עוברים למאגר חיצוני או למסד נתונים משותף | המפתח חי בשירות: שגיאה בקוד חושפת את הנתונים, החיפוש לפי שדות מסתבך |
| הצפנת דיסק | הגנה על המדיה ועל הגיבויים | כל עוד המערכת פעילה, הקריאה שקופה — קו ההגנה נשאר בהרשאות ובלוגים |
| מאגר מפתחות ייעודי | רוטציה, תפקידים ועקבות ביקורת לכל פעולה | תלות במסלול הקריאה: אי-זמינות של שירות המפתחות עוצרת את העיבוד |
| מתחם נפרד לנתונים רגישים | נדרשת ריזידנטיות ומעגל מצומצם של מנהלים | שני מתחמים, שתי ערכות עדכונים, חשבונות נפרדים |
היכן לאחסן מפתחות ומי מנהל אותם
מפתחות לא נשמרים במאגר קוד, במשתני סביבה או לצד הנתונים עצמם. מפתח מאסטר נמצא במאגר ייעודי, השירות מקבל מפתח קצר-מועד לזמן הפעולה, רוטציה מתבצעת לפי לוח זמנים, וכל הנפקה נרשמת בלוג. ההרשאות לניהול מפתחות מופרדות מההרשאות לעיבוד נתונים: מהנדס תחזוקה לא יכול לייצא את מפתח המאסטר.
חלוקת נתונים לפי רמות רגישות
רמת הרגישות קובעת את מצב ההצפנה, תקופת השמירה ומעגל הגישה. אנליטיקה אנונימית נשארת במתחם המשותף, נתונים אישיים — בהצפנה בצד האפליקציה, והמערכים הרגישים ביותר מועברים למתחם נפרד עם ריזידנטיות בטריטוריה הנדרשת. כך מחמירים את המצב באופן נקודתי, בלי לבנות מחדש את כל המאגר.
יישום עמידה ב-152-FZ: שלבי עבודת הנדסה
סדר העבודות בנוי כך שכל צעד נשען על הקודם: בלי מפת נתונים, הפרדת הרשאות ותיעוד לוגים נשארים פורמליות. לכן מתחילים במיפוי, ומסיימים בבדיקה שהאמצעים אכן פועלים, ולא רק מתוארים במסמכים.
מיפוי: מפת נתונים וזרימות
אוספים מרשם: אילו קטגוריות של נתונים אישיים מעובדות, באילו מערכות הן נמצאות, דרך אילו שירותים הן מועברות, למי ועל איזה בסיס יש גישה. התוצאה — תרשים זרימות עם נקודות כתיבה, קריאה וייצוא לשירותים חיצוניים, וציון תקופות שמירה לכל מערך.
- מיפוי נתונים וזרימות — מרשם מערכות, קטגוריות נתונים ונקודות העברה.
- תרשים פריסה והצפנה — היכן הנתונים נמצאים פיזית, הצפנה באחסון ובערוץ, סדר העבודה עם מפתחות.
- הפרדת הרשאות — תפקידים לפי עקרון המינימום ההכרחי, חשבונות שירות נפרדים, שלילת גישה בעת פיטורים.
- הגדרת רישום לוגים — אירועי גישה לנתונים אישיים במאגר נפרד, מוגן מפני עריכה ומחיקה.
- בדיקת תרחישי שחזור — פריסת אימון מגיבוי על מתחם נקי לפי חישוב אישי. נוהל תגובה — מי, מה ובאיזה מועד עושה בעת אירוע, למי ואיך מדווח; העברת התיעוד לצוות שלכם.
בדיקה: כיצד משתכנעים שהאמצעים פועלים
בודקים במעשים, לא בניירת: מפעילים מחיקת הנתונים של אדם מסוים ובודקים שהם נעלמו מכל המערכות; מנסים לקבל גישה מחוץ לתפקיד שהוקצה ומוודאים שהסירוב נרשם בלוג; פורסים גיבוי ומשווים שלמות. תרחיש שלא עבר משמעו שהאמצעי עדיין לא הוטמע.
מדיניות גישה, סכמות הצפנה ונוהלי רישום לוגים
נוהלים הם מה שנשאר אצל הלקוח לאחר היישום: לא שרת מוגדר, אלא נהלים כתובים שמהם הבודק רואה שגישה, הצפנה ותיעוד לוגים מנוהלים, ולא נוצרו באופן ספונטני. להלן מערך תוצרים שאנו מעבירים במסגרת הפרויקט: כל אחד סוגר סעיף משלו ב-152-FZ וב-GDPR.
מטריצת גישה וחשבונות שירות
- מטריצת תפקידים והרשאות: אילו עובדים וקבלנים יש להם גישה לאילו מערכות ונתונים — עם נימוק לכל תפקיד.
- מדיניות גישה: נקודת כניסה אחודה, אימות דו-שלבי, הרשאות מינימליות הכרחיות, סדר אישור ושלילה בעת שינוי תפקיד או פיטורים.
- חשבונות שירות: לכל אחד — בעלים, ייעוד, תוחלת חיים, שמירת הסוד במאגר מוגן ואיסור כניסה בסיסמה.
- תרשים זרימות של נתונים אישיים ומדיניות אחסון מפתחות הצפנה: היכן הנתונים נמצאים, היכן מעובדים, מי יכול להשתמש במפתח ובאיזו תדירות הוא עובר רוטציה.
לוגים: הרכב, מועדים, הגנה מפני שינוי
- כללים ותקופות שמירה של לוגים: רשימת אירועים שחובה לתעד, תקופת שמירה וסדר רוטציה.
- הגנה מפני שינוי: מאגר בכתיבה בלבד, הרשאות נפרדות לקריאה ולכתיבה, בקרת שלמות, העברת הלוגים למתחם נפרד.
- נוהל תגובה לאירוע: זיהוי, סיווג, מועדי הודעה לרגולטור ולנושאי הנתונים, ניתוח סיבות ותיקון הרשאות גישה.
את המערך נתאם עם מחלקת אבטחת המידע שלכם ונביא אותו לצורה המתאימה לביקורת פנימית.
מקרה בוחן: סגירת הערות ביקורת בנושא הגנת נתונים אישיים
הלקוח — שירות עם נתונים אישיים של עשרות אלפי משתמשים. לפני בדיקה מתוכננת של הרגולטור, ביקורת פנימית מצאה פער בין מדיניות הגישה לבין אופן הענקת ההרשאות בפועל. מקרה היישום החל במיפוי חשבונות, ולא ברכישת אמצעי הגנה חדשים.
מה היה לפני: נקודות תורפה
חשבונות נוצרו ידנית במערכות שונות, הרשאות הצטברו יחד עם שינויי תפקיד: לחלק מהמנהלים נשארה גישה מלאה לאחר מעבר לצוות אחר. דוח גישות נאסף במשך שבועיים — ייצואים ממספר מערכות אוחדו בטבלה, ועד לרגע האישור הוא התיישן חלקית.
גיבויים לא הוצפנו בכל מקום: חלק מהגיבויים עם נתונים אישיים נשמרו במאגר משותף, שהגישה אליו הייתה רחבה ממעגל המורשים. לוגים נוהלו, אך לא אוחדו למקום אחד, ולכן לא ניתן היה לשחזר מי קרא רשומה מסוימת.
מה נהיה אחרי: שינויים מדידים
חשבונות הועברו ל-Keycloak כמקור אחוד לתפקידים: הרשאות ניתנות לפי תפקיד ולפרק זמן, ולא «ליתר ביטחון». הרשאות מיותרות צומצמו ב-68% מהחשבונות, וסגירת גישה בעת פיטורים או העברה אורכת שעות במקום שבועות.
דוח גישות נאסף ב-10 דקות בייצוא אחד — רואים למי יש אילו הרשאות ועל איזה בסיס. הגנת הגיבויים נסגרה בהצפנה בצד המקור, המפתחות הועברו למאגר נפרד, ולוגי הגישה אוחדו למתחם משותף עם תקופת שמירה בלתי ניתנת לשינוי.
מעבר הבדיקה — ללא הערות בנוגע לגישות ולהגנת גיבויים; נותר רשימת שיפורים מתוכננת, שאותה סוגרים בתהליך התמיכה הרגיל.
מה לעשות אם התשתית כבר פרוסה?
אין צורך לבנות מחדש את המתחם הפעיל כולו: עיקר הדרישות של 152-FZ נסגרות בתוספת מעל. הצפנת ערוצים ומדיה, הפרדת תפקידים, תיעוד לוגים של פעולות עם נתונים אישיים ונוהל שמירתם מופעלים מעל השירותים הקיימים, בלי לכתוב מחדש את האפליקציות.
יישום מדורג מתחיל במיפוי: היכן הנתונים נמצאים פיזית, אילו שירותים והחלפות חיצוניות פונים אליהם, למי יש גישה ישירה ל-DBMS ולגיבויים. לאחר מכן עדיפות לפי סיכון — תחילה מבודדים מאגרים עם הנפח הגדול ביותר של רשומות ואינטגרציות חיצוניות.
בחלקים יהיה צורך לשנות את סכמת האימות, את הפילוח ברשת ואת הטיפול במפתחות. כאן עוזר תקופת מעבר: המתחם החדש מוקם לצד הישן, השירותים מועברים בקבוצות, והחשבונות הישנים ממשיכים להתקיים עד להעברה מלאה של ההרשאות.
סודות ורוטציית מפתחות נלקחים על ידי HashiCorp Vault — השירותים מקבלים גישה דרך פרטי גישה קצרי-מועד במקום מחרוזות חיבור סטטיות בקונפיגורציה, ודליפת קובץ הגדרות מפסיקה לפתוח את מסד הנתונים.
מזעור השינויים מושג בכך שהאפליקציות נשארות ללא שינוי: שכבת הגישה משתנה, ולכן המעבר מתבצע בלי עצירת השירותים. סשנים לא מתאפסים, הרשאות ניתנות בקבוצות, כל שינוי נרשם בלוג — המבקר רואה מי, מתי ולאילו רשומות קיבל גישה.
ספקות טכניים: הצפנה, לוגים, גישות
לפני תחילת פרויקט 152-FZ עולים אותם שאלות: האם יהיה צורך לכתוב מחדש את השירותים, היכן נמצאים המפתחות, מה לעשות עם נתונים מחוץ למתחם וכיצד לשמור על עמידה בעת שינויים. להלן תשובות, כדי שתשוו אותן לארכיטקטורה שלכם.
האם יהיה צורך לכתוב מחדש את השירותים?
לא. העמידה נבנית בשכבות סביב האפליקציה: הצפנת המאגר והערוץ, הפרדת גישה, תיעוד לוגים. צריך לכתוב מחדש לוגיקה רק במקומות שבהם נתונים אישיים נכנסים ללוגים או למטמון בצורה גלויה.
מי מחזיק במפתחות?
המפתחות נשארים במתחם שלכם: אנחנו מגדירים את הניהול שלהם, אך לא הופכים לבעלי החזקה. רוטציה לפי לוח זמנים והפרדת תפקידים — אדם אחד לא יכול לפענח ולהנפיק גישה. גבולות האחריות נקבעים בכתב, כולל בדיקת קבלן.
מה לעשות עם נתונים מחוץ למתחם?
גיבויים, ייצואים, אינטגרציות חיצוניות, מחשבים ניידים בעבודה — נקודת הדליפה הנפוצה ביותר. לגבי כל אחד קובעים: האם הוא נחוץ, האם ניתן להפוך את הנתונים לאנונימיים, היכן הם נמצאים ומתי נמחקים.
כיצד לשמור על עמידה בעת שינויים?
עמידה היא תהליך, לא בדיקה חד-פעמית. התשתית מתוארת בקונפיגורציה, ולכן כללי גישה, הצפנה ותקופות שמירת לוגים מיושמים על שירותים חדשים באופן אוטומטי, והשינויים עוברים בדיקה לפני העלאה.
נדון במשימה: מה לשלוח להערכת המתחם
כדי לחזור עם הערכת עבודות ותוכנית יישום, ולא עם ניסוחים כלליים, נדרש הרכב מינימלי של נתוני מקור. ככל שנתוני המוצא מדויקים יותר, כך יש פחות הנחות באומדן ולוחות הזמנים של השלבים ריאליסטיים יותר: תיקונים באמצע הפרויקט יקרים יותר מחצי שעה של ניתוח התרשים בהתחלה.
- תרשים שירותים וזרימות נתונים: היכן נשמרות רשומות, לאן הולכים גיבויים וייצואים, האם יש אתרי גיבוי והעברה אל מחוץ למתחם.
- רשימת הנתונים המעובדים וקטגוריות נושאי הנתונים: נתונים אישיים רגילים, קטגוריות מיוחדות, מערכים אנונימיים — מזה תלוי היקף ההצפנה וסדר העבודה עם הסכמות.
- מדיניות גישה נוכחית ומודל תפקידים: כיצד ניתנות הרשאות, למי יש סמכויות מורחבות, האם נותרו חשבונות משותפים בלי אחריות אישית.
- הרכב הלוגים: אילו אירועים כבר מתועדים, היכן הם נמצאים, כמה זמן נשמרים והאם הם מוגנים מפני שינוי בדיעבד.
- דרישות הבודקים או הביקורת הפנימית: הוראה, רשימת הערות, שאלון — לפיהם בונים את סדר העדיפויות של השלבים.
- מגבלות: חלונות תקנון, הקפאת מהדורות, דרישות למיקום הנתונים בטריטוריית המדינה.
אין צורך בחבילה מלאה בהתחלה — שלחו את מה שיש, כולל טיוטות וייצואים בכל צורה. אנו מציעים שיחת ועידה על המשימה: בשיחה ננתח את הפערים ונסכם מה להשלים. בסיומה נחזור עם הערכת עבודות, תוכנית יישום ולוחות זמנים לשלבים.