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