איך לראות אילו אפליקציות ניגשות ל-Microsoft 365 שלכם

אפשר לראות כל אפליקציה עם גישה ל-tenant ה-Microsoft 365 שלכם ממרכז הניהול של Microsoft Entra, תחת Identity ← Applications ← Enterprise applications ← All applications. בחירת אפליקציה ופתיחת לשונית ה-Permissions שלה מציגה בדיוק לאילו נתוני Microsoft Graph היא יכולה להגיע, מחולק להרשאות שהאדמינים של הארגון אישרו ולהרשאות שמשתמשים בודדים אישרו לעצמם.

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

איפה מוצאים את רשימת האפליקציות עם גישה ב-Entra?

1. היכנסו ל-entra.microsoft.com עם חשבון שמחזיק לפחות בתפקיד Cloud Application Administrator או Application Administrator.
2. עברו אל Identity ← Applications ← Enterprise applications ← All applications.
3. בחרו את האפליקציה שברצונכם לבדוק, ואז פתחו Permissions.

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

מה ההבדל בין הסכמת אדמין להסכמת משתמש?

לשונית Permissions מתחלקת לשתיים:

• Admin consent — הרשאות שהוענקו לכל הארגון על ידי מנהל. אלו חלות על כל משתמש שההרשאה מכסה, לא רק על מי שלחץ בפועל.
• User consent — הרשאות שיחיד אישר לעצמו, אדם אחד בכל פעם, בלי מעורבות אדמין (כאשר הגדרות ההסכמה של ה-tenant שלכם מאפשרות זאת).

בחירת כל הרשאה ברשימה פותחת חלונית Permission Details שמתארת בדיוק מה היא מאפשרת.

איך מבטלים גישה של אפליקציה?

עבור הענקת Admin consent: פותחים את ההרשאה ברשימה, בוחרים בפקד … לצדה, ובוחרים Revoke permission — זה עובד ישירות בפורטל.

עבור הענקת User consent, לפורטל אין כפתור ביטול. לקיחתה בחזרה דורשת קריאת Microsoft Graph API (‏DELETE /oAuth2PermissionGrants/{id} עבור הרשאות מואצלות, או הקריאה המקבילה ל-appRoleAssignments עבור הרשאות אפליקציה) או פקודת PowerShell תואמת, שמופעלת על ידי מישהו עם תפקיד Cloud Application Administrator. ביטול הרשאה גם לא מונע מאותו משתמש להסכים שוב בפעם הבאה שהאפליקציה תבקש — עצירת זה דורשת שינוי מדיניות ההסכמה של ה-tenant בנפרד, תחת Enterprise apps ← Consent and permissions ← User consent settings.

מה אם הארגון שלי פרוס על פני כמה tenant-ים של Microsoft 365 או דירקטורי שותף?

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

מה בדיקה אפליקציה-אחר-אפליקציה לא מספרת לכם, ואיך 8200.dev עונה על כך?

מעבר על Enterprise applications אפליקציה אחר אפליקציה מספר לכם למה כל אפליקציה *מורשית* להגיע. הוא לא מדרג את האפליקציות לפי כמה סיכון הן בפועל מייצגות, לא מסמן אילו הרשאות התיישנו, ולא נשאר יציב בזמן שאתם עוברים על הרשימה — הסכמה חדשה יכולה להיכנס בזמן שאתם עדיין בודקים את האחרונה. קונקטור Microsoft 365 של 8200.dev קורא Sites, Files, Directory, רישומי Application, משתמשים, מדיניות אבטחת tenant, דוחות רישום MFA, יומני ביקורת, שיוכי תפקידים והרשאות מואצלות — כולם דרך scopes קריאה-בלבד של Graph — והופך אותם למלאי אחד, מתעדכן ברציפות ומדורג-סיכון, במקום רשימה שפותחים ידנית מחדש. הוא מתחבר באותו אופן לכל דירקטורי עבודה או לימודים של מיקרוסופט השייך לארגון, כך שקבוצה הפרוסה על פני יותר מ-tenant אחד לא צריכה הגדרה נפרדת לכל אחד. כל scope כאן קריאה-בלבד: שום דבר לא משנה הרשאה או מדיניות אלא אם הארגון בוחר בנפרד להפוך פעולה ספציפית לאוטומטית.

ראו את רשימת הקונקטורים המלאה כדי לראות איך זה משתלב לצד Google Workspace, Slack ו-GitHub.