LoginSignup
2
0

More than 5 years have passed since last update.

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

Posted at

はじめに

前回に引き続き、閉域構成の検証をしてみました。
今回は、タイトル通り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 の接続のリダイレクトについて

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0