תצוגת סנכרון קבוצות התפקידים של Entra: תכננו את הגישה ביעד

Read in English

ניהול זהויות · המקורות נבדקו ב־7 בנובמבר 2026

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

מה מוסיפה התצוגה המקדימה של נובמבר

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

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

בדקו התאמה לפני הקמת פיילוט

סקירת הסנכרון דורשת Entra ID Governance או Entra Suite לכל משתמש מסונכרן במקור כאשר מסנכרנים קבוצות וחברים. P1 מכסה סנכרון משתמשים בלבד, גם כשקבוצות משמשות רק לבחירתם. הסנכרון עצמו אינו דורש רישיון ביעד, אך תכונות היעד עשויות לדרוש אותו. סנכרון קבוצות אינו חוצה ענני Microsoft ואינו תומך בקינון; היקפו חייב להיות משתמשים וקבוצות שהוקצו. טבלת העננים תומכת בקבוצות בתוך Commercial או Government, ולא בתוך 21Vianet.

בנפרד, הנחיות קבוצות התפקידים דורשות P1 לתכונה ו־P2 להפעלה לפי צורך באמצעות PIM. קבוצות שניתן להקצות להן תפקידים משתמשות בחברות Assigned ולא בחברות דינמית, ומותרות עד 500 בדייר. אי אפשר לשנות את יכולת הקצאת התפקידים לאחר היצירה. בדקו את הדרישות האלה לצד זכאות הסנכרון, במקום לפרש שורת רישוי אחת כאישור לכל התכונות.

לסדר ההגדרה יש משמעות

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

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

רשומת קבלה מעשית

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

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

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