尽量减少PCI暴露的最佳实践

Question

来自etsy.com 提供一些洞察力的Michael在将软件组件分割为PCI和非PCI环境方面。

我试图从软件体系结构的角度来确定最优的解决方案。将您的PCI相关软件分割成不同的服务，或者仅仅是单独的软件组件是最佳实践吗？

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

换句话说，来自非PCI代码库的任何给定功能是否通过HTTP之类的通信协议与PCI代码库中的任何给定功能(例如，接受信用卡)进行通信，还是应该简单地提供与PCI相关的特性作为打包的dll/jar，而非PCI功能引用这些特性？

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

Answer 1

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

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

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

说到这一点，我的建议将与其他海报一致-抽象您的PCI敏感系统背后明确的服务边界。至少，这将允许您分别管理这两个系统的生命周期。更重要的是，它将使您可以灵活地更改PCI部件的部署架构，而不必更改依赖的系统。PCI是一个实时的标准，所以今年满足要求的东西可能不会在明年出现。在我的经验中，通过松散耦合和SOA具有一定程度的敏捷性可以帮助您重新架构部署模型以适应新的约束。

希望这会有所帮助！)

Answer 2

你同意黑客破坏你的电子邮件列表和运输数据库，给你所有的客户发邮件说他们黑了你，提供了一个准确的发货地址作为他们进入数据库的证据吗？(即使他们没有真正获得PCI保护的信用卡号码等)如果不是，请考虑尽可能多地支持PCI，因为所有这些都需要保护。

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