大規模エンタープライズがゼロトラストに向けたネットワーク再設計を推進するうえで、オンプレミスとAzureの両環境で一貫性のあるセグメンテーションとセキュリティポリシーを実現することは、もはや必須といえます。
特にハブ&スポーク型のハイブリッドアーキテクチャでExpressRoute接続を前提とし、Azure Firewall PremiumやNSGによる多層防御を組み合わせ、**Entra ID(旧Azure AD)**を用いたIDベース制御を連携することで、ゼロトラストの要件を満たす強固なネットワークを構築できます。
本記事では、NIST SP 800-207(ゼロトラストアーキテクチャ)、ISO/IEC 27001、CIS Benchmarksなどのガイドラインに準拠した高難度の実装について、設計原則から具体的な構成例、運用ベストプラクティスまでを包括的に解説します。
1. ゼロトラストとネットワークセグメンテーションの連携が不可欠
1.1 ゼロトラストモデルを支えるネットワーク再設計
ゼロトラストの中核理念は**「すべてのリソースやユーザー、通信を信用せず、常に検証する」**というものです。
NIST SP 800-207が掲げるように、ネットワーク内外を問わず常に最小権限と検証を行い、不正アクセスの横展開を防ぐことが求められます。
これを実践するには、強固なネットワークセグメンテーションが欠かせません。企業ネットワークの内部・外部境界をより細かく分割し、それぞれの境界でアクセス制御を行うことで、万一の侵害時にも被害を限定化できます。
1.2 ハイブリッド環境での一貫したセグメント設計
多くの大企業では依然としてオンプレミスに基幹系システムが残りつつ、新規開発はクラウドのIaaSやPaaSを活用するハイブリッド環境にシフトしています。
この際、オンプレ側で運用してきた境界防御(ファイアウォールやゾーニング)とAzure側のセグメンテーションとを整合させ、同等のセキュリティポリシーを適用できる設計が鍵となります。
表面上は「オンプレの拠点→ExpressRoute→Azure」と繋がっていても、クラウド側ではハブ&スポークを中心としたネットワークモデルが推奨され、Azure Firewall PremiumやNSGを用いて各サブネット・ワークロード単位で制御する形になるので、既存のセグメンテーション手法とは大きく異なります。
結果的に「クラウド側でもオンプレに近いセグメント分割を再現しつつ、さらにゼロトラストを満たすためにエンドポイント/IDベースの制御を追加で導入」するのが自然な流れとなります。
2. ハブ&スポークとExpressRouteを軸としたハイブリッドネットワーク基盤
2.1 Hub & Spokeアーキテクチャの概要
Azureでは、共通ネットワークサービスを集約したハブVNetと、業務アプリケーションが稼働するスポークVNetを繋ぐ構成を「ハブ&スポーク」型と呼びます。オンプレミスからの接続(ExpressRouteやVPN Gateway)はハブVNetに収容し、スポークVNetへの通信は強制的にハブを経由させるのが基本です。これにより、セキュリティ機能やゲートウェイを中央で一括管理できるため、大規模環境でも構成がシンプルになりやすい利点があります。
東西トラフィック検査を一貫適用するには、各スポークで UDR により他スポーク/オンプレ宛を必ず Firewall 経由にします。Virtual WAN を使う場合は Routing Intent(Private) で同等の経路強制が可能です(詳細は 2.4 参照)。
2.2 ExpressRouteによるオンプレ接続
オンプレミスとAzureを安定して繋ぐにはExpressRouteが最適です。
インターネットを経由しない閉域接続ゆえ、高帯域・低遅延かつネットワーク障害リスクが低いです。
ハブVNet側のExpressRoute Gatewayとオンプレ側のPEルーター間でBGPを確立し、双方のサブネットに対する経路を交換します。
セキュリティ的には、トラフィックを暗号化しないまま専用線を通すケースが多いですが、機密度が高ければ拠点側でVPNトンネルを重ねる二重化も検討します。
グローバル企業の場合は複数地域でExpressRouteを契約し、ER Global Reachで相互接続すれば遠隔地の拠点とAzureとの通信を広域イーサやMPLSのように扱えます。
2.3 ゼロトラスト視点のポイント
従来のハブ&スポーク+専用線構成だけでは「ハブVNetに到達した時点で内部トラフィック」という暗黙の信用が生まれやすいため、そこをAzure FirewallやNSGの細かいポリシーで制御し直す必要があります。
すべての通信がハブを経由してスポークへ流れるようUDR(ユーザー定義ルート)で経路を強制し、未知の経路(たとえばスポーク同士の直接ピアリングやインターネット直結)を防ぎます。
この設計により、オンプレ側から来る通信であっても信頼ゼロの前提で再検証し、Azure Firewallが許可したものだけスポークへ通す構造が作れます。
CIS Benchmarksでもこの考えを支持し、全サブネットでインバウンド/アウトバウンドが最小化されるよう推奨しています。
2.4 East‑West TLS検査を成立させる経路強制(UDR/Routing Intent)
ゼロトラストの「東西トラフィックも常に検証」を実現するには、トラフィックを必ず Azure Firewall を通す経路強制が前提です。
Hub & Spoke(通常のVNet)
各スポークのサブネットに UDR(ユーザー定義ルート)を関連付け、他スポーク/オンプレ宛てのプレフィックスの**次ホップを Azure Firewall(仮想アプライアンス)**に設定します。
ハブ—スポークの VNet ピアリングでは「Allow forwarded traffic」を有効にし、ハブ側は Gateway Transit/Use remote gateway の是非を設計方針に合わせて設定します。これにより スポーク↔スポークの横断通信がハブの Firewall を必ず経由します。
UDR の例(スポークA サブネットに関連付け)
宛先プレフィックス 次ホップ種類 次ホップ 用途
10.20.0.0/16(スポークB) Virtual appliance スポークB行きをFW経由に強制
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16(オンプレ全体を要約) Virtual appliance オンプレ行きをFW経由に強制
(任意)0.0.0.0/0 Virtual appliance すべての外向きをFWへ(北南検査も一元化)
注意:UDR はシステムルートより優先されます。ピアリングと組み合わせる際は、Allow forwarded traffic が未設定だと転送パケットがドロップされます。
Azure Virtual WAN(Secure Hub)
Secure Hub に Azure Firewall を配置し、Routing Intent で “Private traffic” を Firewall に誘導します。Inter‑hub を有効にすれば地域をまたぐスポーク間の East‑West も一括で検査できます。UDR を大量配布せずにPrivate(RFC1918)プレフィックスを自動的に Hub に吸い上げられるため、運用が簡素化します。
用語の補足:「強制トンネル(forced tunneling)」という表現は、Azure ではインターネット向けの外向き通信を下流FWにヘアピン転送したい場合のモード名としても使われます(NVA/オンプレへの経路強制)。East‑West の検査自体は UDR/Routing Intent で成立するため、記事では**“経路強制(UDR/Routing Intent)”**という用語で明確化するのが安全です
3. Azure Firewall Premiumによる中心的な境界防御
3.1 Premium SKUの特徴:IDPS/TLSインスペクション
ゼロトラストの実践では、ネットワーク内部の通信もすべて検査対象とし、異常検知を行うIDPS(侵入防止システム)機能が鍵となります。
Azure Firewall Premiumは標準SKUに加え、IDPSシグネチャやTLS(SSL)インスペクション、URLフィルタリングなど上位のUTM的機能を備えています。
オンプレ側のファイアウォール(FortiGateやPaloAltoなど)に近いレイヤ7検査能力を持ち、C&C通信やマルウェアサイトへのアクセスもThreat IntelligenceやURLカテゴリでブロックできます。
TLSインスペクションを有効にすると、Firewallがクライアントとサーバー間のHTTPSを中継し復号検査を実施。内部CA証明書をFirewallにアップロードしておけば、社内端末がそれを信頼することでエンドツーエンド暗号化に近い形を維持しながら中間で検査できます。
これで内部脅威の暗号化通信も含め、Azure Firewallが一元的に可視化と制御を行えるため、ゼロトラストの「すべての通信を検証する」要件に合致します。
NIST SP 800-207でもSSL/TLS暗号化下のラテラル移動検知が困難だと指摘しており、クラウドレイヤでのTLSインスペクションは侵害拡大を早期発見する上で大きな効果があります。
TLS インスペクションは Outbound と East‑West を対象とし、「経路強制(UDR/Routing Intent)」と「CA 配布(PolicyのTLS設定)」が動作前提です。
3.2 Firewall Policyとマイクロセグメンテーション
Azure Firewall PremiumにおけるFirewall Policyは、複数のルールコレクションを階層的に管理できる仕組みで、基礎のグローバルなAllow/DenyルールをBase Policyに設定し、特定ワークロード専用の許可ルールは子ポリシーとして追加する運用が可能です。
これにより、全社共通の拒否ルール(例えば既知のマルウェアカテゴリ等)をBase Policyで強制しつつ、各アプリケーションやテナント単位で必要な例外許可を子ポリシーで定義できます。
大規模企業ではシステムや部署ごとにネットワーク要件が異なるため、この階層構造でのマイクロセグメンテーションが非常に有効です。
たとえば業務Aサブネット→業務Bサブネットへの通信は原則禁止とし、BがHTTP APIを提供しているならそこだけApplicationルールで443/TCPを許可する、といった具合に細かく制御します。
オンプレ環境からAzureへの流入通信でも、ExressRouteからのすべてがフリーで通るわけではなく、Firewall側で許可されたソースIP/プロトコル/宛先だけを通す形です。
Base PolicyはCISやISO27001に則って厳格なグローバルブロックルールを設定(たとえば「特定国IPへのOutbound禁止」「Tor出口ノードは拒否」「Threat Intelligenceで悪性判定されたものは拒否」など)、子ポリシーでアプリチームが必要な特定ポートをAllowする、という役割分担が理想的です。
これこそゼロトラストの「最小権限通信」の具体的実装になります。
3.3 FirewallとNSGの共存
Azure Firewallがネットワークの境界(ハブ)で集中検査する一方、各スポークVNet内部では**ネットワークセキュリティグループ(NSG)**がサブネット/VM単位でより細やかなフィルタを行います。
これによって、同一スポーク内のセグメント化や、最終的にホスト単位の遮断も併用できます。特に「管理用サブネット」や「DBサブネット」などクリティカルな部分にはNSGでローカルにさらに厳しいポート制限を加えておくと、万一Firewallを通過したマルウェアでもサブネット内部の横移動を防ぎやすくなります。
また、NSGにはFortiGateやPaloAltoのようなL7可視化は無いものの軽量でオーバーヘッドが少なく、ステートフルにトラフィックを制御できます。
実装時の注意点としては、NetworkルールをFirewallで許可した後にNSGでブロックしていないかなど、ルールの重複や競合を設計・検証する必要があります。
トラブルシュート時にはFirewallログとNSGフローログを突合し、どの段階で拒否されたかを確認します。もし要件的に「特定通信だけをNSGでさらに絞りたい」場合、Firewallの許可ルールに加え、NSGで送信元ホストや宛先ポートをさらに限定する方法があります。
過度に細かいルールを重ねると運用が煩雑になりやすいため、FirewallとNSGの役割分担を明確に決めておくことが大切です。
3.4 East‑West TLS インスペクションの前提条件と制約
対象:Azure Firewall Premium は East‑West TLS 検査(スポーク間/オンプレ↔Azure間のプライベート通信)に対応します。
前提①:CA証明書の配布 — Firewall Policy の TLS inspection に中間CAを登録(Key Vault 経由)し、クライアント端末にそのCAを信頼配布します。
前提②:経路強制 — Hub&Spoke では UDR、Virtual WAN では Routing Intent(Private) で東西トラフィックを必ず Firewall に通すこと。
前提③:SNI 依存 — Azure Firewall のアプリケーション検査は SNI/Host/URL を評価します。SNI を出さない TLS(IP直指定など)は Application ルール側で照合不可のため、Network ルールで許可するなどの設計が必要です(診断ログの ActionReason に “SNI TLS extension was missing” が出ることがあります)。
制約メモ — 一部のWebカテゴリは TLS 終端非対応で例外指定が要るケースがあります(URL を明示許可など)。
4. Entra ID(旧Azure AD)認証との連携でゼロトラストを強化
4.1 IDベースのアクセス制御
ゼロトラストでは**「ネットワーク境界よりもIDや端末状態を信用の基盤にする」という考えが核心です。
Azure FirewallやNSGはIP/ポート単位の制御が基本ですが、それを超えてユーザーやデバイスIDに基づくアクセス制御を行うにはEntra ID(旧Azure AD)**の条件付きアクセスやAzure AD認証モードを活用します。
具体例として:
VMへのRDP/SSHにAzure AD認証を導入し、オンプレやインターネットからの接続でもユーザーが正当なAzure ADアカウントを持ち、かつMFA済みでなければログインを許可しない。
ジャンプサーバやBastionへのアクセス時に、Entra ID側で「Managed端末のみ許可」「IPアドレス制限」「リスクの高いユーザーは拒否」等の条件を適用し、ゼロトラストを徹底。
アプリケーションゲートウェイ + Azure ADでWebアプリをプロキシし、Application Proxyの形でID認証を必須とする。ネットワーク的にはFirewallを通しても、IDがなければアプリケーションレイヤで拒否される。
このように、ネットワークレイヤのセグメンテーションとIDレイヤでの認証が組み合わさることで、「許可されたネットワークから来てもIDが認証されていなければアクセスできない」という複合的なゼロトラストが成立します。
CISでも「特権アクセスには多層の検証を実施すべし」と推奨しており、オンプレ→Azureでも最終的にEntra IDのMFA/条件付きアクセスを経る構造が望ましいです。
4.2 Azure Resourceへのアクセス監査
Entra IDはAzure Resource Managerへのアクセスやロール管理も統合しているため、誰がいつファイアウォールのポリシーを変更したかまで含めて一元的に監査可能です。
ISO27001やCISでは変更管理と監査ログが必須要件となっており、大規模環境では従来オンプレファイアウォール(FortiGate等)毎に個別の監査ログを手動収集していたところを、Azure ADアクティビティログとAzure Monitorで自動的に可視化できるメリットがあります。
さらに、Privileged Identity Management (PIM) 機能により、Azure FirewallやNSGへのポリシー更新権限を普段は与えず、必要時のみリクエスト承認後に付与する運用が可能です。
これにより特権ロールを常時持たないゼロトラストな体制を構築できます。
5. セキュリティ運用とコンプライアンス準拠
5.1 ログ収集・SIEM連携と異常検知
Azure Firewall PremiumやNSGでブロック/許可されたイベントは、Azure Monitorの診断ログを経てLog Analyticsワークスペースに集約できます。
ここでKQL(Azure Monitor Query)を用いて詳細に検索可能で、さらにMicrosoft Sentinelに連携すればSIEMとして相関分析やアラート、SOARが活用できます。
たとえば以下のシナリオが典型です。
IDPSログ + Azure ADサインインログの相関: シグネチャ攻撃を試みたクライアントが、同時に複数Azure ADテナントへのログインを試行しているならハイリスクとしてアラート発砲。
Threat Intelligence: Firewallで遮断された接続先が既知のC2サーバーと判明した場合、同じホストからの他トラフィックも含めてインシデント化して自動調査を行う。
ゼロトラスト視点のLateral Movement検知: 通常通らないスポーク間通信が短時間で多数発生した場合、ラテラル移動の疑いがあるとして高優先度アラートを発生させる。
クラウドに移行しても**オンプレのSIEM(Splunk、QRadar等)**を使い続ける例もありますが、Azure LogsはJSON形式でEvent Hub経由などで取り込む必要があり、運用負荷が上がります。
Microsoft Sentinelを導入すればネイティブにAzure FirewallやNSGログを取り込めるため、ゼロトラスト実装と相性が良いです。
また、Defender for Cloudでセキュリティポスチャを可視化し、NISTやISO基準に対してどれだけギャップがあるかをスコアリングできる点も大きな利点です。
5.2 NIST SP 800-207、ISO/IEC 27001、CIS Benchmarksへの準拠
本構成は、NIST SP 800-207が提唱するゼロトラストアーキテクチャの基本理念(リソース単位でのポリシー適用と継続的検証、防御面の拡張)に沿っており、ネットワーク層のゼロトラストを大枠で満たします。
またISO 27001にも明記される「ネットワーク分離とアクセス制御」「暗号化の実施」「ログ監査」「特権アクセス管理」などの項目に対して、Azure Firewall Premium+NSG+Entra ID+ロギング運用で多くの要件をカバー可能です。
さらにCIS Microsoft Azure Foundations BenchmarkではNSGの必須導入やVNet構成ポリシーなどを推奨していますが、本稿のHub & Spoke + Firewall + NSG併用設計はその遵守点を概ね網羅します。
とくにCISレベルの要件としては「すべてのサブネットにNSGが適用されていること」や「不要ポートの閉鎖」「不審なログの監視」などが重点ですが、ゼロトラスト原則で**“ホワイトリスト運用”**を行うことで大半を満たせます。
5.3 継続的改善サイクル
最終的にゼロトラスト設計は一度構築して終わりではなく、脅威の進化や組織の要件変化に伴ってポリシーやテクノロジーをアップデートし続けるプロセスです。
ネットワーク分割が過剰になり業務効率を落としていないか、あるいは逆にDX推進に伴う新規接続要件がNSGやFirewallポリシーに適切に反映されているか等を定期レビューし、Security by Designの方針で新しいプロジェクトごとにセグメンテーションやID認証を前提に設計します。
監視ログの分析、ペネトレーションテストやレッドチーム演習の結果をフィードバックする仕組みを整えれば、社内標準のゼロトラストモデルは実際のビジネス変化にも耐える柔軟な体制となるでしょう。
まとめ
ハブ&スポーク型ハイブリッドネットワークにAzure Firewall PremiumとNSGを組み合わせてネットワークセグメンテーションを実践し、Entra IDを活用してIDベースのアクセス管理を強化することは、ゼロトラストを具現化するうえで極めて有効なアプローチです。
特に以下の点が本設計の要点となります。
ExpressRouteを通じたハイブリッド基盤: オンプレミスとの安定した専用線接続を確立し、Hub & Spoke構成でクラウドリソースを一元管理。
Azure Firewall Premiumによる集中検査: TLSインスペクションやIDPS、Threat Intelligence等を駆使し、インバウンド/アウトバウンド/東西トラフィックをすべて検査する。
NSGで補強するマイクロセグメンテーション: サブネット/VM単位での最小権限ルールを設定し、万一の侵害時の横移動リスクを極限まで抑制。
Entra ID (旧Azure AD)でゼロトラストを徹底: 条件付きアクセス、Azure AD認証によるマネージド端末やユーザーID検証を加え、境界だけに頼らない多層防御を実装。
ログ・SIEM連携とガバナンス: Firewall・NSG・Azure AD等のログを集中収集し、SentinelやDefender for Cloudと統合。NISTやISO/CISなど国際標準に基づき継続的な監査・改善を行う。
これらを包括的に取り入れることで、大規模企業のセキュリティ要求にも応えつつ、クラウドネイティブな拡張性や集中管理のメリットを得られます。
ゼロトラストにおける「常に検証」「最小権限」「侵入前提」——これらを具体的にネットワーク設計で体現するには相応の難易度がありますが、本記事の指針を参考に、企業固有の要件(業種規制や内部政治・組織構造)と照らし合わせながら最良のアーキテクチャを導き出していただければ幸いです。
参考リンク
設計指針/ゼロトラスト
- ゼロトラストを Azure ネットワークへ適用: https://learn.microsoft.com/ja-jp/security/zero-trust/azure-networking-overview
- NIST SP 800‑207 Zero Trust Architecture (PDF): https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf
- NIST SP 800‑207A (PDF): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207A.pdf
- セグメント化にゼロトラストを適用: https://learn.microsoft.com/ja-jp/security/zero-trust/azure-networking-segmentation
トポロジ/ルーティング(Hub&Spoke、UDR、ピアリング)
- Hub&Spoke リファレンス: https://learn.microsoft.com/ja-jp/azure/architecture/networking/architecture/hub-spoke
- VNet ピアリング(Allow forwarded traffic 等): https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-manage-peering
- ユーザー定義ルート(UDR)概要: https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-udr-overview
- Azure Virtual Network Manager の UDR 管理: https://learn.microsoft.com/ja-jp/azure/virtual-network-manager/concept-user-defined-route
- スポーク間ネットワーク パターン: https://learn.microsoft.com/ja-jp/azure/architecture/networking/guide/spoke-to-spoke-networking
Azure Virtual WAN/Routing Intent
- vWAN ルーティング ポリシー(Private/Internet をFWへ): https://learn.microsoft.com/ja-jp/azure/virtual-wan/how-to-routing-policies
- vWAN を用いた Hub‑Spoke アーキ: https://learn.microsoft.com/ja-jp/azure/architecture/networking/architecture/hub-spoke-virtual-wan-architecture
- Secure Hub + Azure Firewall(PowerShell): https://learn.microsoft.com/ja-jp/azure/firewall-manager/secure-cloud-network-powershell
Azure Firewall Premium/TLS インスペクション
- Premium 機能: https://learn.microsoft.com/ja-jp/azure/firewall/premium-features
- ルール処理ロジック(DNAT→Network→Application): https://learn.microsoft.com/ja-jp/azure/firewall/rule-processing
- エンタープライズ CA 証明書デプロイ: https://learn.microsoft.com/ja-jp/azure/firewall/premium-deploy-certificates-enterprise-ca
- 既知の問題(SNI 必須など): https://learn.microsoft.com/en-us/azure/firewall/firewall-known-issues
- Firewall Policy(Base/子ポリシー等): https://learn.microsoft.com/ja-jp/azure/firewall-manager/policy-overview
「強制トンネル」と「東西検査の経路強制」
- Azure Firewall の強制トンネリング: https://learn.microsoft.com/ja-jp/azure/firewall/forced-tunneling
- vWAN の P2S 強制トンネル: https://learn.microsoft.com/ja-jp/azure/virtual-wan/how-to-forced-tunnel
NSG/マイクロセグメンテーション
- NSG の概要: https://learn.microsoft.com/ja-jp/azure/virtual-network/network-security-groups-overview
- NSG フローログ(将来廃止の告知あり): https://learn.microsoft.com/ja-jp/azure/network-watcher/nsg-flow-logs-overview
監視・ログ・SIEM
- Azure Firewall の監視: https://learn.microsoft.com/ja-jp/azure/firewall/monitor-firewall
- Azure Firewall ログカテゴリ一覧: https://learn.microsoft.com/ja-jp/azure/azure-monitor/reference/supported-logs/microsoft-network-azurefirewalls-logs
- Microsoft Sentinel データコネクタ一覧: https://learn.microsoft.com/ja-jp/azure/sentinel/data-connectors-reference
- Azure Firewall × Sentinel ソリューション: https://learn.microsoft.com/ja-jp/azure/firewall/firewall-sentinel-overview
ハイブリッド接続(ExpressRoute)
- ExpressRoute ドキュメント: https://learn.microsoft.com/ja-jp/azure/expressroute/
- ExpressRoute Global Reach: https://learn.microsoft.com/ja-jp/azure/expressroute/expressroute-global-reach
- ExpressRoute の暗号化: https://learn.microsoft.com/ja-jp/azure/expressroute/expressroute-about-encryption