はじめまして、キュービックでWordPress一筋のエンジニア()のmikihoです。
今回はWordPressを使う人間にとって、頭痛のタネである脆弱性対応 。
対策についてはさまざまな方が言及してますけど、では実際に脆弱性の検出・対応の管理ってどうすればいいのか、を深掘りして実際に計画・実行までして失敗した話です。
前提
キュービックではWordPressでのメディア作成がメインであり、全社で管理しているメディア数は100近くとなってます。
そしてそれらのメディアたちを一元管理するような仕組みは導入されておらず、かろうじてメディアの一部情報が別ツールによってまとめられている程度でした。
そんな状態なので当然メディアによって導入されているプラグインはバラバラ、本体バージョンもバラバラ状態の無法地帯。
リニューアルのタイミングなどでついでに脆弱性対応を追加で盛り込んだり、本体バージョン・プラグインのバージョンを一斉アップデートしたりと対応はしているものの後手に回りがちというのが正直なところでした。
そもそも、100近いメディアの各々にどういう脆弱性が出ているのかをどうやって管理しろというのか…というのが話の始まりになります。
色々試してみた
管理状態も含め、最初は危機感を持っていた面々によって検知の仕組みをテスト導入したり…というのを繰り返していました。
今回はテスト導入をおこなったサービスごとになんで失敗だったのかを話していきます。
walti.io
Saas型のセキュリティスキャンサービスで、WordPress以外のさまざまなセキュリティスキャンが行えることも魅力のサービスでした。
おそらくこの後に導入したものも含めて、一番機能面で優秀だったサービスだったと思います。
【良かった点】
- WordPressの脆弱性チェッカー（WPScan）に関しては制限がなかった
- スケジューラーを設定することにより定期チェックが自動で行える
- slack連携が行え、検知したらslackへ通知を出せる
- walti.ioのダッシュボード上で管理メディアの一覧化・検知の有無が一目でわかる
【うまくいかなかった点】
- 構成/サーバーの設定によってスムーズにいかず、導入コストが嵩む場合があった
→導入当時、サーバー周りの担当してくださってたチームの人員が少なかったのも理由の一つ - 全メディアを一斉に定期チェックに出したら負荷が高すぎた
- 本格的に体制を整える前にサービスが終了した
Walti.ioは優秀なツールでしたが、実は導入ノウハウ周りの記事は少なかった。
そのため、トラブルが起きた際の解決はどうにか導入担当者が行うしかなく、当時のリソースでは導入コストが高い、と言わざるおえない状態になってしまっていました。
当時はただでさえ構築された環境の統一化が図れていない弊社においては、導入の際に発生したトラブルもメディアごとによって違うこともあったのが頭の痛い問題。
そしてスケジューラーで制御ができるものの、一斉にスキャンを行うとサーバー側の負荷が高まり次々にメディアがダウンするという阿鼻叫喚を生み出したのも問題の一つだったりします。
そして、検知されたところで対応に関してふわっとしか纏まっていなかったのでテスト導入というより、ほんとに「導入しただけ」という状態が長く続いてしまってもいたのです。
そう言った裏事情もありつつ、サービスの終了を理由にwalti.ioは静かに終了しました。
WPScan
そもそもwalti.ioのサービス内にあるWordPressの検知で動いていたのはWPScan。
このWPScanはオープンソースであり、単純にスキャンをさせるだけならば、社内でも可能だしそれを使えないか？という提案から始まった取り組み。
動作させるだけならそこまで難しくないものの、検知した情報を整形・必要情報だけ取り出して…という点に関してはカスタマイズが必要。
その部分に関してはチームメンバーに力を借りてどうにか実現することができました。
これがそれなりにうまくいったのです。
そもそも脆弱性対応のフローはwalti.io導入の本格化の話が出たタイミングで作成してあり、正式に対応フローとして社内公開しよう、と社内の担当者向けに根回しをする手前の段階だったために検知さえできればOKな状態だったのです。
WPScanを月一で行い、結果をCSVで取得、メディアの運用責任者が見慣れたシートの形式に落とし込んで脆弱性の見える化し対応フローのテスト導入を開始。
様子を見ながら開始したテストでしたが2~3ヶ月ほど特に大きいトラブルも起きずに順調に対応が行えておりました。
が、ここでとんでもない問題が発覚。
WPScanの結果の一部が誤検知だったのです。
調べてみたところ、最新の脆弱性のないバージョンに本体・プラグインをアップデートしていても「脆弱性がある」として検知されているメディアがあった。
【調査結果】 WPScanはそもそも、表面上見えるファイル内のバージョン情報を取得していたため、メディアによってバージョン取得がうまくいっていなかった。
つまり君は何を基準に脆弱性を検知していたんだ…？
中身のコードまで調査をしたものの、そもそも現状ではバージョンを完全に取得することは無理、という結論になりました。
【よかった点】
【うまくいかなかった点】
- 本体/プラグインの正確なバージョンが取得できないことによる誤検知
- シートによる管理だったため対応有無の管理は手動だった
誤検知さえなければ、このまま全てが終わるはずでした。
誤検知以外の問題点も、十分解決できる範囲だったので。
まぁ、ある意味普通にバージョンが表に見えてる方が危ないということもあり、むしろバージョン情報が取れなくてよかったわーと笑うしかない状態でした。
（取れたメディアもあったので別途頭を抱える羽目になりましたが）
MainWP
あまりに失敗が続き、一旦距離を置いてまったく別件で進めていたWPをいい感じに一元管理できないか、という方向の案件を進めていました。
実は以前より導入しかけて放置していたMainWPという一元管理を行うプラグインを本格的に導入するかという話がありまして、MainWPの中にある拡張機能についても併せて調査を開始。
そしてMainWPの拡張機能内に「Vulnerability Checker」という、WPScanを走らせる機能が存在していたことに気づきました。
WPScanに戻ってきたものの、そもそもMainWPは子サイトとして管理しているWordPressの本体およびプラグインのバージョンは完璧に取得ができている。
つまり、前回と同じ誤検知トラブルは起きないのではないのか。
もしかして、一元管理問題と脆弱性検知が全てこいつ一つでうまくいくのでは…！ということで期待値かなり高い状態でテストを開始しました。
【よかった点】
- WPの一元管理ツールが大元なので、脆弱性が検知されたメディアが一覧化できた
- スキャンのスケジュールは一定自動で制御できたこと・同時に管理メディアの同期も行えたため対応有無が一定MainWP上で確認ができたこと
【うまくいかなかった点】
- API限界が来たら自動でスキャンが止まるが、どこまで終わったのかがわからない
MainWPは元々複数のサイトの一元管理を目的としたプラグインだったため、グルーピング機能などメディアの絞り込み・検索が簡単にできるので管理の面では申し分のないものでした。
その上、テスト段階ではきちんとメディアのWordPress本体やプラグインのバージョンを正確に拾った上で脆弱性を検知していることが確認できました。
管理面・脆弱性の検知面でも問題がなかったため、管理してるメディアを全部登録していくかと、作業をした結果。
登録数が増えれば増えるほどに自動スキャンが全メディア終わったのかがわからなくなったんです。
なにせ、API上限が来てもエラーにならなかったので。
おそらく、今回のケースほど管理メディアが多くなければ、問題にならなかったところなのですが、今回はメディア数が多いことによる弊害により拡張機能「Vulnerability Checker」による脆弱性検知には使えないという結論に達しました。
まとめ
結論、100近いメディアの脆弱性検知・対応管理は難しい。
当然といえば当然の帰結ですが、ほんとこの一言につきます。
おそらく、ここまでの規模でなければMainWPと拡張機能で十分解決できたはずなのです。
流石にこの規模になると既存のサービスなどと独自のものを組み合わせたり、そもそも最初から独自のものを作ろうとした方が早かったのかもしれませんね。
さらにいえば、実はこの最初のwalti.ioの導入からMainWPに辿り着くまでに1年以上かかってます。
当初脆弱性検知をと言い出した方がインフラ側のチームの方で、WordPress側の保守管理をしているチームとは別。
ただでさえ難しい規模のメディア数に、足並み揃えられないまま対応に乗り出すのは本当に無謀なことだったと思います。 結局一気に話が進んだのは足並みを揃えてからの話だったので、足場固めも大事なタスクの一つだと痛感した失敗談でもありました。
