¿Dónde mantener el repositorio de fuente central?

¿Cuál es la mejor práctica de la industria con respecto a asegurar el acceso al código fuente? Estoy pensando que solo se permiten conexiones SSL a través de apache a nuestro servidor en un puerto oscuro que no entre en conflicto con nada más. Lo que me molesta es almacenar el código fuente en un servidor público, es decir, no solo accesible a través de una LAN. Además, este servidor tiene varios usos. Apache ya está ofreciendo algunos otros sitios web internos de la compañía. Me gustaría que todos puedan acceder al código fuente desde cualquier lugar (casas, aeropuerto, lo que sea) siempre que tengan las credenciales correctas. Sugerencias?

Si le preocupa que esté en un servidor público pero desea acceder desde cualquier lugar, debe considerar que sus desarrolladores usen una VPN basada en el cliente para iniciar sesión en su red de forma remota para acceder a un servidor de control de fuente interno.

No estoy muy seguro de por qué la gente piensa que el enfoque de VPN es el mejor. No es necesariamente más seguro y solo ofrece una ventaja que se me ocurre.

Por ejemplo, se sabe que PPTP tiene una seguridad menos que ideal, aunque creo que ha mejorado un poco desde la primera introducción ... así que tenga cuidado con la solución VPN que usa. Yo iría con OpenVPN o IPSEC.

Sin embargo, no puede vencer la conveniencia de SSL / TLS sin la VPN (lea más abajo). Y para hacerlo aún más seguro, solo puede hacerlo certificado.

Sin embargo, si cree que podría ofrecer otros servicios además del control de código fuente, entonces considere una solución VPN porque hará un túnel sobre otros servicios.

La desventaja de usar una VPN es que su PC se convierte efectivamente en parte de la red a la que se está conectando. Eso también puede ser una ventaja. Pero, si está a un millón de millas de distancia de su hogar y la conexión de red a la base de operaciones no es demasiado rápida, cada vez que quiera hacer un diferencial o ingresar o salir del código, puede encontrarse conectando y desconectando la VPN.

¡Puedo hablar por experiencia personal aquí, ya que soy un desarrollador y fue un verdadero fastidio hacer esto! Idealmente, se prefieren ambas opciones.

Entonces, si va a navegar por la web, etc., entonces podría hacer que leer las noticias, etc., sea bastante lento. Pero al menos obtienes acceso seguro al correo electrónico. Así que considere cómo lo usará primero ... Si yo fuera usted, consideraría implementar ambos.

En realidad, me gusta tu sugerencia. Si hace que su repositorio de código fuente sea accesible SOLO a través de SSL / TLS, y se asegura de que sus desarrolladores no usen frases de contraseña fáciles de usar (o mejor aún, usen certificados), entonces eso debería ser tan seguro como cualquier otra cosa. .

En cambio, podría ocultar su servidor dentro de su LAN y obligar a los desarrolladores a usar una VPN para obtener acceso, pero eso solo significa que sus desarrolladores deben poner su nombre de usuario / contraseña (y / o certificado) en un cuadro de inicio de sesión diferente. Recomendaría no crear un punto de entrada en su red cuyas implicaciones de seguridad no siempre sean obvias, solo para permitir el acceso a un solo servicio. Si ya tiene una VPN configurada y asegurada para otros usos, entonces, es obvio, continúe y úsela. De lo contrario, puede ser más simple y, por lo tanto, más seguro, hacer que el servicio esté directamente disponible a través de SSL / TLS.

El estándar de la industria probablemente depende de cuál es su industria (o la de sus clientes) :-)

Prácticamente debe considerar a quién quiere dar acceso y qué pueden manejar. Algunas personas a las que desee / necesite acceder no podrán hacer frente a mucho más que un nombre de usuario / contraseña. Otros pueden entender ssh y una clave privada, que siempre que pueda obtener la clave de forma segura, no está mal. El cliente TortoiseSVN puede manejar ssh + svn y admite claves privadas con un poco de giro del brazo. Eso ha sido lo suficientemente bueno para mis propósitos.

Un túnel VPN también es una sugerencia justa, aunque en muchos lugares estarás encantado de dar acceso a personas externas solo a tu control de fuente, ¡pero no a toda tu red!

Como otros, prefiero una VPN. Una alternativa sería un túnel SSH, que supongo que en términos prácticos es una especie de VPN de todos modos.

Que sea solo interno e implemente una solución VPN de usuario remoto. / Doh- duplicado.

Si desea acceder desde cualquier lugar, necesita un servidor público, eso está claro.

En ese servidor, desea exponer lo menos posible , preferiblemente solo Mercurial / Subversion y nada más. Esto es para evitar que una brecha en la seguridad se propague desde el control de origen al resto de su empresa. Por esa razón, estaré de acuerdo con Matt cuando diga que una VPN puede ser peligrosa: brinda un acceso mucho más amplio de lo necesario.

Para Mercurial, puede bloquear las cosas estrictamente utilizando hg-sshpara restringir los comandos disponibles para los clientes que se conectan a través de SSH. Al usar SSH, puede exigir fácilmente que los clientes usen autenticación de clave pública en lugar de contraseñas. Esto protege su servidor contra ataques de inicio de sesión de fuerza bruta.

Incluso si una clave SSH se ve comprometida (tal vez tenía una frase de contraseña débil y la computadora portátil que la almacenó fue robada), entonces el peor daño que puede hacer un atacante es agregar un historial de basura en Mercurial. El protocolo utilizado es inherentemente solo para agregar, por lo que no se puede eliminar nada hg push.

Para HTTPS, la autenticación la realiza el servidor web front-end . Esto significa que puede solicitar certificados del sitio del cliente si lo desea y, por lo tanto, obtener seguridad como la autenticación de clave pública SSH anterior.