谁往我的补丁里塞了漏洞？

为什么更新救不了你

欢迎来到安全剧场

每一份安全补丁对防御者和攻击者来说都各具意义。在每一个“修复”中，不可避免地会潜入新的变动——而这些代码依然是由那些和原版一样容易出错的材料构成的。

更糟糕的是，补丁本身就是给攻击者的蓝图！代码变更包含的二进制差异，就像行为变更一样容易被比对。它们是逆向工程的绝佳素材。

警告：补丁可能包含今天的修复（以及绝对包含明天的漏洞）。

现实比我想象的要混乱得多。去问问任何资深系统管理员关于快速更新的看法，你都会听到他们用血泪换来的教训：“等六个月。别给他们当免费的测试员。”

让我们花点时间来体会一下 IT 团队的两难境地：

补丁同样能搞死系统——根本不需要攻击者出手。

2024 年 7 月的 CrowdStrike 事件证明了一个残酷的事实：当未经测试的代码导致关键基础设施崩溃时，遵循所谓的“最佳实践”并不能提供豁免权。在短短几小时内，全球航班停飞，医院陷入瘫痪。

但无视补丁？那等同于保证已知的漏洞会被利用。

在安全上砸钱往往适得其反。复杂且层叠的控制措施变得无法管理，也无法监控。

投入多少才算合适？什么样的控制才是最优的？安全与易用性之间完美的平衡点在哪？

视情况而定。（没错，咨询顾问最喜欢的回答。）

但这其实是个好消息：个性化的风险管理每一次都能击败那种“一刀切”的方案。

别再搞那些花架子，开始主动进行风险管理。

确定并记录所有关键事项：

是否存在普适的最佳实践？有的，尽管具体实现各异：

关键考量因素

为所有用户采用像 YubiKey 这样的硬件安全密钥，或者至少强制使用 passkey。
- OTP（动态口令）容易受到社会工程学攻击；硬件令牌则不然。
- 在所有服务上普遍强制要求 MFA。
稳健且经过验证的备份。
- 确保云基础设施拥有离线备份——理想情况下是不可变的且地理分散的。
  - “离线”意味着跨供应商或跨账号（例如，在 GCP 或 Azure 中备份 AWS 数据，或使用 Backblaze B2 等第三方方案）。
- 将备份策略扩展到员工设备，考虑到像会议室 Wi-Fi 不可靠这种恢复场景（需与 SLA 和恢复目标保持一致）。
每季度进行一次恢复演练：利用备份、快照和基础设施即代码（IaC）工具，在未使用的区域恢复完整的基础设施。
在任何真实凭据旁边放置 CanaryTokens，以便在入侵开始时第一时间获知。

了解你的风险概况：你保护的是什么数据？哪些威胁真正相关？你能承受多长时间的停机？恢复和重建哪个成本更低？

审视你的实际暴露面：

一个乏味的真相：安全是层层堆叠的，没有银弹。纵深防御、离线备份、灾难演练、补偿性控制。将补丁视为必要的恶，而不是万灵药。