למה ניהול זכויות של Entra ID נכשל (ואיך לתקן את זה)

By Mirko Peters · 2026-10-28

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

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

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

עיקרי הדברים

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

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

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

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

חבילות מבוססות תפקיד לעומת חבילות יישום

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

גבולות קטלוג ובקרות בעלות

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

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

מניעת התפשטות חבילות לאורך זמן

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

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

בניית אסטרטגיית ממשל בת קיימא

תכנון חבילות גישה שניתנות להרחבה דורש להתייחס לממשל כאל תהליך עבודה התנהגותי מתמשך, ולא כמשימת הגדרה חד-פעמית. שלבו את החבילות מבוססות התפקיד עם מוסכמות שמות אינטואיטיביות שמציינות בבירור את תחום העסק ואת רמת היעד, כגון finance-analyst-standard או engineering-platform-elevated. שלבו שמות אלה עם תיאורים ברורים וללא ז'argon, שנכתבו במיוחד לעובדים חדשים ולא למנהלי IT.

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

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

שאלות נפוצות

מדוע יש לבנות חבילות גישה לפי תפקיד ולא לפי אפליקציה?

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

מהי מטרת הקטלוג בניהול זכויות של Entra ID?

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

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

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

מה קורה כאשר חבילת גישה פוקעת?

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