Slack、GitHub、Microsoft 365にまたがるサードパーティOAuthアプリの監査方法

サードパーティのOAuthアプリを監査するには、各プラットフォームそれぞれの承認リストを個別に確認する必要があります。Slackの「インストール済みアプリ」ページ、GitHubの組織OAuthアプリポリシー、Microsoft EntraのEnterpriseアプリケーション一覧です。それぞれが「どのアプリが自社のデータを操作できるか」という同一の問題の異なる断面を示しており、どのプラットフォームも他の2つを映し出すことはありません。

本ガイドでは、各プラットフォームでの正確な確認手順と、そこで何がわかるか、そしてプラットフォームごとの監査がどこで限界を迎えるかを説明します。

Slackで承認済みのOAuthアプリはどこで確認できますか?

「設定と管理」→「アプリを管理」に進むと、自社のワークスペースに限定されたSlack Marketplaceが開きます。続いてサイドバー上部の「インストール済みアプリ」を選択してください。これはすべてのSlackプランで利用可能で、インストール済みの各アプリと、そのアプリが承認されたスコープが一覧表示されます。

Enterprise Gridでは、管理ダッシュボードの「連携機能」セクションに、すべてのワークスペースを横断する組織全体のビューが追加されます。このワークスペース横断ビューはadmin.apps:readスコープによって提供されますが、これはEnterprise Gridに限定されており、そこであっても、どのアプリが承認済み・制限付き・保留中であるかが表示されるだけで、同じ呼び出しで各アプリの完全なスコープ一覧が公開されるわけではありません。単一ワークスペースでは、「インストール済みアプリ」ページが、アプリが実際に何をできるかを示す正式な情報源であり続けます。

GitHubで承認済みのOAuthアプリはどこで確認できますか?

組織の「設定」→「サードパーティのアクセス」→「OAuth app policy」に進みます。新規の組織ではデフォルトでOAuthアプリのアクセス制限が有効になっているため、このページはメンバーが新しいアプリへのアクセスをリクエストする場所であり、オーナーがそれを承認または拒否する場所でもあります。以前承認したアプリを取り消すには、同じ一覧からそのアプリを見つけ、「Deny access」を選択します。

GitHub Apps(従来のOAuth Appsとは別の仕組みで、多くの最新の連携機能で使用されています)は別の場所で確認します。組織の「設定」→「Integrations」→「GitHub Apps」(または「Installed GitHub Apps」)に、インストール済みのアプリと、それぞれがアクセスできるリポジトリが一覧表示されます。

2026年時点では、組織は「そもそも誰が新しいアプリをリクエストできるか」についても段階的な制御を設定できるようになっており、「設定」→「サードパーティのアクセス」から、メンバーと外部コラボレーターの両方がアプリをリクエストできる(従来からのデフォルト)、外部コラボレーターはブロックしメンバーのみリクエスト可能にする、あるいは両方のグループともいかなるアプリのリクエストもできないようにする、という選択が可能です。これにより、リクエストがオーナーの承認待ちキューに届く前の段階で、監査対象の範囲を絞り込むことができます。組織全体のOAuthアプリアクセス制限そのものも完全に無効化することが可能で、その場合すべてのメンバーについて承認ステップが取り除かれます。これは、OAuth app policyの一覧を承認済みアプリの完全な記録として信頼する前に、有効なままになっているかどうかを確認しておく価値がある設定です。

Microsoft 365で承認済みのOAuthアプリはどこで確認できますか?

Microsoft Entra管理センターにサインインし、「ID」→「アプリケーション」→「エンタープライズ アプリケーション」→「すべてのアプリケーション」に進みます。アプリを選択し、続いて「アクセス許可」を選択します。「管理者の同意」タブにはテナント全体に付与された権限が表示され、その場で直接取り消すことができます。「ユーザーの同意」タブには個々のユーザーが自分自身のために承認した内容が表示されますが、ポータルにはこれを取り消すボタンは用意されていません。取り消すには、Microsoft Graph APIの呼び出しか、Cloud Application Administratorロールを持つ担当者によるPowerShellコマンドレットの実行が必要です。テナントがユーザーの同意そのものをブロックしている場合、グローバル管理者は代わりに管理者の同意ワークフローを有効化でき、それによりブロックされたリクエストは行き止まりではなく、レビュー可能なものになります。このレビューキューの具体的な仕組みについては、Microsoft 365アクセスガイドをご覧ください。

なぜプラットフォームごとの監査は最新の状態を保ちにくいのですか?

3つのコンソール、3つの異なる形式、そしてそれらを開くだけでも必要になる3つの異なる管理者ロール。Slackの組織横断的なプログラムによるビューにはEnterprise Gridが必要で、Microsoftのユーザー単位の付与状況を確認するにはポータルのクリックではなくPowerShellまたはGraphが必要であり、GitHubは従来のOAuth AppsとGitHub Appsを別々の一覧に分けているため、管理者は両方を個別に確認しなければならないことを把握しておく必要があります。さらにSlackは、自らの「インストール済みアプリ」ビューを「承認済み」「制限あり」「リクエスト」タブに分けているため、完全な確認には3つのプラットフォームに加えて3つのフィルターを確認する必要があります。この3つのいずれも、アプリをリスクの高さでランク付けすることはなく、また同一のベンダーが他の2つのプラットフォームでもより広範な権限を持って接続されているかどうかを教えてくれることもありません。

プラットフォームごとの一覧ではわからないこと、そして8200.devがそれにどう答えるか

各コンソールは、そのプラットフォーム1つにおいて何が承認されているかを教えてくれます。しかし、統合された全体像 — 同じAIノートテイカーがSlackチャンネル、GitHubリポジトリ、Microsoft 365メールボックスに接続され、それぞれが個別に付与されたスコープを持っている、といった状況 — を教えてくれるものはありません。8200.devのAgent Guardは、最小権限の読み取り専用スコープでこの3つすべてを読み取ります。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を用い、この3つすべてから得られたすべての検出結果を、リスクスコア付きの1つの一覧にまとめます。Microsoft 365コネクタは、特定の単一テナントではなく、あらゆる組織自身のMicrosoft職場または学校ディレクトリで動作するため、自社がこの構図の中で唯一の組織であっても、複数の組織のうちの1つであっても、同じ方法で接続できます。

これらのスコープはすべて読み取り専用です。ここに含まれるものは、単独でアプリのアクセス権を取り消すことはありません。それは組織が意図的に対応を判断する推奨事項として残るか、あるいは特定のルールの自動化について組織が明示的にオプトインするものです。

完全なスコープ一覧と各コネクタがスキャンする内容については、Slack、GitHub、Microsoft 365の各コネクタページをご覧ください。