Programação de pares e ISO 27001

Trabalho com uma equipe de programação eXtreme e faço programação em pares há mais de 7 anos em um ambiente Windows. Quando começamos a fazer isso, alguém fazia login com suas credenciais do Windows e, portanto, todo o acesso aos recursos do domínio e, mais especificamente, o controle de versão, seria responsável perante esse usuário do Windows. Eventualmente, evoluímos para ter contas de emparelhamento de janelas para estações de emparelhamento específicas (por exemplo, pairA, pairB, PairC, etc.). Todos os desenvolvedores conhecem as senhas dessas contas. A responsabilidade pelas confirmações (check-ins) é alcançada colocando as iniciais dos programadores no comentário durante a confirmação.

Até agora, isso funcionou bem para nós, mas minha empresa atualmente está passando por uma auditoria da ISO 27001 e isso foi sinalizado pelo auditor como um risco. Eu tenho várias soluções possíveis, como criar uma conta de emparelhamento para cada combinação de pares, mas eu realmente gostaria de saber se mais alguém encontrou esse problema e como o resolveu.

Que solução foi aceitável pelos auditores?

Eu diria que os auditores preferem que os desenvolvedores efetuem login como eles mesmos e não como um "par" com senha compartilhada. O risco deve ser óbvio - um desenvolvedor adiciona um código malicioso como "PairA" e coloca as iniciais de outra pessoa no comentário (ou não o comenta). Como você rastreia o desenvolvedor mal-intencionado?

Eu recomendo que quem estiver dirigindo primeiro (em uma sessão) faça logon com seu próprio ID e o par continue colocando as duas iniciais nos comentários - dessa forma, o código permanecerá rastreável para um desenvolvedor real.

Eu manteria as contas como estão, normalmente apenas uma pessoa está dirigindo e, mesmo que a outra pessoa use a máquina (não oficialmente), a pessoa conectada ainda deve estar ciente do que está acontecendo em sua máquina.

Os check-ins ainda precisariam de comentários para mostrar quem era o par.

Em vez de criar contas separadas para que o trabalho não seja bloqueado para um usuário possivelmente ausente, use seu sistema de controle de versão. Quando um par começar a funcionar, crie uma ramificação de tarefas. Confirme o código na ramificação da tarefa sempre que os testes forem aprovados. Quando a tarefa estiver concluída, volte e feche o ramo da tarefa.

Até agora, isso funcionou bem para nós, mas minha empresa está passando por uma auditoria ISO 27001

ISO 27001 ou não, seu sistema atual funciona apenas porque você é uma pequena empresa onde há um alto grau de comunicação e confiança mútua. Esse tipo de coisa não aumenta muito bem, então você provavelmente teria que considerar outras opções em algum momento no futuro.

Criar uma conta separada para cada par possível parece ainda menos prático: você precisaria de 90 contas para um grupo de 10 desenvolvedores, e cada um desses 10 desenvolvedores precisaria conhecer 9 combinações diferentes de login / senha.

A única solução prática é usar contas individuais, como outras pessoas sugeriram, e rastrear a identidade da segunda pessoa do par de outra maneira (comentar na confirmação do controle de versão, campo no sistema de rastreamento de problemas etc.).

Pelo bem de Pete, deixe que o membro que dirige o par assuma o crédito / responsabilidade pelo envio / confirmação. Da próxima vez que o outro membro irá dirigir. O "motorista" não fará nada que ele não concorde com o co-piloto.

A programação é um esforço colaborativo. Nenhuma escritura de programação é 100% individual. Não há necessidade de ser exigente, querendo refletir que um determinado envio / confirmação foi feito por Tom e Harry, e não apenas por Tom. Os benefícios da programação em pares valem a pena negligenciar essa nuance.

O auditor está certo, as contas de "pool" devem ser evitadas.