מדריך ליחידות ניהול מנוהלות ב-Microsoft Entra

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

למדו על יחידות ניהול מנוהלות ב-Microsoft Entra עם הנחיות מעשיות בנושאי אבטחה, ממשל, בקרת גישה, יישום ושימוש בעולם האמיתי.

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

Cover: Fix Azure Governance Before Your Next Cloud Audit

אם אתם מנהלים ארגון גדול שעובד עם Microsoft 365 או Azure, הדברים עלולים להסתבך מהר מאוד. יחידות ניהול מנוהלות (Administrative Units, או בקיצור AUs) ב-Microsoft Entra ID פועלות כמו ראשי שמירת השכונה ברחובות הדיגיטליים של הדייר שלכם. הן מאפשרות לחלק את בסיס המשתמשים לפי חלקים, כך שמנהלים מקומיים יקבלו שליטה מספקת לניהול "השטח" שלהם, אבל לא על העיר כולה.

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

מהי יחידת ניהול מנוהלת ב-Microsoft Entra ID?

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

לאחר שהגדרתם יחידת ניהול מנוהלת, אפשר להאציל הרשאות ניהול, כמו User Administrator או Helpdesk Admin, רק לאנשים או לקבוצות שנמצאים בתוך היחידה. כך צוותי IT מקומיים נשארים ממוקדים בעובדים שלהם, בלי להתערב בכל מקום אחר. מדובר בביזור השליטה, אבל בלי לפתוח את כל הדלתות בבת אחת.

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

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

כיצד יחידות ניהול מנוהלות של Azure נבדלות מקבוצות ומ-OUs

יחידות ניהול מנוהלות (AUs): נועדו להאצלת ניהול. מגדירות היקף של תפקידי ניהול למשתמשים ולקבוצות מסוימים בתוך היחידה, אך אינן מעניקות הרשאות גישה למשאבים כמו קבצים או תיבות דואר.
קבוצות: משמשות להקצאת גישה לאפליקציות ולמשאבים (למשל Teams, SharePoint, רישוי). קבוצות אינן מגבילות או מגדירות גבולות ניהול, והן מייצגות רק חברות לצורך הרשאות או הפצה.
יחידות ארגוניות (OUs): מושג מ-Active Directory מקומי, המארגן אובייקטים (משתמשים, מחשבים) בהיררכיה לצורך החלת מדיניות קבוצה. לא תוכננו להאצלה בענן או ב-Microsoft 365, ואין להן מקביל ישיר ב-Entra ID.

בקצרה: השתמשו ב-AUs לתחימת ניהול, בקבוצות לגישה, וב-OUs לארגון מקומי. בחרו את הכלי המתאים למשימה.

יישום יחידות ניהול מנוהלות: תרחישי מפתח עבור Microsoft 365

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

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

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

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

מתי להשתמש ביחידות ניהול מנהלתיות בתרחישי ניהול מורכבים

ארגונים מפוזרים גיאוגרפית: הקצו צוותי IT אזוריים לניהול משתמשים רק במיקום שלהם (לדוגמה, אירופה, אסיה) בלי גישה לדייר הגלובלי.
חלוקה מחלקתית: האצילו הרשאות ניהול למשאבי אנוש, לכספים או לפקולטות אקדמיות, כך שההרשאות של כל צוות יישארו מוגבלות למחלקה שלו.
גבולות תאימות או פרטיות: הפרידו בין משתמשים הכפופים לרגולציות שונות (כמו GDPR או HIPAA) ליחידות AU ייעודיות, ואכפו גבולות אבטחה.
מיזוגים ורכישות: שלבו יחידות עסקיות חדשות או חברות שנרכשו, ואפשרו להן לנהל את עצמן, בלי לפתוח גישה לכל הסביבה שלכם.
חינוך ומחוזות בית ספר: תנו למנהלי בתי ספר שליטה רק על התלמידים והצוות בקמפוס שלהם, תוך שמירה על נתוני בתי ספר אחרים מחוץ להישג יד.

שימוש ביחידות ניהול מנהלתיות של Azure לניהול חלוקת דייר Microsoft 365

ניהול מבוזר: יחידות AU מאפשרות להקצות מנהלים מקומיים רק לאנשים או לקבוצות שהם מכירים, בלי צורך במנהל גלובלי למשימות יומיומיות. זה עוזר למנוע מצב של “יותר מדי טבחים במטבח”.
גבולות אבטחה ברורים: על ידי חלוקת הדייר באמצעות יחידות AU, ניתן להגדיר גבולות שמתיישרים עם מחלקות, אזורים או ישויות משפטיות, כאשר לכל אחד מהם הרשאות ניהול מותאמות אישית.
תאימות קלה יותר: כאשר צוותי IT רואים רק את המשתמשים בתחום האחריות שלהם, קל הרבה יותר לעבור ביקורות, לאכוף הרשאות מינימליות ולהגביל סיכוני חשיפת נתונים.
איתור תקלות פשוט יותר: מנהלים מקומיים יכולים לאפס סיסמאות, לנהל רישיונות או לשנות חברויות בלי להפריע לנתונים של צוותים אחרים, וכך הניהול היומיומי הופך לחלק יותר.
תמיכה באסטרטגיות ממשל: לאסטרטגיות מתקדמות סביב RBAC, PIM ואכיפה, כדאי לקרוא את הגישה הזו לממשל Azure ולשיטות העבודה המומלצות ב-RBAC, שמציעה טיפים מעשיים.

איך להגדיר יחידות ניהול מנהלתיות ב-Microsoft Entra ID

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

אפשר לבנות יחידות AU ישירות ב-Azure Portal, שמציע תהליך אינטואיטיבי וצעד אחר צעד. לארגונים גדולים או דינמיים יותר, ניתן להפעיל כישורי אוטומציה עם Microsoft Graph API, ולתת לסקריפטים לבצע את מרבית העבודה.

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

לבסוף, כדאי להקצות תפקידי ניהול באמצעות מודל Azure AD הקלאסי, או דרך Privileged Identity Management (PIM) לצורך גישה לפי דרישה ויכולת מעקב. הסעיפים הבאים יפרטו כל שלב, כך שתצאו מוכנים לבנות, לאבטח ולהאציל סמכויות בביטחון.

יצירה והגדרה של יחידות ניהול מנהלתיות ב-Microsoft 365

גישה ל-Azure Portal: נווטו אל Microsoft Entra ID, בחרו ב-Administrative Units ולחצו על “+ יחידת ניהול מנהלתית חדשה” כדי להתחיל בתהליך ההגדרה.
שם, תיאור ובחירת היקף: תנו ליחידת ה-AU שם ברור ותיאורי (כמו “מנהלי מכירות APAC”). אפשר להוסיף תיאור אופציונלי למנהלים עתידיים.
הוספת חברים: ניתן להקצות משתמשים או קבוצות ישירות כחברים. החליטו מי מנוהל בתוך יחידת AU זו, כי המנהלים ישפיעו רק על האנשים האלה.
אפשרות לאוטומציה: מעדיפים קוד? השתמשו ב-Microsoft Graph API כדי ליצור, לעדכן ולנהל יחידות AU עבור תהליכים המוניים או אוטומטיים. סקריפטים מקלים על שינויים גדולים ומפחיתים שגיאות.
בדיקת התנגשויות חברות: הימנעו מחברויות חופפות בין יחידות AU אם אתם רוצים היקף מוגדר בצורה הדוקה. משתמש יכול להיות מנוהל רק ביחידת AU אחת עבור הקשר תפקיד מסוים.

הקצאת משתמשים וקבוצות ליחידות ניהול מנהלתיות

הקצאה ישירה: הוסיפו משתמשים או קבוצות באופן ידני דרך Azure Portal (Users > Add member), כך שייהפכו לאובייקטים מנוהלים ביחידת ה-AU שלכם.
קבוצות דינמיות (עם מגבלות): אפשר להוסיף קבוצות דינמיות כחברים ב-AU, אבל ליחידות המנהל עצמן אין כרגע יכולת לאכוף כללים דינמיים באופן מקורי – כללי הקבוצות הדינמיות שמורים בקבוצה ולא ביחידת המנהל.
ייבוא בכמויות: בארגונים גדולים, השתמשו ב-PowerShell או ב-Graph API כדי להקצות משתמשים וקבוצות רבים ביעילות. כך חוסכים זמן ומבטיחים עקביות.
סקירת חברות באופן קבוע: הגדירו בדיקות תקופתיות כדי להסיר חשבונות יתומים ולוודא שלמשתמשים עדיין יש את ההיקף המתאים להם. החיים משתנים – שמרו על הגבולות מעודכנים.
הכללת מכשירים: כרגע, מכשירים (כמו מחשבים ניידים וטלפונים) אינם יכולים להיות חברים ב-AU. הניהול מתמקד אך ורק באנשים וקבוצות, ולא בחומרה או במשאבים.

הקצאת תפקידים למנהלים באמצעות Privileged Identity Management

הקצאת תפקידים לכל AU: מתוך ה-AU, הקצו תפקידים כמו User Administrator, Groups Administrator או Helpdesk Admin, כך שמנהלים מואצלים יקבלו הרשאות רק בתוך אותה יחידת מנהל.
שימוש ב-PIM לגישה בזמן אמת (JIT): השתמשו ב-Privileged Identity Management (PIM) של Azure AD כדי להעניק גישת ניהול זמנית לפי דרישה (JIT). המשמעות היא שניתן להפעיל תפקידים לזמן קצר, ובכך להפחית את הסיכון של הרשאות "תמיד פעילות".
הפעלת תהליכי אישור: הגדירו אישורים ב-PIM כך שגישת ניהול תדרוש אישור נוסף – פתרון מציל חיים לסביבות עם דרישות תאימות או אבטחה גבוהה.
ניטור וביקורת גישה: עקבו אחר מי מפעיל אילו תפקידים ומתי. חברו יומני ביקורת ל-Microsoft Sentinel או השתמשו ב-Purview Audit למעקב פורנזי אחר פעילות משתמשים בכל Microsoft 365. זה מעשיר את הממשל ומחזק את תמונת האבטחה שלכם.
סקירת הרשאות ניהול שהוקצו: בדקו מחדש את התפקידים שהוקצו באופן קבוע. הסירו הרשאות מיושנות או מיותרות כדי למנוע הצטברות הרשאות (privilege creep) ולחזק את עקרון ההרשאות המינימליות.

דרישות ניהול, רישוי ומגבלות

לפני שתתחילו לחלק את הדייר שלכם לחלקים באמצעות AU, יש כמה תנאי מקדים ואילוצים שכדאי לקחת בחשבון. לא כל המנויים של Microsoft 365 שווים – שימוש ב-AU דורש בדרך כלל רישיונות Azure AD Premium P1 הן למשתמשים שמוגדרים והן למנהלים שמוקצים להם.

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

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

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

מגבלות ניהול מרכזיות: היררכיה, מכשירים ו-SharePoint

אין מבנה היררכי: ל-AU אין מושג של קינון או ארגון הורה-ילד. לא ניתן, למשל, ליצור AU בשם "צפון אמריקה" עם AU-משנה לכל מדינה או מחוז. כל AU עומדת בפני עצמה.
פערים בניהול מכשירים: מכשירים כמו מחשבים ניידים, טלפונים או מדפסות לא ניתנים לניהול ישיר באמצעות AU. אם אתם צריכים היקף ברמת המכשיר, ייתכן שתידרשו לפתרונות אחרים או למדיניות Intune.
מגבלות SharePoint/OneDrive: AU לא מגבילים הרשאות ניהול על אתרי SharePoint או על OneDrive. ניהול ממשל נתונים באפליקציות אלה דורש אסטרטגיות נפרדות או חלופות כמו Microsoft Dataverse לצרכי נתונים מורכבים.
אתגרים בהקצאת רישיונות: ניתן להקצות רישיונות למשתמשים בתוך AU, אבל אין אוטומציה מובנית המוגבלת ל-AU, ולכן קשה יותר לבצע אוטומציה בקנה מידה גדול.
ניהול מאפיינים: עדכון מרוכז או דיווח על מאפייני משתמשים בתוך AU מוגבל. לרוב תצטרכו כלים חיצוניים, PowerShell או Graph API כדי לסגור את הפערים.

אבטחה, ממשל וחלופות ל-Administrative Units

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

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

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

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

השלכות אבטחה שנותרו וחלופות לדיירים וירטואליים

הצטברות הרשאות (Privilege Creep): אם הרשאות מנהל אינן נבדקות, מנהלים לשעבר או עובדים שעוברים מתפקיד לתפקיד עלולים לצבור הרשאות "זומבי" – אחד מסיכוני הפנים המובילים. בדיקות סדירות והסרה של הרשאות מיותרות הן חיוניות.
פערים בביקורת ובנראות: יומני הביקורת המקוריים עשויים לא לחשוף בקלות מי שינה מה ובאיזו יחידת AU. לפיקוח ברמה ארגונית, חברו את יומני Entra למערכות SIEM, או השתמשו ב-Microsoft Purview/Sentinel לניטור חזק ודוחות תאימות. פרקים כמו Agentageddon מסבירים את הסיכונים הכרוכים בפיגור בביקורת של בינה מלאכותית וממשל ב-Microsoft 365.
מגבלות היקף: יחידות AU אינן יכולות לפלח סביבות רב-ענניות או היברידיות באופן מקורי. בתצורות היברידיות או רב-ענניות, פנו לכלים של צד שלישי או לפתרונות דיירים וירטואליים לקבלת גבולות מעמיקים יותר וממשל מרכזי.
מתי כדאי לשקול חלופות: שקלו פתרונות כמו דיירים וירטואליים של CoreView כשאתם זקוקים לפילוח רב-שכבתי, למיפוי תאימות או לאוטומציה מתקדמת של תהליכי עבודה מעבר למה שיחידות AU מספקות. Shadow IT ובינה מלאכותית דורשים ניטור מתקדם – ראו הניתוח הזה על יסודות Microsoft Foundry ו-Purview לרעיונות נוספים.

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

אם אתם חוקרים יחידות מנהליות של Microsoft Entra, הפרקים הבאים מוסיפים הקשר מעשי על אבטחת זהויות, ממשל, גישה מיוחסת ויישום:

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