この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに

9月にAzure Private Linkのプレビュー版が公開されました。
これまでインターネット経由だったPaaSへのアクセスがプライベートIP経由で行えるようになる、という機能です。
非常に便利と感じPrivate Linkを調査しておりましたが、その中で気になったことの一つとしてPaaS(SQL Server)に対しプライベートIPアドレスでアクセスするという点がありました。
これまでApp ServiceからSQL Serverへのアクセスにおいて、SQL Serverのファイアウォール設定に悩まされていました(詳細は後述)。
Vnet統合したApp ServiceであればAzure Private Linkで接続されたSQL Serverに、プライベートIPアドレスでアクセスできる(=接続元がパブリックIPではなくなる)のでは？と思い検証を実施することにしました。

※本記事ではApp ServiceがプライベートIPアドレスでSQL Serverにアクセスできないか検証した結果を記載しております。Azure Private Link(以下Private Link)そのものの説明と構成手順については最小限にとどめております。
※結果を先に記載すると、App ServiceのプライベートIPでSQL Serverにアクセスすることができました。ただし少し特殊な環境のため素直にApp Service Environmentを利用するほうが金額は張りますがシンプルです。

目次

１．問題の状況説明
２．問題解決のための仮説
３．検証内容
４．まとめ

１．問題の状況説明

App Serviceは送信元IPアドレスにパブリックIPアドレスを利用します。
そのIPアドレスは以下の通り5つ存在しています。

確認場所：App Service > 設定 > プロパティ > 送信IPアドレス

App ServiceからSQL Databaseにアクセスする際に、アクセス元を制限したい場合にはSQL Serverの「ファイアウォールと仮想ネットワーク」にて設定を行うことが可能です。
ただしファイアウォール規則は最大で128個(※1)までとなります。
App Service一つで5つのパブリックIPアドレスを許可する必要があるため、仮に複数のApp Serviceが存在しておりさらにスケールアウトして台数を増やした場合には登録しきれない事態が生じます。またパブリックIPアドレスは変わる可能性があります。
もしくは「Azureサービスおよびリソースにこのサーバーへのアクセスを許可する」をオンにすることでファイアウォール規則を登録せずともAzureのリソースからのアクセスを許可することは可能です。ただし他のお客様のサブスクリプションからの接続も含むため、Azureを利用する第三者のApp Serviceからアクセスされる可能性があります(※2)。


確認場所：SQL Server > セキュリティ > ファイアウォールと仮想ネットワーク

２．問題解決のための仮説

App ServiceにはVnet統合という機能があります。この機能を利用することでApp ServiceはVnet内のリソースにアクセスすることが可能になります。
本記事ではVnet統合の詳細説明と手順については省略します(※３)。
重要な点のみを記載します。
検証にて実施したVnet統合は仮想ネットワークゲートウェイおよびポイント対サイトの構成な方法となります(仮想ネットワークゲートウェイが不要なVnet統合については現在プレビュー中)。
App Serviceに割り当てられたプライベートIPアドレスは「ポイント対サイトの構成」にて確認可能です。
確認場所：仮想ネットワークゲートウェイ > 設定 > ポイント対サイトの構成 > 割り当て済みIPアドレス

VnetとSQL ServerをPrivate Linkで接続すると、SQL ServerにはプライベートIPアドレスでアクセスが可能になります。
これらを組み合わせることでプライベートIPアドレスのApp ServiceからプライベートIPアドレスのSQL Serverへアクセスができないかと考えました。

３．検証内容

次の流れで検証を実施しました。簡単な部分の説明は省略いたします。

①SQL Serverを作成　※省略
②仮想ネットワークを作成　※省略
③Private Linkを構成
④Web Appを作成　※省略
⑤仮想ネットワークゲートウェイを作成、ポイント対サイトを構成　※省略
⑥Vnet統合を実施　※省略
⑦疎通確認

簡素ですが検証環境の構成図です。


③Private Linkを構成
次の流れで構成しました。
・サブスクリプションリソースグループ、名前、リージョンを決定
・プライベートリンクリソースを選択
　現在選択できるリソースは限られています(※４)。
・Vnetおよびサブネットを選択、プライベートDNS統合するか決定
　今回は「privatelink.database.windows.net」というプライベートDNSゾーンが作成されます。


デプロイが完了すると以下2つのリソースが作成されていました。
・Private Link用のNIC
・プライベートDNSゾーン



ところどころplivateとなってしまっています・・・。

またSQL Serverでも「プライベートエンドポイント接続(プレビュー)」が作成されています。


⑦疎通確認
SQL Serverへの疎通確認結果について記載します。
前提としてSQL Serverのファイアウォールは次の通りの設定です。
・「Azureサービスおよびリソースにこのサーバーへのアクセスを許可する」がオフ
・許可するのはVnetのアドレス空間のみ

①インターネットからSQL Serverにアクセス
133.20.3.xxx.xxxからのアクセスは許可していないため接続はできませんでした。


②Azure上のサービスからSQL Serverにアクセス
App ServiceのパブリックIPからのアクセスです。同様に40.121.212.165からのアクセスは許可していないため接続はできませんでした。


③Vnet上のVMからのアクセス
VnetのプライベートIPは許可しているため接続ができました。
10.4.0.4はPrivate LinkによりSQL Serverに割り当てられたプライベートIPアドレスです。


④App Serviceからのアクセス
10.4.0.4に対して接続をこころ見ています。分かりにくいですが、エラーは発生しておらずアクセスできています。併せてSQL Databaseのメトリック Successful Connections も同時刻にアクセス件数だけ成功していることを確認しました。

４．まとめ

これまでPaaSはインターネットアクセスが必須という点で、社内向けの外部からは閉じたシステムの選定から漏れることが多いと感じていました。
そういった問題をクリアしつつPaaSのメリットを取り入れられるメリットがあると感じます。
今回若干ニッチな検証となりましたが引き続きPrivate Linkには期待してウォッチしていこうと思います。

参考情報

※１，２
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-firewall-configure
※３
https://blogs.msdn.microsoft.com/jpcie/?p=455
※４
https://docs.microsoft.com/ja-jp/azure/private-link/private-endpoint-overview#private-link-resource