MS_AzureProxy

Azureのプロキシ的なモノ。

• 戻る（Azure）
  • Azureの仮想ネットワーク
    • GW / LB的なモノ。
    • プロキシ的なモノ。
  • FgCF (Financial-grade Cloud Fundamentals)
    • AppService閉域構成テクニカルリファレンス
    • AKSをセキュアに利用するためのテクニカルリファレンス

概要

• アウトバウンドをコントロールする系
• インバウンドをコントロールする系はコチラ

補足（インバウンドとアウトバウンドを分けて考える）: この 2 ページの
分け方は、クラウドのネットワーク設計を理解するうえで有効である。

【インバウンド（外 → 中）】 …「誰に見せるか」
  Front Door / Application Gateway / Load Balancer / NSG
  → AzureのGW / LB的なモノ。

【アウトバウンド（中 → 外）】…「どこへ出て良いか」
  Azure Firewall / NAT Gateway / Private Endpoint / Service Endpoint / NSG
  → 本ページ

オンプレミスでは「外から入れない」ことに注意が向きがちだが、
クラウドではアウトバウンドの制御が同等に重要である。理由は、

理由	内容
データ持ち出しの防止	侵害された VM が外部へデータを送るのを止める
マルウェアの C2 通信の遮断	感染後の被害拡大を防ぐ
依存先の明確化	「このシステムはどこと通信するのか」を棚卸しできる
SNAT ポート枯渇の回避	出口を設計しないと同時接続数の上限に当たる

最後の点は特に見落とされやすい。
既定のアウトバウンド経路（既定の送信アクセス）は
SNAT ポート数が限られており、
大量の外部接続を行うと枯渇して接続できなくなる
（Azureのアウトバウンド設計）。

詳細

選択肢

Azure Firewall

≒プロキシ（串）

Network Security Group (NSG)

≒フィルタリング

Azure Private Endpoint

Azure の Endpoint が対象。

Azure Service Endpoint

Azure の PaaS や SaaS が対象。

補足（この 4 つは「排他」ではなく「役割が違う」）: 並列に並んでいるが、
実際には同時に使うものである。

手段	何をするか	通信の行き先
NSG	5-tuple（IP / ポート / プロトコル）でフィルタ	変わらない
Azure Firewall	FQDN やアプリケーション層でフィルタ、ログ記録	Firewall を経由（串）
Service Endpoint	PaaS への経路をAzure のバックボーン内に閉じる	変わらない（IP はパブリックのまま）
Private Endpoint	PaaS にVNET 内のプライベート IP を割り当てる	プライベート IP に変わる

特に Service Endpoint と Private Endpoint の違いが分かりにくいので
整理しておく。

【Service Endpoint】
  VM(10.0.1.4) ──[Azure バックボーン]──→ ストレージ(20.x.x.x)
                送信元が VNET だと分かるので、ストレージ側で
                「この VNET からのみ許可」と設定できる
                ※ 宛先はパブリック IP のまま

【Private Endpoint】
  VM(10.0.1.4) ──[VNET 内]──→ ストレージ用の NIC(10.0.2.5)
                宛先が VNET 内のプライベート IP になる
                ※ オンプレからも VPN/ER 経由で到達できる

	Service Endpoint	Private Endpoint
費用	無料	有料（時間課金＋データ処理量）
オンプレから使えるか	使えない	使える
データ持ち出しの防止	不十分（他テナントの同種リソースにも到達できる）	できる（特定リソースのみ）
DNS の設定	不要	必要（AzureのDNS）
現在の推奨	－	こちら

Microsoft の現在の推奨は Private Endpoint であり、
Service Endpoint は「無料で手軽」という位置付けに留まる。

比較

IPアドレスで制限

IP アドレスで制限するような場合は、
Azure Private Endpointの方が楽
（ただし、Azure の Endpoint だけが対象）。

FQDNで制限

FQDN で制限するような場合は、
Azure Firewallしか選択肢が無い。

補足（「FQDN で制限」が必要になる場面）: この一行は
閉域構成の設計で必ず突き当たる問題を指している。

NSG は IP アドレスでしか制御できない（サービス タグを除く）。
しかし、実際に許可したい相手は

• *.ubuntu.com（apt のリポジトリ）
• *.docker.io（コンテナ イメージ）
• *.microsoft.com（Windows Update）
• *.nuget.org / registry.npmjs.org（パッケージ）

のように FQDN でしか特定できず、IP は変動する
（CDN 配信のため）。

したがって、

要件	手段
Azure の PaaS だけに出したい	Private Endpoint（IP が固定される）
特定の FQDN にだけ出したい	Azure Firewall（アプリケーション規則）またはプロキシ
全部止めたい	NSG（既定の送信規則を Deny）

という整理になる。
本文の「Azure Firewall しか選択肢が無い」は
Azure のマネージド サービスの範囲ではという意味であり、
実際には**サードパーティの NVA（ネットワーク仮想アプライアンス）**や
Squid 等の自前プロキシも選択肢になる（運用負荷は増える）。

なお、Azure Firewall は単価が高い
（Azureの課金の「Gateway 系」）。
検証環境で作ったまま放置すると高額請求の原因になる。

参考

...

---

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