10
ספט
08

הגנה על בסיסי נתונים Database Security

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

הפתרון שנבחר

לאחר בחינת מספר אלטרנטיבות, הוטמע בארגון פתרון Database Firewall. בחרנו בפתרון שמותקן על שרתי ה – DB ולא רכיב המותקן ברשת. השיקול העיקריים היו:

  1. להיות 'הכי קרובים' למידע כך שאם מישהו מגיע למסד הנתונים שלא דרך רשת ה – LAN , הפתרון יתפוס גם עליו.

  2. אפס שינויים בטופולוגית הרשת וביטול התלות באיש התקשורת, בפרט אם תהיה תקלה ברשת והנטייה שלו תהיה לעקוף את ה – DB FW.

  3. שליטה מלאה של מנהל אבטחת מידע במוצר, ללא נגיעה של איש תקשורת (וגם לא של DBA).

  4. החשש העיקרי היה של השפעה על ביצועים על בסיסי הנתונים. בינתיים זה בסדר.

מענה נדרש ו – Use Case

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

  1. הגבלת גישה מסדי נתונים ואובייקטים מסוימים. יש לציין שבהרבה מקרים לא ניתן, מבחינה עסקית, לחסום גישה לבסיסי נתונים. 'אני המפתח של המערכת, איך אני יכול לפתח בלי גישה לבסיס הנתונים של כרטיסי אשראי…?'

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

הממצאים

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

איש פיתוח מחליט לגלות את מספר כרטיס האשראי של עובד אחר במחלקה שלו. הוא פותח בחקירה. ראשית, הוא מתחבר לבסיס נתונים רגיש דרך  סיסמא של משתמש אפליקטיבי. לאחר מכן הוא מריץ שאילתא על שמות טבלאות שהשם שלהן מורכב מ: Crdit Card. הוא מוצא את Credit_Card_Tbl.

העובד מציג את השדות בטבלה זו ולאחר מכן מריץ את השאילתא:

 select customer_name, id_num, cc_num from Credit_Card_Tbl

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

 select customer_name, id_num, cc_num from Credit_Card_Tbl where rownum<100

הוא חוקר את הפלט ומגיע למסקנה שזה מה שהוא צריך.

עכשיו הוא ניגש לטבלה אחרת ומריץ את השאילתא הבאה:

 select customer_name, id_num from Customer_Tbl where customer_name like ‘%moshe cohen%’.

יש לו את מספר תעודת הזהות של החבר שלו.

עכשיו הוא מריץ את השאילתא הבאה:

 select customer_name, id_num, cc_num from Credit_Card_Tbl where id=’31234567’.

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

IP: 192.168.1.200; PC: dev123; select customer_name, id_num, cc_num from Credit_Card_Tbl

IP: 192.168.1.200; PC: dev126; …

IP: 192.168.1.200; PC: dev123; select customer_name, id_num, cc_num from Credit_Card_Tbl where rownum<100

IP: 192.168.1.200; PC: dev152; …IP: 192.168.1.200; PC: dev123; select customer_name, id_num from Customer_Tbl where customer_name like ‘%moshe cohen%’

IP: 192.168.1.200; PC: dev126; …

IP: 192.168.1.200; PC: dev1823; …

IP: 192.168.1.200; PC: dev123; select customer_name, id_num, cc_num from Credit_Card_Tbl where id=’31234567'

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

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

מודעות פרסומת

12 Responses to “הגנה על בסיסי נתונים Database Security”


  1. 1 דמניוק
    11/09/2008 ב- 22:54

    זה נשמע כמו מערכת ניטור ולא כמו firewall שמטרתו למנוע גישה לא מאושרת(שבמקרה של גניבת מידע מגורם מאושר לא תמנה כל כך).

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

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

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

  2. 12/09/2008 ב- 0:28

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

  3. 3 דמניוק
    12/09/2008 ב- 0:50

    טוב מין הסתם מי שכבר מורשה לשלוף מאותה טבלה, יותר נכון להשתמש ביוזר פרויקטלי שהוקצה עבורו לשליפות אז הוא יכיר טוב מאוד את ה- ERD של ה- DB.

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

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

    אבל כמובן שהטמעת מערכת SIM תעשה לך את החיים יותר קלים ותפנה לך את הזמן שאתה חופר בלוגים.

  4. 12/09/2008 ב- 3:45

    אשמח לקרוא איזה מערכות בחנת וכן נה הסיבות שהמערכת לא נבחרה.

  5. 13/09/2008 ב- 17:16

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

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

    אני אשלח אליך מייל בערוץ פרטי ונוכל להמשיך משם…

  6. 20/09/2008 ב- 14:39

    מחכה למייל בפרטי 🙂

  7. 30/09/2008 ב- 19:48

    לגבי שימוש ביוזר אפליקטיבי, למה לא להגביל את השימוש בו באמצעות כלי Application Identity Management (לשם הגילוי הנאות, החברה בה אני עובד מייצרת מוצר כזה)?

  8. 01/10/2008 ב- 16:42

    בסביבות מסוימות, בעיקר של אפליקציות ישנות (Legacy), ישנן תוכניות ושגרות רבות שרצות על אותו יוזר. לא תמיד ניתן לעשות שימוש במוצר כזה.
    המוצר שלך אולי מדבר טוב עם מערכות Windows/.Net אבל לא בהכרח עם כאלה שנכתבו לפני עשר ועשרים שנה.
    מעבר לכך, אם היוזר מוטבע (Hard Coded) בתוכניות וסקריפים שהושקעו בהם אלפי שנות אדם פיתוח, לא תמיד תמצא את כל המופעים של היוזר והסיסמא.

  9. 04/10/2008 ב- 11:36

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

  10. 10 שאול
    06/10/2008 ב- 13:29

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

  11. 06/10/2008 ב- 16:48

    לדעתי, השוואה נכונה בין מערכות אינה כוללת השוואת Feature Lists. "למי יש יותר גדול…"
    בדקתי בעבר מערכות סופר יקרות שלא נתנו מענה לתכונה אחת מסכנה. לאחר מכן בחנתי מערכת שאינה Best of Breed, וגיליתי שהיא נותנת מענה לסט תכונות בסיסיות וגם לתכונה הכי חשובה. הבחירה הנכונה תהיה לבחור במערכת השניה.
    לכן, ההשוואה שאני עשיתי מתאימה לצרכים של הארגון שלי ולמגבלות שהיו לי באותו זמן. גם עבר מאז לא מעט זמן – מוצרים משתנים הרבה בפרק זמן כזה.
    בנוסף, אם עשיתי תהליך חלקי ו/או לקוי, ואתה תסתמך על ההשוואה שלי, החברות עלולות להפגע בגללי.
    אני פירטתי במספר פוסטים לא מעט תכונות חשובות מכלי כזה – רשימה שלא היתה לי כשאני התחלתי את התהליך. זה יאפשר לך לבנות סט פרמטרים להשוואה. עכשיו כל שנשאר לך, זה לפגוש את הספקים ולבחון את הפתרונות שהם מציעים.

  12. 12 Yigal
    07/04/2009 ב- 18:37

    הגנה על בסיס הנתונים הקריטי של ה-AS\400 ניתן למצוא פתרונות על כך אצלי.ניתן לפנות אליי.


להשאיר תגובה

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

הלוגו של WordPress.com

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

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

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

תמונת Twitter

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

תמונת Facebook

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

מתחבר ל-%s


ספטמבר 2008
א ב ג ד ה ו ש
« אוג   אוק »
 123456
78910111213
14151617181920
21222324252627
282930  
מודעות פרסומת

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