同意フィッシングから保護する
生産性がプライベート ネットワークに限定されなくなり、作業がクラウド サービスに大きく移行しました。 クラウド アプリケーションを使用すると、従業員はリモートで生産性を高めることができますが、攻撃者もアプリケーションベースの攻撃を使用して重要な組織データにアクセスできます。 メールのフィッシングや資格情報の侵害など、ユーザーに焦点を当てた攻撃にはなじみがあるかもしれません。 "同意フィッシング" は、注意が必要なもう 1 つの脅威ベクトルです。
この記事では、同意フィッシングの概要、組織を保護するための Microsoft の取り組み、組織が安全を維持するため実行できる手順について説明します。
同意フィッシングとは
同意フィッシング攻撃では、悪意のあるクラウド アプリケーションにアクセス許可を付与するようにユーザーが誘導されます。 その後、これらの悪意のあるアプリケーションは、ユーザーの正当なクラウド サービスとデータにアクセスできます。 資格情報の侵害とは異なり、同意フィッシングを実行する "脅威アクター" は、個人または組織のデータへのアクセスを直接許可できるユーザーを標的にします。 同意画面には、アプリケーションが受け取るすべてのアクセス許可が表示されます。 正規のプロバイダー (Microsoft ID プラットフォームなど) がアプリケーションをホストしているため、疑いを持たないユーザーは条件を受け入れます。 このアクションにより、悪意のあるアプリケーションに、要求されたデータへのアクセス許可が付与されます。 次の図は、さまざまなアクセス許可へのアクセスを要求する OAuth アプリの例を示しています。
同意フィッシング攻撃を軽減する
管理者、ユーザー、または Microsoft のセキュリティ研究者は、疑わしい動作を示す OAuth アプリケーションにフラグを付けることができます。 Microsoft は、フラグが立てられたアプリケーションをレビューして、サービス利用規約に違反しているかどうかを判断します。 違反が確認された場合、Microsoft Entra ID ではそのアプリケーションが無効化され、すべての Microsoft サービスで以後使用することが禁止されます。
Microsoft Entra ID で OAuth アプリケーションが無効化されると、次のアクションが実行されます。
- 悪意のあるアプリケーションとそれに関連するサービス プリンシパルは、完全に無効な状態になります。 新しいトークン要求または更新トークンの要求は拒否されますが、既存のアクセス トークンは有効期限が切れるまで引き続き有効です。
- これらのアプリケーションは、Microsoft Graph の関連アプリケーションおよびサービス プリンシパル リソースの種類の
disabledByMicrosoftStatus
プロパティにDisabledDueToViolationOfServicesAgreement
と表示されます。 将来的に組織で再度インスタンス化されないようにするために、これらのオブジェクトを削除することはできません。 - アプリケーションが無効化される前に組織内のユーザーがそのアプリケーションに同意すると、メールが特権ロール管理者に送信されます。 このメールでは、実行されたアクションと、セキュリティ体制を調査して改善するために実行できる推奨手順が示されます。
推奨される対応と修復
Microsoft が無効にしたアプリケーションが組織に影響を与える場合、組織は環境を安全に保つために次の手順を実行する必要があります。
- 次を含む、無効化されたアプリケーションのアプリケーション アクティビティを調べます。
- アプリケーションによって要求された、委任されたアクセス許可またはアプリケーションのアクセス許可。
- アプリケーションによるアクティビティとアプリケーションを使用する権限を持つユーザーのサインイン アクティビティに関する Microsoft Entra ID 監査ログ。
- 不正な同意許可を防止するためのガイダンスを確認して使用します。 このガイダンスでは、確認中に検出された無効なアプリケーションと疑わしいアプリケーションへのアクセス許可と同意の監査について説明されています。
- 以下のセクションで説明する、同意フィッシングに対するセキュリティ強化のベスト プラクティスを実装します。
同意フィッシング攻撃に対するセキュリティ強化のベスト プラクティス
管理者は、組織内でアプリケーションを許可および使用する方法を制御するための適切な分析情報と機能を用意して、アプリケーションの使用を制御する必要があります。 攻撃者は決してその手を緩めませんが、組織がそのセキュリティ体制を改善するために実行できる手順があります。 従うべきベスト プラクティスのいくつかを、次に示します。
- アクセス許可と同意フレームワークのしくみについて組織を教育する。
- アプリケーションから求められるデータとアクセス許可を理解し、アクセス許可と同意がプラットフォーム内でどのように機能するかを理解します。
- 同意要求を管理および評価する方法を管理者が理解しているか確認します。
- 定期的に組織内のアプリケーションと同意済みのアクセス許可を監査して、それらのアプリケーションが必要なデータにのみアクセスしており、最小特権の原則に準拠していることを確認します。
- 一般的な同意フィッシングの戦術を特定してブロックする方法を理解する。
- スペルや文法に誤りがあるか確認します。 メール メッセージまたはアプリケーションの同意画面にスペルミスや文法の誤りがある場合、それは疑わしいアプリケーションである可能性があります。 その場合は、同意プロンプトの [こちらでご報告ください] リンクを使用して直接報告します。Microsoft では、それが悪意のあるアプリケーションかどうかを調べ、悪意のあるアプリケーションである場合は無効化します。
- アプリケーション名やドメイン URL を信頼性のソースとして利用しないでください。 攻撃者は、正当なサービスまたは企業が提供しているアプリケーションやドメインに見えるようにそれらの名前を偽造し、悪意のあるアプリケーションに同意させようとします。 代わりに、ドメイン URL のソースを検証し、可能であれば確認済みの発行元から入手したアプリケーションを使用します。
- 攻撃者が組織内の既知のユーザーを偽装しているフィッシング キャンペーンから保護することで、Microsoft Defender for Office 365 による同意フィッシング メールをブロックします。
- 組織でアプリケーションの異常なアクティビティを管理できるように、Microsoft Defender for Cloud Apps のポリシーを構成します。 たとえば、アクティビティ ポリシー、異常検出、OAuth アプリ ポリシーなどです。
- Microsoft 365 Defender を使用した高度な検出に関するガイダンスに従って、同意フィッシング攻撃の調査と検出を行います。
- 特定の条件を満たすと共に、それらを満たしていないアプリケーションから保護する信頼されたアプリケーションへのアクセスを許可します。
- 特定の条件を満たすアプリケーションにのみユーザーが同意できるように、ユーザーの同意設定を構成します。 このようなアプリケーションには、組織によって開発されたアプリケーションや、検証済みの発行元から開発されたアプリケーションが含まれます。これは、選択した低リスクのアクセス許可に対してのみです。
- 発行元が確認されたアプリケーションを使用します。 発行元の確認により、管理者とユーザーは、Microsoft がサポートする審査プロセスを通じてアプリケーション開発者の信頼性を把握できます。 アプリケーションに確認された発行元が存在する場合でも、同意プロンプトをレビューすることにより、要求を理解して評価することが引き続き重要です。 たとえば、要求されているアクセス許可をレビューして、それが有効にするようアプリで要求されているシナリオに合っていることを確認することや、同意プロンプト上でのその他のアプリと発行元の詳細などのレビューです。
- 一般的な疑わしいアプリケーションの動作に対処するため、プロアクティブなアプリケーション ガバナンス ポリシーを作成して、Microsoft 365 プラットフォーム上でサードパーティのアプリケーションの動作を監視します。