Entra ID アプリケーション権限の悪用—仕組みと防御戦略

Entra ID のアプリケーション権限の悪用とは？

Entra ID のアプリケーション権限の悪用は、攻撃者がアプリケーションレベルの権限（アプリケーション権限、委任された権限、管理者同意済みスコープ）を活用したり、誤設定された OAuth の同意、漏えいしたクライアント シークレット/証明書、または悪用されたサービス プリンシパルを用いて、テナント内で特権操作を実行する場合に発生します。パスワードベースの侵害とは異なり、この手法は正当なプラットフォームの仕組み（OAuth トークン、アプリのロール、Graph API 呼び出し）を利用するため、悪意のある操作が通常のアプリケーション操作に見えることがよくあります。

アプリケーション権限の悪用はどのように機能しますか？

以下は、攻撃者が Entra ID のアプリケーション権限を悪用する際に用いる典型的な手法と段階を、手順ごとに分解したものです。

1. 最初の足場を確保する

攻撃者はまず、対象のクラウド テナントに関連する足がかりを何らかの形で取得します。一般的な侵入口には、フィッシング（委任されたユーザー同意を得るため）、侵害されたユーザー アカウント、リポジトリ/設定から漏えいしたアプリ クライアント シークレット、アプリの盗まれた証明書/秘密鍵、または弱い管理者同意のワークフローを悪用することなどがあります。

2. 登録済みアプリケーションと権限を特定する

侵入後、攻撃者はサービス プリンシパルとアプリケーション登録を列挙し、高い特権（権限）を持つアプリを特定します（例：Application.ReadWrite.All、Directory.ReadWrite.All、Mail.ReadWrite、Group.ReadWrite.All）。列挙は、Microsoft Graph のクエリ、Azure AD ポータルへのアクセス、または委任トークンを使ってエンタープライズ アプリと付与されたスコープを一覧化することで実施できます。

3. 悪用可能な同意および委任の経路を特定する

攻撃者は、管理者が同意したアプリ、委任スコープが過度に広いアプリ、暗黙的な付与（implicit grant）を許可するレガシー エンドポイント、または保護が不十分な機密クライアント認証情報（シークレット/証明書）を探します。特に、サインインしたユーザーを必要としないバックグラウンド アクセス（アプリケーション権限）を許可するアプリを重点的に狙います。

4. アプリの認証情報を窃取・流出する、または同意を悪用する

クライアントシークレットや証明書が発見可能である場合（パイプライン、リポジトリ、設定ファイル、またはアクセス権が弱い Key Vault など）には、攻撃者はそれらを抽出してトークンと交換します。委任された同意（delegated-consent）フローでは、攻撃者が特権ユーザーをだまして悪意あるアプリスコープ（app scopes）への同意をさせることがあります（同意フィッシング）。さらに、マルチテナントアプリの同意付与（consent-granting）機能を活用する場合もあります。

5. トークンを取得して特権アクションを実行する

盗まれた／悪用された認証情報、または付与された同意を使って、攻撃者は OAuth アクセストークンを要求します（アプリ権限のためのアプリケーショントークン、またはユーザーに代わっての委任トークン）。その後、Microsoft Graph または他の API を呼び出して、ユーザーの一覧を取得したり、メールを読み取ったり、OneDrive のファイルをダウンロードしたり、ディレクトリ オブジェクトを変更したり、バックドアを作成したりします（新しいアプリ登録やカスタムロール）。

6. 権限を昇格し、永続化し、横方向に移動する

アプリケーション権限を使うことで、攻撃者は新しいサービスプリンシパルを作成したり、資格情報を追加したり、ロールを割り当てたり、データを大規模に持ち出したりできます。アプリトークンが長期間有効になり得て、実行される操作も正当なものに見えることが多いため、攻撃者は持続性を維持しつつ、クラウドからオンプレミスの依存関係（例：アイデンティティ情報の同期、ハイブリッドコネクタの変更）へと移行できます。

✱ バリアント：同意（Consent）フィッシング & 不正なマルチテナント アプリ

特権ユーザーをだまして広範な権限を付与させます。攻撃者は一見無害に見えるアプリをホストし、危険なスコープを要求して、ソーシャルエンジニアリングにより管理者または特権ユーザーに同意（consent）させます。いったん同意が得られると、アプリはテナント全体で動作できます。不正なマルチテナント アプリは、多数のテナントから管理者の同意を収集するために使われることがあります。

レガシーの OAuth フローとインプリシット（implicit）グラントの悪用：古い OAuth フロー、または設定ミスのあるリダイレクト URI（redirect URI）によって、トークンの窃取や同意のバイパスが可能になります。攻撃者はこれらを悪用し、対話型ユーザーフローの保護なしで委任トークン（delegated tokens）を取得します。

攻撃フロー図

例：組織の視点

組織の視点では、これは次のように見えます。攻撃者は Contoso Corp の管理者をフィッシングし、正当な分析ツールに見えるアプリに同意（承認）させます。アプリが管理者の同意を受けると、攻撃者はアプリの資格情報をアプリケーショントークンと交換し、Microsoft Graph を使ってメールボックスを列挙して OneDrive から機密文書をダウンロードします。その後、アクセスを維持するために、長寿命の証明書を備えたセカンダリのサービス プリンシパルを登録し、長期にわたるデータ流出とテナントの変更を可能にします。

アプリケーション権限の悪用例

アプリケーション権限の悪用による影響

Entra ID のアプリケーション権限の悪用は、重大な結果を招きます。具体的には、テナントの侵害、大量のデータ流出、不正なアカウントおよびサービス プリンシパルの作成、オンプレミスのリソースへの横方向の移動、そして検知が難しい長期的な持続（永続化）です。

財務的影響

攻撃者は、知的財産、顧客の PII、または財務データを持ち出して、不正行為、規制当局の罰金、身代金要求、または是正コスト（フォレンジック、法務、通知）につながる可能性があります。クラウドリソースの悪用（例：クリプトマイニング）によっても、思いがけない請求が発生することがあります。

業務の中断

ディレクトリ オブジェクト、グループ メンバーシップ、またはアイデンティティ同期を改ざんすると、認証フローが中断されたり、重要なアプリで障害（ダウンタイム）が発生したり、緊急のローテーションや連携（インテグレーション）の再設定が必要になったりする可能性があります。

風評被害

悪用されたアプリ権限に紐づくテナントの侵害やデータ漏えいは、顧客の信頼を損ない、ネガティブな報道を招き、パートナー関係にも悪影響を及ぼす可能性があります。

法的および規制上の影響

規制対象データ（PHI、財務記録）の不正な露出は、GDPR、HIPAA、またはその他のコンプライアンス調査、罰金、ならびに訴訟の可能性につながることがあります。

アプリ権限の悪用で狙われやすいもの：リスクがあるのは誰？

過剰な権限を付与されたエンタープライズアプリケーション

Directory.* またはテナント全体の Application 権限を付与されたアプリは、アイデンティティとリソース全体にわたって一括操作を可能にするため、高価値の標的になります。

マルチテナントまたは顧客向けの連携

広いスコープを要求するサードパーティの SaaS アプリやマルチテナント アプリは、管理者が同意した場合、またはアプリ自体が悪意を持っている場合に悪用される可能性があります。

漏えいする DevOps/CI パイプライン

ソース管理に誤ってコミットされたクライアント シークレットや証明書、セキュアでないストレージに保存されている場合、または CI ログから参照できる場合は、機密のクライアントが危険にさらされます。

レガシー OAuth 構成と条件付きアクセスの抜け漏れ

レガシーの認証フローを使用するアプリ、または厳格な条件付きアクセス（Conditional Access）ポリシーがないテナント（例：同意時に MFA なし、管理者同意のワークフローなし）は、悪用されやすくなります。

期限切れまたは監視されていないサービス プリンシパル（Service Principals）

有効な認証情報（クレデンシャル）が残っている古い、または孤立したアプリ登録は、持続的な攻撃ベクトルです。攻撃者は好きなときに余裕をもって解読（クラック）できます。

リスク評価

アプリケーション権限の悪用を防ぐ方法

防止は多層的に行います。影響範囲を縮小し、アプリ認証を強化し、人為的な同意ミスを最小限に抑えましょう。

アプリと同意の健全性

• 最小権限スコープを徹底します。必要な Microsoft Graph スコープだけを最小限で要求し、可能な限りアプリケーション権限より委任（delegated）を優先してください。
• 管理者の同意ワークフローを利用します。高い特権を持つアプリでは、正当な理由の提示と複数承認者による管理者同意（admin consent）を必須にしてください。
• アプリの登録や同意を行える対象を制限します。アプリ登録と管理者の同意は、少数の審査済みグループに限定してください。
• 未使用のアプリを確認して削除します。サービス プリンシパルとアプリ登録を定期的に監査し、孤立しているものや不要なものを削除してください。

認証情報とシークレットを保護する

• 機密性の高いクライアントには、クライアント シークレットの代わりに証明書ベース（非対称）の認証を優先してください。証明書は露出しにくく、安全にローテーションできます。
• シークレットは管理されたボールト（Azure Key Vault）に、厳格な RBAC とマネージド ID のアクセスで保存してください。ソースコードや平文の設定には決して保存しないでください。
• クライアントのシークレットと証明書のローテーションを自動化し、運用上可能な範囲で有効期限を短く設定します。

Conditional Access & Session Controls

• アプリのトークン発行には Conditional Access を必須にしてください。リスクの高いサインインをブロックし、準拠したデバイスを要求し、適用可能な場合は委任フロー（delegated flows）に対して MFA を強制します。
• リスクの高いシグナルが表示されたら、継続的なアクセス評価（continuous access evaluation）を使用してトークンを無効化（取り消し）します。

Application Design & Monitoring

• 最小権限と透明性を重視してアプリを設計します。同意のみ（consent-only）機能ときめ細かなスコープを実装し、各権限が必要な理由を文書化してください。
• Graph API の利用をログに記録し、監視します。異常なパターン（大量のメールボックスのダウンロード、ユーザーの大量列挙、新しいアプリ/サービス プリンシパルの作成）を検知したらアラートを出してください。
• エンタイトルメント管理とポリシーを使って、どのアプリがアプリケーション権限を利用できるかを制限します。

Netwrix がどのように支援できるか

Netwrix Identity Threat Detection & Response（ITDR）は、高リスクなアプリ登録、異常な同意付与、疑わしい Graph API のアクティビティを継続的に監視することで、Entra ID のアプリケーション権限の濫用に対する防御を強化します。未承認の特権昇格を早期に検知し、アラート通知や侵害された権限の取り消しなどの対応アクションを自動化することで、Netwrix ITDR は滞留時間（dwell time）を最小限に抑え、アイデンティティ主導の攻撃による影響範囲（blast radius）を縮小するのに役立ちます。ハイブリッド Active Directory と Entra ID 全体にわたる包括的な可視性により、組織は最小権限を徹底し、高リスクなサービス プリンシパルを保護し、侵害の兆候（indicators of compromise）を迅速に調査できます。これにより、Identity から始まるデータセキュリティを実現します。

検出、防止（緩和）、対応の戦略

検出

1. 不審な Graph API のパターンを監視してください。たとえば Applications.ReadWrite.All や Users.ReadAll の急増、または大容量ファイルのダウンロード。
2. 新しいアプリ登録や新しい認証情報に対してアラートを出してください。サービス プリンシパルが作成されたとき、認証情報が追加されたとき、または同意が付与されたときに通知します。
3. 管理者の同意イベントと承認者を追跡してください。不審な場所や時間からの予期しない管理者同意はフラグを立てます。
4. 異常なトークン発行を検出します。未知のクライアントが要求したトークン、または古い資格情報を使用して要求されたトークンは調査してください。
5. 欺けん（デセプション）を活用します。デコイのアプリやサービスプリンシパルを作成し、それらへのアクセスを監視してください。

対応

• 侵害された資格情報を直ちに無効化（リボーク）します。クライアントシークレットをローテーションし、証明書をリボークし、漏えいした資格情報をすべての場所から削除してください。
• 悪意のあるアプリの同意を削除し、問題のあるサービスプリンシパルを無効化します。権限を削除し、アプリを無効化して、これ以上の API アクセスをブロックしてください。
• トークンの無効化を強制する：可能な範囲で発行済みの更新（refresh）トークンおよびアクセス（access）トークンを無効化し、再認証を必須にします。
• テナント全体で監査を実施する：役割、グループのメンバーシップ、委任された権限、および二次的な影響の可能性がないかプロビジョニングコネクタを確認します。
• 横移動の痕跡を調査する：作成されたアカウント、ロールの割り当て、異常なアプリ登録、または変更された条件付きアクセス（conditional access）ポリシーがないか確認します。

緩和

• アイデンティティに対して Zero Trust を採用する：すべての要求を継続的に検証し、どのアプリやアイデンティティが実行できることを制限します。
• 最小権限の自動化を使いましょう。自動化やアプリには必要なリソースへのアクセスだけを許可し、高リスクなタスクは専用で監査可能なサービス原則（service principles）に分離します。
• 強固なサプライチェーン対策を実施しましょう。リポジトリ、CIパイプライン、デプロイ成果物（deployment artifacts）をスキャンして漏えいしたシークレットを検知し、シークレットスキャンをPRチェックに統合します。

業界別の影響

攻撃の進化と今後のトレンド

• 同意（Consent）フィッシングが成熟しています。ソーシャルエンジニアリングに、見栄えの良いアプリページを組み合わせることで、管理者の同意が成功する確率が高まります。
• アプリの偵察の自動化：ツールが現在、テナントを大規模にスキャンし、高リスクのアプリ、漏えいした認証情報、devops のシークレットを見つけます。
• 有効期限が長い非対話型の認証情報は依然として魅力的です。——証明書の保護とローテーションが標準的な防御策になりつつあります。
• クラウドからオンプレミスへのアイデンティティ接続（ブリッジ）：攻撃者は Entra ID の悪用にハイブリッド同期コネクタを組み合わせ、オンプレミスの AD への到達範囲を広げるケースが増えています。
• AI 支援の偵察：自動化されたシステムがテナントのメタデータを分析し、大きな影響を与える権限に最短で到達する経路を見つけます。

主要な統計データとインフォグラフィック

（強調のための架空の指標—利用可能な場合は、ご自身のテレメトリに置き換えてください。）

• 事故の多くは、CI/CDにおけるシークレットの漏えいや誤った管理に関係しています。

• 近年、クラウド侵害の中で一定の割合を占めていたのが、同意型フィッシング（Consent phishing）キャンペーンです。

• 多くの組織では、アプリの権限やサービスプリンシパルに対する定期的な監査が不足しています。

最後に

Entra ID のアプリケーション権限を悪用することは非常に強力です。正当なプラットフォーム機能を利用するため、悪意のある行為が通常の自動化に紛れ込みます。防御の体制は、予防的コントロール（最小権限、シークレット保護、同意のガバナンス）、検知（Graph の監視、アプリのライフサイクルイベントに関するアラート）、そして迅速な対応（資格情報の無効化、同意の削除）を組み合わせるべきです。アプリ権限の監査をプログラム化して継続的に行い、さらに誰が同意したりアプリを登録できるのかについて厳格な運用上の制御を実施することで、攻撃対象領域（攻撃面）を大幅に減らせます。