自由気ままに書いちゃおう

好きなことをつらつらと・・・

Azureのパブリックセグメントとプライベートセグメントについて

今回はAzureのパブリックセグメントとプライベートセグメントについて記載します。
まず用語の定義についてですが、
・パブリックセグメントはインターネットへ直接アクセスできる
・プライベートセグメントはインターネットへ直接アクセスできない
とします。

この考え方はAWSのものです。
AWSではサブネットに関連づいているルートテーブルのデフォルトゲートウェイにigwが設定してあるかどうかで、パブリック/プライベートを区別しています。

■AWSのパブリックセグメント

下記にようにigwがデフォルトゲートウェイに設定されているサブネットは、
パブリックセグメントと呼ばれます。

f:id:guri2o1667:20200229111449p:plain


■AWSのプライベートセグメント

下記のようにigwがデフォルトゲートウェイに設定されていないサブネットは、
プライベートセグメントと呼ばれます。
ターゲットがlocalとなっているエントリは、同じVPC上であれば通信可能を意味しています。

f:id:guri2o1667:20200229111628p:plain


では、本題です。
■Azureのパブリックセグメントとプライベートセグメントについて

AWSでは、ルートテーブルの設定次第(igw次第)で判別していました。
Azureでは、このような判別はできません

順を追って話していくと、
Azureのサブネットには、サブネット作成時に自動的にシステムルートと呼ばれるものが生成されます。(システムルートの内容はAzurePortalからは確認できません)
システムルートの詳細設定は下記サイトに載っています。

docs.microsoft.com


このシステムルートの中に
・0.0.0.0/0 (デフォルトゲートウェイ)はネクストホップがInternet
と定められています。この設定は修正/削除不可です。
つまり、AWSの考え方からすると
Azureで作成されるサブネットはすべてパブリックセグメント!!!
となります。

そのため、Azureの考え方を整理/理解し、パブリックセグメントとプライベートセグメントを定義しなくてはいけません。

■Azureのパブリックセグメントとプライベートセグメントの考え方について

実はそんなに難しい考え方ではなく、オンプレミス環境と同じ考え方です。
つまり、
・外部から直接アクセスされるサブネットは、パブリックセグメント
・外部から直接アクセスされないサブネットは、プライベートセグメント
となります。

■AWSのようなプライベートセグメントをAzureで作成するには?

AWSのプライベートセグメントは、そこに配置された仮想マシンから直接インターネットへの通信ができないようになっています。
AWSのプライベートセグメントに配置された仮想マシンがインターネットと通信(WindowsUpdateやyum等)するには、NATゲートウェイを使用するのが一般的です。

AWSのようなプライベートセグメントをAzureで作成するには、
結論から申し上げると、やろうと思えばできるけどAzureの非推奨仕様となります。

AzureのNSG(送信トラフィックの規則)でインターネットへの通信を拒否することでAWSのプライベートセグメントのようなことを実現することはできます。
※この場合、NSGはサブネットにつけたほうが管理しやすいかも。

Azureは「外部への通信は少なからず発生するものであり、セキュリティを考慮して外部通信を全部ブロックするのであればもっと他の措置が必須だよ」という考え方が根底にあります。これはAWSの考え方とは逆です。
意外なところにもAzureとAWSの差があったりします。

■Azureのサブネットに配置した仮想マシンからのインターネット通信に関して

NSGの送信トラフィックの規則では、規定でインターネット通信が許可されております。システムルートでもデフォルトゲートウェイをインターネット側に向けているため、正常に通信することができます。
※戻りの通信に対しては受信トラフィックの規則に追加する必要はありません。


以上です。