NSG の 既定の規則 には気をつけたい
TL;DR
- NSG の default rules について簡単に説明しておき隊
- どんどん許可されていくので、便利ともいえるし、気づいていない穴が開いているかも
- 今さら仕様が変わることも考えづらい気はする
はじめに
Azure の Network security group (NSG) には default rules (既定のルール) というのがインバウンド・アウトバウンドのそれぞれに設定されていますが、それが全然「ゼロ トラストではない」よなぁ、という話を書いておきます。
NSG の default rules
記事を読み進めるにあたり、今から言及する default rules をこちらに書いておきます。
Inbound security rules はこちらです。
| Priority | Name | Port | Protocol | Source | Destination | Action |
|---|---|---|---|---|---|---|
| 65000 | AllowVnetInBound | Any | Any | VirtualNetwork | VirtualNetwork | Allow |
| 65001 | AllowAzureLoadBalancerInBound | Any | Any | AzureLoadBalancer | Any | Allow |
| 65002 | DenyAllInBound | Any | Any | Any | Any | Deny |
Outbound security rules はこちらです。
| Priority | Name | Port | Protocol | Source | Destination | Action |
|---|---|---|---|---|---|---|
| 65000 | AllowVnetOutBound | Any | Any | VirtualNetwork | VirtualNetwork | Allow |
| 65001 | AllowInternetOutBound | Any | Any | Any | Internet | Allow |
| 65002 | DenyAllOutBound | Any | Any | Any | Any | Deny |
Service tag の "VirtualNetwork" の具体的な中身
さて、上の表に 2 回ほど出てきている "VirtualNetwork" というのは、Azure 用語としては Service tag と呼ばれています。
で、この Service tag は、ファイアウォールのアドレス グループ オブジェクトのようなもので、CIDR の集まりです。
例として、この中に 198.51.100.0/24 と 203.0.113.0/24 と、、みたいなものが入っていると考えて間違いありません。
Service tag をユーザーが明示的に指定する例としては、"AzureBackup" があります。
その場合、NSG のアウトバウンド方向のに対して利用し、VNet の中から Azure Backup を構成するサービスに割り当てられているパブリック IP アドレスの集まり への通信を許可するためにその Service tag を指定します。
Azure Backup を構成するインフラストラクチャーが内部的にたぶん変化することがあり、それに応じて許可すべきパブリック IP アドレスが変わります。
ただ、そのタイミングも通知されるわけでもなく、予測できるわけではないため、その IP アドレスの集まりとしての Service tag が用意されている、というわけです。
じゃあ "VirtualNetwork" はその名前からすると Virtual Network (VNet) の IP アドレスだと思いがちですが、実際にはそうではありません。
実は、"VirtualNetwork" の具体的な CIDR は、VNet Peering で接続された VNet の IP アドレス、ExpressRoute で接続されてオンプレミスから BGP で経路広報されてきた IP アドレスなどがすべて含まれるような仕様です。
そういえば、、、と、VNet Peering した 2 つの VNet にある Azure VM 同士、特に何も考えずに通信ができている、ということを思い出していただければと思いますが、そういうこと です。
これは、便利とも言えますし、一方でゼロ トラスト ネットワーク、LAN の中だって全部信頼するのは昨今厳しいよね、という考え方からは対極にあります。
良いか悪いかでいえばちょっと permissive すぎないか、と思い直すところではありますが、今さらこれほど基礎的な仕様が変わる可能性は限りなく低いと思いますので、そういうものだと思って設計していくしかありません。
既定でインターネットへのアクセスが許可されている
ここに関してはすぐに仕様が変わっていくことが明らかになっていますが、一応言及しておきます。
AllowInternetOutBound というルールがありますが、これは宛先の Service tag を "Internet" としているため、インターネット全体へのアクセスが許可されています。
適当な Windows Server を立てて、特に何も気にせず Windows Update をインターネット側から取得できることは便利とも言えますが、これはこれでさすがにインターネット側を信頼しすぎでは、、、という気もします。
NSG のルールとは別に、Azure 既定の送信アクセスの動作変更のアナウンスに関する補足 (Tracking ID:3T84-PZZ) や Azure VM の送信接続 (SNAT) オプション まとめ で言及されているとおり、そもそも既定の SNAT が無くなるため、インターネットへの接続要件は少し変わります。
とはいえ、NSG の default rules がいきなり変わるということも考えづらいので、NAT Gateway などを配置した場合には既定ですべてのインターネットへと通信が可能であることに注意してください。
明示的な deny
IT の世界、特にネットワーク設計などに携わるインフラ エンジニアがよく言っている「暗黙の deny」ではないですが、「明示的な deny」がインバウンド・アウトバウンド方向に含まれています。
ただし、このルールによって拒否される通信は実はあんまり多くないかもしれません。
たとえば Public IP を直接紐づけた Azure VM を置いておけばインターネットから様々なトラフィックを受け、それらは DenyAllInBound で防がれますが、今日日そのような設計も珍しいのではないでしょうか。
DenyAllOutBound を考えても、"VirtualNetwork" でもなく "Internet" でもない宛先ってどれくらいあるんだよ、、という気もします。
AllowAzureLoadBalancerInBound は？
残っているのは AllowAzureLoadBalancerInBound ですが、これはほぼ無害というか、逆に必須の要素の 1 つなのでこれを否定するようなルールを書くことはまずありません。
Service tag として AzureLoadBalancer が設定されており、Azure Load Balancer からのトラフィックを許可するための特別なルールです。
まとめ
ということで、NSG の default rules はインバウンド・アウトバウンドそれぞれに 3 つずつ設定されていますが、その中身を見てみると、なかなかセキュリティ的に気になるポイントは多いです。
Azure の仕様なのでどうしようもなく、それより高い priority のルールで上書きしていくことがほとんどかと思いますが、一応説明しておきました、ということで。
Discussion