¿Cómo configurar un entorno de múltiples desarrolladores con énfasis en la seguridad del código fuente?

3

Uno de mis clientes ejecuta una pequeña empresa de desarrollo de software (15 empleados) con PHP como su único lenguaje de desarrollo del lado del servidor. Están teniendo un entorno de red con todas las computadoras conectadas a un servidor central a través de LAN. El servidor también ejecuta un servidor FTP.

Su configuración de hardware es la siguiente:

Entorno de desarrollador individual: Windows 7 x64 Professional + XAMPP + Netbeans

Entorno de servidor de desarrollo central: CentOS 7 + Apache + PHP + mySQL

Su flujo de trabajo actual es el siguiente:

  1. Cuando varios desarrolladores participan en un mismo proyecto, crean un nuevo directorio en el servidor central en una carpeta / projects usando un cliente FTP (con una credencial de FTP común que todos conocen).
  2. Luego usan GoodSync ( enlace ) para sincronizar sus archivos desde su máquina local al servidor y viceversa.

También planean instalar y usar Git en el servidor principal.

Todo funciona bien, pero la organización quiere restringir la seguridad del código para no permitir el acceso de todos los códigos de todos los proyectos a todos los desarrolladores.

Entonces, ¿cómo pueden crear un sistema simple y fácil de administrar pero seguro para múltiples desarrolladores?

    
pregunta Mithun John Jacob 18.03.2015 - 07:31
fuente

1 respuesta

2

En primer lugar, debe sopesar el costo / beneficio de lo que está tratando de lograr.

En general, prevenir el robo de código por parte de los desarrolladores es una batalla cuesta arriba, pero afortunadamente no creo que sea un problema muy común. No puedo pensar en muchos ejemplos destacados de robo de código, excepto en algunos casos en los que están involucrados algoritmos patentados muy específicos, o tal vez un empleado que se lanza a un cliente y se lleva su código.

En términos de restringir físicamente el acceso al código, realmente la única forma viable es restringir el acceso a los repositorios. Aun así, eso solo será significativamente efectivo si la arquitectura de su aplicación es tal que los componentes completos pueden operarse como servicios separados y los empleados de alto riesgo pueden trabajar en componentes de bajo riesgo que pueden interactuar con los componentes de alto riesgo como una "caja negra" sin tener para darles acceso al código.

Suena como si un empleado de alto riesgo que se embarca en el proyecto en el que están trabajando es su mayor amenaza y, fundamentalmente, necesiten acceso a ese código para hacer su trabajo, por lo que no hay mucho que pueda hacer al respecto.

La amenaza de una acción legal o daño a su reputación profesional por lo general proporciona un incentivo suficiente para que los desarrolladores hagan lo correcto. Examinar estos controles es probablemente un enfoque más práctico. Intentar contratar empleados de confianza también debería ser obvio.

En relación con su proceso de implementación específicamente, es bastante malo desde el punto de vista de seguridad y operativo. Parece que no tiene ningún tipo de control de versión, y me sorprendería que no estuviera sobrescribiendo los cambios de forma accidental e intentando averiguar quién cambió qué sin saber de qué manera.

Normalmente se considera una buena práctica para:

  • Sus desarrolladores no deben tener acceso directo a sus servidores de producción, excepto a través de un proceso de implementación automatizada que toma el código del control de versiones, donde los cambios se atribuirán a un desarrollador específico
  • Para tener un despliegue discreto (en oposición a cambiar archivos de manera incremental) proveniente de una versión de control de versión explícita
  • Para que los desarrolladores tengan cuentas únicas y, por lo general, su acceso de control de versión dicta el acceso a los servidores de producción a través de su capacidad de confirmar código, que luego se implementará automáticamente.

Hay muchos recursos para implementar el control de versiones y la administración de la implementación, por lo que no voy a profundizar mucho en ello.

    
respondido por el thexacre 18.03.2015 - 13:09
fuente

Lea otras preguntas en las etiquetas