壊れたとき、誰が直すのか——CMSは機能ではなく、運用体制で選ぶものだった

守られた部分と、残った部分

7月、WordPress本体に緊急の弱点が見つかりました。プラグインでもテーマでもなく本体側です。ログインなしで中まで入れてしまう種類のもので、公開から数日のうちに実際に狙われはじめました。

7月19日の朝6時半頃、あるサーバー会社が動きます。攻撃に使われる経路をサーバー側で塞ぎました。利用者が何もしなくても、その入口だけは閉じた状態になります。

ありがたい対応です。ただ告知にはこう書いてありました。

これは暫定の措置です。恒久的な対策は、利用者自身のアップデートになります。

守ってもらえた部分と、自分に残った部分。その朝にはっきり分かれました。

この記事はWordPressが危ないという話ではありません。何かが起きたとき、誰が何をするのか。それが平時に決まっているかどうかの話です。

気づく人と、直せる人が別だったら

注意喚起が届くかどうかはサイトをどこに置いているかで変わります。

レンタルサーバーならサーバー会社から届きます。届く先は契約者です。

AWSのようなクラウドに自前で組んでいる場合その一通は来ません。手前に防御を挟んでいれば助かることもありますが、誰かが勝手に塞いでくれる前提には立てません。自分で情報を追っていなければ、何が起きたのかを知らないまま時間が過ぎます。今回のように公開直後から狙われるものだとそこが一番危ない。

通知が届く場合もその一通がどこに着くかは契約によって変わります。

サイトを外部に任せている場合、サーバーの契約が任せた先の名義になっていることがあります。作った会社とは限りません。作ったのは別の会社で、保守はまた違うところが見ている。そういう形もよくあります。名義がそちらにあれば事業者の手元にメールは来ません。事業者名義なら事業者がその文面を読んで、何が起きたのか判断することになります。

どちらが良いかを言いたいのではありません。問題は、気づく人と直せる人が別になっているときです。

事業者に届いても手を入れるのは任せた先。任せた先に届いても止めるかどうかを決めるのは事業者。そのあいだに連絡が一往復入ります。攻撃が自動化されている状況ではその一往復が長くなることもあります。

平日の朝ならまだいい。金曜の夜だったらどうか。連休の初日だったらどうか。そこまで含めて決まっているかどうかです。

「有効にしてある」と「上がっている」

WordPressの自動更新を入れてあるから大丈夫。そう考える人は多いと思います。

ただ、サーバー会社の案内には注意書きが添えられていました。自動更新を有効にしていても、実際に完了しているか管理画面で確認するように、と。わざわざ書かれているということは、そうなっていない例があるからです。

設定を有効にしてあることと実際にバージョンが上がっていることは別です。カスタマイズの都合で止めていた。エラーで途中まで進んで戻っていた。理由はいろいろあります。

確認は管理画面を開けば数十秒で終わります。その数十秒を誰がいつやるのか。決まっていなければ誰もやりません。

閉じた扉は、通り道でもあった

いちばん考えさせられたのはここでした。

サーバー会社が塞いだのは攻撃に使われる経路です。同時にその経路はまっとうな機能が使っていた通り道でもありました。塞げば攻撃は止まる。通っていた業務も巻き添えになることがあります。

告知にもその可能性が並んでいました。外部サービスとの連携が動かなくなる。管理画面からの一括処理ができなくなる。作り込んだ独自機能が反応を返さない。

守ることと壊すことが、同じ操作の裏表になっていたわけです。

壊れていたとしてもそれを拾うのはサーバー会社ではありません。塞いだ側の仕事は塞ぐところまでです。

保守を見てもらっている会社があるなら、そこが拾ってくれるかもしれません。ただ、そこまでが契約に入っているかは別の話です。月々の保守が更新とバックアップまでで、突発の影響確認までは含んでいないこともある。含まれていたとしてもどこを見ればいいかは、その業務を毎日回している人にしか分からない部分が残ります。

三日後、影響が出ている場合は個別に相談すれば解除を検討するという追記が出ました。窓口はできた。ただし申し出た人にだけ適用されます。自分のサイトのどこが止まっているかを把握していて、それを申し出られる人。そこまでがセットです。

安全のために閉じられた扉が自社の業務の通り道でもあったかどうか。それを判断できる人がどこにいるか。

戻せるかどうかは、平時にしか確認できない

最後は復旧です。

バックアップがどこにあるか。何日前まで戻せるか。戻す操作を誰がやるか。戻したあとの確認は誰がするか。

バックアップは取ってありますという答えはよく返ってきます。戻したことがありますか、と聞くと止まることが多い。取ってあることと、戻せることのあいだにも距離があります。

これも壊れてから調べるものではありません。

以前、逆のことを書いていた

正直に書くと、この件では見込みを外しました。

5月にWordPressで始めるなら——最初から「いつか乗り換える」前提で組むという記事を書いています。そこで、弱点が出やすいのは本体よりも後から足したプラグインのほうだと書きました。根拠は新しく見つかる弱点の9割以上がプラグイン由来という調査です。

その2ヶ月後に来たのは本体単体の穴でした。プラグインを一つも入れていなくても関係がありません。

数字で判断するというのは多いほうに賭けるということでした。少ないほうが来ないという意味ではなかった。そこを混ぜて読んでいたわけです。

ただ、結論のほうは残りました。あの記事で言いたかったのは、保守の負担は減る方向に動かないから乗り換え前提で組んでおくということです。今回の一件はその前提を強めこそすれ弱めはしません。

変わるのは、誰が直すか

では何を選べばいいのか。ここで単純にCMSの乗り換えを勧めるのは違うと思っています。作る側が言えば、それは売り込みになる。

代わりに自分に残る範囲がどう変わるかだけ並べます。

自社で借りたサーバーにWordPressを置く構成は、月々のコストが一番安く上がります。触れる人が多く情報も出回っている。できることの幅も群を抜いています。選ばれる理由はたいていここです。

そのかわり本体もプラグインもサーバーも、更新の責任は自分に残ります。今回のような突発対応も自分に来る。

ただ、その安さに突発対応の分は入っていません。案内を読んで更新を確かめるだけなら短く済みます。読めないのは何かが止まっていたときです。どこが止まったのかを突き止めて、解除を申し出て、戻ったかを確かめる。半日で終わることもあれば何日か引きずることもあります。

しかもその日は選べません。繁忙期でも決算前でも来るときは来ます。安さと引き換えに引き受けているのは、この読めなさのほうです。

同じ自前でもクラウドに自分で組んでいるなら、暫定の遮断が降ってくることはありません。巻き添えで止まる心配はない代わりに、気づく役目がまるごと自分に残ります。

CMSを外部サービスに預けて表示側を静的に作るヘッドレスの場合、CMS側の弱点対応は預けた先が持ちます。公開されている面が静的なので狙われる面そのものが小さくなる。

かわりに手を入れられる人が限られます。構築のときに限りません。記事の更新は管理画面で完結しますが、それ以外はだいたいコード側に回ります。ボタンの色を変える。ページを一枚足す。並び順を入れ替える。WordPressなら管理画面から触れていたものが、ヘッドレスでは直して公開し直す作業になります。

社内で昔少しコーディングをかじった人に頼む、というような進め方は成り立ちません。作った側か、同じ作り方ができる人に作業は回り続けます。

日々の微修正まで含めて誰が持つのか。そこを決めずに始めると、直したい一行が何週間も直らないまま残ります。

ShopifyやSTUDIOのようなサービスに乗る場合、ほとんどが向こう側の担当になります。かわりに、できることの範囲はサービスが決めたところまでです。

乗り換えれば安全になる、という話ではありません。どのサービスにも障害はあるし弱点も見つかります。変わるのは、誰が直すのか。そして自分が何もしなくても直るのか。この二つだけです。

緊急対応に人を割ける体制があるならWordPressでいい。自由度は最大です。割けないなら、直す人が向こう側にいる構成を選んでおく。

平時に、書き出せる状態にしておく

CMSは機能の一覧で選ぶものだと扱われがちです。実際に効いてくるのは、そこではありませんでした。

誰が気づくか。どれくらいで塞がるか。塞がれた副作用を誰が拾うか。壊れた後、戻せるか。この四つに答えられる状態を作ることが、CMSを選ぶということだったと思っています。

答えは構成によって変わります。正解も一つではありません。ただ、緊急の案内が届いた朝に考えはじめるものではない。それだけは今回はっきりしました。