Парное программирование и ISO 27001

16

Я работаю в команде программистов eXtreme и более 7 лет занимаюсь парным программированием в среде Windows. Когда мы впервые начали это делать, кто-то входил в систему со своими учетными данными Windows, и, следовательно, весь доступ к ресурсам домена и, в частности, контроль версий, был бы подотчетен этому пользователю Windows. В конечном итоге мы получили учетные записи для оконных пар для определенных станций (например, pairA, pairB, PairC и т. Д.). Все разработчики знают пароли к этим учетным записям. Ответственность за коммиты (регистрации) достигается путем помещения инициалов программистов в комментарии во время фиксации.

До сих пор это работало нормально для нас, но моя компания в настоящее время проходит аудит ISO 27001, и аудитор отметил это как риск. У меня есть несколько возможных решений, таких как создание парного аккаунта для каждой комбинации пар, но я действительно хотел бы знать, сталкивался ли кто-нибудь еще с этой проблемой и как они ее решили?

Какое решение было приемлемо для аудиторов?

Мартин Хьюз
источник
11
Я бы сказал, что большинство людей, которые используют методы парного программирования, считают, что все, что делает ISO, это формат даты и кодировки символов.
Ларс Виклунд
6
Зачем вам нужны парные аккаунты? Не сработает ли сохранение отдельных учетных записей, в которые вы можете войти на любой машине?
Гаррет Холл
Вы не можете использовать отдельные учетные записи, потому что, что произойдет, если кто-то рано придет на работу / пойдет в туалет и т. Д., А машина войдет в систему как другой пользователь?
Джон Симбл
@JohnSbly Вы подразумеваете, что хотите продолжить работу над этим аккаунтом? В противном случае вы сможете открыть другой сеанс на компьютере под своим собственным пользователем.
Синдзё
2
@JohnSbly, тогда драйвер выходит из системы, и позволяет пиру войти в систему. Если они идут в туалет, заблокируйте машину, если не доверяете своим сверстникам. Тем не менее, отсутствие доверия является более серьезной проблемой, которая должна быть исправлена.
CaffGeek

Ответы:

13

Я бы предположил, что аудиторы предпочли бы, чтобы разработчики входили в систему как сами, а не как «пара», которая имеет общий пароль. Риск должен быть очевидным - разработчик добавляет некоторый вредоносный код как «PairA» и помещает чужие инициалы в комментарии (или вообще не комментирует его). Как вы проследили до злонамеренного разработчика?

Я бы порекомендовал, чтобы тот, кто ведет первым (в сеансе), вошел в систему со своим собственным идентификатором, и пара продолжила помещать оба своих инициала в комментарии - таким образом, код остается прослеживаемым до реального разработчика.

Мэтью Флинн
источник
+1, это то, что делается в моей компании. У нас есть выбор рецензирования кода или парного программирования. Случай парного программирования - это всего лишь частный случай рецензирования, когда рецензент постоянно проверял, пока код был написан.
Даниэль Приден
@Daniel спасибо, что поделились своим опытом. Когда мы впервые начали сопряжение, это был драйвер, который будет входить в систему. Однако наши сеансы сопряжения теперь более беспорядочные, и довольно часто пара обменивается, прежде чем задача будет полностью завершена. Хотя это не идеально, иногда необходимо организовать наши перестановки, так как каждый должен создать пару для производственного кода. Это означает, что оригинальный «драйвер» должен уйти и, таким образом, выйти из системы. Мы можем проверить этот код без них, но сбои в работе пары, которая потенциально находится в процессе отладки приложения, не слишком легки.
Мартин Хьюз
7

Я бы вел учетные записи такими, какие они есть, обычно за рулем работает только один человек, и даже если другой человек (неофициально) пользуется машиной, вошедший в нее человек все равно должен знать о том, что происходит на его машине.

Checkins все еще будут нуждаться в комментариях, чтобы показать, кем была пара однако.

CaffGeek
источник
Вы имеете в виду сохранить парные учетные записи («сохранить учетные записи такими, какие они есть») или использовать отдельные учетные записи («лицо, вошедшее в систему»)?
Калеб
@Caleb, человек как человек, который вошел в систему, кто делает вождение
CaffGeek
6

Вместо создания отдельных учетных записей, чтобы работа не была заблокирована для потенциально отсутствующего пользователя, используйте систему контроля версий. Когда пара начнет работать, создайте ветку задач. Передайте код в ветку задачи при каждом прохождении тестов. Когда задача будет завершена, выполните объединение и закройте ветку задачи.

Кевин Клайн
источник
5

До сих пор это работало хорошо для нас, но моя компания в настоящее время проходит аудит ISO 27001

ISO 27001 или нет, ваша текущая система работает только потому, что вы небольшая компания, в которой существует высокая степень общения и взаимного доверия. Подобные вещи не очень хорошо масштабируются, поэтому вам, вероятно, придется рассмотреть другие варианты в будущем.

Создание отдельной учетной записи для каждой возможной пары кажется еще менее практичным: вам потребуется 90 учетных записей для группы из 10 разработчиков, и каждый из этих 10 разработчиков должен будет знать 9 различных комбинаций логин / пароль.

Единственное практическое решение состоит в том, чтобы использовать отдельные учетные записи, как предлагали другие, и отслеживать личность второго человека в паре каким-либо другим способом (комментарий в коммите контроля версий, поле в системе отслеживания ошибок и т. Д.).

Калеб
источник
2

Ради Пита, пусть ведущий член пары берет кредит / ответственность за толчок / фиксацию. В следующий раз другой участник поедет. «Водитель» не будет делать ничего, с чем он не согласен с вторым пилотом.

Программирование - это совместное усилие. Нет программирования на 100% индивидуально. Не нужно быть привередливым, желая отразить, что данный пуш / коммит был сделан Томом и Гарри, а не только Томом. Преимущества парного программирования стоит игнорировать этот нюанс.

Аудитор прав, «пул» счетов следует избегать.

Тулаинс Кордова
источник