PCI-DSS下的源代码存储库管理存在哪些限制(如果有)？

Question

PCI-DSS下的源代码存储库管理存在哪些限制(如果有)？

我工作的公司希望为我们网络下托管的客户开发信用卡处理服务.目前我们正在使用SVN进行版本控制.它是安全的,只有需要签出/提交访问权限的开发人员才能拥有它.与此同时,我计划从SVN转移到HG.但是,由于缺少对远程克隆的访问控制,安全团队对使用分布式SCM工具表示保留.具体而言,他们声称这会违反PCI-DSS合规性.可以？

Answer 1

首先,我只是说我的答案是快速阅读PCI-DSS 2.0,特别是要求6.

我不明白为什么使用Mercurial是一个问题,如果你使用它的方式与你使用Subversion的方式相当.以下是我认为这个的一些原因:

• 据推测,您不会将客户数据存储在您的存储库中(只有对该数据进行操作的代码).
• PCI-DSS经常使用诸如"标准行业惯例"之类的词语.Mercurial现在是一个非常常见的VCS,这很有帮助.
• 似乎是推动需要锁定的变更集的能力.特别是,能够推动存储库的"规范"克隆.仅仅因为Mercurial具有这些"远程克隆"并且开发人员可以将随机(甚至恶意)更改推送到这些克隆中,并不意味着这些更改将(或应该)最终出现在您的生产系统中.
• 使用Subversion,听起来你有权限将签入限制到开发人员的子集(或者甚至只是一个"看门人"？).
• 使用Mercurial,您可以将其设置为在中央(规范的"生产"存储库)上使用SSH.为每个开发人员提供他们自己的SSH凭据(这是PCI-DSS所必需的 - 没有共享密码!).在这种情况下,您可以在托管中央存储库的文件系统上设置权限,并且只在Mercurial目录中为特定用户提供写访问权限.
• 使用Mercurial,您可以改为(或者)通过HTTP发布您的中央仓库.在这种情况下,您可以使用Apache(或其他Web服务器)进行身份验证和授权.
• 您还可以完全禁止对中央仓库进行写入,并且判定所有源更改必须通过一个或两个特定人员发送,他们将在拉动(或应用)之前查看更改.

所以我认为在使用像Mercurial这样的DVCS时,有足够的空间可以兼容PCI-DSS.以上所有内容同样适用于Git.