我试图在软件架构方面确定最佳解决方案。将PCI相关软件划分为单独的服务或仅使用单独的软件组件是最佳做法吗？
例如，如果我们考虑付款处理;最好的做法是将逻辑封装到PCI环境中包含的源代码模块中，并将代码更改推送到与非PCI环境并行的生产，还是最好以SOA方式将支付处理逻辑封装到单个服务中？
换句话说，来自非PCI代码库的任何给定功能是否通过HTTP等通信协议与PCI代码库的任何给定功能（例如，接受信用卡）进行通信，或者我应该只提供PCI相关功能作为打包的dll / jar等，非PCI功能引用？
在我看来，将PCI相关功能（例如支付处理）封装到单个服务中是更理想的，因为我们可以控制服务可发现性水平并定义明确的边界，而只是简单地提供dll / jar在非PCI环境中公开安全源代码以供开发人员反编译
答案 0 :(得分：1)
The answer really depends on what you wish to achieve with the segmentation.
If you goal is to somehow reduce/contain the in-scope systems for PCI DSS assessment, then in my experience source code modularisation will not help you. Your assessor will most likely define in scope "systems" by whether these systems process, transmit or store card holder data as defined by PCI DSS. In my experience, modularisation of the source code will not help you remove that machine/device from the scope of the assessment.
Should your goal be purely a software architecture decision, then I would suggest that the impact of both approaches on the non-functional requirements (i.e. performance, availability, security etc.) be reviewed to determine which approach suits best.
In saying all that, my advice would be in line with the other posters - abstract your PCI sensitive systems behind clear service boundaries. At a minimum this will allow you manage the life cycle of the two system separately. More importantly, it will give you the flexibility to change the deployment architecture of the PCI pieces without having to change the dependent systems. PCI DSS is a live standard so something that meets requirements this year may not next year. In my experience, having some level of agility through loose coupling and SOA helps you re-architect deployment models to suit new constraints.
I hope this helps! :)
答案 1 :(得分：-1)
黑客是否可以妥协您的电子邮件列表和发货数据库，并通过电子邮件通知所有客户说他们攻击了您，提供准确的送货地址作为他们进入数据库的证据？ （即使他们没有真正获得PCI保护的信用卡号码等）如果没有，考虑尽可能多地支持PCI，因为它都需要保护。
信用卡公司将考虑您在妥协后＆＃39;如果发生上述情况，即使没有CC信息被泄露。他们讨厌外表＆＃39;一个成功的黑客，可能比你更多...