• 戻る（Azure）
  • Azureの管理（Azure Subscriptionの管理@エンプラ） ＞ FgCF
    • Azureの仮想ネットワーク

区分1	区分2	区分3	MS-DC内（暗黙的通信）	MS-DC内（明示的通信）	MS-DC外（比較的安全な通信）	MS-DC外（安全とは考え難い通信）
ユーザ管理	ユーザ アプリ	ユーザ・コード	－	PaaS、SaaS への通信	任意の DC 外通信	任意の DC 外通信
ユーザ管理	ユーザ アプリ	ユーザ・コード用 ランタイム＆ライブラリ	－	・Azure Monitor ・内部パッケージ・リポジトリ ・Azure コンテナ・レジストリ（ACR）	ディストリビュータ提供の ・外部パッケージ・リポジトリ ・外部コンテナ・レジストリ	その他のリポジトリ・レジストリ ・githubusercontent ・Google Storage
MS 管理	マネージド サービス	CaaS PaaS SaaS 基盤	未公開の通信	XaaS 定義の通信 ・Azure Active Directory ・ARM API ・Master API ・MS コンテナ・レジストリ（MCR）	AKS パッケージ・リポジトリ （Akamai CDN 上）	－
MS 管理	マネージド サービス	ゲスト VM （IaaS）	・仮想パブリック IP アドレス ・Azure Managed IDエンドポイント	－	ディストリビューションが 使用するパッチ、NTP 通信	－
MS 管理	物理 DC インフラ	ホスト OS （物理 HW）	ブラック・ボックス（非公開）	ブラック・ボックス（非公開）	ブラック・ボックス（非公開）	ブラック・ボックス（非公開）

移行メモ（表の変換）: 原典は PukiWiki のセル結合記法（> と
2 段のヘッダ行）を使用していた。
GitHub の表記法にセル結合が無いため、

• 縦の結合（区分 1・区分 2）は同じ値を展開、
• 横の結合は同じ値を各列に展開、
• 2 段だったヘッダ（「MS-DC 内 / 外」と「暗黙的 / 明示的 /
  比較的安全 / 安全とは考え難い」）は1 行に統合

して表現した。
原典の「MS-DC 内」は「既知の経路で到達する」、
「MS-DC 外」は「到達経路を特定できない」という説明が付されていた。

補足（この表の読み方）: 一見複雑だが、
2 つの軸で通信を分類した表である。

縦軸：誰が管理する層の通信か
  ユーザ管理（自分で制御できる）
     ↓
  MS 管理（マネージド サービスが勝手に行う）
     ↓
  物理 DC（見えない）

横軸：どこへ出て行くか、経路が分かるか
  ← 安全                                        危険 →
  暗黙的通信 ── 明示的通信 ── 比較的安全 ── 安全とは考え難い
  （MS-DC 内、経路が既知）      （MS-DC 外、経路が不明）

この表が優れているのは、
「アウトバウンドを塞ぐ」と言ったときに、
どこまで塞げて、どこは塞げないのかが一目で分かる点である。

領域	制御できるか
物理 DC の通信	不可（ブラック ボックス。信頼するしかない）
MS 管理の暗黙的通信	実質不可（塞ぐとサービスが動かない）
MS 管理の明示的通信	一部可（Private Link 化など）
ユーザ管理の通信	可（ここが設計の対象）

つまり、「全部塞ぐ」は不可能であり、
制御できる範囲を見極めて、そこに注力するという
現実的な整理を与えている。
右下（ユーザ・コードから DC 外への任意通信）が
最も危険かつ制御可能な領域であり、
後掲の「外向き通信のロックダウン」の主対象になる。

• 信頼できるサーバ / サービスか？
• 信頼できる場合も、マルチテナントのケースは要検討。

• 基本的には信頼する（未公開の通信を信頼しないとソモソモ使用不可能）。
• 明示的な通信をチェックして、必要に応じて対応する（Master API のプライベート化など）。

補足（この割り切りが実務的）: 「未公開の通信を信頼しないと
そもそも使用不可能」という一文は、
クラウド利用の前提を端的に述べている。

マネージド サービスを使うということは、
Microsoft の基盤系通信を信頼するということである。
これを信頼できないなら、そもそもクラウドを使うべきではない。

一方で、明示的な通信は制御の余地がある。
例に挙がっている「Master API のプライベート化」は、
AKS の API サーバ（コントロール プレーン）を
パブリック エンドポイントからプライベートに切り替えるもので、
「基盤だから諦める」のではなく
公開されている選択肢は使うという姿勢を示している。

同種の例としては、

サービス	プライベート化の手段
AKS の API サーバ	プライベート クラスタ
ACR	Private Endpoint（Azure Private Endpoint）
Azure Monitor	AMPLS（Azureの監視と管理）
Key Vault / Storage / SQL	Private Endpoint

がある。

マルチテナントのケースは、

• Azure Private Linkによるプライベート化
• Azure Firewallなどの FQDN フィルタリングによるプライベート化

などを検討する。

補足（マルチテナントが問題になる理由）: この論点は
Azure Peering Serviceや
Azure ExpressRouteでも繰り返し出てくる、
クラウド特有の重要な問題である。

【問題】 通信先が「サービス」であって「自分のリソース」ではない

  VM → storage.blob.core.windows.net
         ├─ 自社のストレージ アカウント
         ├─ 他社のストレージ アカウント  ← ここにも到達できる
         └─ 攻撃者のストレージ アカウント ← データを持ち出せる

経路（IP・FQDN）としては同じであるため、
NSG やサービス タグでは区別できない。

対処は 2 通りある。

手段	効果
Private Endpoint	特定のリソース 1 つにしか繋がらない。最も確実
Azure Firewall の FQDN フィルタ	特定のアカウント名の FQDN のみ許可。ただし完全ではない

なお、この問題は
**「データ流出（data exfiltration）の防止」**として
クラウド セキュリティの主要論点になっている。

• 主に、ユーザ管理領域の通信に問題がないかを確認する。
• 必要に応じ、外向き通信をロックダウンする。

補足（実際に何が外へ出ているか）: 「ユーザ管理領域の通信」は、
開発者が意識せずに発生させていることが多い。
概要の表の右上・右下に挙がっているものが典型である。

通信	発生元
パッケージの取得	nuget.org、npmjs.org、pypi.org、apt/yum リポジトリ
コンテナ イメージの取得	docker.io、ghcr.io、quay.io
ソースの取得	github.com、raw.githubusercontent.com
ライセンス認証・テレメトリ	各種製品
NTP	時刻同期
証明書失効確認	CRL / OCSP

本文の表が githubusercontent や Google Storage を
**「安全とは考え難い通信」**に分類しているのは、

• 誰でも任意のファイルを置ける（＝マルウェアの配布元になり得る）、
• 経路が特定できない（CDN 経由で IP が変動する）

ためである。
ビルド時に必要でも、本番の実行時に必要なことは稀であり、

対策	内容
内部リポジトリ／レジストリを立てる	Azure Artifacts、ACR に取り込んでおく
ビルド時に固める	コンテナ イメージに焼き込み、実行時は取りに行かない
FQDN で限定	必要なものだけ Azure Firewall で許可

という順で潰していくのが定石である。
表が「内部パッケージ・リポジトリ」「Azure コンテナ・レジストリ（ACR）」を
MS-DC 内の明示的通信（＝比較的安全）に置いているのは、
外部への依存を内部に持ち込むという対策そのものを示している。

168.63.129.16

• このアドレスが、VNET 内の DHCP（や DNS）の機能を提供する。
• 他にも、VM エージェントとの通信に利用されている。
• 別の VNET の名前解決には、
  • Hubに自前の DNS を構築するか、
  • ローカル DNS ゾーンを使用する。

補足（168.63.129.16 の性質）: このアドレスは
Azure 全体で共通の固定 IP であり、
特殊な扱いを受ける。

性質	内容
NSG に関わらず到達できる	ブロックできない
ルーティングされない	ホスト側で処理される。パブリック IP ではない
どの VNET からも同じ	すべての VNET で同一のアドレス

提供する機能は次のとおり。

• DHCP（プライベート IP の割り当て）
• DNS（Azure 提供の名前解決）
• 正常性プローブの送信元（Load Balancer）
• VM エージェントとの通信（Azureの仮想マシン）

注意点として、OS のファイアウォールでこれを遮断すると
VM が正常に動作しなくなる。
ハードニングの際に「不審な通信」として塞いでしまう事故がある。

なお、名前解決について本文が触れている
「別の VNET の名前解決」の問題は、
Azure 提供 DNS は自 VNET 内の名前しか解決できない
という制約に由来する。
現在は Azure DNS プライベート リゾルバーが
このためのマネージド サービスとして提供されており、
「Hub に自前の DNS を構築する」必要は無くなっている
（AzureのDNS）。

• NSG
  NSG による送信（インターネット通信）の拒否
• UDR
  • UDR による既定のルート（インターネット通信）の拒否
  • NVA にルーティングしてのフィルタリング
    • Azure Firewall
    • オンプレのプロキシそのもの
    • オンプレのプロキシと同型の NVA

※ Azure のエッジは、基幹線に近い所に繋がっているので、
　 オンプレのプロキシ（オンプレを迂回する）より安全。

移行メモ（正誤）: 原典の「NAにルーティングしてのフィルタリング」は、
直後に Azure Firewall・NVA が列挙されていることから
「NVA（Network Virtual Appliance）」の脱字と判断し修正した。

補足（NSG と UDR は役割が違う）: この 2 つは並列に見えるが、
できることが根本的に違う。

	NSG	UDR（ユーザ定義ルート）
何をするか	通す／通さない	どこを経由するか
粒度	IP・ポート	宛先プレフィックス単位
FQDN	不可	－（経由先で判定させる）
使い方	単純な遮断	Firewall / NVA に強制的に向ける

FQDN 単位の制御が要る場合、
NSG だけでは実現できないため、

UDR : 0.0.0.0/0 → 次ホップ = Azure Firewall のプライベート IP
         ↓
Azure Firewall : FQDN で許可／拒否 ＋ ログ記録
         ↓
インターネット

という強制トンネリングの構成を採る。
これが「NVA にルーティングしてのフィルタリング」の意味である。

注意点として、

注意	内容
Firewall 自身のサブネットには UDR を向けない	ループする
Private Endpoint への経路	UDR より優先される（システム ルート）
費用	Azure Firewall は高い（Azureの課金）
単一障害点	Firewall が落ちると全通信が止まる。ゾーン冗長を検討

がある。

補足（末尾の「Azure のエッジの方が安全」という主張）: 一見意外だが、
根拠のある主張である。

【オンプレのプロキシを経由させる（強制トンネリング）】
  Azure VM → VPN/ER → オンプレのプロキシ → オンプレの回線 → インターネット
             ↑ 遠回り。ER の帯域を消費。オンプレの回線品質に依存

【Azure のエッジから出る】
  Azure VM → Azure Firewall → Azure のエッジ → インターネット
             ↑ 基幹線に近く、経路が短い

「オンプレのプロキシを通すのが安全」という考え方は、
オンプレに検査装置があるからという前提に立つが、

問題	内容
専用線の帯域を消費する	クラウドの外向き通信が ER を圧迫する
経路が長い	遅延が増え、可用性も下がる
オンプレの出口が単一障害点になる	クラウド側が巻き添えで止まる
検査能力は同等	Azure Firewall でも FQDN フィルタ・IDPS は可能

したがって、Azure 側で出口を持ち、Azure Firewall で検査する方が
性能・可用性・費用のいずれでも有利になる場合が多い。

ただし、**組織のポリシーで「すべての外向き通信を
社内の検査装置を通す」**と定められている場合は
強制トンネリングを選ばざるを得ない。
その場合は ER の帯域設計に織り込む必要がある。

なお、既定の送信アクセス（暗黙の SNAT）は廃止されており、
新規 VNET では
NAT Gateway、パブリック IP、LB の送信規則のいずれかを
明示的に構成する必要がある。
大量の外部接続を行う場合は NAT Gateway が
SNAT ポート枯渇を避ける定番の手段である。

• Azure 仮想マシンと DNS - 168.63.129.16 の謎に迫る - Qiita
  https://qiita.com/ksasaki/items/a18060701daf81ce3031
• IP アドレス 168.63.129.16 とは | Microsoft Docs
  https://docs.microsoft.com/ja-jp/azure/virtual-network/what-is-ip-address-168-63-129-16

※ Azure 仮想ネットワーク基礎（Azureの仮想ネットワーク）中の
　 「隔離型 VNET 環境からの外部通信設計の整理方法」にも同様のトピックが含まれる。

---

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