「セキュリティ」と一口に言っても、セキュリティベンダーだけではなく、さまざまなベンダーが、DoS攻撃からマルウェアによる攻撃まで、さまざまなサイバー攻撃への対策を行っています。この連載では、ネットワークベンダーから見たセキュリティの現状を、解説していきます。

セキュリティを語る上で外せない"プロキシ"

ネットワーク上において、「プロキシ」は興味深い"デバイス"の1つです。プロキシはキャッシングや負荷分散、アプリケーション セキュリティ、そして、アプリケーションのためのアクセラレーション サービスまでの基盤となっています。開発と運用とネットワークを橋渡しする存在でもあるため、大半のデータセンター アーキテクチャでは、これら3つのグループすべてで、頻繁に使用されています。

しかし、プロキシのすべてが同じアーキテクチャ的方針に基づいて構築されているわけでなく、すべてのプロキシが同じではありません。プロキシの多くはハーフプロキシですが、ハーフプロキシか、一方のフルプロキシであるかによって、「何が行えるか」は異なります。

フルプロキシでは、従来の古いプロキシでは行えなかった、非常に重要な「3つの機能」を果たすことが可能になります。これら3つの機能について検討する前に、まずは「ハーフプロキシとフルプロキシの違いについて」説明したいと思います。

ハーフプロキシ

ハーフプロキシとは、プロキシが"リバース"と"フォワード"のいずれかにおいて、接続をどのように処理するかを表す概念です。基本的には「プロキシがクライアント側においてのみ接続を仲介する」ことを意味します。

したがって、クライアントとアプリケーション間のコミュニケーションのうち、ハーフプロキシはその半分(ハーフ)だけを処理します。ハーフプロキシについて最も重要なことは、「クライアントとサーバの双方で共有するネットワーク スタックは1つのみ」であることです。

フルプロキシ

これに対してフルプロキシは、クライアント側とアプリケーション側で異なる2つのネットワーク スタックを維持し、両方の側についてフルにプロキシ処理を行います。フルプロキシという名称は、この役割から取られたものです。

フルプロキシは、ハーフプロキシと同様に動作設定できますが、本来の価値は「クライアントとサーバの両方に、それぞれ個別に接続できる」ところにあります。

このデュアルスタックによる手法こそ、ネットワーク スタックが1つだけであるハーフプロキシでは不可能な機能を、フルプロキシが実現できる理由です。

3つの重要な機能

フルプロキシは、対象とするプロトコルをすべて理解できます。また、フルプロキシ自身がプロトコルと接続のエンドポイントであり、接続を行うクライアントでもあります。

これはまた、フルプロキシがバッファリングや再送信、TCPオプションなどのネットワーク スタックごとに、自らのTCP接続ふるまいを持つことができることも意味します。フルプロキシを使用した場合には、それぞれの接続が、自らのTCP接続ふるまいを持った独自のものとなります。

フルプロキシに対して接続するクライアントは、フルプロキシがサーバーに対して行う接続とは異なる通信を行うことを意味します。フルプロキシはリクエストとレスポンスの両方をチェックし、ソリューションが許可する場合には、その両方を操作できます。

その1:クライアント側とサーバ側を最適化

フルプロキシはネットワーク スタックと特性を個別に維持できるため、それぞれの側についてそれぞれのニーズに合わせた最適化を行えます。

クライアント側における、特にモバイル機器を対象とする場合の低速、高レイテンシのネットワーク接続を最適化するためのTCP設定は、サーバ側に使用される、高速、低レイテンシのデータセンターへのネットワーク接続を最適化するための設定とは大きく異なると思われます。

フルプロキシはその両方を同時に最適化でき、あらゆる状況において可能な限り最高のパフォーマンスを実現します。ネットワーク スタックを1つしか持たないハーフプロキシでは、平均的な接続を対象として最適化せざるを得ないため、ほとんどの場合どちらか一方のパフォーマンスが最適とは言えない状態になります。

その2:プロトコル ゲートウェイとして機能

プロトコル ゲートウェイは、特にアプリケーション プロトコルのバージョンを変える場合、たとえばHTTP/1からHTTP/2またはSPDYに移行する場合などにおいて、アーキテクトにとって重要なツールとなります。フルプロキシは2種類の互いに異なる接続をそれぞれ維持するため、クライアント側ではHTTP/2を、サーバ(アプリケーション)側ではHTTP/1を受け入れることができます。

これは、フルプロキシがクライアント側の接続を終端し(プロキシがサーバとなる)、サーバに対しては別の接続を開始する(プロキシがクライアントとなる)ためです。クライアント側にどのプロトコルを使用するかによって、サーバ側のプロトコル選択が制約されることはありません。

現実的にフルプロキシは、どのような意味のある(あるいは意味のない)プロトコル変更にも対応可能です。プログラム可能なフルプロキシを使えば、それが仮に一般的ではない(したがって広くサポートされてはいない)ものであってもゲートウェイ構築を行うことができ、その際にプロキシという概念について同じものを一から作る必要もありません。

その3:SSL/TLSを終端

これは技術的に見ればプロトコル ゲートウェイの特殊なケースですが、HTTP/Sが支配的であること(およびSSL EverywhereとEncrypt All The Thingsの重要性)を考慮すれば、単独のケースとして扱うべきだと思います。基本的にはSSL/TLSの終端は、最新および今後のアーキテクチャにおいてきわめて重要な機能の1つとなっています。

なぜならHTTPプロトコル内の情報に基づいてHTTPベースのトラフィック(たとえばREST APIコール)を検証し、その行き先を決定しなければいけませんが、プロキシなしでは暗号化のためその情報の取得が阻まれてしまうからです。SSL/TLSを終端する機能は、プロキシが、クライアントが接続する(かつ最終的には信頼する)安全なエンドポイントとなることを意味します。

また終端とは、プロキシが暗号化された要求を解読し、応答を暗号化する役割を果たすことです。つまりメッセージの内部を「見て」、そのデータをルート決定や負荷分散の判断に使用することを意味します。

フルプロキシでなければ、新しい、また新たに登場するアプリケーション アーキテクチャに向けてプロキシが提供する機能とそのメリットの活用は限られたものとなってしまいます。プロキシについては、それがフルプロキシか否かを確認するようにしてください。

著者プロフィール

伊藤 悠紀夫(いとう ゆきお)
F5ネットワークスジャパン
セールスエンジニアリング本部
プリセールスコンサルタント

UNIXサーバ、ストレージ、シン・クライアントといったインフラエンジニアを経て、F5ネットワークスジャパンへ2012年に入社。
現在はセキュリティ・クラウドをキーワードにイベント講演やハンズオンラボを行い、F5ソリューションの啓蒙活動に奮闘中。
最近はOpenStackやIoTといったキーワードを中心に連携ソリューションを模索している。