如何避免网络安全风险

很多小团队没有专职安全岗，运维顺手兼着，出事往往不是被高级攻击打穿，而是某个后台还挂着默认口令、某台测试机端口开到公网、备份没验证过能不能恢复。这篇不讲原理，只给一份能照着做的日常清单：先摸清自己有哪些东西，再按优先顺序收紧，最后留好能查证的记录。规模大、已有专职安全团队或强合规要求的企业，需要在此基础上叠加更细的制度流程。

很多小团队没有专职安全岗，运维顺手兼着。真出事的时候，往往不是被什么高级攻击打穿，而是某个后台还挂着默认口令、某台测试机端口直接开到公网、备份从没验证过能不能恢复。这类口子不需要多高的技术就能被扫到，也不需要多高的技术就能堵上。

这篇不讲原理，只给一份能照着走的日常清单：先摸清自己有哪些东西，再按优先顺序收紧，最后留好能查证的记录。规模大、已有专职安全团队或强合规要求的企业，需要在此基础上叠加更细的制度流程，这份清单只当底线用。

第一步：先搞清楚自己有什么，别急着买设备

安全投入最容易花错的地方，就是还没弄明白自己有哪些资产就先买工具。先用一张表把东西列出来，比买什么都管用。资产清单不需要精细到每台机器，但必须覆盖对外暴露的面。

• 列一份最小资产清单：域名与解析、公网可访问的端口与服务、云账号与子账号、对外用的第三方 API Key 和后台账号、存数据的机器；漏项通常出在「临时开的测试环境」和「离职同事留下的账号」
• 每个资产标注三件事：谁负责、放在哪、有没有人还在用；找不到负责人的资产先标记待确认，别直接关停业务相关的服务
• 判断标准：能不能在十分钟内说清「我们有哪些东西暴露在公网」。做不到，就说明清单还没做完

清单做完先别急着动手改配置，先确认哪些是业务在用的。关掉一个没人记得但其实是某个对账脚本依赖的接口，带来的麻烦不比安全事件小。

第二步：把公网上没必要的口子关上

这一步是投入产出比最高的。大量被扫到的目标，本质上是「本来就不该暴露在公网」的服务。先按下面这张表对照一遍自己手里的东西。

口令与登录这块不花钱、收益最大：默认口令必改，多人共用一个后台账号的做法要拆开，能开两步验证的都开。改完别只记在心里，写进资产清单的备注里。

第三步：权限按最小给，别图省事给一把大的

小团队最常见的做法是一份凭据到处复制：部署脚本用它、第三方集成用它、临时排查也用它。方便是方便，但一旦泄露，能改的范围就是全部。日常操作、脚本调用、第三方集成各用各的凭据，是成本很低的一道隔离。

1. 梳理凭据归属把现有凭据列出来，写清谁能看到、存在哪里、被哪些服务引用；找不到引用方的先标记，别直接删。
2. 拆分与收敛按用途拆成独立凭据，只给完成这件事所需的最小范围；能只读的就不要给写权限。
3. 盯住高风险时点离职、换岗、外包结束当天收回账号并轮换相关凭据，别等「下次整理再说」。

凭据类的具体操作和自查方式，站内已有的 Key 安全、轮换与泄露自查那几篇写得比较细，这里不重复，按那几篇的步骤走就行。

第四步：备份要能恢复，应急要有人知道做什么

只备份不验证，等于没有备份。很多团队平时备份任务跑得好好的，真要用的时候才发现备份文件是空的、或者恢复出来的数据版本不对。判断备份是否可用，只有一条标准：最近一次真的恢复成功是什么时候。

• 备份三问：多久备一次、存在哪、最近一次真的恢复成功是什么时候
• 留一份「出事第一小时做什么」的便签：谁能拍板停机、先断什么、找谁、从哪看日志
• 演练频率按业务重要性定，不必追求复杂，关键是把顺序写下来并让值班的人看过

小团队最怕的不是出事本身，而是出事时没人知道下一步该找谁。便签不用写得像预案，一页纸说清顺序就够了，关键是值班的人真的看过。

第五步：留痕 + 定期回看，别装完就不管

前面几步做完只是一次性动作，真正让它长期有效的是回看。最少要留的：登录记录、关键后台的改动记录、对外接口的异常调用。注意日志里别写明文口令和完整凭据，否则留痕本身变成新的口子。

判断标准很直接：能不能回答「上周谁登过后台、改了什么」。答不上来，说明留痕还不够用。这套自查清单如果要做成长期跟踪的表，可以参考站内工具目录里的现成结构，到 /tools 看看哪类适合自己团队的规模。