なぜSSL-VPNなのか。素朴な疑問を解消しよう：使い方が見えた！ これからが本番、SSL-VPN（1）（2/3 ページ）

[則房雅也，日本電気（株）]

Web化しないと安全に
アプリケーションをインターネットから使えない？

SSL-VPNを実現する手法にはいろいろある

　いろいろな偶然と必然が重なって多くのアプリケーションがWeb化されたが、すべてのアプリケーションがWeb化できるわけではない。ブラウザにも機能の限界がある。Webポータルを開発するコストを掛けなくても、イントラネットで使われているクライアント／サーバ型のアプリケーションの利用範囲をインターネットに広げることができるのがSSL-VPNである。インターネットにつながった拠点間で、社員が外出先からイントラネットへと、業務に必要なアプリケーションを使うことができるようになる。

　リバースプロキシ以外に使われているSSL-VPNの手法には次のものがある。

1	SSLトンネルを使ってアプリケーションパケットをリレーする方式
2	SOCKSプロトコルにSSLを組み込んでTCP/UDPパケットをプロキシする方式
3	SSLトンネルを使ってL2フレームをリレーする方式
4	SSLを適用したThinクライアントを使ってアプリケーションを遠隔利用する方式

　いずれの方式であっても、かつて専用クライアントソフトを使っていたものでも、いまでは、ブラウザさえあればSSL-VPNを実現することができる。必要となるVPNモジュールは、JavaやActiveXを使ってダウンロードする。ユーザーPCにソフトも装置も事前にインストールする必要はない。これらについてはあちこちで紹介されているので多くを繰り返し説明する必要はないだろう。最も本質的なところだけを触れることにする。

1.SSLトンネルを使ってアプリケーションパケットをリレーする方式

　Javaアプレットを使ってSSL-VPN装置との間にSSLチャネルを作り、アプリケーションの通信データを通すトンネルとして機能させる。アプリケーションがこのSSLチャネルの入り口に向かって通信するように、JavaアプレットがHOSTSファイルに情報を追加し、通信先としてループバックアドレスを用いさせる。IPSecのトンネルではIPパケットを処理しIPルーティングでデータを送るが、SSLのレイヤになると、アプリケーションサーバの待ち受けポートにアプリケーションパケットが届くように動作する（図2）。

図2　SSLトンネルでリレーする方式

　NATなどIPルーティングの課題はSSLチャネルが作られたときに解決しているのである。ポートフォワードといういい方はここから来ている。

　ポートの対応が鍵になるこの方式では、SSLのチャネルを作るとき、アプリケーションパケットを届けるサーバとポートが決まっている必要がある。SSLのチャネルを一度作れば、アプリケーションがどこへでもアクセスできるようにはならない。誤解されやすい点なので指摘しておく。しかし、これがインターネットからイントラネットへのアクセスに要求される強固なセキュリティ管理の根拠になる。

2.SOCKSプロトコルにSSLを組み込んでTCP/UDPパケットをプロキシする方式

　SOCKSを使う方式がほかと違うところは、アプリケーションプロトコルがSSL-VPN装置で終端しないで、アプリケーションサーバまでつながることである。そのため、普段使っているアプリケーションクライアントをそのまま使える。アプリケーションプロトコルは、SSL-VPN装置まで常にSOCKSプロトコルで送られ、このSOCKS通信を行ううえでSSLが使われる。SOCKSが汎用的にTCP/UDPをプロキシするためのプロトコルなので、結果的に、いろいろなアプリケーションが、オリジナルのクライアントを使ってSSL-VPN経由でアプリケーションサーバにアクセスできるようになる（図3）。

図3　SOCKS＋SSLを使うプロキシ

　SOCKSプロトコルではドメイン名に対応するIPアドレス解決をサーバ側で行わせる仕組みを持っていることから、ユーザーPCのHOSTSに情報を追加する必要はなく、どのアプリケーションサーバを指定してでもSSL-VPNを作ることができる。これをさせるかさせないかは、SSL-VPN装置側のポリシー管理の話となる。この方式で強固なセキュリティを実現するためには、ユーザー認証とアクセス管理が鍵となる。

3.SSLトンネルを使ってL2フレームをリレーする方式

　ほかの方式に比べてこの方式はとても新しい。概念的に似たような技術としてPPTPがある。PPTPではPPPフレームをIPパケットに包んでIPトンネルを作って送るが、ここでは、PPPフレームをSSLのトンネルで運ぶ。この仕組みが成り立つように、ActiveXコントロールでL2レベルのドライバをインストールし、ActiveXがSSL-VPN装置との間に作ったSSLチャネルの入り口にPPPフレームが送られるようにする。この方式がほかのどの方式とも違う点は、SSL-VPN装置より先の通信が、PPPフレームから取り出したIPパケットのIPルーティングになることである（図3）。

　理論上PPTP同様いろいろなアプリケーションが使える。SOCKSでは個々のアプリケーションが通信するタイミングでSOCKSとSSLが機能するのに対し、こちらの方式ではActiveXがSSLのチャネルを作っておき、そこにいろいろなアプリケーション通信を通すようにする。ユーザー認証のタイミングなどが違う。つまり、強固なセキュリティを実現するためには、PC上で実行されるアプリケーションを管理することが鍵となる。

4.SSLを適用したThinクライアントを使ってアプリケーションを利用する方式

　Thinクライアントを使えば、PC側にはアプリケーションを置かず、共有サーバでアプリケーションを動かし、これをPCから操作するということが行える。ICA（Independent　Computing　Architecture）やRDP（Remote Desktop Protocol）という技術を使い、SSLが一緒に使えるようになっている。仮想画面上でアプリケーションが動作すると、その変化差分が送られるのである。サーバコンピューティングと呼ばれるモデルである。

　アプリケーションプロトコルが関係しない点で、ほかの方式とアーキテクチャがずいぶん違う。ただ、共有サーバ側ではほかのサーバとの通信にアプリケーションプロトコルが利用されることになる。

　このようにSSL-VPNのアーキテクチャは昨日今日考え出されたというわけではない。10年以上もインターネット上で使われ、鍛え上げられてきた技術と経験と工夫の集積といってもよい。SSLという1つの技術で何かと対比するのは間違いで、いろいろな通信、セキュリティ技術を融合するソフト集積技術として考え、どう利用するのかを考えることが建設的な見方だといえる。