对象：以个人到小规模方式，自己管理多台服务器、站点、域名的人。越是抱着「先这么跑着」而把盘点一拖再拖，越扎心。这里不讲攻击手法，只谈你自己列清后就能消除的风险。
与其「添加」，不如先「数清再减少」
没掌握的状态，本身就是风险。一做盘点，通常会发现下面这些东西在沉睡。
① 要守的不是「服务器」，而是「放置密钥的电脑」
无论把服务器端加固到什么程度，只要放着 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 密钥、重置码的实物，哪怕一行都不能写。只要设计成『仅用即便泄露也不致命的信息来表达运维状态』，台账就不会变成攻击地图。