Skip to content

MS_AzureNSG

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

Network Security Group (NSG)

概要

補足（NSG は「ファイアウォール」ではない）: NSG を
オンプレのファイアウォール製品と同じものと考えると誤る。

NSG ファイアウォール（Azure Firewall / NVA）
層 L3/L4（IP・ポート・プロトコル） L7 まで（FQDN、URL、アプリ）
実装 各ホストの仮想スイッチで分散処理（VPF） 専用の機器／サービスを経由（串）
性能 ボトルネックにならない スループットに上限がある
費用 無料 高い
ログ フロー ログ（別途有効化） 詳細なログが標準
経路 変えない（フィルタするだけ） 経由させる（UDR が要る）

重要なのは、NSG は経路を変えないという点である。
各仮想マシンのホスト側で分散してフィルタするため、
どれだけ規則を書いても中央の機器を圧迫しない。

その代わり、FQDN での制御ができない
（サービス タグを除く）。
これがAzureのプロキシ的なモノ。で述べた
「FQDN で制限するなら Azure Firewall しか選択肢が無い」の理由である。

詳細

  • 以下のような仕組みになっている。
  • 既定値を知ると理解しやすい。

設定例

VMへのインバウンド設定

  • VM の NIC に既定で作成＆関連付けられた NSG がある。
    • 既定では、
      • インバウンドはホワイトリスト
      • アウトバウンドは制限なし
    • ホワイト or ブラック・リスト化
      • ホワイト・リスト化
        優先順位の高い位置に、許可（Allow）ルールを追加
      • ブラック・リスト化
        優先順位の高い位置に、拒否（Deny）ルールを追加
      • 優先順位
        ・世間一般では、ブラック・リスト化 ＜ ホワイト・リスト化 らしい。
        ・故に、先ず、ホワイト・リストを見て許可、その後で、ブラック・リストを見て拒否する。
    • SRC と DST には以下がある。
      • Any
      • IP アドレス（範囲指定も可能）
      • サービスタグ or 仮想ネットワーク
      • アプリケーション・セキュリティ・グループ
  • NIC 設定からサブネット設定に変更する。
    • 当該サブネット向けの NSG を新規作成（既定値）。
    • 使用する VM に絞った RDP/SSH のインバウンドを許可する。
    • 作成した NSG をサブネットに関連付ける。
    • VM の NIC に関連付けられた NSG をすべて削除する。

移行メモ（体裁）: 原典の「拒否すする」は
「拒否する」の誤りであるため修正した。
また「作成したNSGをサブネットを関連付ける」は助詞の誤りのため
「サブネットに関連付ける」とした。

補足（規則の評価は「最初に一致したもの勝ち」）: NSG の規則は
優先度（100〜4096）の小さい順に評価され、
最初に一致した時点で確定する。以降の規則は評価されない。

優先度 100  : Allow  10.0.0.0/24 → 3389   ← ここで一致したら
優先度 200  : Deny   *           → 3389   ← ここは見られない
優先度 65500: DenyAllInBound（既定）

したがって、本文の「先ずホワイト・リストを見て許可、
その後でブラック・リストを見て拒否」という順序は
優先度の数値をどう振るかの話である。

よくある設計は次のとおり。

優先度帯 用途
100〜999 明示的な拒否（絶対に通したくないもの）
1000〜1999 明示的な許可
2000〜 補助的な規則
65000〜 既定の規則（変更不可）

「Deny を先に置く」設計の方が事故が少ない
（後から広い Allow を足しても、
重要な Deny が先に評価されるため）。

補足（NIC ではなくサブネットに付けるべき理由）: 本文の手順が
**「NIC の NSG を削除してサブネットに付け替える」**という
流れになっている点は重要である。

サブネットに付ける NIC に付ける
管理対象 サブネット単位（数個） VM 単位（数十〜数百）
新しい VM 自動的に適用される 付け忘れる
一貫性 保たれる 崩れやすい
例外 作りにくい 作りやすい（＝穴が開きやすい）

「付け忘れ」が起きないという点が決定的である。

個別の制御が必要な場合は、
NIC に NSG を追加するのではなく
**アプリケーション セキュリティ グループ（ASG）**を使う。
ASG は「NIC に貼るラベル」であり、
NSG の規則で IP の代わりに ASG 名を書ける。

【IP ベース】   Allow 10.0.1.0/24 → 10.0.2.0/24 : 1433
【ASG ベース】  Allow asg-web     → asg-db      : 1433

IP 設計に依存しないため、規則が読みやすく、保守しやすい。

Azure Bastion

関連付け

NSG はサブネットに関連付けることができる。
サブネットに接続されているすべてのリソースにその NSG のルールが適用される。

クラシック モデル

  • サブネット以外にも、個々の VM に関連付けることができる。
  • これにより、トラフィックをさらに制限することができる。

Resource Manager モデル

  • サブネット以外にも、VM の NIC に関連付けることができる。
  • これにより、トラフィックをさらに制限することができる。

補足: クラシック モデル（ASM）は既に廃止されているため、
現在は Resource Manager モデル（サブネット または NIC）のみである
（Azureの管理ポータルとARM API）。

適用順序

各 NSG 内の優先度に基づき、次の順番でトラフィックに適用される。

受信トラフィック

  1. サブネットに適用される NSG
  2. NIC (Resource Manager) または VM (クラシック) に適用される NSG

送信トラフィック

  1. NIC (Resource Manager) または VM (クラシック) に適用される NSG
  2. サブネットに適用される NSG

補足（この順序が「両方で許可が必要」を意味する）: 受信と送信で
順序が逆になっているのは、パケットの進行方向を考えれば自然である。

【受信】外 → [サブネット NSG] → [NIC NSG] → VM
【送信】VM → [NIC NSG] → [サブネット NSG] → 外

重要なのは、両方の NSG で許可されないと通らないという点である
（AND 条件）。

「疎通しない」トラブルの切り分けでは、

手段 内容
有効なセキュリティ規則 ポータルの NIC の画面。サブネットと NIC を合成した結果が見られる
IP フロー検証（Network Watcher） 送信元・宛先・ポートを指定して、通るかどうかを判定。どの規則で落ちたかまで表示される
フロー ログ 実際の通信の許可／拒否を記録

の順に使うのが早い。IP フロー検証が最も直接的である。

なお、NSG はステートフルである。
受信を許可すれば、その応答は送信規則に関わらず返る
（逆も同様）。応答用の規則を書く必要は無い。

サービス・タグ

IP アドレスのカテゴリに対応するシステム指定の識別子

対象となるNSG ルールのプロパティ

既定のサービス・タグは、以下の任意の NSG ルールのプロパティで使用可能。

  • 発信元アドレスのプレフィックス
  • 宛先アドレスのプレフィックス

便利なサービス・タグ

  • VirtualNetwork
  • Internet
  • AzureCloud
  • Storage、Sql
  • AzureCosmosDB
  • AzureKeyVault
  • AzureMonitor
  • AzureActiveDirectory

サービス・タグの一覧

補足（サービス タグが実務で不可欠な理由）: Azure の各サービスの
IP アドレス範囲は変動する。これを手で追うのは不可能である。

サービス タグを使うと、

【手書き】 Allow → 20.43.x.x, 20.44.x.x, 40.79.x.x, ...（数十〜数百）
           → Microsoft が範囲を変更したら破綻する

【タグ】   Allow → Sql.JapanEast
           → Microsoft が自動で更新してくれる

となり、保守が不要になる。

リージョン修飾（Storage.JapanEast のように書く）ができるものもあり、
必要なリージョンだけに絞れる。
単に Storage と書くと全世界のストレージが対象になるため、
絞れるものは絞るのが望ましい。

ただし注意点として、
サービス タグは「Azure のそのサービス全体」を指す。
Storage を許可すると、他テナントのストレージにも到達できる。
データ持ち出しを防ぐ観点では不十分であり、
そこは Azure Private Endpoint の役割になる。

構成のポイント

NSGの作成単位

VNET 単位に作成、VNET 中の全サブネットに関連付けると楽。

補足: 「楽」ではあるが、層ごとに分ける方が
セキュリティ上は望ましい。

方針 長所 短所
VNET に 1 つ 管理が単純 層ごとの制御ができない（Web も DB も同じ規則）
サブネット（層）ごと DB サブネットには Web からの 1433 のみ、等の制御ができる 数が増える

規模と要件次第だが、
本番環境では層ごとに分けるのが原則である
（Azureのサブネッティングの
「層ごとにサブネットを切る」方針と対応する）。

数が増える問題は、Azure Virtual Network Manager の
セキュリティ管理者規則で一元管理する、
あるいは IaC で生成することで解消できる。

ILBに対するNSG

  • Azure Load Balancerに書かれた理由で出来ない。
  • 以下のように、ネットワーク間を許可する。
    • 誤）192.168.2.0/24 → 192.168.3.100/32
    • 正）192.168.2.0/24 → 192.168.3.0/24

補足（なぜ ILB の IP を宛先に書けないのか）: ロード バランサーは
**物理的な機器ではなく、分散して動作するソフトウェア（VFP）**である。

【誤解】 クライアント → [LB という機器] → VM
         （LB の IP 宛のパケットが実在する）

【実際】 クライアント → VM（宛先 IP は VM のものに書き換わる）
         ※ LB は「宛先を書き換える規則」であり、通過する箱ではない

NSG が評価される時点では、宛先 IP は既に VM のものに
なっている（DNAT 済み）。
したがって、ILB のフロントエンド IP を宛先に書いた規則は
一致しない。

本文の「正」が示すとおり、
バックエンドの VM が属するサブネット範囲を宛先に書くのが正しい。

同じ理由で、

  • 正常性プローブは AzureLoadBalancer サービス タグからの通信として
    許可する必要がある（既定の規則で許可されている）、
  • ILB を経由しても送信元 IP はクライアントのままである
    （SNAT されない）

という点も押さえておきたい。

既定値

3種のサービス・タグ

以下の 3 種類のサービス・タグが既定値に指定されている。

  • VirtualNetwork (Resource Manager)（クラシックの場合は VIRTUAL_NETWORK）:
    仮想ネットワーク アドレス空間（Azure で定義されている CIDR 範囲）だけでなく、
    すべての接続されているオンプレミス アドレス空間と接続されているVNET（ローカル ネットワーク）が含まれる。
  • AzureLoadBalancer (Resource Manager)（クラシックの場合は AZURE_LOADBALANCER）:
    • Azure のインフラストラクチャのロード バランサを表す。
    • Azure の正常性プローブ（≒死活監視）が開始される Azure データセンター IP に変換される。
  • Internet (Resource Manager)（クラシックの場合は INTERNET）:
    • パブリック インターネットによってアクセスできる仮想ネットワークの外部の IP アドレス空間を表す。
    • Azure に所有されているパブリック IP アドレス空間がこの範囲に含まれる。

補足（VirtualNetwork タグの範囲が広い点に注意）: 説明にあるとおり、
VirtualNetwork は自 VNET だけを指すのではない。

含まれるもの
自 VNET のアドレス空間
ピアリングした VNET
VPN / ExpressRoute で繋がったオンプレミス
ローカル ネットワーク ゲートウェイで定義した範囲

つまり、既定の AllowVNetInBound を残したままだと、
オンプレミス全体からの通信が許可されていることになる。

閉域構成では、この既定規則を
より高い優先度の明示的な規則で上書きする必要がある。
「NSG を付けたのにオンプレから入れてしまう」というのは
ほぼこの理解不足が原因である。

既定のルール

概要

  • 既定のルールでは、トラフィックが次のように許可/拒否される。
    • 仮想ネットワーク
      発信 / 着信トラフィックは、送信 / 受信方向の両方で許可。
    • ロード バランサ
      • ロード バランサによる VM の正常性プローブ（≒死活監視）を許可。
      • 負荷分散セットを使用していない場合は、このルールを上書きできる。
    • インターネット
      • トラフィックは送信方向は許可
      • 受信方向はブロックされる。
  • ザックリ言って、
    • アウトバウンド：全開
    • インバウンド：全閉
    • （Internet ⇔）ロードバランサ（⇔ VM 死活監視）：制限なし

補足（「アウトバウンド全開」が既定である点が最重要）: この一行が
本ページで最も注意すべき事実である。

何も設定しなければ、VM は全世界のどこへでも通信できる。
これは、

リスク 内容
データの持ち出し 侵害された VM が外部へ送信できる
C2 通信 マルウェアが指令サーバに接続できる
意図しない依存 気付かないうちに外部サービスに依存する

という問題に直結する。
Azureのプロキシ的なモノ。、
Azureのアウトバウンド設計が
「アウトバウンドの制御」を主題にしているのはこのためである。

閉域構成では、

  1. DenyAllOutBound より高い優先度で Internet 宛を Deny、
  2. 必要な宛先だけをサービス タグや Private Endpoint で許可、
  3. FQDN 単位の制御が要るなら UDR で Azure Firewall へ向ける

という手順を踏む。

設定

  • 受信
# Name 優先順位 発信元 IP 発信元ポート 宛先 IP 宛先ポート プロトコル Access
1 AllowVNetInBound 65000 VirtualNetwork * VirtualNetwork * * ALLOW
2 AllowAzureLoadBalancerInBound 65001 AzureLoadBalancer * * * * ALLOW
3 DenyAllInBound 65500 * * * * * DENY
  • 送信
# Name 優先順位 発信元 IP 発信元ポート 宛先 IP 宛先ポート プロトコル Access
1 AllowVnetOutBound 65000 VirtualNetwork * VirtualNetwork * * ALLOW
2 AllowInternetOutBound 65001 * * Internet * * ALLOW
3 DenyAllOutBound 65500 * * * * * DENY

補足（既定の規則は削除できない）: 優先度 65000 以降の既定規則は
削除・編集ができない。
変えたい場合は、より小さい優先度（＝高い優先順位）の規則で
上書きする。

例えばインターネットへの送信を止めるには、

優先度 4000 : Deny  * → Internet  (すべてのポート)   ← これを追加する
優先度 65001: AllowInternetOutBound（既定・削除不可） ← 評価されなくなる

とする。既定規則を消そうとして「消せない」と悩む必要はない。

参考

Azure Resource Manager (ARM)

Microsoft Docs

その他

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally