WordPress サイト制作の手順では、よしあきがテスト環境へデプロイして、ディレクターやエンドクライアントに確認してもらう流れを書いた。また、Cursorへの短い指示でテスト環境を自動化した話では、サブドメイン作成、サブ FTP、WordPress 簡単インストール、GitHub リポジトリ作成までをまとめる話を書いた。
この記事はその続きである。
テスト環境は、作るところを自動化するとかなり楽になる。ただ、楽に作れるようになるほど、作った後にどう管理するかも決めておかないと危ない。WordPress のテスト環境は、外からアクセスできる URL を持ち、管理画面があり、プラグインも動く。公開前の一時的な場所であっても、放置すれば攻撃対象になりうる。
よしあきは最近、テスト環境について「作成」「保護」「更新」「権限」「削除」までを一つのライフサイクルとして見直した。この記事では、その時点の運用ルールを整理する。
テスト環境を作るだけでは足りない
制作中のテスト環境は、便利な確認場所である。
- ディレクターに初稿を見てもらう
- エンドクライアントにブラウザで確認してもらう
- WordPress の管理画面で設定や固定ページを調整する
- GitHub Actions からデプロイして、本番に近い状態を確認する
この流れ自体はとても便利だ。ローカル環境だけで確認していると、SSL、Basic 認証、サーバー上の PHP、WordPress の簡単インストール、FTP の転送先など、本番に近い層で起きる問題が見えにくい。
一方で、テスト環境は「一時的だから多少ゆるくてもよい」と見なされやすい。ここが危ない。
一時的な URL でも、インターネット上に出ているならアクセスできる。WordPress が動いているなら、WordPress 本体やプラグインの脆弱性の影響を受ける。FTP アカウントを作れる状態なら、公開領域にファイルを置ける。便利さとリスクは同時に増える。
だから、よしあきはテスト環境を「作るもの」ではなく、作って、本番と見分けがつく URL にし、アクセスを制限して、更新して、API キーの権限を絞り、最後に消すものとして扱うことにした。
テスト環境で起きうるリスク
テスト環境でまず困るのは、進行中案件のサイトが改ざんされることだ。
たとえば、サブ FTP アカウントを作成できる権限が漏れていると、公開領域に不正な PHP ファイルや HTML ファイルを置かれる可能性がある。WordPress の管理画面やプラグインに弱い箇所が残っていれば、そこから入られる可能性もある。
もう一つ大きいのは、踏み台化である。
不正ファイルを置かれると、検証サイトがフィッシングページ、マルウェア配布、スパム送信補助、外部攻撃の中継のような用途に使われる可能性がある。テスト環境そのものは本番ではなくても、同じサーバーや同じ親ドメイン配下で起きた問題は、信用や検索評価にも響きうる。
さらに、API や管理画面の権限が広いと、次のような被害も考えられる。
- サブドメインを削除される
- WordPress を削除される
- FTP アカウントを追加・変更される
- DNS やメール設定に影響が出る
- MySQL やログに触られる
ここまで考えると、テスト環境は「見せるための仮置き場」ではなく、公開前の小さな本番環境として扱った方がよい。
公開範囲は Basic 認証で閉じる
テスト URL は、一時的な確認用である。検索結果に載せたいわけでも、不特定多数に見せたいわけでもない。
そのため、よしあきの運用では、検証環境には原則として HTTP Basic 認証を付ける。Basic 認証は万能なセキュリティ対策ではないが、偶発的なアクセスやクローラの取得を減らす最低限の壁になる。
このとき大事なのは、Basic 認証用のユーザー名・パスワードを、他の重要なパスワードと混ぜないことだ。
- 本番の管理者パスワードと同じにしない
- FTP パスワードと同じにしない
- メールアカウントのパスワードと同じにしない
- WordPress 管理者パスワードと同じにしない
テスト環境の Basic 認証は、あくまでテスト URL を簡易的に閉じるためのものとして分けておく。入力のしやすさを優先して短めの文字列にする場合でも、影響範囲が他の認証に広がらないようにする。
WordPress 案件では、テーマファイルのデプロイ先とドキュメントルートが分かれることがある。そのため、サイト全体を Basic 認証で閉じたい場合は、テーマディレクトリだけでなく、ドキュメントルート側に .htaccess や .htpasswd を置く運用も必要になる。
本番と混同しない URL にする
Basic 認証があっても、URL 自体が本番に似ていると事故の元になる。
ブラウザのタブ、ブックマーク、FTP の接続先、デプロイ先の設定を見たときに「これは本番か、テストか」を即判別できるようにしておきたい。本番と間違えてデプロイしたり、本番の設定をテスト用だと思って触ったり、逆にテスト URL を本番だと思ってクライアントに渡したりする、といったミスは実務でありうる。
そのため、よしあきはテスト環境の URL を 本番ドメインに似せない 方針にしている。
- 本番と同じドメイン（例: クライアントの公開サイトと同じ registrable domain）をテスト用に使わない
- 本番 FQDN に
stagingや-stgを足しただけの形も避ける - テスト用は、本番とは 別系統のドメイン 配下に切る
こうしておくと、見た目の段階で環境を分けやすい。セキュリティ対策というより、運用ミスを減らすための見分けに近い。
WordPress のテスト環境ではプラグイン自動更新を有効にする
納品後もしばらく WordPress のテスト環境を残す場合、よしあきは プラグインの自動更新を原則有効にすることにした。
理由は、放置期間中の既知脆弱性リスクを下げるためである。
本番環境では、プラグイン更新による表示崩れや機能不具合を避けるため、保守契約や確認フローに合わせて慎重に更新することがある。だが、テスト環境は本番ではない。納品後に確認用として残しているだけの環境なら、表示が多少変わるリスクより、古いプラグインを放置するリスクの方が大きいと判断している。
もちろん、これは「本番も全部自動更新でよい」という話ではない。本番は案件ごとの保守方針に従う。ここで言っているのは、納品後にしばらく残す WordPress のテスト環境の話である。
テスト環境は、見られる期間が終わったら消す。それまでの間は、少なくとも既知のプラグイン脆弱性を放置しにくい状態にしておく。
自動更新を有効にする直前に、データベース（必要ならメディアも）を 1回だけ 退避しておくと安心である。よしあきは All-in-One WP Migration でエクスポートし、.wpress ファイルを手元や案件フォルダに保存している。サーバー上に置きっぱなしにしない。
何のために残すか。よしあきの場合は、たとえば次のようなときだ。
- 納品後に修正が必要になった
- 納品後の改修に再利用
- 他案件で実装するときの参考にする
プラグインの自動更新で環境が変わっても、上記のような用途で 納品時点に近い状態 に戻したいことがある。更新のたびにバックアップを取る必要はない。テーマは Git で管理しているし、壊れても再デプロイや再構築で戻せるなら、バックアップ自体を省略してもよい。
API キーは 90 日・カスタム最小権限にする
よしあきのテスト環境作成では、ホスティングの API を使ってサブドメインや FTP アカウントを作る。自動化の入口としては便利だが、API キーが漏れたときの影響も考える必要がある。
API キーを「すべての操作」にすると、サーバー上のかなり広い範囲を触れる。テスト環境作成に必要なのは、その全部ではない。
そこで、検証環境作成用の API キーは 有効期限 90 日、権限は カスタムを標準にした。
よしあきの現時点の設定は、おおよそ次の考え方である。
| 権限項目 | 設定の考え方 |
|---|---|
| サーバー情報 | 読み取り専用 |
| ドメイン設定 | 読み取り専用 |
| サブドメイン設定 | すべての操作 |
| SSL設定 | 読み取り専用 |
| FTPアカウント設定 | すべての操作 |
| WordPress簡単インストール | WordPress 案件を扱うならすべての操作 |
| DNSレコード設定 | 利用不可 |
| メールアカウント設定 | 利用不可 |
| メール振り分け設定 | 利用不可 |
| MySQL設定 | 利用不可 |
| PHPバージョン切替 | 利用不可 |
| Cron設定 | 利用不可 |
| アクセスログ・エラーログ | 利用不可 |
静的サイトだけのキーなら、WordPress 簡単インストールも利用不可でよい。WordPress の検証環境を作る可能性があるなら、そこだけ有効にする。
SSL は、サブドメイン作成時に一緒に設定できる範囲で足りる想定なら、読み取り専用でよい。あとから SSL を API で単独操作する運用にするなら、そこだけ見直す。
ポイントは、DNS、メール、SSH、MySQL、Cron、ログ取得を付けないことだ。API キーが漏れても、影響範囲をテスト環境作成に必要な範囲へ閉じ込める。
可能なら IP 制限も併用する。本番操作用のキーと検証環境作成用のキーは分ける。無期限のキーは残さない。API キー文字列は、記事・チャット・Git には書かない。
納品後、いつ消すか
テスト環境は、最後に消すところまでを運用に含める。
よしあきの現行ルールでは、半年前に納品が完了した案件を月に一度の棚卸し対象にし、テスト環境を削除する。
削除時に見るものは、サーバー上の URL だけではない。
- WordPress 簡単インストール
- 付随するデータベース
- 権限が残っていない MySQL ユーザー
- サブドメイン
- サブ FTP アカウント
- 手元の SFTP 設定
- パスワード管理ツールに残った接続情報
- 案件管理シート上のテスト URL
WordPress を消しても、DB ユーザーや FTP アカウントが残っているかもしれない。サブドメインを消しても、手元の SFTP 設定やパスワード管理ツールには古い情報が残るかもしれない。
削除対象から外す案件がある場合は、理由と次回確認日を残す。たとえば「追加確認の可能性がある」「クライアント都合でしばらく確認URLを残す」などである。理由がないまま残すと、次の月も判断できずに放置される。
消すことも、セキュリティ対策の一部である。同時に、管理のしやすさにもつながる。テスト環境が増え続けると、FTP 設定・案件管理シート・削除判断の対象が増え、管理コストが上がる。管理コストが上がると、取りこぼしによるセキュリティリスクも増え、制作の作業効率も下がる。
よしあきの運用チェックリスト
記事として整理すると、今の運用チェックリストは次のようになる。
- テスト環境には、原則 HTTP Basic 認証を付けて不特定多数のアクセスを制限する
- テスト URL は本番ドメインと別系統にする
- Basic 認証のパスワードは、本番・FTP・メール・WordPress 管理者と分ける
- WordPress のテスト環境を納品後もしばらく残すなら、プラグイン自動更新を有効にする
- プラグイン自動更新を有効にする直前に、All-in-One WP Migration で1回だけ退避する（任意）
- API キーは 90 日・カスタム権限を標準にする
- API キーには DNS・メール・SSH・MySQL・Cron・ログ取得を付けない
- FTP アカウントは、アクセスできるディレクトリを広げすぎない
- 半年前に納品完了した案件を、月次で削除対象にする
- 削除時は WordPress、DB、サブドメイン、サブ FTP、手元設定、管理シートまで見る
- 残す場合は、理由と次回確認日を残す
これらは大げさなセキュリティ設計というより、Web制作の実務で「後から困らないための片付け」に近い。
まとめ
テスト環境は、早く作れることが大事だ。確認 URL をすぐ出せると、制作の進行はかなり楽になる。
ただ、作れるようになった環境をそのまま増やしていくと、管理対象も増える。特に WordPress は、管理画面、プラグイン、DB、FTP、サブドメインなど、複数の層が絡む。どこか一つだけ見て「消したつもり」になると、別のところに情報や権限が残る。
よしあきにとってのテスト環境管理は、次のセットで考えるものになった。
- 作成時にアクセスを制限する
- 本番と見分けがつく URL にする
- 残す間は更新する
- API キーの権限を絞る
- 期限を決める
- 納品後は棚卸しして消す
自動化は、作成を速くするだけでは足りない。作った後のライフサイクルまで決めておくことで、テスト環境はようやく「安心して使える一時環境」になる。