Onde manter o repositório de origem central?

Qual é a melhor prática do setor em relação à segurança do acesso ao código-fonte? Estou pensando que apenas conexões SSL via apache permitidas para o servidor em uma porta obscura que não entre em conflito com mais nada. O que me incomoda é armazenar o código-fonte em um servidor público, ou seja, não apenas acessível via LAN. Além disso, este servidor tem vários usos. O Apache já está disponibilizando outros sites internos da empresa. Gostaria que todos pudessem acessar o código-fonte de qualquer lugar (residências, aeroporto, qualquer que seja), desde que tenham as credenciais corretas. Sugestões?

Se você está preocupado com o fato de ele estar em um servidor público, mas gostaria de acessar de qualquer lugar, considere que seus desenvolvedores usem uma VPN baseada em cliente para fazer login remotamente na sua rede para acessar um servidor de controle de origem interno.

Não sei ao certo por que as pessoas pensam que a abordagem da VPN é a melhor. Não é necessariamente mais seguro e oferece apenas uma vantagem em que consigo pensar.

Sabe-se que o PPTP, por exemplo, possui uma segurança abaixo do ideal, embora eu acredite que tenha melhorado um pouco desde a primeira introdução ... portanto, tenha cuidado com a solução de VPN que você usa. Eu iria com OpenVPN ou IPSEC.

No entanto, você não pode superar a conveniência do SSL / TLS sem a VPN (leia mais abaixo). E para torná-lo ainda mais seguro, você pode torná-lo apenas certificado.

No entanto, se você acha que pode oferecer outros serviços além do controle de origem, considere uma solução VPN, porque você encapsulará outros serviços.

A desvantagem de usar uma VPN é que seu PC se torna efetivamente parte da rede na qual está se conectando. Isso também pode ser uma vantagem. Mas, se você está a um milhão de milhas de distância de casa e a conexão de rede à base não é muito rápida, toda vez que você deseja fazer uma diferença ou fazer check-in ou check-out de código, pode se conectar e desconectar a VPN.

Eu posso falar por experiência pessoal aqui, pois sou desenvolvedor e foi uma verdadeira dor de cabeça fazer isso !!! Idealmente, as duas opções são preferidas.

Então, se você estiver navegando na Web, etc, isso pode tornar a leitura das notícias etc. muito lenta. Mas pelo menos você tem acesso seguro ao email. Então, considere como você o usará primeiro ... Se eu fosse você, consideraria implementar os dois.

Na verdade, eu gosto da sua sugestão. Se você tornar seu repositório de código-fonte acessível SOMENTE via SSL / TLS e garantir que seus desenvolvedores não usem senhas fáceis de usar (ou, melhor ainda, use certificados), isso deve ser o mais seguro possível. .

Em vez disso, você pode ocultar seu servidor na LAN e forçar os desenvolvedores a usarem uma VPN para obter acesso, mas isso significa que seus desenvolvedores precisam colocar seu nome de usuário / senha (e / ou certificado) em uma caixa de login diferente. Eu recomendaria não criar um ponto de entrada na sua rede cujas implicações de segurança nem sempre sejam óbvias, apenas para permitir o acesso a um único serviço. Se você já possui uma VPN configurada e protegida para outros usos, com certeza, é um acéfalo, vá em frente e use-o. Caso contrário, pode ser mais simples e, portanto, mais seguro, disponibilizar o serviço diretamente diretamente via SSL / TLS.

O padrão da indústria provavelmente depende de qual é a sua indústria (ou dos seus clientes) :-)

Praticamente você precisa considerar a quem você deseja acessar e com o que eles podem lidar. Algumas pessoas que você deseja / precisa acessar não poderão lidar com muito mais do que um nome de usuário / senha. Outros podem ser capazes de entender o ssh e uma chave privada, desde que você possa obtê-la com segurança, não é ruim. O cliente TortoiseSVN pode lidar com ssh + svn e suporta chaves privadas com um pouco de torção no braço. Isso tem sido bom o suficiente para os meus propósitos.

Um túnel VPN também é uma sugestão justa, embora em muitos lugares você fique feliz em fornecer às pessoas externas acesso apenas ao seu controle de origem, mas não a toda a sua rede!

Como outros, eu prefiro uma VPN. Uma alternativa seria um túnel SSH, que suponho em termos práticos é uma espécie de VPN de qualquer maneira.

Torne-o somente interno e implemente uma solução VPN de usuário remoto. / Doh - duplicado.

Se você deseja acessar de qualquer lugar, precisa de um servidor público - isso é claro.

Nesse servidor, você deseja expor o mínimo possível , de preferência apenas Mercurial / Subversion e nada mais. Isso evita que uma violação na segurança se espalhe do controle de origem para o restante da sua empresa. Por esse motivo, eu concordo com Matt quando ele diz que uma VPN pode ser perigosa: fornece acesso muito mais amplo do que o necessário.

Para o Mercurial, você pode bloquear as coisas firmemente usando hg-sshpara restringir os comandos disponíveis para clientes que se conectam por SSH. Ao usar o SSH, você pode facilmente exigir que os clientes usem autenticação de chave pública em vez de senhas. Isso protege seu servidor contra ataques de login de força bruta.

Mesmo que uma chave SSH seja comprometida (talvez tenha uma frase secreta fraca e o laptop que a armazena foi roubado), o pior dano que um invasor pode causar é adicionar o histórico de lixo no Mercurial. O protocolo usado é inerentemente apenas anexado, para que nada possa ser excluído hg push.

Para HTTPS, a autenticação é feita pelo servidor web front-end . Isso significa que você pode exigir certificados do site do cliente se desejar e obter segurança como a autenticação de chave pública SSH acima.