אבטחת מידע ב – SAP

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

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

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

• טרנזקציות המאפשרות ניהול הרשאות (כגון SU01). חשוב לבקר באופן שוטף מי מקבל הרשאות אלה (רק מנהלי/מיישמי ההרשאות). מומלץ לנטר במערכת ה – SIEM הגדרת SU01 למשתמשים.
• טרנזקציות המאפשרות עדכון נתונים בטבלאות בייצור. בניגוד לבסיסי נתונים SQL כגון Oracle, MS-SQL, בעולם ה – SAP ניתן לגשת לנתונים ישירות לטבלאות (קצת כמו אקסל). טרנזקציה SE16, ונוספות, מאפשרות גישה כזו. זה סיכון שאסור לאפשר (למעט מקרי חירום) וחייבים לחסום אותו.
• הרשאות המפרות את עיקרון הפרדת הרשויות (Segregation of Duties). ארגון לא אחראי יאפשר בשמחה לעובד אחד גם להקים ספק, גם ליצור דרישת תשלום לאותו ספק, ולבסוף לסגור את הספק במערכת. נשמע מעולה, לא?
• ממשקים אל ומהמערכת שאינם מאובטחים. כמו כל מערכת אחרת, האם הממשקים מוגבלים בהרשאות גישה? האם מידע רגיש (למשל, כרטיסי אשראי) עובר באופן מוצפן?
• כתיבת קוד מעבר לקיים בחבילת הבסיס (למשל ABAP ב – SAP) שחושף את המערכת לפרצות אבטחה.
• התקנת טלאי אבטחה לתשתית המערכת.

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

10 חוקים לניטור וחסימה במערכת DLP

אחת התופעות הידועות והמרגיזות אצל חברות אינטגרציה, בכל הקשור בהטמעת מערכות, היא שהן מתקינות מוצר עם סט בסיסי ומובנה של חוקים ועוזבות. מבחינת חברות אלה, הן סיימו את העבודה והצדיקו את הכסף. מבחינת הארגון, אין לו שימוש אמיתי בחוקים אלה. כבר ציינתי את זה כאן בעבר. זה בערך כמו התחנה המרכזית החדשה בתל אביב שעמדה במשך שנים רבות ללא שימוש (אבל היא הייתה בנויה/מותקנת).
ביקשו ממני לציין חוקי תוכן שכדאי ליישם במערכת DLP – חוקים שיתנו ערך מוסף אמיתי לארגון. אומנם לא כל מערכות DLP מגיעות עם אותן יכולות, אך אני מניח שניתן להגדיר את סט החוקים הבא במערכות המובילות היודעות לנטר תכנים (בניגוד למערכות שיודעות רק לחסום התקני זכרון).
חשוב להכיר את יכולות המערכת מעבר להגדרות חוקים בסיסיות. לרוב, ניתן להגדיר סף (Threshold) שקופץ רק כשעוברים אותו (למשל מעל 5 חזרות של תוכן מסוים באותו מייל). ניתן גם להחריג יחידות ארגוניות או משתמשים בודדים מחוקים מסוימים.
בדוגמאות הבאות ניתן להגדיר לא רק את ערוץ המייל, אלא גם ערוצים נוספים כגון FTP, Web Post, התקני זכרון ניידים ועוד. המערכות יודעות לתמוך במגוון ערוצי תקשורת.

אז הנה מספר חוקים:

1. שליחה של מספרי כרטיסי אשראי. חשוב להפעיל, במידה וניתן, בדיקת תקינות למספרים (בדומה לתעודות זהות, גם למספרי כרטיסי אשראי יש חוקיות) כדי למנוע התראה על מספרים שאינם תקינים (שאינם בהכרח כרטיסי אשראי). חוק חשוב לתקן PCI.
2. שליחה של מספרי תעודות זהות. גם כאן להפעיל בדיקת תקינות ולוודא שמדובר בתעודות זהות.
3. שליחה של תנאי העסקה – שכר, משכורת.
4. שליחה של מידע רפואי (צריך ליצור במערכת מילון של מושגים רפואיים רגישים).
5. שליחת קבצים מספריות ברשת שסומנו כרגישות. למשל, משאבי אנוש, ספריות של אפליקציות עסקיות, הנהלה ודירקטוריון, שיווק.
6. שליחה אל נמענים מהעיתונות כדי לאתר הדלפות.
7. שליחה אל נמענים מחברות מתחרות. האם זה תקין שעובד בחברת סלולר אחת ישלח מייל לחברת סלולר מתחרה?
8. שליחה של סיסמאות. נזהה את זה בין השאר ע"י הביטויים: סיסמא, סיסמה, סיסמאות, admin ועוד.
9. שליחה של נתוני עמלות. סוכן מכירות של החברה ינסה להשיג ממקור פנים נתוני עמלות של סוכנים מתחרים.
10. שליחה של שאילות לבסיסי נתונים. נזהה ע"י הימצאות כל הביטויים הבאים: select, from, where

תרשים סיכונים מערכות/מנגנוני הגנה ומניעה

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

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

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

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

הערות כלליות:

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

 הערות על מערכות:

• DB FW: ניתן להגדיר הרשאות גישה עפ"י יוזר מערכת הפעלה, יוזר בסיס נתונים, כתובת IP, שם מחשב ועוד. יכול לאפשר מניעת גישה לשדות רגישים או ניטורם. מאפשר לנטר ולחסום נסיונות Brute Force.
• DLP: יכול לחסום התקני זכרון נתיקים, למנוע או לנטר שליחה/שמירה של מידע רגיש על סמך ביטויים/תכנים או ספריות ברשת.
• הצפנת כונן קשיח משלב ה – Boot: מונעת אפשרות לאתחל את המחשב באמצעים עוקפי מערכת הפעלה של הכונן.
• AFW: מגן בפני התקפות בקלטים באפליקציה, בפלטים ובניצול חולשות על השרת, מניעת התקפות DoS.
• XML FW: מגן בפניות ל – Web Services כנגד התקפות XML המובילות ל – DoS, מניעת זליגה דרך SQL Injection.

עקיפת Listener

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

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

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

סיכונים הנובעים מ – Listener

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

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

ה – Listener  הינו רכיב תוכנה של Oracle המאפשר תקשורת בין המשתמש לבסיס הנתונים.  מכאן שלרכיב זה יש חשיבות מאוד גבוהה באבטחת מידע. גורם זדוני שפוגע ברכיב זה, פוגע למעשה בתקשורת לבסיס הנתונים. הוא דומה ברעיון ל – Socket של פרוטוקול TCP/IP אשר מאזין לתעבורת רשת בפורט מסוים. בברירת מחדל, ה – Listener  מוגדר להאזין על תעבורה המגיעה על פורט 1521.

היעדר אבטחה על ה – Listener  עשויה להוביל לסיכונים הבאים:

• מניעת שירות (DoS) לבסיס הנתונים. פורץ יוכל להפסיק את פעולת הרכיב. בנוסף, פורץ שמשיג שליטה ב – Listener  יכול להגדיר ל – Listener סיסמא לא מוכרת ולמנוע מ – DBA לשלוט להבא ברכיב.  דרך נבזית נוספת היא הגדרת Timeout של שניה אחת להתחברות לבסיס הנתונים. מהר מאוד, כמות הפניות להתחברות לבסיס הנתונים (דרך ה – Listener) תהיה גבוהה מאוד ותוביל למניעת שירות.
• גניבת מידע רגיש. הפורץ יכול להגדיר כתיבת Trace על פעולות מול בסיס הנתונים. למשל, פעולת החלפת סיסמא. במקרה כזה, ה – Trace עשוי לתעד את הסיסמא החדשה באופן נגיש לפורץ.
• גישה לא מורשית (פריצה) לשרת. פורץ יוכל  להגדיר כתיבת קובץ שידרוס את קובץ .rshosts שמגדיר לאיזה כתובות IP מותרת גישה. דריסת הקובץ אפשרית מכיון של – Listener  יש הרשאה גבוהה על השרת.

אלה לא כל החולשות של הרכיב. ישנן עוד רבות שהאקרים ו – DBAs מכירים. מספר נקודות חשובות להקשחת הרכיב (ויש עוד הרבה שלא ציינתי):

• לשדרג את בסיס הנתונים לגרסת Oracle מתקדמת. ככל שהגרסה מודרנית יותר, כך הרכיב מאובטח יותר בברירת מחדל. תת גרסה מתקדמת של 10g תאפשר, למשל, חיבור ל – Listener  על בסיס משתמש של מערכת הפעלה LOCAL OS AUTHENTICATION כדי למנוע ניהול הרכיב מרחוק (ובכך לאפשר פריצה).
• התקנת טלאי (Patches) אבטחת מידע של אורקל.
• לשנות את ה – TNS Port בו הוא מאזין לפורט שאינו ברירת מחדל.

לסיום, חשוב תוודאו שבזמן שמאבטחים את בסיס הנתונים, מטפלים גם בהקשחת ה – Listener.

 

מה לנטר בבסיסי נתונים

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

• מספר כשלונות בהתחברות לבסיס נתונים (בעיקר בסביבת ייצור)

• התחברות ליוזרים המגיעים עם התקנת המערכת (Default Users)

• התחברות דרך כלי SQL (למשל sqlplus) לבסיס נתונים בייצור

• התחברות לבסיס נתונים בשעות לא סבירות

• התחברות מכתובות IP לא מקובלות

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

• ביצוע עדכון טבלאות ע"י משתמש שאינו אפליקטיבי 

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

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

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

ניסיון עקיפת 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 על טבלאות רגישות וטבלאות חדשות.

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

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

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

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

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

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

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

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

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

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

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

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

GRANT GRANT ANY OBJECT PRIVILEGE TO user

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

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

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

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