最小化 PCI DSS 暴露的最佳实践

Posted 2023-02-18

【中文标题】最小化 PCI DSS 暴露的最佳实践

【英文标题】：Best Practices to Minimise PCI DSS Exposure

【发布时间】：2015-09-03 23:34:28

【问题描述】：

来自 etsy.com offers some insight 的 Michael Rembetsy 将软件组件划分为 PCI 和非 PCI 环境。

我正在尝试确定软件架构方面的最佳解决方案。将您的 PCI 相关软件分割成单独的服务或只是单独的软件组件是最佳实践吗？

例如，如果我们考虑付款处理；将逻辑封装到 PCI 环境中包含的源代码模块中是最佳实践，并与非 PCI 环境并行将代码更改推送到生产环境，还是最好以 SOA 方式将支付处理逻辑封装到单个服务中？

换句话说，来自非 PCI 代码库的任何给定功能是否通过 HTTP 等通信协议与您的 PCI 代码库的任何给定功能（例如接受信用卡）通信，或者我应该简单地提供非 PCI 功能引用的 PCI 相关功能，如打包的 dll/jar 等？

在我看来，将与 PCI 相关的功能（例如支付处理）封装到单个服务中更为可取，因为我们可以控制服务可发现性的级别并定义明确的边界，而可能只是提供一个 dll/jar将安全源代码公开给非 PCI 环境中的开发人员进行反编译

【问题讨论】：

我们的政策是尽可能避免 PCI 范围；任何处理持卡人数据的东西都被实现为一个最小化的服务，它将与业务决策、日志记录等超出范围的组件进行通信。我们这样做是为了最大限度地减少 PCI 表面，因为任何推送到 PCI 生产环境的软件更改都必须经过一个代码审查/文档过程，这是一件乏味且耗时的事情。

【参考方案1】：

答案实际上取决于您希望通过细分实现什么。

如果您的目标是以某种方式减少/包含用于 PCI DSS 评估的范围内系统，那么根据我的经验，源代码模块化对您没有帮助。您的评估员很可能会根据这些系统是否处理、传输或存储 PCI DSS 定义的持卡人数据来定义“系统”范围。根据我的经验，源代码的模块化不会帮助您将该机器/设备从评估范围中删除。

如果您的目标纯粹是软件架构决策，那么我建议您审查这两种方法对非功能性需求（即性能、可用​​性、安全性等）的影响，以确定哪种方法最适合。

说了这么多，我的建议与其他海报一致 - 将您的 PCI 敏感系统抽象到清晰的服务边界后面。至少，这将允许您分别管理两个系统的生命周期。更重要的是，它可以让您灵活地更改 PCI 部件的部署架构，而无需更改相关系统。 PCI DSS 是一个实时标准，因此今年满足要求的东西明年可能不会。根据我的经验，通过松散耦合和 SOA 获得一定程度的敏捷性可以帮助您重新构建部署模型以适应新的约束。

我希望这会有所帮助！ :)

【参考方案2】：

对于黑客入侵您的电子邮件列表和运输数据库并向您的所有客户发送电子邮件说他们入侵了您并提供准确的送货地址作为他们进入数据库的证据，您是否可以接受？ （即使他们没有真正获得受 PCI 保护的信用卡号码等）如果没有，请考虑尽可能多地支持 PCI，因为它都需要保护。

如果发生上述情况，即使没有 CC 信息被泄露，信用卡公司也会将您视为“泄露后”。他们讨厌成功黑客的“外表”，可能比你更讨厌......

【讨论】：

当您说“尽可能多地支持 PCI”时，我将其解释为“是的，将 PCI 相关功能托管为与非 PCI 相关功能分开的进程，并具有明确定义的边界. 而不是简单地将 PCI 功能捆绑到单独的 jar/dll 文件中作为非 PCI 相关功能”。你同意吗？

保罗，抱歉我的回复太迟了 - 一直在担任总统竞选的国家数字总监，这让一个人非常忙碌......回答你的问题，我的意思是建立一个应该理解的理解使用 PCI 安全标准来保护所有他们的客户数据。我有 1 个安全客户（事后有人叫我），他们只有一些电子邮件/送货地址信息，正如我上面建议的那样。黑客向商家被黑客入侵的所有电子邮件地址发送了相同的电子邮件。信用卡公司讨厌这种糟糕的公关，并将促成 1 万美元的法医审计费用！