Archive for the 'הגנה על בסיסי נתונים' Category



17
ינו
08

פריצה לבסיס נתונים: קשה או קל?

מומחי אבטחת מידע רבים טוענים שקל לפרוץ לבסיסי נתונים (בין אם ישירות ע"י גישה ל – DB ובין אם דרך אתרים). התקפות שונות כגון SQL Injection (הזרקת קוד SQL עוין) או Cross Site Scripting (התקפה המכונה XSS בה שותלים סקריפטים עוינים באתרים) מאפשרות התקפות על אתרים ובסיסי נתונים. ובאמת, ישנם הרבה מומחים ואתרים המוכיחים כמה קל לבצע התקפות כאלה ואחרות.

אינני מנסה לטעון שזה לא נכון וגם אינני יכול לטעון שמהערכות שלנו מאובטחות ב – 100%. אבל הנה חומר למחשבה:

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

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

07
ינו
08

שיקולים בבחירת פתרונות Database Security

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

הצפנה

  • מצריכה שימוש בתוכנה – עלות לא קטנה.
  • ניהול מפתחות הצפנה, גיבוי, ואבטחת המפתחות – לא טריוויאלי.
  • דורשת תכנון קפדני מה לא להצפין (האם אפשר להצפין אינדקסים? Primary Key?).
  • כיצד אפליקציות יידעו לפענח הצפנות?
  • אבחנה בין משתמש שמגיע למידע דרך אפליקציה (שאמור לראות מידע רגיש) לבין אותו משתמש שמגיע ב – SQL (לא דרך אפליקציה ובמקרה כזה לא אמור לראות מידע רגיש).
  • אפשרות להפריד בין ניהול התוכנה  (ברמת Administrator) לבין ניהול ההצפנה/מפתחות (למשל, כדי ש – DBA לא יוכל לראות מידע רגיש). 

הגבלת הרשאות

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

פתרון ברמת/שכבת בסיסי הנתונים

  • עלול להיות מוגבל ביכולות (לא Granular).
  • עלול לצרוך משאבי CPU רבים.
  • האם מצריך התקנות רבות?

פתרון רשתי

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

אתם מוזמנים להוסיף שיקולים משלכם. 

31
דצמ
07

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

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

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

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

  1. הצפנת שדות רגישים ע"י תוכנה.
  2. הגבלת הרשאות גישה ברמת אובייקטים דרך ההרשאות של ה – DB.
  3. הגבלת הרשאות גישה ברמת עמודה ע"י פתרון כגון Database Vault (לסביבת Oracle).
  4. הגבלת גישה ע"י Database Firewall.

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

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

תמים שנה אזרחית טובה לכולם תמים

CISO

30
ספט
07

סיסמאות לבסיסי נתונים

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

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

אז לא להתעצל, ולהגדיר לסביבת הייצור סט סיסמאות שונה.

CISO

30
אוג
07

AFW ו – DB FW

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

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

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

CISO




ספטמבר 2020
א ב ג ד ה ו ש
 12345
6789101112
13141516171819
20212223242526
27282930