Programowanie par i ISO 27001

Od ponad 7 lat pracuję w zespole programistycznym eXtreme i programuję w parach w środowisku Windows. Gdy zaczęliśmy to robić, ktoś logowałby się przy użyciu poświadczeń systemu Windows, a zatem cały dostęp do zasobów domeny, a dokładniej kontrola wersji, byłby odpowiedzialny przed tym użytkownikiem systemu Windows. W końcu ewoluowaliśmy, aby mieć konta parowania systemu Windows dla określonych stacji parowania (np. PairA, pairB, PairC itp.). Wszyscy deweloperzy znają hasła do tych kont. Odpowiedzialność za zatwierdzenia (zameldowania) osiąga się poprzez umieszczenie inicjałów programistów w komentarzu podczas zatwierdzania.

Do tej pory działało to dla nas dobrze, ale moja firma przechodzi obecnie audyt ISO 27001, który został oznaczony przez audytora jako ryzyko. Mam wiele możliwych rozwiązań, takich jak utworzenie konta parowania dla każdej kombinacji par, ale naprawdę chciałbym wiedzieć, czy ktoś inny napotkał ten problem i jak go rozwiązał?

Jakie rozwiązanie było możliwe do zaakceptowania przez audytorów?

Zakładam, że audytorzy woleliby, aby programiści logowali się jako sami, a nie jako „para” z wspólnym hasłem. Ryzyko powinno być oczywiste - programista dodaje złośliwy kod jako „PairA” i umieszcza w komentarzu inicjały innej osoby (lub wcale tego nie komentuje). Jak prześledzić drogę do złośliwego programisty?

Polecam, aby ten, kto jedzie pierwszy (w sesji), zalogował się przy użyciu własnego identyfikatora, a para nadal umieszczała oba swoje inicjały w komentarzach - w ten sposób kod pozostaje identyfikowalny z powrotem do rzeczywistego programisty.

Chciałbym zachować rachunki takimi, jakie są, zwykle tylko jedna osoba prowadzi, a nawet jeśli druga osoba korzysta z maszyny (nieoficjalnie), osoba zalogowana powinna być nadal świadoma tego, co dzieje się na jej maszynie.

Meldunki nadal będą wymagały komentarzy, aby pokazać, kto był tą parą.

Zamiast tworzyć osobne konta, aby praca nie była zablokowana dla potencjalnie nieobecnego użytkownika, użyj systemu kontroli wersji. Kiedy para zacznie działać, utwórz gałąź zadań. Przypisuj kod do gałęzi zadań za każdym razem, gdy testy zakończą się pomyślnie. Po zakończeniu zadania połącz ponownie i zamknij gałąź zadania.

Do tej pory działało to dla nas dobrze, ale moja firma przechodzi obecnie audyt ISO 27001

ISO 27001 lub nie, twój obecny system działa tylko dlatego, że jesteś małą firmą, w której istnieje wysoki stopień komunikacji i wzajemnego zaufania. Tego rodzaju rzeczy nie skalują się zbyt dobrze, więc prawdopodobnie i tak będziesz musiał rozważyć inne opcje w przyszłości.

Utworzenie osobnego konta dla każdej możliwej pary wydaje się jeszcze mniej praktyczne: potrzebujesz 90 kont dla grupy 10 programistów, a każdy z tych 10 programistów musiałby znać 9 różnych kombinacji login / hasło.

Jedynym praktycznym rozwiązaniem jest korzystanie z indywidualnych kont, jak sugerują inni, i śledzenie tożsamości drugiej osoby w parze w inny sposób (komentarz w zatwierdzeniu kontroli wersji, pole w systemie śledzenia problemów itp.).

Ze względu na Pete'a pozwól, aby kierujący członkiem pary wziął na siebie odpowiedzialność / odpowiedzialność za wypychanie / zatwierdzanie. Następnym razem inny członek będzie prowadził. „Kierowca” nie zrobi niczego, na co nie zgodzi się z drugim pilotem.

Programowanie jest wysiłkiem kolaboracyjnym. Żaden akt programowania nie jest w 100% indywidualny. Nie trzeba być wybrednym, chcąc zastanowić się, czy dane polecenie push / commit zostało wykonane przez Toma i Harry'ego, a nie tylko Toma. Korzyści z programowania par są warte przeoczenia tego niuansu.

Audytor ma rację, należy unikać kont „puli”.