對象：以個人到小規模方式，自己管理多台伺服器、站點、網域的人。越是抱著「先這麼跑著」而把盤點一拖再拖，越扎心。這裡不講攻擊手法，只談你自己列清後就能消除的風險。
與其「新增」，不如先「數清再減少」
沒掌握的狀態，本身就是風險。一做盤點，通常會發現下面這些東西在沉睡。
① 要守的不是「伺服器」，而是「放置金鑰的電腦」
無論把伺服器端加固到什麼程度，只要放著 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 終端按「成本 vs 風險」用最少步數切斷
把金鑰放在已停止支援（EOL）作業系統的終端上——很常見。這時若擺出「全部換金鑰＋改伺服器設定」的大架勢，太重，結果反而乾脆不做。
先確認有無外洩跡象
步數最少的切斷＝從終端刪掉金鑰
把期限的懸崖記進行事曆
訣竅是：與其追求完美的正解，不如選今天就能幹完的切斷。
⑤ 把明文密碼從雲端清除
在討論選哪款 PM（密碼管理器）之前，還有更大的實害——一份明文密碼清單放在雲端文件裡這種狀態。一外洩就是全軍覆沒。
明文清單（雲端文件）
- 一個帳號陷落就會全部外洩
- 在假冒站點上也會手動貼上進去
- 沒有外洩偵測、沒有自動填入
裝置端加密的保管
- 內容在終端側加密（提供方也讀不了）
- 在假冒網域上不會自動填入＝抗釣魚
- 遷移完成後把明文確實刪除
比起「哪款 PM 最強」，「有沒有把明文從雲端清除」要見效得多（→ 如何挑選密碼管理器 / 正確的保管）。
⑥ 整改要「用可逆的步驟，逐項進行」
盤點出問題後，會很想一口氣全改掉。但在生產環境裡，憑一股勁同時改好幾處才是最危險的。換金鑰、改設定、生產部署這類難以回退的操作，要逐項進行、並在動手前準備好全文備份＋還原步驟再去碰（＝做成可逆）。因整改本身又開出新窟窿，那就本末倒置了（→ 備份與還原）。
⑦ 設計上不讓台帳寫入機密
留存檢查結果的台帳，一旦它本身外洩就成了攻擊地圖。所以從一開始就劃清寫什麼。
可以寫（外洩也不致命）
- 公鑰、指紋
- 設定結構、是否開啟 2FA
- 檢查結果（通過/不通過）
絕對不寫（一行就成凶器）
- 私鑰內容
- 密碼、API 金鑰
- 重設碼的實物
指紋和公鑰只是用來識別「是哪把金鑰」，單憑它們無法被濫用。僅用即便外洩也不致命的資訊來表達維運狀態——做到這一點，台帳即便放到雲端或共用，受損也會被限制住。
本站的觀點：在做加法之前，先盤點
本站堅持不把機密（金鑰、密碼、連線資訊）以明文放進共用文件或程式碼，金鑰按用途分開（一把外洩也不波及＝把爆炸半徑降到最小），整改務必用可逆的步驟逐項推進。在新增新工具之前，先把「沒掌握的狀態」變成「已列清的狀態」。它毫不花俏，卻是能消除風險最多的那項盤點。
接下來閱讀
- 金鑰：SSH 金鑰與最小權限
- 地基：安全最低限度檢查清單 / 多因素驗證指南
- 保管：如何挑選密碼管理器
FAQ
Q什麼是安全盤點？
就是在「新增」新防護之前，先把自己手頭的金鑰、帳號、終端、註冊項列成清單，找出不需要的或處於危險狀態的並加以減少的工作。個人到小規模維運的事故，往往不是因為缺少防火牆或 WAF，而是源於『不清楚哪台電腦的哪把金鑰能打開哪台伺服器』『不確定是否開了 2FA』這類「沒掌握的狀態」，盤點正是用來消除它們。
Q應該從哪裡下手？
順序是『電腦 → 伺服器』。一旦把 SSH 改成金鑰驗證，實質的邊界就已經從伺服器轉移到了放置金鑰的自己那台電腦上。先檢查持有金鑰的電腦是否健康（尤其是 .ssh 是否在雲端同步資料夾之外），接著是郵件帳號的 2FA 和備份碼，然後再做 SSH 金鑰盤點，這樣的順序最有效率。
Q寫了盤點結果的台帳安全嗎？
只要劃清寫什麼，就能安全地使用。公鑰、指紋、設定結構、是否開啟 2FA、檢查結果都可以寫（這些本身不是祕密）。另一方面，私鑰內容、密碼、API 金鑰、重設碼的實物，哪怕一行都不能寫。只要設計成『僅用即便外洩也不致命的資訊來表達維運狀態』，台帳就不會變成攻擊地圖。