連載

2003年10月18日

“SSL-VPN or IPSecVPN”どちらが最適ですか？：SSL-VPNの導入メリット（後編）

LINE

Hatena

　前編「リモートアクセスVPNにSSL-VPNを採用する最適なケースは？」では、SSL-VPNはどのような技術を使用しているのか、さらにどのような仕組みでVPN環境を実現しているのか、について説明した。後編では、インターネットVPNを構築するためのソリューションの１つであるIPSecVPNと以下のポイントについて比較する。

実装されるプロトコル階層の違いが何に影響するのか
利用する環境に応じてどのような点を注意すべきか
運用・管理においてどのような点を注意すべきか

　この特集は双方のVPN技術を単純に比較してどちらが有効なのかという結果を導くことを目的としていないことを最初に断っておく。組織がリモートアクセス型VPN環境を構築する場合に、どちらのVPN技術が最適なのかを判断するために必要な情報を提供することを目的とする。

実装されるプロトコル階層による違い

　SSL-VPNで使用するSSLは、OSI7階層モデルのセッション層で実装される技術である。一方、IPSecVPNで使用するIPSecは、ネットワーク層で実装される技術である。この実装される階層の相違が上位のアプリケーションに与える影響について記述する。

図1 SSL-VPNとIPSecVPNで使用するOSI階層モデル

　IPSecはネットワーク層で実装されるため、上位のアプリケーションプロトコルに依存せずに利用することが可能である。つまり、HTTPやSMTP、FTPなどのアプリケーションを変更することなくIPSecVPNを使用して利用することが可能である。また、組織で独自に開発したクライアント／サーバアプリケーションについても同様に利用可能である。

　SSLはセッション層で実装されるが、実際は下位のトランスポートプロトコルごとにSSL対応する必要がある。例えば、HTTP（80）をSSL対応したプロトコルはHTTPS(443)であり、POP（110）についてはPOP over SSL（995）が存在する。外部から利用したいアプリケーションがSSL対応されているかいないかはSSL-VPNを導入するうえで重要なポイントである。アプリケーションがSSLに対応していない場合、以下のアプローチが考えられる。

・利用するアプリケーションにSSLを実装する

　アプリケーション自身をSSLに対応させる場合は、クライアントとサーバアプリケーションの両方のソフトウェアを変更する必要がある。このアプローチを選択する場合は、そのアプリケーションをSSL対応した場合の効果と変更するためのコストを比較検討する必要があるだろう。

・利用するアプリケーションをWebインターフェイスで利用可能なように変更する

　Webインターフェイスでアプリケーションにアクセスできるようなゲートウェイを開発し、サーバアプリケーションの変更を最小限に抑えつつ、SSL経由で利用できるようにするアプローチである。このアプローチも開発作業が発生するため、必要なコストとの比較が必要である。さらに、このアプローチの場合は外部から利用したい情報が変更されたり、追加されたりした場合にゲートウェイのアプリケーションも変更する必要がある。

　前編で記述したように、現在マーケットで提供されているSSL-VPN製品ではWebインターフェイス以外のアプリケーションに対応できるような機能を用意するものが多い。その機能を利用する場合はクライアント側に特別なアプリケーションをインストールする必要があるため（ユーザー自身でインストールする必要がある、あるいはJavaアプレットとしてダウンロードされる）、SSL-VPNの特徴の1つである“クライアントレス”とはいえない。

利用環境における違い

●接続形態

　VPNの接続形態には、組織間をVPNで接続するサイト間接続型と外部から組織内にVPN経由で接続するリモートアクセス型がある。SSL-VPNは、ブラウザからWebサーバへのアクセス形態を利用したソリューションであるため元来リモートアクセス向きである。また、IPSecVPNはもともと組織間を接続することを目的として標準化された技術である。それをリモートアクセス形態にも拡張しているが、ユーザー認証方法やNAPT（Network Address Port Translation）環境への対応方法、接続先ネットワーク情報の取得方法など標準化されていない仕様があり、相互接続性の問題を抱えている。

　サイト間接続が必要な組織でリモートアクセスも必要とする場合にどのようなソリューションを利用するのか、また、すでに導入されているサイト間接続環境に対してどのようなリモートアクセスソリューションを導入するかは、組織の運用サポートに関する考えやユーザーの操作性などから検討する必要がある。

●介在するアクセス制御デバイス

　すでにインターネット接続が構築されているネットワークにリモートアクセスのためのVPN装置を導入する場合を考えてみる。

図2 インターネットが接続できる状況に、VPN装置を追加する

　図2では、組織に導入されているファイアウォール装置の背後にVPN装置を設置する場合を考える。インターネット上のVPNクライアントからVPN装置に接続することを実現するためにファイアウォール上で許可すべきプロトコルを示す（参照：System Insiderフォーラム「技術解説　IT管理者のためのIPSec講座 - IPSecを構成する主な3つのプロトコル）。

・IPSecVPNの場合

IKE（500/udp）
ESP（プロトコルID：51）
UDP-Encapsulation（？？？/udp：？？？の個所はVPN製品により異なる）
- CheckPoint VPN-1 2746/udp
- Netscreen Series 500/udp（IKEと同じポートを使用）
- Cisco VPN3000 4500/ud

・SSL-VPNの場合

SSL（443/tcp）
インターネット経由でメールを購読する場合
- POP over SSL（995）
- IMAP4 over SSL（993）

　IPSecVPNでリモートアクセスを実現する場合は、上記のすべてのプロトコルの通過を許可する必要がある。SSL-VPNの場合、Webインターフェイスのアプリケーションのみを使用するのであればSSL（443）のみ許可すればよい。上記の例の場合、POP over SSLやIMAP4 over SSLを使用しなくても、Javaアプレットなどを使用してアクセスすることが可能である。その場合も、SSL（443）を使用するため、ファイアウォール上は外部からのSSLを許可するルール1つで済む。

●IPSecVPNにおいて注意すべき点

　上で記述した以外にIPSecVPNでは、エンドユーザーが以下の点についても意識する必要がある。

・Path MTU

図3 IPSecVPNで意識すべきMTU

　IPSec/ESPでは、図3のようにESPヘッダが追加され、NAT-Traversalではさらにポート番号変換用のUDPヘッダも追加されるため、IPSecなしで通信する場合と比較して一度に転送可能なデータ量が減少する。送受信するデータサイズが媒体のMTUサイズを超過する場合には、パケットはフラグメント（断片化）される。一般にフラグメントが多数発生するとデータの転送性能に影響を与えるため、可能な限りフラグメントが発生しないようにエンドポイント間で最大のMTUサイズ（PMTU）を検出する仕組みを有するVPNクライアントもある。

　しかし、経路上のルータが最適なMTUサイズ情報を含むICMP（Internet Control Message Protocol）メッセージの通過を拒否している場合は、送信元に最適なMTU値が戻されないため通信ができないことになる。

・ネットワークカードなどの追加

　VPNクライアントによっては、ネットワークカードを追加、ダイヤラソフトウェア（AOLなど）をインストールする場合に、1度VPNソフトウェアをアンインストールする必要がある。これは、VPNクライアントの仮想アダプタを新しくインストールしたネットワークカードアダプタにリンクさせる必要があるためである。

運用・管理面における違い

●VPNクライアントソフトウェアの存在

　IPSecVPNでリモートアクセスVPN環境を構築する場合、組織内のネットワークにVPNゲートウェイ装置を設置し、ユーザー側のクライアント端末には専用のVPNクライアントソフトウェアを導入する必要がある。さらに、インストール後にはVPNゲートウェイ装置に設定されているパラメータと同じ値をVPNクライアント上でユーザー自身が設定する必要がある。定義するパラメータには以下のようなものがある。

・IKE（フェイズ1）パラメータ

Diffie-Hellmanパラメータ
暗号化アルゴリズム（DES、3DES）
ハッシュアルゴリズム（SHA1、MD5）
ライフタイム

・IPSec（フェイズ2）パラメータ

暗号化アルゴリズム（DES、3DES）
ハッシュアルゴリズム（SHA1、MD5）
ライフタイム

・VPNドメインネットワーク

・DNSサーバアドレス／WINSサーバアドレス

　日ごろIPSecに関してあまりなじみがないユーザーにとって、上記のパラメータを間違いなく設定することは非常に困難である。入力ミスが1つあるだけでVPNコネクションは確立できないのである。このような状況では、管理者がエンドユーザーをサポートする負荷は非常に大きくなる。実際、カスタマがリモートアクセス環境においてIPSecVPNの導入を躊躇（ちゅうちょ）する大きな理由の1つが、エンドユーザーのサポート負荷が大きい点である。これを解決するために、IPSecVPN製品を提供するベンダでは、VPNゲートウェイ側で定義したパラメータをVPNクライアントに配布する機能を提供している。その機能を利用することで面倒なパラメータ設定をユーザーに任せることを解決できる。

　それに対して、SSL-VPNを導入した場合、Webインターフェイスのアプリケーションを利用する限りでは、ユーザー端末にはSSLに対応したブラウザソフトウェアのみインストールされていればよい（現在提供されている環境であれば、実際は何も行わなくてもよい）。しかし、Webインターフェイスのアプリケーション以外を利用する場合は、SSL-VPN装置からJavaアプレットのダウンロードや、Windowsアプリケーションをユーザー端末にインストールする必要がある。特にJavaアプレットの場合、利用するたびにダウンロードする必要があり、さらに起動までに時間がかかる。

●マルチプラットフォーム

　リモートアクセスで使用するクライアント端末として、ノート型PC（Windows系OS）やPDA端末（WindowsCE系OS）など複数のプラットフォームを利用したい場合がある。

　SSL-VPNの場合、Webインターフェイスのアプリケーションを利用するのであればSSL対応のブラウザソフトウェアが存在すればよいので、大抵のプラットフォームで利用できる。また、Webインターフェイス以外のアプリケーションに対応したJavaアプレットやWindowsアプリケーションも同一のベンダから提供されるため、異なるプラットフォームでも同じような使用方法が実現できる。ただし、利用するアプリケーションによってどの機能を使用するかをエンドユーザーが判断する必要がある。

図4 SSL-VPNとIPSecVPNで利用可能なプラットフォーム

　IPSecVPNの場合、Windows系のOS向けのVPNクライアントは大抵のベンダから提供されるが、PDA端末（WindowsCE系OS）向けのVPNクライアントも一緒に提供しているベンダはまれである。一般にPDA端末向けのVPNクライアントは、モバイル端末向けのソフトウェアベンダから調達する必要がある。従って、組織ではOSプラットフォームによって異なるVPNクライアントソフトウェアを導入する必要があるため、管理者にとっては複数ソフトウェアをサポートする負荷が増大し、ユーザーにとっては同じリソースにアクセスするにもかかわらず、利用するプラットフォームごとにユーザーインターフェイスを学習する必要がある。

　クライアント端末にはSSL対応したブラウザが存在すれば利用できるというSSL-VPNであるが、Webインターフェイスのアプリケーション以外を利用するケースやセキュリティを強化するためにクライアント証明書を利用するケースでは、クライアント端末にアプリケーションや証明書をインストールする必要がある。結果的に、エンドユーザーに頼らなければならない設定作業が発生してしまう。

　SSL-VPNを利用するときにはユーザー名／パスワードにより認証するが、エンドユーザーが便利さを追求するあまりパスワードを保存する設定にしていた場合はどうだろうか。他人がクライアント端末を起動してもVPNを利用できてしまう。クライアントをインストールする必要がないため、逆にだれでも利用できる立場にあるのである。逆にIPSecVPNのように特別なソフトウェアをインストールしなければならないことがある意味セキュリティを確保しているという考え方もできる。

　結論としては、どのようなソリューションを導入するかは、

どのようなエンドユーザーが対象なのか
どのような使い方を想定するのか
どの程度のセキュリティを実現する必要があるのか

などを基に検討する必要があるだろう。

「SSL-VPNの導入メリット」バックナンバー