Bluecoat SGのプロキシ認証と属性によるアクセス制御

(1)認証の動作

プロキシ認証を有効にすると、クライアント端末からHTTP GET要求があると、プロキシサーバは407 Proxy Authentication Requiredを応答する。407を受け取ったクライアントは認証ポップアップを表示し、利用者によって入力された値をHTTPヘッダに含めて再度HTTP GET要求を送信する。Basic認証を用いた場合だと、このパスワードは平文でプロキシサーバに送られるが、それが許容できるかどうかは社内の接続なので状況による。

一度ユーザ認証が行われると、ブラウザは資格情報をキャッシュしてHTTP GETを行う度にキャッシュしている認証情報をHTTPヘッダに含めて送信する。よって暗号化されていないBasic認証の場合だとパケットキャプチャを見る度に不安な気分になる。Base64エンコードはされているので、パスワードがそのまま見えるわけではないが、暗号化されているわけではない。

プロキシサーバは認証情報を受け取ると認証サーバに問い合わせを行う。Basic認証の場合はLDAPで認証サーバに問い合わせを行う。LDAPサーバは2台まで登録でき、冗長化される。HTTP GETのたびにLDAPに問い合わせに行くのは負荷が高いため、Bluecoatはサロゲートの設定がある。一度認証されると、サロゲートで設定したタイミングまではLDAPへの問い合わせは行われない。TCP単位でサロゲートするか、IP単位でサロゲートするか選択できるが、基本的にはTCP単位とする。IP単位にしてしまうと、下位でNAPTしているような環境では、認証されていないユーザが認証なしに接続できてしまう可能性があるためだ。

認証モードもいくつか選択ができるがCookieを選択するのは注意が必要だ。HTTPSの場合にプロキシサーバではCookieが読めないという理由だが、プロキシサーバで複合化する構成の場合には選択の余地がある。基本的にはデフォルトでよい。デフォルトはTCP単位で認証するというモードとなる。

プロキシサーバでいくら認証モードやサロゲートを設定したところで、利用者から見ると違いがわからないことがある。実際には認証が発生していてもWEBブラウザがキャッシュしている認証情報を自動で送信するため、利用者は気付かないためだ。WEBブラウザを終了させると再度認証ポップアップが出力される。ただし、Windowsの場合は資格情報をOSレベルで保存するため、この機能を無効にしないとOSを再起動しても認証ポップアップが発生しない事態になりえるので注意が必要だ。コントロールパネルから資格情報マネージャを起動して設定を確認できる。

(2)Windows統合認証

Bluecoat SGにはいくつもの認証方法が用意されている。端末がWindows環境であれば認証基盤はActiveDirectory(AD)になる事が多い。Windowsログインに使用しているADでプロキシ認証も行い、かつADに登録しているユーザはプロキシも使えるということであれば、Windows統合認証を利用する事が考えられる。Windows統合認証はNTLM認証と、kerberos認証があり、kerberosのほうがセキュリティは高度だが、Bluecoat SGにおけるkerberos認証の実績はまだ多くないとのことだ。NTLMは既にMSに推奨されていないが、BluecoatはNTLMv2に対応しており、選択できる。

Windows統合認証はアプリケーション側にも設定が必要になる。IEであれば、詳細設定でWindows統合認証を利用するにチェックを入れる必要がある。そもそもWindows統合認証に対応していないアプリケーションを多く利用する環境ではこの認証方式は望ましくない。

(3)属性によるアクセス制御

ユーザ認証を行う場合、ユーザの属性に応じたアクセス制御を行う場合がある。実装としては認証後にプロキシサーバからLDAPを用いて認証サーバに問い合わせを行う。NTLMを使用する場合にはADに登録されているセキュリティグループを参照することになる。LDAPを用いる場合にはどの属性でも参照できる。AD担当者と協議してこの運用はよく検討しなければならない。

具体的な設定はVPMのルールで定義する。Authenticationレイヤで認証レルムを定義し、アクセスレイヤでSourceに認証レルムで定義した認証結果の属性値をセットすればよい。