בדיקה שלוקחת שתי דקות: נכנסים למרכז הניהול של Microsoft 365, מסננים את רשימת המשתמשים לפי תפקיד, וסופרים כמה חשבונות מוגדרים כמנהל מערכת כללי (Global Admin).
המספר כמעט תמיד גבוה ממה שבעל העסק היה מנחש. וכשעוברים על הרשימה אחד-אחד, מתברר מי יושב שם: הבעלים, מנהל התפעול שפעם היה צריך לפתוח משתמש חדש, ספק חיצוני שהקים את הסביבה לפני ארבע שנים ומעולם לא הוסר, חשבון גנרי בשם admin שהסיסמה שלו מופיעה בקובץ אקסל משותף, ולא פעם גם עובד שכבר לא עובד כאן.
אף אחד לא ישב והחליט שכך ייראה מערך ההרשאות בעסק. הוא הצטבר, החלטה קטנה אחרי החלטה קטנה, ואף אחד לא חזר לנקות.
מה מנהל מערכת כללי באמת יכול לעשות
התיעוד של Microsoft לא מנסח את זה בעדינות: למנהל מערכת כללי יש גישה כמעט בלתי מוגבלת להגדרות הארגון ולרוב הנתונים שלו. בפועל זה אומר איפוס סיסמה של כל משתמש בארגון, כולל של מנהלים אחרים, ניהול מנויים ורישיונות, וגישה להגדרות של כל שירות. יש גם פרט שמפתיע אנשים: מנהל מערכת כללי אינו יכול להסיר את התפקיד מעצמו. מישהו אחר חייב לעשות את זה.
המשמעות המעשית פשוטה. כל חשבון כזה הוא עותק מלא של המפתח לארגון. חשבון שנפרץ אינו אירוע של משתמש אחד אלא אירוע של כל סביבת Microsoft 365. תוקף שמחזיק הרשאות ברמה הזו יכול למחוק תיבות, לשנות כללי העברה, ולהגיע גם ליעדי הגיבוי אם הם נשענים על אותה מערכת הזדהות. זו בדיוק הסיבה שפתרונות של גיבוי חסין שינוי בנויים כך שגם הרשאה לגיטימית ברמה הגבוהה ביותר לא יכולה למחוק את העותק השמור.
איך מגיעים למצב הזה בלי להחליט עליו
- ההקמה הראשונית. מי שהקים את הסביבה נשאר מנהל-על, גם אם היום הוא רק מחדש רישיונות פעם בשנה.
- ספק חיצוני. קיבל הרשאות מלאות כדי לבצע פרויקט מוגדר, והפרויקט נסגר לפני שנתיים.
- רק לרגע. מישהו נתקע בלי הרשאה, קיבל מנהל-על כדי לפתור מהר, ואף אחד לא הוריד את זה אחרי.
- החשבון המשותף. חשבון admin שכולם משתמשים בו. כשמשהו קורה, אין דרך לדעת מי ביצע את הפעולה.
- העובד שעזב. התפקיד נשאר גם אחרי שהרישיון בוטל. על מה עוד נשאר מאחור כתבנו בפוסט על תיבת הדואר של העובד שעזב.
התפקיד הכי פחות מתיר שמספיק למשימה
ההנחיה של Microsoft בתיעוד היא להחזיק כמה שפחות מנהלי מערכת כלליים, ולהקצות לכל אדם את התפקיד הכי פחות מתיר שמאפשר לו לבצע את עבודתו. ברוב העסקים אפשר לרדת מרשימה ארוכה של הרשאות מלאות לשניים-שלושה חשבונות, בלי שאף אחד ירגיש הבדל ביום-יום. הטבלה הבאה מראה מה מספיק למשימות הנפוצות:
| המשימה בפועל | התפקיד שמספיק | מה הוא לא יכול |
|---|---|---|
| איפוס סיסמאות, ניתוק משתמש תקוע | מנהל מערכת של צוות תמיכה | לא נוגע בחשבונות של מנהלים |
| תיבות דואר, שחזור פריטים שנמחקו, הרשאות שליחה בשם | מנהל מערכת של Exchange | אין גישה לחיוב ולמנויים |
| פתיחת משתמשים חדשים, הקצאת רישיונות | מנהל משתמשים | לא מעדכן מאפייני Exchange Online |
| חשבוניות, חידוש מנויים | מנהל חיובים | אין גישה לנתוני משתמשים |
| ביקורת, הכנה ל-ISO 27001, צפייה בהגדרות | קורא כללי | קריאה בלבד, לא משנה דבר |
השורה האחרונה שימושית במיוחד. רואה חשבון, יועץ או מבקר שצריך לראות את ההגדרות לא צריך הרשאת כתיבה בכלל, וזה בדיוק סוג ההרשאה שנוטים לתת ביד רחבה מדי.
החשבון היחיד שכדאי דווקא להוסיף
צמצום הרשאות בלי תכנון יוצר סיכון הפוך: נעילה מחוץ לסביבה. Microsoft ממליצה על שני דברים משלימים. הראשון הוא חשבונות מנהל ייעודיים, נפרדים מחשבון המשתמש היומיומי, במקום תפקיד ניהול שתלוי על אותו חשבון שממנו קוראים מיילים וגולשים. השני הוא חשבון גישה לשעת חירום, שנועד למנוע נעילה בטעות מחוץ למערכת הזהויות.
חשבון חירום מעשי בעסק קטן נראה כך: חשבון ייעודי שאינו שייך לאף אדם, סיסמה ארוכה ששמורה פיזית ולא במנהל הסיסמאות של הצוות, אפס שימוש ביום-יום, והתראה שנשלחת ברגע שמישהו נכנס איתו. וכמו בכל שאר חשבונות הניהול, התיעוד מדגיש שאין להשאיר אותם בלי שכבת ההגנה הנוספת של אימות דו-שלבי.
מה עושים עם זה השבוע
- פתחו את מרכז הניהול, סננו את המשתמשים לפי תפקיד, וכתבו את רשימת מנהלי-העל על נייר.
- מול כל שם ענו על שתי שאלות: מה הוא עושה עם ההרשאה, ומתי השתמש בה בפעם האחרונה.
- כל מי שהתשובה שלו נכנסת לאחת השורות בטבלה למעלה, העבירו לתפקיד הצר יותר.
- הפרידו את חשבונות הניהול מחשבונות השימוש היומיומי.
- ודאו אימות דו-שלבי על כל חשבון שנשאר עם הרשאות ניהול.
- הקימו חשבון חירום אחד, ותעדו היכן הסיסמה שמורה ומי רשאי לגשת אליה.
- שמרו את הרשימה. בביקורת ISO 27001 ובתהליכי היערכות לתיקון 13 שואלים בדיוק את זה: מי מורשה, מכוח מה, ומתי נבדק לאחרונה.
הרשאות של בני אדם הן רק חצי מהתמונה. אפליקציות צד-שלישי מקבלות גישה לתיבות בלי סיסמה בכלל, דרך מנגנון הסכמה נפרד לגמרי מרשימת המנהלים. פירטנו איך זה עובד בפוסט על הרשאות אפליקציות ב-Microsoft 365.
שאלות שחוזרות
כמה מנהלי מערכת כלליים מותר שיהיו?
Microsoft אינה נוקבת במספר. ההנחיה בתיעוד היא להחזיק כמה שפחות. הכלל המעשי: מספיק כדי שלא תיתקעו בחוץ אם אדם אחד לא זמין, ומעט מספיק כדי שתוכלו למנות את כולם בעל פה.
אם אוריד לעובד את תפקיד מנהל-העל, הוא יאבד גישה למיילים שלו?
לא. תפקיד הניהול נפרד מהרישיון ומתיבת הדואר. הסרת התפקיד משפיעה רק על מה שהוא רשאי לעשות במרכז הניהול, לא על העבודה היומיומית שלו.
אפשר להסיר את התפקיד מעצמי?
לפי התיעוד של Microsoft, מנהל מערכת כללי אינו יכול להסיר לעצמו את ההקצאה. נדרש מנהל כללי נוסף שיעשה זאת, וזו עוד סיבה לא לרדת למנהל-על יחיד בארגון.
האם ספק ה-IT צריך להיות מנהל-על באופן קבוע?
לא בהכרח. לחלק גדול מהעבודה השוטפת מספיקים תפקידי Exchange, ניהול משתמשים או תמיכה. כשנדרשת הרשאה מלאה לפרויקט, עדיף להקצות אותה לתקופה מוגדרת ולהסיר בסיומה.
שורה תחתונה
אם אינכם יודעים כרגע כמה מנהלי-על יש בארגון, זו הבדיקה הראשונה שכדאי לעשות. היא לוקחת פחות זמן מפגישה, והתוצאה שלה כמעט תמיד מפתיעה. אנחנו מבצעים את המיפוי הזה כחלק משירותי אבטחת מידע וסייבר, לצד הפרדת חשבונות ניהול והגדרת חשבון חירום. ואם נוח לכם לעשות את זה לבד, הטבלה והצ׳קליסט שלמעלה מספיקים כדי להתחיל. אם תעדיפו שנעבור על זה יחד, כתבו לנו.
אריאל מרום, מייסד ומנכ״ל M-Challenge ומוביל פיתוח MCS – Managed Cyber Security. פעיל בתחום המחשוב, הענן ואבטחת המידע מאז 2007.