編集

次の方法で共有

セキュリティ強化されたハイブリッド メッセージング インフラストラクチャ - モバイル アクセス

Microsoft Entra ID
Microsoft 365
Office 365

この記事では、Microsoft Exchange にアクセスする Outlook モバイル クライアントに対する多要素認証を実装する方法について説明します。 ユーザー メールボックスを持つ Microsoft Exchange には、2 つの異なる可能性に対応する 2 つのアーキテクチャがあります。

アーキテクチャ (Exchange Online)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange Online.

このシナリオでは、ユーザーは先進認証をサポートするモバイル クライアントを使用する必要があります。 Microsoft でサポートされている Outlook モバイル (iOS 版 Outlook/Android 版 Outlook) をお勧めします。 次のワークフローでは、Outlook モバイルを使用します。

"この記事のすべての図の Visio ファイルをダウンロードします。"

ワークフロー (Exchange Online)

  1. ユーザーは、メール アドレスを入力して、Outlook プロファイルの構成を開始します。 Outlook モバイルが AutoDetect サービスに接続されます。
  2. AutoDetect サービスで Exchange Online に対する AutoDiscover V2 匿名要求が作成され、メールボックスが取得されます。 Exchange Online から、Exchange Online を参照するメールボックスの ActiveSync URL アドレスが含まれた 302 リダイレクト レスポンスが返されます。 この種類の要求の例については、こちらを参照してください。
  3. AutoDetect サービスにメールボックス コンテンツのエンドポイントに関する情報が追加されたので、認証なしで ActiveSync を呼び出すことができるようになりました。
  4. この接続フローで説明したように、Exchange から 401 チャレンジ レスポンスが返されます。 これには、クライアントがアクセス トークンを取得するために使う必要のある、Microsoft Entra エンドポイントを識別する認可 URL が含まれています。
  5. AutoDetect サービスから、クライアントに Microsoft Entra 承認エンドポイントが返されます。
  6. クライアントは Microsoft Entra ID に接続して認証を完了し、サインイン情報 (電子メール) を入力します。
  7. ドメインがフェデレーションされている場合、要求が Web アプリケーション プロキシにリダイレクトされます。
  8. Web アプリケーション プロキシで、AD FS への認証要求がプロキシ処理されます。 ユーザーにサインイン ページが表示されます。
  9. ユーザーは、資格情報を入力して認証を完了します。
  10. ユーザーは Microsoft Entra ID にリダイレクトされます。
  11. Microsoft Entra ID により、Azure の条件付きアクセス ポリシーが適用されます。
  12. このポリシーでは、デバイスが Microsoft エンドポイント マネージャーに登録されている場合にユーザーのデバイスの状態に基づいて制限を適用したり、アプリケーション保護ポリシーを適用したり、多要素認証を適用したりすることができます。 この種類のポリシーの詳細な例については、ここで説明する実装手順を参照してください。
  13. ユーザーはポリシー要件を実装し、多要素認証要求を完了します。
  14. Microsoft Entra ID から、アクセス トークンと更新トークンがクライアントに返されます。
  15. クライアントはアクセス トークンを使用して Exchange Online に接続し、メールボックス コンテンツを取得します。

構成 (Exchange Online)

レガシ認証 (図の赤い破線) を使用した Exchange Online ActiveSync へのアクセス試行をブロックするには、Outlook モバイル サービスが使用するプロトコルに対してレガシ認証を無効にする認証ポリシーを作成する必要があります。 具体的には、AutoDiscover、ActiveSync、および Outlook Service を無効にする必要があります。 対応する認証ポリシーの構成を次に示します。

AllowBasicAuthAutodiscover : False

AllowBasicAuthActiveSync : False

AllowBasicAuthOutlookService : False

認証ポリシーを作成したら、そのポリシーをユーザーのパイロット グループに割り当てることができます。 テスト後に、すべてのユーザーに対してポリシーを展開することができます。 組織レベルでポリシーを適用するには、Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> コマンドを使用します。 この構成には Exchange Online PowerShell を使用する必要があります。

フェデレーション ドメインの場合は、条件付きアクセス ポリシーを使う代わりに AD FS を構成して多要素認証をトリガーすることができます。 ただし、接続を制御し、条件付きアクセス ポリシー レベルの制限を適用することをお勧めします。

アーキテクチャ (Exchange On-premises)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange on-premises.

"この記事のすべての図の Visio ファイルをダウンロードします。"

このシナリオでは、「ハイブリッド先進認証の使用」で説明されているとおり、ユーザーが先進認証をサポートするモバイル クライアントを使用する必要があります。 Microsoft でサポートされている Outlook モバイル (iOS 版 Outlook/Android 版 Outlook) をお勧めします。 次のワークフローでは、Outlook モバイルを使用します。

ワークフロー (Exchange On-premises)

  1. ユーザーは、メール アドレスを入力して、Outlook プロファイルの構成を開始します。 Outlook モバイルが AutoDetect サービスに接続されます。
  2. AutoDetect サービスで Exchange Online に対する AutoDiscover V2 匿名要求が作成され、メールボックスが取得されます。
  3. メールボックスがオンプレミスに置かれると、メールボックスの ActiveSync URL アドレスを取得するために AutoDetect で使用できるオンプレミスの AutoDiscover URL が含まれた 302 リダイレクト レスポンスが、Exchange Online から返されます。
  4. AutoDetect では、前の手順で受信したオンプレミスの URL を使用して、 Exchange On-Premises に対する AutoDiscover v2 匿名要求が作成され、メールボックスが取得されます。 Exchange On-Premises から、Exchange On-Premises を参照するメールボックスの ActiveSync URL アドレスが返されます。 この種類の要求の例については、こちらを参照してください。
  5. これで AutoDetect サービスにメールボックス コンテンツのエンドポイントに関する情報が追加されたので、認証なしでオンプレミスの ActiveSync エンドポイントを呼び出すことができるようになりました。 この接続フローで説明したように、Exchange から 401 チャレンジ レスポンスが返されます。 これには、クライアントがアクセス トークンを取得するために使う必要のある、Microsoft Entra エンドポイントを識別する認可 URL が含まれています。
  6. AutoDetect サービスから、クライアントに Microsoft Entra 承認エンドポイントが返されます。
  7. クライアントは Microsoft Entra ID に接続して認証を完了し、サインイン情報 (電子メール) を入力します。
  8. ドメインがフェデレーションされている場合、要求が Web アプリケーション プロキシにリダイレクトされます。
  9. Web アプリケーション プロキシで、AD FS への認証要求がプロキシ処理されます。 ユーザーにサインイン ページが表示されます。
  10. ユーザーは、資格情報を入力して認証を完了します。
  11. ユーザーは Microsoft Entra ID にリダイレクトされます。
  12. Microsoft Entra ID により、Azure の条件付きアクセス ポリシーが適用されます。
  13. このポリシーでは、デバイスが Microsoft エンドポイント マネージャーに登録されている場合にユーザーのデバイスの状態に基づいて制限を適用したり、アプリケーション保護ポリシーを適用したり、多要素認証を適用したりすることができます。 この種類のポリシーの詳細な例については、ここで説明する実装手順を参照してください。
  14. ユーザーはポリシー要件を実装し、多要素認証要求を完了します。
  15. Microsoft Entra ID から、アクセス トークンと更新トークンがクライアントに返されます。
  16. クライアントは、アクセス トークンを使用して Exchange Online に接続し、オンプレミスのメールボックス コンテンツを取得します。 このコンテンツは、ここで説明するようにキャッシュから提供される必要があります。 これを実現するために、クライアントは、ユーザーのアクセス トークンとオンプレミスの ActiveSync エンドポイントが含まれたプロビジョニング要求を発行します。
  17. Exchange Online のプロビジョニング API は、指定されたトークンを入力として受け取ります。 API は、2 つ目のアクセストークンと更新トークンのペアを取得して、Active Directory の代理呼び出しを介してオンプレミスのメールボックスにアクセスします。 この 2 番目のアクセス トークンの対象範囲は、Exchange Online のクライアントとオンプレミスの ActiveSync 名前空間エンドポイントの対象ユーザーです。
  18. メールボックスがプロビジョニングされていない場合は、プロビジョニング API によってメールボックスが作成されます。
  19. プロビジョニング API によって、オンプレミスの ActiveSync エンドポイントへのセキュリティで保護された接続が確立されます。 API は、認証メカニズムとして 2 番目のアクセス トークンを使用して、ユーザーのメッセージング データを同期します。 ユーザーの介入なしにバックグラウンドでデータを同期できるよう、更新トークンを使用して新しいアクセス トークンを定期的に生成します。
  20. データはクライアントに返されます。

構成 (Exchange On-premises)

レガシ認証 (図の赤い破線) を使用した Exchange On-premises ActiveSync へのアクセス試行をブロックするには、Outlook モバイル サービスが使用するプロトコルに対してレガシ認証を無効にする認証ポリシーを作成する必要があります。 具体的には、AutoDiscover と ActiveSync を無効にする必要があります。 対応する認証ポリシーの構成を次に示します。

BlockLegacyAuthAutodiscover: True

BlockLegacyAuthActiveSync: True

この認証ポリシーを作成するためのコマンドの例を次に示します。

New-AuthenticationPolicy -Name BlockLegacyActiveSyncAuth -BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover

認証ポリシーを作成した後、Set-User user01 -AuthenticationPolicy <name_of_policy> コマンドを使用することにより、そのポリシーをまずユーザーのパイロット グループに割り当てることができます。 テスト後に、ポリシーを展開してすべてのユーザーを含めることができます。 組織レベルでポリシーを適用するには、Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> コマンドを使用します。 この構成には Exchange オンプレミス PowerShell を使用する必要があります。

また、一貫性を実現し、Outlook クライアントからのアクセスのみを許可する手順が必要です。 組織内で Outlook モバイルを承認されたクライアントとして許可するには、先進認証をサポートする Outlook モバイル クライアントではないクライアントからの接続試行をブロックする必要があります。 次の手順を実行して、Exchange On-premises レベルでこれらの試行をブロックする必要があります。

  • 他のモバイル デバイス クライアントをブロックします。

    Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block

  • Exchange Online のオンプレミスへの接続を許可します。

    If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}

  • iOS 版 Outlook および Android 版 Outlook の基本認証をブロックします。

    New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block

これらの手順の詳細については、「iOS および Android 版 Outlook でのハイブリッド先進認証の使用」を参照してください。

フェデレーション ドメインの場合は、条件付きアクセス ポリシーを使う代わりに AD FS を構成して多要素認証をトリガーすることができます。 ただし、接続を制御し、条件付きアクセス ポリシー レベルの制限を適用することをお勧めします。

コンポーネント

  • Microsoft Entra ID。 Microsoft Entra ID は、Microsoft のクラウドベースの ID およびアクセス管理サービスです。 これは、本質的に EvoSTS (Microsoft Entra ID で使用されるセキュリティ トークン サービス) に基づく先進認証を提供します。 これは、Exchange Server オンプレミスの認証サーバーとして使用されます。
  • Microsoft Entra 多要素認証。 多要素認証は、サインイン プロセスでユーザーに別の形式の ID (携帯電話に示されるコードや指紋スキャンなど) を求めるプロセスです。
  • Microsoft Entra 条件付きアクセス。 条件付きアクセスは、Microsoft Entra ID が多要素認証などの組織のポリシーを適用するために使う機能です。
  • AD FS。 AD FS を使用すると、セキュリティを向上しながらセキュリティとエンタープライズの境界を越えてデジタル ID とエンタイトルメント権限を共有することで、フェデレーション ID とアクセス管理が使用できるようになります。 これらのアーキテクチャでは、AD FS はフェデレーション ID を使用したユーザーのサインインを円滑にするために使用されます。
  • Web アプリケーション プロキシ。 Web アプリケーション プロキシは、AD FS を使用することで、Web アプリケーションへのアクセスを事前認証します。 さらに、AD FS プロキシとしても機能します。
  • Microsoft Intune。 Intune は、Windows、Android、Mac、iOS、Linux オペレーティング システムの各エンドポイントを管理する、クラウドベースの統合エンドポイント管理です。
  • Exchange Server。 Exchange Server は、ユーザーのオンプレミスのメールボックスを管理します。 これらのアーキテクチャでは、Microsoft Entra ID によってユーザーに発行されたトークンを使うことで、メールボックスへのアクセスを認可します。
  • Active Directory サービス。 Active Directory サービスは、ドメインのメンバーに関する情報 (デバイスとユーザーを含む) を格納します。 これらのアーキテクチャでは、ユーザー アカウントは Active Directory サービスに属していて、Microsoft Entra ID に同期されます。

代替

先進認証をサポートするサードパーティのモバイル クライアントを、Outlook モバイルの代替として使用できます。 この代替手段を選択した場合、サードパーティ ベンダーはクライアントのサポートを担当します。

シナリオの詳細

エンタープライズ メッセージング インフラストラクチャ (EMI) は、組織の主要なサービスです。 旧式で安全性の低い認証と認可の方法から最新の認証への移行は、リモート ワークが普通になる世界では重要な課題になります。 メッセージング サービスのアクセスに多要素認証の要件を実装することは、その課題に対応する最も効果的な方法の 1 つです。

この記事では、Microsoft Entra 多要素認証を使って Outlook モバイル アクセス シナリオのセキュリティを強化するための 2 つのアーキテクチャについて説明します。

この記事では、次のシナリオについて説明します。

  • ユーザーのメールボックスが Exchange Online にある場合の Outlook モバイル アクセス
  • ユーザーのメールボックスが Exchange On-premises にある場合の Outlook モバイル アクセス

どちらのアーキテクチャも、iOS 版 Outlook と Android 版 Outlook の両方に対応しています。

その他のハイブリッド メッセージング シナリオで多要素認証を適用する場合の情報については、次の記事を参照してください。

この記事では、その他のプロトコル (IMAP や POP など) については説明しません。 通常、これらのシナリオでは上記プロトコルを使用しません。

一般的な注意事項

  • これらのアーキテクチャでは、フェデレーション Microsoft Entra ID モデルが使用されます。 パスワード ハッシュ同期とパススルー認証モデルについては、ロジックとフローが同じになります。 唯一の違いは、Microsoft Entra ID が認証要求をオンプレミスの Active Directory フェデレーション サービス (AD FS) にリダイレクトしないという事実に関連しています。
  • 図では、ローカルの Active Directory、Microsoft Entra Connect、Microsoft Entra ID、AD FS、および Web アプリケーション プロキシの各コンポーネント間の基本的な対話を黒い破線で示しています。 こうした対話の詳細については、「ハイブリッド ID で必要なポートとプロトコル」を参照してください。
  • Exchange On-premises は、最新の更新プログラム とメールボックスの役割を適用した Exchange 2019 を表しています。
  • 実際の環境では、サーバーが 1 台のみではありません。 高可用性を実現するために、負荷分散された Exchange サーバー アレイを使用していることもあります。 ここで説明するシナリオは、その構成に適したものです。

考えられるユース ケース

このアーキテクチャは、次のシナリオに関連しています。

  • EMI セキュリティの強化。
  • ゼロ トラスト セキュリティ戦略の導入。
  • Exchange Online への移行時または共存時のオンプレミス メッセージング サービスに対する標準の高レベル保護の適用。
  • 非公開または高度にセキュリティ保護された組織 (金融分野の組織など) での厳格なセキュリティまたはコンプライアンスの要件の強制的な適用。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

可用性

全体的な可用性は、関係するコンポーネントの可用性に依存します。 可用性の詳細については、次のリソースを参照してください。

オンプレミス ソリューションのコンポーネントの可用性は、実装した設計、ハードウェアの可用性、および内部の操作と保守のルーチンに応じて異なります。 こうしたコンポーネントの一部の可用性の詳細については、次のリソースを参照してください。

ハイブリッド先進認証を使うには、ネットワーク上のすべてのクライアントが Microsoft Entra ID にアクセスできることを確認する必要があります。 また、Office 365 ファイアウォール ポートと IP 範囲の開放を常に維持する必要があります。

Exchange Server のプロトコルとポートの要件については、オンプレミスの Skype for Business および Exchange サーバーでのハイブリッド先進認証の使用の概要を説明した記事の、「Exchange クライアントとプロトコルの要件」のセクションを参照してください。

Office 365 の IP 範囲とポートについては、「Office 365 URL および IP アドレス範囲」を参照してください。

ハイブリッド先進認証とモバイル デバイスの詳細については、「Office 365 IP アドレスと URL Web サービスに含まれない他のエンドポイント」の AutoDetect エンドポイントに関するセクションを参照してください。

回復性

このアーキテクチャに含まれるコンポーネントの回復性の詳細については、次のリソースを参照してください。

セキュリティ

モバイル デバイスのセキュリティに関する一般的なガイダンスについては、「Microsoft Intune を使用してデータとデバイスを保護する」を参照してください。

セキュリティとハイブリッド先進認証の詳細については、「詳細情報: ハイブリッド認証のしくみ」を参照してください。

従来の強力な境界保護を使用しているクローズドな組織の場合、Exchange ハイブリッド クラシック構成に関連するセキュリティ上の問題があります。 Exchange ハイブリッド モダン構成は、ハイブリッド先進認証をサポートしていません。

Microsoft Entra ID については、「Microsoft Entra セキュリティ オペレーション ガイド」を参照してください。

AD FS セキュリティを使用するシナリオの詳細については、次の記事を参照してください。

コストの最適化

実装にかかるコストは、Microsoft Entra ID と Microsoft 365 のライセンスのコストによって異なります。 合計コストには、オンプレミス コンポーネントのソフトウェアとハードウェアのコスト、IT 運用、トレーニングと教育、およびプロジェクト実装のコストも含まれます。

これらのソリューションには、少なくとも Microsoft Entra ID P1 が必要です。 価格の詳細については、Microsoft Entra の価格に関するページを参照してください。

AD FS と Web アプリケーション プロキシの詳細については、「Windows Server 2022 の価格とライセンス体系」を参照してください。

価格の詳細については、次のリソースを参照してください。

パフォーマンス効率

パフォーマンスは、関係するコンポーネントのパフォーマンスと企業のネットワーク パフォーマンスに依存します。 詳細については、「ベースラインとパフォーマンス履歴を使用した Office 365 パフォーマンスのチューニング」を参照してください。

AD FS サービスが含まれるシナリオのパフォーマンスに影響するオンプレミスの要因の詳細については、次のリソースを参照してください。

スケーラビリティ

AD FS スケーラビリティの詳細については、「AD FS サーバーの容量の計画」を参照してください。

Exchange Server オンプレミスのスケーラビリティの詳細については、「Exchange 2019 の優先アーキテクチャ」を参照してください。

このシナリオのデプロイ

このインフラストラクチャを実装するには、次の記事に含まれるガイダンスで説明されている手順を完了する必要があります。 手順の概要は次のとおりです。

  1. 先進認証の実装手順で説明されているとおり、Outlook モバイル アクセスをセキュリティで保護します。
  2. Microsoft Entra ID レベルで、他のすべてのレガシ認証の試行をブロックします。
  3. 認証ポリシーを使用して、メッセージング サービス レベルでのレガシ認証の試行をブロックします。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Pavel Kondrashov | クラウド ソリューション アーキテクト
  • Ella Parkum | プリンシパル カスタマー ソリューション アーキテクト - エンジニアリング

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ