Azureネットワークセキュリティ設計入門｜VNet・NSG・ファイアウォールの考え方

「とりあえずVMを作ったら外からRDPで繋げるようにしました」——この一言を聞いたとき、どれだけ危険か説明できますか？

RDP（リモートデスクトッププロトコル）をインターネットに直接公開することは、玄関のドアを開けっ放しにして「鍵がかかっているから大丈夫」と言っているようなものです。ブルートフォース攻撃・資格情報スタッフィング・既知の脆弱性を使った侵入が、公開した瞬間から始まります。

Azureのネットワークセキュリティは「デフォルトで開いている」わけではありませんが、設計を誤れば簡単に穴が生まれます。この記事では、VNet・NSG・Azure Firewallの役割と実務での設計パターンを解説します。

クラウドセキュリティの全体像については「クラウドセキュリティとは？責任共有モデルから始める設計の全体像」を先にご覧ください。

クラウドのネットワークは「デフォルトで開いている」という誤解

オンプレミスでは物理的なネットワーク機器がデフォルトで通信を制御します。一方Azureでは、リソースを作成した後に利用者が明示的にネットワーク設定を行う必要があります。

ただし「何もしなければすべて開いている」わけではありません。AzureのVNet内のリソースはデフォルトでインターネットからのインバウンド通信がブロックされています。問題が起きるのは「使いやすくするために穴を開けた」後に、その穴を適切に管理しないケースです。

特に多いのは以下の3つのパターンです。

• 管理目的でRDP（3389番）・SSH（22番）をインターネットに直接公開
• NSGのインバウンドルールに「送信元：Any・ポート：Any・許可」を設定
• 開発環境のつもりで作ったリソースが本番データにアクセスできる状態のまま残っている

最小権限の原則はネットワーク設計にも適用されます。「必要な通信だけを許可し・それ以外はすべて拒否する」がAzureネットワークセキュリティの基本姿勢です。最小権限の考え方については「最小権限の原則とは？実務での考え方と設計例」を参照してください。

参考：Azure ネットワーク セキュリティの概要 | Microsoft Learn

Azureネットワークセキュリティを構成する3つの要素

VNet——Azureの中に作る仮想ネットワーク

VNet（Virtual Network：仮想ネットワーク） Azure上に構築する論理的なネットワーク。IPアドレス範囲を定義し、その中にサブネットを作成してリソースを配置する。異なるVNet間の通信はデフォルトで遮断される。

VNetはAzureにおける「ネットワークの箱」です。VMやデータベースをVNet内のサブネットに配置することで、リソース間の通信を論理的に分離・制御できます。

VNetの設計で重要なのはIPアドレス範囲の計画とサブネット分割です。後から変更が困難なため、設計段階で将来の拡張を見込んだアドレス範囲を確保することが重要です。

NSG——通信の許可・拒否を制御するルール

NSG（Network Security Group：ネットワークセキュリティグループ） VNet内のトラフィックを制御するファイアウォールルール。送信元・宛先・ポート・プロトコルの組み合わせで通信を許可・拒否する。サブネットまたはNICに関連付けて使用する。

NSGはAzureにおける基本的なファイアウォール機能です。インバウンド（外から内への通信）とアウトバウンド（内から外への通信）それぞれにルールを設定できます。

NSGはサブネット単位とNIC（ネットワークインターフェース）単位の両方に適用できます。通常はサブネット単位で設定し、特定のVMだけ例外ルールが必要な場合にNIC単位で追加します。

Azure Firewall——より高度な通信制御が必要な場合

Azure Firewall Azureが提供するマネージドのクラウドネットワークファイアウォールサービス。NSGより高度な機能（FQDN（ドメイン名）ベースのフィルタリング・脅威インテリジェンス・ログ分析）を提供する。有料サービス。

NSGはIPアドレス・ポート・プロトコルベースの制御です。FQDNベースのフィルタリング（特定のドメインへの通信のみ許可する）・アプリケーション層の制御・脅威インテリジェンスが必要な場合はAzure Firewallを検討します。

小〜中規模の環境ではNSGのみで十分なケースがほとんどです。Azure Firewallはコストがかかるため、本当に必要な要件があるかを確認してから導入してください。

参考：Azure Firewall とは | Microsoft Learn

VNet設計の基本——サブネット分割で守る

サブネットで役割を分離する理由

サブネット（Subnet） VNetのIPアドレス範囲をさらに細かく分割した論理的なネットワーク区画。役割ごとにサブネットを分けることで、NSGによるきめ細かいアクセス制御が可能になる。

サブネット分割の目的は「役割の異なるリソースを同じネットワークに置かない」ことです。WebサーバとデータベースサーバとAD管理用VMが同じサブネットにある状態では、1つが侵害されたとき他のリソースへ容易に横展開されます。

多層防御の観点でサブネットを分けることで、侵害の影響範囲を限定できます。多層防御の考え方については「クラウドセキュリティとは？」で解説しています。

実務で使えるサブネット設計パターン

一般的なWebアプリケーション環境での基本的なサブネット構成例です。

VNet（例：10.0.0.0/16）
├── フロントエンドサブネット（10.0.1.0/24）
│   └── Webサーバ・ロードバランサー
│   └── NSG：インターネットからの80/443を許可
├── バックエンドサブネット（10.0.2.0/24）
│   └── アプリケーションサーバ
│   └── NSG：フロントエンドサブネットからの通信のみ許可
├── データサブネット（10.0.3.0/24）
│   └── データベースサーバ
│   └── NSG：バックエンドサブネットからの通信のみ許可
└── 管理用サブネット（10.0.4.0/24）
    └── 踏み台サーバ（Bastion）
    └── NSG：管理者のIPからのみRDP/SSH許可

このパターンのポイントは「外部からデータベースに直接アクセスできない構造」にすることです。インターネット→フロントエンド→バックエンド→データという一方通行の流れを設計段階で作ります。

踏み台サーバ（Bastion Host） 管理用の通信を一元化するための中継サーバ。直接VMにRDP/SSHするのではなく、踏み台サーバを経由することで管理アクセスの経路を限定・ログを集約できる。AzureではAzure Bastionというマネージドサービスも提供されている。

参考：Azure Virtual Network の設計 | Microsoft Learn

NSG設計の実務パターン

インバウンド・アウトバウンドルールの考え方

NSGのルール設計の基本は**「デフォルト拒否・必要なものだけ許可」**です。

Azureでは以下のデフォルトルールが存在します。

デフォルトでインバウンドはほぼ遮断されていますが、アウトバウンドはインターネットへの通信が許可されています。マルウェアに感染したVMがC2サーバと通信するリスクを考えると、アウトバウンドも必要な通信のみに絞ることを推奨します。

AD環境での攻撃者のC2通信については「AD攻撃手法と要塞化」で解説しています。

管理ポート（RDP・SSH）をインターネットに公開しない

最も重要なルールです。RDP（3389番）・SSH（22番）をインターネットに直接公開することは絶対に避けてください。

推奨する管理アクセスの方法

JITアクセスはDefender for Cloudの機能の一つです。Defender for Cloudについては「Azure Defender for Cloudとは？」で解説しています。

参考：Azure Bastion とは | Microsoft Learn

優先度の設計——ルールの順番が重要な理由

NSG優先度（Priority） NSGルールの処理順序を決める数値（100〜4096）。数値が小さいほど優先して処理される。条件が一致した時点で処理が止まるため、ルールの順番が重要。

NSGのルールは優先度の低い数値から順に評価され、条件に一致した時点でそのルールが適用されます。

設計の原則

• 100〜200番台：明示的に許可するルール（特定IPからのRDP許可など）
• 300〜900番台：追加の許可ルール（サービス間通信など）
• 1000番台：明示的に拒否するルール
• 4096：デフォルトの「すべて拒否」（変更不可）

「すべて許可するルール（Any・Any・Allow）」を低い優先度番号で設定してしまうと、後続のすべての拒否ルールが無効になります。これが現場でよくある設定ミスの一つです。

よくある失敗パターン

① RDP・SSHをインターネットに直接公開している

「手軽に接続できるから」という理由でRDP/SSHをAny許可しているケースが最も多い失敗です。Defender for Cloudの推奨事項でも常にトップに表示される問題です。Azure BastionまたはJITアクセスへの移行を検討してください。

② NSGに「Any・Any・Allow」ルールを設定している

トラブルシューティングのために一時的にすべての通信を許可したまま放置しているケースがあります。「一時的」のつもりが永続化するのが典型的なパターンです。作業後は必ずルールを削除または修正してください。

③ すべてのリソースを同じサブネットに配置している

WebサーバもDBサーバも管理用VMも同じサブネットに入っている状態です。1台が侵害されると同一サブネット内の全リソースへ横展開できる状態になります。役割ごとにサブネットを分けることが防御の基本です。

④ アウトバウンドルールを設定していない

インバウンドは制御しているがアウトバウンドは「AllowInternetOutBound」のままにしているケースです。感染したVMがC2サーバと自由に通信できる状態になります。必要なアウトバウンド通信のみを明示的に許可する設計を推奨します。

Azureネットワークセキュリティ設計チェックリスト

VNet・サブネット設計

• VNetのIPアドレス範囲を計画してから作成した
• 役割ごとにサブネットを分割している（フロントエンド・バックエンド・データ・管理）
• 開発環境と本番環境のVNetを分離している

NSG設計

• すべてのサブネットにNSGを関連付けている
• RDP（3389）・SSH（22）をインターネットに直接公開していない
• 「Any・Any・Allow」のような過剰な許可ルールがないか確認した
• アウトバウンドルールで不要なインターネット通信を制限している
• NSGルールの優先度が意図通りに設定されている

管理アクセス

• 管理アクセスはAzure Bastion・JIT・VPNのいずれかで実現している
• 踏み台サーバを使う場合、接続元IPを特定のアドレスに限定している

監視

• NSGフローログを有効にしている
• Defender for Cloudのネットワーク系推奨事項を確認した

まとめ——ネットワーク設計は「最初に閉じる」が原則

Azureのネットワークセキュリティ設計の核心は「デフォルトで閉じた状態から始め・必要なものだけ開ける」という思想です。

VNetでリソースを論理分離し・NSGで通信を制御し・管理ポートはインターネットに直接公開しない——この3点を守るだけで、ネットワーク起因のセキュリティリスクを大幅に低減できます。

今日確認すべきことは1つです。AzureポータルでNSGのインバウンドルールを開き、RDP（3389）またはSSH（22）が送信元「Any」で許可されていないか確認してください。該当するルールがあれば即座に修正してください。

次のステップはゼロトラストの考え方をAzureで実装するパターンです。「ゼロトラストとは？Azureでの実装パターン」（公開予定）で詳しく解説します。

あわせてご覧ください

• クラウドセキュリティとは？責任共有モデルから始める設計の全体像
• Azure Defender for Cloudとは？セキュリティスコアと推奨事項で守れる環境を作る
• 最小権限の原則とは？実務での考え方と設計例
• AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る
• セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方