年1回のサーバー棚卸しで確認すべき項目

年1回のサーバー棚卸しでは、契約と料金、管理者の権限、ソフトウェアの更新状況、バックアップの四つを中心に確認します。使わなくなった契約や、退職者・旧制作会社のアクセスが残っていないかを見直す機会です。

確認に使うのは、契約一覧、直近の請求書、サーバーやWordPressの管理画面です。小規模サイトなら次の一覧で大枠を押さえられます。

この確認と、実際の更新・解約は別にして構いません。用途不明の契約をその場で解約すると、メールや自動処理が止まることがあります。

台帳ではなく実際の資産から逆引きする

契約台帳に載っている項目だけを確認すると、記録されていない資産を見つけられません。サーバー管理画面・ドメイン一覧・DNS・請求履歴から現在の対象を洗い出します。公開サイトのソースや設定から、CDN・フォーム・解析などの外部サービスも追います。

CISAの資産可視化に関する指針は、最新の資産インベントリを更新・構成管理・脆弱性対応の前提としています。連邦機関向けの要件ですが、台帳の目的を考える参考になります。資産を数えるだけでなく、管理行動へつなげることが重要です。

各資産には用途・契約者・所有者・更新日を記録します。どのサイトや業務が依存しているかも確認します。名称が似たテスト環境や旧ドメインは、URLだけで同じものと判断しません。

サーバー・ドメイン・SSL・外部サービスの契約名義を確認します。制作会社や退職者の名義になっていれば、継続や移管の条件を調べます。請求先と登録メールが現行の社内体制へ合っているかも見ます。

自動更新は、管理不要を意味しません。次回決済日、カード期限、料金改定の通知先を確認します。不要なオプションと、事業継続に必要なバックアップを同じ「費用削減」の対象にしません。

契約中なのに使っていない資産は廃止候補です。ただしメール・転送・認証・過去URLが依存している場合があります。解約前に利用状況と移行先を調べ、担当部門の承認を取ります。

管理者一覧を確認し、在籍者と担当業務へ照合します。退職者・旧制作会社・一時作業者の権限が残っていれば停止候補にします。管理者権限が不要な利用者は、業務に合う権限へ下げます。

人のアカウントだけでなく、FTP・SSH鍵・APIキー・定期処理の認証も確認します。所有者不明のキーをすぐ削除すると、自動処理が止まる可能性があります。利用ログや設定を調べ、置き換え後に古い認証を無効化します。

多要素認証の回復手段も棚卸し対象です。特定社員の端末だけで回復できる状態を避けます。会社の承認を通じて利用できる回復方法と副担当を決めます。

WordPress本体・テーマ・プラグイン・PHPの現在の版を確認します。WordPressのSite Healthでは、更新状態や有効なテーマ・プラグインに加え、サーバーやデータベースの情報を確認できます。情報を取得した日時も記録します。

未使用のテーマやプラグインは、停止中でもファイルが残ります。用途と依存を確認し、不要なら安全な削除計画へ回します。長く更新がない製品は、提供元の保守状況や既知の脆弱性を調べます。更新間隔だけで危険とは断定できませんが、保守が終わっている場合は代替を検討します。

棚卸し当日にすべて更新する必要はありません。影響が大きい更新は検証環境とバックアップを用意します。緊急性・業務影響・作業量から優先順位を付け、期限と担当者を決めます。

バックアップは「有効」と表示されるだけでは足りません。対象・保存先・直近成功時刻・保持世代を確認します。サーバー障害時にも取得できる場所かを見ます。

復元の方法と権限を確認します。事業者へ依頼する方式なら、受付時間と費用を調べます。可能な範囲で検証環境へ復元し、ファイルとデータベースがそろうことを確かめます。

監視では、通知先と直近のテスト結果を確認します。サイトが停止したとき、停止中の社内メールへだけ通知する構成では役立ちません。通知を受けた後の連絡先と判断者まで追います。

支払い失敗が近い契約や、使われている管理者アカウントへの不正アクセスの疑いは、早い対応が必要です。一方、余っている容量や不要かもしれないオプションは、用途を調べてからでも判断できます。

古いPHPや更新が止まったプラグインを見つけた場合、慌てて本番を更新するより、保守担当へ互換性と変更方法を確認する方が安全です。年次点検をしたという理由で一斉に変更する必要はありません。

日常のバックアップ失敗や緊急の脆弱性は、年1回の棚卸しを待たずに対応します。棚卸しは日々の保守の代わりではなく、契約や管理体制の見落としを拾うための確認です。