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

  • [アーティクル]

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

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

セキュリティ規則

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

プロパティ 説明
名前 ネットワーク セキュリティ グループ内で一意の名前。 名前の長さは最大 80 文字です。 先頭は単語文字にする必要があり、末尾は単語文字または "_" にする必要があります。 名前には、単語文字や "."、"-"、"_" を含めることができます。
優先度 100 ～ 4096 の数値。 規則は、優先順位に従って処理され、数値が小さいほど優先順位が高いために、大きい数値の前に小さい数値が処理されます。 トラフィックが規則に一致すると、処理が停止します。 この結果、優先順位低く (数値が大きい)、優先順位が高い規則と同じ属性を持つ規則は処理されません。
Azure のデフォルトのセキュリティ規則には、常に最初にカスタム 規則が処理されるように、優先順位が最も低い、最も高い数値が割り当てられます。
送信元または送信先 個別 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。 現在、ESP と AH のプロトコルは Azure portal では使用できませんが、ARM テンプレートでは使用できます。
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 拒否

"ソース" 列と "宛先" 列の VirtualNetwork、AzureLoadBalancer、および 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 を使用したアウトバウンド通信の動作は、ご利用のサブスクリプションの種類によって次のように異なります。

    • Enterprise Agreement: Standard Enterprise Agreement サブスクリプションにデプロイされている VM の場合、TCP ポート 25 でのアウトバウンド SMTP 接続はブロックされません。 ただし、その VM からの受信メールを外部ドメインが受け入れる保証はありません。 電子メールが外部ドメインによって拒否またはフィルター処理された場合は、その外部ドメインの電子メール サービス プロバイダーに連絡して問題を解決する必要があります。 これらの問題は Azure サポートの対象ではありません。

      Enterprise Dev/Test サブスクリプションの場合、ポート 25 は既定でブロックされます。 このブロックは削除できます。 このブロックの削除を要求するには、Azure portal で Azure Virtual Network リソースの [診断と解決] 設定ページの [メールを送信できません (SMTP ポート 25)] セクションに移動して、診断を実行します。 これで、資格のある Enterprise Dev/Test サブスクリプションが自動的に除外されます。

      そのサブスクリプションがこのブロックから除外され、VM が停止および再起動されると、それ以降はそのサブスクリプション内のすべての VM が除外されます。 この除外は、要求されたサブスクリプションにのみ、かつインターネットに直接ルーティングされる VM トラフィックにのみ適用されます。

    • 従量課金制:アウトバウンド ポート 25 の通信が、送信元となるすべてのリソースについてブロックされます。 制限解除を申請することはできません。申請は許可されません。 仮想マシンからメールを送信する必要がある場合は、SMTP リレー サービスを使用する必要があります。

    • MSDN、Azure Pass、Azure イン オープン プラン、Education、無料試用版: 送信ポート 25 の通信が、送信元となるすべてのリソースについてブロックされます。 制限解除を申請することはできません。申請は許可されません。 仮想マシンからメールを送信する必要がある場合は、SMTP リレー サービスを使用する必要があります。

    • クラウド サービス プロバイダー: アウトバウンド ポート 25 の通信が、送信元となるすべてのリソースについてブロックされます。 制限解除を申請することはできません。申請は許可されません。 仮想マシンからメールを送信する必要がある場合は、SMTP リレー サービスを使用する必要があります。

次のステップ