我们的营销部门希望开始聘请外部公司来协助开发和维护我们的营销网站。目前该网站使用的是 FreeBSD（使用 apache），但计划在未来几个月内将所有内容迁移到 CentOS。目前的设置是，我们有一个内部 Subversion 服务器，用于存放所有代码，开发人员将代码签入和签出，然后将代码推送到外部暂存服务器以确保一切正常，然后推送到我们的实时服务器。
就像我提到的，他们将聘请一家外包公司来与他们合作编写代码。我的任务是能够处理代码，但同时让他们远离网络。
以下是我的一些想法：
通过我们的 SonicWall（我们的主要网关）为他们提供 VPN 访问权限，并且只允许他们通过端口 443 访问 Subversion 服务器并阻止其他所有内容（我甚至不确定 Sonicwall 是否会这样做，或者它是否只允许我在子网级别授予访问权限。）
在 DMZ 中设置 Subversion 服务器，仅允许来自其公司 IP 地址的入站流量。这将有效地阻止对我们网络的访问，但仍允许内部和外部人员访问 Subversion。
为他们在登台服务器上提供一个帐户并让他们从那里开始工作（最懒惰、最不喜欢的解决方案......）
我最倾向于选择 2。有人对这些解决方案有什么意见吗？或者有完全不同的更好的解决方案吗？我们的最终目标是让他们能够在不损害我们网络的情况下处理代码。
答案1
假设转向 Git 这样像样的分散式版本控制系统不是一个选择（并且涉及“外包开发人员”，我不能确信他们不会把 SVN 搞砸，更不用说 Git 了）...
如果 SonicWall 可以做到这一点，那么在防火墙上打一个洞让他们能够从内部访问 SVN 也是一种选择，但我不喜欢这样做。虽然 SVN 的安全漏洞历史并不光彩，但只要有一个漏洞，外包公司（或任何有权访问外包公司网络的人）的某个不值得信任的白痴就会打开你的漏洞......“外包公司的系统安全性有多好其他VPN 的终结” 是一个几乎没有人问过的问题）。
我会把 SVN 服务器放在一个互相不信任的位置，然后把它锁得严严实实。我当然不会让他们访问暂存区，这只会导致无法维护的噩梦场景（您能够进行干净部署的机会是极小的），并且潜在的安全问题会永远困扰着您的梦想。