00:00:00
资料库 · 防御、泄露与事件响应
第 ⑤ 卷，条目 81–100。这一卷的来源比前四卷杂，原因在总览里说过：Schneier 的站点挡了抓取（403），Google 安全博客的域名被安全策略拦住，只从镜像 feed 拿到几条。所以我用 Let's Encrypt、GitHub Security、Mozilla 和 Troy Hunt 补上了缺口。
这一卷讲的是别人已经踩过的坑：数据泄露之后发生什么、证书和 PKI 生态往哪走、供应链攻击的现实形态、以及 AI 带来的新攻击面。和前四卷相比，这一卷的内容更接近"该建立什么流程"而不是"该修什么代码"。
数据泄露与披露
81. 1,000 Data Breaches Later, the Disclosure Lag is Worse Than Ever
来源：Troy Hunt（Have I Been Pwned 创办者）。
读它解决什么：处理过一千次数据泄露之后，对"企业多久才承认"这件事的观察。
要点：
- 基于处理约 1000 起泄露事件的经验，结论是披露延迟比以往更严重
- 作者运营 Have I Been Pwned，掌握大量泄露样本
我的补充：这条的数据基础在这个领域几乎是独一份的——没有几个人手里有一千起泄露事件的一手样本。披露延迟恶化对普通人的实际含义是：你的凭据可能在泄露发生后很久才被通知，而攻击者在这段时间里已经用完了。所以个人层面的防御不能依赖通知：每个站点用不同密码（这样单点泄露不扩散，是唯一能自己掌控的措施）、开启 MFA、定期在 HIBP 上查自己的邮箱。企业层面的含义是：披露流程要在事故之前准备好（对外沟通模板、法务口径、通知渠道），事发时才写就必然拖延——而拖延本身会造成第二轮信任损失，通常比技术损失更难恢复。
82. Swimming Pools, Pee, and Trying to Delete Your Data From the Internet
来源：Troy Hunt。
读它解决什么：想搞清"要求删除我的数据"这件事在现实中能做到什么程度。
要点：
- 讨论从互联网上删除个人数据的困难
- 用泳池与尿液的类比来说明数据一旦扩散就无法收回
我的补充：那个类比虽然粗俗但准确：数据一旦泄露就无法收回。泄露的数据库会被无数次转手、镜像、打包重售，删除请求只能作用于原始持有者，对已扩散的副本毫无作用。这对系统设计有一个非常实际的推论：不收集的数据才是安全的数据。审视自己的产品时值得逐字段问：这个字段真的需要吗？需要存多久？能不能存哈希而不是原文？能不能存"年龄段"而不是"出生日期"？这是唯一能真正降低泄露影响的手段，其他措施都只是降低泄露概率。
83. Weekly Update 517: Cyber Ransoms
来源：Troy Hunt，周更系列第 517 期。
读它解决什么：勒索相关的近期动态与讨论。
要点：
- 周更节目，本期主题涉及网络勒索
- 517 这个期数说明这个系列已持续近十年
我的补充：关于付不付赎金：付了不保证拿回数据（解密工具可能不工作），不保证数据不被公开（双重勒索是常态），而且资助了下一轮攻击。但真正到了那一刻，"不付"这个选择往往不在技术人员手里。所以唯一有意义的工作是在事发之前：离线且经过恢复演练的备份。注意两个限定词——离线（否则勒索软件会一起加密掉，这是最常见的失败形态），以及演练过（没恢复过的备份不算备份，我见过备份跑了两年、真要用时发现某个关键库一直没被包含）。
84. Weekly Update 514: This Week in Data Breaches
来源：Troy Hunt，周更系列第 514 期。
读它解决什么：近期数据泄露事件的汇总讨论。
要点：
- 周更节目，本期集中讨论当周的数据泄露
- 反映泄露事件的常态化频率
我的补充：这个系列每周都有新泄露可讲，这个事实本身就是最重要的信息。它意味着泄露不是异常事件而是基础环境假设——你的用户的邮箱和密码组合大概率已经在某个泄露库里了。这直接推导出两个防御措施：撞库防护（对认证端点做速率限制、异常检测；把已泄露密码库接入注册和改密流程，拒绝已知泄露的密码——HIBP 提供了这个 API，且用 k-anonymity 设计，不需要把用户密码发给它）。这比"教育用户设置强密码"有效得多。
85. Weekly Update 513: Clauding The Home Network
来源：Troy Hunt，周更系列第 513 期。
读它解决什么：把 AI 助手接进家庭网络的实践与安全考虑。
要点：
- 周更节目，主题涉及在家庭网络中使用 AI 助手
- 标题的 "Clauding" 指使用 Claude
我的补充：把 AI 助手接入自己的网络和设备，安全上的核心问题是权限边界：它能读什么、能改什么、出错时最坏能造成什么。这里最容易被低估的风险是间接提示注入（见第 95、96 条）——助手读到的任何外部内容（网页、邮件、设备日志）都可能包含针对它的指令，而它无法可靠区分"我该处理的数据"和"给我的命令"。所以给 AI 工具的权限要按最坏情况来设：能读日志但不能改配置，能查询状态但不能重启设备。这个原则和给第三方服务发 API key 时的思路一致，只是 AI 的输入面更宽。
86. Weekly Update 512: IoT Lockout Fail
来源：Troy Hunt，周更系列第 512 期。
读它解决什么：一个 IoT 设备把用户锁在外面的失败案例。
要点：
- 周更节目，主题是 IoT 设备的锁定失败
- 属于具体案例讨论
我的补充：IoT 的安全设计有一个和普通软件不同的约束：失效模式必须考虑物理世界。智能锁云服务挂了应该开还是关？智能灯的服务停了应该亮还是灭？这些不是纯技术问题。更常见的现实问题是厂商停止服务后设备变砖——你买的是硬件，但它的功能依赖厂商的云。选购时的实际标准：能不能脱离云工作（本地控制、支持 Matter/Zigbee 这类本地协议）。这一条也适用于给自己的系统做设计：任何依赖外部服务的功能，都要定义清楚那个服务不可用时的行为。这个博客里调用第三方 API 的地方我都加了超时并有降级路径，理由相同。
87. Welcoming the Nepalese Government to Have I Been Pwned
来源：Troy Hunt。
读它解决什么：又一个政府机构接入 HIBP 的公告。
要点：
- 尼泊尔政府成为 HIBP 的政府用户
- HIBP 向政府机构提供其域名下账号的泄露查询
我的补充：这个项目的机制值得知道：政府机构可以监控本国政府域名下的邮箱出现在哪些泄露里。为什么这有价值——公务人员用工作邮箱注册第三方服务，那个服务泄露了，凭据就成了针对政府系统的撞库素材。这个模式对企业完全适用：HIBP 的域名搜索功能可以让你监控自己公司域名下的账号出现在哪些泄露中。这是一个成本极低、覆盖面很实在的检测手段，很多安全团队没用上。
88. Welcoming the Philippine Government to Have I Been Pwned
来源：Troy Hunt。
读它解决什么：菲律宾政府接入 HIBP 的公告。
要点：
- 菲律宾政府成为 HIBP 的政府用户
- 与第 87 条同类型
我的补充：这类公告连着看，能看出一个趋势：泄露监控正在从"个人自查工具"变成机构级的基础设施。这背后是威胁模型的变化——针对机构的攻击越来越多从"打穿边界"变成"用泄露凭据直接登进去"，因为后者成本低得多且不触发入侵检测（对系统来说那就是一次正常登录）。所以检测重心也要跟着变：关注异常登录（新设备、异常地理位置、非工作时间、不可能的移动速度）比关注网络层入侵信号更贴近当前的攻击形态。
证书、PKI 与信任基础设施
89. Decreasing Certificate Lifetimes to 45 Days
来源：Let's Encrypt，2025 年 12 月。
读它解决什么：证书有效期缩短到 45 天，对运维意味着什么。
要点：
- Let's Encrypt 将证书有效期从 90 天降到 45 天
- 是业界证书生命周期持续缩短趋势的一部分
我的补充：缩短有效期的根本原因是吊销机制不可靠。CRL 太大、OCSP 有隐私问题和可用性问题（OCSP 软失败等于攻击者阻断查询就能绕过），所以行业选择了另一条路：让证书自己快速过期，用短生命周期代替吊销。运维上的含义很直接：自动续期不再是可选项。45 天的周期意味着人工续期必然出事（忘记、人员变动、脚本坏了没人发现）。要做的是：ACME 客户端自动续期 + 到期前的监控告警（不要只依赖续期成功，要独立监控实际证书的剩余天数）。我见过太多次故障是"证书过期"，而每一次事后都会说"下次一定自动化"。
90. Shorter Certificate Lifetimes and Rate Limits
来源：Let's Encrypt，2026 年 2 月。
读它解决什么：证书变短之后，速率限制怎么调整。
要点：
- 讨论更短的证书生命周期与速率限制的关系
- 有效期减半意味着签发请求量翻倍
我的补充：这是个容易被忽略的连带影响：有效期减半，签发量翻倍，速率限制的余量就变紧了。管理很多域名的人要注意：如果你的续期都堆在同一天（比如都是某次批量申请的），45 天周期下更容易撞到限额，然后一批证书同时续期失败。做法是把续期时间打散（ACME 客户端一般会在有效期过一半时就尝试，这本身就提供了缓冲窗口），并且监控续期失败而不只监控证书过期——失败发生时你还有二十多天可以处理，等到过期就是直接故障了。
91. Simplifying Certificate Renewals for Millions of Domains with ACME Renewal Information (ARI)
来源：Let's Encrypt，2026 年 3 月。
读它解决什么：ARI 是什么，它怎么改善大规模证书续期。
要点：
- 介绍 ACME Renewal Information（ARI）机制
- 已于 2025 年 9 月发布为 RFC 9773
我的补充：ARI 解决的是一个真实的协调难题：CA 需要紧急吊销一批证书时，怎么让几百万客户端及时续期而不把服务器打挂。ARI 的做法是让 CA 通过一个端点告诉客户端"你该在这个时间窗口内续期"，CA 就能主动打散负载、也能在紧急情况下让客户端提前续期。运维上要做的很简单：用支持 ARI 的 ACME 客户端（新版 Certbot、lego、Caddy 都支持）。这样遇到 CA 侧的大规模吊销事件时，你的续期是被自动引导的，不需要人工介入——这类事件历史上发生过好几次，每次都造成一片手忙脚乱。
92. A Post-Quantum Future for Let's Encrypt
来源：Let's Encrypt，2026 年 6 月。
读它解决什么：Web PKI 的后量子迁移计划。
要点：
- Let's Encrypt 的后量子密码学规划
- 2026 年 6 月发布
我的补充：后量子迁移的紧迫性分两块，要区分清楚。密钥交换是紧迫的——因为"现在录下流量，等有量子计算机了再解密"（store-now-decrypt-later）是现实威胁，所以 TLS 的密钥交换已经在部署混合后量子方案（Chrome 和 Firefox 都已默认启用 X25519+ML-KEM）。签名（也就是证书用的）没那么紧迫，因为签名只需要在证书有效期内安全，而后量子签名的体积大得多（会显著增加握手数据量）。所以你现在能做的：确保 TLS 库和终端能协商混合后量子密钥交换，证书这块跟着 CA 的节奏走就行。顺带说，第 89 条那个 45 天有效期对后量子迁移也是有利的——生命周期越短，换算法时的过渡期越短。
93. Improving Transparency and Assurance in the Web PKI: Mozilla Root Store Policy v3.1
来源：Mozilla Security Blog，2026 年 6 月。
读它解决什么：浏览器对 CA 的要求在收紧，v3.1 改了什么。
要点：
- Mozilla 根证书存储策略 v3.1，主题是透明度与保证
- 承接 2025 年 3 月的 v3.0
我的补充：根证书存储策略是整个 Web 信任体系的实际执法机制。CA 的约束力不来自法律，来自"浏览器会不会信任你"——历史上有多家 CA 因为违规被移出信任存储，直接终结了业务（Symantec、WoSign、DigiNotar）。对普通开发者的实际含义有两点：一是不要自己维护根证书列表（跟不上策略更新和吊销），用系统或语言运行时提供的；二是内网自签 CA 要有和公共 CA 同等的纪律——私钥保护、有效期控制、可吊销。我见过内网 CA 的私钥躺在共享盘上、有效期设二十年，那等于给内网所有 HTTPS 加了一个永久后门。
94. Firefox will upgrade more Mixed Content in Version 127
来源：Mozilla Security Blog，2024 年 6 月。
读它解决什么：浏览器如何自动把 HTTP 子资源升级到 HTTPS。
要点：
- Firefox 127 起自动升级更多混合内容
- 混合内容指 HTTPS 页面中加载的 HTTP 资源
我的补充：混合内容的危害是它让整页的 HTTPS 保护失效——页面本身加密了，但里面一个 HTTP 加载的脚本可以被中间人替换，于是攻击者照样能控制页面。浏览器自动升级（把 http:// 请求改成 https://）是个务实的方案：多数站点已经支持 HTTPS，升级后就直接可用。给站点维护者的建议：别依赖浏览器的自动升级（各浏览器行为不一致，且升级失败时的降级行为不同），自己设 Content-Security-Policy: upgrade-insecure-requests 明确表达意图，并且从模板里彻底清掉写死的 http:// 链接。检查方法：控制台的混合内容警告，或者用 CSP 的 report-only 模式收集实际情况。
AI 时代的新攻击面
95. AI threats in the wild: The current state of prompt injections on the web
来源：Google 安全博客，2026 年 4 月。
读它解决什么：提示注入在真实网络环境中的现状，不是理论讨论。
要点：
- 描述提示注入在野的当前状态
- "in the wild" 表示基于真实观测而非实验
我的补充：提示注入的根本困难在于 LLM 没有可靠的指令与数据边界。传统注入（SQL、命令）有明确的解法：参数化查询把代码和数据彻底分开。而 LLM 的输入就是一段文本，"这是要处理的内容"和"这是给你的命令"在同一个通道里，目前没有等价于参数化的机制。所以现实的防御只能是架构层面的：假设注入会成功，然后限制它能造成什么——最小权限（代理只有完成任务必需的权限）、危险操作需要人确认、以及不要把"读取不可信内容"和"执行高权限操作"放在同一个代理里。后者是最关键的一条：能读网页又能发邮件的代理，就能被网页上的一段文字指挥去发邮件。
96. Google Workspace's continuous approach to mitigating indirect prompt injections
来源：Google 安全博客，2026 年 4 月。
读它解决什么：一个大型产品如何持续缓解间接提示注入。
要点：
- Google Workspace 缓解间接提示注入的方法
- 标题的 "continuous" 表明这被当作持续过程而非一次性修复
我的补充：间接提示注入是这里的关键词：注入内容不是用户输入的，而是藏在 AI 读到的文档、邮件、日历邀请里。这个场景对办公套件特别致命——AI 助手的价值就在于能读你所有的文档和邮件，而这些内容中的任何一份都可能来自外部（一封陌生人的邮件、一个共享文档）。"持续"这个定语值得注意：它承认了这个问题没有一次性的解法，只能靠持续检测与缓解叠加。给部署 AI 工具的人的实际结论：给助手接入数据源时，逐个评估"这个数据源里的内容是否可能由外部人员写入"。邮件、共享文档、客服工单、评论区全都是——这些接入之后，助手的行为就部分受外部人员控制了。
97. What 50 open source projects taught us about security in the AI era
来源：GitHub Security Blog。
读它解决什么：从 50 个开源项目的实践中总结 AI 时代的安全经验。
要点：
- 基于 50 个开源项目的观察
- 主题是 AI 时代的安全实践
我的补充：AI 给开源项目带来的最直接变化是低质量报告的洪水——用 AI 生成的"漏洞报告"数量激增，其中大量是幻觉出来的不存在问题，或者把扫描器的误报包装成报告。维护者的时间被这些消耗掉，真正的报告反而更容易被埋掉。这不是假设，多个知名项目的维护者公开抱怨过。对维护者的实际做法：要求可复现的 PoC 作为受理门槛（不能复现就不进入排队），这一条能过滤掉绝大部分噪音。对报告者的提醒：用 AI 辅助分析可以，但提交前必须自己验证——提交未验证的报告是在消耗别人的时间，而且会损害你后续报告的可信度。
供应链安全
98. Disrupting supply chain attacks on npm and GitHub Actions
来源：GitHub Security Blog。
读它解决什么：平台方如何应对 npm 与 GitHub Actions 上的供应链攻击。
要点：
- GitHub 应对 npm 与 GitHub Actions 供应链攻击的措施
- 两个生态都是攻击的高频目标
我的补充：GitHub Actions 是被严重低估的攻击面。用第三方 action 等于在你的 CI 里执行别人的代码，而 CI 通常持有仓库写权限、发布凭据、云访问权限——比生产服务器的权限还大。必须做的几件事：用 commit SHA 固定 action 版本（uses: foo/bar@a1b2c3d 而不是 @v3，因为 tag 是可以被移动的，攻击者拿到仓库权限后把 v3 指向恶意提交，你什么都没改就中了）、给 workflow 的 permissions 显式收窄（默认权限过宽）、发布用 OIDC 短期令牌而不是长期 secret、警惕 pull_request_target（它在特权上下文里跑，且能被 fork 的 PR 触发）。这条和 编程卷第 42 条 那次 arrayref 攻击是同一个战场的不同生态。
99. The case for a cooldown: Why Dependabot now waits before issuing version updates
来源：GitHub Security Blog。
读它解决什么：为什么依赖更新工具现在会等一段时间才提 PR。
要点：
- Dependabot 引入冷却期，新版本发布后不立即提交更新 PR
- 文章为这个设计给出理由
我的补充：这个设计看起来反直觉但很聪明。恶意版本的典型生命周期是几小时到几天：发布、被发现、被下架。如果你的机器人在发布后五分钟就提 PR、CI 自动跑过、然后自动合并，你就成了最早的受害者之一。等 几天再更新，绝大多数恶意版本已经被下架了，而多等几天带来的安全风险几乎为零（除了真正的紧急安全补丁，那些应该走单独的快速通道）。这里有个更普适的原则：自动化的速度不总是优点。在供应链这个场景里，"慢一点"本身就是一种防御——因为你在借用整个生态的检测时间。
100. Tame Dependabot: Group your updates, slow the cadence, keep security fast
来源：GitHub Security Blog。
读它解决什么：依赖更新 PR 太多没人看，怎么配置到可持续。
要点：
- 讲如何配置 Dependabot：分组更新、降低频率、但保持安全更新的速度
- 标题本身就是三条建议
我的补充：这条解决的是一个真实且普遍的失败模式：Dependabot 默认配置会产生大量 PR，团队看不完就开始无脑合并或者全部忽略——两种结果都很糟（前者是自动引入未审查的变更，后者是安全补丁也被忽略了）。标题里的三条建议正好对应解法：分组（把同一生态的补丁版本合成一个 PR）、降低常规更新频率（月度而不是每天）、安全更新走快速通道（保持即时）。这个区分是关键——把"常规版本升级"和"安全补丁"当成两类东西处理，前者可以慢、可以攒，后者必须快。这也和 编程卷第 86 条"提高频率降低难度"不矛盾：分组降频的同时保持了固定节奏，不至于攒成一次大升级。
本卷小结
三个带走的结论：
- 不收集的数据才是安全的数据。 泄露之后无法收回（第 82 条），披露延迟还在恶化（第 81 条）。逐字段审视"这个真的要存吗、要存多久、能不能存哈希"，是唯一能降低泄露影响的手段。
- 证书自动化不再是可选项。 有效期已降到 45 天并且还会更短（第 89 条），人工续期必然出事。用支持 ARI 的客户端，并独立监控实际剩余天数而不只监控续期任务成功。
- 提示注入没有参数化查询这种解法。 只能靠架构限制损失：别把"读取不可信内容"和"执行高权限操作"放进同一个代理（第 95 条）。给 AI 接数据源前，先问这个源里的内容能不能由外部人员写入。
上一卷： ← ④ 漏洞研究与利用链 · 回到 安全资料库总览