גישה מותנית למנהלים

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

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

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

Cover: Fix Microsoft Entra ID Conditional Access and Identity Debt

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

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

הבנת ההשפעה על האבטחה והדרישות של MFA בגישה מותנית עבור מנהלים

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

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

אבל לפני שמטמיעים משהו, יש כמה דברים חיוניים. תצטרכו את Microsoft Entra ID (השם הקודם היה Azure AD), שכן הגישה המותנית מובנית בפלטפורמה הזו. חשבונות המנהל צריכים להיות מוגדרים בבירור בתוך הדייר שלכם: חשבו מי מחזיק באיזו רמת הרשאה, החל ממנהל גלובלי ועד מי שמנהל את Teams או SharePoint. גם הרישוי המתאים לתכונות הגישה המותנית, בדרך כלל Azure AD Premium P1 או P2, הכרחי.

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

הפעלת MFA בגישה מותנית לאבטחת חשבונות מנהל

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

ההגדרה הזו אינה מסתכמת בהתחברות אחת. המדיניות שתבנו חלה על Microsoft 365, על שירותי Azure ועל כל יישומי הענן המחוברים למערך הניהול שלכם. כשמשלבים גישה מותנית עם MFA, מקבלים שליטה מדויקת. ניתן לדרוש הוכחת זהות נוספת כאשר הסיכון גבוה (למשל מכשירים לא מוכרים או מיקומים חריגים), ובעיקר, ניתן להתאים את הדרישות לתפקידים או ליישומים שונים.

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

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

איך ליישם Conditional Access MFA עבור מנהלי מערכת

היכנסו ל-Azure Portal
התחילו בכניסה אל portal.azure.com עם חשבון בעל הרשאות ניהול מתאימות. כך תקבלו גישה ל-Conditional Access תחת Microsoft Entra ID (שנקרא בעבר Azure AD).
נווטו אל מדיניות Conditional Access
עברו אל "Microsoft Entra ID", ואז בחרו "Security" ← "Conditional Access". זהו המקום המרכזי לצפייה בכל המדיניות, יצירתה וניהולה. אם זה נראה מורכב בהתחלה, זכרו שאתם לא לבד; הממשק נבנה לכוונון מדויק בקנה מידה גדול.
צרו מדיניות חדשה
לחצו על "New policy" ותנו לה שם בעל משמעות, למשל "Admin MFA Enforcement". השם חשוב, כי בעתיד תרצו לדעת בדיוק אילו משאבים כל מדיניות מכוונת אליהם.
הגדירו את תפקידי המנהלים שהמדיניות תחול עליהם
תחת "Users or workload identities", בחרו "Select users and groups". בחרו "Directory roles", ואז בחרו קבוצות מנהלים מורשות כמו Global Administrator, Security Administrator, Exchange Administrator וכדומה. היו יסודיים אך זהירים, ואל תכללו עדיין את חשבונות ה-break-glass לשעת חירום.
בחרו אפליקציות ענן ופעולות
עברו אל "Cloud apps or actions" ובחרו את פורטלי הניהול או משאבי הענן שהצוות שלכם משתמש בהם הכי הרבה. כך תוודאו שאתם מאבטחים את הגישה למטרות בעלות הערך הגבוה באמת, ולא רק לנקודות כניסה כלליות.
הגדירו תנאים
כוונו את המדיניות לפי גורמים כמו מצב המכשיר, מיקומים (מהימנים מול מסוכנים) או סיכון הכניסה. בארגונים רבים, השארת "Any device, any location" היא האפשרות הבטוחה ביותר בהתחלה. בצעו התאמות עדינות ככל שתכירו את דפוסי השימוש.
דרשו MFA
תחת "Grant", בחרו "Grant access" וסמנו "Require multifactor authentication". ייתכן שתוסיפו גם דרישת תאימות מכשיר, אם דרישות האבטחה שלכם מחייבות זאת.
הפעילו מצב Report-Only
התחילו עם "Report-only" כדי לדמות את פעולת המדיניות לפני שתפעילו אותה באכיפה מלאה. שלב קריטי זה עוזר לאתר תצורות שגויות ולמנוע נעילה של מנהלי המערכת. בדקו את יומני הכניסה וראו את ההשפעה לפני שתתחייבו (טיפ מקצועי: אל תדלגו על שלב זה, לא משנה כמה בטוחים אתם).
פרסו בהדרגה ועקבו
הפעילו את המדיניות עם קבוצת פיילוט ועקבו אחר התוצאות. פתרו בעיות שעולות, והרחיבו לאחר מכן לקבוצות מנהלים רחבות יותר. בצעו התאמות שוטפות ככל שתיתקלו במקרי שימוש חדשים. כוונון מדיניות Conditional Access הוא תהליך מתמשך ולא משימה חד-פעמית. לטיפים נוספים בנושא ממשל וצמיחה, כדאי להתבונן בגישה הזו לצמצום סיכונים וניהול התפשטות המדיניות.

שימוש בתבניות של Microsoft לפריסה מהירה של Conditional Access MFA

עיינו בתבניות המובנות: Microsoft מציעה תבניות מוכנות של Conditional Access ישירות בפורטלים של Azure ו-Defender. חפשו אפשרויות בשם "Require MFA for admin roles" או דומה לה, שנועדו לחשבונות מוגנים.
בחרו והתאימו אישית: בחרו את התבנית שמתאימה ביותר לצרכים שלכם. התאימו את ההגדרות לתפקידי המנהלים, לאפליקציות ולמצב האבטחה הספציפיים שלכם, כלומר למשתמשים בהיקף, לבקרות הנדרשות ולבחירת האפליקציות.
בדקו ופרסו במהירות: התבניות מייעלות את ההקמה ומחילות את ברירות המחדל המומלצות של Microsoft. בדקו את הדיוק ולאחר מכן החילו. השתמשו במצב report-only כדי לבחון את ההשפעה לפני הטמעת השינויים בכל הדייר.
הרחיבו במהירות ושמרו על עקביות: התבניות מאפשרות להרחיב הגנה מבלי לפספס שלבים, וזה שימושי במיוחד לארגונים הנתונים ללחץ זמן או בעלי משאבים מוגבלים.

בקרות ניהול מתקדמות: מיקומים בשם ו-Directory Roles Exclusions ב-Conditional Access

לאחר שהגדרתם מדיניות MFA, הגיע הזמן להעלות את הרמה עם בקרות ניהול מתקדמות. לא כל הסביבות והתרחישים מתאימים לכללי אבטחה אחידים. Named locations מאפשרים להגדיר טווחי IP מהימנים, כגון רשת המשרד המקומית שלכם או VPN מאובטח, כך שתוכלו להחיל כללי Conditional Access שונים בהתאם למקום שממנו המנהלים מתחברים.

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

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

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

בדיקת מדיניות Conditional Access חדשה במצב Report-Only

הפעלת מצב Report-Only: כשיוצרים או עורכים מדיניות Conditional Access חדשה, בחרו “Report-only” במקום “On”. כך מתבצעת סימולציה של האכיפה: אף משתמש לא ייחסם, אבל תראו בדיוק מה היה קורה אילו הופעלה המדיניות בפועל.
מעקב אחר יומני כניסה: בדקו את יומני הכניסה (Sign-in logs) בפורטל Azure כדי לבחון את התוצאות המדומות עבור המנהלים. תראו אילו כניסות היו מפעילות MFA או נחסמות, וכך תקבלו אזהרה מוקדמת על הפרעה אפשרית למשתמשים.
התאמה וכוונון: השתמשו בנתוני הטלמטריה כדי לזהות פערים, התראות שווא או מדיניות מגבילה מדי. התאימו בהתאם את היעד, התנאים או החריגות לפני שתפעילו את מצב האכיפה על כל המנהלים.
הרצה עם קבוצות פיילוט: שקלו להקצות את המדיניות החדשה תחילה לקבוצה קטנה של מנהלי בדיקה. עודדו משוב ותעדו בעיות תפעוליות, כדי שההטמעות הרחבות יתבצעו בצורה חלקה ואף אחד לא ייננעל בלי התראה.

שיטות עבודה מומלצות להטמעת בסיס Conditional Access וגיבוש אסטרטגיית האבטחה הסופית למנהלים

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

הפכו את התחזוקה השוטפת להרגל. בצעו סקירה קבועה של המדיניות לאיתור סחף (Drift), כלומר הנטייה לצבור חריגות או לאפשר להגנות להיחלש ככל שצורכי העסק משתנים. שמרו על תיעוד מעודכן, הכולל אילו חשבונות ותפקידים נכללים בהיקף, אילו חריגות קיימות, ומתי ומדוע בוצעו שינויים. כללו הנחיות ברורות לייבוא, ייצוא והתאמה של מדיניות Conditional Access לכיסוי המנהלים בשירותים כמו Intune, Teams, Exchange, SharePoint ואחרים.

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

לסיום, טפחו תרבות של יישור קו. ודאו שכל המעורבים – IT, אבטחה והנהלה עסקית – מסונכרנים לגבי כללי גישה של מנהלים, טיפול בחשבונות חירום ועדכוני מדיניות. עם תיעוד מוצק, סקירה שוטפת ופריסת בסיס, תקבלו תוכנית Conditional Access שלא רק מגינה, אלא גם מסתגלת לארגון שלכם. למידע נוסף על אכיפת ממשל ומניעת סטייה, ראו אסטרטגיות ממשל ארגוני ב-Azure, שמדגישות את החשיבות של מדיניות בת-קיימא ומאוכפת.

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

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

Conditional Access – Simply Explained — הבנה של האופן שבו אותות זהות, מכשיר, מיקום וסיכון מעצבים החלטות גישה.
Privileged Identity Management – Simply Explained — איך הרשאות לפי דרישה וזרימות אישור מצמצמות את החשיפה של הרשאות ניהול.
Microsoft Defender XDR – Simply Explained — חיבור אותות זהות לזיהוי, לחקירה ולתגובה לאירועים.
Microsoft Teams Governance – Simply Explained — איך בעלות ברורה וכללי מחזור חיים הופכים שיתוף פעולה מאובטח לבר-קיימא.

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