はじめに
Azureコンテナソリューショングループ）土居です。
我々の部署ではAzureにフォーカスをあてクラウドネイティブ関連の技術を追求しお客様をサポートしていきます。
その一環としてAzureに関して日々ブログで技術紹介していきますので宜しくお願いします。
今回はApp Serviceの連載第二弾目となります。
AzureのPaaS代表格であるApp ServiceとSQL Databaseの組み合わせでよく使われるVNet統合とプライベートリンクを利用した構成を紹介していきます。
PaaSのデフォルト設定は危険
PaaSはインフラを一から管理をする必要もなくポータル画面からポチポチッと数クリックするだけでアプリケーション環境が構築できるため非常に便利ですが、利用にあたっては注意が必要です。
PaaSはインターネットアクセスを前提としているため、普通に利用すると周辺サービスとの連携の際もインターネットを利用します。オンプレでDBサーバは通常プライベートネットワークに配置され、WEBサーバまたはAPPサーバからのアクセスは全てプライベートネットワークを通って通信する事が一般的でした。そのため、従来のDBサーバへの接続通信は暗号化されていないケースも多々存在します。 このようなアプリケーションを上記のPaaS環境にリフト＆シフトした場合どうなるでしょう？ 暗号化されていないDBへの接続通信がインターネット上を流れる事になりセキュリティ上好ましくありません。
また、DBサーバへの管理アクセスもインターネット上に公開されているというのも攻撃者にとって格好の的となります。万が一、管理者アカウントとパスワード等が流出でもしてしまったら、悪徳者へデータ全てへのアクセスを許してしまうことになり大変危険です。
プライベートエンドポイント
上記のような問題を解決するため、AzureのPaaSではプライベートエンドポイント（プライベートリンク）をサポートするサービスが多く存在します。 プライベートエンドポイントではPaaSのサービスをユーザーのVNet環境に紐付けて、Azure上のプライベートネットワーク経由でサービスを利用できます。
プライベートエンドポイントを作成するためには、VNetにプライベートエンドポイント用のサブネットを作成する必要があります。
今回のケースでは、SQL Databaseのプライベートエンドポイントを作成していきます。 プライベートエンドポイントを作成してもまだインターネットからのアクセスは有効なままになっているので、必ずインターネットからデータベースにアクセスできないようにアクセス制御設定も行うようにしましょう。
VNet統合
VNet統合は、App ServiceをユーザーのVNet環境に紐付けてAzureプライベートネットワーク上のサービスと連携する場合に利用します。
（VMにセカンダリNICを割り当てるイメージです。そのため、Webアクセスは通常通りパブリックからアクセス可能です。）
VNet統合の作成にも、専用のサブネットが必要になります。先程プライベートエンドポイントを作成したVNet上に新しくサブネットを払出して接続します。
これで、以下の図のようにApp ServiceとSQL Databaseのそれぞれが同じVNet上に接続され、プライベートネットワークを経由したデータ通信経路が確保されました。
DNSによる名前解決
App ServiceからSQL Databaseへの接続にはFQDNを利用します。 そのため、VNet統合とプライベートエンドポイントを使ってセキュアなアクセス経路が確保できてもアプリ側でDB接続先の名前を変えないとパブリック経由アクセスのままになります。 プライベートエンドポイントを作成するとVNet内のプライベートDNSに対してレコードが作成されるので、App Serviceの設定からDB接続情報を変更します。
実際の設定手順
MicrosoftドキュメントのチュートリアルにあるApp Service（ASP.NET）とSQL Databaseのサンプルを利用します。
チュートリアルに従ってApp ServiceとSQL Databaseを作成しアプリケーションをデプロイするところまで行います。
※App ServiceでVNetが利用できるのはStandard以上になるため、App ServiceプランはS1を選択します。
デプロイ完了後、公開URLにアクセスして動作を確認します。
問題なさそうですね。 デプロイ後のリソースグループはこんな感じになります。
App Serviceの【設定】-【構成】-【接続文字列】からSQL DatabaseへのアクセスFQDNを確認します。
試しにApp ServiceのKuduコンソールからnslookupを叩いてみます。
当然のようにパブリックIPが返ってきますので、インターネット経由でSQL Databaseにアクセスしていることになります。
次に、SQL Databaseの【セキュリティ】-【ファイアーウォールと仮想ネットワーク】を開くと、【パブリックネットワークアクセスの拒否】がいいえになっていることが分かります。
【Azureサービスおよびリソースにこのサーバへのアクセスを許可する】が有効になっているのでAzureリソースからアクセスは可能ですが、好ましい状態であるとは言えませんね。
次に、VNet統合とプライベートエンドポイントを関連付けるVietual Networkを作成します。 今回は事前にDBサブネットとAPPサブネットも作成しておきました。
いよいよ、SQL Databaseのプライベートエンドポイントの作成に入っていきます。
SQL Databaseの【セキュリティ】-【プライベートエンドポイント接続】を開いて新規作成します。
プライベートエンドポイントを作成する場合は、接続するリンクの種類を選択する必要があります。
今回はSQL DatabaseなのでMicrosoft.Sql/serversを選択します。
プライベートエンドポイントを作成すると、リソースグループの中身が一気に増えました。 プライベートエンドポイントリソースとネットワークインターフェイス、作成時に統合したプライベートDNSゾーンが追加されています。
プライベートDNSゾーンを覗くとSQL DatabaseのAレコードがDBサブネットのIPアドレスを割当てて作成されています。
このAレコードの詳細を選択し、FQDNをコピーしておきます。
SQL Databaseのパブリックアクセスを拒否します。これにより、アプリケーションでDBエラーが発生することが確認できます。
App ServiceでVNet接続を行います。 【設定】-【ネットワーク】-【VNet統合】を選択して、APPサブネットにApp Serviceを紐付けます。
VNet接続が完了したら、最後に上記でコピーしておいたFQDNに接続文字列の変更を行います。
サンプルアプリケーションの再起動が行われ、無事SQL Databaseに接続されました。
App ServiceのKuduコンソールからnslookupを叩いてみても、ちゃんとプライベートIPアドレスが返ってきていることが分かります。
終わりに
App ServiceとSQL Databaseの組み合わせでVNet統合とプライベートリンクを利用した通信閉域化について紹介しました。 これ以外にもApp Service Environmentを利用した閉域空間での利用方法などもありますが高価格になりやすいです。 今回の手法だとプライベートリンクとAzure DNSのわずかな費用のみで似たような閉域構成を実現できるので是非ご検討下さい。
本記事の記載にあたり、以下資料を参考にしています。 前回に引き続き日本マイクロソフト社様の動画は非常に分かりやすく解説されているため、お時間ある方は是非一度見て頂いて損はないかと思います。
Microsoft Azure PaaS 構成方法 (Web Apps & SQL Database) [構築の要点] | 日本マイクロソフト - YouTube
