Azure Payment HSM v2 挑战支付安全专用硬件模式
Azure Payment HSM v2 于 9 月 17 日进入公开预览阶段，对至今仍支撑众多关键支付系统的专用硬件模式发起挑战。
Microsoft、Marvell 与 Utimaco 从三个不同层面构建了这项服务。Azure 负责运营托管平台，Marvell 提供 LiquidSecurity 硬件，Utimaco 则贡献其 Atalla Payments Module 软件。
这一组合面向银行、支付处理商、金融机构及其他处理受监管支付工作负载的服务提供商。它支持发卡、PIN 转换、移动支付认证和加密密钥管理等功能。
更重要的变化在于运营模式。支付机构可继续掌控加密密钥，而无需在自身设施中部署和维护实体支付硬件安全模块（HSM）。
这一承诺也构成了此次发布的核心张力。支付 HSM 保护着极其敏感的交易，但其周边控制措施历来需要专用设备、专业团队以及严谨管理的恢复流程。
Azure Payment HSM v2 将更多运营责任转移至云服务。其成功将取决于机构是否愿意接受这一取舍，同时维持合规性、应用兼容性、可预测的延迟以及清晰的控制边界。
Azure Payment HSM v2 整合三层安全能力
这项新服务将专业支付密码技术封装为托管 Azure 基础设施，而非由客户自行运营的硬件部署。
根据公开预览公告，Azure Payment HSM v2 初期面向美国西部和西欧地区的客户提供服务。有限的区域部署为此次发布划定了重要边界。
这仍是一项预览服务，并不意味着它已适用于所有生产级支付系统。在该平台能够支撑全球迁移计划前，Microsoft 及其合作伙伴仍需完成客户测试、积累运营证据并扩大可用范围。
HSM 是一种防篡改计算设备，可在受保护的硬件边界内生成、保护和使用加密密钥。支付 HSM 则增加了银行卡网络和支付处理商所需的专用操作能力。
这些操作包括保护 PIN、转换 PIN 块、发放支付凭证、验证交易数据，以及与可信合作伙伴交换密钥。它们不同于通用加密或证书管理工作负载。
Marvell 通过其 LiquidSecurity HSM 技术提供硬件基础。该公司为高密度云环境设计了这套硬件，以满足多个相互隔离的工作负载对高加密吞吐量的需求。
Utimaco 通过 Atalla Payments Module 提供支付专用层。该软件保留了与长期发展的 Atalla 产品系列相关的接口和支付功能。
随后，Microsoft 通过 Azure 将整套系统作为托管服务提供。Azure 承担了底层基础设施职责，而这些职责原本需要机构在设备、设施、网络和供应商支持之间自行协调。
三家公司表示，客户将保留加密密钥主权。实际上，密钥主权意味着客户控制密钥访问与策略，而云运营商负责配套基础设施的管理。
这一差异很重要，因为运营管理与密钥控制权并非同一回事。银行可以委托硬件维护，而不必然赋予服务提供商使用其支付密钥的权限。
该服务旨在满足 PCI 安全、合规、审计、性能和运营要求。然而，为满足这些要求而设计的服务，并不会自动使每个客户部署都符合要求。
合规仍是一项共同责任。机构仍须围绕该服务配置应用、访问控制、网络、流程、监控和审计证据。
合作伙伴还将这一组合描述为行业首创。这一说法应被狭义理解，因为托管支付密码服务在其他地方已然存在。
其独特之处在于这一特定的多供应商架构：它在同一托管服务中结合了 Atalla 支付软件、Marvell 云 HSM 硬件和 Azure 服务运营能力。
这比宣称 Azure 发明了托管支付密码技术更为准确。AWS 已在运营支付密码服务，而 Microsoft 也已提供基于 Thales 硬件的早期 Azure Payment HSM。
变化在于 Azure 内部的架构与责任模型。新版本旨在以云运营服务替代更多由客户自行管理的设备工作。
为何支付密码技术始终紧贴实体硬件
支付 HSM 对云迁移保持抗拒，原因在于其接口、控制流程和合规义务均围绕专用银行基础设施发展而来。
通用加密服务多年前便已迁入公有云。各类组织经常使用托管系统管理加密密钥、证书、数字签名和应用密钥。
支付密码技术的迁移路径则更为缓慢。银行无法用普通密钥保管库替代支付 HSM，因为支付系统需要专用命令和运营控制。
支付应用通常通过与既有 HSM 产品系列绑定的接口进行通信。迁移这些应用所需的工作，可能远不止传输密钥或选择另一个云区域。
一次迁移可能影响消息格式、密钥块、审计流程、灾难恢复、延迟以及与外部支付合作伙伴的连接。每项变更都可能扩大测试范围。
Atalla 在这段历史中占据重要地位。Mohamed Atalla 在开发出保护自动取款机与银行系统之间 PIN 的技术后，于 1973 年创立了 Atalla Corporation。
该产品线后来历经多次易主，直至 Utimaco 于 2018 年将其收购。在这些变迁中，其接口始终嵌入于各类支付环境。
Marvell 表示，Atalla Payment Module 可让现有应用通过熟悉的 Atalla 接口使用新服务。这一兼容性主张旨在解决支付基础设施现代化的一大障碍。
这一方式改变的是软件下方的硬件，同时保留面向应用的支付逻辑。它更像一次基础设施迁移，而非对整个支付应用进行全面重写。
这一差异是商业价值的核心。若迁移迫使银行替换整个支付技术栈中稳定的交易软件，托管基础设施带来的价值便十分有限。
合作伙伴表示，客户可将现有 Atalla 应用指向 Azure Payment HSM v2。随后，Azure 将管理扩缩容、可用性、备份、恢复及底层硬件。
Marvell 在其云迁移说明中提供了有用背景。该公司表示，一块 LiquidSecurity 2 适配器最多可管理 100,000 个密钥对，每秒可执行超过 100 万次加密操作。
这些数据描述的是底层适配器，而非每个 Azure Payment HSM v2 部署均可保证达到的性能水平。应用延迟还将取决于网络、服务配置和工作负载设计。
传统部署还会因容量规划带来另一项问题。机构通常会按预期峰值需求配置实体设备，即便平均流量远低于该水平。
它们还必须安排冗余、安全管理、固件维护、备用容量、备份流程和灾难恢复。即使交易需求保持稳定，这些责任仍然存在。
云规模基础设施提供了另一种模式。服务提供商可运营共享硬件资源池，同时维持相互隔离的客户环境和硬件支持的密钥保护。
这种模式可以提升资源利用率并缩短配置周期。但它也可能使客户更依赖服务运营商、其区域覆盖范围以及故障管理流程。
因此，支付密码技术长期贴近实体硬件有其充分理由。新服务并未让这些顾虑消失。
相反，Azure Payment HSM v2 试图在将基础设施工作转交 Microsoft 的同时，保留熟悉的支付行为。其吸引力建立在减少应用边界变更之上。
压力将落在客户自运营的支付 HSM 上
Azure Payment HSM v2 对那些仍由客户自行管理设备容量、可用性、维护和恢复的部署带来最大压力。
Microsoft 已提供一项基于 Thales payShield 10K 设备构建的 Azure Payment HSM 服务。该服务将专用支付设备置于 Azure 数据中心中，但仍保留了大量客户责任。
Microsoft 的现有服务指南将当前产品描述为裸金属服务。客户在完成配置后获得管理控制权，并持续负责 HSM 配置。
现有服务可将设备直接部署在客户虚拟网络中。机构可部署成对 HSM 以保障可用性，并使用 Thales 管理工具进行安全远程访问。
这一安排支持云托管应用，同时并未放弃专用设备模式。然而，它也未消除与专用支付硬件相关的运营模式。
Microsoft 表示，现有服务并未针对支付 HSM 本身提供特定的正常运行时间保证。标准 Azure 网络承诺仍然适用，但客户必须自行设计 HSM 的可用性方案。
其部署指南要求在彼此独立的基础设施单元中部署多台设备。客户还须实施负载均衡、密钥备份，以及用于灾难恢复的备用区域部署。
这正是 Azure Payment HSM v2 直接挑战的模式。新平台承诺提供托管服务，而非由客户必须自行管理的托管硬件。
对于基础设施团队而言，这将多项重复性决策转向 Microsoft，包括扩充容量、更换故障设备、维护平台以及协调恢复工作。
对于安全团队而言，决策更为复杂。他们必须判断托管边界是否能够保留所需的控制、证据、职责分离和密钥处理流程。
对于财务和采购团队而言，比较范围不止于设备采购。专用基础设施还会带来设施、支持、人员、冗余和生命周期成本。
公开预览公告并未附带公开定价。因此，买方尚无法仅依据该公告完成全面的商业比较。
迁移风险或许比直接基础设施成本更重要。稳定的 HSM 部署可能处于众多支付应用和合作伙伴连接的核心。
更换该组件可能需要广泛的认证和运营审查。即使接口兼容，也无法消除本地设备与远程托管端点之间的所有差异。
此次发布也给早期的 Azure 服务组合带来压力。Microsoft 需要说明客户应在何时选择 v2，而不是基于 Thales 的支付 HSM。
一些组织可能更倾向于专用硬件和直接的管理控制。另一些组织则可能更看重减少基础设施管理负担和更快的扩展能力。
Microsoft 尚未公开说明现有服务的退役路径。客户不应假设 v2 会立即取代所有现有架构。
两种模式的共存可能成为一项特性。Azure 可以同时支持高度受控的专用部署和托管支付密码服务，以满足风险要求不同的客户。
预览版将揭示这种市场细分是否清晰。产品边界若令人困惑，可能会拖慢采用速度，尤其是在合规团队需要明确责任划分时。
AWS 表明托管支付安全已是竞争激烈的市场
更广泛的竞争并非云与非云之间的较量，而是哪一种云模式能够提供可接受的控制力、兼容性、合规证据和运营简便性。
AWS Payment Cryptography 已为支付处理提供托管加密功能。客户无需采购专用支付 HSM 实例即可访问这些功能。
AWS 服务模式 支持发卡方、收单方、处理商、网络、交换机构和支付服务商等支付参与者。AWS 表示，该服务符合 PCI PIN、PCI P2PE 和 PCI DSS 要求。
AWS 通过服务 API、命令行工具、软件开发工具包及其管理控制台提供支付操作。请求会发送至一组通过 PCI 验证的托管 HSM。
这一架构提供了不同的迁移路径。应用程序集成 AWS 接口，而不是接入熟悉的 Atalla 应用边界的托管版本。
Azure Payment HSM v2 似乎更强调与基于 Atalla 的既有环境兼容。这一重点可能会吸引希望采用云端运营、同时不愿重新设计既有支付命令的机构。
没有一种方法在所有情况下都更优。以 API 为中心的服务可以与云身份、监控、自动化和应用工具实现紧密集成。
以兼容性为中心的服务则可减少已经采用特定支付 HSM 接口的组织所需的改动。它也可能简化涉及现有 Atalla 部署的混合迁移。
选择取决于买方的起点。新的支付平台可以评估云原生 API，而无需背负数十年的集成历史。
大型处理商可能拥有大量围绕现有 HSM 产品系列构建的应用程序、脚本、流程和合作伙伴连接。保留这些接口可能具有显著价值。
Thales 仍是重要的竞争因素。其 payShield 系统在支付环境中占据重要地位，其中也包括现有的 Azure Payment HSM 服务。
已经采用 Thales 标准的客户，可能暂时没有充分理由迁移。其人员、应用程序、密钥仪式和审计流程可能都已适配该平台。
Utimaco 通过与 Marvell 和 Microsoft 的合作，获得了进入云端支付工作负载的新路径。Atalla 软件不再必须与传统 Atalla 设备密不可分。
Marvell 则为本已围绕云安全定位的硬件获得了专用工作负载。此次合作将 LiquidSecurity 的应用扩展至通用密钥管理和签名以外。
Microsoft 在托管支付密码服务领域获得了对 AWS 更有力的回应。它也获得了一种服务 Atalla 客户的方式，而无需要求这些客户采用当前基于 Thales 的运营模式。
这一竞争背景限制了“行业首创”的说法。首创的并不是托管云支付密码服务这一类别。
更站得住脚的“首创”是指三家供应商及其各自层级形成的托管组合。买方应根据可衡量的能力，而非标签，来评估最终服务。
这些衡量指标包括支持的支付命令、区域可用性、交易延迟、吞吐量、可用性承诺、迁移工具和合规文档。
对密钥交换的支持同样重要。支付组织经常使用严格受控的流程，在机构、处理商、网络和遗留系统之间交换密钥。
托管服务必须适应这些外部关系。它不能只现代化 Azure 内部部分，却忽视客户如何交换和恢复关键密钥。
竞争压力应会随着时间推移带来更清晰的文档。Microsoft 需要说明 Azure Payment HSM v2 与其现有服务及外部替代方案相比有何不同。
托管基础设施并不能消除支付安全风险
该服务减少了硬件管理工作，但客户仍需负责应用安全、访问设计、迁移决策，以及很大一部分合规成果。
“托管”一词可能造成不切实际的期待。它说明由哪一方运营基础设施，而非将所有安全责任都转移给服务提供商。
Microsoft 可以管理 HSM 硬件，而客户仍可能错误配置应用权限。客户也可能通过 HSM 边界之外薄弱的运营控制暴露敏感工作流程。
支付安全依赖于完整的交易路径。这一路径包括应用程序、网络连接、操作员身份、密钥交换流程、监控和下游系统。
HSM 为密钥和密码操作提供受保护环境。它无法纠正应用程序中其他位置的欺诈性业务逻辑或遭泄露的凭据。
预览状态带来了额外不确定性。公告并未提供公开的服务级别承诺、最终可用性时间表、完整的区域路线图或公开定价结构。
公告也未列出具名的生产客户。此次发布未包含独立性能结果和迁移案例研究。
对于初始预览版而言，缺少这些细节很正常。然而，受监管机构在迁移关键授权或 PIN 处理工作负载前需要这些信息。
区域覆盖是另一项限制。美国西部和西欧提供了两个起始区域，但跨国机构通常需要更具体的数据驻留和恢复选项。
服务只有在可用区域与组织的法律及运营要求相匹配时，才能支持数据主权。跨境恢复计划可能面临单独的限制。
这些公司称该平台具备高可用性。潜在用户仍需要有关冗余、故障域、维护行为、恢复目标和区域故障切换的具体信息。
密钥主权也需要仔细验证。客户应明确 Microsoft 可以执行哪些操作，以及哪些控制权仍完全属于客户。
他们应审查密钥如何进入和离开服务、备份如何受到保护，以及紧急恢复如何运作。退役流程同样值得重视。
兼容性声明需要针对实际应用进行测试。熟悉的 Atalla 接口并不保证时序、错误行为、支持的命令或运营工具完全一致。
对于此前在同一数据中心内访问 HSM 的交易系统而言，网络延迟可能变得重要。即使是微小变化，也可能影响具有严格处理目标的系统。
团队应测试正常工作负载和故障条件。流量高峰、连接丢失、限流、维护事件和区域中断都可能暴露不同的行为。
他们还应确认该服务如何生成审计证据。合规团队需要将提供商控制措施和客户控制措施映射到适用 PCI 要求的文档。
符合 PCI 要求并不会消除客户的合规范围。组织仍需由合格评估师评估其完整环境和运营流程。
供应商集中带来了另一项权衡。整合三家专业供应商可以形成更强的服务，但也会在其路线图和支持组织之间产生依赖关系。
当事件跨越 Azure 平台、Marvell 硬件和 Utimaco 软件时，客户需要明确的升级路径。责任归属不清可能延长恢复时间。
这些问题并不否定该服务的价值。它们界定了将一个颇具吸引力的架构转化为可信支付平台所需完成的工作。
三个信号将决定接下来会发生什么
区域扩展、经验证的迁移结果和生产级承诺将表明 Azure Payment HSM v2 是会改变支付基础设施，还是仍将停留在专业预览阶段。
第一个信号是 Microsoft 的可用性路线图。新增区域将增强其面向全球部署、本地处理和合规灾难恢复的吸引力。
扩展若较为缓慢，将把该服务限制在更狭窄的工作负载范围内。它还可能迫使跨国客户在初始覆盖范围以外的市场保留专用 HSM。
第二个信号是 Atalla 迁移的证据。Microsoft 和 Utimaco 需要提供参考架构，展示现有应用如何连接、传输密钥、处理故障并保留审计控制。
具名客户部署将比笼统的兼容性声明更具分量。它们将表明机构能否在不重新设计关键支付应用的情况下实现现代化。
性能证据应包括应用级测量，而不仅仅是硬件容量。买方需要了解在真实交易模式和区域网络条件下的延迟与吞吐量结果。
第三个信号是生产服务合同。正式发布应带来明确承诺，涵盖服务级别、支持责任、恢复行为、合规证据和运营边界。
这些细节将决定客户是否将 v2 视为关键基础设施。受监管买方很少仅根据硬件规格作出这一决定。
竞争对手的回应也值得关注，但其重要性次于执行。AWS 可以扩展支持的操作，而 Thales 可以强化专用或托管部署选择。
Microsoft 面临的当务之急是证明其新的责任模式有效。该公司必须在运营基础设施的同时，不削弱客户对支付密钥的控制。
对 Marvell 而言，考验在于云硬件经济性和可预测的性能。其 LiquidSecurity 平台必须在严苛的运营条件下支持专业支付工作负载。
对 Utimaco 而言，考验在于软件可移植性。Atalla 兼容性必须经受住从熟悉的设备迁移至 Microsoft 托管服务环境的考验。
银行和支付处理商应从范围有限的评估开始。受控工作负载可以暴露集成缺口，而不会让核心授权流量立即面临风险。
团队应在测试前记录当前的 HSM 依赖关系。该清单应包括命令、密钥格式、应用程序、合作伙伴交换、延迟目标和恢复流程。
随后，他们可以将预览版与现有 Azure 服务、AWS Payment Cryptography 及当前基础设施进行比较。相关结果是运营适配性，而非笼统的云偏好。
Azure Payment HSM v2 为支付机构提供了一个可信的新选择，可将密钥控制权与硬件运维职责分离开来。但这种分离并非自动实现，也并非毫无风险。
接下来的问题很实际：Microsoft 能否充分说明其控制措施、可用性和迁移路径，让受监管客户信任这种托管模式？
正在评估该服务的机构，应在将关键交易路径交由其承载前关注这三个信号。测试区域行为，验证 Atalla 兼容性，并要求获得明确的生产环境承诺。
如果这些结果经得起验证，Azure Payment HSM v2 将通过让更多支付工作负载无需自行拥有硬件，给专用部署带来压力。如果不能，机构仍会将熟悉的设备部署在最敏感的系统附近。
