בפרויקטים שלנו, Conditional Access הוא כמעט תמיד הצעד הראשון בהקשחת סביבת Microsoft 365. וכשמתחילים לאכוף מדיניות, לחסום פלטפורמות לא מזוהות, לדרוש מכשיר תואם או MFA עמיד לפישינג לאדמינים, אנחנו מקיימים עם הלקוח פגישה ייעודית על סכנת הנעילה. במאמר הזה נסביר מה צריך להגדיר לפני שמתחילים, איך לנטר את חשבונות החירום, ואיך מטמיעים Conditional Access בהדרגה בלי להשבית את העבודה.
מה זה חשבון Break Glass ולמה צריך אותו
חשבון Break Glass, או בשמו הרשמי Emergency Access Account, הוא חשבון אדמין עם הרשאות מלאות שלא שייך לאף עובד ולא משמש לעבודה שוטפת. הוא קיים רק בשביל רגע אחד: כשאף אדמין אחר לא מצליח להתחבר. זה קורה יותר ממה שנדמה:
- טעות במדיניות Conditional Access: למשל מדיניות שחוסמת את כל המשתמשים, כולל האדמינים, או דורשת אמצעי אימות שעוד לא נרשם.
- תקלה בשירות האימות: תקלה ב-MFA של מיקרוסופט או אצל ספק הסלולר, שמונעת מהאדמינים לקבל הודעה או אישור.
- פדרציה שנפלה: ארגון שמתחבר דרך ADFS או ספק זהויות חיצוני, ושרת הפדרציה לא זמין.
- עזיבה או חשבון שנפרץ: האדמין האחרון עזב, או שהחשבון שלו ננעל בעקבות אירוע אבטחה.
בלי חשבון חירום, היציאה ממצב כזה עוברת דרך התמיכה של מיקרוסופט: תהליך ארוך שלא בשליטתכם, בזמן שהארגון לא יכול לנהל את הסביבה שלו.
איך מגדירים נכון
ההנחיות של מיקרוסופט לחשבונות חירום השתנו בשנים האחרונות. פעם ההמלצה הייתה חשבון עם סיסמה ארוכה, בלי MFA ומוחרג מכל המדיניות. היום MFA חובה בכניסה לפורטלי הניהול, Azure, Entra, Intune ו-Microsoft 365 admin center, לכל החשבונות, כולל חשבונות חירום, וגם החרגה מ-Conditional Access לא עוקפת את החובה הזו. לכן ההמלצה שונה:
| עיקרון | ההמלצה |
|---|---|
| כמות | לפחות שני חשבונות חירום, כדי שלא תהיה נקודת כשל אחת |
| סוג החשבון | חשבון ענן בלבד בדומיין onmicrosoft.com, לא מסונכרן מ-AD ולא תלוי בפדרציה |
| אימות | אימות ללא סיסמה ועמיד לפישינג: מפתח FIDO2 פיזי (המומלץ) או אימות מבוסס תעודה. שיטה שונה מזו של האדמינים הרגילים, ולא תלויה בטלפון של אף אחד |
| שמירה | מפתחות FIDO2 בכספות בשני מקומות נפרדים, עם נוהל ברור מי ניגש ומתי |
| Conditional Access | שני החשבונות בקבוצה ייעודית, והקבוצה מוחרגת מכל מדיניות שחוסמת או מגבילה התחברות, כדי שטעות במדיניות לא תנעל גם אותם |
| הרשאות | Global Administrator בהקצאה קבועה (Active) ב-PIM, לא Eligible, ובלי תפוגה או ניקוי אוטומטי |
| שימוש | רק בחירום. לא לעבודה שוטפת, לא לבדיקות ולא לחשבון שירות |
| בדיקה תקופתית | התחברות יזומה לפחות פעם ב-90 יום, ואחרי כל שינוי בצוות ה-IT, כדי לוודא שהחשבון והמפתח עובדים |
העיקרון שמאחורי כל השורות האלה אחד: חשבון החירום צריך לעבוד גם כשכל השאר לא עובד. לכן הוא לא יכול להיות תלוי באותו טלפון, באותה שיטת אימות או באותה מדיניות שעלולות להיכשל.
ניטור ואוטומציה על חשבונות החירום
חשבון עם הרשאות מלאות שמוחרג מהמדיניות הוא גם מטרה מושלמת לתוקף. לכן צריך לדעת מיד על כל שימוש בו, וגם לוודא שהוא באמת נשאר מוחרג.
הבעיה השנייה פחות מוכרת: כל אדמין שיוצר מדיניות Conditional Access חדשה צריך לזכור להחריג ממנה את קבוצת חשבונות החירום. מספיקה מדיניות אחת ששכחו בה את ההחרגה, וחשבון החירום כבר לא יציל אף אחד. לכן אנחנו מציעים ללקוחות אוטומציה קטנה שרצה בענן:
- בדיקת החרגות כל חצי שעה: האוטומציה עוברת על כל מדיניות ה-Conditional Access שחוסמת או מגבילה התחברות, ומוודאת שקבוצת חשבונות החירום מוחרגת מכולן. אם נוצרה מדיניות בלי החרגה, נשלחת התראה.
- התראה על כל התחברות: כל ניסיון התחברות לחשבון חירום, מוצלח או כושל, מייצר התראה במייל. בשגרה לא אמור להיות אף אחד.
- בדיקת חיים (Keepalive): כל 45 דקות האוטומציה מדווחת שהיא רצה, וכל כשל בהרצה מייצר התראה, כדי שלא נגלה ביום פקודה שהניטור עצמו הפסיק לעבוד.
העלות צנועה. לפי הניסיון שלנו: הקמה של 8–10 שעות עבודה, ועלות ענן של 5–15 דולר בחודש לפי שימוש. ארגונים עם Microsoft Sentinel יכולים לממש את חלק ההתראות גם שם, אבל בדיקת ההחרגות דורשת לוגיקה ייעודית.
הטמעת Conditional Access בלי להשבית את הארגון
חשבון חירום הוא רשת הביטחון. אבל הדרך הנכונה היא לא להגיע אליו בכלל, ולכן כל מדיניות עוברת אצלנו שלושה שלבים:
- Report-only. המדיניות רצה ומתועדת ביומני ההתחברות, אבל לא נאכפת. רואים בדיוק את מי היא הייתה חוסמת, ומטפלים בפערים לפני שמישהו נחסם באמת.
- אכיפה על קבוצה מצומצמת. מפעילים על קבוצת פיילוט של משתמשים או מכשירים שכבר מוכנים, ומרחיבים בהדרגה.
- אכיפה מלאה. רק אחרי שהפערים טופלו, עם החרגות מתועדות ומשימת מעקב לכל החרגה.
כך זה נראה אצל אחד הלקוחות שלנו, ארגון תעשייתי, באמצע התהליך:
| מדיניות | סטטוס | מה נדרש לפני שמתקדמים |
|---|---|---|
| חסימת פלטפורמות מכשיר לא מזוהות | פעילה, עם החרגה אחת | החשבון המוחרג משתמש ב-Legacy Authentication, וצריך להסדיר את ההתחברות שלו ולהסיר את ההחרגה |
| MFA לרישום אמצעי אימות | פעילה | משתמשים חדשים נרשמים עם Temporary Access Pass, אחרי הדרכה לצוות ה-IT |
| MFA עמיד לפישינג לאדמינים | Report-only | כל האדמינים צריכים להגדיר Passkey ב-Microsoft Authenticator ולבדוק התחברות |
| חסימה לפי סיכון משתמש | פעילה על קבוצת פיילוט | הרחבת הקבוצה יחד עם פיילוט איפוס סיסמה עצמאי (SSPR) |
| דרישת מכשיר תואם | Report-only | מחשבים רבים עוד לא Compliant, מטפלים בפערים לפי דוח ומפעילים בהדרגה |
| הגנת אפליקציות (MAM) | פעילה | איסוף משוב על חוויית המשתמש |
| MFA עמיד לפישינג לכל המשתמשים | Report-only | העברת משתמשים מ-SMS לאימות באפליקציה, ואחר כך ל-Passkey |
שני דברים בולטים בטבלה. ראשית, המדיניות הרגישות ביותר, אלה שעלולות לנעול אדמינים, נשארות ב-Report-only עד שכל האדמינים רשומים לאמצעי האימות החדש. שנית, כל החרגה מקבלת בעלים ומשימת מעקב, כדי שלא תהפוך לחור קבוע במדיניות. על המעבר מ-SMS ל-Passkeys כתבנו בהרחבה במדריך לפרישת SMS ושיחות קוליות ב-Entra.
בשורה התחתונה
לפני שמפעילים מדיניות Conditional Access אחת, צריכים להיות בטננט שני חשבונות חירום: ענן בלבד, עם מפתחות FIDO2 בכספות נפרדות, מוחרגים מכל מדיניות שחוסמת התחברות, ועם התראה על כל התחברות. ואחרי שהם קיימים, כל מדיניות חדשה מתחילה ב-Report-only, עוברת לקבוצת פיילוט, ורק אז נאכפת על כולם.
רוצים לדעת אם חשבונות החירום שלכם באמת יעבדו ביום פקודה? קבעו שיחה עם הצוות של OnCloud, ונבדוק את חשבונות החירום ואת מדיניות הגישה בטננט שלכם.
קביעת שיחה