SSL VPN と OpenVPN：多くの嘘とわずかな真実
SSL VPN市場は、ここ5年、活況を呈しているが、その裏には従来のVPN技術への不満がある。つまり、Point-to-Point Tunneling Protocol（PPTP）にセキュリティ上の問題があることと、IP Security（IPsec）標準が複雑でOSに食い込んでいることが嫌われたのである。一方のSSL VPNはセキュリティが強固で使いやすく堅牢であり、これにより従来技術は影が薄くなったと主張している。私は、こうした主張を聞くにつけ、眉をしかめざるをえない。そして、事実を指摘すべきだと考えたのである。
前編：SSL VPNの問題点成熟したセキュリティ技術（SSL/TLSなど）を利用している場合、システムのセキュリティはゼロ・サム・ゲームになりがちだ。SSL VPNが新しいパラダイムであるのはそのとおりだが、アーキテクチャに新たな機能を追加すれば、まず間違いなくセキュリティが犠牲になる。もちろん、わずかな利点を絞り出すことはできるだろう。しかし、セキュリティを犠牲にせずに機能を大きく追加したという話は、眉に唾を塗って聞くべきである。機能とセキュリティの両面を同時に改善することは不可能ではない。実際、後ほど紹介するOpenVPNという実例がある。しかし、そうした両得の主張の多くは幻以外の何物でもなく、その背後にはマーケティングのための策略が隠れているのである。
SSL VPNのアーキテクチャ上の主な利点は、IPsecの複雑さをなくし、暗号化層に簡潔で十分な実績のあるSSL/TLS構造を導入した点にある。これについては何ら問題はない。実際、IPsecは、以下に述べるように、さまざまな理由から効果的に使うのが難しいプロトコルなのだ。
問題点の一つは、IPsecで設定可能な構成が多すぎること。しかも、その中にはアーキテクチャが安全ではなくなってしまうものがあるのだ。IPsecの設定オプションと構造的コンポーネントの多さは、「複雑は安全の敵」という格言を絵に描いたようなものである。
2つめの問題点は、IPsecが本質的にOSカーネルと密接に結びつく必要があること。OSとの干渉は、いかなるアプリケーションにとっても好ましいことではない。ましてや、決定的に重要なセキュリティ・コンポーネントの場合は尚更である。安全で可用性の高いシステムを作るためにはカーネル・スペースとの干渉を可能な限り避ける必要があるということは、Multicsの時代からよく知られていることである。アプリケーションがカーネル・スペースと干渉する場合、一般に、アプリケーションの障害が全システムの崩壊に繋がるからである。ましてや、セキュリティ・コードがカーネル・スペースと干渉していれば、セキュリティの枠組み全体がたった1つの欠陥によって攻撃に屈する可能性がある。そして、カーネルと結合したコンポーネントの陥落は、そのままrootアクセスを奪われることに等しい。IPsec VPNはカーネル・スペース内に実装される。SSL VPNはそうではない。したがって、この点においてはSSL VPNはなかなかに賢い発想である。
しかし、現実には、この利点は商売気に利用されているだけである。SSL VPNの中にはこうした利点を現に活用しているものもあるが、ほとんどは一歩前進三歩後退の状態にある。VPNで重要となるアーキテクチャ上の要件の多くがなおざりにされているからである。弱点は主として「クライアント（ソフトウェア）のないVPN」と言われている構成に起因する。
従来のVPNの場合、サーバー上で中央VPNソフトウェアを動かし、各クライアントはローカル・アプリケーションをインストールして拡張ネットワークに参加する。このクライアント・アプリケーションは、あらかじめ管理者がマシンごとにインストールし設定しておく。ユーザーは、前からあったマシンを使って接続しようとしても接続することはできない。あらかじめ設定されたマシンから接続するしかないのである。こうした環境で誰もが思いつく改善点は、クライアントはあらかじめ設定しておくべしという独裁体制を排し、どのマシンからでもVPNセッションを開始できるようにして、虐げられしユーザーを解放することである。素人目には格好良く見えるだろうが、これがセキュリティ上意味することは重大である。
安全な通信は、双方の状況を把握することなしにはありえない。ユーザーのマシンにクライアント・アプリケーションのプレインストールを求めることは、この要件を満たす一助となるのである。クライアント・アプリケーションがないということは、盗聴はありえないがボタンがなく勝手にデタラメにダイヤルする携帯電話機のようなものである。エンド・ツー・エンドのリンクの暗号化は保証されていても、電話が誰に繋がるかわからない。これが安全だと言えるだろうか。
従来のVPNとSSL VPN
従来のVPNはエンド・ポイントが信頼できることを前提としており、サーバーもクライアントも高い信頼性を持つマシンである（そう願いたい）。どちらも担当の管理者がVPNコンポーネントを手ずからインストールし、企業のセキュリティ・ポリシーが適用されているマシンなのである。さらに、双方のデバイスには認証の証明書がプレインストールされているため各エンド・ポイントは通信相手の認証が可能で、これによって相手が信頼できることを高い確率で確認することができる。
SSL VPNでは、ユーザーは手近にあるマシンから中央VPNに接続することができる。自宅にあるマシンからでも、子供のノート・パソコンからでも、喫茶店にあるマシンからでも、東欧なら公衆マシンからでも接続可能である。このことから、2つの重大な問題が発生する。第1に、トラスト・モデルが崩壊する。サーバーとクライアントは最早あらかじめ設定されたトラスト関係を持たず、実行時に何らかの方法で関係を築く必要がある。1024ビットRSAキーを覚えられるユーザーはともかくとして、我々一般人はパスワードを使うしかない。かくして、Man in the Middle攻撃のための道が大きく開かれるのである。この攻撃法は十分に開発が進んでおり、最低の技術しか持たないスクリプト・キッズでさえ実行可能である。したがって、SSL VPNで交換した情報は、すべて、攻撃者によって復号されかねない。しかも、こうした盗聴を検出するのは極めて困難である。
もう一つの問題は、ユーザーが接続に使うマシンが企業の厳しい（そう願いたい）セキュリティ・ポリシーの管理下にはないことである。ユーザーが偽物（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
OpenS/WANのインストールと設定に数日を潰した私は、他の製品を探すことにした。VPNを立ち上げるのにカーネルに手を加えるという微妙な操作が必要だというのは、とても真っ当なこととは思えなかったのだ。作業中、私は「こんなはずはない」と言い続けたものだ。
凄まじいインストール手順（Oracle）を何とかやり終えた人なら、Apacheのような複雑なソフトウェアのインストールが./configure; make; make installでできるというのに、この手順は何故これ程にもおぞましいのかと誰もが思うだろう。このときの私も、同じ思いだった。もちろん、IPsec VPNがカーネルと結合しており、一方のApacheはユーザー・スペース・デーモンとして動いていることは知っている。しかし、ユーザーとしても管理者としても、そんなことはどうでもよいことだ。ただ、簡単にインストールできて、壊れにくく、設定がわかりやすい製品がほしいのである。必ずもっとよい製品があるはずだと確信して探していたところ、OpenVPNを見つけることができた。
私がOpenVPNに出会ったのは、そのWindows用クライアントがリリースされバージョン2.0の完成を目前にした2004年夏のことだった。このバージョン2.0には、堅牢かつ集中化されたクライアント構成機能と、さらに強力になったトラフィック制御ツールが含まれている。インストールは簡単そうだ。セキュリティには、信頼できる本当のSSL/TLSライブラリが使われている。調べてみる価値はありそうだった。
少し調べてみると、Peter Gutmannの手になる著名なVPN記事が見つかった。記事では、OpenVPNだけを将来性のあるものとし、その他のオープンソースVPNを酷評している。そこで、さらによく調べてみることにした。そして、インストールの手順を見て驚いてしまった。何と./configure; make; make installだったのだ。当たりだ。調べては納得し、納得しては調べる。ついに見つけたのである。IPsec VPNのオープンソース版、同じ機能を備え、追加機能も健全。しかも、従来のVPNで頭痛の種だった、カーネルに食い込むような複雑なところはない。
OpenVPNの概要
OpenVPN はSSL/TLSライブラリと構造体を使って暗号化層を管理している。二重認証SSL/TLS鍵共有/鍵交換はIPsecのInternet Key Exchange（IKE）とほぼ同等で、IPsecのEncapsulating Security Payload（ESP）と類似のトンネル・システムを実装している。我らが尊敬すべき基準と同等かそれ以上である。OpenVPNで利用可能な暗号化アルゴリズムには、お馴染みかつ贔屓の重量級選手がすべて顔を揃えている。デフォルトは、RSA認証、Diffie-Hellman鍵共有、HMAC-SHA1整合性チェック、明示的IV、CBCモードのBlowfishを使った対称暗号である。そして、私の見るところ、これらは極めて安定している。
素人にとって、これは何を意味するのだろうか。それは、OpenVPNが、最低でも、最良のIPsec実装に見いだされるセキュリティ・レベルのトンネルを作り、それを維持できるということである。これは重要な点だ。多くの人が長い間IPsecで我慢してきたのにはわけがある。それは、IPsecが信頼できないネットワーク上に信頼できるデバイス・ツー・デバイス通信を実現してくれるからである。OpenVPNは、それをさらに進化させたのだ。
ここで、先へ進む前に少し時間をいただきたい。一点、はっきりさせておきたいことがあるのだ。「SSL VPN」と称する製品はどれも本当のVPNではなく、標準のWebブラウザを使ったアクセスもどきにすぎないという大変な誤解を解いておきたいのだ。IPsecは、通常「ネットワーク拡張」と呼ばれているものを提供する。これは文字通りの意味であり、プライベート・ネットワークを拡張して、そのローカル・ネットワークの制御の及ばないマシンをも包含する機能である。そのマシンが社内のLANに到達するには信頼できないネットワークを経由する必要があるだろう。これを実現し健全なトラスト・モデルを維持するために、IPsec VPNは管理者がクライアント・コンポーネントを拡張ネットワークに参加する必要のあるマシンにインストールすることを求める。
OpenVPNのアーキテクチャも同じである。違いはない。仕掛けもない。OpenVPNはIPsecと全く同じように、クライアントのインストールを必要とする。そして、これは良いことなのだ。OpenVPNの場合は、クライアントを容易に設定できるように、Windows、Solaris、Linux、BSD、MacOSX用にインストールの容易なクライアントを提供している（CiscoやCheckpointのVPNの場合と比べてみよ！）。それはともかくとして、ここで肝心な点は、OpenVPNのネットワーク拡張アーキテクチャがIPsecと全く同じだということである。
これに対して、昨今登場したいわゆるSSL VPNの多くは「クライアント（ソフトウェア）がない」アーキテクチャであると喧伝し、ごく普通のWebブラウザを使ってVPNにアクセスできると主張する。これはすでに述べたように深刻なセキュリティ問題を抱えているだけでなく、機能にも制約を課す。こうした製品の多くはポートをフォワーディングしているだけか、Webプロキシか、プロトコルを毎回「Web化」しているだけだ。真のネットワーク拡張ではないのである。
プロトコルを1回ごとに処理するのがあまり堅牢なソリューションでないことは、誰にも直ぐにわかることだ。新しい優れたプロトコルが登場してVPNで使いたい場合を考えればよい。IPsecもOpenVPNもネットワーク拡張をリンク・レベルで扱う。したがって、すべてのプロトコル、すべてのトラフィックがVPNトンネルを通過できるのである。
OpenVPNで本当に驚くべき点は、そのデザイン・パラダイムの変更にある。何と、OpenVPNはカーネル・モジュールではなく、ユーザー・スペース・デーモンとして実装されているのである。ネットワーク・インタフェース・アクセスは仮想TAP/TUNドライバを使って管理される。このドライバは現代のオペレーティング・システムではほとんど標準的なものである。
この単純な変更が機能に柔軟性を生み、セキュリティを改善し、かくしてIPsecは埃を被ることになるのである。最も重要なオプションは2つある。サーバーの特権をユーザーnobodyにまで引き下げられること、そしてサーバー・デーモンをchrootするオプションである。どちらも最小権限の原則という我々のセキュリティ理念に沿うものである。
IPsecプロセスの場合、これを攻略すれば自由に使えるrootシェルが手に入る。攻撃者にとって、悪い取引ではあるまい。しかし、OpenVPNの場合は、インスタンスをクラックする方法をたまたま見つけたとしても、ほとんど空同然のディレクトリに入り込める特権のないユーザーが得られるだけである。守備側にとって、これは大きな改善だろう。攻撃者が賢ければ最終的にはこの障壁も突破するだろうが、しばらくの時間は必要だ。その間に、侵入を検知し対応することができる。IPsecのように攻略後直ちにrootシェルを奪われれば、管理者には息継ぐ間もなく、最低レベルの技術しか持たない攻撃者からもシステムを守ることはできない。
ワームへの障壁
OpenVPNが現在提供しているセキュリティ機能に感心しただけではない。非常に興味深い機能も発見した。未知のワームに対する障壁である。「ワーム選好性」という脆弱性をもたらすものは何だろうか。攻撃者側から考えてみよう。攻撃者としては、リモートから攻略できるような脆弱性がほしい。自動化でき効率的に攻撃可能なもの、そしてターゲット・システムへの十分なアクセス・レベルが得られるものがあればOSツールにアクセスして感染を拡大できる。また、同じ構成のマシンが大量に存在し、攻略可能な脆弱性を持っていれば、大規模な攻撃が可能だ。つまり、10台のマシンに感染するワームを書きたい者など誰もいない。それでは割に合わないのである。
OpenVPNの設計者はこの点を考慮し、OpenVPNに偉大なるオプションを与えた。標準的なワーム攻撃を分散させるオプションtls-authである。すべてのVPNクライアントとサーバーは、あるキーを持たなければ他のOpenVPNインスタンスとSSL/TLSハンドシェイクを開始することすらできないが、このオプションでそのキーの割り当てが可能となる。キーはOpenVPN管理ドメインごとに一意的であるため、OpenVPNインスタレーションごとに異なる。したがって、ワームで攻撃するにしても、自動的に攻撃できるほど類似性のあるOpenVPNインスタンスは、200万台のWindows 2000マシンではなく、10台、あるいは50台、せいぜい100台である。もちろん、曰わくのある攻撃を止めることはできない。しかし、自動化されたワーム攻撃は劇的に減少する。
上に述べたセキュリティ制御のほとんどはデフォルトで有効になっているか、インストールの解説書で強く推奨されている。
優れているのは、セキュリティについてばかりではない。すでに述べたように、初期インストールは容易である。設定もわかりやすい。サーバーを制御する設定ファイルは1つ、他のオープンソース製品でお馴染みの形式で記述する。クライアントの構成オプションは、–pushと–pullディレクティブを使って集中制御することもできる。
複数の–remoteディレクティブを用いれば、複数のOpenVPNサーバーによるフェイルオーバー構成が可能。トラフィック制御とサービス品質（QoS）オプションもまた、容易に実装できる。認証法には推奨されているX.509証明書によるものの他、ごく一般的なものがさまざま使える。ユーザー・パスワード、スマート・カード、静的キー設定も、通常レベルから高度なものまで、いろいろなセキュリティ・レベルで利用可能だ。
OpenVPNを調べていて、VPNに相応しく有用な機能を1つ見つけた。ルーティングとアクセス制御のレベルが適当なのである。ほとんどのSSL VPNでは、この機能が高度すぎる。これに対してOpenVPNのルーティング機能は使いやすく、特定のユーザーに割り当てることができる。まだリリースされていないが、2.1ではグループに割り当てることも可能だ。これによって、リモート・アクセスを分割しクライアント・トラフィックを振り分ける柔軟なネットワーク構成が可能になる。
コマンドラインを見ると胃が痛くなる質でOpenVPNを使うのは遠慮したいという向きには、OpenVPN環境のインストールと管理を支援するグラフィック・ツール群が用意されている。My Certificate WizardとOpenVPN GUIはよくできた製品で、コマンドライン・インタフェースという怪物から、か弱い心臓を守ってくれる。OpenVPN Webサイトには、他のグラフィック・ツールも提供されている。
世の中はさまざまだ。中には、定期的にカーネルをコンパイルするのが大好きで、トラブルが発生したら10秒以下で対応すべくマシン・ルームに詰めてVPNマシンのお守りをしている人もいるだろう。そういう人にはIPsecが相応しい。中には、セキュリティはどうでもよく、見栄えのいいリモート・アクセス・ツールがほしいだけの人もいるだろう。そういう人には昨今話題のSSL VPNからいずれかを選ぶとよいだろう。ただし、機密データを扱うような企業の場合は正しい選択ではないだろうが。そうではなく、インテリジェントで管理しやすく堅牢な機能を具備し業界屈指の強力なセキュリティを装備したVPNがほしいのなら、OpenVPNを選択すべきことは明白である。
原文
