שליטה בהרשאות של Microsoft Graph: הימנעות ממלכודת ההרשאות המינימליות

By Mirko Peters · 2026-08-28

כשמתחילים לפתח אפליקציות, לכתוב סקריפטים לאוטומציה או לשלב כלים של צד שלישי בסביבת Microsoft 365 שלכם, Microsoft Graph מהר מאוד הופך למערכת העצבים המרכזית. הוא מחבר בין Teams, SharePoint, Exchange ו־Azure Active Directory, ומספק לכם תצוגה אחידה של הנתונים הארגוניים. עם זאת, לכוח גדול מגיעה אחריות אדריכלית גדולה לא פחות. לעיתים קרובות מדי, צוותים נופלים למלכודת הנוחות ומעניקים הרשאות רחבות וגורפות

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

כשמתחילים לפתח אפליקציות, לכתוב סקריפטים לאוטומציה או לשלב כלים של צד שלישי בסביבת Microsoft 365 שלכם, Microsoft Graph מהר מאוד הופך למערכת העצבים המרכזית. הוא מחבר בין Teams, SharePoint, Exchange ו־Azure Active Directory, ומספק לכם תצוגה אחידה של הנתונים הארגוניים. עם זאת, לכוח גדול מגיעה אחריות אדריכלית גדולה לא פחות. לעיתים קרובות מדי, צוותים נופלים למלכודת הנוחות ומעניקים הרשאות רחבות וגורפות רק כדי שהאפליקציה תעבוד במהירות. קיצור דרך כזה עלול לחשוף את כל הדייר שלכם לסיכוני אבטחה הרסניים. היום נפרק יחד איך מנווטים בבטחה בהרשאות של Microsoft Graph, ואיך מוצאים את האיזון בין פונקציונליות האפליקציה לבין עיקרון ההרשאות המינימליות המוחלט.

הכוח הנסתר והסיכון שבהרשאות של Microsoft Graph

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

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

הבנת ההבדל בין גישה מואצלת לגישה של אפליקציה בלבד

כדי לאבטח את הדייר שלכם ב־Microsoft 365, עליכם קודם כול לשלוט בשני מודלי ההרשאה העיקרייםש־Microsoft Graph משתמש בהם: גישה מואצלת (delegated) וגישה של אפליקציה בלבד (application).

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

לעומת זאת, גישה של אפליקציה בלבד פועלת באופן עצמאי מכל משתמש. האפליקציה רצה כדמון ברקע, כסקריפט מתוזמן או כשירות אוטומטי. מכיוון שאין הקשר של משתמש מחובר שמגביל את הנתונים, גישה של אפליקציה בלבד מסתמכת על הרשאות של אפליקציה (app roles). תפקידים אלה נושאים לעיתים קרובות הרשאות עצומות על פני כל הדייר. אבטחת תרחישים של אפליקציה בלבד דורשת ממשל הדוק, סקירות קבועות של השימוש ב־service principals, וקפדנות מלאה בעיקרון ההרשאות המינימליות.

מלכודת ההרשאות המינימליות: טעויות נפוצות בהרשאות

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

אחת המלכודות המסוכנות ביותר היא שימוש בהרשאות רחבות של כל הדייר או בתווים כלליים (wildcards), מתוך נוחות. לדוגמה, הענקת User.Read.All כאשר אפליקציה צריכה רק לקרוא את הפרופיל של המשתמש הנוכחי, יוצרת חשיפה מיותרת. טעות נפוצה נוספת היא סינון התוצאות בשכבת האפליקציה לאחר שליפת מערך הנתונים כולו, במקום להשתמש במסנני שאילתות OData בצד השרת. אם האפליקציה שלכם מבקשת את כל אוספי האתרים רק כדי לסנן אותם מקומית, נתונים שהאפליקציה לא הייתה אמורה לראות כבר חצו את גבול הרשת והגיעו לשכבת האפליקציה.

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

אבטחת הדייר שלך מבלי לשבור את פונקציונליות היישומים

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

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

פרקטיקה קריטית נוספת היא יישום של היקפים מדויקים (granular scopes). במקום לבקש גישה רחבה לכל תיבות הדואר או לכל האתרים, חפשו אפשרויות הסכמה ספציפיות למשאב, במקומות שבהם הן זמינות. לדוגמה, אינטגרציות מודרניות של Microsoft Teams ו-SharePoint מאפשרות להעניק הרשאות לצוותים או לאתרים מסוימים, במקום לדייר כולו. כך מבודדים את פרופיל הסיכון: אם אפליקציה אחת תיפרץ, רדיוס הנזק יוגבל לסביבת עבודה שיתופית אחת, ולא לארגון כולו.

אסטרטגיות מעשיות לניהול אבטחת Microsoft 365

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

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

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

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