Programowanie par i ISO 27001

16

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?

Martin Hughes
źródło
11
Sądzę, że większość ludzi, którzy stosują praktyki programowania w parach, sądzi, że ISO robi jedynie format daty i kodowanie znaków.
Lars Viklund,
6
Dlaczego potrzebujesz kont do parowania? Czy nie działałoby utrzymywanie indywidualnych kont, na które można się zalogować na dowolnym komputerze?
Garrett Hall
Nie możesz korzystać z indywidualnych kont, ponieważ co się stanie, jeśli ktoś przyjdzie wcześniej do pracy / pójdzie do toalety itp., A urządzenie zaloguje się jako inny użytkownik?
John Sably
@JohnSiable Czy masz na myśli, że chcesz kontynuować prace nad tym kontem? W przeciwnym razie powinieneś być w stanie otworzyć inną sesję na komputerze jako własny użytkownik.
Sinjo
2
@JohnSiable, a następnie sterownik wylogowuje się i umożliwia zalogowanie się użytkownika. Jeśli pójdą do toalety, zamknij maszynę, jeśli nie ufasz rówieśnikom. Jednak brak zaufania jest większym problemem, który należy naprawić.
CaffGeek

Odpowiedzi:

13

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.

Matthew Flynn
źródło
+1, tak się dzieje w mojej firmie. Mamy do wyboru przegląd kodu równorzędnego lub programowanie parami. Przypadek programowania w parach jest tylko szczególnym przypadkiem recenzowania, w którym peer ciągle recenzuje podczas pisania kodu.
Daniel Pryden
@Daniel dziękuję za podzielenie się swoimi doświadczeniami. Kiedy zaczęliśmy parować, logował się kierowca. Jednak nasze sesje parowania są teraz bardziej rozwiązłe i dość często para zamienia się, zanim zadanie zostanie w pełni ukończone. Chociaż nie jest to idealne, czasami konieczne jest zorganizowanie naszych zamian, ponieważ każdy musi sparować kod produkcyjny. Oznacza to, że oryginalny „kierowca” musi odejść i wylogować się. Możemy pobrać ten kod bez nich, ale zakłócenia w parze, które potencjalnie są w trakcie debugowania aplikacji, nie są zbyt lekceważone.
Martin Hughes
7

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ą.

CaffGeek
źródło
Czy masz na myśli utrzymanie par kont („zachowaj konta takimi, jakie są”), czy korzystaj z indywidualnych kont („osoba zalogowana”)?
Caleb
@Caleb, osoba zalogowana jako kierowca
CaffGeek
6

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.

Kevin Cline
źródło
5

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.).

Caleb
źródło
2

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”.

Tulains Córdova
źródło