Access, permissões e segurança para desenvolvedores de terceiros

Question

Nosso departamento de marketing quer começar a contratar uma empresa externa para ajudar no desenvolvimento e manutenção de nosso site de marketing. O site agora está no FreeBSD (usando o apache), mas com planos dentro dos próximos meses para migrar tudo para o CentOS. Como está configurado agora, temos um servidor Subversion interno abrigando todo o código, os desenvolvedores verificam o código de entrada e saída, o código é então enviado para um servidor de temporariedade externo para garantir que tudo fique bem e depois enviado ao nosso servidor ativo.

Como mencionei, eles vão contratar uma empresa terceirizada para trabalhar com eles no código. Minha tarefa é poder trabalhar com o código, mas ao mesmo tempo mantê-los fora da rede.

Aqui estão algumas ideias que tive:

1. Dê-lhes acesso VPN através do nosso SonicWall (nosso gateway principal) e só permita acesso na porta 443 para o servidor Subversion e bloqueie todo o resto (eu nem tenho certeza se o Sonicwall vai fazer isso ou se isso só me permitirá conceder acesso em um nível de sub-rede.)

2. Configure um servidor subversion em uma DMZ e permita somente o tráfego de entrada de seu endereço IP corporativo. Isso efetivamente bloquearia o acesso à nossa rede, mas ainda permitiria que pessoas dentro e fora acessassem a subversão.

3. Conceda a eles uma conta no servidor de teste e deixe-os trabalhar a partir de lá (a solução mais preguiçosa e menos apreciada ...)

A opção 2 é aquela em que estou mais inclinado. Alguém tem alguma informação sobre essas soluções ou tem uma solução completamente diferente que funcionaria melhor? Nosso objetivo final é permitir que eles trabalhem no código sem comprometer nossa rede.

    

Answer 1

Supondo que mudar para um sistema descentralizado de controle de revisão decente como o Git não é uma opção (e onde "desenvolvedores terceirizados" estão envolvidos, eu não estaria confiante de que eles não farão um monte de SVN, vamos sozinho Git) ...

Se o SonicWall conseguir, fazer um buraco no firewall para dar acesso ao SVN internamente é uma opção, mas eu não gosto disso. Embora o SVN não tenha um histórico glorioso de brechas de segurança, é preciso apenas um para você ser surpreendido por algum idiota indigno de confiança da empresa terceirizada (ou de qualquer pessoa que tenha acesso à rede da empresa terceirizada ... "quão boa é a segurança dos sistemas no outro fim da VPN "é uma pergunta que nem é suficiente para as pessoas perguntarem).

Eu estaria colocando o servidor SVN em um local mutuamente não confiável e bloqueando-o como um tambor. Eu certamente não estaria dando a eles acesso a encenações, isso é apenas uma receita para cenários de pesadelo insustentáveis (as chances de você poder fazer uma implementação limpa são epsilon) e potenciais problemas de segurança que irão assombrar seus sonhos para sempre.