גישה מדויקת ב-Microsoft 365: איך לאבטח אפליקציות, תיבות דואר וקבצים בלי הרשאות יתר
פורסם ב-11 במאי 2025
מבוא
ככל שאימוץ הענן מואץ, אפליקציות הפכו לשחקניות מפתח בכל סביבת Microsoft 365: הן מריצות אוטומציות, משלבות שירותים וניגשות למידע רגיש. אבל עם הצמיחה הזו מגיע סיכון: אפליקציות רבות מקבלות הרשאות יתר, משתמשות בשיטות אימות חלשות או ניגשות ליותר מידע ממה שהן צריכות.
המודלים המסורתיים של אמון באפליקציות כבר לא מספיקים. בתגובה, Microsoft מציגה בקרות חדשות שעוזרות לאכוף איך אפליקציות מבצעות אימות ולאילו משאבים הן יכולות להגיע, בהתאם לעקרונות Zero Trust המודרניים.
הפוסט הזה מציג שלושה עדכונים מעשיים שנותנים לאדמינים שליטה הדוקה יותר בהתנהגות האפליקציות:
- ה-API של Entra application management policies
- הגבלת גישה ב-SharePoint וב-OneDrive
- הגבלת גישה לתיבות דואר עבור אפליקציות Graph
היכולות האלה הן מפתח לבניית סביבת אפליקציות מאובטחת ב-Microsoft 365, לפי עיקרון ההרשאות המינימליות (least privilege).
1. 🔐 ה-API של Entra application management policies
למה זה חשוב
ארגונים רבים נשענים על client secrets ותעודות לאימות אפליקציות, אבל אלה עלולים להפוך בקלות לנקודות תורפה. ניהול לקוי של מחזור החיים או ברירות מחדל מתירניות מדי יכולים להוביל לפיזור של פרטי גישה, ל-shadow IT ולחשיפה.
כדי לעזור למנוע את הסיכונים האלה, Microsoft מאפשרת כעת לארגונים להגדיר מדיניות מפורטת שמסדירה את שיטות האימות של אפליקציות.
מה חדש
אפשר להגדיר Application Authentication Method Policies באמצעות Microsoft Graph (Beta). המדיניות האלה מאפשרת להתיר או לאסור סוגי פרטי גישה מסוימים, לאכוף כללי תפוגה ולחסום פרקטיקות לא מאובטחות, הן ברמת ה-tenant כולו והן לכל אפליקציה.
מעבר לכך, Microsoft מציעה רשימה עשירה של סוגי הגבלות מוכנים שאפשר להחיל, וכך האכיפה הופכת מעשית הרבה יותר.
טבלת סוגי ההגבלות:
| שם ההגבלה | תיאור | דוגמאות |
|---|---|---|
| asymmetricKeyLifetime | אכיפת טווח חיים מרבי למפתח א-סימטרי (תעודה). | הגבלת תעודות ל-30 ימים לכל היותר עבור אפליקציות שנוצרו אחרי 01/01/2019. |
| audiences | הגבלת יצירה או קידום של אפליקציות לפי ערכי signInAudience. | מניעת הגדרת אפליקציות חדשות כ-multi-tenant. |
| customPasswordAddition | הגבלת secrets מותאמים אישית בעת יצירת אפליקציה או service principal. | חסימת secrets שלא נוצרו על ידי Azure באפליקציות שנוצרו אחרי 01/01/2015. |
| nonDefaultUriAddition | חסימת identifier URIs שלא עומדים בפורמט ברירת המחדל. | התרת api://{appId} או api://{tenantId}/{appId} בלבד כ-URIs. |
| passwordAddition | חסימה מלאה של password secrets. | מניעת שימוש בסיסמאות בכל האפליקציות החדשות שנוצרו אחרי 01/01/2019. |
| passwordLifetime | אכיפת טווח חיים מרבי ל-password secrets. | הגדרת תוקף מרבי של 30 ימים ל-secrets שהונפקו אחרי 01/01/2015. |
| symmetricKeyAddition | חסימת שימוש במפתחות סימטריים. | מניעת פרטי גישה חדשים מסוג מפתח סימטרי באפליקציות שנוצרו אחרי 01/01/2019. |
| symmetricKeyLifetime | אכיפת טווח חיים מרבי למפתחות סימטריים. | הגבלת טווח החיים ל-30 ימים במפתחות סימטריים חדשים. |
| trustedCertificateAuthority | התרת תעודות רק מ-CAs מהימנים. | דחיית כל תעודה שהונפקה על ידי רשויות שלא ברשימה. |
דוגמאות מהשטח
- ✅ לאכוף תעודות קצרות טווח לאפליקציות אוטומציה: אתם מגדירים מדיניות שמגבילה את תוקף התעודה ל-30 ימים עבור כלי אוטומציה פנימיים, וכך מצמצמים את החשיפה במקרה של גניבה או דליפה.
- 🚫 לאסור רישום multi-tenant כברירת מחדל: ה-tenant שלכם חוסם יצירת אפליקציות multi-tenant אלא אם אושרו במפורש, וכך מצמצם סיכון בשרשרת האספקה.
💡 טיפ מקצועי: הבקרות האלה חזקות במיוחד בצוותי פיתוח מרובים, שבהם יצירת האפליקציות ורישומן מבוזרים.
2. 📁 Selected Permissions ב-SharePoint וב-OneDrive
למה זה חשוב
אפליקציות שזקוקות לגישה לקבצים קיבלו עד היום הרשאות ברמת ה-tenant כולו כמו Sites.Read.All או Files.ReadWrite.All. זה יוצר סיכון מיותר, כי רוב האפליקציות צריכות גישה רק לכמה משאבים.
עכשיו, עם Selected permissions, אדמינים יכולים להגביל במפורש את הגישה של אפליקציה רק לאתרי SharePoint או לכוננים של OneDrive שהיא צריכה.
איך זה עובד
- מקצים לאפליקציה את ההרשאה Sites.Selected.
- משתמשים ב-Graph API או ב-PowerShell כדי להעניק גישה לפי אתר או ברמת הכונן.
- האפליקציה לא יכולה לגשת לשום דבר אחר אלא אם אושר במפורש.
דוגמאות
- 🎯 כלי של שותף חיצוני שמוגבל לאתר אחד: אפליקציה של סוכנות שיווק מקבלת גישה רק אל Campaigns2024.sharepoint.com/sites/agency. אין גישה ליחידות עסקיות אחרות.
- 📊 דשבורד Power BI שמוגבל ל-OneDrive של משתמש אחד: כלי BI קורא רק מהתיקייה של מנהל המכירות, בלי נראות לתוכן של אחרים.
💡 טיפ מקצועי: אפשר להפוך את הקצאת ההרשאות לאוטומטית באמצעות סקריפטי provisioning כחלק מ-CI/CD לפריסת אפליקציות.
3. ✉️ הגבלת גישת אפליקציות לתיבות דואר ב-Exchange
למה זה חשוב
כברירת מחדל, מתן גישת Graph API אל Mail.Read או Mail.Send נותן לאפליקציות גישה מלאה לכל תיבות הדואר. זה מסוכן, במיוחד לאפליקציות שצריכות גישה רק לתיבות משותפות או לחשבונות מערכת.
עכשיו Microsoft תומכת ב-Application Access Policies, שמאפשרות להגביל הרשאות לתיבות דואר או לקבוצות מסוימות.
איך זה עובד
- משתמשים ב-PowerShell (New-ApplicationAccessPolicy) כדי להגדיר כללים.
- מחילים מדיניות לפי אפליקציה, לפי תיבה, או דרך קבוצות.
- יש תמיכה גם בהרשאות קריאה וגם בהרשאות שליחה דרך Microsoft Graph.
דוגמאות
- 🛠️ אפליקציית Helpdesk שמוגבלת לתיבות תמיכה בלבד: מונעים מהאפליקציה לקרוא תיבות של מנהלים בכירים, על ידי הגבלתה ל-support@company.com ול-techdesk@company.com.
- 🧾 כלי אוטומציה של HR שמוגבל לתיבת ה-onboarding: המערכת מתקשרת רק עם hr-onboarding@company.com לתהליכי מייל אוטומטיים.
💡 טיפ מקצועי: שלבו את זה עם Conditional Access ועם App Enforced Restrictions כדי לקבל מודל תחום במלואו.
🧠 לסיכום
העדכונים האלה הם לא רק מועילים, הם בסיס לממשל אפליקציות מודרני ב-Microsoft 365. כל אחד מהם מתיישר ישירות עם עקרונות Zero Trust:
- לא לסמוך כברירת מחדל (ובמיוחד לא על אפליקציות),
- תמיד לאמת (איזו שיטה, איזה היקף),
- להגביל חשיפה (בדיוק לצורך).
צוותי אבטחה, זהויות ותאימות צריכים לסקור כבר היום את הרשאות האפליקציות הקיימות, ולוודא שהן תואמות את השימוש בפועל. הכלים האלה הופכים את התהליך הזה לניתן לאוטומציה, ניתן לביקורת וניתן לאכיפה.
ואם אתם רוצים להרחיב את הבקרות האלה למאות אפליקציות או משתמשים, פלטפורמות כמו Griffin31 יכולות לעזור למפות, לתעדף ולתקן פערים מהר מתמיד.