BIG-IP v9 を利用したサイトのセキュア化
はじめに ビジネスやコミュニケーションのツールとしてインターネットの活用が進み、インターネットサイトが様々なシーンで不 可欠な存在となっています。それに伴い、官民を通じてインターネットサイトで重要なデータ、つまり個人情報や顧客 情報が大量に処理されています。コンピュータやネットワークを利用して、こうした重要データの取り扱いは、今後ま すます拡大していくものと予想されています。 個人情報や顧客情報は、その性質上いったん誤った取り扱いをされると、取り返しのつかない被害を及ぼす恐れが あります。法的責任、機会損失など多くの面でビジネスに打撃を与え、多大な規模の損害を招く可能性があります。 実際、顧客情報などの大規模な流出や、個人情報の売買事件が多発し社会問題化しています。 そうした状況の中で、インターネットサイトのセキュリティを高める事が重要な課題になっており、システムに携わる 人々もそのように感じています。 しかし、セキュリティ対策はその他の業務より後回しされがちで、対策が十分行き届いていないのが実情です。 セキュリティ機能の概要 BIG-IP は、長い間ロードバランサとして開発され続け、現在のロードバランサ市場においてその地位は揺るぎ無いも のとなっています。BIG-IP v9 においてもロードバランサ機能が中核を担うテクノロジである事は疑う余地はありませ んが、それに加えてセキュリティ関連の機能が大幅に拡張されています。BIG-IP v9 のセキュリティ機能をリストアッ プしてみましょう。·
ファイアウォール、パケットフィルタリング·
DoS アタック及び SYN フラッド攻撃に対する防御·
SSL ハードウェアアクセラレーション·
拡張クライアント認証·
パケットの無害化·
選択可能なコンテンツの暗号化（Cookie の暗号化、個人情報の暗号化等） ここでは、BIG-IP v9 において特徴的な、SSL ハードウェアアクセラレーション・拡張クライアント認証・パケットの無害 化・選択可能なコンテンツの暗号化について説明していきます。 BIG-IP v9 の特徴的なソリューションについて SSL ハードウェアアクセラレーションSSL（Secure Sockets Layer）とは、ネットワークを介したコンピュータ同士の通信を安全にやり取りするための技術 であり、OSI 参照モデルにおけるセッション層ならびにトランスポート層において機能するプロトコルです。
SSL は、対となる 2 つの鍵を用いることで、やり取りする情報の暗号化と復号化を行う暗号方式を利用しています。こ の暗号システムの関連技術を総称してPKI(Public Key Infrastructure:公開鍵基盤)と呼んでいます。
ピュータ同士の電子商取引の場合、互いに顔を見ながらの直接的なやり取りではないため、回避すべきリスクが存 在します。そのリスクとして、盗聴・なりすまし・改竄・否認が挙げられます。 SSL を利用する事により、先に挙げたリスクを防ぐ事が可能です。ただし、SSL の処理はサーバの CPU に激しい負 荷をかけます。膨大なSSL トラフィックにサーバが耐えられず、サイトがダウンするという事もあります。特別にハード ウェアを追加していない場合、一台のサーバで処理できるSSL セッション数は数十程度でしょう。そのサーバの負荷 を軽減させる為に、従来のBIG-IP においても SSL 通信をハードウェア処理させ、実サーバの SSL 処理に伴う負荷 をオフロードする為のハードウェアチップが搭載されています。BIG-IP v9 で特徴的なのは、そのパフォーマンスで す。
新ハードウェアの開発に伴い、SSL 処理を最大で 15000TPS(Transaction per sec)もの処理を行う事が可能となり ました。このパフォーマンスは、従来のBIG-IP の 10 倍以上に相当するものです。このパフォーマンスを実現可能にし た主な要因は、SSL 通信をハードウェア処理するチップが更新された為です。全ての新しいプラットフォーム(BIG-IP 1500/3400/6400)に、そのチップが搭載されています。 従来のそれと比較して大きく異なる点は、このチップではSSL 通信のバルク処理もハードウェア処理が可能な点で す。これまでは、ハードウェア処理可能なのはSSL 通信において初めのハンドシェーク処理部分のみであり、SSL バ ルク通信の処理部分は汎用のCPU を利用していました。 そのバルク通信部分に関しては、CPU への処理負荷が掛かっていた為、SSL TPS の上限値が制限されてしまって いました。新しいプラットフォームにおいては、その制限が無くなり飛躍的にパフォーマンスが向上しています。また、 SSL に関する処理は全てハードウェアで処理を行う為、汎用 CPU へ与える負荷は一切ありません。 多くのマーケットリサーチ会社が、今後ますますSSL 通信が増えると予想しています。ネットワークに流れる全ての通 信をSSL 化する事が要件であるユーザも存在します。新プラットフォームの SSL の驚異的なパフォーマンスはユー ザに大きなメリットを生むと考えられます。 拡張クライアント認証
BIG-IP v9 に Client Authentication モジュールを追加する事により、クライアントが BIG-IP 上のバーチャルサーバへ アクセスしたタイミングで、外部の認証サーバへクライアントを認証させる機能を実装可能です。次の図をご覧下さ い。
1. クライアントが、BIG-IP 上のバーチャルサーバへアクセスする際に、HTTP Basic 認証が行われます。クラ イアントに対して、ユーザ名とパスワードの入力を促します。
2. クライアントからユーザ名とパスワードを入力されると、それらを利用しバーチャルサーバは、クライアントの 代わりに外部の認証サーバへ認証を行います。デフォルトで対応している認証サーバは、LDAP、
RADIUS、OCSP、TACACS です。その他の認証サーバに関しても PAM(Pluggable Authentication Module)を利用して、柔軟に対応可能です。 3. バーチャルサーバと外部の認証サーバ間で認証が成功した場合のみ、クライアントは負荷分散対象のサ ーバ群へアクセス可能です。認証が失敗した場合は、バーチャルサーバからクライアントに対して、HTTP レスポンスコード401(Authorization Required)が応答され、クライアントに対して再度ユーザ名とパスワー ドの入力を促します。 この拡張クライアント認証モジュールを利用する事により、既存の認証サーバのインフラストラクチャを活用しながら、 簡単に負荷分散対象のサーバ群へのアクセスセキュリティを高める事が可能で、クライアント認証の導入に関わるコ ストを大幅に削減する事が可能です。 パケットの無害化 BIG-IP v9 で進化した iRule を利用して、悪意のあるユーザに対してクラッキングの手掛かりとなるデータを渡さない ようにする事が可能です。 例えば、Web サーバからクライアントに応答される HTTP レスポンスヘッダについて考えて見ましょう。HTTP のレス ポンスヘッダの中に、Server ヘッダと呼ばれるデータが存在します。この Server ヘッダを確認する事により、クライア ントはWeb サーバで使用されているサーバの OS や Web サーバのソフトウェアおよびバージョン等の情報が入手可 能です。実際に、Web サーバからのレスポンスヘッダのデータを確認してみましょう。
HTTP/1.1 200 OK
Date: Mon, 27 Dec 2004 16:30:54 GMT
Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
上記のServer ヘッダを確認する事により、Web サーバのソフトが Apache v1.3.26 であり、OS はディストリビューシ ョンがDebian の Linux、CGI プログラムに PHP を利用していると予測する事が可能です。悪意のあるユーザにとっ ては、この情報をもとにインターネットから脆弱性情報の収集やクラッキングツールを簡単に入手可能で、このサイト
BIG-IP v9 では、iRule でデフォルトで提供されている”sanitize”関数を利用する事で HTTP のレスポンスヘッダを簡 単に削除する事が可能です。 “sanitize”とは日本語では、“無害化する”あるいは”消毒する”などと訳され、悪い部分の毒を抜くといった意味合いの 言葉です。次の図をご覧下さい。 実際に、”sanitize”関数を利用した iRule が次の例です。
when HTTP_RESPONSE {
HTTP::header sanitize "ETag" "Content-Type"
"Connection"
}
このiRule では、”when HTTP_RESPONSE”句を利用する事により、HTTP のレスポンスデータに対してのみ when 句内に含まれるiRuleを適用する事を定義しています。sanitize 関数のパラメータとしてクライアントに渡しても良いヘ ッダを指定します。BIG-IP v9 上では、HTTP のレスポンスヘッダを解析し、パラメータとして渡されたヘッダ以外のヘ ッダを削除した後でクライアントに渡し、クラッキングの手掛かりとなるようなデータを削除可能です。 選択可能なコンテンツの暗号化（Cookie の暗号化、個人情報の暗号化等） BIG-IP v9 の iRule を利用して、サーバからクライアントに渡すコンテンツの暗号化を簡単に実現可能です。 暗号化の対象とするコンテンツの一例として、Web サーバからクライアントブラウザに渡される Cookie を例に挙げ て、暗号化のメリットや実現方法を説明します。
Cookie は元々、米 Netscape Communications が同社の Web ブラウザ｢Netscape Navigator｣の目玉機能として開 発されたものですが、現在はInternet Explorer をはじめとする多くの Web ブラウザで Cookie がサポートされていま す。HTTP はステートレスなプロトコルとして設計されているので、特定のクライアントからの初めてのリクエストなの か、あるいはそれに続くリクエストであるのか等を一切考慮しません。このステートレスである事は、現在利用されて
いる多くのWeb アプリケーションにとって大きな課題となります。インターネットショッピングサイトを例にあげると、通 常、ユーザは①ログイン ②商品を選択し、買い物カゴへ入れる ③決済というステップを踏むのが一般的です。 HTTP プロトコルにおいては、①②③という一連の処理のセッション維持を実現する事ができません。セッション維持 を実現する為に、Web サーバはユーザに対して Cookie と呼ばれる小さなデータを渡し、クライアントからのリクエスト ヘッダ内に一時的に情報を書き込み、それをユーザの識別子として扱う事で、セッション維持を実現します。 Cookie は、現在の多くの Web アプリケーションにおいて、欠かせない存在になっています。しかし、悪意のあるユー ザがこのCookie を改竄する事により、別のユーザへなりすます危険性があります。 Cookie の改竄によって発生する被害は、なりすましに伴うクレジットカード番号の不正利用、機密情報漏洩などの深 刻な被害が想定されます。 HTTPS を利用して、仮にネットワークの盗聴の心配が無いとしても、Cookie の使い方がいい加減であれば、なりす ましの被害にあう危険性があります。具体的には、セッションID としてユーザ ID やメールアドレスをそのまま使用し Cookie として保存するような、いい加減なセッション管理を行っている場合が該当します。いい加減な Cookie の利用 を行っているサイトはまだまだ多いのが現状で、注意が必要です。ここでは、SSL で通信を暗号化する・しないにかか わらず適用できる対策の一つであるCookie の暗号化の説明をします。 既存のアプリケーションで利用しているCookie を暗号化するとなると、Cookie データを取り扱うアプリケーションプロ グラムに変更に加え、更にそれをテストする時間も必要となり、多大なコストが必要になってしまいます。このように多 大なコストの掛かる変更に対してBIG-IP v9 の iRule を利用すれば、既存のアプリケーションに一切変更を加える事 なく、簡単にCookie を暗号化することが可能です。次の図をご覧下さい。 実際に、Cookie を暗号化した iRule が次の例です。
when HTTP_RESPONSE {
# encrypt cookie data
HTTP::cookie encrypt "Name" "Passphrase"
}
when HTTP_REQUEST {
# decrypt cookie data
HTTP::cookie decrypt "Name" "Passphrase"
}
このiRule では、”when HTTP_RESPONSE”句を利用する事により、HTTP のレスポンスデータに対してのみ when 句内に含まれるiRule を適用する事を定義しています。Web サーバからクライアントへの Cookie の受け渡し方法 は、Web サーバに対してクライアントからの HTTP リクエストヘッダ内に Cookie が存在しない場合、Web サーバから クライアントに対するHTTP レスポンスヘッダ内に Set-Cookie ヘッダを加えてクライアントに Cookie を渡します。そ のレスポンスヘッダが、｢HTTP::cookie encrypt "Name" "Passphrase"｣の iRule にて処理されます。HTTP レスポン スヘッダのCookie 部分を解析し、Cookie の名前が”Name”であるものが存在した場合、”Passphrase”(※任意の文 字列を利用可能)を鍵として、Name の値の部分のみを暗号化し(※Cookie の名前部分は暗号化されません)クライ アントに渡します。クライアントのディスクあるいはメモリ上には、暗号化済みCookie が保持されます。そのクライアン トが、同じWeb サーバへアクセスする際には、暗号化済みの Cookie が、HTTP リクエストの Cookie ヘッダ内に含ま れます。
更に、このiRule ではもう一つの when 句である”when HTTP_REQUEST”を利用する事により、HTTP リクエストデ ータに対して、このwhen 句内に含まれる iRule を適用する事を定義しています。
ここで、クライアントからのHTTP リクエストが HTTP_REQUEST 句の条件に一致しますので、この when 句内に含 まれるiRule が適用されます。
｢HTTP::cookie decrypt "Name" "Passphrase"｣にて、HTTP リクエストヘッダに含まれる Cookie を解析し、名前 が”Name”の物が存在する場合は、”Passphrase”を鍵として復号化を行い Web サーバへ渡します。以上の様に、 BIG-IP の iRule を利用して簡単に Cookie データの暗復号化が可能です。今回は、Web サーバから返されるコンテ ンツの中からCookie を暗号化対象として例に挙げましたが、iRule ではサーバから送られるコンテンツあるいはクラ イアントから送られるコンテンツ全てに対して解析可能で、あらゆるデータを暗号化対象のデータとして選択する事が 可能です。 BIG-IP v9 の iRule について ここで、前述にも登場したBIG-IP v9 の iRule についての概要説明をしておきます。 iRules は、BIG-IP v9 において従来のそれと比べて飛躍的な進化を遂げました。 TCL をベースとした完全なネットワ ークプログラミング言語として生まれ変わっています。iRule は、全ての種類の IP トラフィックとそのペイロードデータ を読み取ることができ、クライアントとサーバ間で流れるトラフィックの全てのセッションフローに対して追跡・解析を行
い、それに基づく処理が可能となっています。組織は、この柔軟でパワフルなiRule 機能を活用して、共通のアプリケ ーションレベルのセキュリティポリシーを設定し、アプリケーションレベルの攻撃と潜在的な危険性をフィルタしてブロ ックする事ができます。管理者はiRule を利用して、パーシステンス（接続維持）、リソースクローキング、コンテンツの 暗号化、コンテンツの書き換え、拒否の対象となるアプリケーショントラフィックを柔軟に定義できます。iRule は、組織 により高度なアプリケーショントラフィック管理を提供します。 まとめ これまで、説明してきたようにBIG-IP v9 では、セキュリティ機能が大幅に拡張されています。今後、更にインターネッ トサイトに対するセキュリティに関心が集まると同時に、個別のセキュリティリスクに対応する為の多数のアプライアン ス製品を配置し、それに伴う導入・運用管理コストが増大してしまうでしょう。BIG-IP v9 のテクノロジを利用すれば、 BIG-IP v9 単体でコストを抑えながら、インターネットサイトのセキュア化が実現可能です。
