アプリ同意付与の調査

  • [アーティクル]

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

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

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

前提条件

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

顧客データ

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

  • グローバル管理者としてのテナントへのアクセス権 - クラウド専用アカウント (オンプレミス環境に含まれないもの)
  • 侵害インジケーター (IoC) の詳細
  • インシデントに気付いた日時
  • 日付範囲
  • 侵害されたアカウントの数
  • 侵害されたアカウントの名前
  • 侵害されたアカウントのロール
  • アカウントに高い特権が付与されているかどうか (GA Microsoft Exchange、SharePoint)
  • インシデントに関連するエンタープライズ アプリケーションがあるかどうか
  • ユーザーの代わりにデータへのアクセス許可を要求したアプリケーションについてユーザーから報告があったかどうか

システム要件

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

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

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 "2b1a14ac-2956-442f-9577-1234567890ab" -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 アクセス許可の表示] を選択します。

    apipermissions

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

    api

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

    アクセス許可の種類

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

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

    examplepermission

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

    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 ツールがいくつかあります。

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

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

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

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

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -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 アクセス許可は、不適切な場合があるため、これらのアクセス許可を見つけ、慎重に確認します。 Permission 列 (F) の例

    Note

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

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

    • つづりのまちがった名前のあるアプリ スペルミスの名前の例

    • 一般的でない名前または平凡な名前 通常とは異なる名前の例

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

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

ConsentType が AllPrincipals のアプリケーションの例

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

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

攻撃の手法

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

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

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

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

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

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

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

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

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

    アクセス許可要求の例

攻撃の兆候を見つける

  1. セキュリティ/コンプライアンス センターを開きます。

  2. [検索] に移動し、[監査ログの検索] を選択します。

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

    監査ログの検索の例

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

    監査ログ検索でのフィルター処理の例

  5. [consent to grant]\(付与することに同意\) の下にアクティビティがある場合は、以下の指示に従い続行します。

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

  7. 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 サポートに連絡して、悪意のあるアプリケーションを報告します。

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 を使用して、アプリを無効にすることで、疑わしいアプリまたは悪意のあるアプリを無効にすることができます

リファレンス

この記事の内容のソースを次に示します。

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

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

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