Best practices and guidelines for security permissions

23 ביוני 2012

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

כמה מילים על נוהגים מיטביים (Best Practices).
ראשית – נתקלתי במינוחים עבריים רבים לתיאור צמד המילים, אך בצמד "נוהגים מיטביים" נתקלתי לראשונה בבלוג של יגאל שניידר והחלטתי לאמץ אותו. אז מה הם בעצם "נוהגים מיטביים" ? מדובר בסט חוקים לפעמים כתובים, לפעמים לא, ליישום מיטבי של ארכיטקטורה – או במילה אחת: פרקטיקה. למעשה קיימות הנחיות Best practice של יצרנים מסוימים, אך לרוב מדובר ב "דרך מומלצת" של אותו ייצרן, ולא הנחיה או הוראה. Best practice לרוב מגובשים ע"י הקהילה או מומחים בתחום מסוים. אני אישית מאוד חובב את צמד המילים האלו, וטורח לחפש אותם בצימוד למילות מפתח של כמעט כל פרויקט חדש שאני מתחיל להטמיע.

קצת על מנגנון ההרשאות ומעבר אל הקווים המנחים.
רשימת ההרשאות (DACL) מכילה בתוכה רשומות ACE המכילות SID וסוג הרשאה. הרשימה מוגבלת ל 64K (בערך 1800 רשומות), אך מאבדת ייעילות רבה כבר ב 32K ולכן מומלץ להתרחק מכך עד מאוד. סדר היישום של הרשימה – קודם כל הרשאות DENY, לאחר מכן הרשאות ייעודיות לאותו אובייקט, ולבסוף ההרשאות שאותו אוביקט ירש מאביו.

ברשותכם, אתמקד בכמה קווים מנחים חשובים:

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

2. השני, לא להתעסק עם הרשאות שהמערכת נתנה,  לא להוסיף הרשאות, אבל במיוחד לא להוריד. אם המערכת נתנה אותם, כנראה שיש סיבה, ואם היא לא נתנה אותם אפילו לאדמיניסטרטורים (למשל על קבצים ב System32) כנראה שגם יש סיבה. סיפור נחמד הוא בזכות חוכמתו והתחכמותו של איש אבטחת מידע – שהחליט שהוא ייכול להגן ממצב שמישהוא "ייתחזה לחשבון System" (הנונסנס הזה – במילותיו שלו), הוא הוריד את כל ההרשאות ל System מספריות שהיו נראות דיסקרטיות…. כעבור כמה חודשים ווירוס שהיה על לפטופ כלשהוא, שינה את כל הקבצים ב Share לפורמט  FileName.doc.exe (שיטת הסוואה של ווירוסים). מהשינוי שהוא עשה, תוכנת האנטי ווירוס על שרת הקבצים לא ייכלה לגשת לאותם קבצים ולראות אותם, וגרוע מכך – תוכנת הגיבוי לא הגיעה לאותם קבצים ולכן לא ייכלנו לשחזר אותם… הסיפור נגמר בכך שבמאמצים רבים מצאנו תוכנת אנטי ווירוס שיודעת "לתקן" את כל אותם קבצים.

3. לא לתת הרשאות למשתמשים – רק לקבוצות.
את הכלל הזה אני מאמין מכיר כל SysAdmin אחרי כמה שנים בתפקיד, יש המון סיבות לכך – הראשונה זו מחלת ה Sid's שתוקפת כל אובייקט אחרי כמה שנים. אנחנו מתחילים לראות את הג'אנק מצטבר עליו בלי שיש לנו ייכולת להבין מה אלו אותם הרשאות, ולוקח לנו 10 -40 שניות עד שבכלל עולה לנו רשימת ה ACL של האובייקט – ובינינו – מי יינקה את זה עכשיו?. הסיבה השנייה היא העברה של כל אותם הרשאות למחליף, איך זוכרים איפה נתנו הרשאות? איך נדאג שהמחליף ייקבל את כל ההרשאות ולא ייתקשר אלינו בחמישי בערב של Access deny לאיזה ספרייה….הסיבות הן רבות… ההמלצה האישית שלי היא לייצר לכל הרשאה שאתם אי פעם יוצרים, קבוצה ב A/d למשל Sre_mgmt_fldr_Director_Modify או Usr_GidonM_Clndr_READ ולה לתת את ההרשאות.

 4. המלצה – לחלק את קבוצות ההרשאה לקבוצות "משאבים" וקבוצות "אנשים". השיטה הזו מכונה לרוב השיטה ההיברדית, מכיוון שהיא לוקחת גם את השיטה שהצגתי בסעיף 3, וגם את השיטה הפשוטה של ניהול קבוצות משתמשים, הרעיון הוא לקחת קבוצה כמו זו שייצרנו קודם (לדוגמא Usr_GidonM_Clndr_READ) ולתת אותה לכל קבוצת העובדים שכפופים אלי. ניהול חכם בשיטה הזו ייכול להביא לחסכון ניכר מאוד בניהול המשתמשים, תהליכי קליטת משתמשים והתליכי החלפת תפקידים בצורה חלקה ויעילה. כדאי מאוד להיזהר מקולגות שלכם שייתקשו בהתחלה להבין את השיטה – אני נתקל לפעמים בלופים (LOOP) אין סופיים של קבוצות מקוננות, רק כי מישהוא לא הבין את המנגנון…

מתוך networkadminkb.com – מאמר מומלץ!

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

6. אל תבטלו את מנגנון הירושה – נצלו אותו.
בצילום המסך ייתכן ותבחינו בעמודה ובאפשריות שלא ראיתם עד כה, אתם ייכולים לבחור עד לאיזו רמה תחלחל ההרשאה שנתתם, כך למשל בספרייה הראשית של השיתוף תוכלו להגדיר List Folder אל This Folder Only ובכך לאפשר עיון ברשימת הקבצים והספריות רק של הספריה הזו, לצערי אני רוב הזמן נתקל באנשים שבוחרים להוריד את ה V שסימנתי מטה במקום לנהל את ההרשאות באופן הנכון.

 

אלו הם הדברים החשובים, ובעצם אלו שאני נתקל בהם בעבודתי מדי יום…

שבוע טוב.

 

על הכותב: גדעון מרקוס, בוגר חיל האוויר הישראלי – רצ’
סיס-דסק בבסיס צבאי גדול בדרום הארץ. כיום, מומחה סיסטם בכיר לתחום הקליינט
במשטרת ישראל, משתתף פעיל בפורומים וקהילות בתחומי ה IT בארץ ובחו”ל.

בקרו אותי בלינקדין:

View Gidi Marcus's profile on LinkedIn

 

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים

תגובה אחת