בכל ארגון ישנם לפחות אחד או יותר בסיסי נתונים (Databases), חלקם לסביבת ה-Production, חלקם לסביבת Test, אחרים לצרכי QA ועוד. במרבית המקרים, הגישה הרווחת בקרב האמונים על אבטחת התשתיות היא: ישנו Firewall העומד בשער וחוסם את כל מי שלא מורשה להיכנס לארגון; ברמת התקשורת - סגורים כל הפורטים מלבד אלו המשמשים גישה אל בסיס הנתונים; השרתים אשר עליהם מותקנים בסיסי הנתונים מוקשחים בטלאי האבטחה של מיקרוסופט; כך שההרגשה והגישה הרווחת הינה שבסיסי הנתונים מאובטחים היטב.

הבעיה

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

הרשימה להלן מכילה חלק מן ה-Default Ports של אפליקציות בסיסי הנתונים המובילות:

Oracle - 1521, 1810, 2481, 7778

SQL Server - 1433, 1434, 2433

DB2 - 446, 50000, 60000, 60001, 60002, 60003, 523

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

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

הפתרון

על-מנת להגן על בסיסי-הנתונים בארגון מומלץ להתקין את טלאי האבטחה של החברות שמפתחות את אפליקציות ה DB's (Oracle, Microsoft וכד') ע"פ המלצותיהם. בהקשר זה יש לציין כי במרבית הארגונים לא מתקינים כלל את טלאי האבטחה המסופקים ע"י ה-Vendors (ע"פ סקר אשר פורסם לפני כשבוע - יותר מ-60% מן הארגונים לא התקינו טלאי אבטחה של Oracle כלל!). כמו-כן, מומלץ לבדוק את כלל בסיסי הנתונים בחברה באמצעות סורקי פרצות אפליקטיביים ייעודיים של חברות המתמחות בהגנה על בסיסי נתונים וזאת ע"מ לחשוף פגיעויות אפליקטיביות אשר הינן ייחודיות לכל סוג אפליקציית Database באופן ספציפי - פגיעויות אשר כמותן נחשפות ומתגלות על בסיס קבוע וכמעט יומיומי, וכן בכדי לחשוף הגדרות תצורה קיימות אשר חושפות את ה-Database לפריצות ופגיעות. נוסף על כך, מומלץ גם לסרוק עם סורקי פרצות (Vulnerability Scanners) סטנדרטיים אשר ביכולתם לוודא שהפורטים הפתוחים אינם פרוצים ופגיעים.

כאשר ברצוננו להגן על מערכות בכלל ומערכות קריטיות בפרט יש להפנים את העובדה שחוזקה של שרשרת ניכר בחולייתה החלשה ביותר. כלומר: ישנו צורך אמיתי להערך עד כמה שאפשר ל- Zero-Day-Attacks ו/או לתקיפות אשר מנצלות פרצות אפליקטיביות ידועות אשר לא אותרו באמצעות שימוש בכלים נפוצים ו/או חופשיים לשימוש. מטרה זו תושג אך ורק באם נהיה מעודכנים ומודעים לחולשות הקיימות במערכת שלנו.

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

דוגמאות

פרצת אבטחה ידועה הנמצאת במערכות Oracle רבות הינה רשימת משתמשי ברירת המחדל של בסיס הנתונים. בגרסאות קודמות של Oracle היו קיימים כ-600 Default Users, אשר יכלו להיכנס לבסיס הנתונים. זוהי פרצה שניתנת לניצול ע"י תוקף פוטנציאלי המכיר את שמות המשתמשים הללו (הרשימה, אשר חלקה מוצג בדפים הבאים, זמינה באינטרנט בחיפוש גוגל פשוט). אחד משלבי התקיפה הראשונים של פורץ פוטנציאלי יהיה לבדוק את הימצאותם של שמות משתמש אלו; במידה ואפילו אחד מהם זמין לשימוש - דרכו של הפורץ אל תוך ה-Database ואל המידע הקריטי ביותר של הארגון - פתוחה. ראוי לציון כי מרבית שמות המשתמשים הללו נחסמו בגרסה 10g, אולם עקב העובדה כי במרבית הארגונים עדיין משתמשים בגירסאות 8 ו-9 על מערכות Production, מומלץ מאוד לבדוק!!!

להלן חלק מצומצם מרשימה ה-Oracle Default Users: