ネットワークセキュリティグループとアプリケーションセキュリティグループ

この記事では、トラフィックフィルタリングにネットワークセキュリティグループ (NSG) を使用して、Azure仮想ネットワーク内のネットワークトラフィックを制御する方法について説明します。また、ネットワークインターフェイスを論理的にグループ化するためのアプリケーションセキュリティグループ (ASG) についても説明します。

この記事の内容

ネットワークセキュリティグループを使用すると、Azure仮想ネットワーク内のリソースの受信トラフィックと送信トラフィックをフィルター処理できます。アプリケーションセキュリティグループを使用すると、ネットワークインターフェイスをロール別にグループ化できます。個々の IP アドレスではなく論理グループを参照する NSG 規則を記述します。

この記事が必要なユーザー

次の場合は、この記事をお読みください。

Azure仮想ネットワークに接続するすべてのリソースをデプロイします。
サブネット、仮想マシン、またはAzure サービス間を流れるトラフィックを制御する必要があります。
VM が頻繁にスケーリングされたり、IP アドレスが変更されたりする環境のルール管理を簡素化したいと考えています。
新しいAzure ワークロードのセキュリティベースラインを構築しています。

リフトアンドシフトフォーカス: オンプレミスのファイアウォールとセグメント化ルールをサブネット間の NSG として再作成し、アプリケーションで既に使用されている階層間フローをミラーリングします。

フォーカスを最新化する: アプリケーションセキュリティグループを使用して、IP アドレスではなくワークロードロール別にルールを表現し、サブネット NSG をハブファイアウォールとユーザー定義ルートと組み合わせて、強制的にエグレスを検査します。

クラウド間のフォーカス:AWS と Google Cloud のセキュリティグループルールをAzure NSG にミラー化して、ワークロードがクラウド間を移動するにつれてトラフィックポリシーの一貫性を維持します。

Azureサービスと機能

次の表では、Azure仮想ネットワークでのネットワークトラフィックのフィルター処理に使用されるサービスと機能について説明します。

サービスまたは機能	提供される内容	いつ使用するか
ネットワークセキュリティグループ (NSG)	サブネットまたはネットワークインターフェイスに適用される受信および送信のセキュリティ規則のセット。ルールは優先度によって評価されます。最も低い数値が優先されます。	サブネットまたは個々の VM レベルでトラフィックを制御します。仮想ネットワークを使用するすべてのワークロードに適用します。
アプリケーションセキュリティグループ (ASG)	ネットワークインターフェイスの論理グループ。 IP アドレスの代わりに NSG ルールのソースまたは宛先として ASG を使用します。	同じ役割を果たす複数の VM (Web サーバー、アプリサーバー) があり、その IP アドレスはスケーリングによって変化します。グループ化されたすべての NIC は、同じ仮想ネットワーク内にある必要があります。
サービスタグ	Microsoftによって自動的に管理および更新される、Azure サービスの IP アドレスプレフィックスの名前付きグループ。例: `AzureCloud`、`Storage`、`AzureLoadBalancer`、`Sql`。	IP 範囲をハードコーディングせずに NSG ルールのAzure サービスを参照します。 Microsoft は基になる IP 範囲を自動的に更新します。カスタムサービスタグを作成することはできません。

一般的なサービスタグ

次の表に、NSG ルールで最もよく使用されるサービスタグを示します。

サービスタグ	説明
`Internet`	仮想ネットワークの外部にあるすべてのパブリック IP アドレス空間。パブリックインターネットから発信される、またはパブリックインターネット宛てのすべてのトラフィックに一致します。
`VirtualNetwork`	仮想ネットワークアドレス空間、接続されているすべてのアドレス空間 (ピアリングされた VNet)、VPN/ExpressRoute 経由で接続されたオンプレミスネットワーク、および任意のサービスエンドポイント。既定のルートが含まれます。
`AzureLoadBalancer`	Azure インフラストラクチャロードバランサー Azure の正常性プローブの送信元となるホストの仮想 IP に変換されます。正常性プローブトラフィックを許可するために、受信規則で使用されます。
`Storage`	Azure Storage サービスの IP アドレス空間 `Storage.WestUS2`などの地域バリアントをサポートします。 VNet 内からAzure Storageへのアクセスを許可または制限するために使用します。
`AzureCloud`	すべての Azure データセンターのパブリック IP アドレス。 `AzureCloud.EastUS`などの地域バリアントをサポートします。一般的に、Azure サービスへの送信トラフィックを許可する場合に便利です。
`Sql`	Azure SQL Database、Azure Database for MySQL、Azure Database for PostgreSQL、Azure Database for MariaDB、およびAzure Synapse AnalyticsIP アドレスプレフィックス。地域バリアントをサポートします。
拡張セキュリティ規則	1 つのルールで複数の IP アドレス、IP 範囲、ポートを受け入れる拡張 NSG ルール。多数の IP またはポート範囲のトラフィックを許可または拒否する必要がある場合は、ルールの数を減らします。ルールごとに複数の IP とポート範囲、および最大 10 個のアプリケーションセキュリティグループをサポートしますが、ルールごとにサービスタグは 1 つだけです。

選択する方法

次のガイダンスを使用して、シナリオに適したセキュリティコンストラクトを選択します。

NSG の制限とクォータ

Azureでは、NSG リソースに次の既定の制限が適用されます。ほとんどの制限を引き上げるには、Azure サポートを使用して引き上げを要求します。

リソース	既定の制限	上限
NSGごとのルール	2,000	2,000
サブスクリプションあたりの NSG 数	5,000	5,000
サブネットあたりの NSG 数	1	1
NIC あたりの NSG	1	1
サブスクリプションあたりの ASG 数	3,000	3,000
ASG ごとの NIC 数	サブスクリプションによって異なります	サポートに連絡する
各ルールで送信元または宛先として参照される ASG	10	10

Note

NSG ごとに 2,000 ルールの制限には、カスタムルールと既定のルールの両方が含まれます。この制限に近づく場合は、拡張セキュリティ規則を使用して、複数の IP またはポート範囲をより少ない規則に結合します。

NSG と ASG: 使用するタイミング

次の表を使用して、シナリオに合ったセキュリティコンストラクトを決定します。

シナリオ	Use	なぜでしょうか
サブネット内のすべての VM のトラフィックを制御する	サブネットレベルでの NSG	1 つの NSG がサブネット内のすべてのリソースに適用されます。統一されたポリシーの管理が最も簡単です。
サブネットとは別に特定の VM のトラフィックを制御する	NIC レベルの NSG	他の VM に影響を与えずに例外を許可します。ジャンプボックスや bastion ホストに便利です。
多くの VM が同じ役割を果たし、IP アドレスが頻繁に変更される	ASG	ロール (Web、アプリ、データ) によって VM をグループに追加します。グループ名に対してルールを書き込みます。 VM が新しい IP をスケーリングまたは取得するときに、更新は必要ありません。
Azure サービス (ストレージ、SQL、Key Vault) をソースまたは宛先として参照する	サービスタグを持つ NSG	Microsoft更新される可能性がある IP 範囲のハードコーディングは避けてください。サービスタグは自動的に最新の状態を維持します。

次の図は、ASG を使用して、個々の IP アドレスではなく、ロール別に VM をグループ化し、論理グループ間で NSG ルールを書き込む方法を示しています。

セキュリティ体制チェックリスト

運用環境にデプロイする前に、このチェックリストに対して NSG 構成を検証します。

Requirement	アクション	Reference
既定の拒否体制	既定の `DenyAllInbound` 規則 (優先度 65500) に依存していることを確認します。既定の拒否をバイパスする広範な許可ルールを作成しないでください。	セキュリティに関する考慮事項
管理者ポートでインターネットにアクセスできない	SSH (22) および RDP (3389) 上の `0.0.0.0/0` からの受信トラフィックをブロックします。管理アクセスには、Azure Bastionまたは VPN を使用します。	セキュリティに関する考慮事項
Azure Firewallと組み合わせて詳細な検査を行う	NSG はレイヤー 3/4 でのみフィルター処理されます。アプリケーション層 (レイヤー 7) のフィルター処理、TLS 検査、脅威インテリジェンスのAzure Firewallを追加します。	Azure Firewallとネットワークのセグメント化
診断のフローログを有効にする	VNet フローログを使用して、セキュリティ調査とコンプライアンスのためにトラフィックデータをキャプチャします。	ネットワークの監視と診断

ルールの評価順序

NSG ルールでは、first-match-wins セマンティクスが使用されます。

Azureは、優先順位の低い番号 (最も優先度が高い) の順にルールを評価します。
Azureは、ソース、送信元ポート、宛先、宛先ポート、プロトコルの 5 つのタプルに対して各規則を評価します。
トラフィックがルールに一致すると、処理が停止します。 Azureでは、それ以上のルールは評価されません。
一致するカスタムルールがない場合は、既定のルールが適用されます。既定のルールは削除できませんが、優先度番号が 100 ~ 4096 のカスタムルールを作成することでオーバーライドできます。

既定のルール (合計 6 つ):

方向	規則名	優先度	アクション
Inbound	AllowVNetInBound	65000	許可する
Inbound	AllowAzureLoadBalancerInBound	65001	許可する
Inbound	DenyAllInbound	65500	Deny
送信	Vnetアウトバウンド許可	65000	許可する
送信	AllowInternetOutBound	65001	許可する
送信	DenyAllOutBound	65500	Deny

ASGの制約

アプリケーションセキュリティグループを使用する場合は、次の制約に注意してください。

ASG 内のすべてのネットワークインターフェイスは、ASG に割り当てられた最初のネットワークインターフェイスと同じ仮想ネットワーク内に存在する必要があります。
ルールの送信元と宛先の両方で ASG を参照する場合、両方のグループのネットワークインターフェイスが同じ仮想ネットワーク内にある必要があります。
ルールのソースまたは宛先では、最大 10 個の ASG を参照できます。

サブネットレベルの NSG とネットワークインターフェイスレベルの NSG の連携

NSG は、そのサブネット内の VM 上のサブネットとネットワークインターフェイスの両方に関連付けることができます。その場合、Azure は両方の NSG を評価し、トラフィックはその両方を通過する必要があります。最も制限の厳しい組み合わせが優先されます。

方向	最初に評価される	2番目に評価された
Inbound	サブネット NSG	NIC NSG
送信	NIC NSG	サブネット NSG

Tip

より簡単なトラブルシューティングを行うには、NSG をサブネットまたはネットワークインターフェイスに関連付けますが、両方を関連付けることはできません。両方が必要な場合は、目的のルールの相互作用を明確に文書化します。

実際の例: ジャンプボックスを含む Web 層

インターネットからの受信 HTTPS (ポート 443) を許可し、それ以外のすべてを拒否するサブネットレベルの NSG を持つサブネットについて考えます。そのサブネット内のジャンプボックス VM には、特定の管理 IP 範囲からの受信 SSH (ポート 22) も許可するネットワークインターフェイスレベルの NSG があります。

Web トラフィック (ポート 443): サブネット NSG で許可されます。 Web VM 上のネットワークインターフェイス NSG には、443 の拒否規則はありません (既定の AllowVNetInBound 許可)。トラフィックフロー。
ジャンプボックス (管理 IP からポート 22) に SSH 接続します。 サブネット NSG は、インターネットからポート 22 のトラフィックを拒否します。ネットワークインターフェイス NSG で管理範囲からの SSH が許可されている場合でも、サブネット NSG によって最初にブロックされます。 解像度：サブネット NSG にルールを追加して、管理 IP 範囲からポート 22 を許可するか、Azure Bastionを使用してパブリックインターネットパス全体をバイパスします。

この例では、デュアル NSG によって複雑さが増す理由を示します。両方とも個別にトラフィックを許可する必要があります。

次の図は、サブネット NSG と NIC NSG の両方を関連付ける場合の受信トラフィック評価パスを示しています。トラフィックは両方の NSG を通過する必要があります。最も制限の厳しい組み合わせが優先されます。

Azure Virtual Network Managerの相互作用

組織で Azure Virtual Network Manager (AVNM) のセキュリティ管理者ルールを使用している場合、Azure ではそれらのルールが NSG ルールより先に評価されます。セキュリティ管理者ルールでは、許可 (NSG 評価を続行)、常に許可 (NSG をバイパス)、または拒否 (NSG 評価前のブロック) を使用できます。一元化されたネットワークセキュリティ管理については、「Azure Virtual Network Managerと一元管理」を参照してください。

設計上の考慮事項

リフトアンドシフトにおける NSG と ASG の設計上の重点

オンプレミスのセグメント化をサブネットレベルの NSG に変換します。アプリケーションで既に使用されている階層間フロー (Web からアプリ、アプリからデータベースなど) のみを許可し、それ以外のすべてを拒否します。
現在のファイアウォール規則ベースから開始し、移行後に NSG フローログを使用して、実際に必要なフローを確認します。
簡単にするために、まずサブネットレベルで NSG を適用します。個々の VM で例外が必要な場合にのみ、NIC レベルの規則を追加します。
ハードコーディングされた IP アドレスの代わりにサービスタグ ( VirtualNetwork や AzureLoadBalancerなど) を使用して、移行中にルールの再アドレス指定を行うことができます。

NSG と ASG の設計フォーカスを最新化する

アプリケーションセキュリティグループを使用して、ロール (Web、アプリ、データ) ごとにネットワークインターフェイスをグループ化し、ルールが意図を記述し、インスタンスのスケーリングに合わせて自動的に適応できるようにします。
サブネット NSG をハブ Azure Firewallと組み合わせる: NSG は層間のマイクロセグメント化を処理しますが、ファイアウォールは信頼境界を越えるトラフィックを検査します。
プライベートエンドポイントサブネットのみが PaaS サービスに到達することを許可し、ユーザー定義ルートを使用してハブファイアウォールを経由する送信トラフィックを強制します。
Azure Virtual Network Managerセキュリティ管理者ルールを使用する場合は、優先順位 (NSG より前に評価されます) を計画して、プラットフォーム全体のガードレールがワークロード NSG と競合しないようにします。

クロスクラウド NSG と ASG の設計フォーカス

AWS と Google Cloud のセキュリティグループルールをAzure NSG にミラーリングして、同等のレベルが移行後に同じポリシーを適用するようにします。
クラウド間アプリケーションの依存関係に必要な特定のポートとソースのみを許可し、検査された IPsec トンネルを介してそのトラフィックをルーティングします。
運用チームがトラブルシューティングを行うときに同等のワークロードを関連付けることができるように、クラウド間でアプリケーションセキュリティグループ名を標準化します。
NSG をセキュリティで保護されたVirtual WAN ハブファイアウォールとペアリングすると、クロスクラウドトラフィックとブランチトラフィックの両方が NSG によってフィルター処理され、ファイアウォールによって検査されます。

前提条件

NSG と ASG を実装する前に、次の機能があることを確認してください。

サブネットを含む仮想ネットワーク: NSG は、仮想ネットワーク内のサブネットまたは NIC にアタッチされます。計画ガイダンスについては、仮想ネットワークとサブネットに関するページを参照してください。
IP アドレス指定プラン: NSG ルールは、IP アドレスと範囲を参照します。 IP プランを使用すると、正確な規則を作成できます。ガイダンスについては、IP アドレスの計画を参照してください。
必要なトラフィックフローの一覧: ルールを記述する前に、通信する必要があるリソース、ポート、および方向を文書化します。

セキュリティに関する考慮事項

Important

デフォルトで拒否するのが正しい方針です。 Azureの既定の受信規則では、明示的に許可されていないすべてのインターネットトラフィックが拒否されます。広範な許可ルールを作成して、この姿勢を弱めないでください。

管理ポートで 0.0.0.0/0 を許可しない

Caution

SSH (ポート 22) や RDP (ポート 3389) などの管理ポートで、 0.0.0.0/0 (インターネット上の任意のソース) からの受信トラフィックを許可する NSG 規則を作成しないでください。攻撃者は、インターネットを継続的にスキャンして、開いている管理者ポートを探します。代わりに、仮想マシンに安全にアクセスするには、Azure Bastion、VPN、またはAzure Private Linkを使用します。

NSG とAzure Firewallを組み合わせる

NSG は、レイヤー 3 とレイヤー 4 (ネットワークとトランスポート) で動作します。 IP アドレス、ポート、プロトコルに基づいてフィルター処理しますが、パケットの内容は検査しません。アプリケーション層のフィルター処理、脅威インテリジェンス、または TLS 検査を必要とするワークロードの場合は、NSG と共にAzure Firewallをデプロイします。 Azure Firewallとネットワークのセグメント化に関する説明を参照してください。

トラフィックの可視性に VNet フローログを使用する

Note

NSG フローログは、2027 年 9 月 30 日に廃止される予定です。 2025 年 6 月 30 日以降、新しい NSG フローログは作成できません。仮想ネットワークレベルで同じ機能とトラフィック分析を提供する VNet フローログに移行します。

VNet フローログは、仮想ネットワーク内のすべてのワークロードのフローごとの状態とスループットデータをキャプチャします。次の場合に使用します。

セキュリティ調査: 予期しないトラフィックパターンを特定します。
コンプライアンス監査: トラフィックフローが文書化されたポリシーと一致することを証明します。
容量計画: サブネット間の帯域幅の消費量について理解します。

監視と診断の構成については、「ネットワークの監視と診断」を参照してください。

回避するべき一般的なミス

ミス	問題である理由	より優れたアプローチ
すべてを許可する受信ルールの作成（優先度 100、ソース ``、宛先 ``）	既定の拒否体制をバイパスし、すべてのリソースをインターネットトラフィックに公開します。	特定の送信元/宛先/ポートの組み合わせのみを許可します。許可ルールに使用できる最も優先度の高い番号を使用します。
既定の拒否が存在することを忘れる	Teams は既知のトラフィックのルールを作成しますが、他のすべてがブロックされていることをテストしません。意図しない開いているポートが気付かれない可能性があります。	NSG をデプロイした後、トラフィックフローのみを想定した VNet フローログまたは NSG 診断を使用して確認します。拒否されたパスを明示的にテストします。
動的ワークロードに ASG を使用しない	IP ベースの規則は、VM がスケールアウトまたは新しい IP を取得すると中断されます。チームはルールを絶えず更新します。	ASG を使用してロール別に VM をグループ化します。 ASG を参照する規則は、VM がグループに追加またはグループから削除されるため、有効なままです。
セキュリティインシデントまでフローログを無視する	フローログが有効になっていない場合、調査またはコンプライアンス監査のための履歴トラフィックデータはありません。	1 日目から VNet フローログを有効にします。異常に関する視覚化とアラートを行う Traffic Analytics を構成します。
ドキュメントなしでサブネットと NIC NSG の両方を適用する	デュアル NSG を使用すると、トラフィックが予期せず拒否される、混乱を招く相互作用が発生します。トラブルシューティングには時間がかかります。	サブネットレベルまたは NIC レベルの NSG を標準として選択します。両方が必要な場合は、各サブネットの意図された相互作用を文書化します。

仮想ネットワークとサブネット: NSG を適用する場所
Azure Firewallとネットワークのセグメント化: NSG を補完するレイヤー 7 検査
ネットワークの監視と診断: VNet フローログと NSG 診断
Azure Virtual Network Managerと一元管理: セキュリティ管理者ルールと一元化された NSG 管理

詳細情報

次のステップ

Tip

あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。

リフトアンドシフト体験の次の手順:

ハブアンドスポークトポロジを設計する: 移行されたワークロード全体で DNS、ファイアウォール、VPN Gatewayなどの共有サービスを一元化します。

次に、最新化の取り組みを行います。

ハブアンドスポークトポロジを設計する: PaaS ワークロード用の IT 所有ハブとアプリチーム所有のスポークを使用してデュアルハブトポロジを設定します。

マルチクラウドへの移行における次のステップ:

暗号化されたトンネルを他のクラウドに設定する: アマゾンウェブサービス (AWS) Virtual Private Gateway と Google Cloud VPN へのVPN Gateway接続をクラウド間転送用に構成します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-01