決済、メール送信、地図、予約システム。WordPressで作るサイトは、外部サービスとつながるたびにAPIキーやパスワードのような「鍵」を預かります。その鍵がどこにどう保存されているか、納品のときに意識したことはあるでしょうか。WordPress本体の開発チームが公開した次期版の計画に、この鍵の保管方法を根本から整える「Secrets API」が入っています。
いまはプラグインの設定と同じ場所に平文で置かれている
Make WordPress Coreに8月末に投稿された提案によると、現在のWordPressには「秘密の値」を扱う専用の仕組みがありません。APIキーを必要とするプラグインは、サイトのキャッチフレーズなどと同じオプションテーブルに、暗号化せずに書き込むしかないのが実情です。提案者も、これはプラグイン作者の落ち度ではなく、ほかに選択肢がないためだと書いています。
問題は、このテーブルがデータベースのダンプやバックアップ、ステージング環境の複製にそのまま含まれることです。制作会社が検証用にコピーしたデータベースにも、クラウドに置いたバックアップにも、本番の鍵が読める形で残ります。一部のプラグインは独自に暗号化していますが、方式はばらばらで、まとめて点検することができません。
提案されている仕組みの中身
提案では、wp_set_secret()とwp_get_secret()を中心とした少数の関数と、値を包むオブジェクトが用意されます。保存時の暗号化は常に有効で、無効にする設定はあえて設けないとされています。暗号化できる設定にしておくと、結局多くのサイトが平文のまま残るからだ、という理由です。
ほかにも実務で効いてきそうな設計がいくつかあります。
- 取り出した値はログや
var_dump()の出力では伏せ字になり、生の文字列を得るには明示的な呼び出しが必要 - 値を取り出す経路にはフィルターを置かない。フィルターがあると、どのプラグインでも全部の鍵を横取りできてしまうため
- 値の書き出し機能はなく、移行先やステージングでは入力し直す前提。確認用には値そのものではなく指紋(fingerprint)を使う
- 上書きしても直前の値を一つだけ残し、入力ミスや切り替え途中の不具合に備える
- WP-CLIからも扱えるようにし、コマンドの引数に鍵を書いてシェルの履歴に残る問題も減らす
既存の設定値を自動で移し替えることはせず、プラグイン作者が自分の判断で移す関数を用意する方針です。移した鍵には「作り直しが必要」という印が付きます。すでにバックアップに平文で残っている以上、暗号化しただけでは不十分で、鍵そのものを発行し直すのが本当の対策だという考え方です。
守れるものと守れないもの
提案は効果の範囲をはっきり線引きしています。守れるのは、データベースの流出、クラウドに置いたバックアップ、SQLインジェクションによる読み取り、設定画面のスクリーンショットやデバッグログからの漏れといった経路です。一方、WordPressの中でコードを実行されてしまった場合は防げません。鍵は使うために取り出せる必要があり、WordPressとして動くコードなら同じように取り出せるからです。
それでも、流出の多くはデータベースやバックアップ経由で起きるという前提に立てば、盗まれたデータベースの価値を下げる意味は大きいと考えられます。鍵へのアクセスが一か所にまとまるので、誰がいつ変えたかを記録できるようになる点も見逃せません。
7.2に入るかどうかと、制作現場の準備
9月18日に公開されたWordPress 7.2のロードマップでは、再認証を求める「sudoモード」やApplication Passwordsの強化と並んで、Secrets APIがセキュリティ面の柱に挙げられています。7.2のベータ1は10月20日から22日、正式版は12月上旬の予定です。ただしロードマップ自体が、掲載項目がすべて入るとは限らないと断っていて、提案でもベータ1までに間に合わなければ7.3へ見送るとしています。管理画面の設定画面は7.3以降に回し、まずはAPIとWP-CLIを固める段取りです。
本体に入ってもすぐに何かが変わるわけではなく、各プラグインが対応して初めて効果が出ます。それまでの間にできるのは、自分たちが納品したサイトにどんな鍵が保存されているかを把握しておくことでしょう。データベースを検証環境にコピーするとき、そこに本番の決済キーやメール送信の認証情報が入っていないか確かめるだけでも、事故の芽は減らせます。プラグインの更新履歴に対応の知らせが載りはじめたら、預かっている鍵を発行し直すよい機会になりそうです。
