¿Es seguro almacenar el historial de revisiones en servidores de producción?

Mientras leo este post, estoy temblando. Probablemente porque comí demasiados carbohidratos después de evitarlos por un tiempo, y estoy experimentando un ataque de hipoglucemia ... pero probablemente porque la idea de esto realmente me aterroriza.

Recuerde, este es un sitio de seguridad de la información. A veces, la respuesta que obtienes no es la respuesta que quieres .

1. Usted afirma estar trabajando para el gobierno.
2. Estás usando tu nombre real en este sitio web. Un poco de excavación muestra exactamente quién es su empleador, entre otras cosas. Al continuar investigando, puedo encontrar información adicional sobre otras cosas.
3. Está pensando en una configuración potencialmente insegura, y esto me lleva a preocuparme por el hecho de que pueda tocar los servidores de producción de esa manera, y la verificación / importación desde los servidores de PRODUCCIÓN que pueden haber sido afectados por malware previamente.

Puede estar bien informado visitando un artículo de wikipedia sobre Seguridad operacional.

¿Por qué esto puede ser un problema?

Un entorno de producción suele ser frontal, lo que significa que es lo que verán sus clientes / clientes / usuarios. Supongamos que tiene los siguientes entornos:

1. Desarrollo
2. Pruebas
3. Producción

Verificando el código de producción, que podría haber sido modificado en caso de una vulnerabilidad explotada exitosamente, ya sea en su (s) aplicación (s) web o en su propio servidor web, y luego depurarlo localmente, significa que puede Terminar infectando a toda tu empresa.

Su equipo de desarrollo generalmente tiene acceso a muchas cosas críticas. ¡Ahora que lo está depurando localmente, es posible que pueda propagar malware oculto en toda su infraestructura completa ! Desarrollo, prueba, producción, etc. A partir de ahí, su atacante puede hacer casi todo lo que quiera.

Usted necesita una clara separación de preocupaciones. Poner su repositorio en su servidor de producción es solo pedir problemas. Si su servidor de producción es hackeado, usted puede ser capaz de mitigar el daño si está limitado solo a sí mismo.

Sin embargo, tan pronto como lo dejas escapar de su pequeño entorno cerrado, podrías tener un mundo de problemas. Tenga en cuenta que los atacantes están buscando cualquier cosa pequeña que puedan explotar. Es por eso que realmente creo que no debe poner su SVN en su servidor de producción.

Ejemplo de diagrama de pwnage

Hice un diagrama de mierda en MS Paint para explicar esto mejor. Supongamos que una vez que se depura, se produce una infección y comienza a propagarse.

Esto depende de lo que guardes en el repositorio. Si este repositorio solo contiene la misma información que ya se encuentra en el servidor, un atacante que comprometa al servidor no obtendrá información nueva al mirar el repositorio.

Pero imagínese que alguien ingresó algunas credenciales de autorización (es decir, contraseña, clave privada ...) u otra información confidencial no pública. Incluso si esto se detectó y el cambio se revirtió y nunca se publicó en el sitio público del servidor, todavía está dentro del repositorio. Y en este caso, el atacante podría obtener información valiosa que, de lo contrario, no estaría disponible en el servidor.

En resumen, recomendaría almacenar solo la información en un servidor que realmente necesita estar allí. Esto significa que no hay repositorios de código y tampoco herramientas como compiladores o similares. Todo esto podría ayudar a un atacante a comprometer el servidor u obtener información adicional.

  

Una vez que quiera desplegar, simplemente levanto y luego copio el contenido (sin .svn) a una carpeta de lanzamiento en el mismo servidor.

¿Por qué no simplemente sincronizar los datos de un checkout local del repositorio al servidor público? rsync es tu amigo.

Capistrano está usando una configuración como la que describe. Pero todo se reduce a "su seguridad es tan fuerte como su enlace más débil".

Entonces, si protege correctamente su servidor web y svn, por ejemplo. utilizando la autenticación con clave ssh, dicha configuración debería ser sólida.

Y debido a que Capistrano utiliza el reenvío de agentes, no hay información de autenticación al servidor SCM en el servidor web.