在保护对源代码的访问方面，行业最佳做法是什么？ 我想通过Apache的SSL连接只允许通过我们的服务器在一个不与别的冲突的模糊的端口。 困扰我的事情是将源代码存储在面向公众的服务器上，即不仅可以通过局域网访问。 而且，这个服务器有几个用途。 阿帕奇已经提供了一些其他内部公司的网站。 我希望每个人都能够从任何地方（家庭，机场，任何地方）访问源代码，只要他们有正确的凭据。 build议？
如果您担心它在面向公众的服务器上，但希望从任何地方访问，则应考虑让开发人员使用基于客户端的VPN来远程login到您的networking，以访问内部源控制服务器。
我不太确定为什么人们认为VPN方法是最好的。 这不一定更安全，只能提供我能想到的一个优势。
据了解，PPTP的安全性不太理想，但我相信自从首次推出以来，它有所改进…所以要小心使用哪种VPN解决scheme。 我会去与OpenVPN或IPSEC。
但是，如果不使用VPN，则无法打破SSL / TLS的便利（进一步阅读下文）。 并且为了使它更加安全，您可以只使用证书。
但是，如果您认为您可能会提供源控制以外的其他服务，那么请考虑使用VPN解决scheme，因为您会将其他服务隧道化。
使用VPN的缺点是，您的PC有效地成为它所连接的networking的一部分。 这也可能是一个优势。 但是，如果你距离家乡100万英里，并且与家庭networking的连接速度不是很快，那么每当你想进行差异检查或检查代码时，你可能会发现自己连接和断开了VPN。
我可以从这里亲身体验一下，因为我是一名开发人员，在做这件事情时真的很痛苦！ 理想情况下，两种select都是首选。
所以，如果你要浏览网页等，那么它可能会使阅读新闻等相当缓慢。 但至less你可以安全地访问电子邮件。 所以考虑你将如何使用它…如果我是你，我会考虑实施两个。
其实，我喜欢你的build议。 如果您只能通过SSL / TLS访问您的源代码库，并确保您的开发人员不使用易于暴力的密码（或者更好的是使用证书），那么应该与其他任何东西一样安全。
您可以将您的服务器隐藏在局域网内，并强制开发人员使用VPN来访问，但这意味着您的开发人员需要将其用户名/密码（和/或证书）放入不同的login框中。 我build议不要在您的networking中创build一个入口点，其安全隐患可能并不总是显而易见的，只是为了允许访问单个服务。 如果您已经configuration了VPN并为其他用途进行了保护，那么确定无疑，请继续使用。 否则，通过SSL / TLS直接提供服务可能会更简单，从而更安全。
行业标准可能取决于你（或你的客户）的行业:-)
实际上，您需要考虑您想要访问的人员以及他们可以处理的内容。 有些人可能想要/需要访问将无法应付不仅仅是一个用户名/密码。 其他人也许可以通过ssh和一个私钥来获得他们的头，只要你能够安全地把钥匙给他们，那也不错。 TortoiseSVN客户端可以处理ssh + svn，并支持一些arm扭曲的私钥。 这已经足够我的目的。
一个VPN隧道也是一个公平的build议，虽然在很多地方你会很乐意让外部的人访问你的源代码控制，但不是你的整个networking！
像其他人一样，我更喜欢VPN。 另一个select是SSH隧道，无论如何，我认为实际上它是一种VPN。
使其仅限于内部使用，并实施远程用户VPN解决scheme。 / Doh-重复。
如果你想从任何地方访问，那么你需要一个面向公众的服务器 – 这很清楚。
在那个服务器上，你想尽可能less地暴露 ，最好是Mercurial / Subversion，而不是别的。 这是为了防止安全漏洞从源代码控制传播到公司的其他部门。 出于这个原因，我会同意马特说，一个VPN可能是危险的：它提供了比需要更广泛的访问。
对于Mercurial，您可以通过使用hg-ssh来限制可用于通过SSH连接的客户端的命令，从而将事情紧紧locking。 通过使用SSH，您可以轻松地要求客户端使用公钥validation而不是密码。 这可以保护您的服务器免受暴力login攻击。
即使一个SSH密钥被攻破（也许它有一个弱密码短语和存储它的笔记本被盗），那么攻击者可以做的最坏的破坏就是在Mercurial中添加垃圾历史。 所使用的协议本质上只是附加的，所以没有什么可以用hg push来删除。
对于HTTPS， 身份validation由前端Web服务器完成 。 这意味着，如果您需要，您可以要求客户端站点证书，因此可以像上面的SSH公钥authentication那样获得安全性。