PCI DSS 4.0 合规的 Secrets 管理要求

PCI DSS V4.0 到底是什么？

PCI DSS 是 Personal Card Identification Data Security Standards 的缩写。它由主要信用卡公司（VISA、Mastercard 等）于 2004 年推出，旨在帮助企业保护持卡人数据并防止欺诈。它是一项不断演进的标准，而 V4.0 是最新版本，于 2022 年初推出。

PCI DSS V4.0 的一个重大转变是，它强调持续性的安全实践，而不是静态的“一年一次”审计。考虑到现代数据泄露通常是由 secrets 泛滥引起的，这完全说得通：比如泄露的密码、暴露的 API keys，或者从未轮换过的 cryptographic keys。

这就是为什么本指南会拆解与 secrets management 相关的 PCI 要求，并为你推荐值得信赖的工具，帮助你满足这些标准。

PCI DSS 范围如何影响合规工作？

在开始之前，先明确 PCI DSS 如何定义 scope，以及为什么这很重要。

PCI DSS V4.0 是一份相当长的规范，但有些公司能够绕开其中大部分要求。怎么做到的？PCI DSS V4.0 提供分层的 PCI SAQs（Self-Assessment Questionnaires），而适用的 SAQ 取决于组织参与支付流程的程度。

通过使用像 Stripe、Shopify 或 Evervault 这类符合 PCI 要求的外部供应商，组织可以缩小自身的合规范围，并遵循更简单的 SAQ。

更多关于 SAQs：

PCI SAQs（Self-Assessment Questionnaires）是一种让商家和服务提供商借助 Payment Card Industry Security Standards Council（PCI SSC）的工具，自行评估其 PCI DSS 合规性的方式。适用于你的 SAQ 取决于你的组织如何存储和处理支付卡数据。

以下是最常见的 PCI SAQ 类型 概览：

我们的目标是展示 secrets management 如何融入 PCI DSS 合规性的整体图景。第三方支付提供商和更轻量的 SAQ 可以缩小 scope，但并不能消除保护 secrets 的需要。简而言之，如果没有合适的 secrets management 系统，就不可能满足这些要求。

接下来，我们将逐项讲解 PCI DSS V4.0 的要求，并展示良好的 secrets hygiene 如何帮助你保持合规。

PCI DSS V4.0 对 secrets 的要求是什么？

PCI DSS 要求 3：保护存储的持卡人数据

加密与密钥管理

PCI 的要求

总体指导很明确：除非绝对必要，否则不要存储持卡人数据。这意味着在认证后立即从磁条或芯片中删除敏感数据，并且至少每 3 个月检查一次数据保留期限是否超出限制。

任何必须存储的数据（例如 PANs）都应进行强加密，且密钥必须定期轮换。加密密钥本身就是敏感 secret。即使数据本身已被加密，若密钥处理不当，整个持卡人数据库仍可能暴露。

通过遵循双重控制措施来降低风险，即没有任何单一方能够完全控制加密密钥。将 secrets 分开存放可以增加一道防线，也让它们更易于管理。

推荐工具

Vormetric’s Data Security Platform 可处理静态加密和 PAN tokenization，帮助你满足严格的加密要求。它可以与像 Infisical 这样的 secrets management 平台配合使用，以便在整个基础设施中动态存储和轮换这些密钥。

PCI DSS 要求 4：加密开放网络上传输的持卡人数据

TLS 与证书管理

PCI 的要求

在数据跨越开放网络传输时，加密对保护敏感数据同样重要。实际中，你应该使用 TLS 1.2 或更高版本等强协议，而未受保护的 PANs 绝不能通过不安全的通道传输，例如明文 HTTP、email 或 chat。

调用中使用的 API keys 和 session tokens 应当动态处理。为了降低暴露风险，secrets 应在数据传输时即时注入，并在静态存储时安全保存在独立的 vault 中。

此外，用于保护通信的证书应定期更新。良好的监控工具会标记接近过期或配置不正确的证书。

推荐工具

使用 Evervault 在开放网络上传输敏感支付数据时加以保护，同时配合 secrets management 平台，在需要时存储和注入 TLS private keys、API keys 以及其他凭证。

PCI DSS 要求 7：基于业务需要知晓原则限制对持卡人数据的访问

Secrets 的基于角色访问控制

PCI 的要求

糟糕的访问控制会给攻击者留下可乘之机。这就是为什么访问应该只限于真正需要的人和系统，也就是最小权限原则。实际中，这意味着限制 secrets 只能用于特定、明确定义的任务。

RBAC（Role-Based Access Control）将 secrets 绑定到特定角色。在 CI/CD 流水线或云环境中，secrets 应仅在运行时可访问，并在随后立即移除。目标是减少敏感凭证暴露的时长。

推荐工具

强大的 secrets management 平台会将访问控制纳入其设计。例如，Infisical 的 RBAC 允许你设置预定义或自定义角色，将权限关联到特定用户和身份。

PCI DSS 要求 8：识别并验证对系统组件的访问

MFA 与安全凭证存储

PCI 的要求

为每个人分配唯一的身份标识，能够确保任何操作都可以追溯到具体用户。这不仅适用于人，也适用于访问支付数据的 service accounts 和自动化系统。

除了唯一 ID 之外，multifactor authentication（MFA）还能增加额外安全性，即使 credential 已被盗用，也能阻止未经授权的访问。MFA secrets，例如 OTP seeds，绝不应存储在 config files 中。相反，secrets vault 可以在需要时实时注入它们。

推荐工具

Cisco Duo 是实现 MFA 的可靠方式，但它需要配合强大的 secrets management 系统来处理 MFA seeds 或 SSH keys 的存储、注入和轮换。

PCI DSS 要求 10：跟踪并监控对网络资源和持卡人数据的所有访问

Secrets 访问监控

PCI 的要求

你需要可靠的日志记录来发现可疑行为并追踪用户操作。如果没有它，查明问题来源会困难得多。由于 secrets 是主要攻击目标，任何异常访问，例如意外的 vault 管理员活动，都应被记录下来。

监控应保持主动。非计划性的访问是一个明确的危险信号，应立即触发告警，并附带关键信息：发生时间、涉及人员，以及执行了哪些操作，例如 read、write、delete。Secrets 也需要监控。异常活动可能是凭证已被攻陷的早期迹象。

推荐工具

设置 Splunk Enterprise Security 来集中日志并捕获未授权访问或失败。如果你需要更经济的选择，Axiom 集成良好且能降低成本。无论哪种方式，都要确保你的 secrets manager 具备内置审计功能，以展示谁在什么上下文中访问了哪些 secrets。

结论

所有这些 PCI DSS V4.0 要求都有一个共同点：它们都指向有效的 secrets management。这就是为什么行业正在转向将 PCI 防护措施嵌入 secrets 生命周期每一层的解决方案。

Infisical 从一开始就是围绕这些控制措施构建的。

优势包括：

• 内置对动态 secrets 和自动化轮换的支持
• 完全开源的 codebase，可嵌入任何 DevOps workflow
• 灵活的多层 secret 层级结构，适用于 apps、envs 和 teams
• 原生 SSH credential 签发以及端到端证书管理
• 采用 AES-256-GCM 加密并强制使用 TLS
• 细粒度 RBAC，支持有时限的即时访问请求
• 开箱即用的审计轨迹，可流式传输到 Splunk、Datadog 和其他平台

如果你想了解更多，请在这里查看我们。

• 原文链接： infisical.com/blog/secre...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～