PCI DSS и релиз автоматизации развертывания

Question

Одно из правил PCI DSS является:

«Стандарт PCI DSS распространяется на все компоненты системы включены в систему или подключены к среде данных о держателях карт»

Как бы вы об обработке сервер автоматизации SCM/выпуска? Должен быть порт, открытый с какого-либо сервера в сегменте сети dev, что делает его способом для какого-либо сервера в сетевом сетевом сегменте.

Разработчики производят код, следуя за менеджером сборки, производящим выпуски артефактов. Релиз артефактов должен пробиваться к производству. Как выпускать артефакты от разработчика до производства - как они пробиваются из окна «не в области» dev к коробке «в области»?

Answer 1

Я провел много исследований по этому вопросу, и то, что мы закончили, - это разделение нашего сервера SCM на dvscm и pdscm.

dvscm:

• Все разработчики совершают код на этот сервер
• хранит процесс генерации сборки высвобождать артефакты здесь
• Dev автоматизированного тестирования получает артефакты развертывания здесь

pdscm:

• Этот сервер синхронизирует артефакты развертывания с dvscm. Существующие артефакты развертывания не обновляются, это синхронный тип добавления.
• QA и PROD среды получают артефакты развертывания оттуда, используя ФМн на основе соединения через SSH с пользовательскими ограничительного оболочки

Таким образом, есть уровень разделения между DEV и ОК/PROD. pdscm заблокирован - у разработчиков нет доступа к нему, по умолчанию все правила брандмауэра DENY.

Единственное исходящее соединение от pdscm - это порт 22 для dvscm, для синхронизации. Единственные входящие соединения с pdscm находятся на порту 22, подключенном к пользователю, у которого есть только предпосылки для чтения артефактов развертывания, с использованием настраиваемой ограниченной оболочки.

Answer 2

Вероятно, на самом деле нет хорошего ответа; Насколько я знаю, у вас не может быть по-настоящему автоматизированного решения непрерывного развертывания, которое не приведет к тому, что «в области видимости» вернется к системам разработки. Таким образом, вы должны иметь ручной шаг в развертывании, но вы можете сделать этот шаг как можно меньше.

В розничной системе я недавно работал над (около 100 кассовых аппаратов в ~ 80 местах), мы выбрали один реестр, который имел некоторую избыточную пропускную способность сети и обозначил его как «островную» систему. Мы могли бы сделать обновление в виде одного файла (zip или что-то еще) и отбросить его в этой системе, и он будет установлен там, а затем распространяться на все остальные регистры во всех местах. Таким образом, мы сузили окно ручного усилия к одному файлу в одном регистре.

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