אל יתהלל מדליף כמפתח

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

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

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

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

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

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

כיצד ניתן לצמצם את הסיכון לדלף מידע מסביבות נמוכות ?

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

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

1.1 דריסת הנתון בערך פיקטיבי, למשל הכנסת מחרוזת "111111" בשדה ת.ז.

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

1.3 הצפנת המידע - לכאורה נראה כפתרון אידיאלי, כיוון שהמידע האמיתי נחשף בעת הצורך רק למי שיש ברשותו את מפתח ההצפנה למשל מנהל המערכת. מלבד העובדה הבעייתית שחשיפת מפתח ההצפנה חושפת את כלל הנתונים, ביצוע הצפנה משנה את מבנה ותצורת המידע ופוגע באמיתות המידע.

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

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

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

הכותב הוא מנהל תחום אפליקציות באבנת אבטחת מידע