Azure Localのファイアウォール要件を見直すなら、結論は「外向き80/443を開けるだけでは不十分」です。Azure LocalはAzure Resource Bridge、AKSインフラ、Azure Arc、Microsoft Update、必要に応じた追加AzureサービスやOEM固有エンドポイントと通信するため、許可リスト、HTTPSインスペクション除外、Arc Private Linkの扱い、Active Directoryやクラスタ内部通信のポートまでセットで確認する必要があります。
Microsoft Learnの「Firewall requirements for Azure Local」は、Azure Local 2311.2以降を対象にしたファイアウォール構成ガイドで、公開ページ上では2026年4月22日に更新されています。特にsecurity admins、identity teams、compliance teamsは、単に「通信できるか」ではなく、「どの宛先を、どの根拠で、どの範囲まで許可するか」を監査可能な形で整理しておくべきです。(Microsoft Learn)
Azure Localのファイアウォール要件で最初に確認すべき結論
Azure Localのファイアウォール設計では、まず次の4点を優先して確認します。
- AzureおよびMicrosoft Updateへ向かうアウトバウンド通信として、TCP 80とTCP 443を許可する
- HTTPSインスペクション、TLS復号、Entra ID tenant restrictions v1をAzure Local管理ネットワーク通信に適用しない
- Azure Arc Private Link ScopesをAzure LocalのArc通信に使える前提で設計しない
- 内部通信では、クラスタノード間、Active Directory、NTP、Windows Admin Center、Hyper-V、Failover Clusteringのポートを個別に確認する
Microsoftの公式ドキュメントでは、Azure LocalがAzureおよびMicrosoft Updateへ接続するために、組織のファイアウォールでアウトバウンドの80/443を開く必要があると説明されています。ただし同時に、Azure LocalインスタンスはAzure Resource Bridge、AKSインフラ、Arc for Serversエージェントを使ってAzureコントロールプレーンへ接続するため、HCI固有のエンドポイントだけでなく、関連コンポーネントのエンドポイントも許可リストに含める必要があります。(Microsoft Learn)
2026年4月22日更新で何が変わったか
2026年4月22日の更新については、公開ページの「Last updated」と、GitHub上の差分を分けて見る必要があります。Microsoft Learnのページ上は2026年4月22日更新ですが、同日のGitHubコミットを見る限り、firewall-requirements.mdの変更は主にauthorとms.authorのメタデータ変更です。つまり、少なくとも公開GitHub差分上では、4月22日に新しいポート要件が追加されたとは読み取れません。(Microsoft Learn)
実務上のポイントは、4月22日の日付だけを見て「ファイアウォール要件が大きく変わった」と判断しないことです。むしろ、現行ページの内容と直近の本文変更を合わせて、既存のファイアウォール設計書、プロキシ例外、ID基盤向け通信、監査証跡を再点検するのが正しい読み方です。
| 確認対象 | 2026年4月時点の読み方 | 管理者が取るべき対応 |
|---|---|---|
| 4月22日の更新 | 公開ページ上は更新日が2026年4月22日 | 最新版として設計レビューに使う |
| GitHub上の4月22日差分 | 本文要件ではなく著者メタデータの変更が中心 | 「新ポート追加」と誤解しない |
| Active Directory要件 | 2026年1月にAD関連ポート一覧が大きく整理 | identity teamsがAD通信を再確認する |
| ICMP要件 | Azure LocalインフラIP範囲から既定ゲートウェイへのICMP要件が追加 | ネットワーク疎通確認ルールを明文化する |
| Storage Replica関連 | 専用セクションが削除され、現行ページでは別の形で内部通信要件を扱う | ストレッチ構成は現行設計ドキュメントと照合する |
2026年1月のGitHub差分では、Active Directoryのファイアウォール要件が単一のADWSルールから、Kerberos、LDAP、DNS、SMB、RPC、ADWSなどを含む一覧へ更新されています。また、Azure LocalインフラIP範囲からインフラサブネットの既定ゲートウェイへICMPを許可するルールも追加されています。(GitHub)
「80/443を開ければ完了」ではない理由
Azure Localの外部通信では、TCP 80と443が基本になります。しかし、セキュリティ運用で重要なのは「ポート番号」だけではなく、「宛先」「経路」「検査方式」「例外管理」です。
たとえば、アウトバウンド443を許可していても、次の状態ではAzure Localの登録、更新、管理、Arc連携で問題が起きやすくなります。
| よくある設定 | 問題になりやすい理由 | 修正の方向性 |
|---|---|---|
| 443は許可しているが宛先が不足 | Azure Local、Arc、ARB、AKS、追加Azureサービスの宛先が揃っていない | リージョン別・サービス別の許可リストを作る |
| SSL/TLSインスペクションを全通信に適用 | Azure LocalはHTTPSインスペクションをサポートしない | Azure Local管理通信を復号対象から除外する |
| Private LinkでArc通信を閉じ込める設計 | Azure LocalはAzure Arc Private Link Scopesをサポートしない | Arcエンドポイントは公開IP解決を前提に設計する |
| プロキシ例外を登録後に考える | Arc登録時に追加FQDNのプロキシバイパスが必要になる可能性がある | 登録前にプロキシバイパス文字列を計画する |
Microsoft Learnでは、Azure LocalはHTTPSインスペクションをサポートせず、通信経路上で無効化する必要があると明記されています。また、Azure Local管理ネットワーク通信ではEntra ID tenant restrictions v1もサポートされないと説明されています。(Microsoft Learn)
Arc Private Linkを前提にしない
Azure Localのファイアウォール要件で特に誤解しやすいのが、Azure Arc Private Link Scopesの扱いです。
Microsoftの公式ドキュメントでは、Azure Arc Private Link ScopesはAzure Localでサポートされないと明記されています。Arc関連の.his.arc.azure.com、.guestconfiguration.azure.com、*.dp.kubernetesconfiguration.azure.comなどのエンドポイントは、Azure Localノード、Azure Resource Bridge VM、利用している場合はプロキシサーバーから、常に公開IPへ名前解決される必要があります。(Microsoft Learn)
これは、compliance teamsにとって重要です。「AzureだからPrivate Linkで閉域化しているはず」という説明は、Azure LocalのArc通信についてはそのまま使えません。
一方で、Arc Private Link Scopes以外のPaaSサービスのPrivate Endpointは、ExpressRouteまたはSite-to-Site VPN経由でAzure VNET上のプライベートエンドポイントへ到達するルーティングが構成されていれば利用できる可能性があります。つまり、設計上は「Arc通信」と「その他PaaS通信」を分けて扱う必要があります。(Microsoft Learn)
許可リストはリージョン、サービス、OEMで分けて管理する
Azure Localのデプロイでは、HCI固有のエンドポイントだけを許可しても足りません。Azure Resource Bridge、AKS on Azure Local、Azure Arc-enabled serversのエンドポイントも許可リストに含める必要があります。Microsoft Learnでは、East US、West Europe、Australia East、Canada Central、India Central、Southeast Asia、Japan East、South Central US、US Gov Virginiaなどの統合エンドポイント一覧へのリンクが示されています。(Microsoft Learn)
グローバル展開では、次のように管理単位を分けると運用しやすくなります。
| 管理単位 | 例 | 管理のポイント |
|---|---|---|
| リージョン別 | Japan East、West Europe、East USなど | 実際にデプロイするリージョンの一覧だけを許可する |
| クラウド種別 | Public Cloud、Azure Government | Government環境は別リストで管理する |
| 追加サービス別 | Azure Monitor、Azure Site Recovery、Microsoft Defender、AVDなど | 有効化したサービス分だけ追加する |
| OEM別 | Dell、HPE、Lenovo、Hitachi、DataONなど | ハードウェア更新やサポート通信を遮断しない |
| 運用ツール別 | Windows Admin Center、Remote supportなど | 管理端末からの通信も設計対象に含める |
OEM固有のエンドポイントは見落とされやすい項目です。Microsoft Learnでは、DataON、Dell、HPE、Hitachi、Lenovo向けの追加エンドポイントが案内されています。ハードウェアベンダーの更新、サポート、診断連携を使う環境では、Azure Local本体の通信だけでなく、OEM側の要件も変更管理に含めてください。(Microsoft Learn)
内部ルールとポートはクラスタ設計の一部として確認する
Azure Localのファイアウォール要件は、インターネット向け通信だけではありません。クラスタノード間、管理端末、Active Directory、NTP、Hyper-V、Failover Clusteringの内部通信も重要です。
Microsoft Learnでは、すべてのノード間でICMP、SMB 445、iWARP RDMA利用時のSMB Direct 5445、WS-MAN 5985の双方向通信を許可する必要があると説明されています。Windows Admin Centerの作成ウィザードを使う場合、一部のポートは自動で開かれますが、各サーバーで別のファイアウォールを使っている場合は手動で開く必要があります。(Microsoft Learn)
| 対象 | 主な通信・ポート | 実務上の注意点 |
|---|---|---|
| Azure Stack HCI OS管理 | TCP 30301、既定ゲートウェイへのICMP | ライセンス、課金、Azure Localサービス通信に影響する |
| Windows Admin Center | TCP 445、5985、5986 | WinRM over HTTPSのみを選ぶ場合は5986が必要 |
| Active Directory | DNS 53、Kerberos 88、LDAP 389/636、GC 3268/3269、SMB 445、ADWS 9389、RPC動的ポートなど | identity teamsが既存AD設計と照合する |
| NTP | UDP 123 | ドメインコントローラーまたはNTPアプライアンスへの通信を確認する |
| Failover Clustering | TCP 445、135、3343、UDP 137、3343、ICMP、RPC動的ポート | 管理端末からノードへの検証通信も含める |
| Hyper-V | TCP 445、135、80、443、6600、2179、RPC動的ポート | ライブマイグレーションやVM管理で遮断が起きやすい |
RPC動的ポートは、最小100ポート以上を5000番台より上で開く必要があると説明されています。範囲を狭くしすぎると、検証や管理操作は成功しても、負荷時や複数サービスの同時通信で不安定になることがあります。(Microsoft Learn)
Microsoft Defender FirewallとAzure Service Tagsの使い方
Azure Localを厳格な許可リスト環境で運用する場合、Azure Service Tagsを使うと、Azureサービスに関連するIP範囲の管理を軽減できます。Microsoft Learnでは、Service TagはAzureサービスのIPアドレス群を表し、MicrosoftがIPアドレスを管理・更新すると説明されています。(Microsoft Learn)
実務では、次の流れで運用します。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | MicrosoftのAzure IP Ranges and Service Tags JSONを取得 | ファイル名の日付は都度変わるため、古いサンプル名を固定しない |
| 2 | 対象Service TagのIP範囲を抽出 | 例：AzureResourceManagerなど、必要なタグだけ抽出する |
| 3 | 外部ファイアウォールまたはDefender Firewallへ反映 | 宛先、方向、ポート、プロファイルを環境標準に合わせる |
| 4 | 変更管理に登録 | JSONの版、反映日、承認者、対象機器を残す |
| 5 | 定期更新する | 一度登録して終わりにしない |
PowerShellでIP範囲を抽出する場合は、次のように現在取得したJSONファイル名に置き換えて使います。
$json = Get-Content -Path .\ServiceTags_Public_YYYYMMDD.json | ConvertFrom-Json
$ipList = ($json.values | Where-Object Name -eq "AzureResourceManager").properties.addressPrefixes
$ipList外部ファイアウォールへ反映する場合は、抽出したIP範囲を宛先として、原則としてアウトバウンドTCP 443を許可する形でレビューします。Windows Server上のMicrosoft Defender Firewallにルールを作成する場合も、環境のセキュリティ基準に合わせ、対象ノード、プロファイル、方向、ポートの指定を確認してから展開してください。
security adminsが確認すべきポイント
security adminsは、Azure Localの通信を「許可するか、遮断するか」だけでなく、例外の範囲を最小化し、継続的に更新できる形にする必要があります。
特に重要なのは、HTTPSインスペクションの例外です。Azure Localの管理通信をTLS復号の対象にすると、登録、更新、Arc連携、ポータル操作などで原因が分かりにくい障害が起きる可能性があります。例外設定では、単に「Azure宛てを除外」ではなく、Azure Localノード、Azure Resource Bridge VM、プロキシサーバー、管理端末の通信経路ごとに確認してください。
また、Firewall requirements for Azure Localでは、すべての宛先をブロックし、許可リストに含めた宛先だけを通すロックダウン構成にも触れています。高セキュリティ環境ではこの考え方が有効ですが、Arc、AKS、ARB、OEM、追加Azureサービスを分離して管理しないと、更新やサポート時に通信遮断が発生します。(Microsoft Learn)
identity teamsが確認すべきポイント
identity teamsは、Active Directory関連の通信を重点的に確認してください。2026年1月の差分では、AD関連のファイアウォール要件がKerberos、LDAP、DNS、SMB、RPC、ADWSなどを含む形に整理されています。これは、Azure Localのデプロイや管理がAD連携に依存する環境で、通信不足による登録失敗、認証失敗、名前解決失敗を防ぐために重要です。(GitHub)
確認すべき観点は次のとおりです。
- ドメインコントローラーとのDNS、Kerberos、LDAP、LDAPS通信が許可されているか
- RPC動的ポート範囲が過度に狭く設定されていないか
- ADWS 9389/TCPが管理要件に含まれているか
- NTPの時刻同期先がドメインコントローラーなのか、専用NTPアプライアンスなのか明確か
- プロキシやファイアウォールのログで認証失敗と通信遮断を切り分けられるか
時刻同期も軽視できません。Kerberos認証では時刻ずれが障害原因になるため、UDP 123のNTP通信は、デプロイ前の疎通確認に含めてください。(Microsoft Learn)
compliance teamsが確認すべきポイント
compliance teamsは、設定そのものよりも「説明可能性」を重視します。Azure Localのファイアウォール例外は、広すぎると監査で問題になり、狭すぎると運用障害になります。重要なのは、例外ごとに根拠と期限、対象範囲を残すことです。
監査証跡としては、次の情報を残しておくと説明しやすくなります。
| 証跡 | 残す内容 | 目的 |
|---|---|---|
| 公式情報の参照 | Microsoft Learnのページ名、確認日、対象バージョン | 要件の根拠を示す |
| 許可リスト | FQDN、Service Tag、IP範囲、リージョン | 例外範囲を説明する |
| 変更申請 | 申請者、承認者、反映日、対象ファイアウォール | 変更管理の証跡にする |
| 検証結果 | 接続テスト、ログ、失敗時の対応 | 実装済みであることを示す |
| 定期レビュー | 四半期または更新時の見直し結果 | 古い例外を残さない |
特にArc Private Linkについては、「Private Linkで閉域化している」という一般的なAzureの説明をそのままAzure Localに適用しないことが重要です。Azure LocalではAzure Arc Private Link Scopesがサポートされないため、例外設計と監査説明を分けて用意してください。(Microsoft Learn)
デプロイ前に使える実務チェックリスト
Azure Localを新規デプロイする前、または既存環境を2026年時点の要件に合わせて見直す場合は、次の順番で確認すると手戻りを減らせます。
| 順番 | チェック項目 | 完了条件 |
|---|---|---|
| 1 | 対象リージョンを確定する | Japan Eastなど、実際の利用リージョンに対応したエンドポイント一覧を確認済み |
| 2 | Azure Local本体、Arc、ARB、AKSの宛先を整理する | HCI固有要件だけでなく関連コンポーネントも許可リスト化済み |
| 3 | HTTPSインスペクション除外を設計する | Azure Local管理通信のTLS復号除外がネットワーク経路全体で反映済み |
| 4 | Arc Private Linkの扱いを確認する | Arc endpointsが公開IPへ名前解決される前提で設計済み |
| 5 | プロキシバイパスを登録前に決める | Arc登録時に必要なFQDNを追加できる運用になっている |
| 6 | AD、DNS、NTPを確認する | 認証、名前解決、時刻同期の通信が許可済み |
| 7 | クラスタ内部通信を確認する | ICMP、SMB、WS-MAN、RPC、クラスタ通信が許可済み |
| 8 | OEM要件を確認する | ハードウェアベンダー固有エンドポイントを必要に応じて追加済み |
| 9 | 追加Azureサービスを確認する | Monitor、Defender、ASR、AVDなど利用サービス分を反映済み |
| 10 | 監査証跡を残す | 公式根拠、変更申請、検証ログ、レビュー日を保存済み |
この順番にすると、ネットワークチーム、IDチーム、セキュリティチーム、監査チームの責任範囲が分かれやすくなります。逆に、デプロイ直前に「とりあえず443を開ける」進め方をすると、Arc登録、更新、Windows Admin Center操作、AD参加、クラスタ検証のどこで失敗しているのか切り分けにくくなります。
失敗しやすいポイントと回避策
Azure Localのファイアウォール設計でよくある失敗は、個別のポート不足よりも、設計前提の誤りです。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| Azure Local本体の宛先だけ許可する | ARB、AKS、Arc関連通信が失敗する | 関連コンポーネントのエンドポイントを同時に確認する |
| TLS復号をセキュリティ標準として一律適用する | Azure Local管理通信で接続エラーが起きる | Azure Local通信をHTTPSインスペクション対象外にする |
| Arc Private Linkを使える前提で設計する | Arc endpointsの名前解決や接続設計が破綻する | Arc通信は公開IP解決を前提にする |
| ADポートを最小限にしすぎる | 認証、ドメイン参加、管理操作が不安定になる | Kerberos、LDAP、DNS、RPC、ADWSを一覧で確認する |
| RPC動的ポートを狭くしすぎる | 検証時は通っても運用時に失敗する | 5000番台より上で十分な範囲を確保する |
| OEMエンドポイントを見落とす | 更新、診断、サポート連携が止まる | ベンダー別要件を変更管理に含める |
| Service Tagsを一度だけ反映する | IP変更に追随できない | JSON更新と定期レビューを運用化する |
2026年4月時点での対応方針
Azure LocalのFirewall requirements for Azure Localを読むときは、「2026年4月22日に更新されたから何か大きなポート変更があった」と短絡的に判断しないことが大切です。公開GitHub差分では、4月22日の該当変更は著者メタデータの更新が中心です。一方で、現行本文にはセキュリティ管理、ID基盤、コンプライアンスに直結する重要な要件がまとまっています。(GitHub)
次に取るべき行動は明確です。まず、現在のファイアウォールルールを「外部向け」「内部クラスタ向け」「AD/NTP向け」「管理端末向け」「OEM/追加Azureサービス向け」に分けて棚卸ししてください。そのうえで、HTTPSインスペクション除外、Arc Private Link非対応、リージョン別エンドポイント、Service Tags更新、監査証跡の5点を確認します。
Azure Localはオンプレミスに置かれるため、従来のデータセンターファイアウォールの考え方だけで設計しがちです。しかし実態は、Azureコントロールプレーン、Arc、AKS、Azure Resource Bridge、Active Directory、クラスタ内部通信が重なるハイブリッド基盤です。ファイアウォール要件を「通信許可リスト」ではなく「Azure Localを安定運用するための制御設計」として見直すことが、2026年4月時点で最も重要な更新ポイントです。
コメント