PCI-DSS 下的源代码存储库管理存在哪些限制（如果有）？
PCI-DSS 下的源代码存储库管理存在哪些限制（如果有）？
我工作的公司希望为我们网络下托管的客户开发信用卡处理服务。目前我们使用 SVN 进行版本控制。它是安全的，因此只有需要签出/提交访问权限的开发人员才能拥有它。与此同时，我正计划从 SVN 迁移到 HG。然而，由于缺乏对远程克隆的访问控制，安全团队对使用分布式 SCM 工具表示保留。具体来说，他们声称这将违反 PCI-DSS 合规性。是吗？
What restrictions, if any, exist over source code repository management under PCI-DSS?
The company I work at wants to develop a credit card processing service for clients hosted under our network. At the moment we're using SVN for version control. It's secured so that only the developers who need checkout/commit access have it. Meanwhile I was planning on moving from SVN to HG. However, the security team has expressed reservations about using a distributed SCM tool due to lack of access control on remote clones. Specifically, they claim this would violate PCI-DSS compliance. Does it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
首先，我只想说我的答案是基于快速阅读 PCI-DSS 2.0 ，特别是要求 6。
如果您以与使用 Subversion 类似的方式使用 Mercurial，我不明白为什么使用 Mercurial 会出现问题。以下是我这样认为的一些原因：
因此，我认为在使用像 Mercurial 这样的 DVCS 时，有足够的空间来遵守 PCI-DSS。以上所有内容同样适用于 Git。
First, I'll just say that I'm basing my answer on a quick read of PCI-DSS 2.0, specifically Requirement 6.
I don't see why using Mercurial would be a problem if you use it in a way comparable to how you used Subversion. Here are some reasons why I think this:
So I think there is plenty of scope to be PCI-DSS compliant while using a DVCS like Mercurial. Everything above would apply equally to Git.
正如其他人所说，如果您需要更多建议，可以向您的 QSA 提出这一问题。也就是说，PCI 的重点是实施正确的控制，而不是强制一种技术优于另一种技术。
开发时，您需要考虑：
这一切都不会阻止您使用存储库您选择的经理
As others have said, this is one to raise with your QSA if you need more advice. That said, PCI is about having the right controls in place rather than mandating one technology over another.
When developing, you need to think about:
Nothing in this should stop you using the repository manager of your choice
安全团队对于访问控制部分的看法是否正确取决于他们想要什么样的控制。
限制读取
对于 SVN 和任何 DVCS 而言，对开发人员可以读取的内容进行任何控制都是有限的。即使您拥有中央 SVN 服务器，通常也不会限制读取您有权访问的路径的旧版本。因此，您可以将旧的历史版本逐个修订转储到本地存储中（
hg subversion、git svn和许多其他工具正是以这种方式工作的）。 SVN 中没有什么神奇之处可以阻止某人下载每个版本并分发这些副本。最后，如果您无法限制用户端对工作副本的访问，则根本没有读取限制。时期。
限制写入
这是一个不同的游戏，因为 Mercurial 允许您根据需要将任何名称设置为提交者。因此，您需要在服务器上添加一些机制，以便任何开发人员都不能通过使用一位开发人员同事的名字提交来引入错误标记修订，并将此修订推送到服务器。虽然 AFAIK Subversion 确实在服务器上自行设置了用户名，但 hg 服务器必须以某种方式提供一个钩子来检查所有传入变更集的用户名。
¹ 也有一种方法可以在 Subversion 中更改提交者名称，但您必须在服务器上启用 pre-revprop 挂钩才能允许这样做。
If the security team is right about the access control part depends on what kind of control they do want.
Restricted read
Having any control about what one developer can read is limited both with SVN as with any DVCS. Even when you have a central SVN server typically there is no limitation to read old revisions of paths where you have the permission for. So you could dump the old history revision-by-revision into a local store (
hg subversion,git svnand lots of other tools work exactly this way). There is nothing magical in SVN which prevents someone from downloading every single revision and distribute these copies.At the end if you can't restrict the access to the working copies at the user side, you have no read restrictions at all. Period.
Restricted write
This is a different game, since Mercurial allows you to set any name as committer as you want¹. So you need to add some mechanics at the server so that no developer can introduce False-Flag revisions by committing with the name of one fellow developer, and push this revisions to the server. While AFAIK Subversion does set the username by itself on the server, a hg server must somehow be supplied with a hook to check the usernames for all incoming changesets.
¹ There is a way to change the commiter name in Subversion too, but you have to enable the pre-revprop hook on the server to allow this.