rss

Nov 4

Windows 7 DirectAccessのメリットとデメリット

Posted at Nov 4, 2009 10:21 AM コメント (0) トラックバック (0)

リリースの日付 : 2009 - 11 - 04

Windows 7に新たに搭載されたDirectAccessは、リモートアクセスのための画期的な代替策なのか。また、中堅企業にとってはどんなメリットと限界があるのだろうか。

 仮装プライベートネットワーク(VPN)は10年以上にわたり、リモートから会社のネットワークリソースへのセキュアなアクセスを提供してきた。管理者はクライアントのインストールからポリシー設定に至るまで時間のかかる作業に悩まされ、ベンダーはWebブラウザ形式のクライアントやロールベースのアクセス制御など、ありとあらゆる対応策で応えてきた。最近では、ワイヤレスのユーザーからローミング障害について不満が出ると、ベンダーは継続的に接続し続けるモバイルVPNの提供に乗り出し始めた。

 そして今度は、Microsoftがさらに優れた解決策の提供を宣言した。「DirectAccess」がそれだ。Windows 7に搭載されたこの新機能では、Windows Server 2008 R2 DirectAccess Serverを経由して、リモートからエンド・ツー・エッジおよびエンド・ツー・エンドのセキュアなアクセスを確保できる。しかし、DirectAccessは本当に画期的な代替策なのか。そしてさらに重要なのは、中堅企業にとってDirectAccessはどんなメリットと限界があるのかということだ。

DirectAccessとは何か
 DirectAccessは、認証され暗号化された自動開始型のIPv6/IPsec ESPトンネルを利用して、リモートのWindows 7ユーザーを社内ネットワーク(イントラネット)リソースに接続する。ほとんどのIPsec VPNがそうであるように、トンネルではWindows 7ホスト(DirectAccessクライアント)を社内ネットワーク(DirectAccess Server)のエッジ部分でゲートウェイに接続できる。あるいは、DirectAccessクライアントがDirectAccess Server経由でIPsecトランスポートモードを使い、IPv6プロトコルを使用するWindows Server 2008ベースのイントラネットサーバとの間でセキュアなエンド・ツー・エンドのセッションを確立できる。

 各DirectAccessクライアントは、会社のイントラネット上で割り当てられたサーバに接続しようとする。接続が可能なら、ユーザーはローカルでイントラネットに接続しているはずであり、DirectAccessは使われない。そうでない場合、ユーザーはリモートにいるはずであり、利用可能なネットワーク接続を介してDirectAccessがイントラネットとの間で双方向のセキュアなトンネルを確立しようとする。

 まず、DirectAccessクライアントとサーバがマシン証明書によって相互を認証する。サーバはイントラネットのActive Directoryを参照してクライアントPCのグループメンバーシップ(および、NAPでPCの安全性チェックが義務付けられている場合はイントラネットのHealth Registration Authority:正常性登録機関)を確認する。すべて順調にいけばIPsec ESP(Encapsulating Security Payload:パケット暗号化ペイロード)トンネルが確立され、クライアントがサーバに接続している間は常時維持される。

 この時点で、クライアントはセキュアなトンネルを使ってイントラネットのDNSサーバとWindowsドメインコントローラーに接続できる。Name Resolution Policy Table(名前解決ポリシーテーブル)では、リモートアプリケーションによるホストネーム参照をイントラネットで解決するか、インターネットのDNSサーバで解決するかを決める。インターネットサーバに振り向けられたリモートのトラフィックはすべて、直接素通りで送られる。

 リモートのアプリケーションがイントラネットサーバにトラフィックを送ろうとする場合、DirectAccessクライアントが自動的に第2のIPsec ESPセッションを確立する。ポリシー設定によっては、これにエンド・ツー・エッジのトンネルモードIPsec、またはエンド・ツー・エンドのトランスポートモードIPsecが介在することもある。いずれの場合も、マシンの証明書およびユーザー証明(例えばドメインパスワード、スマートカードなど)に基づき認証が行われる。すべて順調にいけば、ユーザーはローカルで接続しているのと同じように、許可されたイントラネットリソースとの通信が可能になる。

 特筆すべきは、DirectAccessはIPv6を利用しているということだ。DirectAccessクライアントは常にネイティブのIPv6を通じてIPsecトンネルを確立しようとする。これに失敗した場合(家庭や公衆ネットワークでは大半がうまくいかないだろう)、クライアントは6to4やTeredoなどの技術を使ってIPv4内部でIPv6のカプセル化を試みる。それでもうまくいかなければ(ファイアウォールやプロキシを使っている場合など)、DirectAccessクライアントはMicrosoftのIP-HTTPSトンネリングプロトコルを使ってHTTPSパケット内部にIPv6を格納する手段を取る。ほとんどのネットワークやファイアウォール、プロキシでは下りのHTTP over SSLを許可しているため、これで大抵はうまくいく。ただしいずれのケースとも、全イントラネットリソース用のIPv6 DNSネームスペースとIPアドレスプレフィックス、およびDirectAccessクライアントに割り当てられた公開ルーティング可能なIPv6アドレスを含め、イントラネットがIPv6をサポートしている必要がある。

DirectAccessとVPNとの違い
 DirectAccessはIPsec ESPとMOBIKE(IKEv2 Mobility and Multihoming Protocol)を含むVPNプロトコルを利用している。エンド・ツー・エッジの保護に使った場合、DirectAccessは標準的なIPsec VPNで提供されるのと同様のセキュアなトンネルを提供する。

 DirectAccessが標準的なIPsec VPNと異なる点は、トンネル管理の自動化の程度と、ほかのMicrosoftインフラとの統合の程度だ。他社のVPNの多くは完全に自動化されたトンネルの確立を提供している(一時的な接続の中断を隠すためのアプリケーションの持続性さえも)。しかし、MicrosoftのVPNゲートウェイであるWindows Server 2008のRouting and Remote Access(RRAS)は異なる。RRASユーザーは通常、自分でVPN接続を確立して(L2TP、IPsecまたはPPTP経由で)ログインする。この基盤となる無線あるいは有線接続が途切れれば、VPNトンネルを再度確立しなければならない。DirectAccessは、エンドユーザーによるこの操作と不便さを回避している。

 もう1つの大きな違いはルーティングにある。他社のVPNソリューションの多くは、特にSSL VPNは行き先がイントラネットかインターネットかを区別してリモートクライアントのトラフィックを振り分けている。しかし、レイヤー2トンネリングプロトコル(L2TPやPPTPなど)では単純に、出て行くトラフィックをすべて(分割せずに)トンネルを介してVPNゲートウェイにルーティングし、ゲートウェイからそのトラフィックをインターネットまたはイントラネットに転送しなければならない。DirectAccessはデフォルトでIPv6のネームスペースを利用して効率性を高め、煩雑なIPsec選択やSSL URLマップの必要性をなくした。それでも、DirectAccessクライアントではWindowsファイアウォールのグループポリシーに基づき、非イントラネットのトラフィックをトンネリングすることも可能だ。

 また、DirectAccessはエンド・ツー・エッジの保護にも対応しているが、Microsoftは可能な場合(つまり行き先がIPv6 Windows Server 2008である場合)はエンド・ツー・エンドの保護を奨励している。ネットワークがIPv6に移行すれば、ローカルとリモートの境界が薄れる中で必要とされるセキュリティアーキテクチャをDirectAccessでサポートできるからだ。

DirectAccessの使い方と利用シーン
 DirectAccessは一見、大企業向けに見えるかもしれない。しかし、購入したハードウェアとソフトウェアを最大限に活用しようとしている多くの中堅企業は、Windows RRASをVPNプラットフォームとして利用している。こうした企業ではDirectAccessをRRASのアップグレードと見なすことも十分できそうだ。

 さらに、中堅企業はVPNコンセントレータは購入しても、さらに高度なSSLやモバイルVPNにはなかなか投資しない。こうしたサードパーティーVPN(例えば常時接続トンネル、ファイアウォール/プロキシトラバーサルなど)が提供しているメリットの幾つかを、DirectAccessではハードウェアを購入したりクライアントをインストールしたりすることなく実現できるとしている。

 ただし、DirectAccessは万能ではない。まず、DirectAccessクライアントはWindows 7 Enterprise/UltimateとWindows Server 2008 R2に組み込まれているが、現時点でほかの種類のリモート端末への接続提供には利用できない(RRASなどほかのVPNソリューションは並行して利用できる)。

 次に、DirectAccessサーバはWindows Server 2008 R2 PCに少なくとも2枚のネットワークインタフェースカード(NIC)をインストールしなければならない。インターネットに接続するアダプターは、2つのIPv4アドレス(例えばDMZ上など)経由で公開ルーティングできる必要がある。可用性や拡張性が心配な企業は、複数のDirectAccessサーバを導入することもできる。

 さらに、企業のイントラネットが(少なくともある程度は)IPv6に対応している必要がある。これにはWindows Server 2008(SP2またはR2)を搭載し、IPv6に接続されたドメインコントローラーとDNSサーバが含まれる。Windows Server 2008のどのバージョンを実行しているものであれ、IPv6に接続されるアプリケーションサーバには、エンド・ツー・エンドまたはエンド・ツー・エッジモデルで接続できる。ほかのイントラネットアプリケーションサーバはすべて、NAT-PT(IPv4?IPv6間のプロトコル変換)経由で接続しているIPv4サーバも含め、エンド・ツー・エッジ接続限定となる。

 最後に、DirectAccessがWindowsプラットフォーム中心のイントラネットを想定しているのは明らかだ。例えば、DirectAccessはActive Directoryに参加しておらずマシンの証明書が発行されていないリモート端末の接続には利用できない。Windows認証インフラを採用してきた企業なら、DirectAccessでアクセスがさらに容易になったと感じるだろう。実際、DirectAccessはリモートユーザーがNAP、Windows 7 Federated Search、Windows 7 Folder Redirectionといった新しいWindowsネットワーク機能を活用する手助けをしてくれる。

本稿筆者のリサ・ファイファー氏はCore Competenceの副社長。25年以上にわたってネットワーク、セキュリティ、管理製品の設計、導入、評価に携わり、大小の企業を対象に、セキュリティの必要性、製品評価、新興技術の利用、ベストプラクティスについて助言してきた。

  • トラックバック
  • http://xn--0ckxcsa7dwd586vnlop4q.com/blog/mt-tb.cgi/1903