关键见解
- CSCF v2026 已将边界范围扩大，根据架构类型的不同，将客户客户端连接器（例如API 端点、中间件和文件传输客户端）纳入了 14 项控制措施的范围
- CSCF v2027 延续了这一扩展范围，共包含 32 项控制措施，其中 26 项为强制性要求，这为 2027 年 7 月至 12 月的认证窗口期做好了准备。
- 对于早于 v2026 的架构分类，若存在客户客户端连接器或其他导致范围变更的因素，可能需要重新评估；评估人员将审查第二个范围扩展周期
- 针对扩展边界的一项实用安全原则是：在文件和数据流到达关键支付基础设施之前，对其进行检查、清理和控制。
- 这些流程中的检查点可为记录、监控和核证提供有用的证据，尽管合规责任仍由该机构承担
为2027年CSCF评估做准备
大多数连接到Swift系统的机构都能从内存中绘制出其Secure 区域：消息传递接口、跳转服务器，以及承载支付流量的强化分段。这是该组织中防御最为严密的区域之一。CSCF v2027则关注通向该区域的所有路径的防御强度如何。
最大的变化已经发生。2025年7月发布的CSCF v2026规定，必须分阶段实施控制项2.4“后台数据流安全”，并将客户客户端连接器纳入了14项控制措施的范围。
现有的传统后台数据交换目前仍仅为建议性质，暂定于2028年实施强制性过渡。 当前框架涵盖七项原则下的32项安全控制措施，其中26项为强制性要求，而扩展后的范围将延续至2027年周期。2026年7月发布的CSCF v2027版本虽未新增强制性控制措施，但将“机密与密钥Vault （SKV）”纳入了其中大部分控制措施的适用范围。 建议性控制措施仍属于推荐实践，但在后续版本中可能成为强制性要求。各机构将于2026年7月至12月期间首次针对扩展后的范围进行合规认证，而v2027版本的合规认证窗口期为2027年7月至12月，并需经独立评估支持。
如果您的架构分类仍停留在v2026之前的版本，请立即重新评估，尤其是在上次评估以来已引入客户客户端连接器、外部文件流或新的集成路径的情况下。那些通过临时应变来筹备首次范围扩展认证的团队，将在2027年面临这样的局面：评估人员期望其背后的工作看起来是经过周密规划的。无论如何，关键问题在于：您的安全架构是否已做好准备，以应对如今位于Secure 区域之外的挑战。
客户连接器及其扩展范围
支付环境极少会通过其最坚固的防线遭到攻击。文件和数据是通过客户门户、合作伙伴上传、托管文件传输平台、中间件队列、API 集成以及带入数据中心的可移动存储介质，进入Swift相关系统的。这些渠道中的每一个，都可能将恶意或不可信的内容传输到基础设施中——而根据早期架构审查的结果，这些基础设施原本被归类为“安全范围之外”。
该框架现将这些路径视为相关安全架构的一部分。客户客户端连接器按名称纳入监管范围：API 端点、中间件和文件传输客户端，无论它们是在服务器还是客户端端点上运行。审查范围延伸至软件本身，涵盖安全更新、漏洞扫描以及软件完整性，使内部连接器的代码与它们传输的文件一样，都接受同样的审查。
如果您的架构分类早于 v2026 版本，那么您曾经视为不在范围内的组件（例如面向客户的上传服务、集成总线或文件传输服务器）可能需要重新评估，特别是在这些组件使用或构成客户客户端连接器的情况下。
对于安全领导层而言，风险可归纳为两种情况：恶意文件一旦侵入支付基础设施，将威胁支付业务本身的可用性；而在评估过程中发现的范围缺口，则会成为有据可查的发现，并被董事会知晓。无论哪种结果，其代价都远高于为预防这些情况而进行的重新评估。
文件安全应纳入架构审查范围
扩展范围所涵盖的几乎所有通道，其存在目的都是为了传输文件或结构化数据：来自客户和合作伙伴的上传、机构之间的批量传输、穿越中间件的附件，以及跨越API 边界的文件。网络边缘的单一杀毒引擎，其设计初衷是解决比这更狭窄的问题。
因此，文件安全成为一项架构决策。一个切实可行的原则是：在文件和数据流到达关键支付基础设施之前，对其进行检查、净化和控制，同时确保所采取的控制措施与每条数据流及其风险相适应。
在文件进入支付系统之前对其进行检查
某合作伙伴通过您的客户门户上传了一批发票。该文件被传输到一个受管文件传输平台，由中间件队列提取，集成服务对其内容进行格式转换，最终输出结果通过一条连接到Swift系统的路径传送到应用程序。外部文件与关键支付基础设施之间隔着四个中转环节，而在许多机构中，每个环节都信任前一个环节。
应用“检查、净化和控制”原则，意味着在每个节点部署特定的控制措施。MetaDefender™Core 和MetaDefender ICAP Server 会扫描通过面向客户的 Web 应用程序、RESTAPI 或ICAP 集成上传的文件。MetaDefender Managed File Transfer 会检查在后台系统与 Swift 相关系统之间传输的内容，支持《控制》第 2.4 条“后台数据流安全”。
所有文件均通过 Metascan™（Multiscanning ）进行处理，由 30 多个反恶意软件引擎并行扫描。这种多引擎扫描技术支持 Control 6.1 的“恶意软件防护”功能，其检测已知恶意内容的准确率高于任何单一引擎。随后，Deep CDR™ 技术会对每个受支持的文件进行净化和再生，在文件继续传输之前移除其中嵌入的活动内容。 可疑文件将被发送至Adaptive Sandbox ，通过基于仿真的分析技术，该平台能够有效捕获规避检测的威胁和零日威胁，并支持 Control 6.5A《入侵检测》建议。
同样的处理机制也适用于存储备份和提取数据的存储库，Proactive DLP™ 会检查静态文件中的敏感内容。该机制还涵盖可移动介质和临时设备，MetaDefender （Kiosk ）和MetaDefender （Drive ）会在这些设备进入系统前的检查点对其进行扫描和清理，从而支持控制措施 3.1“物理安全”。
对于内部连接器软件，MetaDefender Software Supply Chain 会在部署前对软件包及其依赖项进行漏洞和恶意组件扫描，支持控制措施 2.2“安全更新”、2.7“漏洞扫描”以及 6.2“Software 完整性”。
其结果是在其处理的所有文件通道上统一应用了一层防护，且该防护层位于其所保护的系统上游。
支持您评估的检查记录
当2027年评估窗口于7月开启时，评估人员将根据扩大的评估范围对第二个确认周期进行审查，而证明相关控制措施已建立并有效运行的证据，其权重将高于仅声明的意图。
文件和数据流中的各个检查点可生成有用的证据：检查事件、转发至 SIEM 的审计日志，以及记录内容在传输至支付系统过程中如何被检查的策略执行记录。这些证据支持控制项 6.4“日志记录与监控”，以及 CSCF 认证本身。
合规仍由机构自行负责，评估人员会对整个架构进行评估。这项工作得出的结果，是对评估人员核心问题的合理解答：哪些因素可能影响您的支付基础设施，以及在影响过程中会发生什么？
给你的架构团队的三个问题
在2027年窗口期到来之前，以下三个问题可作为有用的初步探讨：
- 最终有哪些外部文件和数据流可以进入您的支付基础设施？
- 文件在进入 Swift 相关工作流之前是如何进行检查的？
- CSCF 范围的扩大是否会改变您当前的架构分类或控制措施？
我们的 SWIFT CSCF v2027 数据表将扩展范围、受影响的基础设施以及相关的预防性控制措施浓缩在几页之中，您可以将其分享给架构和 GRC 团队。
如果您更愿意亲自了解您的环境，不妨与OPSWAT 专家交流，并带上您当前的架构分类方案。
