はじめに
セキュリティ対策の一つとしてネットワークセグメンテーションという考え方があります。
これはユーザがアクセス可能なセグメントを制限して、データベースなど機密データが格納されるセグメントは別セグメントに設定してユーザが直接参照できないように制限をかけます。
下記のURLにて詳細が書かれています。
https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/n-tier/n-tier-sql-server
ですが複雑すぎるので今回は下記のシンプルな構成で作成し、Web subnetからDB subnetへ通信するためにはどのような設定が必要か確認しました。
それでは早速構築していきます。
仮想ネットワークの作成
ここではどの範囲のIPアドレスを使用するかを定義します。
Web subnetとDB subnetを含めることができるように定義します。
今回の例では
Web subnet用のアドレス空間：10.1.0.0/16
DB subnet用のアドレス空間：192.168.1.0/24
予備：192.168.2.0/24
と定義しました。
サブネットは
Web subnet用のサブネット：10.1.0.0/24
DB subnet用のサブネット：192.168.1.0/24
として作成します。
仮想ネットワーク（VNET）が構築できたら次はそれぞれのサブネットにリソースを作成します。
サブネットを指定しながらリソースの作成
ここからはいつものようにVMやSQL Databaseなどのリソースを構築する際に
サブネットを指定していきます。
気を付けるポイントは仮想マシン作成時のサブネットを先ほど作成したwebやdatabaseサブネットを指定するだけです。
以下はWebサーバ用のネットワーク構成
データベースサーバ用のネットワーク構成は以下のように設定します。
サブネットにdatabaseサブネットを指定し、パブリックIPは不要なアクセスを防ぐため「なし」にします。
接続確認
今回、サブネットをweb用、database用の2つに分けましたが、web用サブネットからdatabase用サブネットにアクセス可能かを確認します。
まずはPublicIPが設定されているweb用VMにログインします。
Web用VMのネットワーク設定は以下のようになっています。
このサーバからdatabase用VMに接続します。
ホスト名は「sql」として構築しました。
「sql」のVMは192.168.1.0/24のセグメントに構築しており、オンプレ環境ではルーティングなどの設定が必要ですが、Azureだと特別な設定も必要なく、名前解決できているようです。
「web」VMにSQL Server Management Studioをインストールし、
「sql」VMに接続できることを確認しました。
特別なルーティングなど設定する必要がなく、セグメントをWebとDatabaseで分けるのは簡単でした。
0 件のコメント:
コメントを投稿