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

By Mirko Peters · 2026-08-11

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

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

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

כדי לעזור לכם להבין לעומק את הנושא המורכב הזה, הקלטנו לאחרונה פרק מעמיק. הקפידו לשמוע את הדיון המלא באודיו ב-Microsoft Graph Permissions and Consent Models Explained. בפוסט הבלוג הנלווה הזה נרחיב על המושגים האלה, נבחן את ההבדלים המרכזיים בין הרשאות מואצלות להרשאות יישום, נסקור מודלים של הסכמה, נציג שיטות עבודה מומלצות ונספק מסגרת מקיפה שתעזור לוודא שהאפליקציות שלכם יישארו מאובטחות ותואמות לרגולציה.

סקירה של הרשאות Microsoft Graph API

לפני שנכנסים לפרטים הדקים של תהליכי ההרשאה הספציפיים, כדאי להבין מה הן בעצם הרשאות Microsoft Graph API. בבסיסו, Microsoft Graph משמש כשער מאוחד אל הנתונים שנמצאים בשירותי Microsoft 365, ביניהם Exchange Online, SharePoint, Microsoft Teams, OneDrive ו-Azure Active Directory (Microsoft Entra ID). במקום לחייב מפתחים להתאמת מול מספר נקודות קצה מבודדות, Microsoft Graph מספק נקודת קצה REST אחת. עם זאת, מכיוון שה-API הזה פותח גישה כמעט לכל פינה של המרחב הדיגיטלי של הארגון, נדרשת מסגרת הרשאות חזקה ומפורטת כדי לאבטח אותו.

הרשאות מואצלות לעומת הרשאות יישום

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

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

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

הבדלים מרכזיים ומקרי שימוש

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

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

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

הרשאות מואצלות ב-Microsoft Graph

איך הרשאות מואצלות פועלות

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

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

תרחישים נפוצים להרשאות מואצלות

הרשאות מואצלות מניעות את רוב האינטגרציות היומיומיות בתחום הפרודוקטיביות. לדוגמה, אם יישום לניהול הערות ארגוני צריך לסנכרן קבצים לחשבון OneDrive של המשתמש, הוא מבקש את ההיקף Files.ReadWrite. אם למשתמש אין הרשאה לגשת למסמך מסוים, ממשק ה-Graph API ידחה את הבקשה, גם אם ההיקף של היישום מאפשר זאת מבחינה טכנית. באופן דומה, יישומים שמשתמשים ב-Microsoft Graph SDK כדי לשלוח הודעות דוא"ל אוטומטיות בשם משתמש נשענים על היקפים מואצלים כמו Mail.Send.

שיקולי אבטחה והסכמה

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

הרשאות יישום ב-Microsoft Graph

איך הרשאות יישום פועלות

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

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

מתי להשתמש בהרשאות יישום

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

הסכמת מנהל והשלכות אבטחתיות

מכיוון שהרשאות יישום עוקפות את המגבלות של משתמשים בודדים ומעניקות גישה ברמת הדייר, משתמשים רגילים אינם יכולים להסכים להן. רק מנהל בעל הרשאות יכול לאשר הסכמת יישום. הרשאות יישום שהוגדרו בצורה שגויה, כמו מתן Directory.ReadWrite.All או Mail.ReadWrite.All ליישום רקע לא מהימן או בעל קוד לקוי, עלולות להותיר דייר Microsoft 365 שלם פגיע לפריצה מלאה. יש לבצע ביקורת קבועה של נציגי השירות של יישומי הארגון.

יתרונות וחסרונות של הרשאות Microsoft Graph API

יתרונות

• מודל הרשאות מאוחד: מסגרת הרשאות אחידה ועקבית בכל שירותי Microsoft 365 מפשטת את הניהול.
• היקפים מדויקים: היקפים מואצלים ויישומיים מפורטים מאפשרים ארכיטקטורות של פריבילגיה מינימלית מדויקת.
• OAuth2/OpenID Connect סטנדרטי: שימוש בפרוטוקולי אבטחה תקניים בתעשייה לאינטגרציית זהות פשוטה.
• אינטגרציה עם RBAC: מתחברת בצורה חלקה לתפקידים ב-Azure AD ולמדיניות גישה מותנית, לצורך ציות מרוכז.
• הסכמה מצטברת: מאפשרת לאפליקציות לבקש הרשאות נוספות לאורך זמן, במקום לדרוש את כולן מראש.

חסרונות

• מורכבות: ההתמודדות עם החיתוך בין היקפי הרשאות מואצלות, תפקידי אפליקציה ומודלים של הסכמת מנהל עלולה להציף מי שמתחיל.
• סיכוני הרשאות גבוהות: הגדרה שגויה של הרשאות רחבות (כמו Sites.FullControl.All) עלולה לחשוף כמויות אדירות של מידע ארגוני.
• צווארי בקבוק בהסכמת מנהל: דרישת אישור מנהלי להרשאות בעלות השפעה גבוהה עלולה להאט מחזורי פיתוח אג'ילי.
• פיזור התיעוד: מפתחים נדרשים לעיתים קרובות לעבור בין מספר מאגרי תיעוד של Microsoft כדי למפות את התנהגות ה-API המדויקת.

מודלים של הסכמה ושיטות עבודה מומלצות

הסכמת משתמש לעומת הסכמת מנהל ב-Microsoft Graph

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

השפעת מדיניות הדייר על הרשאות

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

אסטרטגיות לזרימת הסכמה חלקה

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

טעויות נפוצות בהרשאות של Microsoft Graph API

• בלבול בין הרשאות מואצלות להרשאות אפליקציה, וחוסר הבנה של דרישות ההקשר של המשתמש.
• בקשת הרשאות מוגזמות מראש, במקום אימוץ גישה של הרשאה מינימלית.
• אי התחשבות בדרישות הסכמת מנהל בעת פריסת שירותים שפועלים ברקע.
• הנחה ששינויים בהרשאות בפורטל Azure נכנסים לתוקף מיד, ללא רענון של האסימון.
• הצגת אסימון גישה מואצל במקום אסימון client credentials שנדרש.
• התעלמות ממדיניות גישה מותנית שחוסמת בקשות Graph API בזמן ריצה.
• הזנחה של אימות תביעות ההיקף (scope claims) בתוך קוד האפליקציה בזמן ריצה.
• אי ביקורת לאורך זמן על הרשאות אפליקציה שניתנו וסוגי שירות (service principals).

רשימת בדיקה להרשאות Microsoft Graph API

השתמשו ברשימת הבדיקה המעשית הזו כדי להנחות את הצוות שלכם בתכנון, ביישום ובביקורת של הרשאות Microsoft Graph API בצורה מאובטחת:

סיכום

הניווט בהרשאות Microsoft Graph API לא חייב להיות תרגיל מתסכל. כשמבינים לעומק את ההבדלים התפעוליים בין הרשאות מואצלות (שדורשות משתמש מחובר ופועלות במגבלות המשתמש) לבין הרשאות אפליקציה (שפועלות ברקע ללא מגבלות ודורשות הסכמת מנהל), אפשר לתכנן פתרונות מאובטחים וגמישים. אימוץ עקרון ההרשאה המינימלית, ביקורת קפדנית וניצול כלי ממשל ארגוניים ישמרו על סביבת Microsoft 365 שלכם בטוחה, בלי לעכב חדשנות.

למידע מעשי נוסף, אסטרטגיות מהשטח וצלילה לעומק באבטחת סביבת הענן שלכם, הקשיבו לפירוק האודיו המלא בפרק הקשור: Microsoft Graph Permissions and Consent Models Explained. שמרו על הרשאות הדוקות, אישורים מאובטחים, ובהצלחה בקידוד!