集中式与分布式版本控制安全性

Question

随着我的公司开始进一步探索从集中版本控制工具（CVS，SVN，Perforce和其他许多人）转向提供团队分布式版本控制工具（在我们的案例中为mercurial），我遇到了一个问题：< / p>

问题

管理员已经提出担心分布式版本控制可能不如我们的CVCS选项那么安全，因为回购历史记录本地存储在开发人员的机器上。

很难确定他确切的安全问题但是我已经认识到，它的核心是这样一个事实：恶意员工不仅可以通过复制单个文件夹来正确窃取最新的知识产权，还可以窃取我们的整个变更历史。 / p>

问题

• 分布式版本控制系统真的为项目引入了新的安全问题吗？
• 恶意窃取代码更容易吗？
• 完整的历史记录是否代表了最新版本的代码所没有的额外威胁？

我的想法

我的看法是，这可能是错误的想法，集中模型更安全，因为历史似乎更安全，因为它在自己的盒子上。鉴于具有对集中式仓库的读访问权限的用户可以在任何关键修订版中选择性地提取项目的快照，我不确定DVCS模型是否使这一切变得更加容易。此外，大多数CVCS工具允许您使用单个命令提取整个repo的历史记录，以便您可以将它们导入其他工具。

我认为另一个问题是历史与最新版本相比有多重要。当然有人可以检查一个绝密文件，然后删除它，历史很快就会很重要。但即使在这种情况下，CVCS用户也可以通过一个命令来检查该绝密版本。

我确信我可能会遗漏某些内容或淡化风险，因为我渴望看到DVCS成为完全支持的工具选项。请提出您对安全问题的任何想法。

Answer 1

如果您具有CVCS的读取权限，则您有足够的权限将回购转换为DVCS，人们一直这样做。没有任何软件工具可以保护您免受心怀不满的员工窃取您的代码的影响，但DVCS还有更多选项可用于处理不受信任的贡献者，例如网守工作流程。因此，它广泛用于开源项目。

Answer 2

• 你是对的，分布式版本控制并没有真正引入任何新的安全问题，因为开发人员已经在两种情况下都可以访问代码。我只能认为，由于使用GIT离线和离线工作更容易，开发人员可能会比集中式更容易做到这一点。我会推动使用代码
对所有公司笔记本电脑强制加密
• 不是很容易，只是一样。如果启用日志，则在访问代码时将获得相同的信息。
• 我个人不这么认为。它可能代表导致某些决定的思考过程，但不一定更多。

归结为如何在两种情况下实施安全措施的知识。如果您在一个系统与另一个系统中拥有更多经验，那么您更有可能实施更多以防止此类丢失，但在一天结束时，您只需在允许其访问代码的情况下信任您的开发人员。没办法。

Answer 3

DVCS提供各种保护措施，防止未经授权的写作。这就是开源团队受欢迎的原因。它控制阅读有几个令人沮丧的限制。开源团队并不关心这一点。

第一个问题是大多数DVCS鼓励使用完整源代码的许多副本。典型的粒度是完整的回购。这可能包括许多不需要的分支甚至整个其他项目，除了历史的关注（以及可搜索的提交注释，可以使代码对攻击者更有用）。 CVCS鼓励开发人员尽可能少地复制到他们的桌面，因为他们复制的越少，它的工作速度就越快。您放置移动设备的次数越少，就越容易保护。

当许多设备作为服务器实施DVCS时，实现有效的网络安全性要困难得多。攻击本地CVCS工作空间需要攻击者获得对文件系统的访问权限。攻击DVCS节点通常需要在托管信息的任何设备上攻击DVCS本身（并记住：维护大多数DVCS的人是开源人员;他们并不关心读取控制的程度）。托管存储库的设备越多，用户设置匿名读访问的可能性就越大（DVCS鼓励因为其开源根源而鼓励）。这极大地简化了正在进行随机扫描的攻击者的工作。

基于URL的CVCS（如subversion）为相当细粒度的访问控制提供了机会，例如每分支访问。 DVCS倾向于对抗这种访问控制。

我知道开发人员喜欢DVCS，但是没有办法像CVCS一样有效地保护它。大多数环境在保护CVCS方面做得非常糟糕，如果是这种情况，那么使用哪种环境并不重要。但是，如果您认真对待访问控制，那么作为更广泛的最低权限基础架构的一部分，您可以更好地控制CVCS。

许多人可能认为没有理由保护源代码。这很好，人们可以争论它。但是，如果要保护源代码，最好的实现方法是不要将源代码复制到随机笔记本电脑（很难很好地保护），而是让开发人员从中央服务器安装它。 CVCS以这种方式运作良好。如果您打算以这种方式将它保存在单个服务器上，DVCS毫无意义。如果要将文件复制到移动设备，请确保尽可能少地复制。这与DVCS相反。

Answer 4

有一堆“安全”问题;它们是否是一个问题取决于您的设置：

• 周围有更多的数据，这意味着名义上的“攻击面”可能更大（取决于你的计算方式）。
  • 但“典型”开发人员检查了多少数据？你可能想在svn中使用稀疏结账，但懒人和一些GUI工具不支持，所以无论如何他们都会检查你的所有代码。 Git用户可能更有可能使用多个回购。这取决于你。
• 身份验证/访问控制可能更好（可能更糟糕！）。这在很大程度上取决于VCS，而不是它是“D”还是“C”。 svn://是明文。
• 删除文件是否优先，这有多容易？如果它发生在遥远的过去，那么在git中意外提交机密文件会更加痛苦（但是人们可能更容易注意到这一点）。
• 您是否真的会注意到恶意用户拉动整个历史记录而不仅仅是结帐？这取决于您的存储库有多大以及您的分支是什么样的。由于分支，完整的SVN结账很容易占用更多空间而不是存储库本身。
• 更改历史记录通常不是您想要免费赠送的内容（即使是拥有源代码许可证的人），但它有多重要？也许你的提交消息中有绝密的设计方法或机密信息，但这似乎不太可能。

最后，安全经济学：

• 额外的安全价值是多少？
• 提高生产力的价值是多少？
• 关心您的开发者值得关注的是多少？

（IIRC事实证明，用户应该忽略安全建议，因为预期的成本比预期的利多 - 这是一个类似的事情昨天过期的证书更是如此多少它的成本你检查地址栏的每个。您在密码输入时间？你多久赶上网络钓鱼企图？什么是你的成本每挫败钓鱼企图是什么？每成功网络钓鱼的成本是多少？）