יש משפט אחד ששומעים שוב ושוב: ״אם אני נותן לאפליקציה הרשאות Graph מסוג delegated עם admin consent, האפליקציה יכולה לעשות הכול בטננט.״
זה מבלבל במיוחד כשמתחילים לעבוד עם Microsoft Graph ו-Entra ID. אם אפליקציה קיבלה scope מסוג delegated כמו PrivilegedAccess.ReadWrite.AzureADGroup, האם כל אחד בטננט יכול להשתמש בו? התשובה הקצרה: לא.
התובנה שמשנה הכול: הרשאות delegated תמיד רצות בהקשר של המשתמש המחובר. כלומר, תפקיד ה-Entra הקיים של המשתמש נשאר שומר סף, בדיוק כמו ההרשאות של האפליקציה.
Delegated לעומת Application permissions: מה ההבדל?
Delegated permissions (משתמש + אפליקציה). בתרחיש הזה:
- האפליקציה פועלת בשם משתמש מחובר.
- גם לאפליקציה צריך להיות ה-scope הנכון מסוג delegated, וגם המשתמש צריך להחזיק בתפקיד ה-Entra הנדרש כדי לבצע את הפעולה.
- אם אחד מהם חסר, ה-scope של האפליקציה או התפקיד של המשתמש, הקריאה נכשלת בגלל הרשאות לא מספיקות.
דוגמה מבדיקה אמיתית: הרצנו Graph CLI עם PrivilegedAccess.ReadWrite.AzureADGroup. כמשתמש רגיל, כל הקריאות נכשלו. כ-Global Admin, פתאום הכול עבד. הרשאות delegated לא מעלות את ההרשאות של משתמשים, הן רק מאפשרות לאפליקציה לבצע את מה שהמשתמש כבר יכול היה לעשות ידנית.
Application permissions (אפליקציה לבדה). כאן אין משתמש מעורב, והאפליקציה רצה תחת הזהות של ה-service principal שלה. הפעולה מצליחה רק על סמך ההרשאות שניתנו לאפליקציה, בלי קשר לתפקיד של משתמש כלשהו.
דוגמה: אפליקציה עם Group.ReadWrite.All כ-application permission יכולה ליצור או למחוק קבוצות גם בלי שאף משתמש מחובר. לכן צריך להתייחס ל-application permissions כמו אל חשבונות שירות בעלי הרשאות גבוהות: הן עוקפות לגמרי את בדיקות המשתמש.
תפקידי Directory ב-Entra: החוליה שמתעלמים ממנה
קל לחשוב שהרשאות API לבדן קובעות מה יבוצע, אבל זה רק חצי מהסיפור. במודל delegated, תפקיד ה-Entra של המשתמש חשוב באותה מידה.
| הרשאת Graph מסוג delegated | תפקידי Entra נדרשים |
|---|---|
| Group.ReadWrite.All | Global Admin, Groups Admin, Directory Writers |
| RoleManagement.ReadWrite.Directory | Global Admin, Privileged Role Administrator |
| PrivilegedAccess.ReadWrite.AzureADGroup | Global Admin, Privileged Role Administrator |
| Directory.ReadWrite.All | תלוי באובייקט: למשל User Administrator למשתמשים; לכל האובייקטים רק Global Admin |
גם אם לאפליקציה יש את ההרשאה, אתם תקועים אם למשתמש אין אחד מהתפקידים האלה. delegated עובד רק כשההרשאה של האפליקציה והתפקיד של המשתמש מתאימים זה לזה.
מודלי consent: משתמש לעומת מנהל
User consent:
- כל משתמש צריך לאשר בנפרד את ה-scopes מסוג delegated כשהוא מתחבר.
- מנהלי הטננט יכולים להשבית או להגביל אותו.
Admin consent:
- Privileged Role Administrator יכול לאשר מראש כל הרשאה לכל הטננט. Cloud Application Administrator ו-Application Administrator יכולים לאשר הכול חוץ מ-application permissions של Microsoft Graph.
- כלומר, המשתמשים לא מקבלים יותר בקשות הסכמה.
- אבל: הוא לא עוקף את התפקיד שהמשתמש צריך. משתמש שאינו אדמין עדיין ייחסם מפעולות בעלות הרשאות גבוהות, גם אם ההרשאות ״אושרו״.
סיכוני אבטחה ושימוש לרעה
אלה הטעויות הנפוצות ביותר שאנחנו רואים:
- שימוש יתר ב-application permissions רק כי הן נראות פשוטות יותר.
- אמונה ש-admin consent שווה כוחות על בכל הטננט.
- הזנחת ביקורת של אפליקציות שמחזיקות scopes רחבים כמו Directory.ReadWrite.All.
הסכנה היא לא ב-delegated permissions, אלא באי-הבנה של אופן הפעולה שלהן, או במתן יתר של application permissions בלי פיקוח.
שיטות עבודה מומלצות
- העדיפו delegated permissions כשאפשר: הן בטוחות יותר מטבען כי הן יורשות את ההרשאות המינימליות של המשתמש (least privilege).
- היזהרו עם application permissions: התייחסו אליהן כמו לחשבונות שירות בעלי הרשאות גבוהות.
- נטרו ובקרו אילו אפליקציות מחזיקות Graph scopes בעלי השפעה גבוהה.
- השתמשו ב-admin consent במשורה ורק לאפליקציות מהימנות.
- סקרו באופן קבוע service principals עם הרשאות app-only ודעו מה הם באמת יכולים לעשות.
consent דינמי לעומת סטטי
לפי התיעוד של Microsoft, הרשאות delegated אפשר להעניק באופן דינמי בזמן ריצה (incremental consent). כלומר, אפליקציה יכולה לבקש scopes נוספים לפי הצורך, והמשתמש מחליט באותו רגע.
ל-application permissions אין את הגמישות הזו: הן סטטיות וחייבות לקבל אישור מראש מאדמינים. זו עוד סיבה לכך ש-delegated permissions הן לא פעם הבחירה הטובה יותר.
Conditional Access: הבדל נוסף
כללי Conditional Access חלים על delegated permissions, כי משתמש מתחבר. אם המדיניות דורשת MFA, תאימות מכשיר או רשתות מסוימות, היא תחול.
ב-application permissions אין התחברות של משתמש, ולכן מדיניות Conditional Access רגילה לא חלה. אפשר לחסום service principals לפי מיקום או סיכון עם Conditional Access for workload identities, אבל רק לאפליקציות single-tenant שרשומות בטננט שלכם, ורק עם רישיון Workload Identities Premium. אפליקציות SaaS ו-managed identities לא מכוסות, וזה פער ממשל (governance) שמתעלמים ממנו לא פעם.
השורה התחתונה
- Delegated = משתמש + אפליקציה, מוגבל על ידי תפקיד ה-Entra.
- Application = אפליקציה לבדה, כפופה ל-service principal שלה.
- Admin consent מסיר בקשות הסכמה, לא בדיקות תפקיד.
אם לוקחים מכאן דבר אחד: הרשאות delegated לא מעלות את ההרשאות של משתמשים, הן מכבדות את הגבולות שלהם.
הרשאות אפליקציות והגדרות consent קל לאבד עליהן שליטה. Griffin31 בודק את הגדרות הטננט שלכם באופן רציף ומראה מה לתקן קודם.