Programación de pares e ISO 27001

16

He estado trabajando en un equipo de programación de eXtreme y haciendo programación en pares durante más de 7 años en un entorno Windows. Cuando comenzamos a hacerlo, alguien iniciaría sesión con sus credenciales de Windows y, por lo tanto, todo el acceso a los recursos del dominio, y más específicamente el control de versiones, sería responsable ante ese usuario de Windows. Finalmente, hemos evolucionado para tener cuentas de emparejamiento de Windows para estaciones de emparejamiento específicas (por ejemplo, par A, par B, parC, etc.). Todos los desarrolladores conocen las contraseñas de estas cuentas. La responsabilidad de las confirmaciones (check-ins) se logra al poner las iniciales de los programadores en el comentario durante la confirmación.

Hasta ahora, esto ha funcionado bien para nosotros, pero mi compañía actualmente está pasando por una auditoría ISO 27001 y esto fue señalado por el auditor como un riesgo. Tengo varias soluciones posibles, como crear una cuenta de emparejamiento para cada combinación de pares, pero ¿realmente me gustaría saber si alguien más se ha encontrado con este problema y cómo lo resolvieron?

¿Qué solución fue aceptable para los auditores?

    
pregunta Martin Hughes 24.07.2012 - 14:36

5 respuestas

13

Supongo que los auditores preferirían que los desarrolladores inicien sesión como ellos mismos y no como un "par" que tenga una contraseña compartida. El riesgo debería ser obvio: un desarrollador agrega un código malicioso como "PairA" y coloca las iniciales de otra persona en el comentario (o no lo comenta en absoluto). ¿Cómo se remonta al desarrollador malicioso?

Recomiendo que quien esté manejando primero (en una sesión) inicie sesión con su propia identificación, y el par continúe poniendo sus iniciales en los comentarios; de esa manera, el código sigue siendo rastreable hasta un verdadero desarrollador.

    
respondido por el Matthew Flynn 24.07.2012 - 18:04
7

Mantendría las cuentas como están, normalmente solo una persona está conduciendo, e incluso si la otra persona usa la máquina (extraoficialmente), la persona que inició sesión debería estar al tanto de lo que ocurre en su máquina.

Sin embargo, los registros aún necesitarían comentarios para mostrar quién era el par.

    
respondido por el CaffGeek 24.07.2012 - 16:30
6

En lugar de crear cuentas separadas para que el trabajo no esté bloqueado para un usuario posiblemente ausente, use su sistema de control de versiones. Cuando un par comienza a funcionar, crea una rama de tarea. Confirme el código en la rama de tareas cada vez que pasen las pruebas. Cuando se complete la tarea, vuelva a fusionar y cierre la rama de tareas.

    
respondido por el kevin cline 24.07.2012 - 18:05
5
  

Hasta ahora esto ha funcionado bien para nosotros, pero mi compañía está actualmente   Pasando por una auditoría ISO 27001

ISO 27001 o no, su sistema actual solo funciona porque usted es una pequeña empresa donde existe un alto grado de comunicación y confianza mutua. Ese tipo de cosas no se escalan muy bien, por lo que probablemente tendrías que considerar otras opciones en algún momento en el futuro de todos modos.

Crear una cuenta separada para cada par posible parece incluso menos práctico: necesitaría 90 cuentas para un grupo de 10 desarrolladores, y cada uno de esos 10 desarrolladores tendría que conocer 9 combinaciones diferentes de inicio de sesión / contraseña.

La única solución práctica es usar cuentas individuales, como han sugerido otros, y rastrear la identidad de la segunda persona en el par de otra manera (comente en su confirmación de control de versión, campo en el sistema de seguimiento de problemas, etc.) .

    
respondido por el Caleb 24.07.2012 - 18:51
2

Por el bien de Pete, deje que el miembro conductor de la pareja se responsabilice por el empuje / compromiso. La próxima vez el otro miembro conducirá. El "conductor" no hará nada con lo que no esté de acuerdo con el copiloto.

La programación es un esfuerzo colaborativo. Ninguna escritura de programación es 100% individual. No hay necesidad de ser fastidioso al querer reflejar que Tom y Harry hicieron un empuje / cometer dado y no solo Tom. Los beneficios de la programación en pares merecen pasar por alto ese matiz.

El auditor tiene razón, se deben evitar las cuentas de "grupo".

    
respondido por el Tulains Córdova 25.07.2014 - 15:52

Lea otras preguntas en las etiquetas