Azure SQL Database のホスト名と IP アドレスの関係

Microsoft Japan Data Platform Tech Sales Team

丹羽 勝久

1. はじめに

Microsoft Azure SQL Database は、SQL Server をベースにしたリレーショナルデータベースの PaaS サービスで、世界中の多くのユーザがこのサービスを利用しています。この SQL Database のインスタンスを作成すると、Azure の外部から作成した特定の SQL Database インスタンスに接続することが可能になります。ところで、世界中のユーザが個別の SQL Database のインスタンスを作成することで、Azure で確保している IP アドレスの枯渇など発生しないのでしょうか?そもそも Azure の SQL Database インスタンスごとにパブリックな IP アドレスを割り当てるのでしょうか?本稿では、そのような疑問を解決するために、「Azure SQL Database のホスト名と IP アドレスの関係」について解説したいと思います。

SQL Database のインスタンスを作成すると以下の2つのリソースが作成されます。

  1. データベース
  2. サーバー(SQL Database が稼働する)

SQL Database は上記2つのリソースの組合せで定義され、1つのサーバー上に複数のデータベースを構築することが可能です。SQL Database の詳細な作成手順については以下をご参照ください。

SQL Database チュートリアル: Azure Portal を使用して数分で SQL データベースを作成する

こちらの記事の 新しい Azure SQL Server レベル ファイアウォールを作成する」 に記載されている手順を実施することで、お使いのクライアント PC(SQL Server Management Studio や SQLCMD など)から作成した SQL Database インスタンスに接続できるようになります。

 

注意

社内でお使いのクライアント PC の「社内 IP アドレス」と実際に接続される Azure から見たクライアント PC の「外部 IP アドレス」は、通常は別の異なる IP アドレスになります(ファイヤーウォールやプロキシサーバーが変換)。もし社外における外部 IP アドレスが不明な場合は、ファイヤーウォールの設定画面にアクセスするとクライアントの外部 IP アドレスが表示されます。また以下のように SQLCMD から直接接続すると表示されるエラーメッセージの赤字部分からアクセスするクライアントの外部 IP アドレスを確認することも可能です。

 

実行例)

C:\>sqlcmd -U user1 –P xxxxxxxxx -S abcdsrv1.database.windows.net -d testdb1Sqlcmd: エラー: Microsoft ODBC Driver 11 for SQL Server: Cannot open server 'abcdsrv1' requested by the login. Client with IP address 'xxx.xxx.xxx.xxx' is not allowed to access the server. To enable access, use the Windows Azure Management Portal or run sp_set_firewall_rule on the master database to create a firewall rule for this IP address or address range. It may take up to five minutes for this change to take effect.。

 

2. SQL Database の作成と接続確認

それでは、2つの SQL Database のインスタンスを作成してみましょう。仮にここでは、以下のような名前で作成してみます。

 

表1. 作成する SQL Database 情報

データベース名

サーバー名

abcdb1

abcsrv1.database.windows.net

xyzdb1

xyzsrv1.database.windows.net

 

ファイヤーウォールの設定を行った後に、接続確認を行います。

接続確認

データベース abcdb1 の確認:

 C:\>sqlcmd -U test1 -P xxxxxx -S abcsrv1.database.windows.net -d abcdb11> select name from sys.databases
2> go
name                                      
-----------------------------------------------------------------------------------------------------
master                                                                           
abcdb1                                                                             (2 行処理されました)

データベース xyzdb1 の確認:

 C:\>sqlcmd -U test1 -P xxxxxx -S xyzsrv1.database.windows.net -d xyzdb1
1> select name from sys.databases
2> go
name                                                                                                   
----------------------------------------------------------------------------------------------------
master                                                                          
xyzdb1                                                                                       (2 行処理されました)

 

3. 各サーバーの IP アドレスを確認

無事に接続出来たら、nslookup コマンド等で、SQL Database のサーバー名の IP アドレスを確認してみます。

IP アドレスの確認:

 C:\> nslookup abcsrv1.database.windows.net 名前:    japaneast1-a.control.database.windows.net
Address:  191.237.240.43
Aliases:  abcsrv1.database.windows.net C:\> nslookup xyzsrv1.database.windows.net
名前:    japaneast1-a.control.database.windows.net
Address:  191.237.240.43
Aliases:  xyzsrv1.database.windows.net

 

上記のように異なるサーバー名であっても、エイリアス(DNSのCNAME)が異なるだけで、実際には同じホスト名、IP アドレスをルックアップしています。

 

4. クライアントからの Azure SQL Database への接続イメージ

それでは、何故同じ IP アドレスであるにもかかわらず、自分のインスタンスに正しくアクセスできるのでしょうか?

それは Azure の設計上、より少ない IP アドレスで多くの SQL Database インスタンスと接続するための特殊な機構を保有しているためです。この機構により同じ IP アドレスの接続先に対して、自身の適切な SQL Database インスタンスに正しく接続することが可能になります。また接続にあたっては、SQL Server のクライアント( SQLCMD や SQL Server Management Studio など)は、SQL Database とのセッション情報として、論理サーバー名(作成した SQL Database のサーバー名)をセッション属性として引き渡します。

この機構を理解するために、簡単にデータベース接続までのイメージを図示すると以下のようになります。※詳細な説明は、英文ですが「Don’t Rely On a Static IP Address for Your SQL Database」を参照してください。

 

  1. 「アプリケーション」(クライアント)から、Azure SQL Database に接続がリクエストされる
  2. 指定されたサーバーの実 IP アドレスである Azure Cloud 内の「Azure Load Balancer」に接続する
  3. Azure Load Balancer は接続リクエストを評価し、バックにある「TDS Protocol Gateway」にセッション情報(論理サーバー名、データベース名など)を含めて引き渡す
  4. 「TDS Protocol Gateway」は、セッション情報の中からバックエンドにある SQL Database のどのホストに接続するか判断する
  5. SQL Database の認証情報等を評価して接続が確立される

 

Azure_SQL_Network

図1. Azure SQL Database のネットワークイメージ

 

上記の機構を裏付けるために、以下のように、論理サーバー名ではなく、Azure Load Balancer の IP アドレスで接続してみます。すると論理サーバー名の指定がないために、どのデータベースに接続するか TDS Protocol Gateway が判断できないため、下記のような接続エラーになります。

IP アドレスで接続する場合:

 c:\>sqlcmd -U test1 -P xxxxxx -S 191.237.240.43 -d abcdb1
Sqlcmd: エラー: Microsoft ODBC Driver 11 for SQL Server: Cannot open server "191.237.240.43" requested by the login.  The login failed.。

 

ちなみに IP アドレスでサーバー名を指定する場合、下記のようにユーザ名に対して、「 <ユーザ名> @ <論理サーバー名> 」と指定すると、IP アドレス指定でも接続は可能です。

IP アドレスで接続する場合のユーザ指定

 c:\>sqlcmd -U test1 @abcsrv1 -P Welcome1 -S 191.237.240.43 -d abcdb1
1> select name from sys.databases
2> go
name                                      
-----------------------------------------------------------------------------------------------------
master                                                                           
abcdb1                                                                             (2 行処理されました)

 

5. 「監査と脅威検出」を設定している場合

作成した Azure SQL Database で「監査と脅威検出」の設定をしている場合は、少し事情が異なります。通常の Azure SQL Database のサーバーのエンドポイント(実体はロードバランサー)にアクセス後、接続ネゴシエーション後、セキュリティ用のエンドポイントに接続先がリダイレクトされます。

以下の「監査と脅威検出」設定画面を見ると以下の赤枠の箇所にドキュメントリンクが貼ってあります。

Audit_Config

図2. 「監査と脅威検出」の設定画面

 

このリンクを見ると、セキュリティ設定がされた接続文字列に対する情報がドキュメントされています。

https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-auditing-and-dynamic-data-masking-downlevel-clients/

 

このドキュメントに、以下の記述があります。


監査を有効にすると、データベースの IP エンドポイントが変更されます。ファイアウォールを厳密に設定している場合は、この変更に従ってファイアウォールの設定を更新してください。

データベースの新しい IP エンドポイントは、データベースリージョンによって異なります。


それでは、上記で作成したサーバー「abcsrv1.database.windows.net」に対して、「監査と脅威の検出」を設定して、先ほどと同様に SQL Database に接続してみます。

まず初めに、監査を有効にした場合の新しい IP エンドポイントを確認してみます。

監査を有効にした場合の IP エンドポイント

 C:\> nslookup abcsrv1.database .secure. windows.net  名前:    datasec-je-2-a3.cloudapp.net
Address:  104.41.179.1
Aliases:  abcsrv1.database.secure.windows.net
          je-2-prod.database.secure.windows.net

 

上記ドキュメント中の東日本リージョンの「104.41.179.1」に割当たっているのが解ります。それでは、今まで通り、SQL Database に接続してみましょう。

監査を有効にした接続

 通常のサーバー名で接続) c:\>sqlcmd -U test1 -P Welcome1 -S abcsrv1.database.windows.net -d abcdb1
1> ネットワーク接続確認)  c:\>netstat -na |grep 191.237.240.43  >>> 何も表示されないため、元のサーバーのIPアドレス(Load Balancer)で接続されていない c:\>netstat -na |grep 104.41.179.1
  TCP         xxx.xxx.xxx.xxx:27280      104.41.179.1:1433      ESTABLISHED  >>> リダイレクトされて監査用のIPアドレス(abcsrv1.database.secure.windows.net)に接続されている

 

ちなみに監査を有効にする場合の接続は以下のように、指定したサーバーと同じ IP アドレスとの接続になります。

監査を有効にする前の接続

 通常のサーバー名で接続) c:\>sqlcmd -U test1 -P Welcome1 -S abcsrv1.database.windows.net -d abcdb1
1> ネットワーク接続確認) 
 c:\>netstat -na |grep 191.237.240.43
 TCP         xxx.xxx.xxx.xxx:30142      191.237.240.43:1433    ESTABLISHED  >>> Azure Load Balancer(abcsrv1.database.windows.net)に接続されている

 

このように「監査と脅威の検出」を設定している場合は、リダイレクトして別のサーバーに接続されるので、ファイヤーウォール等の設定の場合はご注意ください。

 

6.まとめ

今回は、Azure SQL Database のサーバー名と IP アドレスの関係について解説させて頂きました。この仕組みは SQL Database だけでなく、SQL Data Warehouse などにも同様の機構が実装されております。今回説明した機構は通常は特に意識しなくてもご利用頂けますが、ファイヤーウォールやプロキシの設定等で高度な設定を行う場合、今回解説した内容を把握している必要がありますので、ぜひご留意ください。

 

本稿の内容が皆様のクラウド環境構築/設定のお役に立てると幸いです。