26
פבר
08

בחירת מערכת למניעת זליגת מידע רגיש – Information Leakage Prevention

מערכות למניעת זליגת מידע: Information Leakage Prevention או בקיצור ILP. ויש כאלה המכנים את הפתרון Date Leakage Prevention.

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

היפה בפתרון מסוג זה הוא שלא מדובר רק בזליגת קבצים. ניתן להגדיר ביטויים רגישים שייחסמו במידה ויימצאו בכל מידע טקסטואלי (מיילים, פוסטים ל – Web). למשל, אני לא יודע היכן ישנן טבלאות עם מספרי כרטיסי אשראי. אבל אם מישהו שולח קובץ החוצה המכיל 10 מספרי כרטיסי אשראי ומעלה, המערכת תחסום בלי לדעת מה מקור המידע.

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

ישנן 2 גישות עיקריות לבחירת פתרון מתאים לארגון:

  1. מערכת המותקנת ב – Gateway ברשת.
  2. מערכת המותקנת על תחנות הקצה.

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

פתרון מבוסס רשת

פתרון מבוסס תחנות קצה

עיוור למתרחש בתחנות הקצה. למשל, לא מנטר העברת קבצים לכרטיס זכרון. בד"כ, מאפשר גם להגדיר הרשאות לאילו אמצעי זכרון נתיקים המשתמש יוכל לחבר למחשב, אם בכלל.
אינו רואה תעבורה מוצפנת מהרשת. למשל לא מנטר תעבורה ב –  SSL (כגון gmail). אינו מנטר גישה לבסיסי נתונים רגישים. לצורך חסימה, מצריך הגדרת ביטויים רגישים כגון: משכורות, כרטיסי אשראי וכדומה.
עלול להצריך שינויים בארכיטקטורת הרשת. מצריך תחזוקה שוטפת של תחנות הקצה. למשל התקנת Patches מתאימים. זהו חסרון גדול העלול לפגוע בזמינות תחנות.
עלול לחייב התקנה על שרתים רגישים (כגון בסיסי נתונים) עובדה שתפגע בביצועי שרתים. התקנה שעלולה להכביד מבחינת CPU על תחנת הקצה.
במידה ויש יותר מ  Gateway אחד לרשת, יתכן ותידרש התקנה של יותר מרכיב אחד. כדי להיות אפקטיבי, מחייב התקנה על כל תחנות הארגון.
כנראה לא מסוגל לנטר אפליקציות P2P כגון Messenger. לא יתפוס זליגת מידע הנובע מסוס טרויאני המותקן על שרת ושולח מידע החוצה.

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

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

הערות:

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

4 Responses to “בחירת מערכת למניעת זליגת מידע רגיש – Information Leakage Prevention”


  1. 26/02/2008 ב- 11:07

    אני מניח שהניטור החיובי ( ? ) הזה עולה במחיר מהירות גלישה של האירגון ?

  2. 26/02/2008 ב- 11:36

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

  3. 26/02/2008 ב- 17:20

    חיובי מבחינת האירגון, שהרי מטרתו למנוע זליגה מכוונת ובלתי מכוונת החוצה.

  4. 27/02/2008 ב- 8:49

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


להשאיר תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s


פברואר 2008
א ב ג ד ה ו ש
« ינו   מרץ »
 12
3456789
10111213141516
17181920212223
242526272829  

%d בלוגרים אהבו את זה: