こんにちは。普段 Azure インフラ構築業務を主に行っている上村です。今回は、一般提供されてまだ間もない Azure Virtual Network Manager 関連の機能を実際に使用してみました。
Azure Virtual Network Manager は、 2023年3月22日に一般提供 されたリソースです。また、その機能の1つであるセキュリティ管理ルールは、 2023年11月15日に一部のリージョンで一般提供 されています。
Azure Virtual Network Manager とは、複数の VNET を互いに接続したりまとめて管理したりすることができるリソースです。端的に言えば、以下の 2 つの機能を有しています。
また、リージョンやサブスクリプション・テナントを跨いだ構成も取ることができ、大規模で複雑なネットワークの管理に主眼を置かれたソリューションという印象です。
なお、Network Manager によって作成された VNET 同士の接続は、実質的には通常の VNET ピアリングと同じもののようです。そのため通常の VNET ピアリングと共存させることも可能ですし、実際に Network Manager で接続を作成した後に VNET の設定を見てみると VNET ピアリングが追加されていることが確認できます。
以下のように VNET を 4 つ作成し、接続確認用にそれぞれ VM を立てておきます。今回は Network Manager を使って、構成図中の赤点線で示すように test-vnet-01 をハブ VNET としたハブアンドスポーク構成を作成してみます。
Azure Portal で「Network managers」を検索し「+作成」を選択します。
「基本」タブで各項目を入力します。「機能」では、「接続」と「セキュリティ管理」のどちらの機能を用いるかを選択します。ここではどちらも検証したいので、両方を選択しています。
「確認および作成」タブで「作成」を選択して作成します。
次に、接続またはセキュリティ管理の対象になる VNET を選択していきます。
Network Manager のページで「ネットワーク グループ」ブレードを開きます。
画面上の「+作成」を選択し、ネットワーク グループの名前を入力して「作成」を選択して作成します。
VNET を追加していきます。作成したネットワーク グループのページに移動し、「グループのメンバー」ブレードを開きます。
「+追加」-「手動でメンバーを追加」から VNET を追加します。
Network Manager のページで「構成」ブレードを開き、「作成」-「接続構成」を開きます。
「トポロジ」タブで、どのようなネットワーク構成にするかを設定します。
今回はハブアンドスポークを構成するので、「トポロジ」タブで「ハブおよびスポーク」を選択し、ハブにする VNET を選びます。
画面下部の「+追加」から、作成済みのネットワーク グループをスポークとして指定します。
「確認および作成」タブで「作成」を選択して作成します。
これで接続構成は作成されましたが、この状態ではまだ実際の設定には反映されていません。
Network Manager の「構成」ブレードで、対象の接続構成を選択して「デプロイ」を選択します。
「目標状態」タブで、接続構成とリージョンを選択します。接続構成を幾つも作成している場合、この目標状態タブで選択された接続構成のみが実際の設定として適用されます。
また、別リージョンの VNET が含まれている場合は、ここで対象のリージョンをすべて選択しておく必要があります。ここでは test-vnet-03 が西日本に存在するので、東日本と西日本を選択しています。
「レビューおよびデプロイ」タブで「デプロイ」を選択してデプロイします。
デプロイ後に VNET の設定を確認してみると、実際にピアリングが新しく作られていることが確認できます。これでハブ VNET とスポーク VNET のピアリングが完了しました。
別テナントの VNET を接続する場合には、上記のような接続の手順のほかにも幾つかやっておかなければならない手順があります（この手順を実施するためには、接続先のテナントにおいても「ネットワーク 共同作成者」以上のロールが割り当てられている必要があります）。
Network Manager のページで「テナント間接続」ブレードを開き、「作成」を選択します。
接続名を入力して、接続先のテナント B の ID とサブスクリプション（または管理グループ）ID を入力し、「作成」を選択します。
これで、テナント A →テナント B のテナント間接続が構成され、作成したテナント間接続の状態が Pending になります。
次は逆向きの接続を作成していきます。
テナント B に移動し、「仮想ネットワーク マネージャー」と検索して仮想ネットワーク マネージャーのページに移動し、「テナント間接続」ブレードを開きます。
「テナント間接続」ブレードで「作成」を選択します。
接続名を入力、テナント B におけるスコープを選択します。
また、「ネットワーク マネージャーの詳細」ではテナント A の情報を入力し、最後に「作成」を選択します。
これで、テナント B → テナント A の接続も構成されました。
テナント A に戻り、テナント間接続の状態が「Connected」になっていることを確認します。
これでテナント同士は接続できました。
次にテナント A の Network Manager のネットワーク グループに、テナント B 側の VNET を追加していきます。
テナント A の対象のネットワーク グループのページに移動します。
「グループのメンバー」ブレードを開き、「+追加」-「手動でメンバーを追加」を選択します。
ここで、VNET の一覧の上部の「テナント：[テナント A]」となっているフィルターボタンを選択し、ドロップダウンからテナント B を選択します。
表示される「認証」ボタンを選択すると、適切な権限を持っている場合にはテナント B の VNET が一覧表示されます。
接続する VNET を選択して「追加」を選択します。
無事ネットワーク グループに追加されました。
これで別テナントの VNET を接続する準備は整ったので、あとは「接続の作成」と同様に接続構成をデプロイします。
デプロイすると今回想定したハブアンドスポークの構成は完了なので、実際に接続を試してみます。
ハブの test-vm-01 からスポークの test-vm-02/03/04 に PsPing を打ってみます。
問題なく疎通できています。
Network Manager の接続の機能に関する動作確認は以上となります。
次に、セキュリティ管理者ルールについて動作を確認してみましょう。
セキュリティ管理者ルールが NSG と異なるのは、
アクションが「許可」「常に許可」「拒否」の 3 通り存在する
ことです。
上記 3 点についてそれぞれ動作確認していきます。
事前に test-vm-02の属するサブネットに対して NSG を設定しています。NSG 規則は既定のままですが、既定で他 VNET からの接続を許可する規則が入っていますので（AllowVnetInbound）、test-vm-01 から test-vm-02に対しては接続することが可能な状態です。
これをセキュリティ管理者ルールで上書きできることを確認します。
Network Manager のページで「構成」を開き、「作成」-「セキュリティ管理の構成」を選択します。
「ルール コレクション」タブで「+追加」を選択します。
規則コレクションの名前、対象となるネットワーク グループを入力し、セキュリティ管理者ルールの欄の「+追加」を選択します。
規則を入力します。本項冒頭で挙げたアクション以外には、基本的には NSG と同様の設定項目です。ここでは、test-vm-01 から test-vm-02 に対する通信を拒否する規則を設定しています。
規則を全て追加したら、「追加」を選択して元の画面に戻り、「確認および作成」で「作成」を選択して作成します。
Network Manager の「構成」ブレードで、セキュリティ管理者ルールが作成されていることを確認します。
作成したセキュリティ管理者ルールを選択して「デプロイ」を選択し、構成をデプロイします（接続の作成時と同様のため手順は割愛）。
これでセキュリティ管理者ルールが作成・適用されました。試しに test-vm-01 から test-vm-02 に PsPing を打ってみます。
想定通り、疎通ができなくなっていることが確認できました。
次は 2 つめのパターンを試してみます。test-vm-03 のサブネットの NSG に、test-vm-01からの通信を拒否する規則を入れておきます。
これをセキュリティ管理者ルールの「許可」で上書きできるか試してみます。想定の動作としては、NSG の拒否規則によってブロックされるはずです。
先ほど作成・デプロイ済みのセキュリティ管理者ルールのルール コレクションにルールを追加します（詳細は割愛）。
test-vm-01 から test-vm-02 に PsPing を打ってみます。
想定通り、疎通ができなくなっていることが確認できました。
最後のパターンを試してみます。test-vm-04 のサブネットの NSG に、test-vm-01からの通信を拒否する規則を入れておきます。
ここまでは前回と同じですが、今度はセキュリティ管理者ルールの「常に許可」で上書きできるか試してみます。想定の動作としては、NSG の拒否規則は評価されず、通信は許可されるはずです。
セキュリティ管理者ルールを設定する前の段階では、NSG で通信は拒否され通信は通りません。
セキュリティ管理者ルールを設定した後に疎通確認すると、今度は想定通り通信が通りました。
セキュリティ管理者ルールに関する動作確認は以上となります。
Azure Virtual Network Manager の料金は、
対象としているサブスクリプションの数によって決まります。
この記事を書いている時点でサブスクリプションあたり約 14 円/時間という価格設定なので、対象とするサブスクリプションが 1 つの場合は月額で 1 万円を少し超えるくらいの計算になります。
具体的な環境を考えてみましょう。ハブアンドスポーク構成を取り、ハブ VNET に仮想ネットワーク ゲートウェイなどを配置してオンプレミスと接続する構成を例に挙げます。ハブには Azure Firewall も配置し、オンプレミスとの通信は基本的に全てハブ VNET の Azure Firewall を経由するように設定します。このような構成はオンプレミスと Azure 環境を併用する上で比較的よくある構成ではないかと思います。
この場合、通信のセキュリティは基本的にハブに置かれた Azure Firewall にて担保されるため、セキュリティ管理者ルールを敢えて使用する必要はあまり無いでしょう。
一方で、接続の機能は、ハブアンドスポーク構成の管理簡素化の点で有用であると考えられます。方針として当該環境で作成した VNET は全てこのハブアンドスポーク構成に参加させる必要があるといった場合などには、設定漏れを無くす意味でも有用です。動的メンバーシップの機能を利用することで、新規に VNET を作成しただけで自動的にハブアンドスポークに参加させるといったことも実現できます。
一般にこのような構成を取る場合、VNET ピアリング設定でリモート VNET のゲートウェイを使用する等の設定を入れる必要がありますが、 Network Manager ではこの設定も一括で行うことができます。 接続構成を作成する際に、ハブ VNET に仮想ネットワーク ゲートウェイが存在する場合には以下のように「ゲートウェイとしてのハブ」という選択肢が使用できるようになるので、これを選択すればよいだけです。
デプロイしてみると、ハブ VNET 側とスポーク VNET 側でそれぞれ設定が入っていることが確認できます。
また、 既存のハブアンドスポーク構成を Network Manager の管理下に移行することも簡単にできる ようなので、特に規模が大きな環境では導入を検討してみてもよいのではないでしょうか。
その他、一般的なユースケースとしては以下のように考えられます。
一方で、同一サブスクリプション内で少数の VNET を接続するだけの小規模なネットワーク構成のみであれば、従来どおり VNET ピアリング設定を行った方が、コスト面でも分かり易さの面でも良いと考えられます。
いかがだったでしょうか。Azure Virtual Network Manager というリソースは、特に規模が大きく複雑な Azure 環境の管理を簡素化し、設定ミス等によるセキュリティリスクの低減といった効果も期待できるリソースです。既存環境の移行も簡単に行えますので、条件に合致する環境をお持ちの場合は導入を検討してみてもよいのではないでしょうか。
