セキュリティの棚卸し — 複数サーバーを個人運用する人が見落とす点検7項目

対象：個人〜小規模で、複数のサーバー・サイト・ドメインを自分で管理している人。「とりあえず動いてる」で棚卸しを後回しにしているほど刺さります。ここでは攻撃手順は扱わず、自分で一覧化して消せるリスクだけを扱います。

「足す」より先に「数えて減らす」

把握していない状態は、それ自体がリスクです。棚卸しをすると、たいてい次が眠っています。

① 守るのは「サーバー」でなく「鍵を置いたPC」

サーバー側をいくら固めても、SSHの秘密鍵を置いた自分のPCが乗っ取られたら全部開きます。鍵認証にした時点で、フリート（管理下のサーバー群）の実質的な境界は「鍵を持つPC」へ移っています。点検の優先順位は「サーバー→PC」ではなく 「PC→サーバー」。

特に効くのは .ssh がクラウド同期フォルダ（OneDrive/Drive/Dropbox等）の“外”にあるかの確認。秘密鍵がうっかり同期配下にあると、PCを直接やられなくてもクラウドアカウントが落ちただけで鍵が流出します。鍵の権限を最小に保つ考え方は SSH鍵と最小権限 に詳しく書いています。

② 2FAを「信頼の連鎖」でティア化する

「全部に2FAを付けよう」は漠然と始めると終わりません。支配権の連鎖（root of trust）で階層化すると優先順位が一発で決まります。

実務のキモは、バックアップコードは紙で物理保管（クラウドに置くと2FAの意味が半減）、復旧用メールが自分の管理下で生きているかの確認。詳しい手順は 多要素認証ガイド と 最低限チェックリスト へ。

③ SSH鍵は「マトリクス化」して初めて管理

「鍵認証にしてあるから安全」は管理とは言いません。本当に要るのは 「どのPCの・どの鍵が・どのサーバーを開けるか」を一枚の表にすること。各サーバーの authorized_keys を指紋で突き合わせると、見えていなかったものが出ます——重複鍵（同じ鍵が別名で2つ）・未使用鍵（どこでも使われていない）・孤児登録（消えた用途の登録が残存）。authorized_keys は足すのは簡単で消し忘れがち。表にすると「この行は何のため？」と一行ずつ問えます。

④ EOL端末は「手間 vs リスク」で最小手数の遮断

サポート終了（EOL）OSの端末に鍵を置いている——よくあります。ここで「全鍵入れ替え＋サーバー設定変更」と大上段に構えると重すぎて結局やらない。

完璧な正解より、今日やり切れる遮断を選ぶのがコツです。

⑤ 平文パスワードをクラウドから消す

PM（パスワードマネージャー）選びの議論より手前に、もっと大きな実害があります——平文のパスワード一覧がクラウドのドキュメントに置いてある状態。漏れたら即・全滅です。

「どのPMが最強か」より「平文をクラウドから消したか」が桁違いに効きます（→ パスワードマネージャーの選び方 / 正しい保管）。

⑥ 是正は「可逆な手順で、1つずつ」

棚卸しで問題が出ると、まとめて直したくなります。が、本番環境では勢いで複数同時に変更するのが一番危ない。鍵の入れ替え・設定変更・本番デプロイのような戻しにくい操作は、1つずつ・着手前に全文バックアップ＋復元手順を用意してから触る（＝可逆にする）。是正そのもので新しい穴を開けては本末転倒です（→ バックアップと復旧）。

⑦ 台帳に機密を書かない設計

点検結果を残す台帳は、それ自体が漏れたら攻撃地図になります。だから書く内容を最初から線引きします。

指紋や公開鍵は「どの鍵か」を識別するだけで単体では悪用できません。漏れても致命傷にならない情報だけで運用状態を表す——これができれば、台帳をクラウドに置いても共有しても被害が限定されます。

次に読む

• 鍵：SSH鍵と最小権限
• 土台：セキュリティ最低限チェックリスト / 多要素認証ガイド
• 保管：パスワードマネージャーの選び方