2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

WebアプリとDBサーバー間の通信がthe Internetを経由しないように構成する

Last updated at Posted at 2023-11-20

船井総研デジタルのよもぎたです。

サマリ

前回の記事で、Azure App Service 上のWebアプリから外部へのアクセスが固定のNAT Gatewayから出ていくように構成しました。今回は逆に、内部の、WebアプリからDBサーバーへの通信がMicrosoftネットワークで完結するように構成したいと思います。

構成の概要

App Service上のWebアプリについては、前回の記事と同様に構成します。
DBサーバーは、今回はAzure SQL Serverを使います(Managed Instanceではありません)。サービスエンドポイントを構成してWebアプリの仮想ネットワークと通信できるようにします。

そのうえで、DBサーバーへアクセスするテストアプリを作成し、その通信のDBの監査ログから通信相手のIPアドレスを確認して、それがNAT Gwのものではないことを確認したいと思います。

おことわり

App Service上のWebアプリとSQL Serverのプロビジョニング、DBのテスト用テーブルとその中身の作成については割愛させていただきます。

サービスエンドポイントを構成する

SQL Serverを選択し、左のメニューからセキュリティの配下のネットワークを選択します。次に、右のペインのパブリックアクセスタブの仮想ネットワークのセクションで「仮想ネットワークルールの追加」をクリックします。そうすると右に仮想ネットワークルールを構成するタブが表示されますので、そこでサブスクリプションを選択し、App Serviceが統合されている仮想ネットワークとサブネットを選択して「OK」をクリックします。

20231117-01.png

簡単ですが、キモとなるのはここです。

SQL ServerとDBの監査を構成する

まずはSQL Serverの監査を構成します。監査の記録は今回はストレージアカウントに保管することにします。ストレージアカウントを作成して書き込みができるように構成します。

SQL Serverの監査は、左のメニューのセキュリティの配下の「監査」から構成します。右のペインで「Azure SQL 監査を有効にする」のトグルスイッチをOnにします。続いて、監査ログの保存先としてストレージを選択して、サブスクリプションとストレージアカウントを選択します。ストレージ認証は今回はストレージアクセスキーを選択しました。

20231117-02.png

右ペインの上の保存を実行してSQL Serverの監査の構成は完了です。

つづいて、SQL DBの監査を構成します。SQL DBを選択し、左のメニューのセキュリティ配下の監査を選択します。右のペインで「Azure SQL監査を有効にする」のトグルスイッチをOnにして、監査ログの保存先のストレージアカウントを設定します。最後に右ペイン上の保存を実行します。

20231117-03.png

これで監査の準備が整いました。つづいて、テストアプリからDBにアクセスしてから監査ログを参照します。

監査ログを参照する

SQL DBを選択し、左のメニューのセキュリティ配下の監査を選択して、右ペインの上の監査ログの表示を選択します。

20231117-04.png

すると監査レコードという画面に切り替わり、イベントのサマリが表示されます。しかし、ここで表示される内容だけではアクセス元のIPアドレスまでは分かりません。そこで、「クエリエディターで実行」をクリックして、より詳細な情報を確認したいと思います。

20231117-05.png

クエリエディターを起動するには認証が必要になります。Entra IDかSQL認証が選べます。認証をパスすると、Azure Portalでよく見かける形式のクエリとその実行結果の画面構成になります。しかもご丁寧にサンプルのクエリ文まで入力された状態です。今回はこのサンプルをそのまま実行することで、SQL DBへの接続元のIPアドレスまで確認することが出来ます。

20231117-06.png

クエリを実行すると、監査ログが結果の下に表示されます。少し右にスクロールすると、client_ipの列があります。今回の目的は、Webアプリの送信元がNAT Gwではなくて、App Serviceの送信アドレスであることを確認することです。結果として、client_ip列にはApp Serviceの送信アドレスのうちのひとつが出力されていましたので、NAT Gwを通らず(外に出て行かずに)Microsoftネットワーク内で通信していることが確認できました。

ちなみに、監査したこと自体も監査ログに記録されます。そのことを実際に見せられれば、そうあるべきだよな、それが正しい姿だよな、とパッと分かるけれど、盲点でした。

なお、Webアプリの送信元アドレスは、Webアプリの左メニューの設定配下のネットワークを選択し、右ペインの送信トラフィックのセクションで確認できます。

20231117-07.png

最後に

今回も、仕様としては、理屈としてはこうなっているはず、というのを確認してみました。ドキュメントをそのとおりきちんと読んで構築しているつもりですが、やはり実際に確認してみると納得感、安心感を得られます。

最後までお読みいただきありがとうございました。

2
3
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
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?