【Azure VNet入門⑥】Private接続とセキュリティ運用｜Private Endpoint・Bastion・フローログ

Azure

VNetシリーズの最終回です。ここまでで「VNet内の設計」「VNet同士・オンプレ接続」を押さえました。仕上げとなる今回は、「Storage や SQL などのPaaSサービスへ、いかに”閉域”で安全に繋ぐか」と、運用・セキュリティの実務テクニックを一気に整理します。Private Endpoint、サービスタグ、Bastion、フローログ——この回を押さえれば、VNetの全体像が完成します。

「Private Endpoint」と「サービスエンドポイント」、名前が似てて毎回どっちがどっちか分からなくなる…

この記事では、次の6つを順番に整理します。閉域接続はAzure設計の”実務で差がつく”領域です。1つずつ、混同しやすいポイントを丁寧に解きほぐしていきます。

  • サービスエンドポイントとPrivate Endpointの違いを説明できる
  • Private Endpoint用サブネットの設計（network policies）を理解している
  • サブネット委任（delegation）が必要なサービスを構成できる
  • Private DNS Zone と VNetリンクの関係を理解している
  • サービスタグをNSGルールに使える／NSGフローログを有効化できる
  • Bastion と DDoS Protection の概要を理解している

サービスエンドポイントとPrivate Endpointの違い

閉域接続で最初に立ちはだかる壁が、この2つの違いです。どちらも「PaaSへ安全に繋ぐ」ための機能ですが、仕組みが根本的に違います。まず結論を表で示します。

サービスエンドポイントPrivate Endpoint
やること経路の最適化プライベートIPを生やす
PaaS側のIPパブリックIPのままVNet内のプライベートIPに
オンプレから利用不可可能
DNS変更不要Private DNSが必要
料金無料有料（時間＋転送量）

核心はこう整理できます。

  • サービスエンドポイント＝「経路の最適化」だけ。StorageやSQLはパブリックIPのままですが、VNetから出る通信を「Azureバックボーン経由の最短ルート」に載せ、かつ「このサブネットからのアクセスだけ許可」とPaaS側で絞れます。ただし相手はパブリックIPのままなので、オンプレからは使えません。
  • Private Endpoint（PE）＝「プライベートIPを生やす」。PaaSサービスに対してVNet内のプライベートIPを1つ割り当てます。これにより、そのPaaSはまるでVNetの中にいるかのように振る舞い、オンプレからも（VPN/ExpressRoute経由で）プライベートに到達できます。パブリック公開を完全に無効化できるのが最大の強みです。

「PEはプライベートIPを生やす（＝オンプレから可）／サービスエンドポイントは経路最適化のみ（＝オンプレ不可）」。この一文で覚えれば、もう混同しないよ！

実務では、「本気で閉域化するならPrivate Endpoint」が基本方針です。前回までに出てきたApp Serviceの「入口＝Private Endpoint」も、まさにこの仕組みです。

【ここが説明できればOK①】
「Private EndpointはプライベートIPを割り当てる（オンプレからも可）、サービスエンドポイントは経路最適化のみ（相手はパブリックIPのまま・オンプレ不可）」——これを言えれば、1つ目のチェックはクリアです。

Private Endpoint用サブネットの設計（network policies）

Private Endpointを配置するサブネットには、知らないとハマる設定が1つあります。それが private endpoint network policies です。

歴史的な経緯として、PEを置いたサブネットではNSGやUDRが効かない期間がありました。そのため「PEサブネットにNSGを当てて通信を絞りたい」場合、この private_endpoint_network_policies という設定を「Enabled（有効）」にする必要があります（有効にすると、PEサブネットにもNSG/UDRが適用される）。逆に、ポリシーを無効化しておくパターンもあり、要件次第です。

resource "azurerm_subnet" "pe" {
  name                 = "subnet-pe"
  resource_group_name  = azurerm_resource_group.net.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.0.3.0/24"]

  # PEサブネットにNSG/UDRを効かせたいなら Enabled
  private_endpoint_network_policies = "Enabled"
}

覚えておくべき実務ポイントは「PE専用サブネットを用意し、そこにNSGを当ててアクセス制御したいなら network policies を有効化する」という点です。設定名が長くて忘れがちですが、「PEサブネットのNSGが効かない？」と思ったら真っ先にここを疑いましょう。

【ここが説明できればOK②】
「Private Endpoint用サブネットでNSG/UDRを効かせるには private endpoint network policies の設定が関わる。PE専用サブネットを分けて制御するのが定石」——これを説明できれば、2つ目のチェックはクリアです。

サブネット委任（delegation）が必要なサービス

サブネット委任（delegation）は、一部のPaaSサービスを使うときに必要になる設定です。

サブネット委任とは、特定のAzureサービスに対して「このサブネットはあなた専用に使ってよい」と権限を渡す設定です。委任されたサブネットは、そのサービスが必要なリソースを内部で展開できるようになります。

身近な例が、シリーズ第4回・App Service編でも触れたApp ServiceのVNet統合（出口）です。App Serviceが「アプリからVNet内のリソースへ送信する」ために、専用のサブネットを委任してもらいます。他にも Azure Container Apps、Managed DevOps Pool、一部のDBサービスなどが委任を要求します。

resource "azurerm_subnet" "integration" {
  name                 = "subnet-appsvc-integration"
  resource_group_name  = azurerm_resource_group.net.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.0.6.0/24"]

  delegation {
    name = "appservice"
    service_delegation {
      name = "Microsoft.Web/serverFarms"  # App Service に委任
    }
  }
}

ポイントは「委任したサブネットは、そのサービス専用になる」こと。他の用途のリソースを同居させられません。だからこそ、第2回で学んだ「用途別にサブネットを分ける」設計が効いてきます。委任が必要なサービスを使うなら、そのサービス専用のサブネットを最初から1つ確保しておく、というわけです。

【ここが説明できればOK③】
「サブネット委任は、特定サービス（App Service VNet統合・Container Apps等）に専用サブネットの使用権を渡す設定。委任サブネットはそのサービス専用になる」——これを説明できれば、3つ目のチェックはクリアです。

Private DNS Zone と VNetリンクの関係

Private Endpointを使うと、ほぼ必ずセットで登場するのがこのPrivate DNSです。ここを理解しないと「PEを作ったのに名前解決が公開IPを返してしまい、閉域にならない」という典型的な失敗にハマります。

問題はこうです。アプリは mystorage.blob.core.windows.net という名前でStorageにアクセスします。ところがこの名前を普通にDNSで引くと、StorageのパブリックIPが返ってきてしまう。せっかくPEでプライベートIPを生やしても、名前がパブリックIPを指していたら閉域通信になりません。これを解決するのがPrivate DNS Zoneです。

【Private DNS Zone なし】閉域にならない
  アプリ → "mystorage.blob.core.windows.net" をDNSに問合せ
        → パブリックIP(20.x.x.x) が返る … ×

【Private DNS Zone + VNetリンク あり】
  Private DNS Zone: privatelink.blob.core.windows.net
    └ mystorage → 10.0.3.4（PEのプライベートIP）を登録
  ↑ このゾーンを VNet に「リンク」する
        → アプリの問合せに 10.0.3.4 が返る … ○ 閉域成立

流れを整理すると、①PEを作る → ②対応するPrivate DNS Zone（例：privatelink.blob.core.windows.net）を用意し、PEのプライベートIPを登録 → ③そのゾーンをVNetに「リンク」する。このVNetリンクが肝で、「リンクしたVNetからの名前解決だけが、このPrivate DNS Zoneを参照できる」という関係になります。リンクを忘れると、そのVNetからは相変わらずパブリックIPが返り、閉域が成立しません。

【ここが説明できればOK④】
「Private EndpointはPrivate DNS Zoneとセット。ゾーンにPEのプライベートIPを登録し、それをVNetにリンクすることで、そのVNetからの名前解決がプライベートIPを返すようになる」——これを説明できれば、4つ目のチェックはクリアです。

サービスタグとNSGフローログ（運用の効率化・可視化）

ここからは運用を楽にする2つの機能です。まずサービスタグ。NSGルールを書くとき、「Storageの全IP範囲」「Azureの管理通信の範囲」などを手で管理するのは非現実的です（IPは頻繁に変わります）。サービスタグは、これらのIP範囲に「名前」を付けてMicrosoftが自動メンテしてくれる仕組みです。

# 「Storageサービス宛」をサービスタグで許可（IP範囲を書かなくてよい）
az network nsg rule create -g rg-network --nsg-name nsg-app \
  -n allow-storage --priority 300 \
  --direction Outbound --access Allow --protocol Tcp \
  --destination-address-prefixes Storage \
  --destination-port-ranges 443

# 主なタグ: AzureCloud / Storage / Sql / AzureKeyVault /
#           Internet / VirtualNetwork / GatewayManager など

Storage、Sql、AzureCloud、GatewayManager（第5回のゲートウェイ管理通信で登場）といったタグを指定するだけで、膨大なIP範囲の管理から解放されます。IPが変わってもMicrosoftが追随するので、ルールを直す必要がありません。

次にNSGフローログ（トラフィック分析）。これは「NSGを通った通信を記録し、後から可視化・分析できる」機能です。「どこからどこへ、どのポートで、許可/拒否されたか」がログに残るので——

  • 「通信が繋がらない」障害時に、どのNSGルールで拒否されたかを追える
  • 「不審な通信がないか」をトラフィック分析で可視化できる（セキュリティ監査）

Network Watcherの機能として有効化し、ログをStorageやLog Analyticsに送って分析します。「通信のトラブルシュートと監査の土台」として、本番環境では有効化しておくのが定石です。

【ここが説明できればOK⑤】
「サービスタグはPaaSやAzure管理通信のIP範囲に名前を付けてNSGで使える仕組み。NSGフローログは通信を記録し可視化・トラブルシュート・監査に使える」——これを説明できれば、5つ目のチェックはクリアです。

Bastion と DDoS Protection

最後に、セキュリティを固める2つのサービスを概観します。

Azure Bastion（VMへの安全な踏み台）

VMにSSH/RDPで入りたいとき、VMにパブリックIPを付けてインターネットから直接繋ぐのは危険です（世界中から狙われます）。Bastionは、この問題を解決するAzureのマネージド踏み台サービスです。

Bastionを使うと、ブラウザ（Azureポータル）からVMへSSH/RDP接続でき、VM側にパブリックIPは不要になります。インターネットに開いた管理ポート（22/3389）を一切公開せずに済むのが最大のメリットです。第2回で触れたとおり、Bastionは専用サブネットAzureBastionSubnet（名前固定・/26以上）を要件どおりに用意する必要があります。

DDoS Protection（大量通信攻撃からの保護）

DDoS攻撃（大量の通信を送りつけてサービスを麻痺させる攻撃）への防御がDDoS Protectionです。概要として押さえるべきは、保護レベルに段階がある点です。

  • 基本（Infrastructure）保護：Azureプラットフォームに標準で組み込まれ、常時有効。追加料金なし。
  • 標準／IP保護プラン：VNet単位やパブリックIP単位でより高度な緩和・監視・レポートを有効化する有料プラン。厳格な要件やミッションクリティカルな公開サービス向け。

「基本保護は全Azureに標準装備、追加保護が要るなら有料プランを乗せる」という構造を理解しておけば十分です。

【ここが説明できればOK⑥】
「BastionはパブリックIP不要でVMへ安全にSSH/RDPできる踏み台（専用サブネットが必要）。DDoS Protectionは基本保護が標準装備で、追加保護は有料プラン」——これを説明できれば、6つ目のチェックはクリアです。

まとめ ＆ VNetシリーズ全6回

最終回のポイントを振り返ります。

  • PE＝プライベートIPを生やす（閉域の主役・オンプレ可）／サービスEP＝経路最適化のみ
  • PEサブネットのnetwork policies・サブネット委任・Private DNS ZoneのVNetリンクが閉域成立の三点セット
  • サービスタグでIP管理を不要に、NSGフローログで通信を可視化
  • Bastionで安全な踏み台、DDoS Protectionで大量通信攻撃に備える

これでVNetシリーズは完結です。全6回を通して、「VNetを作る → 用途別に分ける → NSGで守る → 経路を制御する → 他ネットワークと繋ぐ → 閉域で安全に仕上げる」という、Azureネットワーク設計の一連の流れを押さえられたはずです。各回の自己チェックを全部言えるようになっていれば、VNetまわりの実務・資格試験は十分に戦えます。

あわせて読みたい

タイトルとURLをコピーしました