Какие ограничения, если таковые имеются, существуют в отношении управления хранилищем исходного кода в PCI-DSS?

Question

Какие ограничения, если таковые имеются, существуют в отношении управления хранилищем исходного кода в PCI-DSS?

Компания, в которой я работаю, хочет разработать сервис обработки кредитных карт для клиентов, размещенных в нашей сети.На данный момент мы используем SVN для контроля версий.Он защищен таким образом, что его имеют только разработчики, которым нужен доступ к извлечению / фиксации.Тем временем я планировал перейти из SVN в HG.Однако команда безопасности высказала оговорки по поводу использования распределенного инструмента SCM из-за отсутствия контроля доступа на удаленных клонах.В частности, они утверждают, что это нарушит соответствие PCI-DSS.Есть ли это?

Answer 1

Во-первых, я просто скажу, что я основываю свой ответ на кратком прочтении PCI-DSS 2.0 , в частности, Требования 6.

Я не понимаю, почему использование Mercurial было бы проблемой, если вы используете его способом, сравнимым с тем, как вы использовали Subversion. Вот несколько причин, почему я так думаю:

• Предположительно, вы не храните данные клиентов в своем хранилище (только код, который работает с этими данными).
• PCI-DSS часто использует такие слова, как «стандартные отраслевые практики» или тому подобное. Mercurial - довольно распространенный VCS, который полезен.
• Кажется, это способность выдвигать наборы изменений, которые необходимо заблокировать. И, в частности, возможность подтолкнуть к «каноническому» клону ваших репозиториев. То, что у Mercurial есть эти «удаленные клоны» и разработчики могут вносить случайные (даже злонамеренные) изменения в эти клоны, не означает, что эти изменения окажутся (или должны) быть в вашей производственной системе.
• При работе с Subversion кажется, что у вас есть права на ограничение проверок для подмножества ваших разработчиков (или, может быть, даже одного «привратника»?).
• С Mercurial вы можете настроить его на использование SSH в центральном (каноническом, «производственном» хранилище). Предоставьте каждому разработчику свои собственные SSH-учетные данные для этого (это требуется для PCI-DSS - пароли для обмена не используются!). В в этом случае вы можете установить разрешения для файловой системы, в которой размещено центральное хранилище, и предоставлять доступ на запись в каталоги Mercurial только определенным пользователям.
• С Mercurial вы можете вместо этого (или также) публиковать свое центральное репо по HTTP. В этом случае вы можете использовать Apache (или другой веб-сервер) для аутентификации и авторизации.
• Вы также можете полностью запретить записи в центральный репозиторий и постановить, что все исходные изменения должны отправляться через одного или двух конкретных людей, которые будут проверять изменения, прежде чем извлекать (или применять) их.

Так что я думаю, что есть много возможностей для PCI-DSS-совместимости при использовании DVCS, как Mercurial. Все вышеперечисленное в равной степени относится и к Git.

Answer 2

Как уже говорили другие, это тот вопрос, который нужно поднять с вашим QSA, если вам нужен дополнительный совет. Тем не менее, PCI - это правильное управление, а не навязывание одной технологии другой.

При разработке нужно думать о:

• Распределение обязанностей между системами тестирования / разработки и производственными системами
• Возможность обнаружить изменения, где они произошли, когда и кем
• Смена процедур контроля при нажатии, чтобы жить

Ничто в этом не должно помешать вам использовать менеджер хранилища по вашему выбору

Answer 3

Если команда безопасности права насчет части контроля доступа, зависит от того, какой контроль они хотят.

Ограниченное чтение

Наличие какого-либо контроля над тем, что может прочитать один разработчик, ограничено как для SVN, так и для любой DVCS. Даже если у вас есть центральный сервер SVN, обычно нет ограничений на чтение старых версий путей, для которых у вас есть разрешение. Таким образом, вы можете сбросить старую историю пересмотра за ревизией в локальное хранилище (hg subversion, git svn и многие другие инструменты работают именно так). В SVN нет ничего волшебного, что мешало бы кому-либо загружать каждую ревизию и распространять эти копии.

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

Запрещено писать

Это другая игра, поскольку Mercurial позволяет вам устанавливать любое имя в качестве коммиттера, как вы хотите¹. Таким образом, вам нужно добавить некоторые механизмы на сервер, чтобы ни один разработчик не мог представить ревизии False-Flag, зафиксировав имя одного из разработчиков, и отправить эти ревизии на сервер. В то время как AFAIK Subversion сам устанавливает имя пользователя на сервере, сервер hg должен каким-то образом быть снабжен ловушкой для проверки имен пользователей для всех входящих наборов изменений.

¹ В Subversion также есть способ изменить имя коммитера, но вы должны включить ловушку pre-revprop на сервере, чтобы разрешить это.