アプリ同意付与の調査

この記事では、アプリ同意攻撃を特定して調査し、情報を保護し、さらなるリスクを最小限に抑えるためのガイダンスを提供します。

この記事は、次のセクションで構成されています。

• 前提条件: 調査を開始する前に完了する必要がある具体的な要件について説明します。 たとえば、有効にする必要があるログ、必要な役割とアクセス許可などです。
• ワークフロー: この調査を実行するために従う必要がある論理フローを示します。
• チェックリスト: フロー チャートの各ステップのタスクの一覧が含まれます。 このチェックリストは、実施した手順を確認するために、または単純に自分の品質ゲートとして、規制の厳しい環境で役立ちます。
• 調査手順: この特定の調査に関する詳細なステップ バイ ステップ ガイダンスが含まれています。
• 復旧: 不正なアプリケーション同意付与攻撃から復旧する方法、またはその攻撃を緩和する方法について、大まかな手順を示します。
• リファレンス: より多くの読み物と参考資料が含まれます。

前提条件

ここでは、アプリケーション同意付与の調査を実行する場合に完了する必要がある一般的な設定と構成について説明します。 調査を開始する前に、「同意許可の種類」に記述されている記事で、同意許可の種類を確認してください。

顧客データ

調査プロセスを開始するには、次のデータが必要です。

• 侵害インジケーター (IoC) の詳細
• インシデントに気付いた日時
• 日付範囲
• 侵害されたアカウントの数
• 侵害されたアカウントの名前
• 侵害されたアカウントのロール
• アカウントに高い特権が付与されているかどうか (GA Microsoft Exchange、SharePoint)
• インシデントに関連するエンタープライズ アプリケーションがあるかどうか
• ユーザーの代わりにデータへのアクセス許可を要求したアプリケーションについてユーザーから報告があったかどうか

システム要件

次のインストールと構成要件を完了していることを確認します。

• AzureAD PowerShell モジュールがインストール済みである
• スクリプトを実行するテナントの全体管理者権限を持っている。
• スクリプトの実行に使用するコンピューターのローカル管理者の役割が割り当てられている。

Note

Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となります。 詳細については、非推奨の最新情報を参照してください。 この日以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正プログラムに限定されます。 非推奨になるモジュールは、2025 年 3 月 30 日まで引き続き機能します。

Microsoft Entra ID (旧称 Azure AD) を使用するには、Microsoft Graph PowerShell に移行することをお勧めします。 移行に関する一般的な質問については、「移行に関する FAQ」を参照してください。 注: バージョン 1.0.x の MSOnline では、2024 年 6 月 30 日以降に中断が発生する可能性があります。

AzureAD モジュールをインストールする

このコマンドを使用して、AzureAD モジュールをインストールします。

Install-Module -Name AzureAD -Verbose

Note

信頼されていないリポジトリからモジュールをインストールするかどうか確認するダイアログが表示されたら、「Y」と入力し、Enter キーを押します。

MSOnline PowerShell モジュールをインストールする

1. 昇格された特権を使用して Windows PowerShell アプリを実行します (管理者として実行)。

2. このコマンドを実行して、PowerShell が署名されたスクリプトを実行できるようにします。

   Set-ExecutionPolicy RemoteSigned
   

3. このコマンドを使用して、MSOnline モジュールをインストールします。

   Install-Module -Name MSOnline -Verbose
   

   Note

   信頼されていないリポジトリからモジュールをインストールするかどうか確認するダイアログが表示されたら、「Y」と入力し、Enter キーを押します。

GitHub から AzureADPSPermissions スクリプトをダウンロードする

1. Get-AzureADPSPermissions.ps1 スクリプトを、GitHub からスクリプトの実行元となるフォルダーにダウンロードします。 出力ファイル "permissions.csv" もこの同じフォルダーに書き込まれます。

2. 管理者として PowerShell インスタンスを開き、スクリプトを保存したフォルダーを開きます。

3. Connect-AzureAD コマンドレットを使用してディレクトリに接続します。 次に例を示します。

   Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"
   

4. この PowerShell コマンドを実行します。

   Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation
   

   このコマンドを使用して、AzureAD セッションを切断します。

   Disconnect-AzureAD
   

同意の用語

アプリケーション同意付与とは

同意とは、アプリケーションがユーザーの代わりに保護されたリソースにアクセスすることを承認するプロセスのことです。 管理者またはユーザーは、組織または個人のデータへのアクセスを許可するように同意を求められることがあります。

アプリケーションには、特定のユーザーに基づいて、または組織全体のために、データへのアクセス権が付与されます。 これらの同意は、攻撃者が環境に常駐し、機密データにアクセスするために、悪用される可能性があります。 これらの種類の攻撃は、不正同意付与と呼ばれます。これは、フィッシング メール、パスワード スプレーによるユーザー アカウントの侵害を通じて、または攻撃者が正当なユーザーとしてアプリケーションを登録した場合に発生することがあります。 管理者アカウントが侵害された場合、登録と同意付与は、単に 1 人のユーザーではなく、テナント全体が対象となります。

アプリケーションが組織のデータにアクセスできるようにするには、そのためのアプリケーションのアクセス許可をユーザーに付与する必要があります。 異なるアクセス許可によって、さまざまなレベルのアクセスが可能になります。 既定では、すべてのユーザーが、管理者の同意を必要としないアクセス許可のアプリケーションに同意することが許可されています。 たとえば、既定では、ユーザーは、アプリが自分のメールボックスにアクセスすることに同意して許可できますが、アプリが組織内のすべてのファイルに自由にアクセスして読み取りと書き込みを行うことに同意して許可することはできません。

Note

ユーザーがアプリにデータへのアクセスを許可できるようにすることで、ユーザーは便利なアプリケーションを簡単に取得し、生産性を高めることができます。 ただし、この構成が入念に監視および制御されていない場合、状況によっては、これがリスクとなる可能性があります。

組織に代わって同意を実行できるロール

テナント全体の管理者の同意を許可できるようにするには、少なくとも次のいずれの役割としてサインインする必要があります。

• アプリケーション管理者
• クラウド アプリケーション管理者

同意の種類

• 管理者 - (組織の代理として) 管理者が同意を実行したことを示します。
• 個々のユーザー - ユーザーが同意を実行し、そのユーザーの情報にのみアクセスできることを示します。
• 指定可能な値
  • AllPrincipals - テナント全体が対象となる管理者による同意
  • Principal - 個々のユーザーによる同意で、そのアカウントに関連するデータのみが対象

同意とアクセス許可

同意を実行する実際のユーザー エクスペリエンスは、ユーザーのテナントで設定されているポリシー、ユーザーの権限の範囲 (または役割)、クライアント アプリケーションが要求するアクセス許可の種類によって異なります。 つまり、そのアプリケーション開発者とテナント管理者は、同意エクスペリエンスの一部を制御できます。 管理者は、テナントでの同意エクスペリエンスを制御するために、テナントまたはアプリに対するポリシーを柔軟に設定および無効にすることができます。 アプリケーション開発者は、どのような種類のアクセス許可を要求するか、およびユーザーの同意フローまたは管理者の同意フローをユーザーにガイドするかどうかを決定できます。

• ユーザーの同意フロー - 現在のユーザーについてのみ同意を記録する目的で、アプリケーション開発者がユーザーを認可エンドポイントに直接アクセスさせる場合。

• 管理者の同意フロー - テナント全体についての同意を記録する目的で、アプリケーション開発者がユーザーを管理者の同意エンドポイントに直接アクセスさせる場合。 管理者の同意フローを適切に動作させるために、アプリケーション開発者は、アプリケーション マニフェストの RequiredResourceAccess プロパティにすべてのアクセス許可をリストする必要があります。

委任されたアクセス許可とアプリケーションのアクセス許可

委任されたアクセス許可は、サインイン済みユーザーが存在し、管理者またはユーザーが同意を適用できるアプリで使用されます。

"アプリケーションのアクセス許可" は、サインイン済みユーザーの存在なしで実行されるアプリで使用されます。 たとえば、バックグラウンド サービスまたはデーモンとして実行されるアプリです。 アプリケーションのアクセス許可に同意できるのは、管理者のみです。

詳細については、以下を参照してください:

• 特定のアプリケーションの管理者承認のための管理者同意ワークフロー
• 発行元検証プログラム
• エンド ユーザーがアプリケーションに同意する方法を構成する

リスクの高いアクセス許可の分類

システムには (少なくとも) 数千のアクセス許可があり、これらのすべてを一覧表示または解析することは不可能です。 下の一覧に、一般的に悪用されるアクセス許可、および悪用された場合に致命的な影響を及ぼすその他のアクセス許可を示します。

次の "ルート" となる委任された (アプリとユーザーの) アクセス許可が、同意フィッシング攻撃で悪用されたことを Microsoft は総じて確認しています。 ルートは、トップ レベルと同じです。 たとえば、Contacts.* は、Contacts アクセス許可のすべての委任アクセス許可 (Contacts.Read、Contacts.ReadWrite、Contacts.Read.Shared、Contacts.ReadWrite.Shared) を含めることを意味します。

1. Mail.* (Mail.Send は含まれるが、Mail.ReadBasic* は含まれない)
2. 取引先担当者。 *
3. MailboxSettings.*
4. People.*
5. Files.*
6. Notes.*
7. Directory.AccessAsUser.All
8. User_Impersonation

上記の一覧の最初の 7 つのアクセス許可は、Microsoft Graph および Azure Active Directory (Azure AD) Graph や Outlook REST などの "レガシ" API が対象です。 8 番目のアクセス許可は、Azure Resource Manager (ARM) 用であり、この包括的な偽装スコープを使用して機密データを公開する API で危険となる可能性があります。

Microsoft インシデント対応チームによる確認では、攻撃者は同意フィッシング攻撃の 99% で、最初の 6 つのアクセス許可を組み合わせて使用していました。 ほとんどのユーザーは、Mail.Read や Files.Read の委任バージョンをリスクの高いアクセス許可とは考えていませんが、この攻撃は一般に非常に広範であり、危険なアクセス許可に実際に同意できる管理者に対するスピア フィッシングではなく、エンド ユーザーをターゲットとしています。 これらの "クリティカルな" レベルの影響があるアクセス許可を使用するアプリを確認することをお勧めします。 アプリケーションに悪意がなくても、悪意のあるユーザーがアプリ ID を侵害した場合には、組織全体が危険にさらされる可能性があります。

リスクが最も高いアクセス許可を次に示します:

• 上記のすべてのアクセス許可のアプリケーション アクセス許可 (AppOnly/AppRole) バージョン (該当する場合)

次のアクセス許可の委任および AppOnly バージョン:

• Application.ReadWrite.All
• Directory.ReadWrite.All
• Domain.ReadWrite.All*
• EduRoster.ReadWrite.All*
• Group.ReadWrite.All
• Member.Read.Hidden*
• RoleManagement.ReadWrite.Directory
• User.ReadWrite.All*
• User.ManageCreds.All
• 書き込みアクセスを許可する他のすべての AppOnly アクセス許可

リスクが最も低いアクセス許可の一覧を次に示します:

• User.Read
• User.ReadBasic.All
• Open_id
• 電子メール
• プロフィール
• Offline_access (この "リスクが最も低い" リストの他のアクセス許可とペアにした場合に限る)

アクセス許可の表示

1. アクセス許可を表示するには、エンタープライズ アプリケーションで [登録] 画面に移動します。

   

2. [API アクセス許可の表示] を選択します。

   

3. [アクセス許可の追加] 選択します。次の画面が表示されます。

   

4. [Microsoft Graph] を選択して、さまざまな種類のアクセス許可を表示します。

   

5. 登録済みアプリケーションで使用されているアクセス許可の種類 ([委任されたアクセス許可] または [アプリケーションのアクセス許可]) を選択します。 上の図では、[アプリケーションのアクセス許可] が選択されています。

6. EduRoster など、リスクが高いアクセス許可のいずれかを検索できます。

   

7. [EduRoster] を選択し、アクセス許可を展開します。

   

8. これで、これらのアクセス許可を割り当てることや確認することができます。

   詳細については、Graph のアクセス許可に関する記事を参照してください。

ワークフロー

[]

さらに、以下を実行できます。

• アプリ同意付与やその他のインシデント対応のプレイブックのワークフローを PDF としてダウンロードする。
• アプリ同意付与やその他のインシデント対応のプレイブックのワークフローを Visio ファイルとしてダウンロードする。

チェック リスト

このチェックリストを使用して、アプリケーション同意付与の検証を実行します。

• 侵害インジケーター (IoC)

  次の侵害インジケーター (IoC) を確認します。

  • インシデントに気付いた日時
  • インシデントの日付範囲 (ゴール ポストまでの距離はどのくらいですか?)
  • 侵害されたアカウントの数
  • 侵害されたアカウントの名前
  • 侵害されたアカウントのロール
  • 侵害されたアカウントは高い特権が付与されているか、標準ユーザーであるか、またはそれらの組み合わせであるかどうか

• ロール

  これらのロールが割り当てられている必要があります。

  • スクリプトの実行元となるコンピューターのローカル管理者の役割

• PowerShell 構成

  以下の手順を使用して PowerShell 環境を構成します。

  1. Azure AD PowerShell モジュールをインストールします。
  2. 昇格された特権を使用して Windows PowerShell アプリを実行します。 (管理者として実行します)。
  3. 署名済みスクリプトを実行するように PowerShell を構成します。
  4. Get-AzureADPSPermissions.ps1 スクリプトをダウンロードします。

• 調査のトリガー

  • アカウントの侵害
  • テナントでアプリ同意設定が変更された
  • アラート/監査イベントの状態の理由として "危険なアプリケーション" が検出された
  • 外見が通常と異なるアプリケーションに気付いた

また、アプリ同意付与やその他のインシデント プレイブックのチェックリストを Excel ファイルとしてダウンロードすることもできます。

調査手順

次の 2 つの方法を使用して、アプリケーション同意付与を調査できます。

• Azure portal
• PowerShell スクリプト

Note

Azure portal を使用した場合に限り、過去 90 日間の管理者同意付与を表示することができます。そのため、攻撃者登録の調査手順を減らすためだけに、PowerShell スクリプト メソッドを使用することをお勧めします。

方法 1 – Azure portal を使用する

Microsoft Entra 管理センターを使用して、個々のユーザーがアクセス許可を付与したアプリケーションを見つけることができます。

1. Azure Portal に管理者としてサインインします。
2. [Microsoft Entra ID] アイコンを選択します。
3. [ユーザー] を選択します。
4. 確認するユーザーを選択します。
5. [アプリケーション] を選択します。
6. ユーザーに割り当てられているアプリケーションと、それらのアプリケーションが持つアクセス許可の一覧を確認できます。

方法 2 - PowerShell を使用する

次のような、不正同意付与の調査に使用できる PowerShell ツールがいくつかあります。

• HAWK ツール
• AzureAD インシデント対応モジュール
• GitHub からの Get-AzureADPSPermissions.ps1 スクリプト

PowerShell は非常に簡単なツールです。このツールでは、テナントで何も変更する必要がありません。 ここでの調査は、不正同意付与攻撃のパブリック ドキュメントに基づいています。

Get-AzureADPSPermissions.ps1 を実行して、テナント内のすべてのユーザーのすべての OAuth 同意付与と OAuth アプリを .csv ファイルにエクスポートします。 「前提条件」セクションを参照して、Get-AzureADPSPermissions スクリプトをダウンロードして実行します。

1. 管理者として PowerShell インスタンスを開き、スクリプトを保存したフォルダーを開きます。

2. 次の Connect-AzureAD コマンドを使用して、ディレクトリに接続します。 次に例を示します。

   Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"
   

3. この PowerShell コマンドを実行します。

   Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation
   

4. スクリプトが完了したら、このコマンドを使用して Microsoft Entra セッションを切断することをお勧めします。

    Disconnect-AzureAD
   

   Note

   接続のほか、サイズと構成されているアクセス許可によっては、スクリプトが完了するまで数時間かかる場合があります。

5. このスクリプトにより、Permissions.csv という名前のファイルが作成されます。

6. このファイルを開き、フィルターまたは書式設定によってデータをテーブルにまとめ、.xlxs ファイルとして保存します。

   次の図は、出力の列ヘッダーを示しています。

   

7. ConsentType 列 (G) で、値 AllPrinciples を検索します。 AllPrincipals アクセス許可により、クライアント アプリケーションは、テナント内のすべてのユーザーのコンテンツにアクセスできます。 ネイティブの Microsoft 365 アプリケーションを正しく動作させるには、このアクセス許可が必要です。 このアクセス許可を持つ Microsoft 以外のアプリケーションは、すべて慎重に確認する必要があります。

8. Permission 列 (F) で、各委任アプリケーションが持つアクセス許可を確認します。 Read および Write アクセス許可、または *.All アクセス許可は、不適切な場合があるため、これらのアクセス許可を見つけ、慎重に確認します。

   Note

   同意を行った特定のユーザーを確認します。 ハイ プロファイルまたは影響の大きいユーザーが不適切に同意している場合、さらに調査する必要があります。

9. ClientDisplayName 列 (C) で、次のような疑わしいアプリを探します。

   • つづりのまちがった名前のあるアプリ

   • 一般的でない名前または平凡な名前

   • ハッカーを匂わせる名前。 これらの名前は慎重に確認する必要があります。

出力の例: AllPrincipals と ReadWrite.All。 アプリケーションには、当たり障りのない名前など、何も疑わしい点がなく、MS Graph が使用されている場合があります。 ただし、この例に示すように、調査を実行し、アプリケーションの目的と、アプリケーションがテナントで所持している実際のアクセス許可を特定します。

情報セキュリティ ポリシー (ISP) の調査を確認する場合、次の情報が役立ちます。

• ReplyURL/RedirectURL
  • 疑わしい URL を探します
• URL が疑わしいドメインでホスティングされていないか
  • 侵害されていないか
  • ドメインが最近登録されていないか
  • 一時的なドメインではないか
• アプリ登録にサービス使用条件/サービス契約のリンクがあるか
• コンテンツは、アプリケーション/発行者に固有で具体的なものか
• アプリケーションを登録したテナントが新しく作成されたか侵害されていないか (たとえば、アプリが危険なユーザーによって登録されいないか)

同意付与攻撃の詳細

攻撃の手法

各攻撃は変化しつつありますが、主な攻撃手法は次のとおりです:

• 攻撃者が、Microsoft Entra ID などの OAuth 2.0 プロバイダーにアプリを登録します。

• アプリケーションは、正当なものに見えるように構成されています。 たとえば、攻撃者は、同じエコシステムで利用できる有名な製品の名前を使用する場合があります。

• 攻撃者がユーザーから直接リンクを入手します。これは、従来の電子メール ベースのフィッシング、悪意のない Web サイトの侵害、または他の手法によって実行される場合があります。

• ユーザーがリンクを選択すると、データへのアクセス許可を悪意のあるアプリに付与するように求める信憑性のある同意プロンプトが表示されます。

• ユーザーが "承諾する" を選択すると、機密データにアクセスできるアクセス許可がアプリに付与されます。

• アクセス トークン、場合によっては更新トークンの引き換えに使用される承認コードをアプリが取得します。

• アクセス トークンを使用して、ユーザーの代わりに API 呼び出しが行われます。

• ユーザーが同意すると、攻撃者は、ユーザーのメール、転送ルール、ファイル、連絡先、メモ、プロファイル、その他の機密データやリソースにアクセスできるようになります。

  

攻撃の兆候を見つける

1. Microsoft 365 Defender ポータル (https://security.microsoft.com) で、[監査] に移動します。 または、[監査] ページに直接移動するには、https://security.microsoft.com/auditlogsearch を使用します。

2. [監査] ページで、すべてのアクティビティとすべてのユーザーを検索し、必要に応じて開始日と終了日を入力してから、[検索] を選択します。

   

3. [結果をフィルター処理します] を選択し、[アクティビティ] フィールドに、「Consent to application」と入力します。

   

4. [consent to grant]\(付与することに同意\) の下にアクティビティがある場合は、次の手順に進みます。

5. 結果を選択して、アクティビティの詳細を表示します。 [詳細情報] を選択して、アクティビティの詳細を取得します。

6. IsAdminContent が "True" に設定されているかどうかを確認します。

   Note

   イベント発生した後の対応する監査ログ エントリを検索結果に表示するため、このプロセスは 30 分から最大で 24 時間かかる場合があります。

   監査レコードが保持され、監査ログで検索できる期間は、Microsoft 365 サブスクリプション、特に特定のユーザーに割り当てられているライセンスの種類によって異なります。 この値が true の場合、誰かがデータへの広範なアクセスを許可した可能性があることを示します。 これが予想外の場合は、すぐに攻撃を確認する手順を実行します。

攻撃を確認する方法

上記の IoC の事例が 1 つ以上ある場合は、さらに調査を行って、攻撃が発生したかどうかを積極的に確認する必要があります。

組織内のアクセス権を持つアプリのインベントリ (一覧) を作成する

Microsoft Entra 管理センター、PowerShell を使用してユーザーのアプリのインベントリを作成することや、ユーザーに対して個別にアプリケーションのアクセス権を列挙させることができます。

• Microsoft Entra 管理センターを使用して、アプリケーションとそのアクセス許可のインベントリを作成します。 これは綿密な方法ですが、一度に 1 人のユーザーしか確認できません。したがって、複数のユーザーのアクセス許可を確認する必要がある場合は、時間がかかる可能性があります。
• PowerShell を使用して、アプリケーションとそのアクセス許可のインベントリを作成する。 これは最も高速で最も綿密な方法で、オーバーヘッドも最小限です。
• 個々のユーザーにアプリとアクセス許可を確認するよう指示し、修復のために結果を管理者に報告させる。

ユーザーに割り当てられているアプリのインベントリを作成する

Microsoft Entra 管理センターを使用して、個々のユーザーがアクセス許可を付与したアプリの一覧を表示できます。

1. 管理者権限を使用して Azure portal にサインインします。
2. [Microsoft Entra ID] アイコンを選択します。
3. [ユーザー] を選択します。
4. 確認するユーザーを選択します。
5. [アプリケーション] を選択します。

ユーザーに割り当てられているアプリと、それらのアプリに付与されているアクセス許可の一覧を確認できます。

攻撃の範囲を特定する

アプリケーションのアクセス権のインベントリ作成が完了したら、監査ログを確認して、侵害の全範囲を特定します。 影響を受けたユーザー、不正なアプリケーションが組織にアクセスした時間帯、そのアプリケーションが持っていたアクセス許可を調べます。 Microsoft 365 セキュリティと Microsoft Purview コンプライアンス ポータルで監査ログを検索できます。

重要

可能な攻撃の前に監査が有効になっていない場合監査データが利用できないため、調査できません。

攻撃を防止してリスクを軽減する方法

• 定期的に組織のアプリケーションを監査し、さらに付与されたアクセス許可を監査して、認可されていない、または疑わしいアプリケーションにデータへのアクセス権が付与されていないことを確認します。

• Office 365 で不正な同意許可を確認、検出、修復します。 OAuth の同意を要求する疑わしいアプリケーションに対して、より多くのベスト プラクティスと保護を行います。

組織が適切なライセンスを持っている場合:

• Microsoft Defender for Cloud Apps でさらに OAuth アプリケーション監査機能を使用します。
• Azure Monitor Workbooks を使用して、アクセス許可および同意に関連するアクティビティを監視します。 Consent Insights ワークブックには、失敗した同意要求の数を示すアプリの一覧が表示されます。 これは、管理者の同意を許可するかどうかを管理者が確認および判断するため、アプリケーションの優先順位を決定するのに役立ちます。

不正な同意付与攻撃を停止して修復する方法

不正なアクセス許可を持つアプリケーションを特定したら、「 アプリケーションを無効にする」の 手順 に従って、すぐにアプリケーションを無効にします。 次に、Microsoft サポートに連絡して、悪意のあるアプリケーションを報告します。

Microsoft Entra でアプリケーションが無効になると、データにアクセスするための新しいトークンを取得できなくなります。また、他のユーザーがサインインしたり、アプリへの同意を許可したりすることはできません。

Note

組織内で悪意のあるアプリケーションが発生したと思われる場合は、削除するよりも無効にすることをお勧めします。 アプリケーションを削除しただけの場合、別のユーザーが同意を与えた場合、後で復活する可能性があります。 代わりに、アプリケーションを無効にして、後ほど復活しないようにします。

推奨される防御方法

組織を保護する手順

さまざまな種類の同意攻撃がありますが、これらの推奨される防御方法は、すべての種類の攻撃 (特に同意フィッシング) を軽減します。同意フィッシングでは、攻撃者は、ユーザーをだまして、機密データやその他のリソースへのアクセス権を悪意のあるアプリに付与させようとします。 攻撃者は、ユーザーのパスワードを盗もうとするのではなく、攻撃者が制御するアプリが貴重なデータにアクセスするためのアクセス許可を入手しようとします。

同意攻撃が Microsoft Entra ID と Office 365 に影響しないようにするために、次の推奨事項を確認してください。

ポリシーを設定する

• この設定はユーザーに影響を与え、環境に適用できない場合があります。 同意を許可する場合は、管理者がその要求を承認する必要があります。

• 確認済みの発行元からのアプリケーションに対してのみ、また低影響として分類される特定の種類のアクセス許可に対して同意を許可します。

  Note

  上記の推奨事項は、最も理想的で安全な構成に基づいて提案されています。 ただし、セキュリティは機能と運用の間で細かいバランスが取られているため、最も安全な構成では、管理者に対してさらにオーバーヘッドが発生する可能性があります。 このような決定は、管理者に相談した後に行うのが最善です。

  リスクに基づくステップアップ同意の構成 - 付与に対するユーザーの同意が有効になっている場合、既定で有効化される

• リスクに基づくステップアップ同意を使用すると、違法な同意要求を行う悪質なアプリへのユーザーの露出を減らすことができます。 危険なエンドユーザー同意要求が Microsoft によって検出されると、管理者の同意への "ステップアップ" が求められます。 この機能は既定で有効ですが、エンドユーザーの同意が有効化されている場合にのみ、動作変更につながります。

• 危険な同意要求が検出されると、管理者の承認が必要であることを示すメッセージが同意プロンプトに表示されます。 管理者の同意要求ワークフローが有効になっている場合、ユーザーは、詳しい確認のために、同意プロンプトからその要求を管理者に直接送信できます。 有効になっていると場合、次のメッセージが表示されます。

  AADSTS90094:: <clientAppDisplayName> には、組織内のリソースへのアクセス許可が必要です。これを付与できるのは管理者のみです。 使用するには、まず、このアプリへのアクセス許可の付与を管理者に依頼してください。 この場合、"ApplicationManagement" というカテゴリ、"Consent to application" (アプリケーションへの同意) というアクティビティの種類、"Risky application detected" (危険なアプリケーションの検出) という状態の理由で、監査イベントもログに記録されます。

Note

管理者の承認を必要とするタスクでは、運用上のオーバーヘッドが発生します。 "同意とアクセス許可、ユーザーの同意設定" は、現在プレビューの段階です。 一般提供 (GA) の準備ができたら、"選択されたアクセス許可について、確認済みの発行元からのユーザーの同意を許可する" 機能を使用して、管理者のオーバーヘッドを削減することができます。これは、ほとんどの組織に対して推奨されます。

アプリケーション開発者が、信頼できるアプリ エコシステムに従うように教育する 開発者が高品質で安全な統合を構築できるようにするために、Microsoft は Microsoft Entra アプリの登録での統合アシスタントのパブリック プレビューも発表しました。

• この統合アシスタントは、推奨される一連のセキュリティ ベスト プラクティスに照らして、アプリの登録を分析し、ベンチマークを実行します。
• この統合アシスタントでは、統合のライフサイクル (開発から監視まで) の各フェーズで関連する成功事例が強調表示され、すべてのステージが適切に構成されるようにします。
• 初めてアプリを統合するユーザーでも、スキルの向上を目指すエキスパートでも、業務が簡単になります。

同意の戦術について組織を教育する (フィッシングの戦術、管理者とユーザーの同意):

• スペルや文法に誤りがあるか確認します。 メール メッセージまたはアプリケーションの同意画面にスペルミスや文法エラーがある場合、疑わしいアプリケーションである可能性があります。
• アプリの名前とドメインの URL に注意します。 攻撃者は、アプリ名を偽造して、正当なアプリケーションに見えるように、または正当な企業からのアプリケーションに見えるようにし、その悪意のあるアプリにユーザーを同意させようとします。
• アプリケーションに同意する前に、必ずアプリ名とドメイン URL を必ず確認します。

信頼できるアプリへのアクセスを促進し許可する

• 発行元が確認されたアプリケーションの使用を推奨します。 発行元の確認により、管理者とエンド ユーザーは、アプリケーション開発者の信頼性を把握できます。 これまでに、390 の発行元による 660 を超えるアプリケーションが確認されています。
• 信頼できる特定のアプリケーション (所属組織や確認済みの発行元が開発したアプリケーションなど) にのみユーザーが同意できるように、アプリケーションの同意ポリシーを構成します。
• アクセス許可と同意フレームワークのしくみについて組織を教育します。
• アプリケーションが求めるデータとアクセス許可を理解し、アクセス許可と同意がプラットフォーム内でどのように機能するかを理解します。
• 管理者が同意要求を管理および評価する方法を理解しているか確認します。

組織内のアプリと同意済みのアクセス許可を監査して、使用されているアプリケーションが必要なデータにのみアクセスしており、最小特権の原則に準拠していることを確認します。

軽減策

• 顧客を教育し、アプリケーション同意付与のセキュリティ保護に関する知見とトレーニングを提供します。
• 組織方針と技術的制御により、アプリケーション同意付与プロセスを制限します。
• スケジュールを作成して、同意対象のアプリケーションを確認します。
• PowerShell を使用して、アプリを無効にすることで、疑わしいアプリまたは悪意のあるアプリを無効にすることができます

関連するコンテンツ

• リモート ワークフォース アプリケーション攻撃を防止する
• 安全で信頼できるアプリ エコシステムを促進する
• 危険な OAuth アプリを調査する
• アプリケーションの同意の管理と同意要求の評価
• Microsoft Entra ID でエンタープライズ アプリのためのユーザー サインインを無効にする
• Microsoft ID プラットフォームでのアクセス許可と同意フレームワークについて理解する。
• 委任されたアクセス許可とアプリケーションのアクセス許可の違いについて理解する。
• エンド ユーザーがアプリケーションに同意する方法の構成
• アプリケーション リストに予期しないアプリケーションがある
• 不正同意付与を検出して修復する
• Microsoft Entra アプリケーションを追加する方法と理由
• Microsoft Entra ID のアプリケーションとサービス プリンシパル オブジェクト
• Microsoft Entra Config Documentor
• アプリケーションの同意の管理と同意要求の評価
• Get-AzureADServicePrincipal
• ビルド 2020: すべてのユーザーのために安全で信頼できるアプリ エコシステムを促進する
• 管理者の同意ワークフローの構成
• 管理者は、すべての同意要求を慎重に評価したうえで要求を承認する必要がある。
• アプリケーションの登録とエンタープライズ アプリケーション
• アクセス許可
• AppConsent フィッシングでの KrebsOnSecurity

その他のインシデント対応プレイブック

次の追加の種類の攻撃を特定して調査するためのガイダンスを確認してください。

• フィッシング
• パスワード スプレー

インシデント対応のリソース

• 新規担当者および経験豊富なアナリスト向けの Microsoft セキュリティ製品およびリソースの概要
• セキュリティ オペレーション センター (SOC) の計画
• Microsoft Defender XDR のインシデント対応
• Microsoft Defender for Cloud (Azure)
• Microsoft Sentinel のインシデント応答
• Microsoft インシデント対応チーム ガイドでセキュリティ チームとリーダー向けのベスト プラクティスを共有
• Microsoft インシデント対応ガイドは、セキュリティ チームによる疑わしいアクティビティの分析で役に立つ