הרשאות API, תפקידי Entra והסכמה (consent) ב-Microsoft Graph — כל מה שצריך לדעת
פורסם ב-26 באוגוסט 2025
למה הרשאות Delegated ב-Microsoft Graph לא אומרות מה שאתם חושבים
איבדתי ספירה של כמה פעמים שמעתי בדיוק את המשפט הזה:
״אם אני נותן לאפליקציה הרשאות Graph מסוג delegated עם admin consent, האפליקציה יכולה לעשות הכול ב-tenant.״
כשהתחלתי לעבוד עם Microsoft Graph ו-Entra ID, גם אני תהיתי על זה. אם אפליקציה קיבלה scope מסוג delegated כמו PrivilegedAccess.ReadWrite.AzureADGroup, האם זה אומר שכל אחד ב-tenant שלי יכול להשתמש בו? החלטתי לכתוב את הפוסט הזה כי הלוואי שמישהו היה מבהיר לי את זה, בפשטות ובכנות, לא כהצגה של ספק אלא כמי שעובד בתחום ופעם הרגיש את אותה בלבול שאני מנחש שגם אתם מרגישים.
המציאות מאחורי הרשאות Delegated
תובנה אחת מכריעה שינתה לי הכול: הרשאות delegated תמיד רצות בהקשר של המשתמש המחובר. כלומר, תפקיד ה-Entra הקיים של המשתמש נשאר שומר סף, בדיוק כמו ההרשאות של האפליקציה.
בקצרה (TLDR)
- Delegated permissions = אפליקציה + משתמש יחד. האפליקציה יכולה לעשות רק מה שתפקיד ה-Entra של המשתמש כבר מאפשר.
- Application permissions = אפליקציה לבדה. רצה תחת ה-service principal ועוקפת בדיקות של תפקידי משתמש.
- Admin consent לא נותן למשתמשים כוחות חדשים, הוא רק מסיר את בקשות ההסכמה.
- Conditional Access חל על delegated (התחברות של משתמש) אבל לא על application permissions.
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 לבדן קובעות מה יבוצע, אבל זה רק חצי מהסיפור. תפקיד ה-Entra של המשתמש חשוב באותה מידה במודל delegated.
הרשאת 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 ← Global Admin בלבד
גם אם יש הרשאת אפליקציה, אתם תקועים אם הזהות של המשתמש לא תואמת לתפקידים שלמעלה. זה פשוט: delegated הוא בעל משמעות רק כשהאפליקציה ותפקיד המשתמש מתאימים זה לזה.
מודלי הסכמה (Consent): משתמש לעומת מנהל
User Consent:
- כל משתמש צריך לאשר בנפרד את ה-scopes מסוג delegated כשהוא מתחבר.
- מנהלי ה-tenant יכולים להשבית או להגביל אותו.
Admin Consent:
- Global Admin יכול לאשר מראש הרשאות אפליקציה לכל ה-tenant.
- כלומר, אין יותר בקשות למשתמשים.
- אבל יש כאן הסתייגות: הוא לא עוקף את התפקיד שהמשתמש צריך. משתמש שאינו אדמין עדיין ייחסם מפעולות בעלות הרשאות גבוהות, גם אם ההרשאות ״אושרו״.
סיכוני אבטחה ושימוש לרעה:
מניסיון, אלה הטעויות הנפוצות ביותר שראיתי:
- שימוש יתר ב-application permissions רק כי הן נראות פשוטות יותר.
- אמונה ש-admin consent = כוחות על ברמת ה-tenant כולו.
- הזנחת ביקורת של אפליקציות שמחזיקות scopes רחבים כמו Directory.ReadWrite.All.
הסכנה היא לא ב-delegated permissions, אלא באי-הבנה של אופן הפעולה שלהן, או במתן יתר של application permissions בלי פיקוח.
שיטות עבודה מומלצות שאני פועל לפיהן היום:
- העדיפו delegated permissions כשאפשר: הן בטוחות יותר מטבען כי הן יורשות את ההרשאות המינימליות של המשתמש (least privilege).
- היזהרו עם application permissions: התייחסו אליהן כמו לחשבונות שירות בעלי הרשאות גבוהות.
- נטרו ובצעו ביקורת על אילו אפליקציות מחזיקות Graph scopes בעלי השפעה גבוהה.
- השתמשו ב-admin consent במשורה ורק לאפליקציות מהימנות.
- סקרו באופן קבוע service principals עם הרשאות app-only, וודאו שאתם יודעים מה הם באמת יכולים לעשות.
הסכמה דינמית לעומת סטטית:
פרט אחד שלמדתי מהתיעוד של Microsoft: הרשאות delegated אפשר להעניק באופן דינמי בזמן ריצה (incremental consent). כלומר, אפליקציה יכולה לבקש scopes נוספים לפי הצורך, והמשתמש מחליט באותו רגע.
ל-application permissions אין את הגמישות הזו. הן סטטיות וחייבות להיות מאושרות מראש על ידי אדמינים.
הגמישות הזו היא עוד סיבה לכך ש-delegated permissions הן לא פעם הבחירה הטובה יותר.
Conditional Access: הבדל נוסף:
כללי Conditional Access (CA) חלים על delegated permissions, כי משתמש מתחבר. אם CA דורש MFA, תאימות מכשיר או רשתות מסוימות, המדיניות הזו תחול.
ב-application permissions אין התחברות של משתמש, ולכן מדיניות CA לא חלה. זה פער ממשל (governance) שמתעלמים ממנו לא פעם.
מילה אחרונה:
Delegated = משתמש + אפליקציה, מוגבל על ידי תפקיד ה-Entra
Application = אפליקציה לבדה, כפופה ל-service principal שלה
Admin consent מסיר בקשות הסכמה, לא בדיקות תפקיד
אם תיקחו מהפוסט הזה דבר אחד, שיהיה זה: הרשאות delegated לא מעלות את ההרשאות של משתמשים, הן מכבדות את הגבולות שלהם.
למידע נוסף: https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview