architecture - 最大限度减少 PCI DSS 风险的最佳实践

Question

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

我正在尝试确定软件架构方面的最佳解决方案。将与 PCI 相关的软件划分为单独的服务或仅划分为单独的软件组件是最佳做法吗？

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

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

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

Answer 1

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

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

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

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

希望对您有所帮助! :)