對象：以個人到小規模方式，自己管理多台伺服器、站點、網域的人。越是抱著「先這麼跑著」而把盤點一拖再拖，越扎心。這裡不講攻擊手法，只談你自己列清後就能消除的風險。
在新增防護之前，先數清並減少手頭的東西
沒掌握的狀態，本身就是風險。一做盤點，通常會發現下面這些東西在沉睡。
① 保護放著金鑰與憑證的電腦
無論把伺服器端加固到什麼程度，只要放著 SSH 私鑰的自己那台電腦被攻陷，那把金鑰能存取的所有伺服器都會暴露。一旦改成金鑰驗證，機群（你管理下的那批伺服器）的實質邊界就轉移到了「持有金鑰的電腦」。檢查的優先順序不是「伺服器 → 電腦」，而是「電腦 → 伺服器」。
尤其見效的是確認 .ssh 是否在雲端同步資料夾（OneDrive/Drive/Dropbox 等）的「外面」。私鑰若不小心落在同步目錄之下，那麼即便電腦沒被直接攻擊，只要雲端帳號被盜，金鑰就會外洩。關於把金鑰權限保持在最小的思路，SSH 金鑰與最小權限 裡有詳細說明。
② 依郵件 → 網域 → 計費的順序設定 2FA
「全部都加上 2FA 吧」這種籠統的開頭永遠做不完。依哪些帳號能復原其他帳號（root of trust）來排序，優先順序就清楚了。
| 層級 | 對象 | 為何最優先 |
|---|---|---|
| 第 0 層 | 郵件帳號 | 幾乎所有服務都能靠「往郵件信箱發重設連結」還原＝郵件被奪，下層的 2FA 就被繞過 |
| 第 1 層 | 網域支配權（註冊商/DNS/託管/程式碼平台） | 站點本身會被奪取、被替換 |
| 第 2 層 | 計費類 API（支付/AI API/郵件投遞） | 直接導致金錢損失 |
實務上：備份碼用紙張實體保管（放到雲端就讓 2FA 的意義大打折扣），並確認用於還原的郵件信箱仍然可用、且在自己掌控之下。詳細步驟見 多因素驗證指南 和 最低限度檢查清單。
③ 列出哪把 SSH 金鑰能打開哪台伺服器
「已經改成金鑰驗證了所以安全」不叫管理。真正需要的，是 把「哪台電腦的・哪把金鑰・能打開哪台伺服器」做成一張表。把各伺服器的 authorized_keys 按指紋逐一比對，原本看不見的東西就會浮現——重複金鑰（同一把金鑰以兩個別名出現兩次）、未使用金鑰（哪裡都沒用到）、孤兒註冊（用途已消失卻仍殘留的註冊）。authorized_keys 加起來容易，刪的時候卻容易忘。做成表，就能逐行追問「這一行是為了什麼？」。
④ 用最少步驟切斷已停止支援的終端
把金鑰放在已停止支援（EOL）作業系統的終端上——很常見。這時若擺出「全部換金鑰＋改伺服器設定」的大架勢，太重，結果反而乾脆不做。
先確認有無外洩跡象
步數最少的切斷＝從終端刪掉金鑰
把支援期限記進行事曆
訣竅是：與其追求完美的正解，不如選今天就能幹完的切斷。
⑤ 把明文密碼從雲端清除
在討論選哪款 PM（密碼管理器）之前，還有更大的實害——一份明文密碼清單放在雲端文件裡這種狀態。一外洩，所有帳號都會同時暴露。
明文清單（雲端文件）
- 一個帳號被盜就會全部外洩
- 在假冒站點上也會手動貼上進去
- 沒有外洩偵測、沒有自動填入
裝置端加密的保管
- 內容在終端側加密（提供方也讀不了）
- 在假冒網域上不會自動填入＝抗釣魚
- 遷移完成後把明文確實刪除
比起「哪款 PM 最強」，「有沒有把明文從雲端清除」要見效得多（→ 如何挑選密碼管理器 / 正確的保管）。
⑥ 整改要逐項進行，並保持可回復
盤點出問題後，會很想一口氣全改掉。但在生產環境裡，憑一股勁同時改好幾處才是最危險的。換金鑰、改設定、生產部署這類難以回退的操作，要逐項進行、並在動手前準備好全文備份＋還原步驟再去碰（＝做成可逆）。不要因整改本身又製造出新的問題（→ 備份與還原）。
⑦ 設計上不讓台帳寫入機密
留存檢查結果的台帳，一旦它本身外洩，就會成為攻擊者的目標清單。所以從一開始就劃清寫什麼。
可以寫（外洩也不致命）
- 公鑰、指紋
- 設定結構、是否開啟 2FA
- 檢查結果（通過/不通過）
絕對不寫（外洩一行就可能被濫用）
- 私鑰內容
- 密碼、API 金鑰
- 重設碼的實物
指紋和公鑰只是用來識別「是哪把金鑰」，單憑它們無法被濫用。僅用即便外洩也不致命的資訊來表達維運狀態——做到這一點，台帳即便放到雲端或共用，受損也會被限制住。
本站的觀點：在新增工具之前，先盤點
本站堅持不把機密（金鑰、密碼、連線資訊）以明文放進共用文件或程式碼，金鑰按用途分開（一把外洩也不會擴散到其他地方），整改務必用可逆的步驟逐項推進。在新增新工具之前，先把「沒掌握的狀態」變成「已列清的狀態」。它毫不花俏，卻是能消除風險最多的那項盤點。
接下來閱讀
- 金鑰：SSH 金鑰與最小權限
- 基本：安全最低限度檢查清單 / 多因素驗證指南
- 保管：如何挑選密碼管理器
- 放置位置：公開的儲存貯體（盤點的對象不只是你的伺服器）
- 忘記刪除的東西：子網域接管與懸空 DNS（停用的東西在刪除前仍是資產）
- 整體觀點：常見的錯誤是前提的失誤（盤點為什麼有效）