Google WorkspaceマーケットプレイスやGitHubマーケットプレイスからアプリをインストールすると、会社のメール、ファイル、カレンダー、コードリポジトリ、CIワークフロー、組織設定、シークレットへのアクセス権をサードパーティに付与することになります。マーケットプレイスへの掲載は、こうしたアプリが承認済みであるかのような印象を与えます。しかしその背後にあるOAuth認可は、記載された機能を超えてビジネスシステムへと深く及んでいることが少なくありません。
アイデンティティセキュリティ企業Offroadが手がけるOAuth調査プロジェクト「OhAuth」は、公開されているOAuthアプリ一覧2,890件を対象に監査を実施しました。内訳はGoogle Workspaceマーケットプレイスが1,595件、GitHubマーケットプレイスが1,295件です。両プラットフォームのインストール件数の合計は少なくとも43億9,000万件に上るとされています。この数値は下限値であり、マーケットプレイスのインストール数表示は「100万件以上」のような概数で示されるため、実際の件数はさらに多い可能性があります。
掲載アプリの約3分の1にリスクシグナル
監査対象の918件（全体の32%）のアプリに、構造的なリスクシグナルが1つ以上確認されました。リスクシグナルとしては、アプリの機能に対して過剰なスコープ、書き込みアクセス権を持つAI機能、発行元ドメインへの脅威情報フラグ、閉鎖済みの発行元ウェブサイト、購入可能な状態になっている発行元ドメイン、著名ブランドに似た名称をサードパーティが発行しているケースなどが挙げられます。この918件のインストール数の合計は下限値で18億5,000万件に達します。127件は2つ以上のシグナルを持ち、16件は3つ以上のシグナルを持っています。
今回の監査では、1,391件のWorkspaceアドオンが確認され、インストール件数の下限値は30億7,000万件に上りました。Google Workspaceでは、281件のアプリが14億7,000万件のインストール全体でDriveへの幅広いアクセス権を保有し、316件が10億2,000万件のインストール全体でSheetsへのアクセス権を、220件が8億1,820万件のインストール全体でGmailへのアクセス権を保有しています。GitHubでは、346件のアプリがコードへのアクセス権を持ち、183件がアクション・ワークフロー・ランナーへのアクセス権を、107件が組織設定へのアクセス権を保有しています。
用途を超えた過剰な権限
インストール件数の観点で最大の問題となっているのは、アプリが謳っている機能と実際にリクエストするスコープの乖離です。677件のアプリが自身の機能を超えた権限を少なくとも1つリクエストしており、インストール件数の合計は下限値で18億2,000万件に上ります。うち266件は、用途外の高レベルDriveアクセス権を持ち、12億6,000万件のインストールに影響しています。
こうした乖離の一部は、OAuthスコープの仕様自体に起因しています。GoogleはSheets、Docs、Calendarに対して「削除なしの編集」スコープを提供していないため、1つのスプレッドシートへの書き込みが必要なアプリであっても、ユーザーがアクセスできるすべてのスプレッドシートの削除も許可するスコープを取得しなければならない状況があります。また、アプリの機能とまったく関係のないスコープが付与されているケースもあります。
監査報告書にはいくつかの具体例が示されています。800万件以上インストールされている選択式フォーム補助アプリが、用途外のDrive・Forms・Sheetsスコープを保有しています。6万人のユーザーに認可されているGmail自動返信アプリが、Drive・Docs・Calendar・Gmailのスコープを保有しています。インストール件数が380万件を超えるURLからDriveへの保存アプリが、ユーザーのDrive内のすべてのファイルを閲覧・編集・作成・削除する権限を持っています。
リスクは、広範な権限が承認された時点で顕在化します。発行元が侵害された場合、すでに付与された権限がそのまま悪用され、正規のアプリが多くの顧客環境にわたるサプライチェーン攻撃の侵入経路となる可能性があります。
スコープの乖離が生まれる背景
フラグが立てられた677件のアプリは、2つのスコープカテゴリに不均等に分布しており、プラットフォームによってもパターンが異なります。Offroadの最高技術責任者（CTO）であるPhilip Shteyn氏は、問題の核心について次のように説明しています。
「両マーケットプレイス全体を見ると、問題の大部分はアプリが完全に無関係なアクセスを求めているケースではありません。アプリの機能とは関連しているものの、必要以上に広いアクセスを求めているケースが大半です」とShteyn氏はHelp Net Securityに語りました。
Google Workspaceでは、フラグが立てられたケースの約90%が「カテゴリは正しいが、アクセスが過剰」なグループに該当するとShteyn氏は述べています。Driveファイルを扱う必要があるアプリが、より限定的なDrive権限で事足りるにもかかわらず、広範なDriveアクセスをリクエストするといったケースです。機能と無関係なスコープをリクエストするケースは全体の約10%にとどまります。
Shteyn氏はスコープの選択肢についても指摘しています。「Google Workspaceの多くのケースでは、より限定的なスコープが技術的には存在します。アプリがそれを使用していないだけです」と同氏は述べました。Googleが十分に限定されたスコープを提供していないケースは、より小さなサブセットを形成しています。
GitHubでは分布がより均等で、フラグが立てられたケースのうち約60%は機能に関連しながらも過剰なアクセスであり、約40%は宣言された目的と無関係なアクセスとなっています。
オフラインになる発行元インフラ
OAuthは、発行元が認可の有効期間中も連絡可能かつ責任ある状態を維持することを前提としています。今回の監査では、この前提に反するケースが確認されました。206件のアプリの発行元ドメインが閉鎖されており、85の異なる発行元ドメインに属する89件のアプリのドメインが、標準的なレジストラで購入可能な状態になっています。休眠ドメインを登録した者は、有効なSPF、DKIM、DMARCレコードを使って発行元のアイデンティティでメールを送信したり、アカウント回復フローを悪用してマーケットプレイスアプリを乗っ取ったりすることができます。また、36件のアプリの発行元ドメインが、商用脅威情報ブロックリストにフラグを立てられています。
18万以上の組織に認可されているあるGoogle Workspaceバックアップ製品は、発行元ドメインが5つの商用脅威情報フィードにフラグを立てられています。このアプリのOAuth認可は、対象テナントのすべてのファイル、メール、カレンダーイベント、連絡先に対する読み取り・編集・削除の権限を持っています。
一度きりの審査としてのマーケットプレイスレビュー
GoogleとGitHubは、掲載を公開する前に発行元、ドメイン、OAuthスコープを対象とした審査を実施しており、機密性の高いスコープにはセキュリティ評価も適用されます。しかし、こうしたリスクシグナルが残り続けているのは、審査が主に承認時点でのみ機能するためです。
「最大の問題は、マーケットプレイスのレビューが主に承認時点でのチェックである点です」とShteyn氏は述べました。
掲載が公開された後、発行元ドメインは有効期限切れになったり、購入可能な状態になったり、元の開発者の管理を離れたりすることがあります。それでもアプリは引き続き掲載され、既存のOAuth認可はそのまま有効であり続けます。「確認済みのマーケットプレイス掲載情報と、その審査対象となった実際の発行元資産は、後になってかい離することがあります」とShteyn氏は説明しました。「私たちが観察した限り、承認後にそのかい離を検出するための継続的な再確認が十分に行われていないようです。」
Offroadは公表の2週間前にGoogleとGitHubに調査結果を報告しました。両プラットフォームは回答しましたが、いずれもこの調査結果を即時のプラットフォーム対応を要するセキュリティ上の脆弱性とは判断しませんでした。
解消されないリスクシグナル
購入可能な発行元ドメインや脅威情報フラグの数値は、特定時点での観測結果です。Offroadは監査および開示期間を通じて対象アプリを継続的に監視しました。開示から2週間が経過した時点で、報告されたアプリはいずれも修正・変更・削除されていませんでした。
Shteyn氏は測定上の限界についても言及しています。「マーケットプレイス全体を対象に、こうしたリスクシグナルが未解消のまま維持される平均期間を測定する縦断的研究は実施していません。この監査はあくまで特定時点での評価を主目的としたものです」と同氏は述べました。
それでも、継続的な監視が示す方向性は一貫していました。「アプリは一度承認されると、発行元ドメインが後から失効したり、購入可能になったり、その他のリスクシグナルが発生したりしても、長期間にわたって掲載され続けることがあります」とShteyn氏は語りました。
書き込みアクセス権を持つAIアプリ
49件のAI搭載アプリが広範な書き込みアクセス権を保有しており、インストール件数の下限値は8,160万件に上ります。ユーザーに代わってメールを送信する権限を持つAIアプリは、固有のリスクプロファイルを持っています。従来のアプリは、クリックやルールなどユーザーの明確なアクションに基づいてメールを送信します。一方、AIアプリはモデルの出力に基づいて、何を、いつ、誰に送るかを独自に判断することができます。同意画面には権限が表示されますが、その権限が使用されるまでにモデルがどれほどの制御を持つかは示されません。
管理者が取るべき対策
Offroadは、OAuthの認可をアイデンティティリスク管理の一環として扱うことを推奨しています。権限の広い認可には、業務上の担当者、正当化されたスコープ設定、使用状況の監視、更新サイクル、および取り消し経路が必要です。同社は、すべての認可を棚卸しすること、高権限のアクションを継続的に監視すること、AIアプリと従来のアプリを分けて管理すること、最もリスクの高い認可を定期的にローテーションすることを推奨しています。マーケットプレイスへの掲載はレビューの出発点に過ぎず、スコープ・発行元・目的・使用状況・業務上の担当者を評価するテナントレベルのセキュリティ評価は、別途実施する必要があります。
翻訳元: https://www.helpnetsecurity.com/2026/06/04/oauth-marketplace-apps-audit/
