攻击面是一张清单：十四个入口与它们的坏结局

一个人以为自己在写业务代码，其实每天都在替十四把钥匙值班。

一、一封域名过期邮件与十四把钥匙

2026 年 8 月 11 日晚上十点，他收到一封标题为「域名将在 72 小时后过期」的邮件。域名是三年前注册的，注册邮箱是一个只用来收通知的旧邮箱。他没有点邮件里的链接，而是手动打开注册商后台——这一步让他避开了钓鱼，却也看到了更麻烦的东西：这个旧邮箱同时是云账号、代码仓库和支付账号的找回邮箱。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他随后翻了这个邮箱的登录记录，发现三次来自陌生设备的尝试，都失败了。失败不代表安全：邮箱没有开二次验证，密码和另一个已经关停的论坛相同。一个入口，四把锁，其中三把是同一把。

那晚他打开一张空白表格，把「一旦失去就很难靠自己拿回来」的东西逐个写下来。写到第 14 行时停笔，因为再往下写都是同一类东西的变体。这 14 行里，过去三年写的业务代码只占一行：登录注册。

他原本以为攻击面是一张技术架构图，画完才发现它更像一份钥匙清单。架构图回答「系统由什么组成」，钥匙清单回答「谁能在你不注意的时候把门打开」。

分档也不是按技术复杂度。域名解析配置很简单，但域名被转走之后，邮件、支付、后台会一起失效；反过来，管理后台的代码最复杂，却有日志、有会话、有回滚。

这张表后来变成每季度 2.5 小时的固定动作。它不产生功能，不产生收入，但决定了另外 1,900 多个小时做出来的东西能不能留住。

第一次盘点他花了 2.5 小时，其中 40 分钟用在「找回流程」上：逐个打开 14 个入口的登录页，点一次「忘记密码」，看验证码发到哪个邮箱、哪个手机号。这一步比读架构文档有用得多。

二、十四个入口，三个档位

14 个入口按「坏结局能不能自己收拾」分三档。档位不描述可能性，只描述后果。

不可逆的 5 个里有 3 个指向同一处：注册邮箱。它不是「一个账号」，而是所有账号的最后一道找回路径。把它单独列出来，是因为很多人的域名、云账号、支付账号都挂在同一个邮箱上，而这个邮箱的密码可能八年没换。

高影响的 5 个共同点是「能改代码或数据」。CI 部署密钥尤其容易被低估：它通常是一个长期有效的令牌，放在仓库的 secret 里，谁拿到谁就能发布。代码仓库泄露只是读到源码，部署密钥泄露是直接上线。

中影响的 4 个不是不重要，而是有兜底。登录注册有锁定和限流，对外 API 有配额，Webhook 有签名，第三方 SaaS 可以撤销授权。它们的坏结局通常是「烦」而不是「没」。

分档会随阶段变化。只有 120 个付费用户时，管理后台被攻破的影响是 120 个租户；签下第一个企业客户后，同一件事要加上合同里的通知义务与审计条款。所以这张表每季度重打一次分，而不是一次定终身。

还有一个容易被漏掉的入口：自己的开发机。它不在 14 个里，因为它的坏结局通常先经过代码仓库或云账号放大；但如果开发机上有生产数据库的连接串，它实际上就是第 15 个入口。他把连接串从本地配置里移走，改用短期凭证，算是给这张表加了一条备注。

三、四十二格与一次打分

清单只有名字没有用。每个入口要回答三个问题，14 × 3 = 42 格，一格不能空。

三个问题是：最坏情况是什么、最低保护是什么、当前状态是什么。「最低保护」不是最佳实践，而是「做到这一条，坏结局就不会发生」的那一条。比如注册邮箱的最低保护是二次验证，不是「强密码」。

全量盘点一次 2.5 小时，一年四次就是 10 小时。第一次会慢，因为要找每个入口的登录页和管理员设置；第二次开始，大部分格子只需要确认「有没有变」。

42 格填完之后打分：可能性 1–5，影响 1–5，两者相乘。分数不是精确的风险值，只是把「先做哪个」变成一个可以争论的数字。

5 个 ≥15 分的先做，这是本季度唯一必须完成的清单。6 个 8–14 分的排进本季度，能做几个做几个；3 个 ≤7 分的写下一行接受理由，比如「Webhook 只收不发，伪造事件的后果是重复一次同步」。

接受理由要写在表里，不能只放在脑子里。写下来的作用是：下个季度重新打分时，你能看出当初的判断是哪一条错了，而不是笼统地觉得「当时太忙」。

分数会骗人。可能性 5 分的入口如果已经有二次验证和告警，实际风险可能低于可能性 3 分但完全没有日志的入口。所以打分之后还要问一句：这一格的「当前状态」是猜的，还是刚登录看过？

四、全年五十三小时

把七项投入按年相加，才知道安全占了多少时间。

复算：攻击面盘点 2.5 h × 4 季 = 10 h
密钥轮换：critical 4 个 × 4 次 × 18 分钟 = 288 分钟
　　　　　high 7 个 × 2 次 × 10 分钟 = 140 分钟
　　　　　合计 428 分钟 ÷ 60 = 7.13 h
依赖审计：618 分钟 = 10.3 h；加每月 20 分钟 × 12 = 4 h，共 14.3 h
限流：4 类 × 40 分钟 = 160 分钟 = 2.67 h（一次性）
日志与审计：5 h（一次性）
边界加固：8 h（一次性）
演练：4 次 × 1.5 h = 6 h
合计：10 + 7.13 + 14.3 + 2.67 + 5 + 8 + 6 = 53.1 h ≈ 53 h
占比：53 ÷ 1,920 = 2.8%

53 小时里只有 10 小时是重复发生的盘点，其余是轮换、审计和一次性改造。一次性的 15.67 小时集中在第一个季度，之后的年份只保留 10 + 7.13 + 14.3 + 6 = 37.43 小时。

为什么先做攻击面，而不是先买工具：工具解决的是「已知入口的已知问题」，清单解决的是「你根本不知道有这个入口」。他见过有人在 WAF 上配了 20 条规则，却忘了域名注册邮箱还是五年前的密码。

排序规则只有三条：≥15 分本季度做完，8–14 分排期，≤7 分写下接受理由。规则简单到不需要记，才能在每次被打断之后重新捡起来。

2.8% 不代表安全便宜，只代表「在 1,920 小时里挤出 53 小时是可行的」。真正贵的是事件：一次供应链事件按 40 小时计，接近全年安全投入的 75%。53 小时买的是不触发那 40 小时的概率。

如果一年只能做一件事，他会选「给注册邮箱和云根账号开二次验证」。这两个动作各只需要一次设置和一次找回流程演练，却覆盖了不可逆档里最容易被接管的两把钥匙。

清单的价值不在长度，而在更新频率。一季度一次、每次 2.5 小时，比一年一次、每次十小时更能发现「新长出来的入口」——比如半年前接的那个第三方 SaaS。

五、行动清单与复算验收

• 列出全部入口，按「能否自己恢复」分成不可逆、高影响、中影响三档。
• 给每个入口填三格：最坏情况、最低保护、当前状态。
• 逐个走一遍「忘记密码」，确认验证码落到哪个邮箱或手机号。
• 用可能性 × 影响打分，把 ≥15 分的排进本季度。
• 给 ≤7 分的入口写一行接受理由，保存在表里。
• 把注册邮箱、云根账号、支付账号的二次验证全部打开。
• 在日历上固定每季度 2.5 小时的盘点，写进日程而不是待办。
• 年底把七项投入相加，核对是否仍接近 53 小时。

验收标准：任取一个入口，都能在 2 分钟内说出它的坏结局、最低保护和当前状态，并知道它上一次被检查是哪一天。

前四条是「把表建起来」，后四条是「让表活着」。如果只有半天，先做第一条和第三条；没有清单，后面的打分和预算都没有落点。

清单不要一次填满 42 格。第一周只填不可逆的 5 个入口，第二周补高影响，第三周才轮到中影响；一次填完的结果通常是三天后再也不打开。

使用边界与实操验收

清单会过期。 新接入一个 SaaS、换一次支付服务商、加一个子域名，都会长出新的入口。判断标准很简单：如果这次变更需要一个新的登录，它就应该进表。

分档是相对的。 同一个入口在 120 个付费用户和 1,200 个付费用户时不是同一档；分档描述的是「坏结局能否自己收拾」，不是「技术难度」。

打分是排序工具。 可能性与影响都是主观估计，5 分和 4 分之间的差别没有意义；有意义的是 ≥15 与 ≤7 之间那条线，它决定了本季度做什么。

53 小时是教学基线。 它来自本组统一口径的 1,920 小时与七项投入，不构成对任何产品安全成本的预测，也不构成安全承诺。

不替代专业评估。 涉及数据跨境、行业监管或合同审计时，清单只能作为输入；具体义务以司法辖区与专业意见为准。

关键参考与核验范围

• OWASP Top Ten ：用于说明 Web 应用最常见的风险类别，不用于推导本文的 14 个入口。
• OWASP ASVS ：用于核对认证、会话与访问控制的验证项。
• CWE Top 25 ：用于说明不可逆操作与权限边界常见的缺陷类型。
• CISA KEV Catalog ：用于说明已被实际利用的漏洞应优先于评分排序。

以上链接于 2026-10-26 实测可公开访问；未核验版本与条款变更。核验日期：2026-10-26。

边界句。 本文只讨论一个人的攻击面盘点、分档与投入排序，不讨论渗透测试方法、具体攻击步骤与合规认证。

系列导航

• 下一篇：认证：密码、魔法链接、OAuth 与一次账号枚举
• 回到目录：一个人的安全基线：十四个入口、十七个密钥与一次 72 小时响应
• 相关阅读：独立开发者的资产韧性：一个人的账号、数据与恢复能力