内容摘要：去年秋天，我在一个安全沙龙上碰到老周。他盯着投影幕布上一张BCBusiness Continuity，业务连续性）渗透的拓扑图，突然冒了句：“这不就是给系统做肠镜嘛——从嘴里进去，看看到底哪段堵了。”

去年秋天，渗透我在一个安全沙龙上碰到老周。渗透他盯着投影幕布上一张BC（Business Continuity，渗透业务连续性）渗透的渗透拓扑图，突然冒了句：“这不就是渗透给系统做肠镜嘛——从嘴里进去，看看到底哪段堵了。渗透”旁边几个人笑了，渗透但我觉着这比喻挺准。渗透

BC渗透跟常规渗透测试最大的渗透区别，不在于工具，渗透在于目标。渗透常规渗透是渗透找漏洞、拿权限、渗透写报告。渗透BC渗透的渗透出发点不是“能黑进去吗”，而是“如果这里真断了，业务能扛多久”。老周他们团队接过一个单子，某城商行的核心交易系统。客户一开始要求按标准渗透流程走一遍，老周说行，但加了个条件：每打穿一层，就掐着秒表记录业务降级的时间窗口。结果测到中间件层的时候，发现一个配置缺陷——主备切换脚本里写死了一个内网IP，那台机器早在半年前就下线了。也就是说，真出故障时，自动切换根本不会触发，得靠人工发现、人工介入。这个时间差，客户自己从来没测过。

做BC渗透，第一步不是扫端口，是画业务流。你得知道钱从哪进、从哪出、中间经过几个系统、每个系统的RTO（恢复时间目标）和RPO（恢复点目标）是多少。这些数字在运维文档里往往写得漂亮，但实际环境里全是水分。我见过一个电商平台，文档写RTO是15分钟，结果渗透时把主数据库网线拔了，从库升主用了47分钟——因为从库的binlog同步延迟在高峰期能到半小时。运维的人自己都不知道。

渗透路径的设计也有讲究。常规渗透喜欢找最短路径拿shell，BC渗透更关心“单点故障”。比如你发现一个Redis未授权访问，常规思路是写SSH key拿服务器。BC思路是：这个Redis挂了，哪些业务会受影响？有没有降级方案？降级方案本身是否可靠？我试过一次，某物流公司的订单队列用Redis做缓冲，主从模式，但哨兵配置里quorum设成了1。这意味着任何一个哨兵误判，都会触发切换。而切换过程中，那几秒的写入丢失，对订单系统来说就是灾难。这个配置问题，扫描器扫不出来，只有从业务连续性角度去推，才能发现。

工具层面，BC渗透没什么神秘武器。nmap、burp、自己写的脚本，够用了。真正花时间的是梳理依赖关系和验证恢复流程。有一次为了测一个支付网关的故障转移，我们硬生生把它的主节点网卡down了三次，每次等业务完全恢复再记录时间。第三次的时候，发现数据库连接池有个泄漏，每次切换后连接数涨一点，三次之后连接池满了，新交易全部阻塞。这个问题在正常渗透里根本不会触发，因为你不去反复折腾它的故障恢复路径。

报告写法也不一样。常规渗透报告按漏洞等级排，高危在前。BC渗透报告按业务影响排，一个中危漏洞如果卡在关键恢复路径上，优先级可能比一个高危SQL注入还高。客户要的不是“你黑进来了”，而是“我哪里会断，断了多久能回来，回来之后数据对不对”。

老周后来跟我说，BC渗透做多了，看系统的眼光会变。以前看到一台服务器，想的是怎么进去。现在看到一台服务器，想的是它死了之后，谁替它收尸。这话糙，但理不糙。