Рекомендации по минимизации выдержки PCI DSS

Question

Michael Rembetsy от etsy.com offers some insight с точки зрения сегментации программных компонентов в средах PCI и не PCI.

Я пытаюсь определить наиболее оптимальное решение с точки зрения архитектуры программного обеспечения. Рекомендуется ли сегментировать ваше программное обеспечение, связанное с PCI, в отдельные службы или отдельные компоненты программного обеспечения?

Например, если мы рассматриваем обработку платежа; лучше всего инкапсулировать логику в модули исходного кода, содержащиеся в среде PCI, и вытеснять изменения кода в производство параллельно с не-PCI-средой или лучше всего инкапсулировать логику обработки платежей в отдельные сервисы в SOA-модуле?

Другими словами, любая предоставленная функция из базы данных, отличной от PCI, обменивается данными с любой конкретной базой данных вашего PCI-кода (например, с использованием кредитной карты) по протоколу связи, например HTTP, или мне просто нужно предоставлять функции, связанные с PCI, как упакованные dll/jar и т. д., которые ссылаются на не-PCI-функцию?

Мне кажется, что инкапсуляция функций, связанных с PCI, таких как обработка платежей, в отдельные сервисы является более желательной, учитывая, что мы можем контролировать уровень обнаружения сервисов и определять явные границы, тогда как просто предоставление dll/jar потенциально предоставляет безопасный исходный код для декомпиляции разработчиками в среде, отличной от PCI.

Answer 1

Ответ действительно зависит от того, чего вы хотите достичь с помощью сегментации.

Если вы намерены каким-то образом уменьшить/скрыть системы в области видимости для оценки PCI DSS, то, по моему опыту, модульная система не поможет вам. Ваш оценщик, скорее всего, определит в области «системы», будут ли эти системы обрабатывать, передавать или хранить данные держателя карты, как определено PCI DSS. По моему опыту, модуляция исходного кода не поможет вам удалить эту машину/устройство из области оценки.

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

Говоря все это, мой совет будет соответствовать другим плакатам - отрисуйте свои PCI-чувствительные системы за четкими границами обслуживания. Как минимум, это позволит вам управлять жизненным циклом двух систем отдельно. Что еще более важно, это даст вам гибкость для изменения архитектуры развертывания частей PCI без необходимости изменения зависимых систем. PCI DSS - это живой стандарт, поэтому что-то, что соответствует требованиям в этом году, может не появиться в следующем году. По моему опыту, наличие некоторого уровня гибкости благодаря свободному соединению и SOA помогает вам перепроектировать модели развертывания в соответствии с новыми ограничениями.

Надеюсь, это поможет!:)

Answer 2

Вы согласны с тем, что хакеры компрометируют ваш список адресов электронной почты и отправку базы данных и отправили по электронной почте всем вашим клиентам, заявив, что они взломали вас, предоставив точный адрес доставки в качестве доказательства того, что они попал в базу данных? (даже если они действительно не попали на номера кредитных карт с защитой PCI и т. д.). Если нет, подумайте о том, чтобы положить столько, сколько вы можете за PCI, потому что все это требует защиты.

Компетенции по кредитным картам будут считать вас «посткоммунистическим», если это произошло, даже если никакая информация CC не была скомпрометирована. Они ненавидят «внешний вид» успешного взлома, возможно, больше, чем вы ...