SSL VPN と OpenVPN：多くの嘘とわずかな真実（2/4 ページ）

[Charlie-Hosner，japan.linux.com]

従来のVPNとSSL VPN

　従来のVPNはエンド・ポイントが信頼できることを前提としており、サーバもクライアントも高い信頼性を持つマシンである（そう願いたい）。どちらも担当の管理者がVPNコンポーネントを手ずからインストールし、企業のセキュリティ・ポリシーが適用されているマシンなのである。さらに、双方のデバイスには認証の証明書がプレインストールされているため各エンド・ポイントは通信相手の認証が可能で、これによって相手が信頼できることを高い確率で確認できる。

　SSL VPNでは、ユーザーは手近にあるマシンから中央VPNに接続できる。自宅にあるマシンからでも、子供のノート・パソコンからでも、喫茶店にあるマシンからでも、東欧なら公衆マシンからでも接続可能である。このことから、2つの重大な問題が発生する。第1に、トラスト・モデルが崩壊する。サーバとクライアントは最早あらかじめ設定されたトラスト関係を持たず、実行時に何らかの方法で関係を築く必要がある。1024ビットRSAキーを覚えられるユーザーはともかくとして、我々一般人はパスワードを使うしかない。かくして、Man in the Middle攻撃のための道が大きく開かれるのである。この攻撃法は十分に開発が進んでおり、最低の技術しか持たないスクリプト・キッズでさえ実行可能である。したがって、SSL VPNで交換した情報は、すべて、攻撃者によって復号されかねない。しかも、こうした盗聴を検出するのは極めて困難である。

　もう1つの問題は、ユーザーが接続に使うマシンが企業の厳しい（そう願いたい）セキュリティ・ポリシーの管理下にはないことである。ユーザーが偽物（Man in the Middle）ではなく本当のサーバとSSLセッションを開始できたとしても、入出力は正体不明のマシン上で行われるのであり、そのマシンの管理者はコンピュータのセキュリティよりもカフェラテを作る方が得意かもしれないのである。

　接続に使った公衆マシンが攻撃者の配下にあれば、キーストローク・ロガーやリモート管理ツールが仕掛けられていて、我らが攻撃者はパスワードを盗み、セッションで交わされたすべてのデータを収集し、機密情報を扱う画面を見ることさえできるだろう。セキュリティは鎖のようなものであり、最も弱い輪の強度が全体の強度になる。「クライアントのないVPN」では、最も弱い輪は、どこにあるとも知れぬマシンなのである。

　セキュリティの不確かなマシンからユーザーが接続する際のリスクを少しでも軽減するために、接続しようとしているクライアント・マシンがウイルス 対策とファイアウォールを有効にしていることを確認するオプションがついているシステムがある。Bruce Schneier氏なら「Security Theatre」―― セキュリティの幻想を生み出すだけで実際には何らセキュリティ上の効果を持たないもの――だと言いそうである。その種のシステムは、マシンがウイルス 対策を講じファイアウォールを設置しているかどうかを一体どうやって調べようというのだろうか。もちろん、クライアント・マシンに尋ねるのである。これは、犯罪者に君は犯罪者かと尋ねるようなものだ。誰かに自身を検証するよう求めるのは無意味なこと。これはセキュリティのイロハである。それだけではない。攻撃者にマシンをクラックして最初にしたことを尋ねてみるとよい。おそらく、「システムをアップデートしてセキュリティを高め、ファイアウォールを有効にして、他の攻撃者に煩わされないようにした」と答えるだろう。

　IPsecでは、ユーザーはあらかじめ認可されたマシンからしか接続できないが、そうしたマシンは信頼でき認証可能な既知のエンドポイントであるという利点がある。これに対して、昨今登場したSSL VPNでは、ユーザーはさまざまなマシンから接続できるが、そのいずれもが、あらかじめ設定されたものでさえ、Man in the Middle攻撃から安全ではない。文句を言われないためだけに、この問題を解決するための証明書をクライアント・マシンにインストールするオプションを提供するシステムがある。まるでクライアント・ソフトウェアをインストールするかのように聞こえるが、証明書の追加はデフォルト構成でもないし推奨構成にもなっていない。システムを箱から取り出した時点でセキュリティが覚束ないのであれば、運用状態でも同様の可能性が高い――誰もがセキュリティの専門家ではなく、構成の選択がもたらす微妙な違いを理解しているとは限らないからである。

　SSL VPNで、わたしが問題だと考える点はもう一つある。複雑さの増大である。IPsecから移行するとすれば、その理由はSSL VPNのほうが簡潔だからである。ところが、SSL VPNは、今や、複雑なアクセス制御システム、入り組んだルーティング機能、多くのポート・フォワーディング、アプリケーション・プロキシを含み、さらにはファイル共有機能まである。こうした機能のうち認可とルーティングはリモート・アクセス・ソリューションに必要だが、他の多くはVPNとしては過大か、あるいは相応しくない。「あらゆる機能をあらゆる人に」といった類のシステムを避けるのは、一般にそうしたシステムは正しく動かず、ハッカーの触手を集めやすいからである。

　ファイル・サーバのことであれば、少々のことには目をつぶろう。しかし、最も本質的なセキュリティに関するものについては譲るわけにはいかない。だからこそ、VPNやファイアウォールやルーティングやWebサービスや電子メール・サービスなどには、専用マシンを当てるのである。ところが、多くのSSL VPNのベンダーは、システム・セキュリティを損ないかねないほど多くのオプションがあった、かつての環境へと戻そうとしているのである。「安全でない接続を許す」というチェックボックスがある製品すらあるのだ。何故こんなオプションがVPNデバイスに必要なのだろうか。

　以上の分析はアーキテクチャに基づいたものであり、SSL/TLSの実装法については考慮していない。わたしとしてはメーカー（Cisco、 Checkpoint、Juniper）は機密システムの構築に熟達していると言いたいところだが、アーキテクチャの肝心な点が欠落しているという事実から、暗号化だけが最善のものとは思えない。暗号化は正しく行うのが難しい。今年初めのbroken IPsec implementationsというニュースをご存じだろうか。暗号化の後にHMACを計算すべきなのに、その逆にしていたのである。暗号化は、個々の要素の適用順序というような簡単なことを誤るだけでセキュリティが崩壊してしまうことがあるのである。事実は、時間が、そしてリバース・エンジニアリングが明らかにするだろう。

　ほとんどのSSL VPNが犯した根本的誤りは、アーキテクチャを変更して、最高度のセキュリティを提供するために必要なトラスト・モデルを壊してしまったことである。しかし、この最高度のセキュリティこそ、ほとんどの人々がVPNという名称に期待するものなのである。セキュリティは鎖のようなものであり、全システムのセキュリティは最も弱い輪の強度にかかっている。クライアントが安全でないのなら、全システムも同じように安全ではない。標準的なSSL VPN製品は、クライアント・マシンのセキュリティ要件を大きく落とすことを代償にして、いかなるデバイスからもVPNを使えるという柔軟性を得たのである。

次ページ：後編：使えるSSL VPN