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



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 ולמצוא את אותם לוגים שהצביעו על הפעולות האסורות.

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

מודעות פרסומת
11
יונ
08

שימוש של מתכנתים במשתמש אפליקטיבי

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

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

לכן חשוב להגביל את השימוש ביוזר זה. למשל:

  1. להגדיר סיסמא קשה לניחוש שרק מעטים יודעים אותה.

  2. להגביל את הגישה במשתמש זה רק לאפליקציה.

  3. להגדיר הרשאות נמוכות ככל הניתן על משתמש זה (למשל, להריץ Stored Procedures מסוימים בלבד).

  4. להגדיר מדיניות אכיפה שתבהיר לאנשים שאין לעשות שימוש אישי במשתמש זה.

22
אפר
08

הרשאות גבוהות בבסיסי נתונים

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

GRANT GRANT ANY OBJECT PRIVILEGE TO user

  • ה – Grant הראשון זו הפקודה להעניק הרשאה כלשהי.

  • ה – Grant השני זו ההרשאה (במקרה זה להעניק הרשאות לאחרים).

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

המסקנה: אין להסתפק בחיפוש משתמשים בעלי הרשאה מובנית גבוהה (למשל SA בבסיס נתונים של מיקרוסופט).

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




ספטמבר 2019
א ב ג ד ה ו ש
« ספט    
1234567
891011121314
15161718192021
22232425262728
2930  
מודעות פרסומת