Как проаудировать сторонние OAuth-приложения в Slack, GitHub и Microsoft 365

Чтобы проаудировать сторонние OAuth-приложения, проверьте список авторизаций каждой платформы по отдельности: страницу Installed Apps в Slack, политику OAuth-приложений организации в GitHub и список Enterprise applications в Microsoft Entra. Каждая из них показывает свой срез одной и той же проблемы — какие приложения могут действовать с Вашими данными — и ни одна не показывает данные двух других.

В этом руководстве приведён точный путь для каждой платформы, что она показывает и где аудит на уровне одной платформы упирается в предел возможностей.

Где посмотреть авторизованные OAuth-приложения в Slack?

Перейдите в Settings & administration → Manage apps — это откроет Slack Marketplace в контексте Вашего рабочего пространства, — затем выберите Installed Apps в верхней части боковой панели. Этот раздел доступен на любом тарифе Slack и отображает каждое установленное приложение вместе со скоупами, на которые оно было одобрено.

В Enterprise Grid раздел Integrations в админ-панели добавляет представление на уровне всей организации сразу по всем рабочим пространствам. Это межпространственное представление работает на основе скоупа admin.apps:read, который доступен только в Enterprise Grid и даже там показывает лишь то, какие приложения одобрены, ограничены или ожидают рассмотрения — полный список скоупов приложения в этом же запросе не раскрывается. В рамках одного рабочего пространства именно страница 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) организации — здесь перечислено, что установлено и к каким репозиториям у каждого приложения есть доступ.

Начиная с 2026 года организация также может настроить градуированный контроль над тем, кто вообще вправе *запрашивать* новое приложение, в разделе Settings → Third-party Access: запрашивать приложения могут и участники, и внешние соавторы (давний вариант по умолчанию), внешним соавторам можно закрыть эту возможность, оставив её участникам, либо запретить запросы обеим группам полностью — что сужает поверхность аудита ещё до того, как запрос вообще попадёт в очередь владельца. Само общеорганизационное ограничение на доступ OAuth-приложений тоже можно полностью отключить, что убирает этап одобрения для всех участников — стоит убедиться, что эта настройка всё ещё включена, прежде чем считать список политики OAuth-приложений полной картиной выданных авторизаций.

Где посмотреть авторизованные OAuth-приложения в Microsoft 365?

Войдите в Microsoft Entra admin center и перейдите в Identity → Applications → Enterprise applications → All applications. Выберите приложение, затем Permissions. Вкладка Admin consent показывает разрешения, выданные для всего арендатора (tenant), — и их можно отозвать прямо там же. Вкладка User consent показывает, что отдельные пользователи одобрили для себя лично, — и портал не предлагает кнопку отзыва для этого случая; чтобы отозвать такое согласие, требуется вызов Microsoft Graph API или команда PowerShell, выполненная пользователем с ролью Cloud Application Administrator. Если арендатор полностью блокирует согласие пользователей, глобальный администратор может вместо этого включить рабочий процесс admin consent, чтобы заблокированный запрос превращался в запрос на рассмотрение, а не в тупик — подробнее о работе этой очереди рассмотрения см. в руководстве по доступу в Microsoft 365.

Почему аудит по каждой платформе отдельно трудно поддерживать в актуальном состоянии?

Три консоли, три формата, три разные админ-роли, необходимые даже для того, чтобы их открыть. Для программного представления на уровне всей организации в Slack нужен Enterprise Grid; для пользовательских разрешений в Microsoft нужны PowerShell или Graph, а не клик в портале; GitHub разделяет классические OAuth Apps и GitHub Apps на два разных списка, о необходимости отдельной проверки которых администратор должен знать. Кроме того, Slack разбивает собственное представление Installed Apps на вкладки Approved, Restricted и Requests, так что полная проверка означает просмотр трёх фильтров поверх трёх платформ. Ни одна из трёх платформ не ранжирует приложения по риску, и ни одна не сообщает, подключён ли тот же поставщик и к двум другим платформам с более широким набором разрешений там.

Что не может показать аудит по одной платформе — и как это решает 8200.dev

Каждая консоль сообщает, что авторизовано именно на этой платформе. Ни одна не даёт объединённую картину — например, тот же AI-помощник по заметкам подключён к каналам Slack, репозиторию GitHub и почтовому ящику Microsoft 365, причём каждое подключение выполнено с собственным, отдельно выданным набором скоупов. Agent Guard от 8200.dev считывает данные со всех трёх платформ с использованием скоупов минимально необходимого доступа, только для чтения — для Slack это channels:read, groups:read, files:read, users:read и связанные скоупы чтения плюс аудит конфигурации рабочего пространства; для GitHub — read:org, доступ к репозиториям только для чтения, read:user, инвентаризация установленных приложений, видимость биллинга Copilot только для чтения и read:audit_log; для Microsoft 365 — 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 любой организации, а не с одним фиксированным арендатором, поэтому подключение работает одинаково независимо от того, единственная ли Ваша организация в этой картине или одна из нескольких.

Каждый из этих скоупов предназначен только для чтения. Ничего здесь не отзывает доступ приложения самостоятельно — это остаётся рекомендацией, которую организация выполняет осознанно, либо явным согласием на автоматизацию конкретного правила.

Полный список скоупов и описание того, что сканирует каждый коннектор, см. на страницах коннекторов Slack, GitHub и Microsoft 365.