「“同意”を1回押しただけ」で、社内データに“静かな抜け道”ができる

Microsoft Entra IDのアプリ同意（OAuth consent）を統制して、Shadow ITと監査対応を同時に楽にする（情シス向け）

※本記事は一般的な情報提供を目的としており、個別案件の法的助言・紛争対応・代理交渉等を行うものではありません。必要に応じて弁護士等の専門家と連携してご検討ください。

1. 情シスが一番怖いのは「侵入」より“正規の同意”で権限が増えること

いまの攻撃は、「パスワードを盗む」よりも、ユーザー自身に“同意”を押させてAPI権限を得るほうが静かで、気づかれにくい場面があります。Microsoft Defender for Cloud Apps の公式ドキュメントでも、サードパーティアプリがユーザー情報やデータへのアクセス権を要求し、ユーザーが詳細を十分確認せずに「同意」を押してしまう、という現実が前提として説明されています。

そして山崎行政書士事務所のクラウド法務の観点でも、OAuth同意は「最も静かに権限が増える入口」であり、理想は“自動検知→自動隔離→証跡生成”まで寄せる、ただし自動化の境界線は「技術」ではなく「責任と説明可能性」で引くべき、という整理がされています。

2. 30秒で押さえる：同意は「認証」ではなく“認可（権限付与）”そのもの

Microsoftの同意モデルは大きく2系統あります。

• 委任されたアクセス（Delegated permissions）：ユーザーがサインインしている前提で、そのユーザーの代わりにデータへアクセス

• アプリ専用アクセス（Application permissions / app roles）：ユーザー不在でもアプリが単独で動ける（バックアップ等の用途でも使われるが、権限は強くなりがち）

Microsoft Learnは、委任アクセス／アプリ専用アクセスの違いと、どちらがどんな許可（スコープ／アプリロール）で制御されるかを整理し、**アプリケーション権限（アプリ専用）は“全データにアクセスし得る”**性質があることまで明確に説明しています。

情シスが見るべきポイントは1つだけです。

「誰が、どのアプリに、どの範囲の権限を与えたか」＝ “監査対象の変更”なのに、現場では“クリック1回”で通ってしまいがち。

3. 事故る組織の共通点：「ユーザー同意」を放置して、止め方も残し方も決めていない

Microsoft Learnでは、既定で「管理者同意が不要な権限」については、すべてのユーザーがアプリに同意できるとされています（例：自分のメールボックスへのアクセスを許可できる一方、全社の全ファイルを自由に読み書きするような権限には同意できない）。

この既定挙動のまま運用していると、情シスはだいたい次の質問で詰みます。

• 「うちのテナントで、外部アプリに同意してるユーザーは何人？」

• 「そのアプリ、誰が許可して、いつからアクセスできる状態？」

• 「撤回（revoke）した証跡は？」

• 「取引先審査で“同意統制”をどう説明する？」

4. 解決策は“止める”だけじゃない：止める＋通す＋監視する（4層で設計）

情シスの現実解は、次の4層を“セット”で組むことです。

第1層：ユーザー同意を「許可範囲つき」にする（または止める）

ユーザー同意は Entra 管理センター等で全ユーザーに対して構成でき、セキュリティリスク軽減のために同意を制限／無効化するガイダンスが示されています。

さらにMicrosoftは、悪意あるアプリにだまされるリスク軽減として、“検証済みの発行元（Verified publisher）”のアプリにのみ同意を許可することを推奨しています。

ただし「Verified publisher＝完全に安全」ではありません。発行者の確認は“いくつかの条件の1つ”であり、品質基準や認証取得を意味しない点も明記されています。

第2層：アクセス許可（権限）を“分類”し、許可ルールを作る

Entra ではアクセス許可を「低／中（プレビュー）／高（プレビュー）」に分類でき、同意ポリシーで「ユーザーが同意できる権限セット」を定義する用途が説明されています。

ここで地味に刺さるのが、最小サインインに必要な権限として openid profile email offline_access が挙げられ、**offline_access により“ユーザーがアプリを使わなくなってもアクセスを維持し得る”**点まで書かれていることです。（＝「同意＝一時的」ではなくなり得る、という話）

第3層：アプリ同意ポリシー（App consent policies）で「条件付き許可」を作る

2026年1月更新のMicrosoft Learnでは、アプリ同意ポリシーは「ユーザーが同意できるアプリ」を制御し、アプリがデータにアクセスする前に条件を満たすことを確認する仕組み、と整理されています。また、組み込み／カスタムポリシーを管理し、既定の同意ポリシーを設定したり、特定のユーザー／グループへ割り当てることもできる、とされています。ポリシーは包含／除外条件セットで構成され、条件として検証済み発行元の状態や要求されたアクセス許可などを扱えることも明記されています。

→ つまり「止めるか／通すか」を二択にせず、**“条件を満たすものだけ通す”**に寄せられます。

第4層：Defender for Cloud Appsで「見える化→禁止→監査」を回す

Defender for Cloud Apps は、OAuthアプリが要求するアクセス許可や、誰が承認したかを可視化し、情シスが「許可するアプリ／禁止するアプリ」を判断できると説明されています。さらに、管理者はアプリを承認済み／禁止済みとしてマークでき、禁止時にユーザー通知の有無も選べるなど、現場運用に寄った手順が提示されています。加えて、OAuth承認アクティビティを監査し、必要に応じてエクスポートして調査に使える点も明記されています。

そして “自動で止める”に踏み込むなら、OAuthアプリのポリシー（OAuth アプリ ポリシー）を作成して運用できる手順もあります。

5. 情シス向け：最短で「事故らない同意統制」に寄せる実装手順

手順1：まず“止め方”を決める（推奨は「制限＋申請」）

現場の落とし穴は「ユーザー同意を全部OFFにしたら、業務が止まってShadow ITが増えた」です。そこで現実解は次のどちらか（組織フェーズで選ぶ）です。

• A案：同意を“検証済み発行元＋低リスク権限のみ”に制限（業務影響を小さく）

• B案：ユーザー同意を原則OFF＋管理者同意ワークフローで申請受付（統制を強く）

手順2：管理者同意ワークフローを“窓口化”する（申請の行き場を作る）

ユーザー同意が無効な場合でも、管理者同意ワークフローを有効にすると、ユーザーが同意プロンプトから直接リクエストでき、管理者側は管理センターで要求を追跡し、応答できます。要求の結果は電子メール通知され、レビュー担当者への通知条件、そして監査ログの整理まで記載があります。

ポイント：情シスが抱えるのではなく、“レビュー担当者（業務責任者）”を明示して運用責任を分散する

手順3：同意を“Change管理”に落とす（証跡が出せる型にする）

山崎行政書士事務所の整理が非常に実務的で、Admin Consentは「一度通ると影響が長く残りやすい」ので、PR・承認・証跡のChange as Codeに落とす、という方針が示されています。「誰が・何のアプリに・どの権限を・いつ・なぜ」許可したかを提出物で即答できる状態をゴールに置くのが、監査・取引先審査で強いです。

手順4：Defender for Cloud Appsで“勝手な同意”を拾って止血する

OAuthアプリの一覧を継続監視し、怪しいものは禁止へ。必要に応じてユーザーへ通知も行う。加えて、OAuth承認アクティビティの監査・エクスポートを回せる体制にしておくと、「いつから／誰が／どの権限」が追えます。

手順5：不正同意が出た時のRunbookを“最初から”用意する

山崎行政書士事務所は、不正（または不要）なOAuth同意が出た際に、**止血（revoke）→追跡（ログ）→報告（説明責任）**を一気通貫で終わらせるRunbookを提示しています。また、自動化の境界線は「可逆性」で引き、削除・恒久変更は原則“人の承認”が必要という考え方も、情シス運用の事故率を下げます。

6. 監査・取引先に“刺さる”即答テンプレ（情シスがラクになる言い方）

• 「ユーザー同意は、**検証済み発行元／許可分類（低）**など条件付きで制限しています」

• 「管理者同意は、同意ワークフローで申請・レビュー・監査ログまで残します」

• 「OAuthアプリは Defender for Cloud Apps で可視化し、禁止・監査まで運用しています」

• 「不正同意時は Runbook により 止血→追跡→報告を定型化しています」

この4点が揃うと、情シスの説明が「頑張ってます」から「仕組みとしてこうです」に変わります。

7. 10分セルフチェック（Yesが揃わないと、次に燃えるのはここ）

• □ ユーザー同意の方針（許可／制限／無効）が決まっている

• □ 検証済み発行元を条件にするか、方針がある

• □ 低リスク権限の“分類”ができている（最低限 offline_access の意味を理解している）

• □ アプリ同意ポリシーで「条件付き許可」を設計できている

• □ 管理者同意ワークフローのレビュー担当者・通知・監査ログまで運用に落ちている

• □ Defender for Cloud AppsでOAuthアプリを監視し、禁止・監査・エクスポートができる

• □ 不正同意のRunbookがあり、止血と証跡化がセットになっている