セキュリティ強化されたハイブリッドメッセージング - Web アクセス

Microsoft Entra ID

Microsoft 365

Office 365

この記事のソリューションでは、メールボックスが Exchange Online または Exchange On-premises でホストされているときに、メッセージングサービス (Outlook on the web または Exchange コントロールパネル) を保護する際に役立つ方法を示します。

アーキテクチャ

このアーキテクチャでは、次のセキュリティについて説明するために、ソリューションを 2 つの領域に分割します。

Exchange Online (図の右側)。
ハイブリッドまたは非ハイブリッドシナリオの Exchange オンプレミス (図の左側)。

このアーキテクチャの Visio ファイルをダウンロードします。

一般的な注意事項

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

Exchange Online ユーザーのフロー

ユーザーは、https://outlook.office.com/owa から Outlook on the web サービスにアクセスしようとします
Exchange Online は、認証のためにユーザーを Microsoft Entra ID にリダイレクトします。

ドメインがフェデレーションの場合、Microsoft Entra ID は認証のためにユーザーをローカルの AD FS インスタンスにリダイレクトします。認証に成功すると、ユーザーは Microsoft Entra ID に戻されます。 (図が簡単になるように、このフェデレーションシナリオは省略しています)。
多要素認証を実施するために、Microsoft Entra ID はブラウザークライアントアプリケーションに対して多要素認証要件のある Azure 条件付きアクセスポリシーを適用します。そのポリシーの設定については、この記事のデプロイのセクションを参照してください。
条件付きアクセスポリシーにより、Microsoft Entra 多要素認証が呼び出されます。ユーザーは多要素認証を完了するように要求されます。
ユーザーが多要素認証を完了します。
Microsoft Entra ID は認証された Web セッションを Exchange Online にリダイレクトして、ユーザーが Outlook にアクセスできるようになります。

Exchange オンプレミスユーザーのフロー

ユーザーは、URL https://mail.contoso.com/owa から Outlook on the web サービスにアクセスしようとします。これは、内部アクセスの場合は Exchange サーバーをポイントし、外部アクセスの場合は Web アプリケーションプロキシサーバーをポイントします。
Exchange オンプレミス (内部アクセスの場合) または Web アプリケーションプロキシ (外部アクセスの場合) は、認証のためにユーザーを AD FS に転送します。
AD FS は、内部アクセスの場合は統合された Windows 認証を使用し、外部アクセスの場合はユーザーが資格情報を入力できる Web フォームを提示します。
AF DS アクセス制御ポリシーに応答して、AD FS が Microsoft Entra 多要素認証を呼び出して認証を完了します。次に、この種類の AD FS アクセス制御ポリシーの例を示します。

ユーザーは多要素認証を完了するように要求されます。
ユーザーが多要素認証を完了します。 AD FS は、認証された Web セッションを Exchange オンプレミスに転送します。
ユーザーは、Outlook にアクセスできます。

オンプレミスユーザーのためのこのシナリオを実装するには、Web アクセス要求を事前認証するための AD FS を設定するように、Exchange と AD FS を構成する必要があります。詳細については、「Outlook on the web で AD FS クレームベース認証を使用する」を参照してください。

また、AD FS と Microsoft Entra 多要素認証の統合を有効にする必要もあります。詳細については、「AD FS で認証プロバイダーとして Azure MFA を構成する」を参照してください。 (この統合には、AD FS 2016 または 2019 が必要です)。最後に、ユーザーを Microsoft Entra ID に同期し、Microsoft Entra 多要素認証のライセンスを割り当てる必要があります。

コンポーネント

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 とアクセス管理が使用できるようになります。このアーキテクチャでは、フェデレーション ID でユーザーのサインインを円滑にするために使用されます。
Web アプリケーションプロキシ。 Web アプリケーションプロキシは、AD FS を使用することで、Web アプリケーションへのアクセスを事前認証します。さらに、AD FS プロキシとしても機能します。
Exchange Server。 Exchange Server は、ユーザーのオンプレミスのメールボックスを管理します。このアーキテクチャでは、Microsoft Entra ID によってユーザーに発行されたトークンを使うことで、メールボックスへのアクセスを認可します。
Active Directory サービス。 Active Directory サービスは、ドメインのメンバーに関する情報 (デバイスとユーザーを含む) を格納します。このアーキテクチャでは、ユーザーアカウントは Active Directory サービスに属していて、Microsoft Entra ID に同期されます。

シナリオの詳細

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

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

ここに示すアーキテクチャでは、メールボックスが Exchange Online または Exchange オンプレミスでホストされているときに、メッセージングサービス (Outlook on the web または Exchange コントロールパネル) を保護する際に役立つシナリオについて説明します。

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

この記事では、その他のプロトコル (IMAP や POP など) については説明しません。それらは、ユーザーアクセスの提供のために使用することをお勧めしません。

考えられるユースケース

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

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

考慮事項

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

[信頼性]

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

可用性

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

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

回復性

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

Microsoft Entra ID の場合: Microsoft Entra の可用性の向上
AD FS を使用するシナリオの場合: Azure Traffic Manager を使用した Azure の高可用性地域間 AD FS デプロイ
Exchange オンプレミスソリューションの場合: Exchange の高可用性

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については、「セキュリティの重要な要素の概要」を参照してください。

このアーキテクチャに含まれるコンポーネントのセキュリティの詳細については、次の資料を参照してください。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

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

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

Exchange の詳細については、「Exchange Server の価格」を参照してください。

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

パフォーマンス効率

パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。詳細については、「パフォーマンス効率の柱の概要」を参照してください。

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

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

スケーラビリティ

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

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

このシナリオのデプロイ

このシナリオをデプロイするには、次に示す大まかな手順を実行します。

Web アクセスサービスから始めます。セキュリティ強化のために、Exchange Online に向けた Azure 条件付きアクセスポリシーを使用します。
オンプレミス EMI に対する Web アクセスのセキュリティを向上するために、AD FS クレームベース認証を使用します。

条件付きアクセスポリシーの設定

この記事の前半にあるオンラインユーザーのフローの手順 3 で説明した、多要素認証を適用する Microsoft Entra 条件付きアクセスポリシーを設定するには:

クラウドアプリとして [Office 365 Exchange Online] または [Office 365] を構成します。
クライアントアプリとして、ブラウザーを構成します。
[許可] ウィンドウで、多要素認証の要件を適用します。

共同作成者

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

プリンシパルの作成者:

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

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

セキュリティ強化されたハイブリッドメッセージング - Web アクセス