דליפת מידע: מה המערכת שלכם צריכה לדעת לפני שזה קורה
במאמר הזה
רוב הדיון הציבורי על דליפת מידע מתחיל אחרי שהיא כבר קרתה, כותרת בעיתון, מאגר שנחשף, מיליוני רשומות.
הדיון הזה מעניין ולא שימושי עד שהוא מגיע, ההחלטות שקבעו אם האירוע יתגלה בכלל כבר התקבלו, ולרוב שנים קודם לכן.
המאמר הזה עוסק בהחלטות האלה לא בניהול משבר, ולא בכלים שמתקינים אחרי, השאלה שמעניינת אותנו היא אחת: מה המערכת צריכה לאפשר לפני שמשהו קורה.
דליפת מידע: מה זה בעצם, ולמה ההגדרה רחבה ממה שנדמה
בעברית משתמשים בכמה מונחים לאותו דבר: דליפת מידע, זליגת מידע, דלף מידע, פרצת נתונים.
המשמעות המשותפת פשוטה: מידע שהגיע לגורם שאינו מורשה לראות אותו, בטעות או בכוונה.
שימו לב למה שלא נמצא בהגדרה: אין בה האקר, אין בה פריצה, ואין בה תוכנה זדונית.
זו הנקודה שרוב התוכן בנושא מפספס, כשמחפשים דליפת מידע, מוצאים בעיקר שני סוגי תוצאות: כתבות על אירועים גדולים וספקים שמוכרים כלי ניטור, שניהם מניחים שהאיום מגיע מבחוץ.
בפועל, בעסק שמנהל מידע עבור לקוחות, חלק ניכר מהאירועים נראה אחרת לגמרי. עובד שייצא קובץ לפני שעזב, ספק שקיבל גיבוי ולא מחק אותו. חשבון שנשאר פתוח אחרי שמישהו עבר תפקיד.
אף אחד מהמקרים האלה לא ייעצר על ידי אנטי וירוס, כי אף אחד מהם אינו קוד זדוני. כולם גישה מורשית טכנית שלא הייתה צריכה להיות מורשית.
זו ההבחנה שקובעת איפה מחפשים פתרון: מול קוד זדוני מתגוננים, מול הרשאה עודפת מתכננים, והתשובה נמצאת בארכיטקטורה ולא ברשימת מוצרים.
עוד נקודה שכדאי לדייק בה: אירועי אבטחת מידע אינם תמיד אירועי דליפה. לפעמים המידע לא יצא לשום מקום, אבל מישהו שינה אותו, מחק אותו, או ניגש אליו בחריגה מהרשאה. גם אלה אירועים, וגם הם דורשים שהמערכת תדע לספר מה קרה.
זו שאלה של ארכיטקטורה, לא של הגנה. ההבדל אינו סמנטי, הוא קובע איפה הפתרון יושב.
כלי הגנה יושב מעל התשתית ובודק תנועה, ארכיטקטורה קובעת מה בכלל אפשר לבקש, ממי, ומה נרשם כשמישהו מבקש.
רוב הדליפות אינן פריצה, הן הרשאה
עסק בענף שירות מחזיק בדרך כלל שורה ארוכה של מערכות נפרדות: CRM, יומן, גיליונות, וואטסאפ, תוכנת חשבונאות, אחסון בענן.
כל אחת מהן מחזיקה עותק של המידע, ולכל אחת מהן מודל הרשאות משלה. זה יוצר מצב שקשה לתאר כשליטה. אף אחד לא יכול לומר, בלי לבדוק, מי בדיוק רואה את פרטי הלקוחות היום.
וכשאף אחד לא יודע מי רואה מה, אף אחד גם לא יודע מתי מישהו ראה משהו שלא היה צריך.
הנה שלושה דפוסים שחוזרים על עצמם:
הרשאה שנשארה
עובד עבר מתפקיד לתפקיד. ההרשאות בכלי אחד עודכנו. בשלושה אחרים נשארו כפי שהיו. אף אחד לא עשה משהו רע, ובכל זאת יש עכשיו אדם שרואה מידע שאינו קשור לתפקידו.
עותק שיצא
מישהו ייצא גיליון כדי לעבוד עליו בנוחות, שלח אותו לעצמו, ושכח. הקובץ חי עכשיו במקום שאף אחד לא סופר.
ספק שהחזיק מידע
מנהל קמפיינים שקיבל רשימת לידים. מפתח קודם שהשאיר עותק של מסד הנתונים. שירות שסגר את הפעילות ואף אחד לא שאל מה קרה למידע שהיה אצלו.
אף אחד משלושת המקרים אינו תקיפה. כולם תוצאה של ארכיטקטורה מפוזרת.
תקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017, שנכנסו לתוקף במאי 2018, מתייחסות במפורש למיקור חוץ ודורשות בחינה מוקדמת של סיכוני אבטחת המידע בהתקשרות ומסגרת חוזית מפורשת. הדרישה הזו קיימת כי המחוקק זיהה בדיוק את הדפוס השלישי.
יש כאן גם צד אנושי שקל להתעלם ממנו, כשעובד צריך ארבעה מסכים כדי לטפל בלקוח אחד, הוא מייצר קיצורי דרך: מייצא קובץ כדי לעבוד עליו בנוחות, שולח רשימה בוואטסאפ כדי לחסוך זמן, שומר סיסמה משותפת כי כך מהיר יותר.
אף אחד מהמעשים האלה אינו זדוני, כולם תוצאה ישירה של ארכיטקטורה שמחייבת קפיצה בין כלים, וכל אחד מהם מייצר עותק נוסף של המידע במקום שאף אחד לא מנטר.
הגישה למספר העותקים היא לצמצם, לא לנטר. ככל שפחות מקומות מחזיקים את המידע, כך פחות מקומות שצריך לעקוב אחריהם, וזו גם הסיבה שאנחנו בונים מערכת אחת ולא מחברים עשר מערכות זרות זו לזו.
מה המערכת צריכה לדעת לספר לכם
נניח שעלה חשד: מישהו העלה גבה, לקוח דיווח על משהו מוזר, או שהתקבלה פנייה.
השאלה הראשונה אינה מי אשם, היא מה בדיוק נחשף. בלי תשובה לשאלה הזו, כל צעד המשך הוא ניחוש: אי אפשר להעריך היקף, אי אפשר להחליט על דיווח, ואי אפשר לומר ללקוח מה קרה למידע שלו.
התשובה תלויה בדבר אחד: האם המערכת תיעדה.
תקנה 10 לתקנות מגדירה מה נדרש ממנגנון תיעוד במאגר שחלה עליו רמת אבטחה בינונית או גבוהה. לפי המדריך שמפרסמת הרשות להגנת הפרטיות, המנגנון צריך לכלול את זהות המשתמש, את התאריך והשעה של ניסיון הגישה, את רכיב המערכת שאליו בוצעה הגישה, את סוג הגישה: קריאה, כתיבה או שליפה, את היקפה, ואם הגישה אושרה או נדחתה. החובה חלה גם על גישה של משתמש אנושי וגם על גישה שמבוצעת באמצעות רכיב קוד.
שימו לב לשני פרטים ברשימה הזו:
הראשון: קריאה, לא רק כתיבה ומחיקה. רוב המערכות שעסקים משתמשים בהן מתעדות שינויים ולא מתעדות צפייה, נוח למפתח, וחסר תועלת בחקירה. אם עובד פתח שלוש מאות תיקי לקוח בשבוע האחרון ולא שינה בהם דבר, מערכת שמתעדת שינויים בלבד לא תראה כלום.
השני: ניסיונות שנדחו. תיעוד שרושם רק מה שהצליח מספר חצי סיפור. תיעוד שרושם גם מה שנחסם מראה דפוס.
השלישי: תיעוד, כמה זמן התיעוד נשמר, ומי יכול לגעת בו.
שלוש שכבות אבטחה הן ההרשאות, ההצפנה והתיעוד. השלישית היא זו שקובעת אם תדעו מה קרה, והיא היחידה שאי אפשר להוסיף רטרואקטיבית: לוג לא נוצר למפרע.
תיעוד שנמחק אוטומטית אחרי תקופה קצרה לא יעזור באירוע שהתגלה באיחור, ולא מעט אירועי אבטחת מידע מתגלים כך. תיעוד שמנהל המערכת יכול לערוך אינו ראיה. שתי הנקודות האלה צריכות להיסגר בשלב התכנון, לא בתגובה לשאלה של רואה חשבון או יועץ משפטי.
מה נחשב אירוע אבטחת מידע חמור
כאן נכנס פרט שמשנה את כל התמונה, והוא מגיע ישירות מהמדריך של הרשות להגנת הפרטיות.
אירוע אבטחה חמור מוגדר, בין היתר, כאירוע שנעשה בו במאגר שימוש במידע בלא הרשאה או בחריגה מהרשאה, או שנעשתה בו פגיעה בשלמות המידע.
עסקים מניחים לרוב שאירוע פירושו גניבה, וההגדרה בפועל רחבה יותר.
והנה החלק שרוב העסקים לא מכירים: הרשות מבהירה ש"שימוש" מוגדר בחוק הגנת הפרטיות גם כגילוי, העברה ומסירה. כלומר, גם אם מישהו רק צפה במאגר ולא ביצע פעולה אקטיבית אחרת כמו העתקה, מדובר באירוע.
עצרו רגע על המשמעות המערכתית של זה: אם צפייה בלבד נחשבת, אז מערכת שמתעדת רק שינויים לא תדע לזהות אירוע, וגם לא תדע לשלול אותו.
זה ההבדל בין לומר "בדקנו ולא נעשתה שום פעולה" לבין לומר "בדקנו ואיש לא ניגש לרשומות האלה". הראשון אינו מספק תשובה, השני כן.
זו אחת ההחלטות הראשונות שצריך לקבל בשלב הארכיטקטורה, לא משהו שמוסיפים כשמתעורר צורך. תיעוד קריאות עולה בביצועים ובאחסון, ולכן מי שלא החליט עליו מראש בדרך כלל לא יוסיף אותו אחר כך.
יש לזה גם צד הפוך, וכדאי לומר אותו. תיעוד מלא של קריאות אינו חינם, והוא לא נדרש בכל מערכת ובכל רמת רגישות. ההחלטה נגזרת מסוג המידע ומהיקפו, וזו בדיוק סוג ההחלטה שנעשית בשיחה עם מהנדס ולא בבחירה מתוך רשימת תכונות של מוצר מדף.
דיווח על אירוע אבטחת מידע: מה נדרש מהמערכת
נבהיר לפני הכל: זה אינו ייעוץ משפטי, ואנחנו לא עורכי דין. אירוע אמיתי מחייב ליווי משפטי, ולא מאמר.
מה שכן אפשר לומר הוא מה נדרש ברמת המערכת.
תקנה 11(ד) לתקנות קובעת שבמקרה של אירוע אבטחה חמור, בעל מאגר שחלה עליו רמת אבטחה בינונית או גבוהה מודיע על כך לרשם באופן מיידי, ומדווח גם על הצעדים שנקט בעקבות האירוע.
נקודה שחשוב לדייק בה: מגמת האכיפה של הרשות הלכה והחמירה בשנים האחרונות, והפרשנות המקובלת כיום היא שהדיווח נדרש באופן מיידי, ללא מסגרת שעות מוגדרת. מספרים ספציפיים שתמצאו במאמרים ישנים כדאי לבדוק מול עורך דין לפני הסתמכות עליהם, זה תחום שהמדיניות בו זזה.
מה שכן ברור מבחינה מערכתית: דיווח מיידי דורש מידע מיידי.
אם תתבקשו מחר לתאר בדיוק מה נחשף, כמה זמן ייקח לכם להרכיב את התשובה?
אי אפשר לדווח על היקף בלי לדעת מה נחשף. אי אפשר לדווח על צעדים שננקטו בלי לנקוט בהם, ואי אפשר לנקוט בהם מהר אם ביטול הרשאות דורש מעבר בין עשרה כלים.
התקנות גם דורשות שנוהל האבטחה יכלול הוראות להתמודדות עם אירועי אבטחת מידע לפי חומרתם, לרבות לעניין ביטול הרשאות וצעדים מיידיים אחרים. נוהל הוא מסמך. מה שמאפשר לבצע אותו בפועל הוא המערכת.
עסק שהנוהל שלו אומר "מבטלים הרשאות באופן מיידי" ושהמערכות שלו מפוזרות בעשרה כלים, כתב נוהל שהוא לא יכול לקיים.
נקודה נוספת שקשורה ישירות למערכת: מי מגלה שיש אירוע, ואיך. עסק שמחכה שלקוח יתלונן מגלה מאוחר. עסק שמוגדרות בו התראות על חריגות מגלה מוקדם יותר, וההפרש הזה הוא לרוב ההבדל בין אירוע מוכל לאירוע שהתפשט.
פאנל התפעול הוא הערוץ שדרכו זה קורה אצלנו: דיווח על תקלה או חשד בוואטסאפ ישיר, פתיחת טיקט בכל שעה, והתראה חוזרת על כל שינוי שנפרס.
שלושה תרחישים, ומה כל אחד דורש מהארכיטקטורה
עובד שעזב
הדפוס הנפוץ ביותר, והכי פחות דרמטי. מה שנדרש: סגירת הרשאות בפעולה אחת, ביטול סשנים וטוקנים, ויכולת לשלוף את רשימת הפעולות שלו מהתקופה האחרונה.
ברוב המקרים אין כאן כוונת זדון, יש קובץ שיצא ונשאר, וחשבון שנשאר פתוח כי אף אחד לא זכר אותו. הבעיה אינה האדם אלא היעדר נקודת שליטה אחת: סגירת גישה צריכה להיות פעולה אחת, כי צריך להיות רק מקום אחד שבו הגישה נפתחה.
מכשיר שאבד
לפטופ נשכח, טלפון נגנב. כשהמידע יושב על המכשיר, זו בעיה. כאשר המכשיר הוא חלון למערכת בלבד, מבטלים את הסשן מרחוק והחלון נסגר.
התקנות מתייחסות במפורש להתקנים ניידים ולסיכון שמידע ידלוף דרכם או שחיבורם יפגע במערכות המאגר. ההחלטה להשאיר את המידע במערכת ולא על הקצה נוגעת ישירות לנקודה הזו.
חשוב לדייק: זה לא פותר הכל. ביטול סשן מרחוק הוא יכולת שנבנית, לא תכונה שקיימת מעצמה. ההחלטה הזו נראית טכנית בשלב האפיון ומתגלה כמהותית בשלב שבו משהו קורה, ולכן היא נלקחת מראש, לפני שיודעים אם היא תידרש.
גישה מבפנים שלא הייתה צריכה לקרות
זה התרחיש הרגיש ביותר, ובענפים מסוימים גם המסוכן ביותר. במשרד עורכי דין, למשל, לא כל עורך דין אמור לראות כל תיק. הגבלת הרשאות בין התיקים אינה נוהל בלבד, היא דרישה מערכתית. מערכת לניהול משרד עורכי דין שבנויה נכון אוכפת את ההפרדה ברמת הנתונים ולא בהסתרת כפתורים במסך.
ההבדל מהותי: הסתרת ממשק מונעת טעות. אכיפה ברמת השאילתה מונעת גישה, וגם מייצרת תיעוד כשמישהו ניסה.
אותו היגיון חל על קליניקה שבה מטפל אחד לא אמור לראות את התיקים של עמיתו, ועל סוכנות ביטוח שבה סוכן לא אמור לראות את תיק הלקוח של סוכן אחר. הענף משתנה, ההיגיון המערכתי זהה.
למה מניעה היא החלטת תכנון ולא רכישת כלי
השוק מוכר אבטחת מידע כשכבה. מתקינים, מגדירים, משלמים חודשית. זה עובד כשמגנים על תשתית מפני קוד זדוני. זה לא עובד כשהשאלה היא מי בארגון רואה מה.
הרשאות לפי תפקיד דורשות מודל תפקידים, ומודל כזה דורש הבנה של מי עושה מה בעסק. את ההבנה הזו רוכשים בשלב המיפוי.
מערכת CRM מותאמת שנבנית כך מגיעה עם מודל הרשאות אחד, לוג אחד, וגבול אחד למידע. פחות נקודות כשל, ופחות מקומות שצריך לעקוב אחריהם.
התקנות מוסיפות עוד נקודה שקל לפספס: הן דורשות דיון תקופתי באירועי אבטחה ובחינה של הצורך בעדכון נוהל האבטחה. דיון כזה מחייב חומר. עסק בלי תיעוד מסודר מגיע לדיון בלי נתונים.
ההשלכה המעשית היא על הקצב: כשמודל ההרשאות הוא חלק מהמערכת, שינוי בתהליך העסקי מתגלגל אליו. תפקיד חדש נכנס, סניף נוסף נפתח, מחלקה מתפצלת. אצלנו כל אלה מטופלים בתוך הריטיינר, בלי הצעת מחיר חדשה ובלי פרויקט נפרד.
שאלות נפוצות
מה ההבדל בין דליפת מידע לבין אירוע אבטחת מידע?
דליפת מידע היא מונח יומיומי שמתאר מצב שבו מידע הגיע לגורם לא מורשה. אירוע אבטחת מידע הוא המונח שבו משתמשות התקנות, והוא רחב יותר: הוא כולל גם מצבים שבהם נעשה שימוש במידע בחריגה מהרשאה או שנפגעה שלמות המידע, גם אם דבר לא יצא החוצה.
האם צפייה במידע בלי להעתיק אותו נחשבת אירוע?
לפי המדריך של הרשות להגנת הפרטיות, כן. "שימוש" מוגדר בחוק גם כגילוי, העברה ומסירה, ולכן גם מי שרק צפה במאגר ולא ביצע פעולה נוספת נכנס להגדרה. המשמעות המערכתית היא שתיעוד שרושם רק שינויים לא יזהה אירוע מהסוג הזה.
כמה זמן יש לדווח על אירוע אבטחה חמור?
התקנות קובעות דיווח מיידי לרשם, לצד דיווח על הצעדים שננקטו. זה נושא שדורש ליווי משפטי ולא הכרעה מתוך מאמר. מגמת האכיפה החמירה בשנים האחרונות, וכדאי לבדוק מול עורך דין כל מסגרת זמן ספציפית שנתקלים בה במקורות ישנים.
איך יודעים בכלל שקרה אירוע?
בחלק מהמקרים מישהו מדווח. בחלק אחר לא מדווח אף אחד, ואז הגילוי תלוי בשני דברים: תיעוד שרושם גם קריאות וגם ניסיונות שנדחו, והתראות שמוגדרות מראש על חריגות. אירועי אבטחת מידע שמתגלים מאוחר הם לרוב אירועים שהמערכת לא נבנתה לזהות מלכתחילה.
מי צריך לדעת שיש אירוע, ומתי?
מבחינה מערכתית, השאלה הראשונה היא מי בארגון יקבל התראה כשמשהו חורג: מי מקבל הודעה, באיזה ערוץ, ועל אילו סוגי אירועים. ב-alcyone14 ההתראות מגיעות בוואטסאפ, ולא ממתינות לכניסה למערכת.
האם אנחנו צריכים מערכת DLP?
זו שאלה לגיטימית, והתשובה תלויה בהיקף ובענף. DLP מנטר תנועה של מידע החוצה, אבל לא קובע מי בארגון רשאי לראות מה מלכתחילה, זו שכבה נפרדת, שנקבעת בארכיטקטורה.
מה קורה למידע שכבר יושב בכלים הישנים שלנו?
שלב המיפוי כולל בדיקה של כל הכלים ושל המידע שיושב בכל אחד מהם. ההעברה נעשית בשלבים, וכל שלב נבדק לפני שממשיכים. כלי שלא נסגר במכוון נשאר מקום שבו המידע ממשיך לחיות, ולכן הסגירה היא חלק מהתהליך ולא הערה בסופו.
האם תיקון 13 שינה משהו מבחינת המערכת?
תיקון 13 לחוק הגנת הפרטיות נכנס לתוקף ב-14 באוגוסט 2025 והרחיב את סמכויות הפיקוח והאכיפה של הרשות. ההשלכה המעשית ברמת המערכת היא שיכולת ההוכחה נעשתה חשובה יותר. עסק שיכול להציג תיעוד מסודר נמצא במצב שונה מעסק שאומר שהוא בטוח שהכל בסדר. המשמעות המשפטית היא נושא לייעוץ משפטי.
אתם מטפלים באירוע אם הוא קורה?
לא במובן של חקירת סייבר או ניהול משבר, זה תחום אחר, שדורש גורמים מקצועיים שזה עיסוקם. מה ש-alcyone14 כן עושה הוא לוודא שהמערכת יודעת לספק את מה שנדרש: מי ניגש, מתי, למה, ומה בדיוק נחשף.
מוכנים לדעת מה המערכת שלכם באמת מתעדת?
דליפת מידע לא מתחילה ביום שבו מגלים אותה. היא מתחילה ביום שבו מישהו החליט אילו שדות המערכת רושמת.
השיחה הראשונה שלנו היא מיפוי: שבסופה תדעו כמה עותקים של המידע שלכם קיימים, מי נוגע בהם, ומה המערכת שלכם תוכל לספר לכם אם יעלה חשד.
ב-alcyone14 מספר הלקוחות שאנחנו לוקחים במקביל מוגבל בכוונה. מהנדס אחד שמכיר את העסק לעומק, לא Account Manager ולא שכבת תקשורת, אלה שותפות.
