対象：個人〜小規模で、複数のサーバー・サイト・ドメインを自分で管理している人。「とりあえず動いてる」で棚卸しを後回しにしているほど当てはまります。ここでは攻撃手順は扱わず、自分で一覧化して消せるリスクだけを扱います。
対策を足す前に、持っているものを数えて減らす
把握していない状態は、それ自体がリスクです。棚卸しをすると、たいてい次が眠っています。
① 鍵や認証情報を置いたPCを守る
サーバー側をいくら固めても、SSHの秘密鍵を置いた自分のPCが乗っ取られたら、その鍵で入れるサーバーすべてに入られます。鍵認証にした時点で、フリート（管理下のサーバー群）の実質的な境界は「鍵を持つPC」へ移っています。点検の優先順位は「サーバー→PC」ではなく 「PC→サーバー」。
特に効くのは .ssh がクラウド同期フォルダ（OneDrive/Drive/Dropbox等）の“外”にあるかの確認。秘密鍵がうっかり同期配下にあると、PCを直接やられなくてもクラウドアカウントが乗っ取られただけで鍵が流出します。鍵の権限を最小に保つ考え方は SSH鍵と最小権限 に詳しく書いています。
② 2FAは、メール→ドメイン→課金の順に優先して設定する
「全部に2FAを付けよう」は漠然と始めると終わりません。どのアカウントが他のアカウントの復旧手段になっているか（root of trust）で階層に分けると、優先順位がすぐ決まります。
| ティア | 対象 | なぜ最優先か |
|---|---|---|
| ティア0 | メールアカウント | ほぼ全サービスが「メールにリセットリンク」で復旧可＝メールを取られると下位の2FAは迂回される |
| ティア1 | ドメイン支配権（レジストラ/DNS/ホスティング/コード基盤） | サイトそのものを乗っ取られる・差し替えられる |
| ティア2 | 課金API（決済/AI API/メール配信） | 直接の金銭被害につながる |
実務で大事なのは、バックアップコードは紙で物理保管（クラウドに置くと2FAの意味が半減）、復旧用メールが自分の管理下で使える状態かの確認。詳しい手順は 多要素認証ガイド と 最低限チェックリスト へ。
③ SSH鍵は、どの鍵でどのサーバーに入れるかを一覧にする
「鍵認証にしてあるから安全」は管理とは言いません。本当に要るのは 「どのPCの・どの鍵が・どのサーバーを開けるか」を一枚の表にすること。各サーバーの authorized_keys を指紋で突き合わせると、見えていなかったものが出てきます：重複鍵（同じ鍵が別名で2つ）・未使用鍵（どこでも使われていない）・孤児登録（消えた用途の登録が残存）。authorized_keys は足すのは簡単で消し忘れがち。表にすると「この行は何のため？」と一行ずつ問えます。
④ サポート終了の端末は、最小限の手順で通信を遮断する
サポート終了（EOL）OSの端末に鍵を置いている——よくあります。ここで「全鍵入れ替え＋サーバー設定変更」と一度にすべてやろうとすると、重すぎて結局やらない。
漏れた形跡が無いか確認
一番手数の少ない遮断＝端末から鍵を消す
サポート期限をカレンダーに入れる
完璧な正解より、今日やり切れる遮断を選ぶのがコツです。
⑤ 平文パスワードをクラウドから消す
PM（パスワードマネージャー）選びの議論より手前に、もっと大きな実害があります。平文のパスワード一覧がクラウドのドキュメントに置いてある状態です。漏れたら全アカウントが一度に危険になります。
平文の一覧（クラウドのドキュメント）
- アカウント1つが乗っ取られると全部漏れる
- 偽サイトでも手で貼ってしまう
- 漏えい検知・自動入力が無い
オンデバイス暗号化の保管
- 中身は端末側で暗号化（提供元も読めない）
- 偽ドメインでは自動入力しない＝フィッシング耐性
- 移したら平文は確実に消す
「どのPMが最強か」より「平文をクラウドから消したか」が桁違いに効きます（→ パスワードマネージャーの選び方 / 正しい保管）。
⑥ 是正は、元に戻せる手順で1つずつ行う
棚卸しで問題が出ると、まとめて直したくなります。が、本番環境では勢いで複数同時に変更するのが一番危ない。鍵の入れ替え・設定変更・本番デプロイのような戻しにくい操作は、1つずつ・着手前に全文バックアップ＋復元手順を用意してから触る（＝可逆にする）。是正そのもので新しい問題を生んでは本末転倒です（→ バックアップと復旧）。
⑦ 台帳に機密を書かない設計
点検結果を残す台帳は、漏れたら攻撃者にとって標的の一覧になります。だから書く内容を最初から線引きします。
書いてよい（漏れても大きな被害にならない）
- 公開鍵・指紋
- 構成の構造・2FAの有無
- 点検結果（合格/不合格）
絶対に書かない（1行でも漏れると悪用される）
- 秘密鍵の中身
- パスワード・APIキー
- リセットコードの実物
指紋や公開鍵は「どの鍵か」を識別するだけで単体では悪用できません。漏れても大きな被害にならない情報だけで運用状態を表す。これができれば、台帳をクラウドに置いても共有しても被害が限定されます。
当サイトの視点：対策を足す前に、棚卸し
当サイトは、秘密（鍵・パスワード・接続情報）を共有ドキュメントにもコードにも平文で置かない運用を徹底し、鍵は用途ごとに分け（1つ漏れても他に被害が広がらないようにする）、是正は必ず可逆な手順で1つずつ進めます。新しいツールを足す前に、まず「把握していない状態」を「一覧化された状態」に変える。派手さは無いのに、消せるリスクが一番多いのがこの棚卸しです。
次に読む
- 鍵：SSH鍵と最小権限
- 基本：セキュリティ最低限チェックリスト / 多要素認証ガイド
- 保管：パスワードマネージャーの選び方
- 置き場所：クラウドストレージの公開設定ミス（棚卸しの対象はサーバーだけではない）
- 消し忘れ：サブドメイン乗っ取り（dangling DNS）（やめたものは消すまで資産のまま）
- 全体像：よくある失敗は「前提」の失敗（棚卸しが効く理由）
- なぜ棚卸しが要るのか：2026年の情報漏えいは「脆弱性」より「正規の認証情報」で起きている（外部依存の一覧が無いと「自分は対象か」すら判断できない）