Access, Permissions, and Security for 3rd party developers

Question

Our Marketing department wants to start hiring an outside company to assist in the development and maintenance of our marketing website. The website right now is on FreeBSD (using apache), but with plans within the next couple of months to migrate everything to CentOS. How it's set up right now is we have an internal Subversion server housing all of the code, developers check code in and out, code is then pushed to an external staging server to make sure everything looks good, and then pushed to our live server.

Like I mentioned, they're going to be hiring an outsourced company to work with them on the code. My task is to be able to work with the code, but at the same time keep them out of network.

Here are some ideas I've had:

1. Give them VPN access through our SonicWall (our main gateway) and only allow them access on port 443 to the Subversion server and block off everything else (I'm not even sure if the Sonicwall will do this or if it will only allow me to grant access on a subnet level.)

2. Set up a subversion server in a DMZ and only allow inbound traffic from their corporate IP address. This would effectively block access into our network, but still allow people inside and outside to access subversion.

3. Give them an account on the staging server and just let them work from there (laziest, least liked solution...)

Option 2 is the one I'm leaning towards the most. Does anyone have any input on these solutions or have a completely different solution that would work better? Our end goal is to allow them to work on the code without compromising our network.

Answer 1

Assuming that moving to a decent decentralised revision control system like Git isn't an option (and where "outsourced developers" are involved, I wouldn't be confident that they won't make a balls-up of SVN, let alone Git)...

If the SonicWall can do it, punching a hole in the firewall to give them access to SVN internally is an option, but I don't like it. Whilst SVN doesn't have a glorious history of security holes, it only takes one for you to be popped by some untrustworthy idiot at the outsourced company (or anyone who has access to the outsourced company's network... "how good is the security of the systems at the other end of the VPN" is a question not nearly enough people ask).

I'd be putting the SVN server in a mutually untrusted location and locking it down tight as a drum. I certainly wouldn't be giving them access to staging, that's just a recipe for unmaintainable nightmare scenarios (the chances of you being able to do a clean deploy are epsilon) and potential security problems that'll haunt your dreams forever.