- ナレッジセンター
- 匠コラム
Azureレシピ ②セキュリティの検証
- 匠コラム
- クラウド
- セキュリティ
ビジネス開発本部 第３応用技術部
第２チーム
渥美 淳一
きっかけ
前回の Azure レシピ では、セキュリティソリューションを Azure 上に移行・集約するイメージを紹介しました。
これにより Amazon WorkSpaces や Azure Windows Virtual Desktop などの仮想デスクトップのセキュリティを高めます。
ではその Azure 上に移行されたセキュリティソリューションは期待通りに動作してくれるのでしょうか？
もちろん、セキュリティソリューションの実力を疑っているわけではありません。
期待通りか否かは、例えばファイアウォールのポリシー設定やネットワーク構成によって異なるからです。
クラウドに移行した場合もオンプレミスのときと同じように、期待通りに、設定した通りに動作することを確認したい場合があります。
それを確認する手段として、世の中には多くの検証ツール（テスター）が存在します。
オンプレミスで使っているテスターの中には、Azure 上で使えないものがあります。
仮想アプライアンス版やソフトウェア版が提供されていないもの、提供されていても Azure 上での使用がサポートされないものです。
Apache Bench や JMeter などのソフトウェアを Azure 仮想マシンにインストールして使う方法もあります。
しかし、検証の品質を維持するためには、オンプレミスで使い慣れたテスターを同じように使えるほうが望ましいです。
そこで弊社では、キーサイト・テクノロジー社の「Ixia BreakingPoint」というテスターを採用しました。
柔軟かつ高度なテストパケットを Azure 仮想ネットワーク内に限定して送受信できる点、オンプレミスでも Azure でも AWS でも使える点が採用理由です。
加えて、Azure DDoS Protection による DDoS 検出シミュレーションに BreakingPoint が採用されたこと も理由のひとつです。
安全に、効果的に、効率良く、セキュリティソリューションの検証、脆弱性診断などを実行できます。
検証前の確認
オンプレミスと同じ感覚で検証してはならないことを理解する必要がありました。
他の Microsoft のお客様に害を及ぼすことなくテストできるよう、まずは以下のルールを正しく認識し、遵守することが必要です。
例えば、Azure に対するあらゆる種類のサービス拒否（DoS）テストを実行するなどのアクティビティが禁止されています。
やってみた
Ixia BreakingPoint によるテスト対象として、今回も Palo Alto Networks 社の次世代ファイアウォールを使いました。
（以下、vPalo と称する）
環境構築
Ixia BreakingPoint には「コントローラー」と「バーチャルブレード」があります。
利用者は Web ブラウザーからコントローラーの IP アドレスにアクセスしますと、GUI 画面が表示されます。
そこで送受信したいテストパケットを設定して実行しますと、コントローラーがバーチャルブレードに命じます。
そしてテストパケットを送受信し、その結果をコントローラーに報告します。
Azure に対してこれらをデプロイしてみました。
Ixia BreakingPoint は、キーサイト・テクノロジー社が提供する Azure Resource Manager テンプレートを使ってデプロイします。
1 つの Azure 仮想ネットワークに 4 つのサブネット、それにつながるコントローラーとバーチャルブレードが自動的にデプロイされました。
次に vPalo を同じ仮想ネットワーク内にデプロイしました。
テストパケットを送受信する 2 つのサブネット（送る側と受ける側）に vPalo を接続し、IP アドレスを設定します。
これにより、バーチャルブレードの送る側のポートから vPalo 経由で受ける側のポートにテストパケットを送受信できるようになりました。
今回は送る側、受ける側に 10 個ずつ IP アドレスを持たせ、10 台の仮想クライアント、10 台の仮想サーバーでテストパケットを送受信しました。
それでは実際に動かしてみます。
vPalo の Microsoft 365（Office 365）テナント制限機能が期待通りに動作するか？
Windows Virutal Desktop セキュリティ入門 で紹介した vPalo と Microsoft 365 テナント制限による情報漏洩対策を検証します。
Microsoft ドキュメント にある通り、vPalo は HTTPS 通信を復号し、テナント制限に必要な HTTP ヘッダーを挿入後、再暗号化して送る必要があります。
vPalo は以下の 3 つのドメイン（Azure AD URL）への通信のみ、HTTP ヘッダーを挿入します。
|
login.microsoftonline.com login.microsoft.com login.windows.net |
HTTPS を復号後、vPalo は 2 つの HTTP ヘッダーを挿入します。
以下はその例です。
|
Restrict-Access-To-Tenants: contoso.onmicrosoft.com Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d |
Restrict-Access-To-Tenants ヘッダーには、許可したいテナント名を入れます。複数ある場合はカンマで区切ります。
Restrict-Access-Context ヘッダーには、テナント制限を設定する（ログを取得する）テナントのディレクトリ ID の値を入れます。
ディレクトリ ID は Azure Active Directory ポータルで確認できます。
これにより、仮想デスクトップから個人テナントなど（contoso.onmicrosoft.com 以外）にアクセスできないようになります。
必要な設定を行った vPalo 経由でテストパケットを送受信してみました。
Ixia BreakingPoint は送る側、受ける側のそれぞれのポートでパケットキャプチャが可能です。
今回は受ける側のポートでパケットキャプチャを行いました。
取得したテストパケットの解析には Wireshark を使いました。
HTTPS 通信ですので、テストパケットは暗号化されています。
そこで HTTPS 通信に使用した秘密鍵ファイルを Wireshark に読み込ませました。
結果、上図の通り、HTTP パケットを確認でき、テナント制限に必要な 2 つの HTTP ヘッダーを vPalo が挿入していることを確認できました。
つまり vPalo は HTTPS の復号および再暗号化も正しく行っていることになります。
期待通り、設定した通りに動作することを確認する上で、Ixia BreakingPoint は有効なツールといえます。
補足
Ixia BreakingPoint を使えば、送受信するテストパケットの HTTP ヘッダーを柔軟にカスタマイズできました。
例えば今回、まず Host ヘッダーを「login.microsoft.com」にして検証しました。
この場合、vPalo がテナント制限のための HTTP ヘッダーを挿入することを確認できました。
次に Host ヘッダーを Azure AD URL 以外にしたところ、vPalo が HTTP ヘッダーを挿入しないことを確認できました。
はまったポイント
Azure で検証できない構成
Azure の Ixia BreakingPoint（検証当時のバージョン）は、VLAN および VR 構成をサポートしていませんでした。
今回の vPalo 検証は Layer 3 インライン構成で問題ありませんでしたが、複雑なネットワーク構成の場合は注意が必要です。
Azure ルートテーブルが必要
オンプレミスでの検証とは違って、Azure で検証する場合はルートテーブルの作成が必要です。
ルートテーブルがない場合、テストパケットは vPalo を経由しません。（左図）
10.10.2.0/24 から 10.10.3.0/24 への通信を vPalo（10.10.2.4）経由にするルートテーブルを作成します。
そして 10.10.2.0/24 のサブネットに関連付けます。
同様に 10.10.3.0/24 から 10.10.2.0/24 への通信を vPalo（10.10.3.4）経由にするルートテーブルを作成します。
そして 10.10.3.0/24 のサブネットに関連付けます。
おわりに
今回は Azure 上のセキュリティソリューション検証例をご紹介しました。
今後も Azure を中心に、お客様にとって有益なレポートを積極的に公開してまいります。
ご興味がおありでしたら是非、お気軽に弊社の担当営業までご連絡ください。
Webからのお問い合わせはこちらから
ラインナップ
ピックアップ
ナレッジセンターを検索する
カテゴリーで検索
タグで検索