この参照アーキテクチャは、オンプレミス ネットワークを Azure に拡張する安全なハイブリッド ネットワークを実装し、Active Directory フェデレーション サービス (AD FS) を使用して、Azure で実行されているコンポーネントのフェデレーション認証と承認を実行します。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
注意
Visio ファイルには、ダイアグラムの 4 つのタブが含まれています。 [AD FS] タブを選ぶと、この記事に関連するアーキテクチャ ダイアグラムが表示されます。
ワークフロー
AD DS サブネット。 AD DS サーバーは、ネットワーク セキュリティ グループ (NSG) 規則がファイアウォールとして機能している独自のサブネットに含まれています。
AD DS サーバー。 Azure で VM として実行されているドメイン コントローラー。 これらのサーバーは、ドメイン内のローカル ID の認証を提供します。
AD FS サブネット。 AD FS サーバーは、NSG 規則がファイアウォールとして機能している独自のサブネット内に存在します。
AD FS サーバー。 AD FS サーバーは、フェデレーション承認と認証を提供します。 このアーキテクチャでは、以下のタスクを実行します。
パートナー ユーザーの代わりにパートナー フェデレーション サーバーが作成した要求を含むセキュリティ トークンを受け取ります。 AD FS は、トークンが有効であることを確認してから、要求の承認のために、Azure で実行されている Web アプリケーションに要求を渡します。
Azure で実行されるアプリケーションが "証明書利用者" になります。 パートナー フェデレーション サーバーは、Web アプリケーションで認識される要求を発行する必要があります。 パートナー フェデレーション サーバーは、取引先組織内の認証済みアカウントに代わってアクセス要求を送信するため、"アカウント パートナー" と呼ばれます。 AD FS サーバーは、リソース (Web アプリケーション) へのアクセスを提供するため、"リソース パートナー" と呼ばれます。
Web アプリケーションへのアクセスを必要とする Web ブラウザーまたはデバイスを実行している外部ユーザーから受信した要求の認証と承認を、AD DS と Active Directory Device Registration Service を使用して行います。
AD FS サーバーは、Azure ロード バランサーを通じてアクセスされるファームとして構成されています。 この実装により、可用性とスケーラビリティが向上します。 AD FS サーバーは、インターネットに直接公開されません。 すべてのインターネット トラフィックは、AD FS Web アプリケーション プロキシ サーバーと DMZ (境界ネットワークとも呼ばれます) を介してフィルター処理されます。
AD FS のしくみの詳細については、Active Directory フェデレーション サービスの概要に関する記事を参照してください。 また、Azure での AD FS デプロイに関する記事には、実装の詳細な手順が記載されています。
AD FS プロキシ サブネット。 AD FS プロキシ サーバーは、独自のサブネット内に含めることができ、NSG 規則によって保護が提供されます。 このサブネット内のサーバーは、Azure 仮想ネットワークとインターネットの間にファイアウォールを提供する一連のネットワーク仮想アプライアンスを通じて、インターネットに公開されます。
AD FS Web アプリケーション プロキシ (WAP) サーバー。 これらの VM は、取引先組織と外部デバイスからの受信要求に対する AD FS サーバーとして機能します。 WAP サーバーはフィルターとして機能し、インターネットからの直接アクセスから AD FS サーバーを保護します。 AD FS サーバーと同様に、負荷分散されているファームに WAP サーバーをデプロイすると、一連のスタンドアロン サーバーをデプロイする場合よりも可用性とスケーラビリティが向上します。
注意
WAP サーバーのインストールの詳細については、「Web アプリケーション プロキシ サーバーをインストールし、構成する」を参照してください。
取引先組織。 Azure で実行されている Web アプリケーションへのアクセスを要求する、Web アプリケーションを実行している取引先組織。 取引先組織のフェデレーション サーバーは、ローカルで要求を認証し、要求が含まれているセキュリティ トークンを Azure で実行されている AD FS に送信します。 Azure の AD FS はセキュリティ トークンを検証し、有効であれば、Azure で実行されている Web アプリケーションに要求を渡して承認することができます。
Note
信頼できるパートナーに AD FS への直接アクセスを提供するように、Azure ゲートウェイを使用して VPN トンネルを構成することもできます。 これらのパートナーから受信した要求は、WAP サーバーをパススルーしません。
コンポーネント
このアーキテクチャは、Azure への AD DS の拡張に関するページで説明されている実装を拡張します。 それには、以下のコンポーネントが含まれています。
シナリオの詳細
AD FS はオンプレミスでホストできますが、アプリケーションがハイブリッドで、その一部が Azure に実装されている場合、クラウドに AD FS をレプリケートする方がより効率的な場合があります。
前述のダイアグラムは、次のシナリオを示します。
- 自社の Azure VNet 内でホストされている Web アプリケーションに、取引先組織のアプリケーション コードがアクセスします。
- 自社の Azure VNet 内でホストされている Web アプリケーションに、資格情報が Active Directory Domain Services (DS) 内に格納されている外部登録ユーザーがアクセスします。
- 承認済みのデバイスを使用して自社の VNet に接続しているユーザーが、自社の Azure VNet 内でホストされている Web アプリケーションを実行します。
この参照アーキテクチャでは、"パッシブ フェデレーション" に焦点を当てています。この場合、フェデレーション サーバーがユーザーの認証方法とタイミングを決定します。 ユーザーは、アプリケーションの起動時にサインイン情報を指定します。 このメカニズムは、Web ブラウザーで最もよく使用され、ユーザーが認証するサイトにブラウザーをリダイレクトするプロトコルが含まれています。 AD FS は、"アクティブ フェデレーション" もサポートしています。この場合、アプリケーションはユーザーによる操作なしで資格情報を提供する責任を負いますが、そのシナリオはこのアーキテクチャの範囲外です。
その他の考慮事項については、「オンプレミスの Active Directory を Azure と統合するソリューションの選択」をご覧ください。
考えられるユース ケース
このアーキテクチャの一般的な用途は次のとおりです。
- ワークロードの一部がオンプレミスで、一部が Azure で実行されるハイブリッド アプリケーション。
- フェデレーション承認を使用して Web アプリケーションを取引先組織に公開するソリューション。
- 組織のファイアウォールの外部で実行されている Web ブラウザーからのアクセスをサポートするシステム。
- リモート コンピューター、ノートブック、その他のモバイル デバイスなどの承認された外部デバイスから接続することで、ユーザーが Web アプリケーションにアクセスできるようにするシステム。
推奨事項
ほとんどのシナリオには、次の推奨事項が適用されます。 これらの推奨事項には、オーバーライドする特定の要件がない限り、従ってください。
ネットワークの推奨事項
AD FS サーバーおよび WAP サーバーをホストしている各 VM のネットワーク インターフェイスを、静的プライベート IP アドレスを使用して構成します。
AD FS VM にパブリック IP アドレスを指定しないでください。 詳細については、「セキュリティに関する考慮事項」セクションを参照してください。
各 AD FS VM および WAP VM のネットワーク インターフェイスが Active Directory DS VM を参照するように、優先およびセカンダリ ドメイン ネーム サービス (DNS) サーバーの IP アドレスを設定します。 Active Directory DS VM では、DNS が実行されている必要があります。 この手順は、各 VM がドメインに参加できるようにするために必要です。
AD FS のインストール
フェデレーション サーバー ファームのデプロイに関する記事には、AD FS のインストールと構成の詳細な手順が記載されています。 ファーム内の最初の AD FS サーバーを構成する前に、次のタスクを実行してください。
サーバー認証を行うために一般的に信頼されている証明書を取得します。 "サブジェクト名" には、クライアントがフェデレーション サービスへのアクセスに使用する名前を含める必要があります。 これは、
adfs.contoso.comなどのロード バランサーに登録されている DNS 名でかまいません。 (セキュリティ上の理由から、*.contoso.comなどのワイルドカード名の使用は避けてください)。 すべての AD FS サーバー VM では同じ証明書を使用します。 信頼された証明機関から証明書を購入できますが、組織で Active Directory 証明書サービスを使用している場合は、独自の証明書を作成できます。"サブジェクトの別名" は、外部デバイスからのアクセスを可能にするために、デバイス登録サービス (DRS) によって使用されます。 これは
enterpriseregistration.contoso.comの形式でなければなりません。詳細については、AD FS 用の Secure Sockets Layer (SSL) 証明書の取得と構成に関する記事を参照してください。
ドメイン コントローラーで、キー配布サービスの新しいルート キーを生成します。 有効時間を現在の時刻から 10 時間差し引いた時間に設定します (この構成により、ドメイン全体でのキーの配布と同期で発生する可能性のある遅延が軽減されます)。 この手順は、AD FS サービスの実行に使用されるグループ サービス アカウントの作成をサポートするために必要です。 次の PowerShell コマンドは、その実行方法の例を示しています。
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)各 AD FS サーバー VM をドメインに追加します。
Note
AD FS をインストールするには、ドメインでプライマリ ドメイン コントローラー (PDC) エミュレーターの Flexible Single Master Operation (FSMO) ロールを実行しているドメイン コントローラーが実行されていて、AD FS VM からアクセス可能である必要があります。
AD FS の信頼
AD FS インストールと、すべての取引先組織のフェデレーション サーバーとの間で、フェデレーションの信頼を確立します。 必要な任意の要求のフィルターおよびマッピングを構成します。
- 各取引先組織の DevOps スタッフは、AD FS サーバーを介してアクセス可能な Web アプリケーションの証明書利用者信頼を追加する必要があります。
- 所属する組織の DevOps スタッフは、取引先組織から提供される要求を AD FS サーバーが信頼できるように、要求とプロバイダー間の信頼を構成する必要があります。
- 所属する組織の DevOps スタッフは、組織の Web アプリケーションに要求を渡すように AD FS を構成する必要もあります。
詳細については、「フェデレーションの信頼の確立」を参照してください。
組織の Web アプリケーションを発行し、それを外部パートナーが使用できるようにするには、WAP サーバーを介した事前認証を使用します。 詳細については、「AD FS 事前認証を使用してアプリケーションを公開する」を参照してください。
AD FS は、トークンの変換と拡張をサポートしています。 Microsoft Entra ID にこの機能はありません。 AD FS を使用した場合、信頼関係を設定する際に、次のことが可能です。
- 承認規則の要求変換を構成する。 たとえば、Microsoft 以外の取引先組織で使用されている表現のグループ セキュリティを、所属組織内で Active Directory DS が承認できるものにマップできます。
- 要求の形式を変換する。 たとえば、アプリケーションで SAML 1.1 要求のみがサポートされている場合は、SAML 2.0 から SAML 1.1 にマップすることができます。
AD FS の監視
Active Directory フェデレーション サービス 2012 R2 用 Microsoft System Center 管理パックを使用すると、フェデレーション サーバーの AD FS デプロイをプロアクティブにもリアクティブにも監視することができます。 この管理パックで監視するものは次のとおりです。
- AD FS サービスがイベント ログに記録するイベント。
- AD FS パフォーマンス カウンターで収集されるパフォーマンス データ。
- AD FS システムおよび Web アプリケーション (証明書利用者) の全体的な正常性。重大な問題や警告のアラートも提供されます。
もう 1 つのオプションは、Microsoft Entra Connect Health を使って AD FS を監視することです。 Microsoft Entra Connect Health には、オンプレミス ID インフラストラクチャの堅牢な監視機能が用意されています。 Microsoft 365 や Microsoft Online Services への信頼性の高い接続を維持することができます。 この信頼性は、主要な ID コンポーネントの監視機能を提供することで実現されます。 また、これらのコンポーネントに関する主要なデータ ポイントにアクセスしやすくなります。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
「AD FS の配置を計画する」の記事から要約された以下の考慮事項は、AD FS ファームのサイズ設定の出発点となります。
- ユーザーが 1,000 人未満の場合は、専用サーバーを作成するのではなく、その代わりに、クラウド内の各 Active Directory DS サーバーに AD FS をインストールします。 可用性を維持するために、少なくとも 2 台の Active Directory DS サーバーがあることを確認してください。 1 つの WAP サーバーを作成します。
- ユーザーが 1,000 から 15,000 人の場合は、2 台の専用 AD FS サーバーと、2 台の専用 WAP サーバーを作成します。
- ユーザーが 15,000 から 60,000 人の場合は、3 から 5 台の専用 AD FS サーバーと、少なくとも 2 台の専用 WAP サーバーを作成します。
これらの考慮事項では、Azure でデュアル クアッドコア VM (Standard D4_v2 以上) サイズを使用していることを想定しています。
AD FS 構成データを Windows Internal Database に格納している場合、ファーム内の AD FS サーバーは 8 台に制限されます。 将来さらに必要となることが予想される場合は、SQL Server を使用してください。 詳細については、「AD FS 構成データベースの役割」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。
サービスの可用性を向上させるには、少なくとも 2 台のサーバーを含む AD FS ファームを作成します。 ファーム内の AD FS VM ごとに異なるストレージ アカウントを使用します。 このアプローチにより、1 つのストレージ アカウントに障害が発生しても、ファーム全体にアクセスできなくなることを回避します。
AD FS VM と WAP VM に個別の Azure 可用性セットを作成します。 各セットに少なくとも 2 つの VM があることを確認します。 各可用性セットには、少なくとも 2 つの更新ドメインと 2 つの障害ドメインが必要です。
AD FS VM および WAP VM のロード バランサーを次のように構成します。
Azure ロード バランサーを使用して WAP VM への外部アクセスを提供し、内部ロード バランサーを使用してファーム内の AD FS サーバー間で負荷を分散します。
ポート 443 (HTTPS) で生じるトラフィックのみを AD FS/WAP サーバーに渡します。
ロード バランサーに静的 IP アドレスを指定します。
/adfs/probeに対して HTTP を使用して、正常性プローブを作成します。 詳細については、「Hardware Load Balancer Health Checks and Web Application Proxy / AD FS 2012 R2 (ハードウェア ロード バランサー正常性チェックと Web アプリケーション プロキシ/AD FS 2012 R2)」を参照してください。注意
AD FS サーバーは Server Name Indication (SNI) プロトコルを使用しているため、ロード バランサーから HTTPS エンドポイントを使用してプローブしようとすると失敗します。
AD FS ロード バランサーのドメインに DNS A レコードを追加します。 ロードバランサーの IP アドレスを指定し、ドメイン内の名前 (
adfs.contoso.comなど) を付けます。 これは、クライアントと WAP サーバーが AD FS サーバー ファームにアクセスする際に使用する名前です。
AD FS の構成情報を保持するには、SQL Server または Windows Internal Database を使用できます。 Windows Internal Database は、基本的な冗長性を提供します。 変更は AD FS クラスター内の 1 つの AD FS データベースだけに直接書き込まれる一方で、他のサーバーはプル レプリケーションを使用してそれらのデータベースを最新の状態に保ちます。 SQL Server を使用すると、フェールオーバー クラスタリングまたはミラーリングを使用してデータベースの完全な冗長性と高可用性を実現できます。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
AD FS では HTTPS が使用されるため、Web 層の VM が含まれているサブネットの NSG 規則で HTTPS 要求が許可されていることを確認してください。 これらの要求は、オンプレミス ネットワークのほか、Web 層、ビジネス層、データ層、プライベート DMZ、パブリック DMZ を含むサブネットや AD FS サーバーを含むサブネットから発信される場合があります。
AD FS サーバーがインターネットに直接公開されないようにします。 AD FS サーバーは、セキュリティ トークンを付与するための完全な権限を持つ、ドメイン参加コンピューターです。 サーバーが侵害されると、悪意のあるユーザーは、すべての Web アプリケーションのほか、AD FS によって保護されているすべてのフェデレーション サーバーに対するフル アクセス トークンを発行できます。 信頼できるパートナー サイトから接続されていない外部ユーザーからの要求をシステムで処理する必要がある場合は、WAP サーバーを使用してそれらの要求を処理します。 詳細については、「フェデレーション サーバー プロキシを配置する場所」を参照してください。
AD FS サーバーと WAP サーバーをそれぞれ独自のファイアウォールを持つ別々のサブネットに配置します。 NSG 規則を使用してファイアウォール規則を定義できます。 すべてのファイアウォールは、ポート 443 (HTTPS) のトラフィックを許可する必要があります。
AD FS サーバーおよび WAP サーバーへの直接的なサインイン アクセスを制限します。 DevOps スタッフだけが接続できるようにしてください。 WAP サーバーをドメインに参加させないでください。
監査のために、仮想ネットワークの境界を越えるトラフィックに関する詳細情報を記録する一連のネットワーク仮想アプライアンスの使用を検討してください。
コスト最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
ここでは、このアーキテクチャで使用されるサービスのコストに関する考慮事項を示します。
AD Domain Services
コストを削減するために、複数のワークロードで使用される共有サービスとして Active Directory Domain Services を使用することを検討してください。 詳細については、「Active Directory Domain Services の価格」を参照してください。
Active Directory フェデレーション サービス (AD FS)
Microsoft Entra ID で提供されるエディションの情報については、「Microsoft Entra の価格」を参照してください。 AD フェデレーション サービスの機能は、すべてのエディションで使用できます。
オペレーショナル エクセレンス
DevOps スタッフは、以下のタスクの実行を準備する必要があります。
- フェデレーション サーバーの管理 (AD FS ファームの管理、フェデレーション サーバーでの信頼ポリシーの管理、フェデレーション サービスで使用される証明書の管理など)。
- WAP サーバーの管理 (WAP ファームや証明書の管理など)。
- Web アプリケーションの管理 (証明書利用者、認証方法、要求マッピングの構成など)。
- AD FS コンポーネントのバックアップ。
その他 DevOps の考慮事項については、「DevOps: Active Directory Domain Services (AD DS) を Azure に拡張する」をご覧ください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Sarah Parkes | シニア クラウド ソリューション アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。