Private Link を利用した「隔離型ネットワーク」を実際に構築してみた
はじめに
こんにちは、SHIFTの秋吉です。
オンプレミス環境（オンプレミス ネットワーク）の拡張として、Azure 上の仮想ネットワーク上にコンピューティング環境を延伸していくと、次の問題に直面することがあります。
ネットワークセグメント・IP アドレスの枯渇
侵入方向のセキュリティリスクの問題・対応
これらを回避するために、「隔離型ネットワーク」を導入することが考えられますが、この記事では、Private Link / Private Link サービス を利用した「隔離型ネットワーク」を実際に構築してみます。
上図において、左のグレーの枠は既存の業務ネットワーク(vnet-biz) を、右のグレーの枠は今回作成する「隔離ネットワーク」(vnet-service) を示します。
業務ネットワークから隔離ネットワークへは、意図したアクセスを行うことができますが、隔離ネットワークから業務ネットワークへは一切アクセスできないようにすることができます。
また、隔離ネットワーク内のプライベートIPアドレスは、業務ネットワーク側の制約は受けませんので、自由に割り当てることができます。
この記事でわかること
Azure の PaaS サービスではない自前の仮想マシンで、Private Link を構成する手順を説明します。また、その過程で、Private Link サービス の構成手順、プライベート エンドポイントの構成手順も説明します。
今回利用する Azure のサービス／リソース
Private Link
Private Link サービス
プライベート エンドポイント
内部ロード バランサー
それらを配置するために、また、動作確認を行うために、次のものも作成します。
仮想ネットワーク ×2 （業務ネットワーク、隔離ネットワーク）
仮想マシン ×3 （業務ネットワークに1台、隔離ネットワークに2台）
構築ステップバイステップ
もちろん、Azureのリソースの作成は、下記の順番にこだわることなく、任意の順番で作成して、あとで組み合わせることが可能ですが、下記の手順に沿って作成いただくと、新規作成したリソースで関連サービスの構成を滑らかに行うことができます。（設定画面を行ったり来たりしなくてすみます。）
仮想ネットワークの作成
「隔離ネットワーク」となる仮想ネットワークの作成
詳細な手順は割愛しますが、以降の説明で参照する場合は、仮想ネットワーク名は「vnet-service」とします。「subnet-servicebe」という名前のサブネットが作成されているとします。上記「隔離ネットワーク」を参照する仮想ネットワークの作成（業務ネットワーク想定）
こちらも詳細な手順は割愛しますが、以降の説明で参照する場合は、仮想ネットワーク名は「vnet-biz」とします。「subnet-biz01」という名前のサブネットが作成されているとします。
ちなみに、仮想ネットワーク vnet-service と vnet-biz は、異なる Azure リージョンに置いても問題ありません。サブスクリプションも別でも構いません。
内部ロード バランサーの作成
仮想マシンの負荷分散を行う内部ロード バランサーを作成します。
ロード バランサーの作成中に、以下の構成を行います。
フロントエンド IP アドレス
バックエンド プール
インバウンドの負荷分散規則
インスタンスの詳細
フロントエンド IP の構成
ロードバランサー 作成中の フロントエンド IP 構成 タブで、 ＋ フロントエンド IP 構成の追加 を押してフロントエンド IP を構成します。
Availability Zones があるリージョンでは、可用性ゾーン に、ゾーンなし、特定のゾーン、または ゾーン冗長 を選択できます。 （Availability Zones がないリージョンでは、このフィールドは表示されないようです。）
バックエンド プール の追加
バックエンド プール タブでバックエンド プール を追加します。
バックエンド プールの構成 は NIC または IP アドレス のいずれかで、適切な名前を付けて 保存 します。
インバウンドの負荷分散規則の追加
インバウンド規則 タブで負荷分散規則の追加 を押します。
負荷分散規則 に次の設定を行います。
上記にない設定は既定のままで、確認および作成 -> 作成 で、ロードバランサーを作成します。
Private Link サービスを作成する
Private Link サービス (お客様のサービス) を次の設定で作成します。
(以下に明示していないものは既定のままとします。)
プライベート エンドポイントの作成
プライベート エンドポイント を作成します。
(以下に明示していないものは既定のままとします。)
動作確認
以上で、基本的な「仕組み」の構築は完了です。
これからは、作成した「仕組み」が期待通りの動作をしていることを確認します。
具体的には、
業務ネットワークにおいて、インバウンド通信は（パブリック インターネットか否かを問わず）すべて拒否した状態で、隔離ネットワークの Web アプリのアクセス、仮想マシンへの RDP 接続ができる
ことを確認します。
確認用仮想マシンの配置
動作確認用に次の3台の仮想マシンを作成します。
仮想マシンをロードバランサーの背後に置く構成設定は、仮想マシン新規作成時に、次の画面のところから設定するとやりやすいです。
（これまでの手順により、先にロードバランサーを作っておきます。）
上画面の 負荷分散のオプション で、 Azure Load Balancer を選び、ロード バランサーを選択します で、これまでの手順で作成したロード バランサーを選びます。
さらに、バックエンド プールの選択 が表示されますので、これも作成済のバックエンド プールを選択します。
ロード バランサー への インバウンド NAT 規則 の追加
仮想マシンを配置したら、vm-service01、vm-service02 の意図した方に RDP 接続をするために、ロード バランサーのインバウンド NAT 規則 を追加します。 ここでは、ポート 3391 指定で vm-service01 に、ポート 3392 指定で vm-service02 に RDP接続するように設定します。
Azure ポータルで ロード バランサー を開き インバウンド NAT 規則 を選択します。
次のキャプチャ画像を参考に、2台の仮想マシンへの RDP 接続を設定します。
サービスタグで、RDP を選択すると、バックエンド ポートだけでなく、フロントエンド ポートも 3389 にリセットされます。
サービス タグでカスタムを選ぶか、RDPを選択する場合、フロントエンド ポートを手動設定することを忘れないようにします。
NSG (Network Security Group) の設定
隔離ネットワークに配置する仮想マシン (vm-service01, vm-service02) は、次画面のように、インターネットからの受信は全拒否（既定）、送信ルールは、プライベートを含め全拒否を追加します。
インターネットへの送信の全拒否は、仮想マシンのメンテナンスができませんので恒常的には NG ですが、検証の間だけ一時的に送信全拒否を追加します。
業務ネットワークから上記仮想マシンに接続して、設定作業や動作確認を行う仮想マシン (vm-biz01) は、次画面のように、受信ルールは インターネットからの RDP を除き、パブリック／プライベートすべて拒否にします。
送信ルールは、インターネットへの送信の全拒否を追加します。
インターネットへの送信の全拒否は、Azure サービスとの通信もできなくなるため、恒常的には NG ですが、検証の間だけ一時的にインターネット送信の拒否を追加します。
IIS の設定
前述のロードバランサーの NAT 設定を行うと、vm-biz01 から、3391指定で vm-service01 へ、3392 指定で vm-service02 に RDP 接続できるようになります。
ここの具体例では、プライベート エンド ポイントの IP アドレスを 10.1.1.4 として、vm-service01 へは "10.1.1.4:3391" で、vm-service02 へは "10.1.1.4:3392" で接続できます。
両仮想マシンに RDP 接続して IIS のセットアップを行います。
さらに、IIS のデフォルト画像 (C:\inetpub\wwwroot\iisstart.png) に手を加えて、ブラウザ表示がどちらの仮想マシンからのレスポンスかを判断できるようにしておきます。
前述の厳しい NSG ルールのもとで、意図した仮想マシンに RDP 接続が 出来ていることにも注目してください。
いよいよ動作確認
各仮想マシンの NSG のルールが、前述画面のようになっていることを確認します。
vm-biz01 でブラウザを立ち上げ、プライベート エンド ポイントのIPアドレスでアクセスしてみます。
（今回の例では、http://10.1.1.4/ ） IIS のデフォルト画像が表示されること、また、その時、前述のデフォルト画像への細工により、vm-service01、vm-service02 のいずれが起動されているかを判断します。
ブラウザの表示はそのままで、ブラウザで表示されている方の仮想マシン（この例では、vm-service01）に RDP 接続したのち、IIS サービスを停止させます。
（ロードバランサーによるフェールオーバーを確認するため。）
ブラウザの表示を更新して、仮想マシンが切り替わったことを確認します。
まとめ
Azure Private Link / Azure Private Link サービスを使用して、業務ネットワークへの侵入経路を完全にシャットアウトした状態でも、「隔離ネットワーク」へのアクセスが問題なくできることを確認しました。
参考
《この公式ブロガーの他の記事》
執筆者プロフィール：秋吉 利彰
"IT" と呼ばれる前から、この業界に身を置き早やうん十年。
PC 上で動作するニッチなプログラミングから クラウド (Azure) でのアーキテクチャまで、これまでの経験で得られた、Tipsや "てみた" 的な記事を書いていこうと思います。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/
PHOTO： UnsplashのSHAMBHAVI SINGH