איך לבצע ביקורת אפליקציות OAuth של צד שלישי ב-Slack, GitHub ו-Microsoft 365

כדי לבצע ביקורת אפליקציות OAuth של צד שלישי, בודקים את רשימת ההרשאות של כל פלטפורמה בנפרד: עמוד Installed Apps של Slack, מדיניות אפליקציות OAuth הארגונית של GitHub, ורשימת ה-Enterprise applications של Microsoft Entra. כל אחת מציגה פרוסה שונה של אותה בעיה בסיסית — אילו אפליקציות יכולות לפעול על הנתונים שלכם — ואף אחת לא מציגה את השתיים האחרות.

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

איפה רואים אפליקציות OAuth מורשות ב-Slack?

עברו אל Settings & administration ← Manage apps, שפותח את Slack Marketplace בהיקף ה-workspace שלכם, ואז בחרו Installed Apps בראש הסרגל הצדדי. זה זמין בכל תוכנית Slack ומציג כל אפליקציה מותקנת עם ה-scopes שאושרו לה.

ב-Enterprise Grid, קטע ה-Integrations בלוח הניהול מוסיף תצוגה כלל-ארגונית על פני כל ה-workspaces בבת אחת. התצוגה הזו מופעלת על ידי ה-scope‏ admin.apps:read, המוגבל ל-Enterprise Grid — וגם שם, הוא חושף רק אילו אפליקציות מאושרות, מוגבלות או ממתינות; הוא לא חושף את רשימת ה-scopes המלאה של כל אפליקציה באותה קריאה. ב-workspace בודד, עמוד Installed Apps נשאר המקור האמין למה שאפליקציה יכולה בפועל לעשות.

איפה רואים אפליקציות OAuth מורשות ב-GitHub?

עברו אל Settings ← Third-party Access ← OAuth app policy של הארגון שלכם. ארגונים חדשים מגיעים עם הגבלות גישת אפליקציות OAuth מופעלות כברירת מחדל, כך שהעמוד הזה הוא גם המקום שבו חברים מבקשים גישה לאפליקציה חדשה ובו בעלים מאשרים או דוחים אותה. כדי לבטל אפליקציה שאושרה בעבר, מוצאים אותה באותה רשימה ובוחרים Deny access.

אפליקציות GitHub Apps (מנגנון נפרד מ-OAuth Apps הקלאסיות, שרוב האינטגרציות המודרניות משתמשות בו) נבדקות במקום אחר: Settings ← Integrations ← GitHub Apps (או Installed GitHub Apps) של הארגון מציג מה מותקן ולאילו מאגרים כל אחת יכולה להגיע.

איפה רואים אפליקציות OAuth מורשות ב-Microsoft 365?

היכנסו ל-מרכז הניהול של Microsoft Entra ועברו אל Identity ← Applications ← Enterprise applications ← All applications. בחרו אפליקציה, ואז Permissions. לשונית Admin consent מציגה הרשאות שהוענקו לכל ה-tenant — וניתן לבטל אותן ישירות שם. לשונית User consent מציגה מה משתמשים בודדים אישרו לעצמם — והפורטל לא מציע כפתור ביטול עבורה; לקיחתה בחזרה דורשת קריאת Microsoft Graph API או פקודת PowerShell מתאימה, שמופעלת על ידי מישהו עם תפקיד Cloud Application Administrator.

למה ביקורת לפי פלטפורמה קשה לתחזוקה?

שלוש קונסולות, שלושה פורמטים, שלושה תפקידי אדמין שונים נדרשים רק כדי לפתוח אותן. התצוגה התכנותית כלל-ארגונית של Slack דורשת Enterprise Grid; הרשאות המשתמש של מיקרוסופט דורשות PowerShell או Graph, לא לחיצה בפורטל; GitHub מפריד בין OAuth Apps קלאסיות ל-GitHub Apps כשתי רשימות נפרדות שאדמין צריך לדעת לבדוק בנפרד. אף אחת מהשלוש לא מדרגת אפליקציה לפי סיכון, ואף אחת לא מספרת לכם אם לאותו ספק יש גם חיבור בשתי הפלטפורמות האחרות עם סט הרשאות רחב יותר שם.

מה רשימה לפי-פלטפורמה לא מספרת לכם, ואיך 8200.dev עונה על כך

כל קונסולה מספרת לכם מה מורשה על אותה פלטפורמה אחת. אף אחת לא מספרת לכם את התמונה המשולבת — אותו בוט תמלול AI מחובר לערוצי Slack, למאגר GitHub ולתיבת דואר של Microsoft 365, כל אחד עם scope שהוענק בנפרד. Agent Guard של 8200.dev קורא את שלושתם עם scopes בהרשאות-מינימום, קריאה-בלבד — channels:read,‏ groups:read,‏ files:read,‏ users:read וscopes קריאה קשורים של Slack בתוספת ביקורת תצורת workspace; read:org,‏ גישת מאגר לקריאה-בלבד,‏ read:user, מיפוי התקנות, נראות חיוב Copilot לקריאה-בלבד, ו-read:audit_log של GitHub; ו-Sites.Read.All,‏ Files.Read.All,‏ Directory.Read.All,‏ Application.Read.All,‏ User.Read.All,‏ Policy.Read.All,‏ Reports.Read.All,‏ AuditLog.Read.All,‏ RoleManagement.Read.Directory ו-DelegatedPermissionGrant.Read.All של Microsoft 365 — וממזג כל ממצא משלושתם למלאי אחד מדורג-סיכון. קונקטור Microsoft 365 מתחבר לכל דירקטורי עבודה או לימודים של מיקרוסופט השייך לארגון, לא ל-tenant קבוע אחד, כך שהוא מתחבר באותו אופן בין אם הארגון שלכם הוא היחיד בתמונה או אחד מכמה.

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

ראו את עמודי הקונקטור של Slack, GitHub ו-Microsoft 365 לרשימת ה-scopes המלאה ומה כל אחד סורק.