Freigeben über

Windows Azure 仮想ネットワーク内のマシンに対するネットワーク分離オプション

  • Artikel

このポストは、3 月 28 日に投稿された Network Isolation Options for Machines in Windows Azure Virtual Networks の翻訳です。

先日、Windows Azure のネットワーク セキュリティに関するホワイトペーパーを公開しました (こちらからダウンロードできます)。このホワイトペーパーでは、Windows Azure プラットフォームのネイティブな機能を活用して情報資産を最適な形で保護するための情報が提供されています。

今回、プリンシパル コンサルタントを務める Walter Myers による記事をご紹介し、先のホワイトペーパーの内容をさらに掘り下げ、仮想ネットワーク内の VM をネットワーク レベルで分離する方法について解説します。

はじめに

企業のお客様は、多様な環境を不正アクセスや有害なアクセスから保護しなければならないため、エンタープライズ環境におけるアプリケーションの分離は重要な課題です。これには、特定のバックエンド ネットワークまたはサブネットワーク内のマシンが、IP アドレスのホワイトリストに基づいて、一定のクライアントまたはコンピューターのみに特定のエンドポイントへの接続を許可するという、従来からのフロントエンドとバックエンドのシナリオが含まれます。このようなシナリオは、クライアント アプリケーションが仮想マシンのアプリケーション サーバーにアクセスする経路が、インターネットからか、Azure 環境内からか、または VPN 接続経由のオンプレミスからかにかかわらず、Windows Azure にあらかじめ組み込むことが可能です。

マシンの分離オプション

Windows Azure プラットフォームでマシンの分離を実装できる状況として、この記事では以下の 3 つの基本的なオプションを取り上げます。

1.単一の仮想ネットワークにデプロイされたマシン間

2.異なる仮想ネットワークにデプロイされたマシン間

3.異なる仮想ネットワーク (オンプレミスから両仮想ネットワークとの VPN 接続が確立済み) にデプロイされたマシン間

これらのオプションについては、この後のセクションで詳しく説明します。

既定では、ギャラリーを基に作成した Windows Server 仮想マシンには、2 つのパブリック エンドポイント (RDP およびリモート PowerShell 接続) があります。管理者によって追加されるエンドポイントを除き、他のパブリック エンドポイントはありません。これらのエンドポイントと、管理者により作成されるその他のエンドポイントは、指定された IaaS 仮想マシンでアクセス コントロール リスト (ACL) により保護されます。この記事を書いている時点で、ACL は IaaS 仮想マシンで使用できますが、PaaS Web ロールまたは Worker ロールではサポートされていません。

ネットワーク ACL のしくみ

ACL は、ルールの一覧を含むオブジェクトです。ACL を作成して、仮想マシンのエンドポイントに適用すると、仮想マシンのホスト ノードでパケット フィルター処理が実行されます。つまり、リモート IP アドレスからのトラフィックのフィルター処理が、仮想マシン上ではなく、ホスト ノードによって実行され ACL ルールと照合が行われるということです。これによって、仮想マシンが、パケット フィルター処理のために貴重な CPU サイクルを消費することを防げます。

仮想マシンが作成されると、既定の ACL が使用されてすべての受信トラフィックをブロックします。しかし、入力エンドポイントが (たとえば、ポート 3389 に対して) 作成された場合、既定の ACL が変更され、そのエンドポイントのすべての受信トラフィックが許可されます。上述のとおり、仮想マシンが Azure ギャラリーを基に作成された場合、下図のポータルのように、PowerShell エンドポイントと RDP エンドポイントが、標準のプライベート ポートを使って作成されますが、パブリック ポートはランダムに生成されます。その後、リモート サブネットからの受信トラフィックは、それらのエンドポイントに制限されるため、ファイアウォールのプロビジョニングが必要なくなります。他のすべてのポートは、そのポートに対するエンドポイントが作成されない限り、受信トラフィックをブロックします。送信トラフィックは既定で許可されます。

ネットワーク ACL を使用すると、次の操作を実行できます。

  • リモート サブネットの IPv4 アドレス範囲に基づいて、仮想マシンの入力エンドポイントに対する受信トラフィックを、選択的に許可または拒否
  • IP アドレスのブラックリストへの登録
  • 仮想マシンのエンドポイントごとに複数のルールを作成
  • 仮想マシンのエンドポイントごとに最大 50 個の ACL ルールを指定
  • ルール順序を使用して、指定された仮想マシンのエンドポイントに対して適切なルールのセットを (最下位から最上位の順に) 確実に適用
  • 特定のリモート サブネットの IPv4 アドレスに対して ACL を指定

このように、ネットワーク ACL は、仮想マシンのパブリック エンドポイントを保護し、エンドポイントに対するアクセスの種類を制御するための鍵になります。現在、インターネットから各仮想マシンへのアクセス制御を可能にする、IaaS 仮想マシンの入力エンドポイント向けネットワーク ACL を指定することが可能です。エンドポイントを指定しない限り、仮想ネットワーク内の仮想マシンは、受信トラフィックを受け取りません。これは、ネットワーク レベルで既定が ACL 拒否になっている状態と同じです (既定の設定は、仮想マシンごとに上書きが可能です)。現在、仮想ネットワークに含まれる特定のサブネットで ACL を指定することはできません。マイクロソフトでは、この点について将来的に変更することを検討しています。

オプション 1: 単一の仮想ネットワーク内のサブネット

現在、Windows Azure では単一の仮想ネットワーク内のサブネット間のルーティングを提供していますが、内部 DIP アドレスに関してはネットワーク ACL 機能を一切用意していません。このため、単一の仮想ネットワーク内のマシンへのアクセスを制限するためには、以下の図で簡単に示すように、セキュリティが強化された Windows ファイアウォールの機能を利用する必要があります。

サーバーを安全に保護するために、Windows ファイアウォールの設定により、すべての受信接続をブロックしたり、以下を決定する受信ルールをセットアップしたりできます。

1) 接続を受け入れるローカル ポート

2) 接続の受け入れ先リモート ポート

3) 受け入れられるリモート IP アドレス

4) 接続を実行できるユーザーの権限

5) 接続を実行できるコンピューターの権限

この場合、ファイアウォールの例外には、自身のサブネット内と、仮想ネットワークのために構成されたその他のサブネットのローカルな Dynamic IP (DIP) アドレスが含まれます。どんなパブリック エンドポイントも、ネットワーク ACL により保護されます。言うまでもなく、ファイアウォールの例外には、ネットワーク ACL で確立された、パブリック エンドポイントのプライベート ポートを含む必要があります。

オプション 2: 異なる仮想ネットワーク内のサブネット

他の Azure 仮想ネットワークにデプロイされたマシン、仮想ネットワークと関連付けられていない Azure クラウド サービスのマシン、または、Windows Azure プラットフォーム外のマシンといった他のマシンから、仮想マシンを保護するには、Windows Azure ネットワーク ACL 機能を利用して、仮想マシンへのアクセス制御を実現します。これは、Windows Azure でアプリケーションの分離を行うにあたって最も自然なシナリオです。既定では、仮想マシン上で許される唯一のアクセスは、既定で提供される RDP とリモート PowerShell のパブリック エンドポイントだからです。異なる仮想ネットワーク内の別の仮想マシンにアクセスする必要がある任意の Azure 仮想マシン (PaaS または IaaS) の場合、単一の仮想ネットワーク内での DIP アドレスではなく、仮想 IP (VIP) アドレスが確認されます。このため、許可 ACL が仮想マシンのエンドポイントに設定されたとき、その ACL は接続の実行を要求するマシンのパブリック VIP を確認します。これに関しては、以下の図を参照してください。

"許可" または "拒否" を指定するルールを作成することにより、仮想マシンの入力エンドポイントに対するネットワーク トラフィックを (管理ポータルで、あるいは PowerShell から) 選択的に許可または拒否することができます。既定では、エンドポイントが作成されたとき、エンドポイントに対するすべてのトラフィックが許可されます。このため、仮想マシンのエンドポイントへの着信を許可するネットワーク トラフィックをきめ細かく制御したければ、許可または拒否のルールの作成方法と、それらのルールを適切な優先順位で指定する方法を理解することが重要です。1 つ以上の "許可" 範囲を追加した場合、それ以外の全範囲を既定で "拒否" する結果になることに注意してください。最初の許可範囲から外れると、許可された IP 範囲からのパケットのみが、仮想マシンのエンドポイントと通信できます。

それでは、同一クラウド サービス内に 2 台のフロントエンドの仮想マシンと、SQL Server を実行する 1 台のバックエンドの仮想マシンを含む例を用いて、実際にこれがどのように機能するかを見てみましょう。ここでは、SQL Server を保護したいので、2 台のフロントエンド マシンのみをアクセス可能にします。下のスクリーンショットには、パブリック VIP アドレスが 168.62.207.83 で canis-testvms という名前のクラウド サービスと、そこに含まれる canis-testvm1 と canis-testvm2 いう名前の 2 台のフロントエンド仮想マシンが示されています。

次のスクリーンショットには、testvirtualnetwork という名前の仮想ネットワークの FrontEnd サブネット内に、その仮想ネットワークに参加する canis-testvm1 と canis-testvm2 という 2 台のフロントエンド マシンが示されています。

以下は、バックエンド SQL Server マシン sql12-01 を示すスクリーンショットです。このマシンは、waltervirtualnetwork という仮想ネットワークに参加し、その BackEndSubnet サブネットに属しています。

まず、この SQL Server 仮想マシンへのアクセスを構成する必要があります。以下で示したとおり、最初に行うのは、パブリック ポートとして 14333 を使用して、プライベート ポート 1433 に対してパブリック エンドポイントを確立することです。上述のとおり、既定の ACL はすべてのリモート アドレスがエンドポイントにアクセスすることを許可しますので、ネットワーク ACL を使ってこの点を修正する必要があります。

次に、画面下部の [MANAGE ACL] ボタンをクリックします。以下のような [MANAGE ENDPOINT ACL] ダイアログが表示されます。最初に追加する ACL は、既定の ACL を "Deny" アクションで上書きする ACL で、これによってすべてのリモート アドレスを締め出します。次に、フロントエンド マシンを含むクラウド サービスの VIP アドレスを指定する別の ACL をより高い優先順位で追加します。その際、/32 ネットワークを使用する CIDR 形式 (168.62.207.83/32) で入力します。これは、シンプルに、フロントエンド マシンを含むクラウド サービスの単一 IP アドレスに割り当てられます。SQL サーバーの視点から見ると、どちらのフロントエンド クライアントも 168.62.207.83 という IP アドレスを有しています。これらは、クラウド サービス内でネットワーク アドレス変換 (NAT) されたものです。

以上が、VPN 接続なしでパブリック VIP アドレスを使用する場合、あるいは VPN 接続があっても DIP アドレスを利用するために、オンプレミスのルーターを通じてルーティングしたくないという場合に、複数の仮想ネットワークでエンドポイントを保護する方法です。DIP については、VPN が追加された次のオプションで説明します。

オプション 3: 異なる仮想ネットワーク (VPN 接続あり ) 内のサブネット

VPN 接続がある場合、仮想ネットワークの既定の分離は変更できませんが、ネットワーク接続のための追加オプションが提供されます。これについての具体的な例を見ていきます。このシナリオでは、複数の仮想ネットワークに参加しているオンプレミスのサブネットが、ファイアウォールのルールにブロックされない場合、DIP アドレスを介して、いずれの仮想ネットワーク内の仮想マシンにもフル アクセスが可能です。そこで、このシナリオにおいては、オンプレミスのロケーションで終了している 2 つの仮想ネットワークを取り上げます。この 2 つの仮想ネットワークは、互いのアドレス空間にアクセスする必要があります。これは、オンプレミスのルーターを "spoke-to-spoke (スポーク間)" 構成のハブとして設定することにより実現できます。このルーターはハブであり、"スポーク" は Azure 側のサイト間接続を終了させる VPN デバイスです。

スポーク間構成を正しく機能させるために、まず Azure 側のゲートウェイで、特定の仮想ネットワークに対応するローカル ネットワークを構成する必要があります。これによって、仮想ネットワークが他の任意の仮想ネットワークのアドレス空間にアクセスすることが可能になります (当然、それらは異なるアドレス空間になければなりません)。下図の管理ポータルのローカル ネットワーク構成をご確認ください。それぞれのローカル ネットワークに対して、各仮想ネットワークがアクセスする必要のある 192.168.1.0/24 というオンプレミスのローカル ネットワーク アドレスがあり、それに加えて、各仮想ネットワークに付加された追加のアドレス空間があります。それらは、一方の仮想ネットワークがアクセスしたい "相手方の" 仮想ネットワークです。

次に、オンプレミス VPN デバイス (私のデバイスは Cisco ASA 5505 です) を構成する必要があります。基本的に、これは、一方の仮想ネットワークから他方の仮想ヘットワークへのアクセス リストを、両サイドの既存のアクセス リストに追加する作業です。たとえば、ローカル オンプレミス ネットワークに 192.168.1.0/24 アドレス空間が存在し、仮想ネットワークの一方に 10.5.0.0/16 アドレス空間が存在する場合、以下に示すように、ローカル ネットワークから仮想ネットワークへのアクセス リスト エントリ (通常は、あらかじめセットアップされています) と、10.5.0.0/16 仮想ネットワークから 10.4.0.0/16 仮想ネットワークへの別のアクセス リスト エントリが必要になります。

access-list AzureAccess extended permit ip 192.168.1.0 255.255.255.0 10.4.0.0 255.255.0.0

access-list AzureAccess extended permit ip 10.5.0.0 255.255.0.0 10.4.0.0 255.255.0.0

さらに、以下のとおり、10.4.0.0/16 仮想ネットワークから 10.5.0.0/16 仮想ネットワークへのアクセス リスト エントリを作成して、10.5.0.0/16 仮想ネットワークに対しても同じ処理をします。

access-list AzureAccess2 extended permit ip 192.168.1.0 255.255.255.0 10.5.0.0 255.255.0.0

access-list AzureAccess2 extended permit ip 10.4.0.0 255.255.0.0 10.5.0.0 255.255.0.0

次のステップでは、以下のように、これら 2 つの "外部" ネットワーク間で NAT をセットアップします。

object-group network VPN_OUT_AZ1

network-object 10.4.0.0 255.255.0.0

object-group network VPN_OUT_AZ2

network-object 10.5.0.0 255.255.0.0

nat (outside,outside) 1 source static VPN_OUT_AZ1 VPN_OUT_AZ1 destination static VPN_OUT_AZ2 VPN_OUT_AZ2 no-proxy-arp route-lookup

それぞれの仮想ネットワークは、DIP アドレスを使って VPN ゲートウェイ経由で他方の仮想ネットワークにアクセスできます (これは、既に説明した、単一の仮想ネットワーク内のサブネットのシナリオと同じ状況です)。ただし、ファイアウォール ルールがこれを妨げないことが前提です。ネットワーキング トラフィックはハブを通じて行き来し、トランザクション コストと待機時間 (レイテンシ) の増加を招くため、このシナリオは一部のユーザーにとっては望ましくないかもしれませんが、外部エンドポイントを一切外に公開したくない企業にとっては許容できるトレードオフになるでしょう。あるいは、パブリック エンドポイントを使用して 2 つ (またはそれ以上) の仮想ネットワーク間の接続を実行することを好み、IPsec とグループ ポリシー オブジェクトを使ってパブリック エンドポイントをより強固に保護する場合もあるかもしれません。

Windows ファイアウォール /IPsec を用いてエンドツーエンドのネットワーク通信を保護する

IPsec が統合された、セキュリティが強化された Windows ファイアウォールは、エンドツーエンドの認証済みネットワーク通信を簡単に実現する方法を提供します。本機能は、信頼されたネットワーク リソースへの高い拡張性を持つ階層化されたアクセスを提供し、データの整合性を維持し、必要に応じて、データの機密性を保護するために役立ちます。インターネット プロトコル セキュリティ (IPsec) は暗号に基づくセキュリティ サービスを使用して、インターネット プロトコル (IP) ネットワークの通信を保護します。

下図に示した 2 つの仮想ネットワークの例では、DIP アドレスが 10.5.1.5 で IPsec 証明書を持つ、オンプレミスのドメインに参加していないマシンがありますが、これを、セキュリティが強化された Windows ファイアウォールか PowerShell を通じて保護するように構成できます。これは、保護されたポートにアクセスしたいマシンは、IPsec 証明書も必要になることを意味します。この例では、ドメインに参加している 10.4.1.6 と 10.5.1.4 という 2 台のマシンがあり、これらは、Windows ファイアウォール、PowerShell スクリプト、またはグループ ポリシーを通じて IPsec 接続を要求するように構成することができます。すなわち、これらのマシンは、内部 DIP アドレス、またはパブリック VIP アドレス経由のいずれでアクセスされたかにかかわらず、完全に保護されるということです。パブリック VIP アドレスに対しては、ネットワーク ACL 機能を利用して、許可された外部 IP アドレスのホワイトリストを作成します。この場合、外部クライアント マシンは IPsec 証明書が必要になります。

単一の仮想マシンに手動で IPsec を適用する

仮想ネットワーク内の仮想マシンに最大限の保護を実現するために、Windows ファイアウォールを有効にして、最初にすべての受信接続をブロックするように構成することができます。その後、セキュアな接続を強化し、またこれらの接続を暗号化するために IPsec を追加することで、必要に応じてポートを開くことができます。Windows Server 2008 以降のバージョンで IPsec を手動で構成するには、Windows ファイアウォールを起動し、[Inbound Rules] ノードを選択してから新しいルールを作成します (以下参照)。

以下のように、IPsec で保護したい特定のポートを選択できます。

次に、目的のポートへの接続を保護する指定を行います。

[Customize …] ボタンをクリックした後、表示されるダイアログ (下図) で IPsec 設定を行います。これ以降、ウィザードで設定を続け、最後にルールに名前を付けます。

PowerShell を使った IPsec 構成のスクリプティングに興味がある方は、こちらのリンクから詳細情報をご覧ください。

ドメイン内でグループ ポリシーを使って、仮想マシンの IPsec ポリシーを設定する

VPN 接続経由でオンプレミス ネットワークに接続された仮想ネットワーク環境では、仮想ネットワーク内のコンピューターはオンプレミスのドメインに参加できます。オンプレミスのドメインに参加すると、IPsec ポリシーを用いたグループ ポリシーを適用して複数のコンピューターを構成し、それらのコンピューターを企業のポリシーに基づいて確実に保護することができます。IPsec ポリシーを作成しグループ ポリシーを使用する方法についての詳細は、こちらのページをご覧ください。以下で、この手順を説明します。

ここでは、ドメイン コントローラーから、Windows Azure のドメインに参加しているサーバーに特定のポリシーを適用したいので、最初に、Azure Servers と命名された独自の OU にこれらのマシンを追加します (下図参照)。この例では、canis-sql12-01 という名前の仮想マシンで設定を行います。

以下は、仮想マシン canis-sql12-01 のファイアウォールの現在の状況です。

ドメイン コントローラーに戻り、[Administrative Tools] メニューからグループ ポリシー管理コンソールを起動します。次に、canisnetworks.com のドメインを展開し、[Group Policy Objects] ノードを選択して右クリックします。[New] メニュー項目を選択します (下図参照)。

[New GPO] ダイアログで、新しい GPO にわかりやすい名前を付け、 [OK] ボタンをクリックします。

これで GPO オブジェクトのリストに追加されましたので、今度は構成のためにこの GPO を右クリックして [Edit] メニュー項目を選択します (下図参照)。

グループ ポリシー管理エディターが表示されます。

これから、以下の 2 つの GPO を追加します。

1.ドメイン プロファイルをオンにする。

2.SCOM 監視ポート 5723 が IPsec により保護されるように構成する (これによって、オンプレミスの SCOM 環境から外部 IP アドレスを使って安全に、この GPO が適用されたマシンを監視することができるようになります)。

下図のように、[Computer Configuration]、[Policies]、[Windows Settings] の順にツリーを展開して、[Windows Firewall with Advanced Security] ノードに移動します。次に、[Windows Firewall Properties] リンクを選択します。

次のダイアログ (下図) で、[Domain Profile] のファイアウォールの状態を [Off] から [On (recommended)] に変更し、 [OK] ボタンをクリックします。

下の図では、[Domain Profile] の Windows ファイアウォールがオンになっていることがわかります。

今度は、左側に表示されている [Windows Firewall] ノードを展開して、[Inbound Rules] ノードを選択します (下図)。現在はルールが存在しないため、ルールのリストは空白です。

以下のように、[Inbound Rules] ノードを右クリックして、ポップアップ メニューから [New Rule…] を選択します。

先に述べた、個々のマシンに IPsec を使ってポートを保護するためにルールを作成したときのように、 [New Inbound Rule Wizard] を使って手動で同様の作業を行います。以下のように、ポート ルールを選択します。

[Protocol and Ports] ウィザード ページで、目的のポートを入力します。

[Action] ウィザード ページで、[Allow the connection if it is secure] オプションを選択し、 [Customize …] ボタンをクリックします。

セキュリティ設定を選択するダイアログでは、下図のように、認証と整合性保護を強化するオプションを選択し、 [OK] ボタンをクリックします。

[Next] ボタンをクリックし、 [Users] と [Computers] ウィザード ページではすべて既定の設定のままにします。

[Profile] ウィザード ページで、以下の図のように、[Domain] プロファイルを選択します。

最後に、以下の図のように、新しい受信ルールに名前を付けます。

これで GPO のセットアップは完了しましたので、グループ ポリシー管理エディターで受信ルール リストの新しい受信ルールを確認します。その後、エディターを閉じ、元のグループ ポリシー管理コンソールに戻ります。

GPO セットアップが済み、今度はこの GPO を Azure サーバー OU にリンクする必要があります。[Azure Servers] OU を右クリックして、ポップアップ メニューから [Link an Existing GPO…] を選択します (下図参照)。

[Select GPO] ダイアログで、作成した新しい GPO を選択し、ダイアログを閉じます。

この設定によって、下の図のように、GPO が Azure Servers OU と関連付けられます。

これから、仮想マシン (canis-sql12-01) に戻って、この GPO を適用し、GPO が適用されたことを確認します。以下のように、コマンド プロンプトで、gpupdate /force コマンドを入力します。下図で、ポリシーの更新が成功したことが確認できます。

GPO が適用されたことを確認するために、次に、gpresult /r /scope computer コマンドを入力します (以下参照)。ご覧のとおり、GPO が適用されていることを確認できます。

では、Windows ファイアウォールを開いて、作成した 2 つの GPO オブジェクトを確認してみましょう。Windows ファイアウォールの最上位ノードで、ドメイン プロファイルの Windows ファイアウォールがオンになっていることを確認できます。また、ファイアウォールの状態にグループ ポリシー設定が適用されているという通知 (この例では、特にドメイン プロファイル向け) が表示されています。

[Inbound Rules] ノードを選択すれば、IPSec 受信ルールがポート 5723 に対して適用されていることを確認できます (下図参照)。

仮想マシンからの送信インターネット接続を制限する

理由は明白ですが、企業のお客様は、一般的にサーバーからの送信インターネット アクセスを制限します。特に、社外で共有された場合に業務に大きな影響を与えかねない機密データを格納するバックエンド サーバーでは通常この制限が行われます。パブリック クラウドでは、この傾向はさらに顕著です。企業のお客様は、たとえクラウド プラットフォームについて検討する段階であっても、クラウド プロバイダーを大いに頼りにしており、クラウドでのセキュリティ制御がオンプレミスよりも劣ることなど決してあって欲しくないからです。ここまでで見てきたように、幸い、Windows Azure の仮想マシンも PaaS マシンも、ドメインに参加でき、グループ ポリシーを適用できますので、企業のお客様は、使い慣れた方法で自社のサーバーを保護し、サーバーから外部に機密情報が漏洩しないように防ぐことができます。ここからは、仮想マシンからの送信インターネット接続を制限する方法を紹介します。ここではグループ ポリシーを使いませんが、先述の IPsec での場合と同様の方法を応用できます。

最初に、前のセクションで使われた SQL Server の仮想マシンから始めます (下図参照)。先ほど、グループ ポリシーを適用した後で、セキュリティが強化された Windows ファイアウォールを起動しました。

このマシンは、現在インターネットにアクセスが可能で、SQL Server Management Studio から、別のオンプレミス SQL Server にもアクセスすることができます。そこで、VPN 構成で定義したように、仮想マシンがオンプレミスのサブネット (192.168.1.0/24) にのみアクセスできるように制限します。最上位のノードを右クリックして、プロパティ ページを表示すると、送信接続が既定で許可されていることが確認できます (下図参照)。

以下のように、このオプションを [Block] に変更します。

これで、オンプレミスの SQL Server またはインターネットへのアクセスはできなくなります (下図参照)。

次に、Windows ファイアウォールの [Outbound Rules] ノードをクリックし、右クリックして、ポップアップ メニューから [New Rule…] を選択します。 [New Outbound Rule Wizard] の [Rule Type] ページで [Custom] ルールを選択します。

[Program] ページでは既定の設定をそのまま使用します。

[Protocol and Ports] ページで、以下の図のように [TCP] プロトコルを選択します。

次に、 [Scope] ページが表示されます。リモート IP アドレス オプションを [These IP addresses:] に変更し、次に [Add…] ボタンをクリックします。

表示されたダイアログで、この仮想マシンがアクセスできる唯一の IP アドレス セットとして、オンプレミスのサブネットを指定します (下図参照)。

最終的に [Scope] ページは以下のようになります。

[Action] ページで、[Allow the connection] オプションを選択します。

次に表示される [Profile] ページで、[Domain] プロファイルのみを選択します。

最後の [Name] ページで、以下のように、新しいルールに “Outbound Connections to On-Premises Subnet” という名前を付けます。

送信ルール ウィザードの設定が完了し、以下のように、新しいルールを確認できます。

これで、オンプレミスの SQL Server またはオンプレミス サブネットの他サーバーに接続できるようになりましたが、望みどおり、インターネットには接続できません。

ここまでの設定で、効果的に、この仮想マシンからインターネットへのアクセスを制限できました。しかし、現在、Windows Azure 環境の他のマシンにもアクセスできません。この問題は、先ほど作成した送信ルールに個々の IP アドレスか IP アドレス範囲を追加することによって解決できます。たとえば、この仮想マシンで SQL Server Management Studio を使用して、pcv94pjwnj.database.windows.net という URL を持つ Azure SQL データベース サーバーにアクセスしたい場合を考えてみましょう (下図参照)。

以下のように、サーバーに対して ping コマンドを実行し、その IP アドレスを確認します。

次に、リモート IP アドレスのホワイトリストにこの IP アドレスを追加します (下図参照)。

これで、このサーバーへのアクセスが可能になります。

Windows Azure プラットフォームから IP アドレス範囲を指定したい場合には、こちらのページから Azure データセンターの IP 範囲のリストをダウンロードできます。選択できる範囲は多数ありますので、実際に使用するデータセンターに関するエントリだけを選択して追加することをお勧めします。私は主に、米国西部のデータセンターを使用していますが、米国北部にもいくつか古いデータベース サーバーがあるため、私の例で言えば、次のようなエントリを追加していれば、米国北部のすべてのデータベース サーバーに対して仮想マシンのアクセスを許可できました。以下のリストでは、送信ルールに追加した私のデータベース サーバーを含む範囲がハイライトされています。

以上で、仮想マシンの送信アクセス制限に関しては、すべての設定が完了しました。なお、Azure のアドレス範囲は定期的に変更されますので、数か月おきに確認するか、ホワイトリストに含まれる IP アドレスの Azure リソースが突然利用できなくなった場合に確認してください。

まとめ

このドキュメントでは、IaaS 仮想マシンを保護するさまざまな方法を見てきました。Windows Azure IaaS 環境は、実質的に、オンプレミス ネットワークの延長として構成できるため、Windows Azure で強化されたオンプレミスの既存セキュリティ構造に関する知識を活用して、エンタープライズ アプリケーションを実行する Azure にデプロイされた仮想マシンを効果的に保護することができます。ネットワーク ACL、仮想ネットワーク、およびセキュリティが強化された Windows ファイアウォールを併せて利用すれば、強固なセキュリティ シナリオを実現することができます。

参考資料

 

Ashwin Palekar

Windows Azure ネットワーク チーム