SSL-VPNが昨年来、たいへんな注目を集めている。この5月には、日本電気が自社のSSL-VPNアプライアンス「SAFEBORDER」を使って新たな社内向けリモートアクセスサービスである「イーセキュアリモートアクセスサービス（es-RAS）」を試験的にスタートさせた。外部からインターネット経由でアクセスし、社内のイントラネットで提供されている申請手続きやマニュアルのダウンロードなどを行えるというサービスである。

　es-RASの主なターゲットユーザーは、海外駐在の社員だという。SAFEBORDER開発部隊のリーダーであり、es-RASの仕掛け人でもあるNECビジネス開発本部エキスパート、則房雅也氏はこのプロジェクトをスタートさせた動機について、「NECのイントラネットは従来、海外からはアクセスする手段がなく、数千人の海外出向者が不便を強いられていた。たとえばみずからの業績評価を行う際に提出する資料も、いったんファイルをメールで受け取り、それに記入してメールで送り返すといった回りくどい方法を採らざるを得なかったのです。彼らに日本のスタッフと同じ環境を提供し、同じようにイントラネットにアクセスできるようにしたいと考えました」と話す。

図1 リモートアクセスのゲートウェイとしてのSAFEBORDER

　この環境を実現する手段として、SAFEBORDERとCSE社の「SECUREMATRIX」が採用された。SAFEBORDERはNECが米Permeo Technologiesと共同開発したSSL-VPNのアプライアンス製品で、2003年6月に販売を開始している。ユーザーが利用するアプリケーションの通信経路やアクセス制御などを動的に管理できる「ダイナミック・ポート・マネジメント（DPM）技術」を採用し、社内ネットワークに設置するだけで、外出先からメールやグループウエア、各種業務システムなどを利用することができるようになるというものだ。同社はSAFEBORDER導入により、約80％のTCO削減が可能になると試算している。

　一方、SECUREMATRIXは、人が頭の中に想い描くイメージとワンタイムパスワードを組み合わせたブラウザベースの認証システムである。ログインするごとに毎回変わるマトリクス表の中から、ユーザーの好きな位置と順番で数値を選ぶというものだ。則房氏は「NEC社内では現在、ICカードを使ったPKI認証を採用している。この方式はセキュリティは高いが、アクセスにICカードリーダーが必要で、持ち運びも不便なことに対して社員の不満が少なくなかった。こうした使い勝手を向上させる手段として、ブラウザベースで認証ができるSECUREMATRIXと、クライアントレスのインターネットVPNであるSAFEBORDERの組み合わせがベストではないかと考えました」と説明する。「この組み合わせであれば、ハードはいっさい不要で、Webブラウザだけあればすむ。海外や出張先にいるユーザーでも、パソコンがあってブラウザがあればいい」というのである。もちろん、SAFEBORDERは従来のICカードを使ったPKI認証なども使用可能という。

図2 PKI認証

　実際にes-RASを使ってイントラにアクセスしてみると、SECUREMATRIXの認証後、すぐにWebブラウザに「SAFEBORDER Application Portal」という画面が現れる。ここからメニューに従い、Internet ExplorerやFTP、TELNETなどイントラネット上のアプリケーションを使えるというわけだ。もちろん、ユーザーに対してどのアプリケーションでどのコマンドを許可するかといった細かいアクセス制御も可能で、社内のイントラネットの奥深くに位置している部門サーバにもアクセスさせることができる。則房氏はそのメリットを、こう解説する。「イントラネットのWebサーバがSSLに対応していたとしても、OSの脆弱性などを考えればあまりそうした環境を外に晒したくはない。だが間にゲートウエイとしてSAFEBORDERを置き、そこで認証とアクセス制御を行えば、これまでであればDMZに置かなければならなかったようなグループウエアのサーバでもイントラネットの中に配置し、SAFEBORDERからチャネルを張らせるといったことができるようになります」。

図3 ポータル画面

　SAFEBORDERを支える技術は、どのようなものなのだろうか。その説明に入る前に、最近のVPNの動向をおさらいしておこう。

　インターネットVPNが大ブームである。背景には、無線LANなどのモバイルインターネット環境が、社会のインフラとして整備されてきていることがあるだろう。リモートアクセスによって外部から社内のイントラネットを利用したいというニーズが、今までにないほど高まっているのである。

　そんな中で安価でセキュアなコネクティビティの手段として注目を集めているのが、インターネットVPNだ。これまでインターネットVPNと言えば、IPsecが業界標準として広く普及してきた。IPsecはOSI7階層モデルのネットワーク層に実装されて仮想トンネリングを行い、あたかも専用線で結ばれているかのような2点間接続を実現する技術である。いったん接続されれば、上位層のアプリケーションプロトコルに依存せずに利用できるため、さまざまなアプリケーションをIPsec経由で使えるようになる。

　だがIPsecには、問題点もある。クライアント側に専用のソフトウエアや装置を必要とすることだ。拠点間接続はともかく、社員が企業のイントラネットにアクセスするためにVPNをリモートアクセスの手段として利用するようなケースでは、かなりのオーバースペックになってしまう。クライアントソフトウエア・装置の管理やサポートの業務は、VPNを運用する部門にとってもかなりの負担となるだろう。さらにNAT越しの接続ではプライベートIPアドレスが衝突してしまい、ルーティングができなくなってしまうという問題もある。家庭内LANを組んでいる自宅のPCから、会社のネットワークに気楽にリモートアクセスするといった用途には、あまり向いていないのだ。

　そんな中で昨年来たいへんな勢いで盛り上がってきたのが、SSL-VPNだ。SSL-VPNは文字通り、SSL（Secure Sockets Layer）技術を暗号化通信に使ったVPNである。トランスポート層の上位でアプリケーションごとに実装されることで、セキュアな通信を実現している。Internet Explorerなど主要なWebブラウザはSSLに標準対応しており、Webベースのアプリケーションであれば、クライアントレスでSSL-VPN環境を簡単に実現することができる。クライアントソフトウエアや装置を導入する必要はない。

　メリットは他にもある。IPsecはアプリケーションごとのアクセス制御が行う機能を標準で持っていないため、アクセス制御を行う場合には、ルータやスイッチでIPアドレスやポート番号をコントロールしなければならない。だがSSL-VPNはアプリケーションごとに実装されるため、細かいアクセス制御をかけるのが非常に容易になっている。

　SSL-VPNの実現方式には、次のようなものがある。

1. リバースプロキシ（HTTPS）タイプ
2. ポートファワーディング（SSLトンネル）タイプ
3. シンクライアントタイプ
4. .SOCKS（TCP/UDPプロキシ）タイプ
5. L2カプセル化タイプ
   

　1はSSL-VPNのもっとも基本的な形態で、クライアントとSSL-VPNゲートウエイ間の通信をHTTPSプロトコルで暗号化し、リバースプロキシを使って社内ネットワークに接続するというものだ。ただこの方式は、SSLを実装したWebブラウザを使った場合に限られる。問題はSSLを実装していないアプリケーションである。こうしたアプリケーションとの通信を実現するために、2〜5の方式が考えられた。

　2のポートフォワーディングタイプは、Javaアプレットを利用するものだ。SSL-VPNゲートウエイにクライアントが接続すると、Javaアプレットがダウンロードされてくる。たとえばイントラネットのサーバからメールを受信するケースを例に考えてみよう。Javaアプレットは、クライアントPCのhostsファイルに自分が通信するメールサーバのドメイン名を記述する。クライアント側のメーラーから送られたパケットはループバックされてクライアントのlocalhostに送られ、Javaアプレットに拾われてSSLトンネルを経由してSSL-VPNゲートウエイへと送られるのである。3のシンクライアントタイプは、この方式をJava化した専用ソフトを使って実現するものだ。

　一見、非常に便利に見えるポートフォワーディング方式だが、弱点はいくつかある。ひとつは、利用するサーバのIPアドレスとドメイン名を事前にクライアント側のhostsファイルに記述しておかなければならないことだ。たとえばイントラネット側に、部門ごとにメールサーバが立てられているようなケースでは、サーバごとのIPアドレスとドメイン名のペアを作っておいて、Javaアプレットにすべて登録しておかなければならない。イントラネットの構成が巨大かつ複雑な場合は、この手順がかなり煩雑なものになってしまう。またメーラーやインスタントメッセンジャーなど、SSL非対応のアプリケーションを利用しようとすると、そのたびにJavaアプレットを新たに作らなければならないという問題がある。

　こうした問題をある程度解決させるのが、4のSOCKSを使った方式だ。そしてSAFEBORDERもこの方式を採用している。SOCKSというのはNECが中心となって開発したプロトコルで、RFC 1928としてIETFによって標準化されている。プロキシによってクライアントとサーバの間にコネクションを張る仕組みである。

図4 SOCKS＋SSLタイプ

　この方式では、アプリケーションの要求に対し、クライアント側にダウンロードされたSOCKSモジュールが無条件でまずSAFEBORDERとの間でチャネルを張ってくれる。そしてたとえばクライアント側のメーラーがイントラネットのメールサーバと通信しようという場合、SOCKSのチャネルを通じてメールサーバのドメイン名がSAFEBORDERに送られる。この際、名前解決はJavaアプレット方式の時のようにクライアントPC内のhostsファイルを使う必要はない。SAFEBORDERがそのドメイン名をサーバ側のネットワーク内にあるDNSで名前解決し、コネクションを確立してくれるのである。

　SOCKS方式のメリットはいくつかある。まず第1に、クライアントPCの側にイントラネットの情報を持たなくてもすむということ。第2に、Javaアプレットを使ったポートフォワーディング方式などと比べ、アクセス制御が非常に容易になることだ。SAFEBORDERでは、クライアント側が渡した自分の部門のメールサーバのドメイン名に対し、名前解決をしてチャネルを張るという手順で行われる。このチャネルを許可するかどうかは、アクセスポリシーとしてSAFEBORDERで設定することができる。つまりこのユーザーにはこの部門のメールサーバはアクセス許可するが、こちらのメールサーバにはアクセスさせない――といったアクセス制御が非常に簡単に行えるようになるのである。

　また先に述べたように、SOCKSを使った方式であれば、IPsecのようにプライベートIP同士が衝突してしまうといった問題も起きない。

　さらにパフォーマンスの問題でも、SOCKS方式は優位に立っているという。リバースプロキシではクライアント側のブラウザからSSL-VPNゲートウエイまでHTTPのチャネルが張られ、いったんゲートウエイでプロトコルが終端する。そしてゲートウエイが別途、WebサーバにHTTPのセッションを張り、認証などを引き継いでアプリケーションに渡すデータも積み直し、トンネル経由で流すという手順になる。当然、この二度手間のために若干のパフォーマンスの劣化は生じてしまう。Javaアプレット方式でも同様で、データの受け渡しの際にいったんプロトコルが終端してしまうため、若干の遅れが出る。しかしSOCKS方式では、メモリ上でアプリケーションデータをリレーするだけなので、性能劣化は少ない。則房氏は「正確な数値ではないが、NECの技術陣でSSL-VPN製品をひととおり検証してみたら、SAFEBORDERの性能劣化が比較的少なかったという結果が出ている。これが数千のユーザーともなると、顕著に差が出てくる可能性はあるでしょう」と話す。

　SAFEBORDERは他にもさまざまな特徴がある。たとえば負荷分散。VPNモジュールに対して並列設置したSAFEBORDERのIPアドレスを指定しておけば、自動的に任意のSAFEBORDERを選んでセッションを開始する。マスタースレーブ関係などを設定する必要はなく、SAFEBORDERをどんどん増やしていくだけでスケーラビリティを実現することができる。

　また次期バージョンでは、アプリケーションシグナチャという機能を実装する計画も進んでいる。これはSAFEBORDERでコネクションを確立した際、クライアント側にあるアプリケーションのシグナチャを解析してからアクセスを受け入れるかどうかを決めるというものだ。たとえばクライアントPCにインストールされているアンチウイルスソフトのシグナチャを判断し、最新のパターンファイルに更新されていなければアクセスを拒否するといった使い方が考えられる。

　SAFEBORDERを使えば、限りなくセキュアなモバイル環境を社員に持たせることもできる。SAFEBORDERでクライアント側のドライバモードを変更し、すべてのネットワークアプリケーションをSAFEBORDER経由でしか使えないように設定してしまえるのである。

図5 社外持ち出し端末の情報漏えい管理

　そうなるとクライアントPCはSAFEBORDER経由で会社のイントラネットにしか使えなくなり、事実上、社内でイントラネットに接続されたPCと同じ状態になる。たとえばこのモードに変更した上で、USBやパラレルポートなどPCの物理的デバイスをすべて殺してしまえば、データを外に出すことは不可能になる。かなり極端なケースではあるが、リモートアクセス環境と情報漏洩防止を同時に実現する方法としては、決して非現実的ではないだろう。今年初め、Yahoo! BBやジャパネットたかたなどの顧客情報漏洩問題が世間を騒がせたことは記憶に新しい。SAFEBORDERを使ったこうした手法も、検討課題のひとつとして考えておいてもいいのではないだろうか。