Conditional Access Policy Not Applied: איך לאבחן ולתקן בעיות ב-Microsoft Entra

By Mirko Peters · 2026-04-23 · Updated 2026-07-28

מדיניות Conditional Access שלא הופעלה דורשת תרחיש עסקי ברור, גבולות אבטחה ונתונים מאומתים ובעלות אחראית. התחילו מהתוצאה הרצויה, בדקו את הקונפיגורציה ואת השפעת המדיניות על משתמשים מייצגים, תעדו את ההחלטה ואת תהליך התמיכה, ולאחר מכן סקרו את הגישה באופן קבוע ככל שהדרישות ויכולות Microsoft 365 משתנות…

Automatically translated with AI from the original post. Read the English original

מדיניות Conditional Access שלא הופעלה דורשת תרחיש עסקי ברור, גבולות אבטחה ונתונים מאומתים ובעלות אחראית. התחילו מהתוצאה הרצויה, בדקו את הקונפיגורציה ואת השפעת המדיניות על משתמשים מייצגים, תעדו את ההחלטה ואת תהליך התמיכה, ולאחר מכן סקרו את הגישה באופן קבוע ככל שהדרישות ויכולות Microsoft 365 משתנות.

Conditional Access policy not applied: רשימת בדיקה מעשית

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

השתמשו ב-Microsoft Learn לקבלת הנחיות עדכניות.

נבדק לאחרונה: יולי 2026.

Conditional Access הוא עמוד השדרה של הגנת הזהויות ב-Microsoft Entra (לשעבר Azure AD). אבל כשרואים ביומנים את הסטטוסים המטרידים “NotApplied”, המשמעות היא שבקרות הגישה לא מבצעות את תפקידן, והארגון שלכם עלול להיות פתוח לגורמים הלא נכונים. הבעיה הזו נסתרת בשקט, עד שביקורות ציות, טיפול באירועי אבטחה או משתמשים בלתי צפויים חושפים את החורים.

האתגר? לעיתים נדירות יש סיבה אחת בלבד לכך ש-Conditional Access policy לא הופעלה. יכול להיות שמדובר בהגדרה שהוחמצה, ב-service principal שחומק דרך הסדקים, או בפיזור מדיניות (policy sprawl) שמעכיר את התמונה. כש-Conditional Access לא עובד, האבחון הופך למסובך מהר. לכן חשוב מאוד להבין איך Microsoft Entra מעריך ומדלג על מדיניות. כך תוכלו לסגור את הפערים הבלתי נראים, להקל על כאבי הראש של המשתמשים ולהרגיע את צוות האבטחה.

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

הבנת הערכת Conditional Access ב-Azure ומדוע מדיניות מציגה NotApplied

Conditional Access ב-Microsoft Entra עשוי להיראות פשוט: מחילים כלל, מקבלים תוצאה. אבל מתחת לפני השטח הדברים מסתבכים מהר. לפני שאתם מנסים לתקן בעיית NotApplied, צריך להבין איך Entra עובר על כל מדיניות ברגע שמשתמש מנסה להתחבר. לא כל מדיניות תופעל או תידלג רק על סמך מה שבדקתם בפורטל הניהול.

כשמדיניות מסומנת כ-“NotApplied”, המשמעות היא ש-Entra בדק את ההתחברות מול המדיניות, אבל קבע שהכלל לא מתאים למצב. אולי המשתמש, המכשיר, היישום או הקשר ההתחברות פשוט לא תאמו את היקף המדיניות, או שכלל אחר בעל עדיפות גבוהה יותר כבר הגיע לתוצאה הנדרשת.

העניין נוגע לסדר ההערכה ולאופן שבו Entra מכריע אילו מדיניות גוברת כשיש חפיפה. יש גם החרגות של מדיניות, זרימות של service principal, מוזרויות של מיקומים מזוהים (named locations), וההתנהגות הייחודית של חלק משירותי Microsoft 365. מדיניות רבות מדולגות, לעיתים מסיבות שאינן ברורות, והתג “NotApplied” הוא הרמז היחיד לכך שמשהו לא תקין.

אם לא תחפרו לעומק בסיבות האלה ולא תזהו את “NotApplied” על מה שהוא, אתם מסתכנים באבטחה שחומקת דרך הסדקים או בתקלות התחברות למשתמשים לגיטימיים. כאן נכנסים יומני ההתחברות, שעוזרים להפריד בין מדיניות שהופעלה, מדיניות שדולגה ומדיניות שהתעלמו ממנה, ונותנים תמונה אמיתית של מה שקורה בפועל. להבנה מעמיקה יותר של Conditional Access וסיכון, פרק הפודקאסט הזה על פיזור מדיניות ומשילות מציג אסטרטגיות שנבדקו בשטח לארגונים בקנה מידה גדול.

כיצד יומני ההתחברות של Microsoft Entra מסייעים לזהות פערים ביישום מדיניות

יומני ההתחברות של Microsoft Entra הם הבלש המרכזי שלכם בפענוח תעלומות של Conditional Access. כל רשומה ביומן מפרטת אילו מדיניות הוערכו עבור ההתחברות, ותראו סטטוסים מפורשים כמו “Applied”, “NotApplied”, “Failure” או “Success”. “NotApplied” לא אומר ש-Entra התעלם מהמדיניות. הוא אומר שהתנאים לא התקיימו, או שמדיניות אחרת קיבלה עדיפות.

הציצו ביומני הכניסה (sign-in logs) בלשונית “Conditional Access”. כאן אפשר להצליב את ההקשר של המשתמש, המכשיר והאפליקציה כדי לגלות מדוע מדיניות לא הופעלה. שימו לב לסימנים כמו כניסות של service principal או זרימות app-only: לעיתים קרובות הן מופיעות כ־“NotApplied” משום ש־CA אינו מעבד טוקנים שאינם אינטראקטיביים. היכולת לקרוא את היומנים האלה חיונית לאיתור פערים ולשלילת תצורות שגויות. למידע נוסף על מדיניות בסיס ועל מעקב אחר בעיות אמון, ראו המדריך הזה על פערי אמון ב-Conditional Access.

התצורות השגויות הנפוצות ביותר של Conditional Access שמונעות אכיפת מדיניות

בואו נהיה כנים: Conditional Access הוא אחד מאותם כלים שטעות קטנה בהם עלולה להפוך לכאב ראש אבטחתי גדול. הגורם הנפוץ ביותר לסטטוס “NotApplied” הוא פשוט תצורה שגויה. החרגה שמוקמה במקום הלא נכון, סף סיכון מקל מדי, או פרוטוקולים מדור קודם שנשכחו יכולים להשאיר דלתות אבטחה פתוחות, בזמן שכולם חשבו שהן נעולות היטב.

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

יתרה מזאת, אימות מדור קודם פועל כמו סמטה אחורית שעוקפת את Conditional Access ואת MFA. זו פרצה שארגונים רבים שוכחים, עד שביקורת ציות מביאה את החדשות הרעות. מנהלים מיומנים שומרים על חדות על ידי בדיקה כפולה של עבודתם ומעקב אחר פרצות חדשות ככל ש-Microsoft 365 מתרחבת. אם תרצו לראות כיצד סחיפת תצורה עדינה יכולה לשנות אפילו את תוצאות הציות של Microsoft עצמה, הפודקאסט הזה על סחיפת ציות ב-Microsoft 365 הוא מאיר עיניים.

מלכודות בתנאי מיקום וסיכון במדיניות Conditional Access

• מיקומים בשם (Named Locations) שהוגדרו שגויות: אם לטווחי ה-IP של מיקומים בשם יש טעויות, כתובות מהימנות חסרות או רשימת מדינות לא שלמה, חלק מהכניסות עלולות לעקוף את המדיניות שלכם מבלי שתבחינו בכך.
• רמות סיכון לא מתאימות: אם תגדירו סף של משתמשים בסיכון או כניסות בסיכון גבוה מדי (או נמוך מדי), סיכונים אמיתיים עלולים לחמוק, או שמשתמשים ייחסמו בגלל אזעקות שווא.
• מיקומים שהושמטו או רחבים מדי: שכחה לכלול את כל טווחי ה-IP הנדרשים, אפליקציות ענן או השארת מדינות “מהימנות” ישנות מובילה לאכיפה לא אחידה.
• נקודות עיוורון במצב המכשיר: התעלמות ממצב הציות של המכשיר או מהצטרפות היברידית ל-Azure AD משאירה מחוץ לתמונה כניסות ממכשירים לא מנוהלים.

כדי להימנע מהטעויות האלה, ביקורות עקביות וממשל ברור, כפי שמוסבר במדריך הממשל הזה ל-Azure, עושים את כל ההבדל.

בקרות גישה וכללי הענקה שגורמים ל-Conditional Access להיכשל

1. בקרות הענקה מתנגשות (“דרוש הכול” מול “דרוש אחד”): הגדרת מדיניות שדורשת את כל בקרות ההענקה, כמו MFA יחד עם מכשיר תואם ואפליקציה מאושרת, יוצרת מצב שבו דרישה אחת שלא התקיימה גורמת ל-“NotApplied” או לחסימה לא מכוונת.
2. לוגיקת חסימת גישה לא ברורה: הפעלה בשוגג של בקרות “הענקה” ו“חסימה” באותה מדיניות עלולה לבטל זו את זו, והתוצאה היא אכיפה בלתי צפויה (או תוצאה של “NotApplied” אם תנאי החסימה לא הופעלו).
3. קבוצות משתמשים חופפות או מוחרגות: הכללת קבוצות רחבות במדיניות בעדיפות גבוהה עלולה לגבור על מדיניות ממוקדת יותר, ולגרום לה להופיע כ-“NotApplied” משום שהתנאים שלה אינם מופעלים לעולם.
4. מיקוד שגוי באפליקציות ענן: החלת מדיניות על אפליקציות ענן שגויות, או החסרת אפליקציה מרכזית, פירושה שההגבלות המתוכננות פשוט אינן מופעלות.

עקיפות של אימות מדור קודם ו-MFA שמשאירות פערים

• פרוטוקולים מדור קודם: פרוטוקולים ישנים כמו POP, IMAP ו-SMTP עוקפים את Conditional Access ואת MFA, ומתגנבים מתחת להגנות שלכם דרך Exchange Online ונקודות קצה קלאסיות אחרות.
• רישומי אפליקציות לא מנוהלים: אפליקציות שנרשמו לפני שאכיפת גישה מותנית נכנסה לתוקף (או שמשתמשות בזרימת client credentials) אינן כפופות לבדיקות המדיניות המודרניות, ולכן תוקפים או משתמשים לא מודעים יכולים לגשת למשאבים ללא אימות נוסף.
• החרגות MFA לחשבונות שירות: החרגות גורפות למערכות מדור קודם או לתיבות דואר משותפות מבטלות הגנות ליבה ויוצרות נקודות עיוורות שתוקפים אוהבים לנצל.
• פרצות בין אפליקציות: שילוב לקוי בין אפליקציות לקוח עלול לעקוף בקשות MFA גם במקומות שבהם אתם מצפים לראות אותן. למידע נוסף על סגירת פערי Zero Trust אלה, עיינו במדריך Zero Trust ב-Microsoft 365/Dynamics 365 הזה.

פתרון בעיות בגישה מותנית באפליקציות Microsoft 365, ב-B2B ובפלטפורמות מכשירים

האכיפה של גישה מותנית חזקה רק כמו החוליה החלשה ביותר שלה. ל-Microsoft 365 יש מאפייני שירות משלו, כניסות של אורחים ושותפים ב-B2B מתנהגות אחרת, והחלת מדיניות על מכשירים לא תמיד פועלת כפי שאתם מצפים. הניואנסים האלה יכולים להפיל גם מדיניות שתוכננה היטב ולהותיר אחריהם עקבות של "NotApplied".

חשבונות אורחים, במיוחד כאלה שנשכחו זמן רב לאחר פרויקט עם שותף, הם דוגמה מובהקת לכך. גבולות האמון ומחזור החיים שלהם שונים ממשתמשים פנימיים, ולכן מדיניות עלולה לפספס אותם או להיות מופעלת בצורה חלשה. להתנהגויות ספציפיות לשירות בפלטפורמות Microsoft 365, כגון Exchange Online או SharePoint, יש שכבת מורכבות נוספת, מהרשאות אפליקציה ועד פסקי זמן של סשנים.

ואז יש את צד המכשירים: האופן שבו המחשב של המשתמש מוצטרף, נרשם או מנוהל (למשל Hybrid Azure AD join, תאימות ב-Intune או פלטפורמות מכשירים ניידים) קובע אילו מדיניות תופעל ואילו תדלג. אם אתם רוצים לחקור לעומק את האכיפה של גישה מותנית בין סביבות, בנו רשימת בדיקה ייעודית לכל סביבה שתאפשר לזהות פערים בזמן אמת, לפני שהם יגרמו לכם לשיחת תמיכה בשעת לילה מאוחרת. למידע נוסף על מלכודות ממשל הקשורות למשתמשי אורח ולממשל Teams, עיינו באסטרטגיות לניהול סיכוני חשבונות אורח ושיפורים בממשל Teams לתמונה רחבה יותר של הסיכונים המתפתחים.

תכונות שירות של Microsoft 365 המשפיעות על גישה מותנית

לא כל עומס עבודה של Microsoft 365 פועל לפי אותם כללים בכל הנוגע לגישה מותנית. לשירותים כמו Exchange Online, SharePoint ו-Teams יש ממשקי API, נקודות קצה ולוגיקה לניהול סשנים ייחודיים. חלק מהפרוטוקולים או הגישה מאפליקציות לנייד לא תמיד מכבדים את הגדרות ה-CA העדכניות ביותר, במיוחד כאשר מעורבות נקודות קצה מדור קודם או אפליקציות OAuth שקיבלו הסכמה.

ייתכן שתראו מדיניות כ-"NotApplied" משום שהאפליקציה משתמשת בשיטות אימות שונות, כמו Exchange Online PowerShell או SharePoint Online דרך זרימה מדור קודם. מצב זה עלול לפתוח שרשראות תקיפה באמצעות phishing להסכמה או גניבת טוקנים, ומדגיש את הצורך בתיקון ממוקד בכל עומס עבודה. למידע נוסף על וקטורי התקיפה ברמת השירות והדרכים להגנה עליהם, עיינו בתיקון שרשרת התקיפה של Microsoft 365.

גישה מותנית לשיתוף פעולה B2B ולמשתמשי אורח

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

אתגרי Windows וציות מכשירים בגישה מותנית

• החרגות לפי פלטפורמת מכשיר: מדיניות שמוגדרת עבור Windows, iOS או Android עלולה לדלג על משתמשים לגמרי אם המכשיר אינו מזוהה או אינו עומד בדרישות הציות.
• מלכודות בהצטרפות היברידית ל-Azure AD: מכשירים שלא הצטרפו כהלכה (היברידית או בכל דרך אחרת) לא יעברו את בדיקות המכשיר של מדיניות גישה מותנית, וכך ייחסם האכיפה של המדיניות.
• פערים באינטגרציה של Intune: מדיניות ציות שמבוססת על Intune עשויה לקחת זמן להירשם, וכך ייווצר פרק זמן שבו נראה שהחלת המדיניות אינה עקבית.
• מכשירים לא תואמים או שלא אומתו: כניסות מכשירים שנפרצו (jailbroken), לא מעודכנים או לא מנוהלים בדרך כלל אינן מפעילות מדיניות מוגנת מכשיר. הנחיות נוספות לשילוב של ציות והגנה מפני איומים זמינות בסקירה זו של Microsoft 365 Defender ו-Purview.

ריסון התפשטות המדיניות והחפיפות שגורמות למדיניות גישה מותנית בלתי צפויה

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

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

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

ניהול תלויות שירותים ומניעת התפשטות מדיניות

• ביקורת מדיניות קיימת: בצעו מלאי ותעדו באופן קבוע את כל מדיניות CA הפעילה, ושימו לב לחפיפות מיותרות או לכללים מיושנים.
• מיפוי שירותים מקושרים: זהו תלויות CA לאורך Azure, Microsoft 365 ואפליקציות של צד שלישי, כדי לאתר פערי אכיפה שנוצרים עם אינטגרציות חדשות.
• איחוד וצמצום: אחדו מדיניות דומה והסירו מדיניות ישנה או בלתי בשימוש, תוך התמקדות בכללים רחבים ומתועדים היטב עם החרגות ממוקדות.
• בדיקת סיכוני AI ואוטומציה: אל תשכחו מתהליכי רקע. סוכני AI ואוטומציה צריכים בקרות משלהם עם היקף מוגדר כדי לחסום סיכוני Shadow IT, כפי שמוסבר כאן: איומי Shadow IT של סוכני AI.

בדיקה בטוחה של השפעת המדיניות באמצעות תוצאות "בחירת הכול" ודיווח

1. הפעילו תחילה מצב דוח בלבד: לפני הפריסה, השתמשו במצב דוח בלבד כדי לדמות את השפעת המדיניות ללא חסימת משתמשים לגיטימיים. נתחו את ההשפעה באמצעות לוחות הדיווח המובנים.
2. השתמשו בזהירות ב"בחירת הכול" בתוצאות: הפעילו את כל פעולות האכיפה בסביבת בדיקה בטוחה כדי לגלות תוצאות לא צפויות או החרגות לא מתוכננות לפני ההפעלה המלאה.
3. תעדו משתמשים ואפליקציות מושפעים: שמרו תיעוד של כל משתמש, קבוצה ואפליקציה שהושפעו מהשינויים, כדי שתוכלו לתקשר עם בעלי העניין ולחזור אחורה אם דברים מתדרדרים.
4. אספו משוב ממשתמשים ומהמערכת: עודדו משתמשים לדווח על תקלות מיד, ובדקו ביומני השגיאות של המערכת חסימות שנגרמו על ידי המדיניות.
5. הסתמכו על יומני ביקורת לתגובה לאירועים: השתמשו ב-Microsoft Purview Audit וביומני הדייר כדי לעקוב אחר פעילות משתמשים ולאמת את תוצאות המדיניות. להנחיות ביקורת, ראו את המדריך המעמיק ל-Purview Audit.

מה לעשות במקרה של נעילה או כאשר מדיניות גישה מותנית אינה מיושמת

כל מנהל Conditional Access מכיר את הסיוט: פורסים מדיניות חדשה, ולפתע אתם – או כל הצוות שלכם – נעולים מחוץ לדייר, או שהמדיניות שחשבתם שתציל את המצב פשוט לא עובדת. שיחות הסלמה מצטברות, ומתברר שאתם צריכים אסטרטגיית שחזור איתנה רק כדי לשמור על רציפות העסק.

החדשות הטובות? יש נוהל מוכח להשבת הגישה מהר – בלי להחמיר את המצב. כדאי שיהיו מוכנים חשבונות break-glass, ושתהיינה לכם טקטיקות של חזרה לגרסה קודמת והחרגה. במידת הצורך, הסלימו לתמיכה של Microsoft או לצוות האבטחה שלכם.

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

שחזור שלב אחר שלב כאשר Conditional Access נכשל

1. השתמשו בחשבון Break-Glass: שמרו לפחות חשבון חירום אחד עם הרשאות Global Administrator, שאליו לא מוחלות מדיניות Conditional Access. התחברו באמצעותו בכל עת כדי לחזור לגישה.
2. החילו מדיניות החרגה זמנית: אם נעלתם את עצמכם, צרו או הפעילו מדיניות החרגה לחשבון או לקבוצה המושפעים – כך תוכלו לחזור לגישה רגילה ולתקן את הבעיה המקורית.
3. הסלימו לעקיפת מנהל: אם צעדי הקו הראשון לא עובדים, פנו לתמיכה של Microsoft או לצוות האבטחה שלכם לקבלת התערבות ישירה או שחרור הדייר.
4. בטלו שינויים אחרונים במדיניות: החזירו כללי Conditional Access חדשים או שעודכנו לאחרונה לתצורה התקינה האחרונה הידועה, ובדקו ביומני הכניסה שהתיקון אכן פועל.

צעדים הבאים וסקירת מדיניות אפקטיבית לאחר זיהוי בעיות של מדיניות שלא הוחלה

• תעדו את הלקחים: רשמו בדיוק מה השתבש, מה עבד כתיקון, והיכן נדרשות בקרות או ביקורות עתידיות.
• בדקו במצב דוח בלבד: לפני שמפעילים מחדש מדיניות, השתמשו במצב report-only של Entra כדי לוודא שאתם מזהים בעיות בלי לגרום להשבתות חדשות.
• אספו והחילו משוב: בקשו משוב ממשתמשים מושפעים ומיומני המערכת, והשתמשו בתובנות שלהם כדי לסגור פערים שנותרו.
• עדכנו את בעלי העניין: עדכנו את כל הצוותים המושפעים, הנהלת IT, שותפים חיצוניים ומשתמשים לגבי התקלה, הפתרון ותוכניות המניעה ארוכות הטווח.
• התחייבו לממשל שוטף: תזמנו סקירות, דיווח ועדכונים שוטפים של מדיניות Conditional Access שלכם – כי ממשל טוב, כפי שמזכיר הפודקאסט על אשליית הממשל, הוא תהליך מתמשך ולא תרגיל של "הגדירו ושכחו".

🎧 כדאי גם להאזין

• ממשל זהויות ב-Microsoft Entra

  למדו על בקרות גישה ומחזור חיים.

• Microsoft Purview – בפשטות

  גלו הקשר של הגנה וציות.

• מודל התפעול לממשל של Microsoft 365

  הבינו בעלות בת-קיימא ותהליכי קבלת החלטות.