ネットワーク セキュリティ グループによるネットワーク トラフィックのフィルタリング

ネットワーク セキュリティ グループ (NSG) には、Azure Virtual Network (VNet) に接続されたリソースへのネットワーク トラフィックを許可または拒否する一連のセキュリティ規則が含まれています。 NSG はサブネットに関連付けることができるほか、クラシック モデルについては個々の VM に、Resource Manager モデルについては VM にアタッチされた個々のネットワーク インターフェイス (NIC) に関連付けることができます。 NSG をサブネットに関連付けた場合、そのサブネットに接続されているすべてのリソースにその NSG のルールが適用されます。 加えて VM や NIC にも NSG を関連付けることで、トラフィックをさらに制限することができます。

メモ

Azure には、リソースの作成と操作に関して、Resource Manager とクラシックの 2 種類のデプロイメント モデルがあります。 この記事では、両方のモデルについて取り上げていますが、最新のデプロイではリソース マネージャー モデルの使用をお勧めします。

NSG リソース

NSG には、次のプロパティが含まれています。

プロパティ Description 制約 考慮事項
Name NSG の名前 リージョン内で一意にする必要があります。
文字、数字、アンダースコア、ピリオド、ハイフンを使用できます。
先頭は文字か数字にします。
末尾は文字、数字、アンダー スコアのいずれかにします。
80 文字を超えないようにしてください。
複数の NSG の作成が必要になることがあるため、NSG の機能が識別しやすくなる名前付け規則を用意してください。
リージョン NSG が作成される Azure リージョン NSG は、その NSG と同じリージョン内のリソースにのみ関連付けることができます。 リージョンごとの NSG 数の上限については、Azure の制限に関する記事を参照してください。
リソース グループ NSG が存在するリソース グループ NSG はリソース グループに存在しますが、リソースが NSG と同じ Azure リージョン内にあれば、任意のリソース グループ内のリソースに関連付けることができます。 リソース グループは、複数のリソースをデプロイ ユニットとしてまとめて管理する目的で使用されます。
たとえば NSG は、それが関連付けられているリソースにまとめることができます。
ルール 許可するトラフィックと拒否するトラフィックを定義する受信規則または送信規則。 この記事の「NSG ルール」のセクションを参照してください。
メモ

エンドポイント ベースの ACL とネットワーク セキュリティ グループは、同じ VM インスタンスではサポートされません。 エンドポイントの ACL が既に導入されている場合に NSG を使用するには、初めにエンドポイントの ACL を削除します。 ACL を削除する方法については、PowerShell を使用してエンドポイントのアクセス制御リスト (ACL) を管理する方法についての記事を参照してください。

NSG ルール

NSG ルールには、次のプロパティが含まれています。

プロパティ Description 制約 考慮事項
名前 ルールの名前。 リージョン内で一意にする必要があります。
文字、数字、アンダースコア、ピリオド、ハイフンを使用できます。
先頭は文字か数字にします。
末尾は文字、数字、アンダー スコアのいずれかにします。
80 文字を超えないようにしてください。
1 つの NSG 内に複数のルールを作成することがあるため、ルールの機能を識別できる名前付け規則に準拠してください。
プロトコル ルールに関して一致するプロトコル。 TCP、UDP、または * * をプロトコルとして使用すると、UDP と TCP のほかに ICMP (East-West トラフィックのみ) も含まれ、必要なルール数を減らすことができます。
一方で、* を使用すると対象範囲が広くなりすぎることがあるため、その使用は必要な場合に限定してください。
発信元ポート範囲 ルールに関して一致するソース ポート範囲。 1 から 65535 までの 1 つのポート番号、ポート範囲 (1 ~ 65635 など)、または * (すべてのポート)。 発信元は、短期ポートである場合があります。 クライアント プログラムで決まったポートを使用している場合以外、通常は * を使用してください。
複数のルールを設定する必要がないように、できるだけポート範囲を使用してください。
複数のポートまたは複数のポート範囲をコンマでグループ化することはできません。
宛先ポート範囲 ルールに関して一致する宛先ポート範囲。 1 から 65535 までの 1 つのポート番号、ポート範囲 (1 ~ 65535 など)、または * (すべてのポート)。 複数のルールを設定する必要がないように、できるだけポート範囲を使用してください。
複数のポートまたは複数のポート範囲をコンマでグループ化することはできません。
発信元アドレスのプレフィックス ルールに関して一致する発信元アドレスのプレフィックスまたはタグ。 1 つの IP アドレス (例: 10.10.10.10)、IP サブネット (例: 192.168.1.0/24)、既定のタグ、または * (すべてのアドレス)。 ルールの数を減らすには、範囲、既定のタグ、* の使用を検討してください。
宛先アドレスのプレフィックス ルールに関して一致する宛先アドレスのプレフィックスまたはタグ。 1 つの IP アドレス (例: 10.10.10.10)、IP サブネット (例: 192.168.1.0/24)、既定のタグ、または * (すべてのアドレス)。 ルールの数を減らすには、範囲、既定のタグ、* の使用を検討してください。
方向 ルールに関して一致するトラフィックの方向。 受信または送信。 受信ルールと送信ルールは方向に基づいて個別に処理されます。
優先順位 ルールは、優先順位に従ってチェックされます。 いずれかのルールが適用されると、それ以上はルールの一致テストが行われなくなります。 100 ~ 4096 の数値 今後新しいルールを追加する余地を残すために、各ルールの優先度の数値を 100 ずつ飛ばして設定することを検討してください。
Access (アクセス) ルールが一致した場合に適用されるアクセスの種類。 許可または拒否。 パケットに一致する許可ルールが見つからない場合はパケットが削除されることに留意してください。

NSG には受信と送信の 2 つのルール セットがあります。 ルールの優先順位は、各セット内で一意である必要があります。

NSG ルールの処理

上図に、NSG ルールの処理方法を示します。

既定のタグ

既定のタグは、IP アドレスのカテゴリに対応するシステム指定の識別子です。 既定のタグは、任意のルールの発信元アドレスのプレフィックスおよび宛先アドレスのプレフィックス プロパティで使用できます。 使用できる既定のタグは 3 種類あります。

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

既定のルール

すべての NSG に既定のルール一式が含まれています。 既定のルールは削除できませんが、これには最も低い優先順位が割り当てられているため、ルールを作成することで上書きできます。

既定のルールでは、トラフィックが次のように許可または拒否されます。

  • 仮想ネットワーク: 仮想ネットワーク内で発信および着信するトラフィックについては、受信方向と送信方向の両方で許可されます。
  • インターネット: 送信トラフィックは許可されますが、受信トラフィックはブロックされます。
  • ロード バランサー: Azure のロード バランサーによる VM とロール インスタンスの正常性プローブが許可されます。 負荷分散セットを使用していない場合は、このルールを上書きできます。

受信の既定のルール

Name 優先順位 発信元 IP 発信元ポート 宛先 IP 宛先ポート プロトコル Access
AllowVNetInBound 65000 VirtualNetwork * VirtualNetwork * * ALLOW
AllowAzureLoadBalancerInBound 65001 AzureLoadBalancer * * * * ALLOW
DenyAllInBound 65500 * * * * * DENY

送信の既定のルール

Name 優先順位 発信元 IP 発信元ポート 宛先 IP 宛先ポート プロトコル Access
AllowVnetOutBound 65000 VirtualNetwork * VirtualNetwork * * ALLOW
AllowInternetOutBound 65001 * * インターネット * * ALLOW
DenyAllOutBound 65500 * * * * * DENY

NSG の関連付け

VM、NIC、サブネットには、使用しているデプロイ モデルに応じて、次のように NSG を関連付けることができます。

  • VM (クラシックのみ): セキュリティ規則は、VM との間で送受信されるすべてのトラフィックに適用されます。
  • NIC (Resource Manager のみ): セキュリティ規則は、NSG が関連付けられている NIC との間で送受信されるすべてのトラフィックに適用されます。 複数の NIC が使用されている VM の場合、各 NIC にそれぞれ異なる (または同じ) NSG を適用することができます。
  • サブネット (Resource Manager とクラシック): セキュリティ規則は、VNet に接続されたすべてのリソースとの間で送受信されるトラフィックに適用されます。

VM (デプロイメント モデルによっては NIC) に関連付ける NSG と、NIC または VM の接続先となるサブネットに関連付ける NSG とが異なっていてもかまいません。 セキュリティ規則は、各 NSG 内の優先度に基づき、次の順番でトラフィックに適用されます。

  • 受信トラフィック

    1. サブネットに適用される NSG: サブネット NSG に、トラフィックを拒否する照合ルールがある場合、パケットは破棄されます。

    2. NIC (Resource Manager) または VM (クラシック) に適用される NSG: トラフィックを拒否する照合ルールが VM\NIC NSG にある場合、サブネット NSG にトラフィックを許可する照合ルールがあったとしても、パケットは VM\NIC で破棄されます。

  • 送信トラフィック

    1. NIC (Resource Manager) または VM (クラシック) に適用される NSG: トラフィックを拒否する照合ルールが VM\NIC NSG にある場合、パケットは破棄されます。

    2. サブネットに適用される NSG: トラフィックを拒否する照合ルールがサブネット NSG にある場合、VM\NIC NSG にトラフィックを許可する照合ルールがあったとしても、パケットは破棄されます。

メモ

1 つの NSG は 1 つのサブネット、VM、または NIC に関連付けられますが、同じ NSG は必要なだけの数のリソースに関連付けることができます。

実装

Resource Manager デプロイメント モデルまたはクラシック デプロイメント モデルで NSG を実装するには、以下のツールを使用します。

デプロイ ツール クラシック リソース マネージャー
Azure ポータル はい はい
PowerShell はい はい
Azure CLI V1 はい はい
Azure CLI V2 いいえ はい
Azure Resource Manager テンプレート いいえ はい

計画

NSG を実装する前に、次の質問への回答を用意する必要があります。

  1. どのようなリソースとの間で送受信トラフィックをフィルタリングするか。 接続できるリソースとしては、NIC (Resource Manager)、VM (クラシック)、Cloud Services、Application Service Environments、VM Scale Sets などがあります。
  2. 送受信トラフィックのフィルタリング対象となるリソースは、既存の VNet 内のサブネットに接続されているか。

Azure におけるネットワーク セキュリティの計画について詳しくは、クラウド サービスとネットワーク セキュリティに関するページを参照してください。

設計上の考慮事項

計画」セクションの質問に対する回答を用意できたら、NSG を定義する前に、以下の各セクションを確認します。

制限

1 つのサブスクリプション内で使用できる NSG の数と、NSG ごとのルールの数には制限があります。 制限の詳細については、Azure の制限に関する記事をご覧ください。

VNet とサブネットの設計

NSG はサブネットに適用できるため、リソースをサブネットごとにグループ化し、NSG をサブネットに適用することで、NSG の数を最小限に抑えることができます。 NSG をサブネットに適用することにしたものの、既存の VNet とサブネットが NSG のことを考えて定義されていないことがあります。 場合によっては、用意した NSG 設計をサポートするように VNet とサブネットを新たに定義し、そのうえで、新しいサブネットに新しいリソースをデプロイすることも必要です。 その後、新しいサブネットに既存のリソースを移動する移行戦略を定義できます。

特殊なルール

以下のルールで許可されているトラフィックをブロックした場合、インフラストラクチャが Azure の重要なサービスと通信できなくなります。

  • ホスト ノードの仮想 IP: DHCP、DNS、正常性の監視などの基本的なインフラストラクチャ サービスは、仮想化されたホストの IP アドレス 168.63.129.16 を通じて提供されます。 このパブリック IP アドレスは Microsoft に属し、この目的のためにすべてのリージョンで使用される唯一の仮想化 IP アドレスです。 この IP アドレスは、VM をホストしているサーバー コンピューター (ホスト ノード) の物理 IP アドレスにマッピングされます。 ホスト ノードは、DHCP リレー、DNS の再帰的リゾルバー、および Load Balancer の正常性プローブとマシンの正常性プローブのプローブ元として機能します。 この IP アドレスへの通信は攻撃ではありません。
  • ライセンス (キー管理サービス): VM で実行される Windows イメージには、ライセンスを適用する必要があります。 ライセンスを適用するために、そのような問い合わせを処理するキー管理サービスのホスト サーバーには要求が送信されます。 この要求は、ポート 1688 を通じて送信されます。

ICMP トラフィック

現在の NSG のルールは、プロトコル TCP または UDP のみを許可します。 ICMP専用のタグはありません。 ただし VNet 内では、その中のすべてのポートおよびプロトコルとの間で送受信されるトラフィックが、既定のルール AllowVNetInBound によって許可されており、それによって ICMP トラフィックも許可されます。

サブネット

  • ワークロードに必要な階層の数を考慮してください。 サブネットを使用して各層を分離し、NSG をそのサブネットに適用できます。
  • VPN ゲートウェイまたは ExpressRoute 回線用のサブネットを実装する必要がある場合は、そのサブネットに NSG を適用しないでください。 適用すると、VNet 間接続またはクロスプレミス接続が機能しない場合があります。
  • ネットワーク仮想アプライアンス (NVA) を実装する必要がある場合は、専用のサブネットに NVA を接続し、NVA との間でトラフィックを送受信するためのユーザー定義ルート (UDR) を作成してください。 サブネット レベルの NSG を実装して、このサブネットに出入りするトラフィックをフィルター処理できます。 UDR について詳しくは、ユーザー定義のルートに関する記事をご覧ください。

ロード バランサー

  • 各ワークロードで使用されているロード バランサーごとに負荷分散とネットワーク アドレス変換 (NAT) に関するルールを検討してください。 NAT 規則は、NIC (Resource Manager) または VM/Cloud Services のロール インスタンス (クラシック) が属しているバックエンド プールにバインドされます。 ロード バランサーに実装されたルールでマップされたトラフィックのみを許可する NSG をバックエンド プールごとに作成することを検討してください。 バックエンド プールごとに NSG を作成することにより、ロード バランサーを経由せずにバックエンド プールに直接送信されるトラフィックも確実にフィルター処理されます。
  • クラシック デプロイでは、ロード バランサーのポートを VM またはロール インスタンスのポートにマップするエンドポイントを作成します。 Resource Manager では、パブリックに公開されたロード バランサーを自分で個別に作成することもできます。 受信トラフィックの宛先ポートは、ロード バランサーによって公開されているポートではなく、VM またはロール インスタンスの実際のポートです。 VM への接続用の発信元ポートとアドレスは、ロード バランサーによって公開されているポートとアドレスではなく、インターネット上にあるリモート コンピューターの発信元ポートとアドレスです。
  • 内部ロード バランサー (ILB) 経由のトラフィックをフィルター処理する NSG を作成する場合、適用される発信元ポートとアドレス範囲は、ロード バランサーのものではなく、呼び出しを開始するコンピューターのものになります。 宛先ポートとアドレス範囲は、ロード バランサーのものではなく、宛先コンピューターのものになります。

他の

  • エンドポイントベースのアクセス制御リスト (ACL) と NSG は、同じ VM インスタンスではサポートされません。 エンドポイントの ACL が既に導入されている場合に NSG を使用するには、初めにエンドポイントの ACL を削除します。 エンドポイントの ACL を削除する方法については、エンドポイントの ACL の管理についての記事を参照してください。
  • Resource Manager では、複数の NIC を備える VM で、1 つの NIC に 1 つの NSG を関連付けて、NIC ごとの管理 (リモート アクセス) を実現することができます。 それぞれの NIC に固有の NSG を関連付けることで、複数の NIC に対してトラフィック タイプを分散することができます。
  • ロード バランサーを使用する場合と同様に、他の VNet からのトラフィックをフィルター処理する際は、VNet に接続しているゲートウェイではなく、リモート コンピューターの発信元アドレス範囲を使用する必要があります。
  • VNet に多数の Azure サービスを接続することはできません。 VNet に接続されていない Azure リソースへのトラフィックを NSG でフィルター処理することはできません。 ご使用のサービスを VNet に接続できるかどうかは、そのサービスのドキュメントをご覧のうえで判断してください。

サンプル デプロイメント

この記事の情報の応用例として、次の図に示す 2 層アプリケーションの一般的なシナリオを考えてみましょう。

NSG

図に示すように、WEB1 VM と WEB2 VM が FrontEnd サブネットに接続され、DB1 VM と DB2 VM が BackEnd サブネットに接続されています。 どちらのサブネットも TestVNet VNet の一部です。 それぞれのアプリケーション コンポーネントは、VNet に接続された Azure VM 内で動作します。 このシナリオの要件は次のとおりです。

  1. WEB サーバーと DB サーバーの間のトラフィックを分離。
  2. 負荷分散ルールでロード バランサーからのトラフィックをすべての Web サーバーのポート 80 に転送。
  3. ロード バランサーのポート 50001 に送信されるトラフィックを、ロード バランサーの NAT 規則で WEB1 VM のポート 3389 に転送。
  4. 要件 1 と 3 を除き、フロントエンドまたはバックエンドの VM に対するインターネットからのアクセスを拒否。
  5. WEB サーバーと DB サーバーからの送信インターネット アクセスを拒否。
  6. FrontEnd サブネットからは、すべての Web サーバーのポート 3389 に対するアクセスを許可。
  7. FrontEnd サブネットからは、すべての DB サーバーのポート 3389 に対するアクセスを許可。
  8. FrontEnd サブネットからは、すべての DB サーバーのポート 1433 に対するアクセスを許可。
  9. DB サーバーで NIC 別に管理トラフィック (ポート 3389) とデータベース トラフィック (1433) を分離。

要件 1 ~ 6 (要件 3 と 4 を除く) は、いずれもサブネット空間に限定されます。 以下の NSG は前述の要件を満たすと共に、必要な NSG の数を最小限に抑えています。

FrontEnd

受信の規則

ルール Access (アクセス) 優先順位 発信元アドレス範囲 発信元ポート 宛先アドレス範囲 宛先ポート プロトコル
Allow-Inbound-HTTP-Internet ALLOW 100 インターネット * * 80 TCP
Allow-Inbound-RDP-Internet ALLOW 200 インターネット * * 3389 TCP
Deny-Inbound-All DENY 300 インターネット * * * TCP

送信の規則

ルール Access (アクセス) 優先順位 発信元アドレス範囲 発信元ポート 宛先アドレス範囲 宛先ポート プロトコル
Deny-Internet-All DENY 100 * * インターネット * *

BackEnd

受信の規則

ルール Access (アクセス) 優先順位 発信元アドレス範囲 発信元ポート 宛先アドレス範囲 宛先ポート プロトコル
Deny-Internet-All DENY 100 インターネット * * * *

送信の規則

ルール Access (アクセス) 優先順位 発信元アドレス範囲 発信元ポート 宛先アドレス範囲 宛先ポート プロトコル
Deny-Internet-All DENY 100 * * インターネット * *

以下の NSG を作成し、各 VM の NIC に関連付けます。

WEB1

受信の規則

ルール Access (アクセス) 優先順位 発信元アドレス範囲 発信元ポート 宛先アドレス範囲 宛先ポート プロトコル
Allow-Inbound-RDP-Internet ALLOW 100 インターネット * * 3389 TCP
Allow-Inbound-HTTP-Internet ALLOW 200 インターネット * * 80 TCP
メモ

前述のルールの発信元アドレス範囲はインターネットであって、ロード バランサーの仮想 IP アドレスではありません。 発信元ポートは 500001 ではなく * です。 ロード バランサーの NAT 規則は、NSG セキュリティ規則とは異なります。 NSG セキュリティ規則は、常にトラフィックの最初の発信元と最終的な宛先に関連付けられ、両者の間にあるロード バランサーは関係しません

WEB2

受信の規則

ルール Access (アクセス) 優先順位 発信元アドレス範囲 発信元ポート 宛先アドレス範囲 宛先ポート プロトコル
Deny-Inbound-RDP-Internet DENY 100 インターネット * * 3389 TCP
Allow-Inbound-HTTP-Internet ALLOW 200 インターネット * * 80 TCP

DB サーバー (管理 NIC)

受信の規則

ルール Access (アクセス) 優先順位 発信元アドレス範囲 発信元ポート 宛先アドレス範囲 宛先ポート プロトコル
Allow-Inbound-RDP-Front-end ALLOW 100 192.168.1.0/24 * * 3389 TCP

DB サーバー (データベース トラフィック NIC)

受信の規則

ルール Access (アクセス) 優先順位 発信元アドレス範囲 発信元ポート 宛先アドレス範囲 宛先ポート プロトコル
Allow-Inbound-SQL-Front-end ALLOW 100 192.168.1.0/24 * * 1433 TCP

NSG のいくつかは個々の NIC に関連付けられるので、これらのルールは、Resource Manager を通じてデプロイされたリソース用となります。 各ルールはその関連付けに応じて組み合わされ、サブネットと NIC に適用されます。

次のステップ