HTTPS化におけるSREチームのアプローチ
横田工氏（以下、横田）：私からは「ZOZOTOWN HTTPS化におけるSREチームのアプローチ」についてお話いたします。
まず簡単に自己紹介をさせていただきます。
私は株式会社ZOZOテクノロジーズ開発部のSREチーム所属の横田工と申します。2013年に株式会社スタートトゥデイ、現在の株式会社ZOZOに入社しました。
その後ZOZOテクノロジーズに転籍し、現在はECサイトのインフラ担当者として、主にオンプレミス環境、サーバネットワークの運用を担当をしております。
2019年3月にZOZOTOWNはHTTPS化を行いました。HTTPS化の裏でSSL/TLSの向上、そしてHTTPS化に耐えうるインフラ構成への変更を行いました。
本日私からお話させていただく内容は、オンプレミスの話がメインです。
突然ですが、みなさんはなぜ運営サイトをHTTPS化するのでしょうか？ 思いつく限りでざっと挙げてみました。
各ブラウザで「保護されていない通信」と表示されてページランクダウンにつながる。もしくはHTTP/2などを使ってサイトを高速化したい。HTTP/2もサイトのSSL化は必須です。SEO優遇を受けたいということで、SEOチームはこういったところを気にするかもしれません。あとは、アクセス解析ですね。
ざっと挙げただけでもメリットが存在するのですが、私たちSREチームの一番の目的は「ユーザーに安心してサイトをご利用いただくこと」と定義しました。
当然のことではありますが、今日はこのあたりをお話させていただければと思います。
SSL通信のおさらい
後続の話をするにあたって、簡単にSSL通信のおさらいをさせてください。
SSL通信の中でも「Connection/Key Exchange」鍵交換ですね。鍵交換の部分と、それにまつわるアルゴリズムRSAや「Forward Secrecy」、そしてその概念を実現するアルゴリズムECDHE。このあたりをおさらいさせていただきます。
こちらはRSA鍵交換でのハンドシェイクの図を表現しております。まず、クライアントはサーバに通信要求を行います。サーバは証明書と公開鍵をクライアントに渡します。クライアントは共通鍵を生成します。そして、生成した共通鍵をサーバから渡された公開鍵を使って暗号化。そしてそれをサーバに送ります。
サーバは、その公開鍵と対になる自分だけが知る秘密鍵を使って、暗号化された共通鍵を復号化します。一連の流れでクライアントとサーバはお互いに共通鍵を知ることができたので、以降のデータの通信はこの共通鍵を使ってやりとりをします。
先ほどの通信の問題点を少し考えてみたいと思います。最大の問題点は、一定の秘密鍵に頼っていたことです。ユーザとサーバ間の通信を行っているときに、仮に第三者が、今はまだ暗号化されていて解読できないとしても、このデータを盗聴、蓄積していたとします。
そして将来的に何らかの原因で、この秘密鍵をリークしてしまったとします。例えばサーバの破棄が甘くてディスクを抜き取られて、そこから秘密鍵が抜き取られるということがあったとします。この秘密鍵がリークするとそこから共通鍵を求めることができるので、その共通鍵を求められてしまえば、実際にやりとりしたデータがすべて解読されてしまう可能性がありました。
RSAの鍵交換は、このように将来的な安全性までは保障できないという問題点がありました。
そこでこの問題を解消するために生まれた考え方が、Forward Secrecyという考え方です。
先ほどのRSAの鍵交換は、一定の鍵に頼っていることでリスクが存在していました。しかしこのForward Secrecyでは、使い捨ての公開鍵と秘密鍵をサーバとクライアントで保持することで、将来的にもデータが解読される危険性がないという考え方です。
そしてこの鍵交換の仕組みに対応するアルゴリズムはECDHE、もしくはDHEとなっています。このECDHE、DHEなどはあくまで鍵交換の仕組みなので、実際にWebサイトで使うときは証明書と組み合わせてECDHE-RSAなどで使います。使い捨ての鍵を生成することだけあり、SSLの復号機器の負荷はある程度上昇すると言われています。
簡単ですが、こちらをSSL通信のおさらいとします。
これまでのZOZOTOWN
ZOZOTOWNの話に戻りますが、サイトのフルSSL化前、ZOZOTOWNにももちろんHTTPSのページは存在しておりましたが、先ほど説明させていただいたようなRSA鍵交換という問題点を抱えておりました。
実際にRSA鍵交換を利用していることを確認します。
こちらはGoogleのデベロッパーツールで見た結果です。Certificate、証明書は問題ありません。リソース、HTTPSページの中にHTTPの要素が混在していると指摘されますが、ここも問題ありません。最後にコネクション。こちらは緑の表示にはなっていません。何やらobsoleteで時代遅れだと記述されています。
もう1つ、確認の際に使用しているものを紹介します。SSL Labsという、SSLページの評価を行ってくれるサイトを見ています。
こちらでは、以前の状態ではKey Exchangeが低得点になっています。ちょっと見えづらいかもしれませんが、下のほうに「Forward Secrecyをサポートしてください」という旨が表示されていました。
このKey Exchangeが起因して、以前のZOZOTOWNのSSL化されたページの評価はB判定となってしまっておりました。
サイトのSSL化が実際に進みだす前に、「まずこのSSL/TLSのアルゴリズムを見直そう！ そして最低限、SSL Labsの評価はA判定まで持っていこう！」と決心しました。このあたりは意外と成果が見えづらいポイントでもありますが、このSSL Labsの評価もモチベーションにするとがんばれると思いました。
見直しとして実施したのは2つです。
まず、鍵交換の優先順位をRSAからECDHE方式を上位にすること。後は別の問題にはなりますが、かなり多様なCiphersを許可していたので、これを一緒に精査しました。実際ほぼ利用のないCiphersを持っている状態でしたので、仮にそのあまり利用のないCiphersで脆弱性が出てきたときに気が付くことができるのかという懸念点もありました。
このあたりはSSLの復号ポイントの機器の統計情報を参考に精査していきました。
HTTPS化に耐えうるインフラへの変更
というわけで、ECDHEの鍵交換の仕組みを使うことを前提にインフラの構成の見直しを行うことを決心します。
こちらは、構成の変更前のシステムの概要図です。
トラフィックの流れを見ていこうと思います。まずはじめにファイアウォール兼ロードバランサーで通信を受け、適切なTCPポート宛ての通信と判断されたトラフィックは、ここでSSLのアクセラレーションが行われます。この真ん中の鍵のマークはSSLの復号ポイントであることを示しています。
その後、復号化された通信は後段のWAFへトラフィックが渡されます。そして、このWAF上でL7レベルの検疫を行います。WAFで正常なトラフィックと判断されたものに関しては、前段のファイアウォール兼ロードバランサーへ折り返し通信が行われます。そして、ここから各Webサーバへの負荷分散、ロードバランスが行われていきます。
この図でもわかりますが、前段のファイアウォール兼ロードバランサーが複数回このトラフィックのフローの中に登場していたので当時の懸念点がこちらになります。
当時はファイアウォール兼ロードバランサーの役割が多かったことで、イベント時、アクセスが集中する時期などは他のネットワーク機器と比べても、このファイアウォール兼ロードバランサーの負荷状況がかなり高いことが気になっていました。仮にこの前段の機器で負荷が上がってハングしてしまうと目も当てられない状態になってしまうので、ここを改善したいという思いがありました。
さらに、この前段の機器が、先ほどからECDHEを使いたいという話をしていましたが、このECDHE系の鍵交換をサポートしているものも、いざ利用したときにカタログスペックよりも大幅に低下した値で限界を迎えてしまうという問題を抱えていたので、RSAに頼らざるを得ないという問題もありました。
以上のことから、SSLの復号ポイントは変更、かつ想定外の負荷が発生した際にはスケールできる構成を取ることにしました。また、SSLの復号ポイントはECDHEの処理に特化したものを採用しようと決めました。
4層構成に変更
このような構成に変更しようとデザインしました。
大きな変更ポイントとしては、先ほどまではファイアウォール兼ロードバランサー、WAF、Webサーバと3層の構成でしたが、4層の構成になっております。こちらも先ほどと同じくトラフィックの流れを見てみたいと思います。
まず、ファイアウォールでトラフィックを受け、適切なポート宛ての通信は後ろのWAFへ、このようにロードバランスされます。ロードバランスということでWAFは複数台の構成となっております。このWAF上でSSLの復号処理が行われます。先ほどまでファイアウォール兼ロードバランサーの前段部分で行われていた復号処理ををWAFに引き渡しました。
仮にSSLの処理やWAFそのものの処理で、機器の負荷が上がってしまったとしても、このWAFを横並びに増設でき、スケールアウトができる構成を取りました。そしてこのWAF上で、さまざまなL7レベルの検疫を行い、正常だと判断されたトラフィックに関しては後段のロードバランサーへ、こちらも先ほどはありませんでしたが、このタイミングで追加しようと決意しました。
この後段のロードバランサーから、各Webサーバにロードバランスが行われるという構成を取ろうと決めました。この構成にすることで、これまでSSLの復号処理を行っていたファイアウォール兼ロードバランサーの負荷状況を後段ににロードバランサー専用のものを入れることで分散できる状態になります。
そして、WAF自体もスケールアウトできる構成になったため、どこか1ヵ所はボトルネックになってしまうという先ほどまで抱えていた問題は解消できたと思います。
もちろん、この構成変更だけで本当に妥当かどうか確認する必要があったので、負荷試験は行いました。SSLの復号ポイントがWAFだったので、より本番に近いトラフィック、リクエスト、Cookie長やWAFでの検知の量などを再現できるようにいろいろやりました。
データセンターの内部だけで完結するように、専用の機械をレンタルしてきて各負荷試験を行いました。この試験を行ったことで、WAFにSSLの復号を任せて、かつECDHE系の鍵交換を行っても問題がないという確信が取れたので、実際に構成変更を実施しました。
構成変更の結果を振り返る
では、構成変更の結果ということで、しばらく時間があいてしまいましたが、2019年3月にサイトがHTTPS化を行われまして、その時の負荷に関してはほぼ想定通りの値を出しておりました。負荷試験をやっていたことで精神的にも余裕がある状態で当日を迎えることができました。
もう1つ負荷試験をやってよかったことは、今後サイトがどの程度成長を迎えたときに、どのくらいまでなら耐えられるかというめどができた点です。
ECDHEを使いたいという話をしていましたが、こちらももちろん実施しました。サイトのHTTPS化対応前にも変更しております。
結果的に、対応前までGoogleデベロッパーツールでコネクションのところを指摘されていましたが、これも全部緑の状態にでき、かつSSL Labsの評価もA判定まで持っていくことができました。
最後に、今回サイトがHTTPS化できたことによって、いろいろなことができる環境の土台ができたと思っております。なので今後も、継続してセキュアな環境づくりを会社として進めていきます。例えばTLS1.0、1.1の廃止やサイト高速化に向けてHTTP/2をやりたいという打診があったとき、すぐに動けるようにSREチームとしても準備していきたいと思っています。
本日はご清聴いただきありがとうございました。
