Skip to content

MS_AzurePrivateEndpoint

nishi_74322014 edited this page Sep 1, 2026 · 1 revision

Azure Private Endpoint

概要

Azure Private Linkのエンドポイント、ネットワーク インターフェイス

  • VNETに Endpoint を「引込む」機能
  • 特定 VNET からのみ、アクセスを可能にする。

補足(「引込む」の実体は NIC 1 枚): Private Endpoint は
抽象的な概念ではなく、実体として VNET のサブネット内に
NIC(ネットワーク インターフェイス)が 1 枚作られる

【Private Endpoint 作成前】
  mystorage.blob.core.windows.net → 20.x.x.x(パブリック IP)

【Private Endpoint 作成後】
  サブネット 10.0.2.0/24 内に NIC が生える
    mystorage-pe : 10.0.2.5  ← このプライベート IP でストレージに届く

この構造から、次のことが導ける。

事実 帰結
VNET 内の IP である オンプレから VPN / ExpressRoute 経由でも到達できる
サブネットの IP を消費する サブネットのサイズ設計に含める必要がある
NIC である ピアリングした VNET からも到達できる(DNS の設定は要る)
リソース単位 特定のストレージ アカウント 1 つだけに繋がる(他テナントの同種リソースには行けない)

最後の点が、Service Endpoint との決定的な違いである
Azureのプロキシ的なモノ。)。

詳細

Good

設定が容易。

対応サービスが多い。

なお、着々と増えている。

Bad

Azureのみが対象。

  • 他社が管理する Endpoint は引き込めない(あたりまえか)。
  • ただし、Azure をサポートしている 3rd party サービスにはサポートがあるケースも。

ログが取れない。

Azure Firewallのようなログ取得機能が無い。

補足(ログが取れない点への対処): Private Endpoint 自体は
パススルーの NIC であり、通信ログを持たない。
したがって、監査要件がある場合は別の層で記録する必要がある。

記録したいもの 手段
誰が何にアクセスしたか 接続先サービスの診断ログ(ストレージなら StorageRead 等)
通信の可否 NSG フロー ログ(現在は仮想ネットワーク フロー ログ)
FQDN 単位の記録 Azure Firewall(Private Endpoint では不可)
経路全体 Network Watcher(接続モニター)

「Private Endpoint にしたから安全」で終わらせず、
接続先サービス側の診断設定を有効にするのが実務上の要点である
Azureの監視と管理)。

引込と遮断は別。

  • 引込:
    • 基本は引込むダケ。
    • 遮断の設定は別途必要。
  • 遮断:
    • 引込んだダケだと、
      • パブリック・エンドポイントが有効。
      • 外からもアクセスできる状態。
    • 必要に応じて、パブリック・エンドポイントを遮断する。
      • リソース・ファイアウォール(NSG)でアクセスを禁止できる。
      • ...

補足(この節が Private Endpoint 最大の落とし穴): 「引込と遮断は別」という
指摘は、閉域化で最も見落とされる点である。

【Private Endpoint を作っただけの状態】

  VNET 内の VM ──[10.0.2.5]──→ ストレージ  ← 増えた経路
  インターネット ─[20.x.x.x]──→ ストレージ  ← 元の経路も生きている

  → 経路が「増えた」だけで、「閉じた」わけではない

つまり、Private Endpoint は経路を追加する機能であって、
遮断する機能ではない
。閉域化を完成させるには、
接続先サービス側で「パブリック アクセスを無効化」する必要がある。

サービス 設定箇所
ストレージ アカウント ネットワーク → パブリック ネットワーク アクセス = 無効
Azure SQL Database ネットワーク → パブリック アクセスを拒否
Key Vault ネットワーク → 選択されたネットワークのみ
App Service ネットワーク → パブリック アクセスを無効

なお、本文が「リソース・ファイアウォール(NSG)」と書いているが、
正確には NSG ではなく、各リソースが持つファイアウォール設定である
(NSG は VNET のサブネット/NIC に付ける別の機能)。
混同しやすいので注意したい。

プライベートDNSを使う。

  • プライベート DNS を使う。
    • パブリック DNS でパブリック IP に名前解決しないようにする。
    • プライベート DNS でプライベート IP に名前解決されるようにする。
    • これには、Azure DNSにカスタマイズを行う。
  • VNETの構成に注意が必要になる。
    • 単位の VNET 内でのみ機能する。
    • VNET ピアリング併用時に問題が起きる。
    • ピアリングした VNET の DNS に追加で細工が必要になる。

※ Preview のためか、CLI で構築すると、DNS 設定が手動になっている。

補足(DNS が閉域化の成否を決める): 前掲の「引込と遮断は別」と並んで、
DNS が正しく構成されていないと Private Endpoint は機能しない

名前解決は次の 2 段階になる。

mystorage.blob.core.windows.net
   ↓ ① パブリック DNS が CNAME を返す(これは Azure 側で自動)
mystorage.privatelink.blob.core.windows.net
   ↓ ② ここをどう解決するかが問題
   ├─ プライベート DNS ゾーンがある → 10.0.2.5(正しい)
   └─ 無い                        → パブリック IP(閉域化が効かない)

したがって、プライベート DNS ゾーン
privatelink.blob.core.windows.net 等)を作成し、
利用する VNET すべてにリンクする必要がある。

本文が指摘する「VNET ピアリング併用時に問題が起きる」のはこの点で、

状況 対処
単一 VNET プライベート DNS ゾーンをその VNET にリンク
ピアリングした VNET から使う 同じゾーンを相手 VNET にもリンクする
オンプレから使う オンプレ DNS から**DNS フォワーダー(VNET 内の DNS)**へ条件付き転送
多数の VNET がある Azure DNS プライベート リゾルバーでハブに集約

特にオンプレからの利用は要注意で、
オンプレの DNS サーバは Azure のプライベート DNS ゾーンを引けない。
VNET 内に DNS フォワーダーを立てて 168.63.129.16 に転送させる
という構成が必要になる(現在は Azure DNS プライベート リゾルバーが
このためのマネージド サービスとして提供されている)。

なお、末尾の「Preview のためか、CLI で構築すると DNS 設定が手動」は
現在も概ね同様で、ポータルは DNS ゾーンの作成・リンクまで面倒を見るが、
CLI / IaC では明示的に書く必要がある

IaC 化する際に忘れやすい箇所である。

通信費用がかかる。

Azure Service Endpointの方が廉価

補足(費用の比較): Private Endpoint の課金は
**時間課金+データ処理量(受信・送信)**である。

Service Endpoint Private Endpoint
費用 無料 エンドポイントごとに時間課金+データ量
数が増えると リソースの数だけ必要(積み上がる)

「ストレージ アカウント 1 つにつき 1 個」
「サブリソース(blob / file / queue / table)ごとに 1 個」
という単位で必要になるため、
大規模な環境では無視できない額になる。

ただし、Azureのプロキシ的なモノ。で述べたとおり、
Service Endpoint はデータ持ち出しを防げず、
オンプレからも使えない

費用だけで選ぶと要件を満たさないことになるため、

状況 選択
オンプレから使う/持ち出しを防ぐ Private Endpoint(費用を受け入れる)
VNET 内からの利用のみ、コスト優先 Service Endpoint

という判断になる。

参考

Microsoft Docs

クイックスタート


Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, 通信技術, Azure

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally