在 CCoP 2.0 下，文件接入是什么样子

本地区的每一套控制措施都要求纵深防御，新加坡针对关键基础信息基础设施的 Cybersecurity Code of Practice 也不例外。这类说法之所以能在评审会议中存活下来，是因为没人能反对它。

如果按字面理解，它说的是一条链中控制措施的类型，而不是数量。在大多数安全场景里，这种区别几乎不起作用，因为各层确实不同, 防火墙、身份控制和终端代理并不是同一种思路的变体。但在文件接入场景里，这个区别非常重要，因为组织往往会叠加三四层控制，而这些控制用同一种方法回答同一个问题。

谁在适用范围内，以及发生了什么变化

Cybersecurity Act 2018 赋予新加坡网络安全局权力，可在能源、信息通信、水务、医疗保健、银行与金融、安全与应急服务、航空、陆路交通、海事、政府和媒体这 11 个行业中指定关键基础信息基础设施。只有被指定后，Code of Practice 才会从指导性文件变成法定义务。

Cybersecurity (Amendment) Act 2024 大幅扩大了适用范围。自 2025 年 10 月 31 日起，新的 Part 3A 将适用于并不拥有其所依赖基础设施的基本服务提供商，以及云服务提供商和数据中心运营商。如果贵组织几年前曾认为该制度属于别人，因为你们是租用而不是自有，那么这个结论值得重新核查。

CSA 于 2026 年 7 月 22 日宣布，Code 将再次更新，以应对高级持续性威胁和 AI 赋能攻击，同时还会按同一时间表推出一份单独的 Cloud Services Code。该公告还提到了与更新后的 Code 相关的 Cyber Trust Mark Level 5 认证，这一点值得关注, 一个自愿性标识如果与具有约束力的文件并列出现，往往会变成所有向该行业销售产品的供应商的采购筛选条件，不论是否已被指定。

文件实际从哪里进入

“File ingress” 听起来像是一件事。在 CII 环境中，它通常有七种，而且很少由同一个团队负责。

1. Email attachments，这是每个人都考虑过的路径，也是大多数控制图里唯一会画出来的路径。
2. Supplier and customer portals: 上传表单、理赔提交、投标响应、入职文件。通常由应用团队构建，防护措施取决于当天应用框架提供了什么。
3. Managed file transfer and scheduled exchanges with counterparties, 其控制设计围绕可用性和对账，而不是内容。
4. OT vendor material: 固件镜像、配置文件、PLC 项目文件、调试文件。这个路径带来的后果最严重，检查却最少，因为格式是专有的，而且维护窗口很短。
5. Removable media at the IT and OT boundary，正式 policy 通常禁止，但实际操作通常会容纳，因为供应商工程师已经带着笔记本电脑和截止时间到了。
6. Cloud storage and collaboration surfaces 与第三方共享，文件到达时并没有经过运营人员会视为边界的任何东西。
7. Backup and restore paths，它们会重新引入在更早某个时间点被接纳的文件，沿用当时存在的任何控制措施。

把这七条路径按你自己的环境逐一写下来，再去争论引擎。这个练习往往比任何产品比较更能消除风险，因为常见发现不是某个控制很弱，而是七条路径里有三条根本从未纳入任何控制范围。

为什么把相似控制叠加起来不算纵深防御

先选一条已经有防护的路径，再看是谁在防护它。

典型的入站链路会先经过一个网关引擎，再经过一个使用不同供应商特征库的第二个引擎，然后可能还有一个 sandbox。三个产品，三张账单，三个仪表板。问它们各自在回答什么问题，答案是一样的: 这个文件是否恶意？问它们各自如何判断，方法也很相似: 基于已知恶意样本的模式匹配、对结构的启发式分析，以及在文件可能会也可能不会暴露自身的环境中观察到的行为。

如果两个控制措施使用同一种方法，它们也会共享这种方法的盲点。基于特征的检测会落后于新样本，落后多久取决于样本被收集、分析和分发所需的时间，而再加一套特征库只能缩短这个窗口，不能关闭它。sandbox 的效果取决于它的设计, 如果文件会识别 sandbox，或者会等待，或者需要一次 sandbox 不会执行的点击，那么它就会表现得毫无问题。把它运行两次，只会得到两次同样的良好表现。

三个控制措施对同一个问题进行采样，本质上是一次一致性测试。它告诉你这些引擎彼此一致，但并不能告诉你文件是安全的。而在一份要求纵深防御的 Code 下，这只是同一层，却被报告成了三层。

从“深度”这个说法所声称的意义上讲，至少需要链条中的一个控制点以完全不同的路径得出其判定。这是一类方法，不是某个产品，而且有好几种：按文件类型和来源进行 allowlisting，使意外格式根本无法到达解析器；通过协议断开，强制内容被重新创建而不是转发；按照文档格式规范进行确定性重建，使一份从未有人见过的文件与一份人人都见过的文件得到相同结果；将渲染步骤隔离开来，使解析发生在一个无关紧要的地方。

每一种都有真实成本，值得把它们说清楚，而不是假装不存在。Allowlisting 会产生例外，而例外会不断累积，直到名单只剩装饰作用。协议断开会增加延迟，OT 维护窗口未必能够容忍。重建会改变文件，这在交易对手期望字节级一致的文档，或者希望签名得以保留时尤为重要。隔离只是转移风险，而不是消除风险。基于对这些成本的诚实判断所选出的控制集合，在医院里和在港口里会很不一样。

能通过评估的解读

CCoP 要求持续监控、覆盖 IT 和 OT 的行为异常检测，以及足以支持按需调查和审计验证的保留能力。这些义务关乎看见和证明。上面的深度论点关乎决策，而两者在一个实际点上交汇, 评估人员询问某条路径如何受到防护时，会接受一串相似引擎的链条，但这条链条的描述会自己写成一句话，而这句话就是，这条路径上的一切都以同样的方式被决定。

对于金融机构，MAS Technology Risk Management Guidelines 以不同措辞提出了并行期望, 通过 email、upload portal 或 third-party exchange 到达的 untrusted files，会在边界处被处理，而不是先放行再事后审查。

这两份文件都没有点名某种技术，也不应该点名。它们最终要问的都是，运营方是否能够描述文件所经过的路径，以及在每一步对它应用了什么推理。七条路径，每一步一种方法，并且在方法重复的步骤旁做出诚实说明, 这份文档只需要一个下午就能写完，而它正是让其余对话变得合理的那份文档。

更完整的控制映射和文档细节见我们的 Singapore compliance page。