Posted at

Azure SQL Databaseの閉域構成を検証してみた


はじめに

前回に引き続き、閉域構成の検証をしてみました。

今回は、タイトル通りAzure SQL Databaseサービスでの検証です!

では、Let’s start!


構成

今回もよりセキュアに、接続許可のあるSQL Databaseのみに接続できる構成を検証してみました。

以下の構成図通りに、Linuxサーバにポートフォワーディングを設定し、中継接続することで、接続元サーバーは接続許可のあるSQL Databaseのみしか接続できない構成を実現しました。

ポイント

検証中にハマったのですが、Azure内部からSQL Database接続の際は、最初のコネクションがポート1433で応答し、通信確立後は接続元サーバーと直接通信を行います。

その際の通信は、ポート11000-11999動的で行われるため、そのポートに関してもNSGの送信規則で許可する必要があります。←ここ本当重要。

(Azure外部からの接続であれば通信ポート1433のまま、通信されます。)

上記のハマった部分は、@yotan 様にご教示いただきました。ありがとうございます!

※1.Linuxサーバからは任意のSQL Databaseへの接続もできますが、そこはユーザー操作権限等で、Linuxサーバを操作できる人を限定的にすれば問題ないと考えています。

※2.実際、本番で運用される場合は冗長化も検討する必要があるので、Linuxサーバの前段に内部ロードバランサを配置してLinuxサーバを2台構築するなどの対応が必要ですが!あくまで検証のため、冗長化云々は割愛します!

Azure SQL Database.png


確認

接続確認に利用したツールとしては、Azure Data Studioです。

SSMSでも接続確認して、同様に制御が可能な事を確認しています。(こちらは結果の画像はありません。)

ちなみに、Azure Data StudioとSSMSの比較は《Azure Data Studio for SQL Server》が役立ちます!

確認結果

任意のSQL Databaseへは接続できなかったが・・・・。

20190417_000001_censored (2).jpg

20190417_000000_censored.jpg

接続許可(サービスエンドポイント利用)のあるSQL Databaseへは接続できました!

20190417_000002_censored.jpg

20190417_000003_censored.jpg

まとめ

今回はSQL Databaseで構成を記載しましたが、Azure SQL Data WarehouseやAzure Database for PostgreSQLでもほぼ同一構成(ポートの変更は必要)で、セキュアな構成が実現できることを確認しました。

セキュアな環境でPaaSやSaaSの使用を諦めていたユーザー様にも、セキュアな閉域構成を維持した状態で、よりクラウドの特性を活かしたPaaSやSaaSサービスが浸透すればいいなと思います!

ご一読いただき、ありがとうございました!


参考文献

・Azure SQL Database と SQL Data Warehouse へのアクセスの制御-ファイアウォールとファイアウォール規則

・Azure SQLDBにlinux踏み台サーバ経由で接続するには

・SQL Database v12 の接続のリダイレクトについて