30
נוב
08

ניסיון עקיפת Database Firewall ע"י פקודות DML, DDL

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

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

create table TMP_TBL as select * from TBL

או יצירת טבלה ריקה ואז:

insert into TMP_TBL select kp1.* from TBL where …

כאשר ה – where ממלא את הטבלה הזמנית רק בנתונים שמישהו מעוניין בהם.

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

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

6 Responses to “ניסיון עקיפת Database Firewall ע"י פקודות DML, DDL”


  1. 30/11/2008 ב- 21:46

    נדמה לי שבפתרונות מבוססי השרת, שמסוגלים לנתח את הביצוע של ה-SQL-ים, יתבצע ניטור נכון של פעולה מסוג זה.
    לגבי FWDB – האם כל המוצרים בנושא נופלים בבעיה מסוג זה?

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

  2. 01/12/2008 ב- 22:24

    אם אני לא טועה ניתן להגדיר סוג ומבנה של נתונים רגישים ב – Database Firewall ובכך לאפשר גמישות של איתור נתונים אלו בכל טבלה קיימת.
    נושא זה יכול להוסיף עוד מעגל למעגלי האבטחה הקיימים על ה – DB ובכך למנוע בעיה שכזו.(כל זאת וניתן להכניס את הנתונים למבנה מובן וקבוע).

  3. 01/12/2008 ב- 22:42

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

  4. 01/12/2008 ב- 22:47

    רוני, אתה יכול להגדיר ניטור אחר פעולות, אבל לא אחר מבני נתונים. אפשר לנסות משהו מאוד מורכב כגון ניטור Like של מידע מסויים, אבל זה מאוד קשה למימוש כאשר יש לך עשרות סוגי מידע רגיש וזה עלול לחנוק את שרת ה – DB FW.
    הכוונה של הפוסט הזה היתה לעורר את תשומת הלב לכך שלא מספיק לנטר טבלאות רגישות כיוון שניתן לשלוף מידע רגיש בדרכים אחרות כגון העתקת לטבלאות זמניות.

  5. 5 ניב
    03/12/2008 ב- 19:08

    אני רוצה לראות DBA בינוני ומעלה, אתם יודעים מה, DBA טוב ומעלה, שלא עוקף את המגנונים לניטור בסיסי נתונים ב-3.14 דקות מקסימום. אבל זה לגבי DBA.
    אמירה אחת מפריעה לי: "למנוע הרשאות… ממפתחים… אפילו אם זה בסביבת פיתוח". ועל זה נאמר – חלומות בהקיץ. תראו לי סביבה אחת בעולם, כולל בסביבות הכי מאובטחות בטחונית, בהן אפשר לבוא למפתח ולהגיד לו יש לך הרשאות חלקיות בלבד אבל בוא תפתח בכל זאת. לא ריאלי, לא ישים, לא קיים.

  6. 04/12/2008 ב- 9:16

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


להשאיר תגובה

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

הלוגו של WordPress.com

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

תמונת Twitter

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

תמונת Facebook

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

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

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

מתחבר ל-%s


נובמבר 2008
א ב ג ד ה ו ש
« אוק   דצמ »
 1
2345678
9101112131415
16171819202122
23242526272829
30  

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