推さない日記：プロキシ編（その２）

前回のおさらい

前回は多段プロキシ構成の概要と、プロキシ不要論についてご紹介しました。

また、プロキシ不要論に従ってファイアウォールに役割を引き継がせた場合の懸念点の一例として、ハイレイヤの通信内容やログ情報を見ることができなくなる、ということを記載しました。

特定ベンダを推さない日記：プロキシ編（その１）

今回は、結局、プロキシは必要なのか、プロキシを選ぶポイントはなにか、といったことについて書いていきます。

結局、プロキシは必要なのですか？

たとえばHTTP Response codeのエラーコードなどのログが、SOC（Security Operation Center）でログ解析をする際に必須の情報なのか、というと必ずしもそうではありません。あれば見る、という場合が多いのではないでしょうか。

では、上位プロキシは撤廃して、ファイアウォールに機能を引き継がせる形で問題ないのか、というと、私は上位プロキシはあったほうがよい、と考えています。

厳密には、上位プロキシの撤廃に係るコストやリスクのほうが大きいため、撤廃することは現実的には難しいだろう、という考え方です。

ただし、予算を圧迫するURLフィルタリング機能や、性能リソースを圧迫するSSL復号化機能は、ファイアウォールに寄せて、プロキシサーバの負担を軽くする方向で、役割の最適化を検討してみてはいかがでしょうか。（後のほうにも書きますが、性能検証を実施中です！）

プロキシ選びの新発想！

これまでの考え方を踏まえると、プロキシ専用機器（ハードウェア製品やソフトウェア製品）を利用しない、何らかの機器で兼任させてしまう、という構成も有力な選択肢になってくると思います。

その選択肢のひとつにロードバランサがあります。実は、多くのロードバランサはプロキシサーバとしても動作させることが可能です。

ロードバランサは、メールサーバなどの負荷分散で必ず導入することになるかと思いますので、いっそのこと、プロキシサーバとしての役割も兼任させてしまうというのは如何でしょうか。

また、とあるファイアウォールもプロキシサーバ（明示プロキシ）として動作できる機能を持っています。
したがって、とあるファイアウォールに主要な機能をすべて集約してしまうパターンも、特価交渉や製品間連携の観点から有力な選択肢になり得る、と考えています。

そうなると、機器の負荷が気になります！

ファイアウォールやロードバランサが、プロキシ専用機器の代わりになるのか？

私、気になります！

おっさん、気になりましたので、まさにいま、各機器をプロキシサーバとして動かした際の負荷を測定しています。もちろん、ファイアウォールで色々な機能を組み合わせた場合の負荷も測定しています。

この試験結果に基づいて、適切なサイジングができるようになる見込みです。

（もしかしたら、ロードバランサやファイアウォールをプロキシとして使わないほうが良い、という結果になる可能性も当然あります！）

さて、どういう結果になるのでしょうか。
ドキドキしますね。

・・・ですが、残念ながら、検証結果はブログでは公開できないことになっています。

私と同じく、気になります！という方がいらっしゃれば、
お問い合わせフォームか、弊社の担当営業までご連絡ください。