אבטחת Microsoft 365 כראוי: Conditional Access, חריגי MFA וחשבונות Break-Glass בשגרה

מי שרוצה לאבטח נכון את Microsoft 365 לא יכול לעבור על פני Conditional Access (מדיניות גישה מותנית ב-Entra ID, לשעבר Azure AD) ואימות מרובה-גורמים (MFA, כלומר התחברות עם לפחות שני גורמים). ברבות מהחברות MFA וכללי Conditional Access ראשוניים מופעלים במהירות – ואז העבודה מתחילה באמת: יש לנמק חריגים, לארגן גישות חירום באופן מסודר ולעצב תהליכי תפעול כך שהאבטחה לא תהפוך לגל התמיכה.

בפרקטיקה כישלון של „אבטחת M365“ נדיר שיהיה קשור לטכנולוגיה עצמה, והוא נובע בדרך־כלל מנושאי היום־יום: חשבונות שירות לממשקים, פרוטוקולים ישנים (Legacy), שירות שטח ללא רשת סלולרית אמינה, אדמינים עם זכויות רחבות מדי, או אירוע שבו בדיוק אמצעי ההגנה חוסם את הגישה של ה-IT. מאמר זה ממפה כיצד Conditional Access, חריגי MFA וחשבונות Break-Glass פועלים יחד — וכיצד להפעיל את כל המערכת כך שתישאר אמינה גם אחרי ה-Go-live.

מדוע Conditional Access הוא המנוף — ולמה MFA לבדו אינו מספיק

MFA מפחית משמעותית את הסיכון של סיסמאות שנגנבו, אך MFA איננו מגדיר מושג גישה שלם. Conditional Access (CA) מקבל החלטות בהתאם להקשר, תחת אילו תנאים גישה מותרת: למשל רק ממכשירים מנוהלים, רק ממדינות מסוימות, רק בעקבות הערכת סיכון או רק דרך אפליקציות לקוח מסוימות. זהו הצעד המכריע לקראת Zero Trust (מודל אבטחה שבו לא נותנים אמון בגישה כברירת מחדל, אלא בודקים אותה באופן מתמשך).

סיבות טיפוסיות לכך ש-MFA לבדו לא מספיק ב-Microsoft 365:

• טוקן במקום סיסמה: אימות מודרני מתבסס על טוקנים (כרטיסי גישה מוגבלים בזמן). טוקן שנגנב יכול לעקוף MFA אם ה-CA אינו דורש תנאים נוספים (למשל מצב המכשיר או בקרה על המושב).
• סיכון אדמין: חשבונות ניהוליים הם יעד אטרקטיבי במיוחד. בלי כללי CA לכניסות של אדמינים (למשל רק מתחנות עבודה של אדמין או רק עם MFA עמיד נגד פישינג) נשארת שטח התקיפה הגדול ביותר חשוף.
• „מותר“ רחב מדי: אם CA אינו מבדיל בין אפליקציות, קטגוריות נתונים וסוגי גישה, האבטחה תהפוך במהירות או לרפה מדי או למחמירה מדי — בשני המקרים ייווצרו בעיות.

העיקר התפעולי הוא לכן: CA כשכבת מדיניות, MFA כחלק ממנה, בנוסף לניהול חריגים מסודר ולדרכי חירום מהימנות.

מבט על הארכיטקטורה: מה Conditional Access ב-Entra ID שולט בפועל

למובילי IT ותפעול חשוב שלא להבין את CA כ“מדיניות בודדת“, אלא כשרשרת החלטות. Entra ID מעריך אותות בכל כניסה ומפעיל מדיניות. אותות חשובים הם:

• זהות: משתמש, קבוצות, תפקידים (למשל תפקידים מועדפים כמו Global Administrator).
• משאב-יעד: Cloud-App (Exchange Online, SharePoint/OneDrive, Teams, וגם צד שלישי דרך Enterprise App).
• סוג לקוח: דפדפן, לקוחות מודרניים, אפליקציות מובייל, וכן „Legacy Authentication“ (פרוטוקולים ישנים ללא טוקנים מודרניים, למשל וריאציות ישנות של IMAP/POP/SMTP-auth).
• מצב מכשיר: „Compliant“ או „hybrid joined“ (מכשיר מנוהל, בדרך כלל דרך Intune או חיבור לדומיין עם סטטוס מכשיר).
• רשת/מיקום: Named Locations (טווחי IP מוגדרים), מדינות/אזורי גיאוגרפיה, אינדיקטורי סיכון.
• תנאי מושב: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (הערכה מחדש מתמשכת בעת אירועי סיכון).

מנקודת מבט תפעולית, איכות תצורת ה‑CA שלכם תלויה במידה רבה בכך שהאותות הללו אמינים. Named Location טוב רק כפי שהיגיינת כתובות ה‑IP שלכם. „Compliant“ טוב רק כפי שניהול ההתקנים שלכם והגדרת ה‑Compliance מדויקות. והערכת הסיכון שימושית רק אם אתם מטפלים בפועל ב‑Events הנובעים ממנה.

Microsoft 365 לאבטחה נכונה עם Conditional Access: סט מדיניות פרקטי

במקום „חוק גדול“ אחד, עובד בשגרה בצורה יעילה יותר סט קטן של מדיניותים ברורים ומובחנים. זה מצמצם תופעות לוואי ומקל על איתור תקלות ב‑incident. תבנית בסיסית מוכחת כוללת:

1) Baseline לכל המשתמשים: فرضת MFA, חסימת Legacy

לבק_accounts רגילים, ה‑baseline הוא: דרישת MFA וחסימת Legacy Authentication. כאן „Legacy“ אינו רק „מיושן“, אלא בעייתי טכנית: פרוטוקולים אלה לרוב אינם תומכים ב‑MFA מודרני ולכן מהווים נקודת כניסה קלאסית ל‑password spraying.

חשוב: אל תחסמו Legacy באופן פתאומי, אלא תכננו תקופת מעבר עם מדידה. בדקו ב‑Sign‑in Logs אילו לקוחות עדיין משתמשים ב‑Legacy. בארגונים זה מתקשר לעתים למדפסות מולטיפונקציונליות, Scan‑to‑Mail או לקוחות דוא“ל ישנים בסביבות מיוחדות.

2) Admin‑Policy: דרישה נוקשה משמעותית מה‑Baseline

לתפקידים בעלי הרשאות צריך להיות מדיניות נפרדת: גישה רק ממכשירי מנהל מוגדרים (למשל „compliant“ וייתכן אסטרטגיית Admin‑Workstation נפרדת), MFA ברמת בטיחות גבוהה (עמידה בפני phishing, למשל FIDO2/Passkey או מבוססת תעודה), וכדאי להגביל ככל האפשר מדינות/מיקומים בסיכון. גם אם לא כל ארגון מיישם מיד ארכיטקטורת Privileged‑Access (PAM, כלומר ניהול גישה מועדפת) מלאה, ההבחנה הזו תורמת מיד: חשבון מנהל מופקע הוא טווח נזק שונה מחשבון משתמש מופקע.

3) Policy לשיתוף חיצוני ואורחים

גישה של אורחים (B2B Collaboration) יוצרת לעתים מסלולי נתונים בלתי צפויים: אורחים מורידים קבצים מ‑SharePoint, עובדים ב‑Teams או ניגשים לפורטלי פרויקטים. הגדירו במכוון אם אורחים יורשו רק עם MFA, האם אפליקציות מסוימות מוקטנות ומה אורך התנאים של Sessions. לעבודה פרויקטאלית, משך Session קצר יותר הוא לעתים רצוי להפחתת הסיכון של „כניסות שנשכחו“.

4) Policy למסלולי נתונים רגישים: לאבטח מכשיר או ישיבה

בשגרה יש דרישות הגנה שונות: נציג מכירות ייתכן ויכול לקרוא דוא“ל מכל מכשיר, אך לא להוריד כמות גדולה של נתונים מ‑SharePoint ללא מכשיר מנוהל. הבדלים כאלה לא ממומשים באמצעות כללי „מאפשר/חוסם“ גורפים, אלא באמצעות קומבינציות CA: „גישה מותקנת אם המכשיר compliant“ או „גישה רק דרך דפדפן עם Session מוגבל“. זה פחות קיצוני מחסימה מלאה — ועדיין אפקטיבי.

חריגי MFA: מתי הם ריאליסטיים — וכיצד לשלוט בהם

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

חשוב להבחין: חריג MFA הוא נדיר שיהיה „MFA כבוי“, ולעתים קרובות מדובר ב“MFA באופן שונה“ או „גישה רק בתנאים אחרים“. קטגוריות חריגים טיפוסיות:

Ausnahmefall 1: Nicht‑interaktive Zugriffe und Schnittstellen

רבות מהפתרונות התוכנתיים המקורבים לתהליכים משלבות שירותי M365: משלוח דוא“ל, גישה ליומן, אחסון קבצים ב‑SharePoint, התראות Teams או גישות ל‑Graph API. אינטגרציות כאלה אינן אמורות לפעול באמצעות חשבונות משתמש עם MFA מושבת. עדיף גישה טכנית דרך App-Registrierungen (יישום ב‑Entra ID) עם הרשאות ברורות ומחזור חיי Secret/תעודה. זו אינה „חריגת MFA“, אלא שיטת אימות שונה שניתן לבצע בה אודיט טוב יותר.

השלכות תפעוליות: יש לסובב Secrets, תעודות פוקעות, והרשאות צריכות להיקח תעודה מחדש. כאשר אתם מתכננים אינטגרציות, הגדירו Ownership (מי מחדש תעודות/Secrets) ו‑Monitoring (למשל התרעות לפני פקיעה). אחרת מה שנראה כאימות אפליקציה „בטוח“ יהפוך לכשל בלתי מתוכנן.

Ausnahmefall 2: Geräte ohne modernen Login (z. B. Scanner, Drucker, Raum-Systeme)

כאן עולות הדיונים הקלאסיים לגבי SMTP‑Relay, Scan‑to‑Mail או תיבות דואר לחדרים. הפתרון השגוי כמעט תמיד הוא „חשבון משתמש ללא MFA“. עדיפים מסלולים טכניים שאינם תלויים בהזדהות אינטראקטיבית: Mail‑Relay מרכזי עם הגבלת IP, גישות מבוססות תעודה או Connector, או תיבות מערכת נפרדות עם הרשאות מצומצמות. ההכרעה הקריטית היא: ההתקן עצמו אינו יכול לנהוג ב‑MFA, לכן יש לאבטח את העיצוב בשכבת ההעברה ובנתיב הרשת.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

עובדי שטח, ייצור או תפעול במשמרות נתקלים במצבים ללא קליטת טלפון או ללא מכשירים ניידים פרטיים. כאן כדאי לשקול מוקדם שיטות MFA אלטרנטיביות: טוקנים חומרתיים, מפתחות אבטחה FIDO2, או Windows Hello for Business (התחברות הקשורה למכשיר). „הפסקת MFA לזמן קצר“ מפתה אופרטיבית, אך קנה המידה שלה גרוע וקשה מאוד לאודיטציה.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

כמה מערכות ישנות משגרות עבודות „כמשתמש“, למשל להעלאת קבצים ל‑SharePoint או ליצירת דוחות. מבחינה עכשווית זה מסוכן כי מערבב תפקידים וזכויות גישה. אם החלפה לא אפשרית מיידית, עבדו בשלבים ביניים: חשבונות שירות מוגבלים, Named Locations ברורים, מדיניות סיסמאות/Secrets חזקה ותיעוד עקבי. ותכננו: בצעו את המיגרציה ל‑App‑Identitäten כחבילת עבודה נפרדת, לא כ“מאוחר יותר“.

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

חריגות בתפעול מקובלות רק אם יש להן מחזור חיים. נהוגות שיטות קלות משקל שמקטינות ביורוקרטיה אך נשארות ניתנות לאודיט:

1. נימוק במשפט אחד: איזו פונקציית עסק/תפעול תלויה בכך (למשל „Scan‑to‑Mail למיקום X“)?
2. מיון טכני: איזו אפליקציה/אילו פרוטוקולים, אילו חשבונות, אילו מסלולי נתונים?
3. בקרות מפצות: מה מגביל את הסיכון (הגבלת IP, זכויות מינימליות נחוצות, ניטור)?
4. תאריך פקיעה: לכל חריגה מוקצה תאריך סקירה. ללא סקירה היא תוסר או תאושר מחדש.
5. Owner: מי האחראי כאשר משהו תקוע או כאשר החריגה פגה?

כך חריגות אינן „טובות“, אך הן הופכות לניתנות לשליטה. וזה בדיוק ההבדל היומיומי בין בסיס אבטחה איתן ל‑M365 לבין חוסר סדר במדיניות.

Break-Glass-Accounts: Notfallzugang ohne Sicherheitsloch

חשבונות Break-Glass הם חשבונות חירום לגישה ל-Tenant, כאשר גישות מנהל רגילות אינן פועלות – למשל בגלל תצורה שגויה ב-Conditional Access, כשל של ספק MFA או אירוע זהות. המטרה ברורה, אך היישום טומן מלכודות אופייניות: חשבון Break-Glass שלא נבדק אף פעם לא יעזור במקרה חירום. חשבון Break-Glass שנגיש מדי בשגרה מהווה יעד אטרקטיבי לתקיפה.

מה שלא נחשב ל-Break-Glass

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

עקרונות יסוד ל-Break-Glass בתפעול

הגדרה פרקטית מתמקדת בשלושה יעדים: נגיש במקרה חירום, קשה לתקיפה בשגרה, וניתן למעקב באופן ברור.

• לפחות שני חשבונות: רדונדנציה נגד נעילה, שגיאות משתמש או פרטי גישה שנפרצו.
• מאובטח בחוזקה: סיסמאות ארוכות ואקראיות; אין הפניית דואר אלקטרוני; אין שימוש לאפליקציות/אינטגרציות.
• מושמט במכוון מ-CA — אך בצורה מצומצמת: נהוג ליצור חריגה ממדיניות CA מסוימת כדי שלא להיחסם במקרה חירום על ידי כללים פנימיים. במקביל חייבים לפעול מנגנוני אבטחה משלימים: התראות בעת שימוש, הקצאת תפקידים מצומצמת, ואחסון נפרד של פרטי הגישה.
• תיעוד והתראות: כל כניסה חייבת להפעיל אות מיידי (SIEM/SOC או לפחות התראת דואר אלקטרוני/Teams לתיבת אירועים). השימוש ב-Break-Glass הוא בהגדרה אירוע אבטחה.

נקודה מרכזית: קבלו החלטה מודעת האם להפעיל Break-Glass עם או בלי MFA. ארגונים רבים משאירים אותו ללא MFA כדי להישאר פעילים במקרה של כשל MFA. אז הבקרות המפצות חייבות להיות מוגדרות בקפדנות (אחסון, נגישות לסיסמה, התראות, החלפה תקופתית). כחלופה ניתן לצייד את ה-Break-Glass ב-MFA מבוסס חומרה (למשל FIDO2) שאינו תלוי בתקשורת סלולארית. החשוב הוא לא אידאולוגיה „נכונה“, אלא מסלול חירום שעובד בפועל בהקשר שלכם.

מציאות פריסת הפתרון: כך תמנעו נעילות ומעמסי תמיכה

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

שלב 1: יצירת נראות (לפני שתחסמו)

השתמשו ביומני Sign-in ובאנליזות כדי לגלות: אילו אפליקציות נמצאות בשימוש? אילו קליינטים הם „Legacy“? אילו מיקומים/טווחי IP אמיתיים? אילו משתמשים חווים כמות יוצאת דופן של בעיות כניסה? בלי נתונים אלה כל מדיניות היא פעולה בעיניים עצומות.

שלב 2: קבוצות פיילוט עם מקרי קצה אמיתיים

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

שלב 3: קביעת Playbooks ל-Helpdesk

כאשר חובת MFA נכנסת לתוקף, כמות הכרטיסים עולה: החלפת מכשירים, טלפונים שאבדו, עובדים חדשים, חשבון חסום לאחר יותר מדי ניסיונות. הגדירו מה ה-First-Level מורשה לפתור (למשל איפוס MFA לאחר אימות זהות) ומתי יש להסלים. בלי תסריטי פעולה ברורים הכל מייד מוסט למעלה — והמנהלים הופכים לצוואר בקבוק.

שלב 4: עבודות המשך טכניות כ-Backlog נפרד

CA עושה חי בחשבון את חובות הטכניות החבויות: Mailclients מיושנים, סורקים שלא תועדו, סקריפטים עם סיסמה ב-Task Scheduler, או אינטגרציות שעדיין משתמשות ב-Basic Auth. תכננו את עבודות ההמשך הללו כחבילות עבודה גלויות. אחרת הן יישארו כ“חריגות קבועות“.

דפוסי תקלות אופייניים בתפעול — ואיך לסווגם מהר יותר

ביומיום שוות השערות מהירות. כמה דפוסים חוזרים על עצמם:

„פתאום Outlook כבר לא עובד“

סיבות נפוצות: Legacy-Client, פרופיל ישן, או חסימה ב-CA עקב סטטוס מכשיר חסר. בדקו: סוג ה-Client ביומן ה-Sign-in Log, ה-CA-Policy שהוטלה, והאם המכשיר מסומן כ-compliant. התיקון התפעולי בדרך כלל אינו „כיבוי Policy“, אלא „עדכון ה-client“ או „ליישם ניהול מכשירים תקין“.

„שירות XY כבר לא יכול לשלוח אימיילים“

לעיתים מדובר במעבר בשיטת אימות SMTP, שינוי במדיניות Relay או כלל CA חדש שתופס בטעות גם חשבונות טכניים. כאן עוזר החלטת ארכיטקטורה ברורה: שליחה דרך Relay/Connector במקום כניסת משתמש, עם הגבלת IP ורישום (נכטיביליות בתוך ה-Incident).

„מנהל לא נכנס יותר ל-Tenant“

זה הרגע שעבורו Break-Glass נועד. אם גם גישת ה-Break-Glass לא עובדת, בדרך כלל חסר מסלול חירום שנבדק או שהחריג נבנה בצורה שגויה. לכן: תרגלו שימוש באופן קבוע (עם תיעוד מי מבצע בדיקות ומתי, ואיך נראה האזעקה).

„יותר מדי חריגות — אף אחד לא מבין את המצב“

זה בעיית Governance. קונסולידרו Policies, הגדירו טקס בדיקה (למשל חצי שעה בחודש), והסירו חריגות שאין להן Owner או מטרה ברורה. טכנית זה לא נוצץ, אבל זו ההבדל בין אבטחה שניתן לשלוט בה לבין זכויות מיוחדות שצמחו היסטורית.

Monitoring ויכולת Nachvollziehbarkeit: מה שאתם באמת צריכים

CA ו-MFA מייצרים הרבה אירועים. אם אתם אוספים הכל — טובעים; אם לא מנתחים דבר — תגלו בעיות מאוחר מדי. מעשי ושימושי הוא עבודה בשלוש שכבות:

• התרעה על אירועים קשים: Break-Glass-Login, Admin-Login ממדינות לא שגרתיות, Block-Events על אפליקציות קריטיות.
• בדיקות תקופתיות: סיבות חוסם מובילות, משתמשים מובילים עם בעיות MFA, ניסיונות Legacy-Auth, אפליקציות חדשות/Enterprise Apps.
• נתיב ביקורת לחריגות: מי אישר איזו חריגה, עד מתי היא תקפה, ומתי היא נבדקה?

אם כבר יש לכם תהליכי רישום מרכזיים ותהליכי Incident (SIEM, Ticketing, Change-Management), טמיעו שם שינויים ב-CA. Conditional Access אינה „הגדרה קטנה“, אלא שכבת גישה קריטית לייצור.

מאמץ ואחריות: מי צריך לספק מה?

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

• Identity-Team / Entra Admins: עיצוב מדיניות, מודל תפקידים, Break-Glass, רישום App-Registrierungen.
• ניהול לקוח (למשל Intune): הגדרת תאימות, מצב המכשיר, פריסת Authenticator/Passkeys, מחזור חיי המכשיר.
• רשת: טווחי IP עבור Named Locations, חריגים ל-Proxy/TLS-Inspection, שינויי מיקום.
• בעלי שירות של יישומי עסק: מסלולי אינטגרציה (Graph/SMTP/SharePoint), המרה מ-Legacy-Auth, סיבוב סודות (Secret-Rotation).
• Helpdesk: תהליכים סטנדרטיים לאיפוס MFA, החלפת מכשירים, Onboarding/Offboarding.

ההחלטה הניהולית החשובה ביותר לעיתים קרובות אינה „MFA כן/לא“, אלא: האם יש לנו זמן ומשאבים לעבודות ההשלמה (פירוק רכיבי Legacy, מודרניזציה של אינטגרציות, ייצוב ניהול מכשירים)? בלי עבודה זו הרווח הביטחוני יישאר מתחת לציפיות — או שהתפעול יהפוך לכבד מדי.

מסקנה: אבטחה מתחזקת כאשר מצב חירום וחריגות הם חלק מהמערכת

לאבטח נכון את Microsoft 365 פירושו להפעיל את Conditional Access כשכבת בקרה מרכזית — לא כהגדרה חד-פעמית. MFA היא חובה, אך איכות התפעול האמיתית נוצרת באמצעות חריגים מסודרים (עם תאריך תפוגה, Owner ובקרות מפצות) ובאמצעות Break-Glass-Accounts הנבדקים, נמצאים במעקב ומשובצים ארגונית. מי שחושב את שלושת האלמנטים האלה יחד, מצמצם סיכוני חשבונות, מקבל יכולת ביקורת ללא עומס מיותר ומונע שתקנות אבטחה יהפכו ליריב בעת תקרית.

לשוחח על פרויקט או יוזמת מודרניזציה עם Net-Base.