PCI-DSS 下的源代码存储库管理存在哪些限制(如果有)?
我工作的公司希望为托管在我们网络下的客户开发信用卡处理服务。目前我们正在使用 SVN 进行版本控制。它是安全的,因此只有需要结帐/提交访问权限的开发人员才能拥有它。与此同时,我正计划从 SVN 转移到 HG。然而,由于缺乏对远程克隆的访问控制,安全团队对使用分布式 SCM 工具表示保留。具体来说,他们声称这将违反 PCI-DSS 合规性。可以?
PCI-DSS 下的源代码存储库管理存在哪些限制(如果有)?
我工作的公司希望为托管在我们网络下的客户开发信用卡处理服务。目前我们正在使用 SVN 进行版本控制。它是安全的,因此只有需要结帐/提交访问权限的开发人员才能拥有它。与此同时,我正计划从 SVN 转移到 HG。然而,由于缺乏对远程克隆的访问控制,安全团队对使用分布式 SCM 工具表示保留。具体来说,他们声称这将违反 PCI-DSS 合规性。可以?
首先,我只想说我的答案基于对PCI-DSS 2.0的快速阅读,特别是要求 6。
如果您以与使用 Subversion 的方式相当的方式使用 Mercurial,我不明白为什么使用 Mercurial 会有问题。以下是我认为的一些原因:
所以我认为在使用像 Mercurial 这样的 DVCS 时,符合 PCI-DSS 的空间很大。以上所有内容都同样适用于 Git。
正如其他人所说,如果您需要更多建议,可以向您的 QSA 提出。也就是说,PCI 是关于建立正确的控制,而不是强制一种技术凌驾于另一种技术之上。
开发时需要考虑:
这不应该阻止您使用您选择的存储库管理器
安全团队对访问控制部分是否正确取决于他们想要什么样的控制。
SVN 和任何 DVCS 都限制了对开发人员可以阅读的内容的任何控制。即使您有一个中央 SVN 服务器,通常也没有限制读取您有权访问的路径的旧版本。因此,您可以将旧的历史版本逐个版本地转储到本地存储中(hg subversion
许多git svn
其他工具正是以这种方式工作的)。SVN 中没有什么神奇的东西可以阻止某人下载每个修订版并分发这些副本。
最后,如果您不能在用户端限制对工作副本的访问,那么您根本就没有读取限制。时期。
这是一个不同的游戏,因为 Mercurial 允许您根据需要将任何名称设置为提交者¹。因此,您需要在服务器上添加一些机制,以便没有开发人员可以通过使用一位开发人员的名称提交来引入 False-Flag 修订,并将此修订推送到服务器。虽然 AFAIK Subversion 确实在服务器上自行设置了用户名,但必须以某种方式为 hg 服务器提供一个挂钩来检查所有传入变更集的用户名。
¹ 也有一种方法可以在 Subversion 中更改提交者名称,但您必须在服务器上启用 pre-revprop 挂钩才能允许这样做。