Microsoft Entra 条件付きアクセスを使用してレガシ認証をブロックする

  • [アーティクル]

ユーザーがクラウド アプリに簡単にアクセスできるように、Microsoft Entra ID ではレガシ認証を含め、幅広い認証プロトコルがサポートされています。 ただし、レガシ認証では多要素認証 (MFA) などをサポートしていません。 MFA は、組織のセキュリティ体制を改善するための一般的な要件です。

Microsoft の分析に基づくと、資格情報のスタッフィング攻撃の 97% 以上がレガシ認証を利用し、パスワード スプレー攻撃の 99% 以上がレガシ認証プロトコルを利用しています。 これらの攻撃は、基本認証が無効化またはブロックされると止まります。

注意

2022 年 10 月 1 日より、使用状況に関わらず、すべての Microsoft 365 テナントで、SMTP 認証を除き、Exchange Online の基本認証を恒久的に無効にする作業を開始する予定です。 詳細については、Exchange Online での基本認証の非推奨に関する記事をご覧ください。

Microsoft Identity Security のディレクター、Alex Weinert は 2020 年 3 月 12 日のブログ記事「New tools to block legacy authentication in your organization」 (レガシー認証をブロックするための新しいツール) で、組織がレガシ認証をブロックするべき理由を強調し、それに役立つ Microsoft の他のツールを紹介しています。

この記事では、テナント内のすべてのワークロードのレガシ認証をブロックする条件付きアクセス ポリシーを構成する方法について説明します。

レガシ認証のブロック保護を展開する場合は、すべてのユーザーに対して一度に無効にせずに、段階的なアプローチをお勧めします。 顧客は、まず Exchange Online 認証ポリシーを適用して、プロトコルごとに基本認証の無効化を開始し、(必要に応じて) 準備ができたら条件付きアクセス ポリシーを使用してレガシ認証をブロックすることを選ぶかもしれません。

条件付きアクセスに対応しているライセンスがない顧客は、セキュリティの既定値群 を利用してレガシ認証をブロックできます。

前提条件

この記事では、Microsoft Entra 条件付きアクセスの基本的な概念を理解していることを前提としています。

Note

条件付きアクセス ポリシーは、第 1 段階認証が完了した後で適用されます。 条件付きアクセスはサービス拒否 (DoS) 攻撃などのシナリオに対する組織の防御の最前線を意図したものではありませんが、これらのイベントからのシグナルを使用してアクセス権を判定できます。

シナリオの説明

Microsoft Entra ID では、レガシ認証を含め、最も広く使用されている認証と承認のプロトコルをサポートしています。 レガシ認証では、条件付きアクセス ポリシーを満たすために必要な二要素認証やその他の認証要件をユーザーに直接求めることができません。 この認証パターンには、ユーザー名とパスワード情報を収集するために広く使用され業界標準の方法である基本認証が含まれます。 通常は、レガシ認証を使用する、または、これのみを使用するアプリケーションの例を次に示します。

  • Microsoft Office 2013 以前。
  • POP、IMAP、SMTP 認証などの電子メール プロトコルを使用するアプリ。

Office に対する先進認証のサポートの詳細については、Office クライアント アプリで先進認証のしくみに関するページを参照してください。

最近は、単一要素認証 (たとえば、ユーザー名とパスワード) では不十分です。 パスワードは、簡単に推測できるうえに、適切なパスワードの選定は難しいため不十分です。 また、パスワードには、フィッシングやパスワード スプレーなどのさまざまな攻撃に対する脆弱性があります。 パスワードの脅威から保護するために実行できる最も簡単な方法の 1 つは、多要素認証 (MFA) を実装することです。 MFA を使用すれば、攻撃者がユーザーのパスワードを入手したとしても、パスワードだけでは認証に成功してデータにアクセスするには不十分です。

レガシ認証を使用しているアプリからはテナントのリソースにアクセスできないようにするには、どうしたらいいでしょうか。 条件付きアクセス ポリシーを使用して、それらのアプリをブロックすることをお勧めします。 必要に応じて、特定のユーザーと特定のネットワークの場所だけに、レガシ認証に基づいたアプリの使用を許可します。

実装

このセクションでは、レガシ認証をブロックするために条件付きアクセス ポリシーを構成する方法について説明します。

レガシ認証をサポートするメッセージング プロトコル

次のメッセージング プロトコルは、レガシ認証をサポートしています。

  • 認証済み SMTP - 認証された電子メール メッセージの送信に使用されます。
  • 自動検出 - Exchange Online でメールボックスを検索して接続するために Outlook および EAS のクライアントで使用されます。
  • Exchange ActiveSync (EAS) - Exchange Online のメールボックスに接続するために使用されます。
  • Exchange Online PowerShell - リモート PowerShell を使用して Exchange Online に接続するために使用されます。 Exchange Online PowerShell の基本認証をブロックする場合は、Exchange Online PowerShell モジュールを使用して接続する必要があります。 手順については、「多要素認証をConnect PowerShell Exchange Onlineする方法」を参照してください。
  • Exchange Web サービス (EWS) - Outlook、Outlook for Mac、およびサードパーティ製アプリによって使用されるプログラミング インターフェイスです。
  • IMAP4 - IMAP 電子メール クライアントで使用されます。
  • MAPI over HTTP (MAPI/HTTP) - Outlook 2010 SP2 以降で使用される、プライマリー メールボックス アクセス プロトコルです。
  • オフライン アドレス帳 (OAB) - Outlook によってダウンロードおよび使用されるアドレス一覧コレクションのコピーです。
  • Outlook Anywhere (RPC over HTTP) - Outlook のすべての現在のバージョンでサポートされているレガシ メールボックス アクセス プロトコルです。
  • POP3 - POP 電子メール クライアントで使用されます。
  • レポート Web サービス - Exchange Online でレポート データを取得するために使用されます。
  • Universal Outlook - Windows 10 用のメール/カレンダー アプリで使用されています。
  • その他のクライアント - レガシ認証を利用していると識別された他のプロトコル。

これらの認証プロトコルとサービスの詳細については、「サインイン ログ アクティビティの詳細」を参照してください。

レガシ認証の使用を識別する

ディレクトリでレガシ認証をブロックする前に、まず、ユーザーがレガシ認証を使用するクライアント アプリを保有しているかどうかを把握する必要があります。

サインイン ログ インジケーター

  1. 条件付きアクセス管理者以上として Microsoft Entra 管理センターにサインインします。
  2. [ID]>[監視と正常性]>[サインイン ログ] の順に移動します。
  3. [クライアント アプリ] 列が表示されていない場合は、[列]、[クライアント アプリ] を選択してその列を追加します。
  4. [フィルターの追加]、[クライアント アプリ] を選択し、すべてのレガシ認証プロトコルを選択し、[適用] を選択します。
  5. 新しいサインイン アクティビティ レポート - プレビューをアクティブにしている場合は、[ユーザーのサインイン (非対話型)] タブでも上の手順を繰り返します。

フィルター処理によって、レガシ認証プロトコルによって行われたサインイン試行のみが表示されます。 各サインイン試行をクリックすると詳細が表示されます。 [基本情報] タブの [クライアント アプリ] フィールドには、どのレガシ認証プロトコルが使用されたかが表示されます。

これらのログは、ユーザーがまだレガシ認証に依存しているクライアントを使っている場所を示しています。 これらのログに表示されず、レガシ認証を使用していないことが確認されたユーザーに対してのみ、条件付きアクセス ポリシーを実装します。

さらに、テナント内のレガシ認証をトリアージするために、レガシ認証ブックを使用したサインインを使います。

クライアントのインジケーター

サインイン時に表示されるダイアログ ボックスに基づいてクライアントがレガシ認証または先進認証のどちらを使っているかを確認するには、記事「Exchange Online での基本認証の非推奨」を参照してください。

重要な考慮事項

以前はレガシ認証のみをサポートしていた多くのクライアントで、先進認証がサポートされるようになりました。 レガシ認証と先進認証の両方をサポートするクライアントでは、レガシ認証から先進認証に移行するための構成更新が必要になる場合があります。 サインイン ログでクライアントに modern mobile、desktop client または browser が表示されている場合は、クライアントは最新の認証を使用しています。 Exchange ActiveSync などの特定のクライアントかプロトコル名がある場合は、レガシ認証が使われています。 条件付きアクセス、サインイン ログ、レガシ認証ブック内のクライアントの種類は、最新の認証とレガシ認証のクライアントを区別して表示します。

  • 先進認証をサポートしているが、先進認証を使うように構成されていないクライアントは、先進認証を使うように更新するか再構成する必要があります。
  • 先進認証をサポートしていないクライアントは、すべて置き換える必要があります。

重要

証明書ベースの認証 (CBA) を使った Exchange Active Sync

CBA を使った Exchange Active Sync (EAS) を実装する場合は、先進認証を使用するようにクライアントを構成します。 Exchange Online における基本認証の非推奨では、CBA を使った EAS に対する先進認証を使わないクライアントはブロックされません。 ただし、レガシ認証をブロックするように構成された条件付きアクセス ポリシーでは、これらのクライアントはブロックされます。

Microsoft Entra ID と先進認証を使用した CBA のサポートの実装の詳細については、「Microsoft Entra 証明書ベースの認証を構成する方法 (プレビュー)」を参照してください。 別のオプションとして、フェデレーション サーバーで実行される CBA は、先進認証で使用できます。

Microsoft Intune を使っている場合、デバイスにプッシュまたはデプロイするメール プロファイルを使って、認証の種類を変更できる場合があります。 iOS デバイス (iPhone や iPad) を使っている場合は、「Microsoft Intune で iOS と iPadOS デバイスのメール設定を追加する」を参照してください。

レガシ認証をブロックする

条件付きアクセス ポリシーを使用してレガシ認証をブロックするには、2 つの方法があります。

レガシ認証を直接ブロックする

組織全体でレガシ認証をブロックする最も簡単な方法は、レガシ認証クライアントに特化して適用され、アクセスをブロックする条件付きアクセス ポリシーを構成することです。 ユーザーとアプリケーションをポリシーに割り当てる際には、まだレガシ認証を使用してサインインする必要があるユーザーとサービス アカウントを必ず除外してください。 このポリシーを適用するクラウド アプリを選択する場合は、すべてのクラウド アプリ、Office 365 (推奨) などの対象アプリ、または少なくとも Office 365 Exchange Online を選択します。 組織は、条件付きアクセス テンプレートまたは共通ポリシーの [条件付きアクセス: レガシ認証をブロックする] で使用できるポリシーを参照として使用できます。

レガシ認証を間接的にブロックする

組織がレガシ認証を完全にブロックするための準備ができていない場合、レガシ認証を使用するサインインが多要素認証のような許可コントロールを要求するポリシーをバイパスしていないことを確かめる必要があります。 認証時、レガシ認証クライアントでは、Microsoft Entra ID への MFA、デバイスのコンプライアンス、または参加状態の情報の送信はサポートされません。 したがって、すべてのクライアント アプリケーションに許可コントロールを含むポリシーを適用して、許可コントロールを満たすことができないレガシ認証ベースのサインインがブロックされるようにします。 2020 年 8 月にクライアント アプリの条件が一般提供されると、新しく作成された条件付きアクセス ポリシーは、既定ですべてのクライアント アプリに適用されます。

知っておくべきこと

条件付きアクセス ポリシーが有効になるまでに、最大 24 時間かかる場合があります。

その他のクライアントを使用しているアクセスをブロックすると、基本認証を使用している Exchange Online PowerShell および Dynamics 365 もブロックされます。

その他のクライアントを対象とするポリシーを構成すると、SPConnect などの特定のクライアントから組織全体がブロックされます。 このブロックは、旧バージョンのクライアントが想定していない方法で認証されるために発生します。 この問題は、古い Office クライアントなどの重要な Office アプリケーションには適用されません。

他のクライアント条件には、利用可能なすべての制御の許可を選択できます。ただし、エンドユーザーのエクスペリエンスは常に同じ、つまり、アクセスがブロックされます。

次のステップ