מערכת AI DLP אינה רואה את הדליפה: היכן נשברת ההגנה
תמונה אופיינית: במערכת AI DLP מוגדרים חוקים, אגף האבטחה מדווח על כיסוי, אך דליפת נתונים חסויים בכל זאת נחשפת מהצד — ממכתב של ספק או מתלונה של עובד שהבחין במשהו מיותר בצ'אט המשותף. האגף נודע על התקרית בדיעבד, כשהקובץ כבר נמצא בידי הנמען.
העניין אינו במספר החוקים אלא באופיים. חוק תופס תבנית: מספר, רצף תווים, כותרת מסמך מוכרת. הדבר שלמענו נבנית הגנת מידע אישי אינו נראה כך — מאגר לקוחות בארכיון, קטע מחוזה בהתכתבות, ייצוא דוח לענן אישי.
בקרת הגישה לנתונים מוגדרת במקרה זה על בסיס ההיקף: למי איזו תיקייה ואיזה שירות נגישים. ואילו הדליפה מתרחשת בערוצים מורשים — יש הרשאת קריאה, אין הגבלה על העתקה. חקירת אירועי דליפה הופכת לארכיאולוגיה: היומנים נאספו, אין קשר בין האירועים, ונדיר להצליח לשחזר את מסלול המסמך.
האפקט השני — רעש. התראות שווא על כל מספר תבניתי מרגילות את האנליסטים לסגור התראות בלי לקרוא, והאירוע האמיתי טובע בזרם. בהמשך נבחן כיצד זה נסגר: מה משתנה בחוקים, בתיוג ובתגובה, כאשר הסיווג והעדיפות נלקחים על ידי המודל ולא על ידי רשימת חריגים.
מה נותן סיווג נתונים מנוהל
סיווג מתחיל בכך שלכל מסמך מוצמדת תווית: פומבי, פנימי, חסוי, סוד מסחרי. תיוג אוטומטי של מסמכים מתבצע לפי תוכן, ולא לפי תיקייה או שם קובץ — המודל מנתח את הטקסט, הקבצים המצורפים והמבנה, והחוק מאשר את התוצאה.
שיעור המסמכים המתויגים ללא מעורבות אדם עולה בדרך כלל על 85–90%, והשאר עובר לבדיקה לפי סימן מוגדר, ולא «משום כך החליט המומחה».
מכאן האפקט העיקרי עבור אגף האבטחה — צמצום הבדיקה הידנית. האירוע מגיע לתור כבר עם תווית והקשר: אילו נתונים, של מי הם, לאן יוצאים. בדיקה מאפס מוחלפת בבדיקת תמצית מוכנה, ולכן זמן התגובה לאירוע נמדד בשעות ולא בימים, ומתקצר עוד ככל שמצטברים חוקים לתרחישים אמיתיים.
הבקרה על שירותי צל נשענת על אותה תווית. כאשר עובד שולח קובץ חסוי לשירות חיצוני או לאחסון אישי, מופעלת מדיניות ולא ניחוש של מנהל המערכת: הזרימה נחסמת או עוברת לאישור של בעל הנתונים.
שירות הצל מפסיק להיות אזור עיוור, ובמערכת ה-DLP מופיעה רשימת הערוצים שבאמצעותם הנתונים באמת יוצאים מההיקף.
סוג נפרד שנפתר — שגיאות בתיוג ידני. האדם מתעייף ומפרש אותו חוזה באופן שונה ביום שני וביום שישי; החוק נותן תשובה זהה לסימן זהה, ומקרים שנויים במחלוקת מועברים לסקירה בנפרד.
בדוח נותרו מדדים שמהם ניכרת העבודה: זמן התגובה לאירוע, שיעור המקרים שנבדקו אוטומטית, שלמות התיוג ומספר ההפעלות בערוצי צל.
השוואה בין גישות לבקרת זרימת נתונים
בחירת הגישה תלויה בשאלה מי אחראי על תיוג הנתונים ובאיזה שלב הוא מופיע. בקרה מובנית של הפלטפורמה — שער דואר, אחסון בענן, סוכן בתחנת הקצה — פועלת לפי מטא-נתונים ותבניות מוכנות: נפרסת במהירות, אינה דורשת תשתית נפרדת ומכסה ערוצים שגרתיים.
בקרה ידנית בכוחו של האגף נשענת על המומחיות של האנליסטים ועל בדיקה ידנית של אירועים. תיוג לפי תוכן הוא משימה נפרדת: משמעות המסמך אינה ניתנת לקריאה משם הקובץ או מהסיומת, יש לחשב אותה מתוך הטקסט, וכאן הגישות נבדלות זו מזו ביותר.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| בקרה מובנית של הפלטפורמה | ערוצים שגרתיים: דואר, דיסקים בענן, מדיה נשלפת, הרשאות גישה | מגיבה למטא-נתונים ולתבניות. קובץ בשם שונה, צילום מסך, הדבקה בגוף ההודעה או ארכיון חולפים על פני החוקים |
| בקרה ידנית בכוחו של האגף | נפח קטן, מחיר שגיאה גבוה, בדיקות חד-פעמיות לפני פרסום | תפוקה מוגבלת בידי אנשים: הסיווג מפגר אחרי הזרימה, ההחלטות סובייקטיביות ומשחזרות גרוע עם החלפת אנליסט |
| קו מתאר ייעודי לסיווג | זרימת מסמכים מעורבת, פורמטים רבים, נדרש תיוג לפי תוכן ומדיניות אחידה | דורש אימון מודלים על הנתונים שלך, כיול ספים ובקרת איכות מתמדת של התיוג |
בפועל משלבים בין הגישות: חוקי הפלטפורמה מטפלים בהפעלות המוניות לפי מטא-נתונים, והסיווג לפי תוכן בודק את מה שלא מגיע אליהם. בהמשך נבחן כיצד זה משתלב עם אמצעי ההגנה שכבר פועלים.
כיצד אנו מטמיעים בקרת נתונים: שלבי העבודה
הגדרת חוקים מיד לאחר הפריסה היא דרך מהירה לקבל זרם של התראות שווא ולאבד את אמון המשתמשים. לכן העבודה מתנהלת מהמלאי לעבר כיול ממוקד: תחילה מתעדים היכן הנתונים חיים וכיצד הם נעים, ורק אחר כך מפעילים בקרה.
- ביקורת זרימות נתונים. מתעדים את הערוצים: דואר, מסרים מיידיים, דיסקים בענן, מדיה נשלפת, הדפסה, גישה למאגרי נתונים. ראיונות עם בעלי המערכות ויומני הגישה מספקים רשימה של נקודות שבהן נתונים חסויים באמת מופיעים.
- מפת מסלולי הנתונים. עוקבים אחר מסלול המסמך מהמקור ועד לנמען החיצוני: מי יוצר, מי מעתיק, היכן נמצאת העתקה. את המפה מתאמים אגף אבטחת המידע ובעלי התהליכים — היא הופכת לתמיכה הן לחוקים והן לחקירת אירועים.
- תיוג ואימון הסיווג. מגדירים קטגוריות — מידע אישי, סוד מסחרי, תיעוד פרויקטים — ומתייגים את המאגרים הקיימים. המודל לומד על המסמכים שלך ומזהה ניסוחים ענפיים, ולא סט מופשט.
- כיול חוקי הבקרה. עבור כל מסלול מגדירים פעולה משלו: רישום ביומן, אזהרה למשתמש, חסימת שליחה. בנפרד מגדירים חריגים להעברה לגיטימית, כדי לא לעצור את עבודת היחידות.
- בדיקה על נתונים אמיתיים. מפעילים מצב צל על חלק מהיחידות: סופרים את שיעור ההתראות השווא וההחמצות, מאמנים מחדש את המודל, מתקנים את הסף. חסימות מפעילים במקום שבו הדיוק אושר במדידה.
- מסירה להפעלה שוטפת. מוסרים למנהלי המערכת נהלי תגובה לאירוע, את התצורה ואת סדר הבדיקה של מקרים שנויים במחלוקת. בשבועות הראשונים מלווים, עד שהאגף עובר למצב עצמאי.
מה נשאר בידיכם לאחר ההטמעה
הטמעת מערכת סיווג והגנת נתונים אינה מסתיימת בהפעלה — הצוות שלך צריך להישאר עם סט ארטיפקטים שלפיהם ניתן לפתח את המערכת, לבדוק אותה ולהעביר אותה בין מנהלי מערכת.
אנו מתעדים לא רק את החוקים הפועלים אלא גם את ההיגיון שמאחורי ההחלטות: בלעדיו כל עריכה של מדיניות הופכת לניסוי על סביבת הייצור.
- מפת מסלולי הנתונים — היכן המידע מופיע, דרך אילו שירותים ומאגרים הוא עובר, ובאילו נקודות מוצבת הבקרה. נדרשת כדי שאינטגרציה חדשה לא תיווצר בעקיפין למדיניות.
- מטריצת מדיניות הגישה — התאמה של «קטגוריית נתונים → מי ובאילו תנאים מקבל גישה → מה קורה בעת הפרה». ניסוחים חד-משמעיים, כדי שהחוק ישחזר גם בלי יוצרו.
- תצורות המסווג — סימנים של קטגוריות רגישות, ספי הפעלה ורשימות חריגים שמסירות תיוגים שגויים.
- נוהל בדיקת הפעלות — מי מגיב, בתוך כמה זמן, אילו פעולות מתאימות לרמת הסיכון, כיצד מתועדת ההחלטה ומתי האירוע נסגר.
- הוראות למנהלי מערכת — פעולות טיפוסיות: להוסיף קטגוריה, לשנות חוק, לבדוק תור אירועים, להחזיר עריכה כושלת לאחור.
- תיעוד ההטמעה — החלטות ארכיטקטוניות והנימוקים שלהן, מפת פריסת הרכיבים, תלויות ונקודות כשל.
- יומן שינויים של המדיניות עם נוהל החזרה לאחור — כל עריכה מקבלת גרסה, וסט החוקים הקודם מוחזר בפעולה אחת.
סט כזה מקצר את זמן הכניסה של מנהל מערכת חדש ומסיר את התלות בקבלן: בדיקת ההפעלות מתבצעת לפי נוהל ולא לפי הזיכרון של מהנדס מסוים. אם נדרש רק רכיב אחד — למשל, מפת מסלולי הנתונים או מטריצת הגישה — נרכיב אותו בנפרד.
ניתוח מקרה הטמעה: מדדים לפני ואחרי
לפני: תור שלא הספיקו לבדוק
ברשת קמעונאית ההגנה על הנתונים נשענה על חוקים לפי תבניות: הפעלות על מספרי כרטיסים, חשבונות ופרטי דרכון נכנסו לתור בדיקה אחיד. כ-900 אותות בחודש אושרו בודדים בלבד — האנליסט סגר את הזרם כשווא, וחלק מהתור כלל לא הגיע לבדיקה. זמן התגובה לדליפה אמיתית התארך ליומיים-שלושה: עד שבדקו את הרעש, הייצוא כבר יצא בערוץ חיצוני.
מה שינו ומה יצא
המהנדסים שלנו השאירו את היירוט בצד Microsoft Purview, ומעליו הוסיפו מסווג שאומן על קורפוס המסמכים הפנימי של הלקוח: הוא מסתכל על ההקשר ולא רק על התבנית, ולכן ייצוא שגרתי ממערכת הרישום חדל להיראות כדליפה.
את סף הרגישות כיוונו לפי מדגם מתויג של אירועים, ולפני ההפעלה המבצעית הריצו את המודל על אירועי תקופות קודמות — זה סיפק מדדים לפני ואחרי על אותו סט בדיוק.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור התראות שווא | 76% | 8% |
| התראות בבדיקה ידנית | כ-900 בחודש | כ-70 בחודש |
| זמן תגובה לדליפה | 2-3 ימים | עד 15 דקות |
| ממצאים לאחר שליחת קובץ | באופן שגרתי | בודדים |
התור חדל להיות צוואר בקבוק: האנליסט עובד עם מקרים מאושרים ולא מסנן רעש. אפקט נפרד — יציבות הקשב: ככל שפחות אותות שווא, כך גדל הסיכוי שהאות האמיתי יבחין בו בדקות הראשונות.
מה לעשות אם המערכת כבר מותקנת אך יש הרבה התראות שווא
התראות שווא כמעט לעולם אינן קשורות לאיכות המודל — הן נובעות משכבה מצטברת של חוקים שנכתבו ידנית במשך שנים בלי בחינה מחדש. לכן מתחילים לא בהחלפת המנוע אלא בביקורת של ההגנה הקיימת: מייצאים את היסטוריית ההפעלות מכמה חודשים ובוחנים אילו חוקים יוצרים את עיקר זרם ההתראות.
לאחר מכן — דיוק התיוג. מתוך הייצוא יוצרים מדגם לכל חוק ולכל סוגי הנתונים, ומתייגים אותו ידנית יחד עם אגף האבטחה שלך: האם האירוע באמת דורש תגובה או לא. בלי תקן כזה, כיול החוקים הופך לניחוש, משום שהספים משתנים בעיוורון.
עם תקן אפשר לראות היכן החוק רועש בשל תנאי רחב מדי, והיכן בשל סף הפעלה שגוי. אז הכיול מתבצע באופן ממוקד: מצמצמים את אזור הבדיקה, מוסיפים תנאי הקשר — סוג הנמען, כיוון ההעברה, קיום תווית — מחריגים זרימות לגיטימיות ומאחדים חוקים כפולים למדיניות אחת.
הסדר הוא כזה: ביקורת ותיוג, הרכבה מחדש של החוקים בקו בדיקה על נתונים היסטוריים, מצב צל על תעבורה חיה, ולאחר מכן הפעלה הדרגתית של חסימות לפי קבוצות משתמשים. ההגנה לא נעצרת במהלך התהליך — המדיניות הפועלת ממשיכה לעבוד בזמן שהחדשות נבדקות במקביל.
את התוצאה מעריכים לפי שני מדדים בעת ובעונה אחת: שיעור ההתראות השווא ומספר האירועים שהוחמצו. אם הראשון יורד והשני עולה — צמצמת את החוק חזק מדי. קצב סביר — לבחון מחדש את התיוג והספים אחת לרבעון, אחרת החוקים שוב מתפצלים מהתהליכים האמיתיים בארגון.
ספקות טכניים לפני תחילת העבודה
הספקות בשלב ההתחלה כמעט תמיד אותם: האם ההגנה תהפוך לזרם של חסימות שווא, האם תחנת העבודה תתחיל להאט, האם אפשר להפעיל זאת בחלקים, ומה עושים עם קבלנים בחשבונות שלהם. להלן כיצד כל אחת מהשאלות הללו נפתרת ברמת התצורה, ולא ברמת הבטחות.
עד כמה מדויק הסיווג ומה עם התראות שווא?
המודל מאומן על קורפוס מתויג של הלקוח ומכויל לפי זרימת המסמכים שלו, ולכן סף הביטחון מוגדר לכל חוק בנפרד. בשלב ההתחלה מפעילים מצב של התראה בלבד: המערכת כותבת את ההחלטה ביומן אך אינה חוסמת, והאנליסט רואה את שיעור התיוגים השגויים האמיתי.
לאחר מכן חוקים עם סף גבוה עוברים לחסימה, והשנויים במחלוקת נשארים בבדיקה ידנית — כך התראת שווא אינה עוצרת את העבודה.
מה תהיה העומס על תחנות העבודה של העובדים?
העיבוד הכבד מועבר לצד השרת, ובמכונה נשאר לקוח שמעביר את האירוע וממשיך לעבוד. עבור מסמכים בנפח גדול מגדירים תור וניתוח מושהה. לפני ההפעלה הייצורית מבצעים מדידות על הפארק האמיתי: חשוב ששליחת הודעה או שמירת קובץ לא יורגשו איטיים יותר.
האם אפשר להטמיע בשלבים?
כן, ואנחנו ממליצים בדיוק על כך. תחילה — פיילוט ביחידה אחת ועל סט חוקים מצומצם, לאחר מכן הרחבה למחלקות, ורק אחר כך מדיניות כללית. לכל שלב קריטריוני קבלה משלו, והחלפת חוקים מקבלת גרסה: חזרה לגרסה הקודמת אורכת דקות ואינה דורשת השבתה.
כיצד להתמודד עם קבלנים חיצוניים וההרשאות שלהם?
עבורם פותחים חשבונות נפרדים ומדיניות נפרדת: סט ערוצים מוגבל, תוקף לגישה, רישום חובה של הפעולות. המערכת רואה את פעילות הקבלן כישות נפרדת, ולכן חקירת אירוע אינה טובעת במסה הכללית של האירועים. עם סיום העבודה הגישה נסגרת אוטומטית לפי לוח זמנים.
נדון במשימה ונשוב עם תוכנית עבודה
את השיחה מתחילים לא במצגת אלא בקו המתאר שלך: כדי לחזור עם הערכת היקף העבודה ותוכנית הטמעה, ולא עם שקופיות כלליות, אנחנו צריכים מינימום של נתוני פתיחה. להלן מה שכדאי להחזיק בהישג יד לקראת הפגישה הראשונה. אם על חלק מהסעיפים אין עדיין תשובה, זה לא חוסם את ההתחלה: חלק מהתמונה נבנה יחד.
- מהיכן הנתונים יוצאים. דואר, מאגרי קבצים, דיסקים בענן, מסרים מיידיים, ייצוא ממערכות רישום, מדיה נשלפת — אילו ערוצים באמת בשימוש ואילו מהם סגורים כיום.
- מה בדיוק אנחנו מגנים עליו. קטגוריות: מידע אישי, סוד מסחרי, חוזים, תיעוד הנדסי ופיננסי. לגבי כל אחת — האם העתקה לרשת הפנימית מותרת או אסורה לחלוטין.
- סוגי הזרימות והיקפן. סדר גודל: כמה משתמשים, כמה קבצים והודעות ביממה, האם ההיקף גדל בעונתיות. מכך תלויים סכימת ניתוח התעבורה ואופן פעולת מודלי הסיווג.
- כיצד בנויה התשתית. קו מתאר מבודד, שרתים משלך, היברידי או ענן; האם קיים איסור מפורש על העברת תוכן מסמכים מחוץ לרשת — אז המערכת מותקנת בתוך ההיקף.
- נוהל התגובה. מי מקבל התראה על אירוע, היכן הגבול בין אזהרה לחסימה, מי בודק התראות שווא ובאיזו תדירות.
- נקודות האינטגרציה. ספריית משתמשים, מערכת ניטור האירועים הפנימית, מערכות בקרת הגישה, יומנים — לאן המערכת צריכה לפלוט אירועים ומאיפה לקחת את תפקידי העובדים.
- החוקים והדרישות הנוכחיים. מה כבר מעוגן במסמכים הפנימיים, האם קיימות דרישות ענפיות לתקופות אחסון ולסדר חקירת אירועים.
- בעל המערכת בצד שלכם. מי יקבל את העבודה, מי ינהל את המדיניות לאחר ההפעלה, ובאיזה אופן נוח להעביר את הידע לצוות.
לפי התשובות הללו אנחנו מרכיבים את הרכב העבודה להגנת הנתונים: אילו ערוצים סוגרים בשלב הראשון, אילו בשני, והיכן נדרש כיול ידני של חוקים לפי זרימת המסמכים שלך. תארו את המשימה באופן הנוח לך — נשוב עם הערכת היקף העבודה, מפת השלבים ותוכנית הטמעה עם לוחות זמנים ברורים.







