ניהול זהויות ותרחיש Break Glass

מהו PIM? מהו Break Glass Account? מהו תהליך PAM? כל אותם מושגים הם רק חלק בתהליך Privileged Access Management, ותהליך PAM הוא תהליך נדרש בכל סביבה שמתבססת על זהויות ובמיוחד על תשתית זהויות בענן.

תהליך Privileged Access Management הינו תהליך שכולל בתוכו מאפיינים רבים, בין היתר: סוגי חשבונות, סוגי הרשאות, דלגציות, אישור וגישה, מצבי חירום וכן מאפיינים נוספים.

לתהליך Privileged Access Management ישנם מספר מטרות ברורות כאשר המרכזית שבהם היא למנוע גניבת זהויות וגישה לא מורשית אשר עלול להוביל למתקפות שונות וחשיפת מידע ונכסים רגישים.

אחד המאפיינים החשובים בתהליך Privileged Access Management הוא הקשחת חשבונות בעלי הרשאות וישנם מספר חשבונות וזהויות בקטגוריה:

  • Emergency – חשבון בעל הרשאות גבוהות וגישה למערכות ניהול בארגון (לעיתים העתק של חשבון אדמין), חשבון נדרש במצבים שבהם צריך גישה למערכות הארגון עם מאפיינים הזדהות שאינם חזקים במיוחד, למשל סיסמה מורכב, גישה רק מתוך הרשת הארגונית וכן הלאה. במצבים מסוימים נחשב כמשתמש מסוג Break Glass Account למקרים חריגים שבהם אין גישה לחשבונות עלי הרשאות או אדמינים אל מערכות הניהול של הארגון.
  • Local Administrative – חשבון מקומי בעל הרשאות גבוהות לניהול אובייקט מקומי, לרוב משתמש מקומי עם הרשאות אדמין לתחנות קצה. מכיוון שמדובר על חשבון בעל הרשאות, מיישמים פתרון של חשבון אדמין מקומי משותף עם פוליסי מוגדר מראש. אחד היישומים הפופולרים הוא LAPS.
  • Application- חשבון ייעודי לטובת אפליקציה מסוימת עם הרשאות מאוד ספציפיות, מיועד להרצת תהליכים, הרצת סקריפטים וכן הלאה. במקרים מסוימים לחשבון Application עלול להיות גישה למידע חשוב כחלק מתהליך מסוים. אחת הבעיות הנפוצות כיום בארגונים הוא שחשבון זה נשמר על גבי plain text שעלול לגרום לחשיפה של פרטי הזדהות ועלול להוביל למתקפת APT למינהם.
  • Service- חשבון ייעודי לטובת הרצת Services ספציפיים, לחשבון Service ישנם הרשאות שונות ובין היתר עלול להכיל הרשאות גבוהות בגישה למידע ארגוני.
  • Privileged User Accounts – חשבון בעל הרשאות גבוהות (לעיתים יכול להיות אדמין) עם גישה למשאבים ומערכות רבות בארגון.

ישנם חשבונות בעלי הרשאות נוספים, כגון: חשבון Domain Administrative, חשבון Tenant Admin וכן הלאה.

Privilege admin accountתהליך הקמת ותחזוק Privileged Access Management אינו תהליך פשוט, ישנם נהלים רבים ומערכות שיודעות לבצע ולסייע בתהליך מסוג זה, למשל תהליך PAM מול Active Directory מקומי, או תהליך PAM בשירות Office365 או לחלופין עבודה עם מוצר ייעודי כדוגמת CyberArk שהוא המוביל בתחום ומנהל זאת בצורה מצוינת. מידע נוסף לגבי חשבונות עלי הרשאות

גם במצבים שבהם עדיין לא עובדים עם תהליך מסודר של Privileged Access Management, עדיין מומלץ לבצע פעולות שונות כדוגמת תרחיש Break Glass Account או Break Glass Process.

מצבים שבהם מומלץ ליצור חשבון Break Glass Account: (מתייחס למצבים בהם ישנה תשתית היברידית)

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

הערה: חשבון בעל הרשאות מסוג Global Admin אינו יכול להיות חשבון מסוג Break Glass מפני שחשבון Global Admin צריך לקבל הקשחת גישה מירבית ובגלל שחשבון Break Glass צריך להיות חשבון עם הרשאות שאינם גבוהות מידי.
הערה: החשבון היחיד אשר מוגדר בקבוצת Global Admin הוא Tenant Admin ולא מעבר לכך!

למה דווקא עכשיו חשבון Break Glass? לאחרונה תשתית הזהויות של Microsoft חוותה Outage בגישה לשירות באמצעות MFA, תקלה אשר גרמה לארגונים רבים בעיות בגישה לממשקים השונים כולל אדמינים.
מכיוון שההמלצות הגורפות של Microsoft וספקי זהויות אחרים היא לבצע הקשחת גישה ואכיפה של אפשרויות MFA על חשבונות בעלי הרשאות וחשבונות אדמין מכל מקום, למעשה גרמה לבעיה אחרת וארגונים שהפעילו הקשחה גישה לשירותי ענן שונים כדוגמת MFA ואינם עבדו עם תהליך Privileged Access Management או ארגונים שאינם הפעילו תהליך Break Glass מצאו את עצמם בבעיה חמורה.

למרות ההמלצות השונות של הקשחת גישה, פרסמה Microsoft בסוף 2017 מאמר מסודר לגבי ניהול גישה במצבי חירום, מי שעבד עם ההמלצה לא חווה בעיה.
קישור למאמר Manage emergency-access administrative accounts in Azure AD.

המלצות להגדרת חשבון Break Glass

בכדי להגדיר חשבון מסוג Break Glass בשירות Office365 או Azure AD יש לפעול לפי הדגשים הבאים:

  • יצירת חשבון ענן בלבד עם דומיין מבוסס onmicrosoft.com
  • שמירת פרטי הזדהות (מחולקים למספר מקומות) בכספת מקומית ונגישה למורשים בלבד
  • חשבון שאינו מקבל הקשחת גישה כדוגמת MFA (ואפילו לא Conditional Access) ומצריך שם משתמש וסיסמה בלבד
  • חשבון שאינו מוגדר בקבוצת Global Admin (יכול להיות במצבים מסוימים בלבד)
  • אינו מוגדר עם אפשרות Self-service password reset
  • חשבון מתוחזק אחת לתקופה שלא עולה על 90 יום
  • ניתן להגדיר חשבון אשר מוגדר עם דלגציה מול הקבוצות הבאות: User administrator וכן Conditional Access Administrator

הרשאות המשתמש הם לטובת הפעלה וביטול של MFA ברמת Conditional Access ולא ניהול MFA עצמו.

המטרה העיקרית של חשבון Break Glass היא לאפשר גישה במצבי חירום כאשר חשבונות בעלי הרשאות ואדמינים אינם יכולים לגשת לממשיק הניהול בארגון, ולכן מומלץ גם במצבים שאין תהליך Privileged Access Management להגדיר חשבון Break Glass עם הרשאות נדרשות.
חשוב מאוד להדגיש כי חשבון Break Glass יכול להיות חשבון עם הרשאות ספציפיות או הרשאות גבוהות, תלוי מאוד באותם נסיבות שהארגון צריך גישה אל ממשקי ניהול ולפי תרחישים שונים.

You may also like...

2 Responses

  1. yaniv הגיב:

    מדריך מצוין ועזר לי בתקלה האחרונה

  1. 15/12/2018

    […] ניהול זהויות ותרחיש Break Glass […]

כתיבת תגובה

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