LinuxユーザーがイジるはじめてのAzure

LinuxユーザーがAzureを使いこなせるように応援するブログです

Azure 仮想ネットワークのハブアンドスポークについて

Azure の案件対応をしていると、時々vNETの構成について相談を受けることがあります。相談内容としては、ネットワーク設計といったハイレベルでの検討状態の時に生まれるネットワークセグメントの分け方やオンプレとの繋ぎ込み、ルーティング優先度、各PaaSサービスとの接続方式などなど多岐に及びますが、仮想ネットワークのハブアンドスポーク構成に疑問を持たれる方も少なくありません。

 

そもそもvNETをHub&Spokeで分けることにどんな意味があるのか、ご利用されていないお客様ほどピンとこないケースも多いようです。

 

この記事ではそんなvNETのHub&Spokeについて記載します。よくある構成はこんな感じでしょう。

 

f:id:akazure:20211206130946p:plain

 

まず大前提の話からすると、1vNETで詰め込んだ構成をするのも、2vNETでHub&Spoke構成にするのも、どちらでも技術的には可能です。つまり192.168.0.0/16と大きな1vNETを取ってリソースをデプロイしていくのも、192.168.0.0/20と192.168.16.0/20と2つのvNETに分けるのもどちらも構成可能です。

 

次にAzureではどちらが推奨かと問われるとHub&Spokeで分けた構成を推奨しています。1vNETで詰め込んだ構成は非推奨というわけではないですが、どちらが推奨構成かと問われれば２つに分けて管理される方を推奨としています。

 

では大きく３つの観点から見ていきましょう。

 

●コンプライアンスから見た観点

ISO27001、つまりISMSの観点ではネットワーク分離という章があります。経産省が出している情報セキュリティ管理基準にも同様の内容が記載されています。そこでは、サービスを利用する側とサービスを提供する側のネットワークを分けることが望ましい、とか、役割や権限を整理しアクセス可能な利用者を限定することが望ましいといった事項が記載されています。つまりvNETだろうがSubnetだろうが、ちゃんと利用する人と管理する人を分けてリソースをデプロイし、それぞれRBACや場合によってはPolicyなどで権限分掌および制限を付けて管理しましょう、となります。この記事を読んでいる方はオンプレのシステムを利用している方も多いと思うので、イメージでいうとこうです。オンプレで自分が利用しているサーバーが外部インターネットへアクセス可能だとしたら、そのインターネット向けまでに経由するプロキシサーバーや、その上位コアルータやスイッチなどの設置や管理もご自分でされていますか？おそらく、あーそこはネットワーク管理者がやってるよ、自分は操作どころかログインすらできないよ、といった当たり前じゃん！的な返答があると思います。その通りです、その通りの構成をAzureというプラットフォームでもお作法守って構成しましょう、というのがネットワークをちゃんと分けましょう、という分離の話です。ですがコンプライアンスから見てもvNETで分けなさい、Subnetでは分けないでください、といったセグメントレベルで明文化されたものはありません。つまりコンプライアンスの観点では1vNETであっても複数Subnetで権限分掌を行いアクセス経路や利用者が限定された管理ができていれば問題はない、とも見えます。コンプライアンスの観点ではどちらであるべきといったことは記載されていないことがわかります。

 

●Azureにおける制約や制限の観点

じゃあ1vNETでSubnetレベルで分けるやり方でもいいじゃん、という話になりそうですがAzureには各リソースにおいて制限がたくさんあります。例えば以下を例にしましょう。

 

ExpressRoute 用の仮想ネットワーク ゲートウェイについて - Azure | Microsoft Docs

「各仮想ネットワークに配置できる仮想ネットワーク ゲートウェイは、ゲートウェイの種類ごとに 1 つに限られています。」

 

つまり1vNETで管理していると、ExpressRoute GatewayもVPN Gatewayも、それぞれ１つずつ作ってしまうと、２個目は同じvNETには立てられないという制限になります。なのでこの場合はゲートウェイが設置された別vNETをもう１つ用意し、既存のvNETとピアリングするか、新設したvNETにワークロードのシステムをデプロイし、さらに1vNET詰め込み用途を用意するか、といった話になります。既に感じられつつあるように情報システム部門が統制しようとする管理対象とは別に再度野良システムを管理するための管理ネットワークが無数に広がっていく図式に陥ります。一方でHub&Spokeの場合はというと、新たにvNETを用意しないといけない要件は変わりませんが、Hub-vNETだけが基本的に増えるだけになります。

 

既設のSpoke-vNETへのアクセスは新規で建てたHub-vNETへピアリングを張るだけでよいです。また、新規でSpoke-vNETを立てて親設のHub-vNETとピアリングを張り、Hub&Spokeをもう１セット増やすスケールもアリでしょう。そしてなによりも、既設のSpoke-vNETと新説のSpoke-vNETとの接続部分はデフォルトルートとなるHub-vNETを経由する図式を取るため、情シスのネットワーク管理者が管理するHub-vNET間経由（主にAzure Firewallで制御）でルーティングの統制ができます。（やればできちゃいますが、Spoke-vNET同士でvNET Peeringを行うとすべての通信が情シスで管理対象にならなくなるため、ここはガイドラインや標準化などで制限をかけましょう）

 

ここではゲートウェイの一例ですが、他にも１つのvNET内にデプロイできる個数が決まっているサービスや機能もあるかもしれません。「今」よりも「今後」の起きうる予測を考えるとvNET単位でスケールできるように当初から設計しておいたほうが無難であることは間違いないでしょう。

 

●有事の際のオペレーション

例えばSpoke-vNETにある特定のSubnet内のVMがウィルス感染やスパイウェアが埋め込まれてしまった、ということが判明した場合を想像しましょう。まず最初にやるべきことはなんでしょうか？

 

犯人捜し？ウィルススキャンのソフトを導入する？

違いますよね。いま以上に被害が拡大しないように問題のあるネットワーク経路を特定し、入り口を塞ぎ、かつ問題のネットワークを孤立させることが何より優先されるべきでしょう。Subnetレベルでネットワーク分離を行っていた場合を想像すると、おそらくNSGによるFW制御で許可していたルールを拒否にする、とか、NSG Flow Logsのパケットログを解析する、などがあげられると思います。既に大量に定義されているNSGルールから特定のルールのみを拒否させるといったオペレーションは間違いも起きやすく判断も見誤る可能性もあります。仮にNSGの設定を入れていたとしても同一vNET内にNAT Gatewayが入っていたりPublic IPを持つVMなどが混在していると手を下す範囲も広がり、しっかりと管理されていた場合であっても作業範囲は広がります。

 

一方Hub&Spoke構成はどうでしょうか。問題となるネットワーク経路を特定する作業は同じかもしれませんが、分離においてはシンプルです。Hub-vNETとピアリングを行っている問題となるSpoke-vNETとのピアリング設定を外せば終わります。つまりSpoke-vNETがデフォルトルートとしているHub-vNET側へのルーティングが断絶されるため、Spoke-vNET内からのすべての通信において行き場がない状態にできます。NSGや他リソースの経路調査など面倒な作業は初動で必要とせず、まずはネットワークを分離させることが最優先でできます。また、復活させるときもAzure FirewallのコレクションルールやNVAのルールセットをしっかり見直して必要最低限のログイン経路だけを開ける、など、分離されている状態だからこそしっかりと調査・検討した上でFW制御を改修させてトラブルシュートに挑める、といったメリットもここにはあります。

Spoke-vNETとのすべての通信はAzure FirewallやNVAなどHub-vNETに配置されているリソースでFW制御やルーティングが一元的に管理できている状態のため、統制されたシステムの中で限定的な作業を行うだけでやりたいことができるメリットがここにはあります。

 

今回の記事は以上となりますが、他にもvNET Hub&Spokeだからこそメリットがあることはいくつかあると思います。「いままで1vNETで詰め込んできたやり方に慣れているから」、「これまでの実績から対応範囲も想起しやすいから」、という考え方もわかりますが、分離することでこれまで見えなかったメリットや管理工数の削減、統制のシンプルさを恩恵として受けるやり方の１つとして参考になればと思います。