4

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.

Improve this question
1
  • Have someone use git-svn, do a checkout of the code you want to collaborate on. Push a copy of the git repository to some external location that both of you can access? Someone inside would need to be responsible for pulling in changes and merging it back to svn repository?
    – Zoredache
    Jul 27, 2011 at 20:49

1 Answer 1

Reset to default
3

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.

Improve this answer
1
  • +1 For the insight on VPN security. The more I think about it, the more I agree with you. The best way to keep our server secure is to not even allow them into it. Looks like I'll be setting up an external SVN server. Thanks for the suggestion.
    – Safado
    Jul 28, 2011 at 15:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .