Programmation par paire et ISO 27001

Je travaille dans une équipe de programmation eXtreme et je fais de la programmation par paires depuis plus de 7 ans dans un environnement Windows. Lorsque nous avons commencé à le faire, quelqu'un se connectait avec ses informations d'identification Windows et, par conséquent, tous les accès aux ressources du domaine, et plus précisément le contrôle de version, seraient responsables devant cet utilisateur Windows. Finalement, nous avons évolué pour avoir des comptes d'appairage Windows pour des stations d'appairage spécifiques (par exemple pairA, pairB, PairC etc…). Tous les développeurs connaissent les mots de passe de ces comptes. La responsabilité des validations (check-ins) est obtenue en plaçant les initiales des programmeurs dans le commentaire pendant la validation.

Jusqu'à présent, cela a bien fonctionné pour nous, mais mon entreprise passe actuellement par un audit ISO 27001 et cela a été signalé par l'auditeur comme un risque. J'ai un certain nombre de solutions possibles telles que la création d'un compte d'appariement pour chaque combinaison de paires, mais je voudrais vraiment savoir si quelqu'un d'autre a rencontré ce problème et comment il l'a résolu.

Quelle solution était acceptable par les auditeurs?

Je suppose que les auditeurs préféreraient que les développeurs se connectent en tant qu'eux-mêmes et non en tant que "paire" qui a un mot de passe partagé. Le risque devrait être évident - un développeur ajoute du code malveillant comme "PairA" et met les initiales de quelqu'un d'autre dans le commentaire (ou ne le commente pas du tout). Comment remontez-vous au développeur malveillant?

Je recommanderais à celui qui conduit en premier (dans une session) de se connecter avec son propre identifiant, et la paire continue de mettre ses deux initiales dans les commentaires - de cette façon, le code reste traçable jusqu'à un développeur réel.

Je garderais les comptes tels qu'ils sont, généralement une seule personne conduit, et même si l'autre personne utilise la machine (officieusement), la personne connectée devrait toujours être au courant de ce qui se passe sur sa machine.

Les enregistrements auraient néanmoins besoin de commentaires pour montrer qui était la paire.

Au lieu de créer des comptes séparés afin que le travail ne soit pas verrouillé sur un utilisateur éventuellement absent, utilisez votre système de contrôle de version. Lorsqu'une paire commence à fonctionner, créez une branche de tâche. Validez le code dans la branche des tâches chaque fois que les tests réussissent. Une fois la tâche terminée, fusionnez à nouveau et fermez la branche de tâche.

Jusqu'à présent, cela a bien fonctionné pour nous, mais mon entreprise passe actuellement par un audit ISO 27001

ISO 27001 ou non, votre système actuel ne fonctionne que parce que vous êtes une petite entreprise où il y a un haut niveau de communication et de confiance mutuelle. Ce genre de chose ne se transforme pas très bien, vous devrez donc probablement envisager d'autres options à un moment donné dans le futur.

La création d'un compte séparé pour chaque paire possible semble encore moins pratique: vous auriez besoin de 90 comptes pour un groupe de 10 développeurs, et chacun de ces 10 développeurs devrait connaître 9 combinaisons de connexion / mot de passe différentes.

La seule solution pratique consiste à utiliser des comptes individuels, comme d'autres l'ont suggéré, et à suivre l'identité de la deuxième personne de la paire d'une autre manière (commentaire dans votre validation de contrôle de version, champ dans le système de suivi des problèmes, etc.).

Dans l'intéret de Pete, laissez le membre le plus motivé de la paire prendre le crédit / la responsabilité du push / commit. La prochaine fois, l'autre membre conduira. Le "pilote" ne fera rien avec lequel il n'est pas d'accord avec le copilote.

La programmation est un effort collaboratif. Aucun acte de programmation n'est 100% individuel. Il n'est pas nécessaire d'être exigeant pour réfléchir à ce qu'un push / commit donné a été fait par Tom et Harry et pas seulement Tom. Les avantages de la programmation par paires méritent d'être ignorés.

L'auditeur a raison, il faut éviter les comptes "pool".