集中式与分布式版本控制安全性
当我的公司开始进一步探索从集中式版本控制工具（CVS、SVN、Perforce 和许多其他工具）转向为团队提供分布式版本控制工具（在我们的例子中为 Mercurial）时，我遇到了一个问题：
问题
经理提出了这样的担忧：分布式版本控制可能不如我们的 CVCS 选项安全，因为存储库历史记录本地存储在开发人员的计算机上。
很难确定他的确切安全问题，但我认为它集中在这样一个事实：恶意员工不仅可以通过复制单个文件夹来窃取最新的知识，还可以窃取我们整个更改的历史记录。
问题
- 分布式版本控制系统真的会给项目带来新的安全问题吗？
- 恶意窃取代码是否更容易？
- 完整的历史记录是否代表了最新版本代码所没有的额外威胁？
我的想法
我的看法是，这可能是一个错误的想法，即中心化模型更安全，因为历史似乎更安全，因为它是独立的。鉴于即使对集中式存储库具有读取访问权限的用户也可以有选择地提取任何关键修订版项目的快照，我不确定 DVCS 模型是否能让这一切变得更容易。此外，大多数 CVCS 工具允许您使用单个命令提取整个存储库的历史记录，以便您可以将它们导入到其他工具中。
我认为另一个问题是历史与最新版本相比有多重要。假设有人可以签入绝密文件，然后将其删除，那么历史记录很快就会变得很重要。但即使在这种情况下，CVCS 用户也可以使用单个命令查看该绝密版本。
我确信我可能会遗漏某些内容或淡化风险，因为我渴望看到 DVCS 成为完全受支持的工具选项。请贡献您对安全问题的任何想法。
As my company begins to further explore moving from centralized version control tools (CVS, SVN, Perforce and a host of others) to offering teams distributed version control tools (mercurial in our case) I've run into a problem:
The Problem
A manager has raised the concern that distributed version control may not be as secure as our CVCS options because the repo history is stored locally on the developer's machine.
It's been difficult to nail down his exact security concern but I've gathered that it centers on the fact that a malicious employee could steal not only the latest intellectual properly but our whole history of changes just by copying a single folder.
The Question(s)
- Do distributed version control system really introduce new security concerns for projects?
- Is it easier to maliciously steal code?
- Does the complete history represent an additional threat that the latest version of the code does not?
My Thoughts
My take is that this may be a mistaken thought that the centralized model is more secure because the history seems to be safer as it is off on its own box. Given that users with even read access to a centralized repo could selectively extract snapshots of the project at any key revision I'm not sure the DVCS model makes it all that easier. Also, most CVCS tools allow you to extract the whole repo's history with a single command so that you can import them into other tools.
I think the other issue is just how important the history is compared to the latest version. Granted someone could have checked in a top secret file, then deleted it and the history would pretty quickly be significant. But even in that scenario a CVCS user could checkout that top secret version with a single command.
I'm sure I could be missing something or downplaying risks as I'm eager to see DVCS become a fully supported tool option. Please contribute any ideas you have on security concerns.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
DVCS 提供多种保护措施，防止未经授权的写入。这就是它受到开源团队欢迎的原因。它在控制阅读方面有一些令人沮丧的限制。开源团队并不关心这个。
第一个问题是大多数 DVCS 鼓励复制完整源代码。典型的粒度是完整的仓库。除了历史记录之外，这可能包括许多不需要的分支，甚至整个其他项目（以及可搜索的提交注释，可以使代码对攻击者更有用）。 CVCS 鼓励开发人员尽可能少地复制到桌面，因为复制越少，运行速度就越快。您在移动设备上放置的内容越少，就越容易确保安全。
当使用许多设备作为服务器来实施DVCS时，实现有效的网络安全就变得更加困难。攻击本地 CVCS 工作区需要攻击者获得文件系统的访问权限。攻击 DVCS 节点通常需要攻击任何托管信息的设备上的 DVCS 本身（请记住：维护大多数 DVCS 的人都是开源人员；他们不太关心读取控制）。托管存储库的设备越多，用户设置匿名读取访问的可能性就越大（DVCS 由于其开源根源而再次鼓励这样做）。这极大地简化了进行随机扫描的攻击者的工作。
基于 URL（如 subversion）的 CVCS 为相当细粒度的访问控制（例如每个分支的访问）提供了机会。 DVCS 倾向于对抗这种访问控制。
我知道开发人员喜欢 DVCS，但它无法像 CVCS 那样有效地得到保护。大多数环境在保护 CVCS 方面做得很糟糕，如果是这种情况，那么您使用哪个都没有关系。但如果您认真对待访问控制，您可以将 CVCS 作为更广泛的最低权限基础设施的一部分进行更大的控制。
许多人可能会认为没有理由保护源代码。这很好，人们可以争论它。但是，如果您要保护源代码，最好的实现是不要将源代码复制到随机笔记本电脑（这很难很好地保护），而是让开发人员从中央服务器安装它。 CVCS 以这种方式运作良好。如果您打算以这种方式将其保留在单个服务器上，则 DVCS 毫无意义。如果要将文件复制到移动设备，请确保复制尽可能少。这与 DVCS 相反。
DVCS provides various protections against unauthorized writing. This is why it is popular with opensource teams. It has several frustrating limitations for controlling reading. Opensource teams do not care about this.
The first problem is that most DVCS encourage many copies of the full source. The typical granularity is the full repo. This can include many unneeded branches and even entire other projects, besides the concern of history (along with searchable commit comments that can make the code even more useful to the attacker). CVCS encourages developers to copy as little as possible to their desktop, since the less they copy, the faster it works. The less you put on mobile devices, the easier it is to secure.
When DVCS is implemented with many devices acting as servers, it is much more difficult to implement effective network security. Attacking a local CVCS workspace requires the attacker to gain access to the filesystem. Attacking a DVCS node generally requires attacking the DVCS itself on any device hosting the information (and remember: the folks who maintain most DVCS's are opensource guys; they don't care nearly as much about read controls). The more devices that host repositories, the more likely that users will set up anonymous read access (which again, DVCS encourages because of its opensource roots). This greatly simplifies the job of an attacker who is doing random sweeps.
CVCS that are based on URLs (like subversion) open the opportunity for quite fine-grain access control, such as per-branch access. DVCS tends to fight this kind of access control.
I know developers like DVCS, but there's no way it can be secured as effectively as CVCS. Most environments do a terrible job of securing their CVCS, and if that's the case then it doesn't matter which you use. But if you take access control seriously, you can have much greater control with CVCS as part of a broader least-privilege infrastructure.
Many may argue that there's no reason to protect source code. That's fine and people can argue about it. But if you are going to protect your source code, the best implementation is to not copy the source to random laptops (which are very hard to secure well), and rather have developers mount it from a central server. CVCS works well this way. DVCS makes no sense if you are going to keep it on a single server this way. If you are going to copy files to mobile devices, make sure you copy as little as possible. That's the opposite of DVCS.
有很多“安全”问题；它们是否是一个问题取决于您的设置：
svn://是明文。最后，安全经济学：
（IIRC 事实证明，用户应该忽略安全建议，因为预期成本大于预期收益——对于昨天过期的证书尤其如此。每次键入内容时检查地址栏要花多少钱每次失败的网络钓鱼尝试的成本是多少？）
There are a bunch of "security" issues; whether they are an issue depends on your setup:
svn://is plaintext.And finally, security economics:
(IIRC it turns out that users should ignore security advice, because the expected cost is more than the expected benefit — this is especially true for things like certificates that expired yesterday. How much does it cost you to check the address bar every time you type in password? How often do you catch a phishing attempt? What is the cost to you per thwarted phishing attempt? What is the cost per successful phish?)
如果您拥有 CVCS 的读取权限，您就有足够的权限将存储库转换为 DVCS，人们一直在这样做。没有任何软件工具可以保护您免受心怀不满的员工窃取您的代码的影响，但 DVCS 有更多选项来处理不受信任的贡献者，例如看门人工作流程。因此它在开源项目中得到广泛使用。
If you have read access to a CVCS, you have enough permissions to convert the repo to a DVCS, which people do all the time. No software tool is going to protect you from a disgruntled employee stealing your code, but a DVCS has many more options for dealing with untrusted contributors, such as a gatekeeper workflow. Hence its widespread use in open source projects.
这取决于如何在这两种情况下实施安全措施的知识。如果您在一个系统上比另一个系统有更多的经验，那么您更有可能实施更多措施来防止这种损失，但最终，您在允许开发人员访问代码的那一刻就信任他们的代码。没有办法解决这个问题。
It comes down to knowledge on how to implement security measures in both cases. If you have more experience in one system vs another then you are more likely to implement more to prevent such loss but at the end of the day, you are trusting your developers with code the minute you allow them access to it. No way around that.