Что нужно для написания PCI-совместимой сборки?

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

Я в значительной степени ненавижу этот дизайн и хотел бы написать автономный, PCI-совместимый элемент управления/сборку WPF, который мы можем подключить вместо компонента веб-браузера. Если код нашего приложения может использовать браузер без сертификата PCI, то он может использовать нашу собственную сертифицированную сборку PCI без сертификата PCI, верно? Все новое управление/сборка, которое он будет делать, — это собирать информацию о карте и безопасно отправлять ее на удаленный защищенный сервер через службу WCF. Это не будет хранить кредитную карту или выполнять какую-либо обработку с ней локально. Мне сказали, что для этого требуется 9-месячный процесс проверки, поэтому мы выбрали браузерный подход.

Может ли кто-нибудь дать мне общее представление о том, что для этого потребуется?

  • Можно ли это написать на C#/WPF?
  • Должны ли в коде быть реализованы специальные меры безопасности (например, CAS)?
  • Должна ли сборка быть запутанной?
  • А раз написано, то что делать?

c# security wpf credit-card pci-compliance
person xr280xr    schedule 06.02.2012    source источник
comment
Существует несколько уровней соответствия PCI, как только вы прикасаетесь к данным CC, уровень повышается. Нет никакого реального способа обойти это, если вы встроите захват информации CC в свое приложение. Причина, по которой элемент управления веб-браузера будет работать, заключается в том, что информация CC никогда не хранится в памяти вашего приложения, а отправляется напрямую третьей стороне. Все это соответствие стандарту PCI — это головная боль, но в целом я рад, что мои данные хотя бы выглядят безопасными.   -  person Travis    schedule 07.02.2012

Ответы (1)


arrow_upward
3
arrow_downward

Хотя PCI-DSS во многом пересекается, формальное название, которое вы ищете, — PA-DSS (стандарты безопасности данных платежных приложений).

Одна из стратегий, позволяющая решить вашу проблему, состоит в том, чтобы выделить части ввода/обработки карт в совершенно отдельное решение. Это отдельное решение в конечном итоге станет «приложением», прошедшим сертификацию PA-DSS. После сертификации вы сможете встроить его в свой более крупный проект (что не изменит соответствие PCI более крупного проекта).

Преимущество его выделения станет очевидным, когда вы изучите стандарт PA-DSS. Одним из критериев является то, что любое изменение, требующее повторной компиляции приложения, потребует повторной сертификации приложения. Это не то, что вы хотите делать на регулярной основе!

Еще одна стратегия, помогающая упростить процесс, заключается в том, чтобы учитывать, что «внутренние» приложения (которые не распространяются среди клиентов) не нуждаются в сертификации PA-DSS (хотя они по-прежнему подпадают под действие PCI-DSS, если они явно обрабатывают данные карты). . Поэтому использование веб-сервиса в вашем домене может упростить задачу. Например, вы можете разместить веб-страницу с информацией о вводе платежа, а затем использовать стандартный веб-браузер в своем основном приложении, указывающий на страницу ввода платежа. Это потенциально позволит вам обойти сертификацию PA-DSS (хотя по-прежнему потребуется сертификация PCI для веб-страницы, которую вы сейчас размещаете).

Что бы вы ни решили, лучшим советом будет привлечь QSA, как только у вас появится разумное представление о предполагаемом дизайне. QSA даст совет о том, какие области могут вызвать проблемы с соблюдением требований, и, в конечном итоге, QSA подпишет ваше соответствие.

person PaulG    schedule 07.02.2012
comment
Спасибо! Трудной частью было выяснить, где искать. - person xr280xr; 07.02.2012