WordPress 4.6.1の緊急更新は適用後の確認を後回しにしない

WordPress 4.6.1は、4.6以前に影響する二つの問題を修正するセキュリティ更新です。画像ファイル名を経由するクロスサイトスクリプティングと、更新パッケージを扱う処理のパストラバーサルが案内されています。対象のサイトは更新を延ばさない方がよい。ただし、急いで適用することと、更新後を確認しないことは別です。

更新作業で必要なのは、二つの速さです。一つは、問題が公表されたあと、対象のWordPressを放置しない速さです。もう一つは、更新のあとに表示や問い合わせの異常を早く見つける速さです。前者だけを優先すると、管理画面のバージョン表示を見て終わりになり、サイトが使えなくなったときに発見が遅れます。

4.6.1では、セキュリティ上の修正に加えて4.6の不具合も15件修正されています。自動バックグラウンド更新に対応するサイトでは、更新が始まる場合があります。自動で更新されたなら安心ではなく、誰が確認するかを決めずに更新だけが終わった状態になります。

緊急更新では変更を一つに絞る

セキュリティ更新の直前に、テーマの見た目、プラグイン、PHPの設定までまとめて変えると、問題が起きたときに原因を追えません。更新をため込むと手間を減らせるように見えますが、異常が出たあとに戻す範囲が広くなります。

4.6.1を適用する回は、原則としてWordPress本体の更新だけを行います。テーマやプラグインにも更新があるなら、緊急性と影響範囲を別に記録します。同じ時間に行う必要がある場合でも、どの変更を先にしたかを残せば、確認の順序を作れます。

更新前に完璧な資料を作る必要はありません。少なくとも、次の四つは一枚に残します。

バックアップは、あると言われただけでは役に立ちません。どこにあり、誰が取り出せるかが分からなければ、復旧の判断をする時点で初めて問題になります。日常の保守では、更新を待たずにこの確認を済ませておくべきです。今回のような緊急更新では、復旧手段が不明なことを理由に放置するのではなく、管理権限と保存先を確認できる人へすぐ連絡します。

更新前に公開siteを止める必要があるかも、siteの役割で決めます。営業時間外に更新できるsiteなら、問い合わせや注文が少ない時間を選べます。一方で、更新を待つ間にsecurity上の問題を抱え続けることもあります。更新を延期するなら、いつ誰が実施するか、延期している間にどの責任者が状態を確認するかを残します。「後で更新する」という判断だけで終わらせません。

更新直後は管理画面と公開画面を別に見る

管理画面で4.6.1と表示されれば、更新が適用されたことは分かります。しかし、読者や顧客が見るのは管理画面ではありません。公開側の確認は、事業で使っている導線から選びます。

たとえば、画像を多く使う会社サイトなら、トップページ、画像付きの記事、問い合わせページを開きます。トップページの画像が見えても、投稿画面で新しい画像を追加できるとは限りません。逆に、管理画面で画像を選べても、生成したサイズや公開ページのURLが正しいとは限りません。画像を扱う画面と、画像を見せる画面を分けて確認します。

問い合わせが主な目的のサイトなら、フォームの表示だけでなく、送信後の画面と受信先の扱いを確認する対象に入れます。送信テストをするときは、実際の問い合わせと混ざらない方法を担当者間で決めます。テストした日時と内容を残せば、後から届かなかったときの調査も始めやすくなります。

画像filenameに関する修正が含まれる更新では、既に掲載した画像だけを見るのでなく、画像を追加する操作も確認します。test用の画像をmedia libraryへ追加し、投稿または固定pageへ置き、保存後に公開画面を開きます。表示できたら、その画像を削除または下書きへ戻してtestを終えます。実在の顧客画像や公開中の画像をtest用に動かさず、どの操作を確認したかを残します。

確認項目を増やしすぎる必要はありません。更新によって止まると事業に影響する場所を先に見ます。

1. 管理画面でWordPressが4.6.1になっているか確認する。
2. 公開中の主要ページを、ログアウトした状態でも開く。
3. 画像を使うページと、管理画面での画像選択または追加を確認する。
4. 問い合わせ、予約、購入など、サイトの目的に直結する導線を確認する。
5. 更新日時、確認した人、異常の有無を記録する。

自動更新は確認の担当をなくさない

自動バックグラウンド更新は、更新を早く適用する助けになります。しかし、自動更新は、サイトの内容が事業に合ったままかを判断しません。画像がずれていないか、フォームが受け付けるか、予約や購入へ進めるかは、サイトの目的を知る人が確認する必要があります。

更新の担当を外部へ任せることはできます。けれども、WordPressの管理者、ドメイン、サーバー、バックアップの場所、連絡を受ける人まで外部任せにすると、緊急時に誰が止め、誰が戻し、誰が公開確認をするのか決められません。作業を任せることと、サイトを戻せる状態を持つことは分けます。

更新後に異常を見つけた場合は、まず確認したURL、操作、時刻、画面に出た状態を残します。その後で、更新を戻すか、themeやpluginを確認するかを決めます。問題が起きた直後に別のpluginを更新したり、CSSを直したりすると、何が原因だったかを追えません。緊急更新ほど、追加の変更を小さく保ちます。

更新を記録すれば次の判断が速くなる

緊急更新の記録は、報告書を増やすためのものではありません。次に問題が出たとき、「どの版へいつ更新し、どのページまでは確認できたか」をすぐ見つけるためのものです。

最初の一手は、更新前に主要ページを三つ決め、バックアップの保存先と確認担当者を書き出すことです。4.6.1を適用したら、同じ紙へ結果を追記します。更新の速さと、公開サイトを使い続けられることを、同じ作業の中で守れます。