ネットワーク セキュリティ グループ

Azure 仮想ネットワーク内の Azure リソースが送受信するネットワーク トラフィックは、Azure ネットワーク セキュリティ グループを使ってフィルター処理できます。 ネットワーク セキュリティ グループには、何種類かの Azure リソースとの送受信ネットワーク トラフィックを許可または拒否するセキュリティ規則が含まれています。 各規則で、送信元と送信先、ポート、およびプロトコルを指定することができます。

この記事では、ネットワーク セキュリティ グループ規則のプロパティ、適用される既定のセキュリティ規則、および変更して拡張セキュリティ規則を作成できる規則のプロパティについて説明します。

セキュリティ規則

ネットワーク セキュリティ グループには、0 個、または Azure サブスクリプションの制限内の任意の数の規則が含まれています。 各規則では次のプロパティを指定します。

プロパティ 説明
名前 ネットワーク セキュリティ グループ内で一意の名前。
優先度 100 ~ 4096 の数値。 規則は、優先順位に従って処理され、数値が小さいほど優先順位が高いために、大きい数値の前に小さい数値が処理されます。 トラフィックが規則に一致すると、処理が停止します。 この結果、優先順位低く (数値が大きい)、優先順位が高い規則と同じ属性を持つ規則は処理されません。
ソース/宛先 IP アドレス、クラスレス ドメイン間ルーティング (CIDR) ブロック (例: 10.0.0.0/24)、サービス タグ、またはアプリケーション セキュリティ グループ。 Azure リソースのアドレスを指定する場合は、そのリソースに割り当てられているプライベート IP アドレスを指定します。 受信トラフィックの場合、ネットワーク セキュリティ グループが処理されるタイミングは、Azure でパブリック IP アドレスがプライベート IP アドレスに変換された後です。送信トラフィックの場合は、Azure でプライベート IP アドレスがパブリック IP アドレスに変換される前になります。 . 範囲、サービス タグ、またはアプリケーション セキュリティ グループを指定すると、作成するセキュリティ規則の数を減らせます。 規則内で複数の個別 IP アドレスと範囲 (複数のサービス タグまたはアプリケーション グループは指定できません) を指定する機能は、拡張セキュリティ規則と呼ばれています。 拡張セキュリティ規則は、Resource Manager デプロイ モデルで作成されたネットワーク セキュリティ グループでのみ作成できます。 クラシック デプロイ モデルで作成されたネットワーク セキュリティ グループで、複数の IP アドレスおよび IP アドレス範囲を指定することはできません。
Protocol TCP、UDP、ICMP、ESP、AH、または Any。
Direction 規則が受信トラフィックまたは送信トラフィックに適用されるかどうか。
ポートの範囲 個別のポートまたはポートの範囲を指定できます。 たとえば、80 や 10000-10005 などと指定できます。 範囲を指定すると、作成するセキュリティ規則の数を減らすことができます。 拡張セキュリティ規則は、Resource Manager デプロイ モデルで作成されたネットワーク セキュリティ グループでのみ作成できます。 クラシック デプロイ モデルで作成されたネットワーク セキュリティ グループで、複数のポートまたはポート範囲を指定することはできません。
アクション 許可または拒否

トラフィックを許可または拒否するために、5 組の情報 (送信元、送信元ポート、送信先、送信先ポート、プロトコル) を使用して、優先度に従ってネットワーク セキュリティ グループ セキュリティ規則が評価されます。 同じ優先度と方向が指定された 2 つのセキュリティ規則を作成することはできません。 既存の接続に対するフロー レコードが作成されます。 そのフロー レコードの接続の状態に基づいて、通信が許可または拒否されます。 フロー レコードにより、ネットワーク セキュリティ グループはステートフルであることが可能になります。 たとえば、ポート 80 経由で任意のアドレスに送信セキュリティ規則を指定した場合、送信トラフィックへの応答に受信セキュリティ規則を指定する必要はありません。 通信が外部から開始された場合は、受信セキュリティ規則のみを指定する必要があります。 反対の場合も同じです。 ポートで受信トラフィックが許可されている場合、そのポートでのトラフィックに応答するために、送信セキュリティ規則を指定する必要はありません。

フローを有効にしたセキュリティ規則を削除したときに、既存の接続が中断されない場合があります。 接続が停止され、少なくとも数分間、どちらの方向のトラフィックも流れていないときに、トラフィック フローが中断されます。

ネットワーク セキュリティ グループ内に作成できるセキュリティ規則の数には、制限があります。 詳細については、Azure の制限 に関する記事をご覧ください。

既定のセキュリティ規則

作成する各ネットワーク セキュリティ グループに、Azure によって次の既定の規則が作成されます。

受信

AllowVNetInBound
Priority source ソース ポート 到着地 宛先ポート Protocol アクセス
65000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Any Allow
AllowAzureLoadBalancerInBound
Priority source ソース ポート 到着地 宛先ポート Protocol アクセス
65001 AzureLoadBalancer 0-65535 0.0.0.0/0 0-65535 Any Allow
DenyAllInbound
Priority source ソース ポート 到着地 宛先ポート Protocol アクセス
65500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Any 拒否

送信

AllowVnetOutBound
Priority source ソース ポート 到着地 宛先ポート Protocol アクセス
65000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Any Allow
AllowInternetOutBound
Priority source ソース ポート 到着地 宛先ポート Protocol アクセス
65001 0.0.0.0/0 0-65535 インターネット 0-65535 Any Allow
DenyAllOutBound
Priority source ソース ポート 到着地 宛先ポート Protocol アクセス
65500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Any 拒否

"ソース" 列と "宛先" 列の VirtualNetworkAzureLoadBalancer、および Internet は、IP アドレスではなく サービス タグです。 "プロトコル" 列で "Any" は TCP、UDP、ICMP を含みます。 規則を作成するときに、TCP、UDP、ICMP、または Any を指定できます。 "ソース" 列と "宛先" 列の 0.0.0.0/0 は、すべてのアドレスを表します。 Azure portal、Azure CLI、または PowerShell などのクライアントでは * または any をこの式に使用できます。

既定の規則は削除できませんが、優先順位の高い規則を作成することでオーバーライドできます。

拡張セキュリティ規則

拡張セキュリティ規則を使用すると仮想ネットワークのセキュリティ定義が簡略化され、大規模で複雑なネットワーク セキュリティ ポリシーを少ない規則で定義できます。 複数のポート、複数の明示的 IP アドレスおよび範囲を組み合わせて、単一のわかりやすいセキュリティ規則を作成することができます。 拡張規則は、規則のソース、宛先、ポート フィールドで使います。 セキュリティ規則の定義の保守を簡素化するには、拡張セキュリティ規則とサービス タグ または アプリケーション セキュリティ グループ を組み合わせます。 規則に指定できるアドレス、範囲、およびポートの数には、制限があります。 詳細については、Azure の制限 に関する記事をご覧ください。

サービス タグ

サービス タグは、指定された Azure サービスからの IP アドレス プレフィックスのグループを表します。 これは、ネットワーク セキュリティ規則を頻繁に更新する煩わしさを最小限に抑えるのに役立ちます。

詳細については、Azure サービス タグに関するページをご覧ください。 ストレージ サービス タグを使用してネットワーク アクセスを制限する方法の例については、PaaS リソースへのネットワーク アクセスの制限に関する記事を参照してください。

アプリケーション セキュリティ グループ

アプリケーション セキュリティ グループを使用すると、ネットワーク セキュリティをアプリケーションの構造の自然な拡張として構成でき、仮想マシンをグループ化して、それらのグループに基づくネットワーク セキュリティ ポリシーを定義できます。 明示的な IP アドレスを手動でメンテナンスせずに、大きなセキュリティ ポリシーを再利用することができます。 詳細については、「アプリケーション セキュリティ グループ」を参照してください。

Azure プラットフォームに関する考慮事項

  • ホスト ノードの仮想 IP:DHCP、DNS、IMDS、正常性の監視などの基本的なインフラストラクチャ サービスは、仮想化されたホストの IP アドレス 168.63.129.16 および 169.254.169.254 を通じて提供されます。 これらの IP アドレスは Microsoft に属し、この目的のためにすべてのリージョンで使われる唯一の仮想化 IP アドレスです。 有効なセキュリティ ルールと有効なルートには、これらのプラットフォーム規則は含まれません。 この基本的なインフラストラクチャ通信をオーバーライドするには、ネットワーク セキュリティ グループの規則に、次のサービス タグを使用してトラフィックを拒否するセキュリティ規則を作成します: AzurePlatformDNS、AzurePlatformIMDS、AzurePlatformLKM。 ネットワーク トラフィック フィルタリングの診断およびネットワーク ルーティングの診断方法について確認してください。

  • ライセンス (キー管理サービス) :仮想マシンで実行されている Windows イメージのライセンスを取得する必要があります。 ライセンスを適用するために、そのような問い合わせを処理するキー管理サービスのホスト サーバーには要求が送信されます。 この要求は、ポート 1688 を通じて送信されます。 default route 0.0.0.0/0 構成を使用したデプロイに関しては、このプラットフォーム ルールは無効となります。

  • 負荷分散プール内の仮想マシン:適用されるソース ポートおよびアドレス範囲は、元のコンピューターからのもので、ロード バランサーではありません。 宛先ポートとアドレス範囲は、ロード バランサーのものではなく、宛先コンピューターのものになります。

  • Azure のサービス インスタンス:HDInsight、Application Service Environments、および仮想マシン スケール セットなどの Azure サービスのインスタンスが仮想ネットワークのサブネットにデプロイされています。 仮想ネットワークにデプロイできるサービスの詳細な一覧については、Azure サービスの仮想ネットワークに関するページをご覧ください。 リソースがデプロイされているサブネットにネットワーク セキュリティ グループを適用する前に、各サービスのポート要件を確認してください。 サービスに必要なポートを拒否すると、サービスは正しく機能しません。

  • アウトバウンド メールの送信:Azure Virtual Machines からのメール送信に関して、Microsoft では、Authenticated SMTP リレー サービスの利用を推奨しています (通常は、TCP ポート 587 で接続されますが、他のポートが使用されることもあります)。 SMTP リレー サービスは、送信者評価に特化することで、サード パーティのメール プロバイダーによってメッセージが拒否される可能性を最小限に抑えます。 そのような SMTP リレー サービスとしては、Exchange Online Protection や SendGrid が代表的ですが、他にもさまざまなリレー サービスが存在します。 Azure に限らず、またサブスクリプションの種類に限らず、SMTP リレー サービスは広く利用されています。

    2017 年 11 月 15 日より前に Azure サブスクリプションを作成した場合、SMTP リレー サービスが利用できるほか、TCP ポート 25 を使用して直接メールを送信することもできます。 2017 年 11 月 15 日以降に Azure サブスクリプションを作成した場合、ポート 25 を使用して直接メールを送信することはできません。 ポート 25 を使用したアウトバウンド通信の動作は、ご利用のサブスクリプションの種類によって次のように異なります。

    • マイクロソフト エンタープライズ契約:送信ポート 25 の通信が許可されます。 仮想マシンから外部のメール プロバイダーに直接アウトバウンド メールを送信できます。Azure プラットフォームによる制限はありません。
    • 従量課金制:アウトバウンド ポート 25 の通信が、送信元となるすべてのリソースについてブロックされます。 外部のメール プロバイダーに仮想マシンから直接 (認証済み SMTP リレーを介さずに) メールを送信する必要がある場合は、申請によって制限を解除することができます。 申請は Microsoft の裁量にて審査および承認されます。また、申請が許可されるのは、詐欺行為防止チェックの実施後となります。 申請を行うには、 [Technical](技術)[Virtual Network Connectivity](仮想ネットワーク接続)[Cannot send e-mail (SMTP/Port 25)](メールを送信できない (SMTP/ポート 25)) を問題の種類とするサポート ケースを開いてください。 ご利用のサブスクリプションから Authenticated SMTP リレー経由ではなく直接メール プロバイダーにメールを送信することが必要である理由をサポート ケースに詳しく記してください。 ご利用のサブスクリプションが免除された場合に、ポート 25 を使用したアウトバウンド通信が許可されるのは、その免除日以降に作成された仮想マシンだけです。
    • MSDN、Azure Pass、Azure イン オープン プラン、Education、BizSpark、および無料試用版:アウトバウンド ポート 25 の通信が、送信元となるすべてのリソースについてブロックされます。 制限解除を申請することはできません。申請は許可されません。 仮想マシンからメールを送信する必要がある場合は、SMTP リレー サービスを使用する必要があります。
    • クラウド サービス プロバイダー:クラウド サービス プロバイダーを介して Azure リソースを使用しているお客様は、クラウド サービス プロバイダーを相手方とするサポート ケースを作成できます。また、安全な SMTP リレーが利用できない場合は、お客様の代わりにプロバイダーがブロック解除のケースを作成するよう要求できます。

    Azure でポート 25 経由のメール送信が許可された場合に、メール プロバイダーが、ご利用の仮想マシンからのインバウンド メールを受け入れるかどうかについては、Microsoft では保証できません。 ご利用の仮想マシンからのメールが特定のプロバイダーによって拒否される場合は、そのプロバイダーに直接働きかけて、メッセージ配信の問題やスパム フィルターの問題を解決するか、Authenticated SMTP リレー サービスを使用します。

次のステップ