常時HTTPS化の落とし穴＜解決編＞

前回は「HTTPSを使うとロードバランサやWAF・IPSといった、通信内容を見て判断したり、内容を書き換えたりする機器が利用できなくなる」という問題について紹介しました。今回はその解決編です。 ロードバランサが暗号を解いてWebサーバへ HTTPSでは送信する側と受信する側でその場限りの暗号鍵を交換し、その鍵を使うことで途中の機器が内容を読み取れないようにします。通常、この送信する側と受信する側とはWebサーバとクライアント（PCやスマートフォン）のことを指しますが、必ずしもそうとは限りません。まずはロードバランサの場合を考えます。 ロードバランサ Webサーバとブラウザの間にいるロードバランサが暗号化された内容を読み取れないのは、暗号通信がWebサーバとブラウザの間で取り決めた暗号鍵を使っているからです。ならば、ロードバランサとブラウザの間で暗号鍵を取り決めればどうでしょうか。ロードバランサは暗号化された内容をきちんと読み取って書き換えることができるようになり、複数のWebサーバに適切に通信を割り振ることができるようになります。 このような機能のことを「SSLアクセラレーション」や「SSLターミネーション（終端）」と言い、それが有効な状態を一般に「ロードバランサ終端」、つまり、暗号通信の終端がロードバランサになっている、と言います。それに対して「サーバ終端」という言い方もあります。 ロードバランサ終端にした場合は通常、ロードバランサとWebサーバ間は暗号化されていないHTTPで通信します。Webサーバは暗号化・復号化処理をしなくて済むので、負荷を抑えられるというメリットもあります。全ページHTTPS化を想定せずに構築したサーバの場合は大きな利点となるでしょう。 ロードバランサ自身の負荷が気になるところですが、IDCフロンティアのロードバランササービスILBは負荷が高くなったときに自動的に拡張するオートスケール機能を持っています。このようなサービスを利用すればHTTPS化による負荷のことをほとんど考慮しなくてすみます。 WAF（Web Application Firewall） WAFの場合も同様に、SSLアクセラレーション機能を持つ機器の後ろに置くことで暗号化されていない通信を診断することができるようになります。SiteGuard LiteのようなWebサーバにインストールするWAFは内部的に復号化された後に置かれているため、サーバ終端でも問題なく診断できます。 ScutumのようにSaaSで提供されるWAFの場合はWAFとWebサーバの間にインターネットがあります。そのため、ブラウザとWAFの間で暗号通信を行うとともに、WAFとWebサーバの間でも暗号通信を行うようにします。つまり、1度の通信で2回の暗号・復号処理が入ることになります。 IPS（Intrusion Prevention System / 侵入防止システム） IPSは少し特殊です。そもそもIPSはWebに特化したものではなく、さまざまな通信プロコトルの攻撃コードをチェックするものですので、ロードバランサの後ろなどではなく、なるべくインターネットに近い側に置いて幅広く診断を行うことが望ましいと言えます。 IPSの場合はWAFと併用し、HTTPSとそれ以外で役割を分けるのがよいでしょう。 なお、文中「SSL」という言葉が出てきましたが、SSLはぜい弱性があるために現在では新しい規格である「TLS」に置き換わっています。しかし、慣習的に「SSL証明書」「SSLアクセラレーション」のような使われ方は続いているようです。すでにファミコンの雑誌ではなくなっている「ファミ通」のように、「SSL」という名前だけ残っていくのかもしれません。 関連リンク ILB（Infinite Load Balancer）（IDCF Cloud） SiteGuard Lite（ホスト型）（JP-Secure） Scutum（クラウド型WAFサービス【スキュータム】） 関連コラム 常時HTTPS化の落とし穴＜問題編＞...