TECHNICAL BRIEF BIG-IP v9 を利用したサイトのセキュア化 はじめにビジネスやコミュニケーションのツールとしてインターネットの活用が進み インターネットサイトが様々なシーンで不可欠な存在となっています それに伴い 官民を通じてインターネットサイトで重要なデータ つまり個人情報や

Transcription

1 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: 公開鍵基盤 ) と呼んでいます インターネットを利用したショッピングや現金の送金は 今では珍しくはありません ただし ネットワークを介したコン F5 Networks Japan K.K. 1

2 ピュータ同士の電子商取引の場合 互いに顔を見ながらの直接的なやり取りではないため 回避すべきリスクが存在します そのリスクとして 盗聴 なりすまし 改竄 否認が挙げられます 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 上のバーチャルサーバへアクセスしたタイミングで 外部の認証サーバへクライアントを認証させる機能を実装可能です 次の図をご覧下さい 拡張クライアント認証の処理概要について説明します F5 Networks Japan K.K. 2

3 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/ OK Date: Mon, 27 Dec :30:54 GMT Server: Apache/ (Unix) Debian GNU/Linux PHP/4.1.2 Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso 上記の Server ヘッダを確認する事により Web サーバのソフトが Apache v であり OS はディストリビューションが Debian の Linux CGI プログラムに PHP を利用していると予測する事が可能です 悪意のあるユーザにとっては この情報をもとにインターネットから脆弱性情報の収集やクラッキングツールを簡単に入手可能で このサイトへの攻撃を行う手掛かりとなってしまいます F5 Networks Japan K.K. 3

4 BIG-IP v9 では irule でデフォルトで提供されている sanitize 関数を利用する事で HTTP のレスポンスヘッダを簡単に削除する事が可能です sanitize とは日本語では 無害化する あるいは 消毒する などと訳され 悪い部分の毒を抜くといった意味合いの言葉です 次の図をご覧下さい 実際に sanitize 関数を利用した irule が次の例です when HTTP_RESPONSE { 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 はステートレスなプロトコルとして設計されているので 特定のクライアントからの初めてのリクエストなのか あるいはそれに続くリクエストであるのか等を一切考慮しません このステートレスである事は 現在利用されて F5 Networks Japan K.K. 4

5 いる多くの Web アプリケーションにとって大きな課題となります インターネットショッピングサイトを例にあげると 通常 ユーザは1ログイン 2 商品を選択し 買い物カゴへ入れる 3 決済というステップを踏むのが一般的です HTTP プロトコルにおいては 123という一連の処理のセッション維持を実現する事ができません セッション維持を実現する為に 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 } encrypt "Name" "Passphrase" F5 Networks Japan K.K. 5

6 when HTTP_REQUEST { # decrypt cookie data } decrypt "Name" "Passphrase" この irule では when HTTP_RESPONSE 句を利用する事により HTTP のレスポンスデータに対してのみ when 句内に含まれる irule を適用する事を定義しています Web サーバからクライアントへの Cookie の受け渡し方法は Web サーバに対してクライアントからの HTTP リクエストヘッダ内に Cookie が存在しない場合 Web サーバからクライアントに対する HTTP レスポンスヘッダ内に Set-Cookie ヘッダを加えてクライアントに 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 が適用されます 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 トラフィックとそのペイロードデータを読み取ることができ クライアントとサーバ間で流れるトラフィックの全てのセッションフローに対して追跡 解析を行 F5 Networks Japan K.K. 6

7 い それに基づく処理が可能となっています 組織は この柔軟でパワフルな irule 機能を活用して 共通のアプリケーションレベルのセキュリティポリシーを設定し アプリケーションレベルの攻撃と潜在的な危険性をフィルタしてブロックする事ができます 管理者は irule を利用して パーシステンス ( 接続維持 ) リソースクローキング コンテンツの暗号化 コンテンツの書き換え 拒否の対象となるアプリケーショントラフィックを柔軟に定義できます irule は 組織により高度なアプリケーショントラフィック管理を提供します まとめこれまで 説明してきたように BIG-IP v9 では セキュリティ機能が大幅に拡張されています 今後 更にインターネットサイトに対するセキュリティに関心が集まると同時に 個別のセキュリティリスクに対応する為の多数のアプライアンス製品を配置し それに伴う導入 運用管理コストが増大してしまうでしょう BIG-IP v9 のテクノロジを利用すれば BIG-IP v9 単体でコストを抑えながら インターネットサイトのセキュア化が実現可能です F5 Networks Japan K.K. 7