【第4回】Windows Server 2025：DMZへのWAP（Web Application Proxy）構築とリバースプロキシ設計

前回の第3回では、オンプレミス環境とM365（Entra ID）をつなぐ認証の心臓部「ADFS（Active Directory Federation Services）」を構築し、証明書の管理やgMSA（グループ管理サービスアカウント）の導入といった、セキュアなIdP（Identity Provider）のコア部分を完成させました。

しかし、ADFSは社内ネットワークの最深部に存在する極めてセンシティブなサーバーです。これを直接インターネットに公開することは、城の門を開け放つようなものであり、セキュリティアーキテクチャ上、絶対に許されません。そこで登場するのが、DMZ（非武装地帯）に配置され、インターネットからの認証トラフィックを安全に受け止めて内部のADFSへ中継するリバースプロキシ「WAP（Web Application Proxy）」です。

本記事では、Linuxエンジニアが日常的に扱うNginxやHAProxyといったリバースプロキシとWAPの違いをプロトコルレベルで比較しながら、Windows Server 2025環境におけるWAPの設計思想、スプリットブレインDNSのトラップ、そしてPowerShellを用いた完全CUIでのWAP構築手順を、圧倒的な情報密度で徹底解説します。

---

1. WAP（Web Application Proxy）の真の役割とアーキテクチャ

DMZ（DeMilitarized Zone）は、インターネットからの不特定多数のアクセスを受け止める過酷なネットワークセグメントです。ここに配置されるWAPは、ADFSを背後に隠し、認証基盤をサイバー攻撃から守る「最強の盾」として機能します。

1-1. 単なるリバースプロキシ（Nginx/HAProxy）との決定的な違い

Linuxエンジニアであれば、「HTTPSのリクエストを内部のサーバーへ転送するだけなら、NginxやApacheのリバースプロキシ機能で十分ではないか」と考えるでしょう。事実、HTTPレベルでのルーティングはNginxでも可能です。しかし、M365ハイブリッド認証環境において、WAPの代替としてサードパーティのプロキシを使用することはMicrosoftのサポート要件から外れるだけでなく、機能的に大きな制約が生じます。

比較項目	WAP (Windows Server 2025)	一般的なリバースプロキシ (Nginx等)
ADFSとの信頼関係	MS-ADFSPIPプロトコルによる証明書ベースの相互認証（Proxy Trust）	単なるHTTPSパケットの転送のみ（信頼関係なし）
エクストラネット防御	WAP層でのパスワード総当たりブロック（ADDSロックアウト防止）が可能	リクエストをそのまま通すため、ADDSが直接ロックアウト攻撃を受ける
事前認証機能	ADFSと連携し、認証済みユーザーのみ社内Webアプリへ転送（Pre-Auth）	別途KeycloakやOauth2-Proxy等との複雑な連携が必要
デバイス認証	証明書ベースのデバイス認証（Windows Hello等）を透過的にサポート	クライアント証明書のパススルー設定が極めて難解

1-2. MS-ADFSPIP（ADFS Proxy Integration Protocol）の仕組み

WAPがNginxと根本的に異なるのは、内部のADFSとの間にMS-ADFSPIP（ADFS Proxy Integration Protocol）という独自の通信チャネルを確立する点です。
WAPを構築する際、WAPはADFSに対して「自分は正当なプロキシである」という登録リクエストを送ります。ADFSはこれを承認し、WAPに対して「プロキシ信頼証明書（Proxy Trust Certificate）」を発行します。以降、WAPはこの証明書を用いてADFSと長時間の暗号化セッションを維持し、ADFSの設定変更（公開するエンドポイントの追加など）を自動的にプル（Pull）して自分自身の設定に反映させます。

これにより、インフラ管理者はWAPの設定ファイルを直接いじることなく、内部のADFS側で設定を変更するだけで、DMZのWAP群へ透過的に設定を波及させることができるのです。

1-3. セキュリティの要「エクストラネットロックアウト」

前述の表でも触れましたが、WAPを採用する最大の理由は「エクストラネットロックアウト」機能です。
悪意のある攻撃者がインターネットからM365（Entra ID）経由で、特定のアカウントにブルートフォース（総当たり）攻撃を仕掛けたとします。認証リクエストはWAPを通り、ADFS、そしてADDSへ到達します。もしWAPが存在しない、あるいはNginxであった場合、ADDS側で「連続ログイン失敗」がカウントされ、ADDSのセキュリティポリシーによってアカウントがロックされます。その結果、そのユーザーは社内LAN（イントラネット）にいる社給PCからもログインできなくなり、業務が完全に停止します（サービス拒否・DoS状態）。

WAPのエクストラネットロックアウトを有効にすると、ADFSは「外部（WAP経由）からの失敗」と「内部からの失敗」を明確に区別し、外部からの攻撃のみをWAP層で遮断（ロックアウト）します。これにより、社内からの正当な業務アクセスは保護され続けるという、極めて高度な防御機構が実現します。

2. WAP配置におけるDMZのネットワーク・DNS設計

WAPはADドメイン（linuxkoubou.local）に参加させる必要はありません。むしろ、DMZのサーバーが侵害された際の影響を最小限にするため、ワークグループ（ドメイン非参加）環境で構築することがセキュリティのベストプラクティスです。

2-1. ファイアウォール要件（IN/OUTの厳格なポート制御）

WAPの前後にはファイアウォールが存在します。Linuxエンジニアが iptables や firewalld、あるいはハードウェアFWで設定すべきポート要件は以下の通り非常にシンプルです。

• インターネット → WAP (DMZ)
  • TCP 443 (HTTPS)：M365や外部クライアントからの認証トラフィック
  • TCP 80 (HTTP)：※証明書失効リスト(CRL)の確認用としてのみ許可を推奨
• WAP (DMZ) → 内部ネットワーク (ADFS)
  • TCP 443 (HTTPS)：MS-ADFSPIP通信、および認証トラフィックのプロキシ用

※重要：WAPからADDS（ドメインコントローラー）への通信（TCP 389, 88, 53など）は一切不要です。WAPはあくまでADFSとしか通信しません。

2-2. スプリットブレインDNS（Split-Brain DNS）の落とし穴

ここで、M365連携における最大の関門である「DNS設計」に直面します。第3回で、ADFSのファーム名を sts.linuxkoubou.com に設定しました。

社内にいるユーザーがブラウザで sts.linuxkoubou.com にアクセスした場合は、社内DNS（ADDS）によって内部のADFSのIPアドレス（または内部ロードバランサーのVIP）に名前解決され、WAPを通さずに直接ADFSへアクセスする必要があります（これをイントラネットアクセスと呼びます）。

一方、自宅や社外のインターネットにいるユーザーが sts.linuxkoubou.com にアクセスした場合は、パブリックDNS（Route53等）によってDMZのWAPの外部IPアドレス（第5回で構築するAlmaLinux LVSのVIP）に名前解決される必要があります。
このように、アクセスする場所によって同じFQDNが異なるIPアドレスに解決される構成を「スプリットブレインDNS（Split-Brain DNS）」と呼びます。

2-3. WAPサーバー自身のhostsファイルによる名前解決の強制

非常に鋭い質問です！WAPがリクエストを受け取った後、それを内部のADFSへプロキシするためには、WAP自身が sts.linuxkoubou.com を内部のADFSのIPアドレスとして解決できなければなりません。もしWAPがパブリックDNSを参照していると、自分自身の外部IPを解決してしまい、ルーティングの無限ループが発生してしまいます。

WAPはドメインに参加していないワークグループ環境であるため、社内DNSを参照させるのはセキュリティ上好ましくありません。したがって、プロの現場ではWAPサーバーのローカルの hosts ファイルに内部ADFSのIPをハードコードする手法がベストプラクティスとして採用されます。

# WAPサーバー（Windows Server 2025）のPowerShellを管理者権限で実行
# hostsファイルに内部ADFS（または内部LVS VIP）のIPを追記する
$hostsFile = "$env:windir\System32\drivers\etc\hosts"
$adfsIp = "192.168.10.20" # 内部ADFSまたは内部ロードバランサーのVIP
$adfsFqdn = "sts.linuxkoubou.com"

Add-Content -Path $hostsFile -Value "$adfsIp`t$adfsFqdn"

# 確認
Get-Content -Path $hostsFile

この設定を忘れると、後述するプロキシ信頼の確立で確実にエラー（Remoteサーバーに接続できません）となります。

3. 証明書（SSL/TLS）の移行と事前準備

WAPはHTTPSリクエストを受け止めるため、第3回でADFSにインストールしたものと全く同じSSL/TLS証明書（秘密鍵付き）をWAPサーバーにもインストールしておく必要があります。

3-1. ADFSからの証明書エクスポート（秘密鍵付き）

証明書の原本（.pfxファイル）が手元にあればそれを使いますが、もしADFSサーバーにしかない場合は、ADFSサーバーからエクスポートします。

# --- ADFSサーバー側での作業 ---
# 証明書ストアから対象の証明書を検索し、秘密鍵を含めてPFXファイルとしてエクスポート
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -match "sts.linuxkoubou.com"}
$password = ConvertTo-SecureString -String "ExportPassword123!" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:\temp\adfs_cert.pfx" -Password $password

エクスポートした adfs_cert.pfx を、安全な経路（SCP等）でDMZのWAPサーバーへ転送します。

3-2. WAPサーバーへの証明書インポートと確認（PowerShell）

転送した証明書を、WAPサーバーの「ローカルコンピューターの個人ストア」へインポートします。

# --- WAPサーバー側での作業 ---
# パスワードを指定して証明書をインポート
$certPassword = ConvertTo-SecureString -String "ExportPassword123!" -Force -AsPlainText
$cert = Import-PfxCertificate -FilePath "C:\temp\adfs_cert.pfx" -CertStoreLocation "Cert:\LocalMachine\My" -Password $certPassword

# インポートした証明書のThumbprint（ハッシュ値）を変数に格納（構築時に使用します）
$thumbprint = $cert.Thumbprint
Write-Output "WAP Certificate Thumbprint: $thumbprint"

4. Windows Server 2025：WAPのインストールと構成（PowerShell）

ネットワークと証明書の準備が整いました。いよいよWAPの役割をインストールし、ADFSとの間にプロキシ信頼（Proxy Trust）を確立します。

4-1. リモートアクセス（Web Application Proxy）役割の追加

Windows Server 2025において、WAPは「リモートアクセス」というサーバーの役割の一部として提供されています。GUIのサーバーマネージャーは使わず、PowerShellで一貫して構築します。

# WAPサーバーのPowerShellを管理者権限で実行
# Web Application Proxy役割のインストール
Install-WindowsFeature -Name Web-Application-Proxy -IncludeManagementTools

4-2. Proxy Trust（プロキシ信頼）の確立スクリプト

インストール後、WAPを構成します。このコマンドを実行する際、WAPは内部のADFSに対してHTTPSでアクセスし、「自分をプロキシとして認めてくれ」という要求を出します。そのため、ADFSのローカル管理者（またはドメインのADFS管理者）の認証情報をスクリプトに渡す必要があります。

# ADFS管理者の資格情報を安全に入力するダイアログを表示
$cred = Get-Credential -UserName "linuxkoubou\administrator" -Message "ADFSサーバーの管理者パスワードを入力してください"

# WAPの初期構成（Proxy Trustの確立）
Install-WebApplicationProxy `
    -CertificateThumbprint $thumbprint `
    -FederationServiceName "sts.linuxkoubou.com" `
    -WebApplicationProxyCredential $cred

裏側で何が起きているか（Linuxエンジニア向け解説）：
このコマンドを叩くと、WAPは https://sts.linuxkoubou.com/adfs/services/trust/proxyevaluation という隠しエンドポイントにアクセスします。資格情報が承認されると、ADFSはWAP専用の新しい証明書（Proxy Trust Certificate）を発行し、WAPに返却します。以降、WAPはこの証明書を使ってADFSへのリバースプロキシを透過的に実行します。

4-3. 動作確認とHTTP.sysの証明書バインディングチェック

構成が完了したら、WAPが正しくポート443をリッスンし、証明書がバインド（紐付け）されているかを確認します。Windowsでは netsh コマンドでHTTP.sys（カーネルモードのHTTPリスナー）の状態を確認できます。

# WAPのサービス状態確認
Get-WebApplicationProxyConfiguration

# ポート443（HTTPS）に対する証明書のバインド状況を確認
netsh http show sslcert

ここで IP:port : 0.0.0.0:443 に対して、先ほどインポートした証明書のハッシュ値が割り当てられていれば成功です。

5. エクストラネットロックアウトの有効化とプロの運用監視

WAPが構築できたら、M365認証環境を保護するための本命機能「エクストラネットロックアウト」を有効化します。この設定はDMZのWAP側ではなく、内部ネットワークのADFSサーバー側で設定します。

5-1. アカウントロックアウトのしきい値設定（PowerShell）

内部のADDS（ドメインコントローラー）のロックアウトしきい値が「10回」で設定されている場合、ADFSのエクストラネットロックアウトのしきい値はそれより少ない「5回」程度に設定し、内部ADDSがロックアウトされる前にWAP側で遮断するように設計します。

# --- 内部のADFSサーバー（ADFS01）で実行 ---
# エクストラネットロックアウトを有効化（5回失敗で15分間ブロック）
Set-AdfsProperties `
    -EnableExtranetLockout $true `
    -ExtranetLockoutThreshold 5 `
    -ExtranetObservationWindow (New-TimeSpan -Minutes 15)

# 設定の確認
Get-AdfsProperties | Select-Object EnableExtranetLockout, ExtranetLockoutThreshold, ExtranetObservationWindow

これにより、外部からパスワード総当たり攻撃を受けた場合、WAP層でパケットがドロップ（あるいは認証エラーのダミーページが返却）され、社内LANにいる該当ユーザーは問題なく業務を継続できます。

5-2. イベントビューアー（Event ID 422 / 245）による疎通監視

WAPとADFS間の「プロキシ信頼」は、証明書ベースのセキュアなチャネルですが、ごく稀にネットワークの瞬断等で信頼関係が失効することがあります。
Linuxエンジニアが監視システム（Zabbix等）を設計する際は、WAPサーバーの「イベントビューアー > サーバーマネージャー > Web Application Proxy」のログを監視し、以下のEvent IDをトリガーとしてアラートを上げるように構成するのがプロの運用です。

• Event ID 422: ADFSとのプロキシ信頼証明書を正常に更新できなかったエラー（放置すると認証が全滅します）。
• Event ID 245: バックエンドのADFSサーバーへの接続に失敗した（HTTP 503エラー等）。

6. 第4回の総まとめと次回の予告

本記事では、M365ハイブリッド認証におけるDMZの防波堤「WAP（Web Application Proxy）」について、単なるリバースプロキシ（Nginx等）とのアーキテクチャの違いから、スプリットDNSの罠、そしてPowerShellを用いた完全CUIでの構築手法までを解説しました。

ADFSという高度なIdPをインターネットの脅威から守り、かつADDSのパスワードロックアウト攻撃を防ぐ「エクストラネットロックアウト」を実現するためには、WAPとADFSの「プロキシ信頼（MS-ADFSPIP）」という独自の連携メカニズムの理解が不可欠です。Linuxエンジニアであっても、このHTTPプロキシの深淵を知ることで、ネットワーク全体の設計力は劇的に向上します。

さて、これでバックエンドのADDS/ADFSとフロントエンドのWAPが完成しました。しかし、現状は「1台のWAP」が全てのトラフィックを受け止めている単一障害点（SPOF）です。
次回の【第5回】AlmaLinux 9：LVSとKeepalivedによるWAP負荷分散クラスターの構築では、いよいよ私たちLinuxエンジニアのホームグラウンドに戻ります。複数台構築したWAPサーバーの前段に、AlmaLinux 9とLinuxカーネルのIPVSモジュールを用いた圧倒的なスループットを誇るL4ロードバランサー（LVS）を構築し、M365認証のトラフィックを高速にさばく最強のロードバランシングアーキテクチャを完成させます。お楽しみに！