一家既做银行卡收单、又走 SWIFT 做跨境支付的机构，年底撞上了两场审计：一边是 PCI DSS 的评估师进场查持卡人数据环境（CDE）的密钥管理，另一边是 SWIFT 客户安全计划的年度合规确认------两边的检查单都指向同一个东西：密钥存在哪、谁管、有没有留痕。机构把 HSM 密码机台账翻出来，评估师一个问题就卡住了："这套密钥管理系统，能分别回答 PCI 的密钥轮换和 SWIFT 安全区的密钥保护吗？两张单子用的是一份证据吗？"
双合规的难点从来不是"多买几台设备"，而是两套来自不同组织、不同逻辑的安全框架，压到同一套密码与密钥体系上 。PCI DSS 管的是"持卡人数据（卡号、有效期、CVV 相关数据）"的安全，SWIFT CSP 管的是"接入 SWIFT 网络那套支付环境"的安全------它们各自有要求、各自有评估，但底层都依赖同一件事：密钥必须锁在受保护的密码硬件里，密钥生命周期必须可证明。这篇按概念递进式拆：先认清两套标准是什么、管谁、什么时效，再看收单与跨境场景里 HSM 相关要求怎么拆，最后落到"一张 HSM 底座 + 统一密钥管理"的双合规落地矩阵与验收清单。
全文结构：
- 一、先认清两套标准：PCI DSS 与 SWIFT CSP 各管什么
- 二、谁会同时面对两套标准：收单 + 跨境支付场景画像
- 三、PCI DSS 4.0 里跟 HSM/密钥相关的要求拆解
- 四、SWIFT CSP 里跟 HSM/密钥相关的要求拆解
- 五、双合规的钥匙怎么规划：一张 HSM 底座的边界设计
- 六、双合规落地映射矩阵：两张检查单对到一套证据
- 七、双合规验收清单
一、先认清两套标准：PCI DSS 与 SWIFT CSP 各管什么
| 维度 | PCI DSS | SWIFT CSP |
|---|---|---|
| 全称 | Payment Card Industry Data Security Standard | SWIFT Customer Security Programme（客户安全计划） |
| 谁提出 | Visa/Mastercard 等卡组织（PCI SSC 制定） | SWIFT（环球银行金融电信协会） |
| 管谁 | 任何存储、处理、传输持卡人数据的组织：商户、收单机构、支付机构、银行、服务商 | 所有接入 SWIFT 网络的银行/金融机构用户 |
| 管什么 | 持卡人数据环境（CDE）的安全：从网络、系统到数据存储、密钥管理 | 接入 SWIFT 那套支付环境的安全：隔离、访问、密钥、检测响应 |
| 框架 | 12 项要求、6 大安全目标 | 3 大目标、7 项原则；客户安全控制框架 CSCF |
| 评估 | 年度评估（QSA 或 SAQ 自评），按交易量/角色分级 | 每年在窗口期内自评估并确认合规，出具 KYC-SA 年度证明 |
| 时效要点 | v4.0（2022-03 发布）；2024-03-31 起 v4.0 全面强制（v3.2.1 同日退役）；51 项过渡要求 2025-03-31 起强制 | CSCF 年度更新，须按当年版本确认（v2024 为 25 项强制 + 7 项建议） |
两套标准有个共同点：都把"加密与密钥管理"当硬骨头。PCI DSS 的"保护存储的持卡人数据"、SWIFT CSP 的"防止凭证泄露""管理身份并隔离特权"，落到设备上都是同一句话------密钥不能放在软件里、不能明文、不能一个人说了算，必须硬件保护 + 全生命周期留痕。这正是 HSM 为什么是双合规的公约数。
二、谁会同时面对两套标准：收单 + 跨境支付场景画像
不是每家银行都被 PCI 和 SWIFT 同时管到，典型的是"境内收单 + 跨境报文"两条业务线的持牌机构：
| 业务线 | 处理什么数据 | 落入哪套框架 |
|---|---|---|
| 银行卡收单（POS/线上/代收付） | 卡号 PAN、有效期、CVV/磁道等同卡数据 | PCI DSS（持卡人数据环境） |
| ATM/POS 取现与交易 | PIN（个人识别码）、卡密钥 | PCI DSS + 卡组织密钥标准（PIN 密钥尤其敏感） |
| 跨境支付报文（SWIFT） | SWIFT FIN/ISO20022 报文、接口密钥、证书 | SWIFT CSP（安全区 + 控制项） |
| 跨境人民币/外币清算对接 | 报文签名加密、证书 | SWIFT CSP / 境内密评叠加 |
这类机构的技术现状往往是：卡数据环境一套系统、SWIFT 接入一套环境、境内核心又是一套，各自为政地上了几台密码设备，密钥台账各记各的------到了双合规审计，才发现证据是散的、口径是乱的。双合规规划，本质是把这三套环境对到"一套密码运维体系 + 分域隔离"上。
三、PCI DSS 4.0 里跟 HSM/密钥相关的要求拆解
PCI DSS 不强制你"必须买 HSM"，但它的要求落地下来，能把密钥锁在硬件里的 HSM 是最直接的答案。逐条看相关要求：
1. 保护存储的持卡人数据（要求 3）
- 卡数据最小化存储（3.1）：能不留就不留------这是成本最低的"加密"；
- 存储的卡数据必须不可读（3.x）：加密、截断、令牌化或强哈希，加密密钥本身再加密；
- 3.5.1.2（2025-03-31 起强制）：全盘加密（FDE）不再被认可为"使非可移动介质上存储的卡数据不可读"的充分手段------必须落到更精细的加密控制。这一条把大量只靠磁盘加密糊弄的机构拉回"真正做字段/库级加密"；
- 密钥管理要求 （3.6 组）：密钥最少化、按用途分离、加密存储、双人控制（split knowledge & dual control）、定期轮换、防未授权替换、归档与销毁。这几条几乎是为 HSM 量身写的------HSM 的天然能力就是密钥不出设备 + 双人控制 + 轮换审计。
2. 加密传输（要求 4）
传输卡数据的网络必须加密（最低 TLS 1.2，推荐 1.3），不能有明文卡号过网。密钥与证书的信任根仍回到密码设备。
3. 多因素认证（要求 8）
8.4.2（2025-03-31 起强制） ：MFA 覆盖所有访问 CDE 的途径------不再只限管理员和远程，任何角色、任何位置的 CDE 访问都要多因素。运维、开发、第三方碰 CDE，一律第二因素。落到产品上，就是统一认证 + 密码介质/动态口令，配合登录审计。
4. 日志与测试（要求 10/11）
CDE 访问日志集中留存（至少 12 个月可回溯）、定期渗透与漏洞管理。密钥操作（产生、轮换、销毁）是日志里评估师最爱看的部分------HSM/KSP 的审计要能直接导出。
5. PIN 密钥与卡组织的专门要求
收单（ATM/POS 取现交易）比一般持卡人数据环境多一块：PIN（个人识别码）及其加密密钥。PIN 一旦在传输、存储、加密环节泄露，账户资金风险是实打实的，所以卡组织和 PCI SSC 对 PIN 密钥有一套更专门的要求：PIN 相关密码操作要落在通过相应评估的硬件里，PIN 密钥按卡组织认可的密钥管理流程装载、传递与轮换（双人执行、按用途分离），普通服务器上"软件密钥 + 文件存放"的做法在收单审计里过不去。
一句话：卡数据密钥、PIN 密钥、报文签名密钥别混用------按用途分开密钥、分开设备域，审计时才能分开对答。
小结：PCI DSS 对 HSM 的诉求是"卡数据密钥 + PIN 密钥的硬件保护、双人控制、轮换可证明"。卡组织对 PIN 密钥等还有专门设备要求（PCI 认可的密码服务与密钥标准体系），这是收单机构必须单独对齐的一块。
四、SWIFT CSP 里跟 HSM/密钥相关的要求拆解
SWIFT CSP 不指定具体产品，但客户安全控制框架（CSCF）的多个控制项，落地都指向同一件事：接入 SWIFT 的安全环境里，密钥和凭证必须锁住、访问必须多因素、动作必须留痕。跟密码设备相关的几组控制：
| CSCF 控制组 | 要求方向 | HSM/密钥落点 |
|---|---|---|
| 目标1 保护自身环境（隔离/加固） | SWIFT 相关系统与一般 IT 隔离、攻击面最小化 | SWIFT 安全区内密钥集中硬件保护，不与普通系统混放 |
| 控制 4.2 多因素认证 | 防止凭证泄露，访问 SWIFT 相关系统多因素 | 运维/管理员访问安全区设备走多因素（密码介质） |
| 控制 5.x 身份与特权管理 | 管理身份、隔离特权、最小授权 | 分岗分权，密钥操作双人，特权账号收口 |
| 控制 5.2 令牌/凭证管理 | 令牌与密钥的安全存储与保管 | 接口密钥/证书锁 HSM，个人令牌按规范保管 |
| 控制 5.4 密码库保护 | 存放密码/密钥的库受保护、加密 | 密钥库用 HSM 做根，不在软件里明文 |
| 目标3 检测与响应（6.x/7） | 日志监控、异常检测、事件响应 | 密钥/证书操作审计进日志，异常轮换/导出能告警 |
年度评估怎么排：把两场审计并成一条线
SWIFT 每年在固定窗口（每年 7.1--12.31）内做年度自评与独立评估、出具年度合规证明（KYC-SA）；PCI DSS 的年度评估一般跟着上一场评估的周期走。两场各干各的，机构下半年往往两头赶，实操是把它们并成一条年度线：
| 时段 | 要做的 | 主要对哪套 |
|---|---|---|
| 年初（1-3 月） | 盘点 CDE/安全区边界与密钥台账变化、证书到期情况 | 两套共用 |
| 上半年 | 跑 PCI 年度评估与渗透/扫描测试，留足整改窗口 | PCI DSS |
| 下半年（7.1--12.31） | SWIFT 年度自评 + 独立评估，出具 KYC-SA | SWIFT CSP |
| 全年 | 日志留存、密钥轮换演练、第三方访问多因素 | 两套共用 |
这套并线能成立的前提是"材料平时可导"：密钥/证书台账、认证日志、轮换记录平时一键能出，年度确认就是再核一遍，而不是年底补一整年。
关键认知 ：SWIFT CSP 的年度合规确认（窗口期每年 7.1--12.31）要求的是"你能证明控制了"------证据就是安全区里密钥谁管的、怎么存的、换过没有、日志全不全。这套证据和 PCI DSS 评估师要的，底层是同一份 HSM/KSP 审计。
五、双合规的钥匙怎么规划：一张 HSM 底座的边界设计
PCI 和 SWIFT 各自有边界（PCI 管 CDE，SWIFT 管安全区），双合规的关键不是"买一台超强 HSM 全装下"，而是规划清楚分域，再决定一台还是多台。工程上三选一：
| 方案 | 做法 | 适合 | 风险点 |
|---|---|---|---|
| 完全独立两台/两套 | 国密密评一套 HSM，卡组织/CDE 一套，SWIFT 环境一套 | 业务边界清晰、各有独立合规审计 | 设备多、运维散、密钥台账易乱 |
| 一台 HSM 逻辑分区 | 同一台设备按逻辑域隔离（国密区/国际算法区/CDE 区） | 中小规模、想省设备 | 要验证分区隔离强度满足 PCI/SWIFT 边界要求 |
| 统一密钥管理平台纳管多台 | HSM 仍按环境分设备，但密钥生命周期与审计由 KSP 统一纳管 | 多环境、多设备的大中型机构 | 平台本身要分权、审计要独立 |
落地的三条边界纪律：
- 合规边界要物理或逻辑隔离 。卡组织/CDE 的密钥管理与境内国密密评（等保/密评要求密码模块满足 GB/T 37092）是不同的合规体系：国际卡数据区按卡组织/PCI 认可的密码服务与密钥标准走，境内国密区用符合 GB/T 37092 的国密 HSM------别拿一台国密设备宣称"同时就是 PCI 认可的"，该隔离的隔离，各按各的清单过。
- 密钥生命周期统一，运维口径统一。隔离的是"密钥本体"，不该隔离的是"管理"------由统一密钥管理平台（KSP）把各环境 HSM 的密钥产生/轮换/归档/销毁统一留痕，审计集中一处。PCI 评估师和 SWIFT 确认要的都是"能导出证据"，统一纳管才交得出来。
- 多因素与访问控制共用一套。PCI 8.4.2 和 SWIFT 4.2 都要 MFA------运维、开发、第三方访问 CDE/安全区的入口统一走多因素认证（ASP + 密码介质），一份认证审计同时背书两张单子。
设备的可用性同样要规划------密码设备一旦承载两套合规的关键密钥，可用性就是业务级问题：
- 双机热备 / 集群：同机房 HSM 做主备或集群，密钥同步与切换要演练过------评估师会问"这台设备挂了，密钥和业务怎么切"；
- 异地容灾：密钥材料跨地同步走受控的封装流程（密钥不以明文出设备），本地与灾备设备各一套，切换演练要有记录；
- 恢复预案：设备故障、密钥丢失的恢复路径与备份密钥保管写进预案，双人开启、审计留痕。
一句话：双合规机构买 HSM 不是买"保险柜"，是买"每天要开合的保险柜"------可用性和安全性要一起验收。
一张 HSM 底座的形态（示意）：
卡组织/CDE 环境 SWIFT 安全区 境内国密/密评区
│ 卡数据/PIN 密钥 │ 接口密钥/证书 │ 核心业务/报文签名
▼ ▼ ▼
┌──────────────────────────────────────────────────────────────────┐
│ 统一密钥管理平台 KSP（密钥全生命周期 + 审计集中留痕） │
│ ├─ 分区 A：PCI/CDE 密钥（按卡组织认可设备/标准） │
│ ├─ 分区 B：SWIFT 接口密钥/证书（安全区硬件保护） │
│ └─ 分区 C：国密业务密钥（符合 GB/T 37092 的国密 HSM） │
└──────────────────────────────────────────────────────────────────┘
访问侧：ASP 统一多因素认证（运维/开发/第三方，PCI 8.4.2 & SWIFT 4.2 共用）
数据侧：TDE 本地敏感数据静态加密（卡号相关/交易数据，配合最小化存储）一句话记住这套设计：密钥按边界隔离，管理按一套统一，认证按一次接入，证据按一份导出。
变更与扩区：双合规是长期维护
双合规不是一次验收就完事。新开一条跨境报文通道、收单新增渠道、机房搬迁......每一次变更都会动到 PCI/SWIFT 的边界。维护纪律就三条：变更先过边界评估 （动 CDE/安全区之前先问"会影响哪张单子"）、密钥随变更重审 （新通道的证书/密钥进对应分区、旧密钥到期归档销毁）、文档随变更更新（分区清单、加密策略别等审计前才补）。把"变更即合规评估"放进变更流程，比一年两场审计前的突击有效得多。
六、双合规落地映射矩阵：两张检查单对到一套证据
把 PCI 与 SWIFT 的要求逐条映射到落点，双合规就变成"同一套动作，两份证据都勾得上"：
| 底层诉求 | PCI DSS 对应 | SWIFT CSP 对应 | 落点 | 验证 |
|---|---|---|---|---|
| 密钥硬件保护 | 要求 3（存储卡数据密钥加密、双人控制） | 5.2 令牌/凭证管理、5.4 密码库保护 | 密钥锁 HSM/受控密码设备，按分区隔离 | 尝试导出密钥被拒；密钥不出设备有审计 |
| 密钥生命周期留痕 | 3.6 组（轮换/归档/销毁） | 6.x 检测、日志留痕 | KSP 统一管理产生/轮换/归档/销毁 | KSP 按密钥导出全生命周期报告 |
| 双人控制 | 3.6（split knowledge & dual control） | 5.x 特权隔离 | 敏感操作双人审批流 | 轮换/导出/销毁有双人复核记录 |
| 多因素访问 | 要求 8（8.4.2 全覆盖） | 4.2 多因素 | ASP 统一多因素 + 密码介质 | 登录需第二因素，认证日志到人 |
| 静态数据加密 | 要求 3（3.5.1.2 起 FDE 不够） | 安全区数据保护 | TDE 本地敏感数据加密 + 最小化存储 | 存储抽查为密文，密钥外置 |
| 传输加密 | 要求 4（TLS1.2+） | 安全区内部链路安全 | 国密/国际算法按环境双轨通道 | 抓包核对套件与双向认证 |
| 日志留存 | 要求 10（≥12 个月可回溯） | 6.4 日志与监控 | 认证/密钥操作日志集中留存 | 可导出近 12 个月访问与密钥操作日志 |
| 定期测试/确认 | 要求 11（渗透/扫描） | 年度合规确认（窗口期） | 年度评估 + 应急演练排期 | 年度评估报告/确认函齐全 |
审计证据包：两张单子要什么、一份怎么交
评估师（PCI 的 QSA、SWIFT 的独立评估方）进场要的无非这几类材料，提前备成"证据包"：
| 证据类别 | 具体内容 | 平时怎么留 |
|---|---|---|
| 密钥生命周期 | 各分区密钥的产生/轮换/归档/销毁记录 | KSP 按密钥导出报告 |
| 认证与访问 | 登录、双人复核、特权操作审计 | 认证日志集中留存 ≥12 个月 |
| 设备与证书 | HSM 设备清单、证书有效期、硬件认证信息 | 台账 + 到期预警 |
| 演练与整改 | 轮换演练、灾备切换、渗透/扫描记录 | 每次演练留报告存档 |
| 边界与策略 | 分区清单、加密策略、最小化存储说明 | 文档随变更更新 |
材料做到"平时可导、到期复核"，双合规就从"每年赶两场审计"变成"每年核一遍同一套材料"。
映射做完会发现：双合规不是"两倍的活"，是"一套加密与密钥运维体系 + 分域隔离 + 统一证据"。PCI 评估师要的密钥双人控制、SWIFT 确认要的密钥保护，本质是同一套 KSP+HSM 记录。
七、双合规验收清单
对着一套要过 PCI + SWIFT 双合规的收单/跨境机构逐条自查：
| # | 检查项 | 达标判定 |
|---|---|---|
| 1 | 环境边界清晰 | CDE、SWIFT 安全区、境内国密区边界定义清楚，密钥分区隔离 |
| 2 | 密钥硬件保护 | 卡数据/PIN 密钥、SWIFT 接口密钥、国密业务密钥均锁在受控密码设备 |
| 3 | 密钥可导出证据 | KSP 能按密钥导出产生/轮换/归档/销毁全生命周期记录 |
| 4 | 双人控制落实 | 敏感密钥操作（轮换/导出/销毁）有双人复核与审批流 |
| 5 | MFA 全覆盖 | CDE 与安全区所有访问均多因素，含运维/开发/第三方 |
| 6 | 卡数据最小化 + 加密 | 无多余卡数据留存；留存部分为密文（非仅 FDE） |
| 7 | 静态/传输加密就位 | 本地敏感数据密文；传输通道 TLS1.2+（或国密）且双向认证 |
| 8 | 日志可回溯 | 认证与密钥操作日志集中留存 ≥12 个月，异常操作可告警 |
| 9 | 各自合规口径对齐 | PCI 按卡组织/PCI SSC 认可的设备与密钥标准；国密区满足 GB/T 37092 与密评 |
| 10 | 年度评估排期 | PCI 年度评估 + SWIFT 年度合规确认（窗口期）排期明确、证据可复用 |
PCI DSS 4.0 和 SWIFT CSP 是两套不同组织、不同逻辑的框架，但它们在"密钥要锁住、访问要多因素、动作要留痕"上收敛到同一个答案。收单 + 跨境支付的双合规，不用把密码体系做成两套：密钥按边界（CDE/安全区/国密区）隔离，生命周期由统一 KSP 纳管，认证一次接入（ASP 多因素），数据静态加密用 TDE，证据一份导出------两张检查单对着同一套 HSM 记录，都能打勾。
你们机构是刚接到 PCI/SWIFT 双合规要求、正在盘点环境边界，还是已经在排 HSM 与密钥管理的审计证据？评论区说说双合规踩过的坑，一起排雷。
文章作者：安当加密技术负责人