3

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

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

4

3 回答 3

8

首先，我只想说我的答案基于对PCI-DSS 2.0的快速阅读，特别是要求 6。

如果您以与使用 Subversion 的方式相当的方式使用 Mercurial，我不明白为什么使用 Mercurial 会有问题。以下是我认为的一些原因：

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

所以我认为在使用像 Mercurial 这样的 DVCS 时，符合 PCI-DSS 的空间很大。以上所有内容都同样适用于 Git。

于 2012-01-21T21:26:11.897 回答
1

正如其他人所说，如果您需要更多建议，可以向您的 QSA 提出。也就是说，PCI 是关于建立正确的控制，而不是强制一种技术凌驾于另一种技术之上。

开发时需要考虑：

  • 测试/开发和生产系统之间的职责分离
  • 能够检测到变化、它们的起源、时间和由谁
  • 推送上线时有变更控制程序

这不应该阻止您使用您选择的存储库管理器

于 2012-01-25T13:23:04.247 回答
0

安全团队对访问控制部分是否正确取决于他们想要什么样的控制。

限制阅读

SVN 和任何 DVCS 都限制了对开发人员可以阅读的内容的任何控制。即使您有一个中央 SVN 服务器，通常也没有限制读取您有权访问的路径的旧版本。因此，您可以将旧的历史版本逐个版本地转储到本地存储中（hg subversion许多git svn其他工具正是以这种方式工作的）。SVN 中没有什么神奇的东西可以阻止某人下载每个修订版并分发这些副本。

最后，如果您不能在用户端限制对工作副本的访问，那么您根本就没有读取限制。时期。

受限写入

这是一个不同的游戏，因为 Mercurial 允许您根据需要将任何名称设置为提交者¹。因此，您需要在服务器上添加一些机制，以便没有开发人员可以通过使用一位开发人员的名称提交来引入 False-Flag 修订，并将此修订推送到服务器。虽然 AFAIK Subversion 确实在服务器上自行设置了用户名，但必须以某种方式为 hg 服务器提供一个挂钩来检查所有传入变更集的用户名。

¹ 也有一种方法可以在 Subversion 中更改提交者名称，但您必须在服务器上启用 pre-revprop 挂钩才能允许这样做。

于 2012-01-27T21:21:59.570 回答