もう師走ですね。びっくりです。こんにちは。
食べログでセキュリティをやったり業務改善をやったりしております @ya_po と申します。
この記事では、私が 食べログの古いSSL/TLSを、113ドメイン・72箇所・29社 抜け漏れなく廃止した 顛末をお話させてもらえればと思います。
同じような境遇にいる方の、なにかの参考になれば幸いです。
食べログから古いSSL/TLSを廃止したい
皆様ご存知の通り、POODLE1やBEAST2など、SSL/TLSにまつわる脆弱性は世の中で意外と多く発見されています。
そのためWebセキュリティの界隈では「HTTPSを使ってるだけでは安全とは限らない」と言われて久しい状況です。
Webサービス提供者の私たちとしてもこの状況に対応していく必要があり、食べログではTLS 1.2と安全な暗号スイートだけが利用されるようにしましょう！ ということになりました。
なにをしたか
全体の道のりはこんな感じでした。
本当に色々なことがありましたが、大変だったことと工夫したこと、振り返りについていくつかピックアップしてご紹介します。
大変だったこと
😥 (1) 対応箇所の数がそもそもわかっていなかった
この対応を進めることになった私ですが、プロジェクト冒頭から頭を抱えていました。
というのも、この対応はめちゃデカ食べログの全部で漏れなく実施する必要があるわけですが、漏れなく対応するために必要になる「食べログにアクセスしにくる提携先企業」「食べログが持っている全ドメイン」「食べログから提携先企業にアクセスしにいっているコード箇所」いずれも資料が古かったりそもそもまとまったリストがなかったりという状況でした。
そのため、開始時点では対応する箇所の数すらわからなかったのです。
ドメイン数については、そもそもまとまったリストが存在しない状態でした。そこで、DNSレコードや監視対象などシステムに登録されているものをすべて洗い出して整理したうえで、本番環境・開発用環境のすべてに対してリストアップを実施しました。
食べログにアクセスしにきている提携先のリストについては、既存のリストはあるものの古くなってしまっていました。そこで、それをサービス開発チームと企画部門に依頼して最新化してもらいました。
食べログから提携先にアクセスしにいっている箇所についても同様に既存のリストが古くなってしまっていました。こちらは、コードをgrepして外部APIを叩いている箇所を特定しリストを補完した上で、サービス開発チームに確認してもらって最新のリストを作成しました。
そして最終的に、対応が必要な箇所は下記のとおりであることがわかりました。
- 食べログにアクセスしにくる提携先企業: 29社
- 食べログが持っている全ドメイン: 113ドメイン
- 食べログから提携先企業にアクセスしにいっているコード箇所: 72箇所
...想像はしていましたがやっぱり多い...😭
😥 (2) 影響する利用者の"割合"ばかり見ていて、利用者"数"のことをすっかり忘れていた
古いSSL/TLSを廃止してしまうと、古いブラウザなど新しいSSL/TLSをサポートしていないブラウザを使っている利用者はアクセスできなくなってしまうので、「どれくらいのユーザがアクセスできなくなる可能性があるのか」というのは利用者向けの廃止告知期間を定めるにあたって大事な指標になります。
調査したところ、アクセスできなくなる可能性のあるユーザ割合としては0.2%に満たなかったため、極端に長い期間でなくてもよさそう〜😌 と安心して進めていたのですが、食べログの規模というものを完全に失念しており、スケジュール半ばで、なんとこれが ユーザ数に直すと10万人を超えてしまう ということに気づいたのでした...
影響する人数が多いということは、以下のような問題があるということになります。
- サイトへのアクセス数が大きく減ってしまう
- お金を払って食べログを使ってくれている利用者に対して、契約不履行となるリスクが増加してしまう
- 利用者からの「アクセスできないよ〜」という問い合わせが爆増して、ユーザ対応部門がパンクする
この問題について法務部門やユーザ対応部門と相談した結果、利用者に向けた告知期間を延長し、できるだけ利用者に認知してもらおう、ということになりました。
結果として、もともと想定していた対応期間も合わせて延長せざるを得なくなってしまい、一介の平社員である私が一人で、部長やマネージャーがズラリと並ぶなか訥々と経緯説明することとなりました。
これは私の社会人人生でも指折りのハイプレッシャーな場でした...
😥 (3)パブリッククラウドの対応が意外とめんどくさい
皆さまはあまりご存じないかもしれませんが、食べログの一部サービスはパブリッククラウドを使ってホストされています。
パブリッククラウドというと「運用が楽！」みたいなイメージがあるかと思うのですが、今回の場合は結構手間がかかりました。
というのも、パブリッククラウドのロードバランサは、オンプレミスのロードバランサに比べ、特に暗号スイートの設定においてあまり自由度がないことが普通です。
大抵の場合、暗号スイートの組み合わせが数パターン用意されていて3、そこから選ぶことしかできません。
しかも食べログで利用しているパブリッククラウドはそもそも複数なので、「今回実施したい設定の要件にマッチする設定値が提供されているのか」「要件にマッチさせるためにはどの設定値を設定すればいいのか」という調査を、それぞれのパブリッククラウドに対して一つ一つ実施することになりました。
工夫したこと
🤔 (i) 多数のコードを楽に改修してもらう工夫
大変だったこと😥 (1)に関係する工夫です。
弊社の食べログ部門には複数のサービス開発チームがあり、それぞれが別の機能群の開発業務を担当しています。
一方で私が所属する部署は、複数のサービス開発チームをまたぐ横断的組織でした。
今回の対応にあたっては、食べログから提携先にアクセスしにいっている72箇所それぞれについて、サービス開発チームにコードを改修してもらう必要があります。
彼らはただでさえサービス開発に忙しいので、この数の改修依頼をそのままドカンと出すと困ってしまうだろうな...ということは容易に想像できました。
そこで、横断的組織として、この対応にかかる各サービス開発チームの負担を下げられるように下記対応を行いました。
- 72箇所それぞれを確認して、利用している通信モジュールを特定
- それぞれの通信モジュールでの改修方法を調査
- 調査した改修方法で想定どおり動作するか実機検証
この対応が効いて、サービス開発チームにも**「ここまで調査してくれてるならあとはやるだけっすね」**というお言葉もいただき、ボリュームのわりにサクッと改修いただけたのかなと思います。
🤔 (ii) 多数のドメインを安全に切り替える工夫
これも大変だったこと😥 (1)に関係する工夫です。
この古いSSL/TLSの対応のためには、各ドメインに対するロードバランサの設定をそれぞれ切り替える必要があります。
しかし、113ものドメインの設定を一度に切り替えることは、作業ボリューム的にも、切り戻しが発生するリスク的にも現実的ではありません。
そこで今回は、ドメイン全体を4つにグループ分けし、影響度が低いものから順に切り替える戦略で進めることにしました。
- 影響度 低: 社内管理画面用ドメインなど、限られた利用者だけが利用するドメイン（×2グループ）
- 影響度 中: 一般利用者に提供しているサービスのドメインのうち、利用者がそこまで多くない・別のシステムから利用されていないドメイン
- 影響度 高: 食べログ内部に向けてAPI提供をしている・利用者が多いなど、万が一の場合の影響範囲が大きいドメイン
これにより下記リスクを避け、万一の際にも利用者に影響が及んでしまう可能性を少なくなるよう進めました。
- 一気に切り替えて事故ってしまい、全ドメインに切り戻しが発生😨
- 最初に影響度の大きいものを切り替えたが、実は切り替え手順に誤りがあって事故ってしまい、利用者影響が発生😨
学んだこと
✍️ (A) 立場によって、同じ"利用者割合"に対しての感じ方が違う
大変だったこと😥 (2) に関係することですが、エンジニアの考える「0.2%の利用者」と、企画部門やユーザ対応部門の考える「0.2%の利用者」はかなりイメージが異なるな、と改めて感じました。
エンジニアだと、例えばサーバを増設するときなど「今捌いているトラフィックのxx%増加するから〜」など、割合をベースにして考えることが多いように思います。
一方で、企画部門やユーザ対応部門だとおそらく、「何人のユーザが影響を受けるのだろう・恩恵を受けるのだろう」というような観点で考えることが普段から多いのではないかと想像します。
もちろんそれぞれの部門の業務の特性もありますし、どちらの考え方も大事だと思うのですが、こういう二面があることを認識して場面によって見方を変えることはとても重要なのだなと思いました。
✍️ (B) 構成変更時は、パブリッククラウドだからこそ早めに検討を始めるべき
パブリッククラウドはたしかに運用は楽なのですが、大変だったこと😥 (3) に書いたとおり自由度が制限されている面がある分、パブリッククラウドの仕様を調査したり、場合によっては要件側を調整するコストが余分にかかってきます。
今回は結果的に、いずれのクラウドにも要件にマッチした設定値が見つかったのでよかったのですが、こういった構成変更のような作業の際は「パブリッククラウドだから余裕〜😌」と安心せずに、早め早めに動き出してリスクを早期につぶしておくのがよいなと感じました。
食べログから古いSSL/TLSを廃止した
このすべての障壁を乗り越え、113ドメイン・72箇所・29社に対して古いSSL/TLSの廃止が無事完了しました。
完了までの間には、ここに書ききれないほど本当に色々な面で色々な方にご助力いただいています。
改めて、大きなサービスの面倒をみるというのは大変で難しいなと感じつつも、工夫が活きた箇所、学びがあった箇所も多くありました。
改めて、皆さまのなにかの参考になれば幸いです。
さいごに:
食べログをまた一つ安全にしてしまった...
明日は食べログアドベントカレンダー2021の6日目の記事が公開されるのでご期待ください！