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

年1回のサーバー棚卸しは、契約台帳に印を付ける作業ではありません。実際に存在するサイト・契約・権限を調べ、台帳との差を見つけます。日々の更新では見えにくい未使用サービスや退職者権限を、まとめて整理する機会です。

棚卸しの日に大量の更新や解約を同時実行すると、問題の原因を追いにくくなります。まず事実と差分を記録し、残す・直す・廃止する判断へ分けます。影響のある変更は、承認と戻し方を用意した別作業として進めます。

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

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

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

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

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

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

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

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

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

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

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

未使用のテーマやプラグインは、停止中でもファイルが残ります。用途と依存を確認し、不要なら安全な削除計画へ回します。更新が止まった製品は、代替候補と移行に必要な期間を決めます。

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

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

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

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

棚卸し結果には、確認した事実と台帳との差を書きます。リスク・所有者・対応期限を一件ずつ付けます。「要確認」のまま次年度へ送らず、判断する人と期日を決めます。

すぐ直せる連絡先の誤りと、移行が必要な旧システムを同じ期限にしません。停止リスクや情報漏えいにつながる差を優先します。不要資産は依存確認、バックアップ、停止観察を経て廃止します。

最後に台帳を現状へ更新し、承認者と確認日を残します。次回棚卸し日だけでなく、途中で再確認する差分も運用カレンダーへ入れます。棚卸しの成果は確認項目の数ではなく、会社が持つ資産と責任者を説明できる状態に戻したことです。