特集：使い方が見えた！ これからが本番、SSL-VPN（後編）
SSL-VPN、アプリケーション連携の先にあるもの

則房雅也　CISSP
日本電気（株）　ビジネス開発本部
SSL VPNリモートアクセス分科会（enNetforum内）主査
2004/7/1

　前編「なぜSSL-VPNなのか。素朴な疑問を解決しよう」ではSSL-VPNが登場するに至った背景や基本的な方式や、VPNのチャネルはどう作られるかという視点で説明した。今回はセキュリティという視点から説明を始めたい。その後で、SSL-VPNを使うと、いま使っているアプリケーションの利用がどう変わるかを説明する。

意外と多くの仮説を信じてセキュリティは 　実行、管理されているものだ

■SSLを使わないリモートアクセスをまず考えてみる

　皆さんが、自宅からADSLを使ってインターネットを利用するとき、セキュリティが何も実行されていないわけではないだろう。PCにログインするときユーザーIDとパスワードを入力するし、契約プロバイダのネットワークにアクセスするとき、そのためのユーザーIDとパスワードを入力している。

　PC上ではパーソナルファイアウォールやウイルスチェックプログラムが常時動いているし、ブロードバンドルータでは、送受信するIPパケットを監視している。このようなユーザーは誰でも、企業のDMZから公開されているWebサーバの情報を閲覧できる。Webサーバに対しては、ページの改ざんが行われないように、Webブラウザを通じて、DMZのどこかで監視プログラムが走っているだろう。

　リモートアクセスを考えるとき、どのようなユーザーであってもこの程度のセキュリティ管理は行われているのである。もう1ステップ奥深く進んで、企業のイントラネットの中までアクセスを受け入れると、これまでできなかったリモートVPNが実現されることになる。ところが、この最後の1ステップが考えているよりはるかに難しく、克服すべき課題も多い。また、DMZ上のサーバにアクセスするときに適用されているセキュリティ基準をそのままリモートVPNに適用することはできない。

■セキュリティ実行結果の間で信頼関係の連鎖ができていない

　まず図を見ていただきたい（図1）。歴史的に、セキュリティはいつもそのとき必要とされる目的を満たすために単独で実現されてきた。その目的以上のことを実装することも難しい。例えば、PCにログインするとき、プロバイダにアクセスするときなど、ユーザーは最低でもIDとパスワードを入力している。この作業で、大多数のユーザーは、そのPCでアプリケーションを使うなら、これらの認証結果が使われていろいろなところへのアクセスが許されるだろうと思うかもしれない。実際には、これらの認証結果がほかから参照されることはまずない。

図1　独立に実行されているセキュリティ

ユーザー自身ではID／パスワード（PCにログイン、プロバイダネットにログイン） − アプリケーションを使うためではない PC上の監視ではあて先ポート番号でアクセス管理、あて先IPアドレスを監視 − 誰が、どのアプリケーションを使っているかは不明 ネットワーク上の監視ではIPアドレスを見るが、NATが入ってユーザーPCのIPアドレスは不明 − 誰が、どのPCから、どのアプリケーションを使っているかは不明 ファイアウォール上の監視ではアクセス先IPアドレスかポート番号でアクセス管理 − 誰が、どのPCから、どのアプリケーションを使っているかは不明 サーバ上の監視ではファイアウォールがあるのでどんなアクセスでも信用する − 内部からか外部からか分からない。誰が、どのPCから、どのアプリケーションを使っているかは不明 アプリケーションではアプリケーションプロトコルでユーザーを確認する 途中の情報はほとんど何も引き継がれない

　PC上ではパーソナルファイアウォールが使われており、送り出すIPパケット、届けられたIPパケットを監視している。ファイアウォールなので、IPアドレスやポート番号は見ても、どのユーザーがどのアプリケーションを使っているかという管理は行っていない。ユーザーがプロバイダへアクセスするときに入力したIDやパスワードは、IPパケットで送られたデータにすぎず、これらが取り出されて使われることもない。

　似たようなことはプロバイダで行う管理に関してもいえる。プロバイダのアクセスポイントでユーザー認証をしても、以降のアクセス管理には、プロバイダがPCに対して割り振ったIPアドレスが使われる。そこでは、IPパケットでアクセス管理、トラフィック管理を行うために、認証したユーザーに割り当てたIPアドレスに認証結果を引き継がせている。リモートアクセスサーバで一般的に行われる手法である。

　企業のDMZにIPパケットが届くときには、何度かNATが実行されて送り手IPアドレスは隠れてしまう。IPパケットを見てもユーザーのPCは分からない。多くはどこかのプロバイダのIPアドレスになっているはずである。こういう条件では、DMZで公開するWebサーバやメールサーバへのアクセスを管理するために、送り手IPアドレスでフィルタを掛けても意味がないことは容易に理解できるだろう。DMZ上のサーバへのアクセスになると、ファイウォールには、「これらサーバのIPアドレスとポート番号へのアクセスを許す」という管理しかできないのである。

　これはいい換えると、DMZにサーバを置く限り、常時監視は行えても、最初のアクセスだけは誰からのものであっても受け付けなければならない。IPアドレスには匿名性が出て、アクセスに使っているPCは分からない。逆の観点からは、サーバ環境にセキュリティ脆弱性が残っている限り、セキュリティの脅威から逃れることはできない、といえるのである。

　イントラネット上のサーバになると、すべてのアクセスがイントラネットのどこかから行われたようにしか見えない。もし、ファイアウォール経由でインターネットからのアクセスが行われると、特別なセキュリティ管理をサーバで、特定のアクセスに限定してだけ行うことは難しい。

　こういうDMZ上のサーバだけでなく、イントラネットのサーバへも安全にアクセスを許そうという目的を満たすのがSSL-VPNである。まず、こういうゲートウェイが満たすべき条件を整理しよう。

■VPNに使われるゲートウェイが満たすべき要件

　それぞれ、以下のようなチェック項目を用いて、管理していただきたい。いずれも、セキュアなSSL-VPNの管理に不可欠な項目である。

（1） セキュアなユーザー管理

1. リモートアクセスしてくるユーザーの本人確認を行う
2. 本人確認に使うユーザー情報を安全に管理する
3. ゲートウェイ運用者のアクセス権を安全に管理する

（2） セキュアなセッション管理

1. ユーザーからゲートウェイへのセッション、ゲートウェイからアプリケーションサーバへのセッションの間で受け渡されるデータが、改残されたり漏えいしたりしないよう安全に管理される
2. 一定時間アイドル状態が続いたセッションは切るなどの管理が行われる
3. アプリケーションプロトコルの動作を壊さない

（3） セキュアなアプリケーション管理

1. 使わせるアプリケーションを限定できる
2. アプリケーションの起動条件をサーバ側で設定、変更できる

（4） セキュアなシステム管理

1. OS、システム環境が要さい化されている
2. セキュリティパッチがすぐ適用できるようになっている
3. 不必要なサービスを起動していない

　しかしながら、上記に並べた項目は一例にすぎない。ユーザー管理、セッション管理、アプリケーション管理、アクセス制御が確実に行われることはSSL-VPNの得意とすることであり、VPNが動作するプラットフォームの要さい化は十分以上に行われなければならない。またこの状態は常に監視される必要がある。

1/3

次（実現しやすいこと）へ

Index
特集：使い方が見えた！ これからが本番、SSL-VPN（後編）
	意外と多くの仮説を信じてセキュリティは実行、管理されてる
	SSLを使うことでとても実現しやすいことがある！
	ファイアウォールとの関係から知る効果的な適用対象

関連記事

特集：マネージド・サービスの選び方　話題が先行するマネージドサービス。ユーザーはますます、どこまでアウトソースするかを見極めることが重要になってくる 前編　「SSL-VPN」の登場でアウトソースが変わる 中編　IPセントレックスのメリットはどこまで創出できるのか？ インフラソリューションはこう選べ 連載　最適インフラビルダーからの提言　ブームのVPNと広域イーサネットサービス。気になるコストの算出方法やネットワーク構成の注意点を解き明かす 第1回　専用線からVPNへの移行、選択に自信あり？ 第2回　外出先からリモートアクセスVPN、どれが得 第3回　専用線二重化と同レベルの安心をVPNで得る 第4回　VPNのアクセス回線を二重化する 第5回　VPNでQoSの確保は難しいのか 特集：ネットワーク設計の定石　具体的にA社の社内ネットワークを基にしながら、LANの設計に必要な状況調査と利用計画の方法、設計と構築のポイントを説明する 前編　どのように社内LANを設計するのか 中編　自社にあったWANサービス、選定のポイントは 後編　WAN接続ポートでの帯域制御とは？

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）