TLS в безопасности? Нужны каллинг-хэш в платежном заявлении PA-DSS?

Question

Я инженер-программист и в настоящее время работаю над другим платежным приложением (моим третьим), которое должно соответствовать соответствию PCI PA-DSS. Я пересматриваю документацию PA-DSS, и мне интересно, не был ли в прошлом перегружена работой при безопасности приложения, когда я мог бы пойти с TLS и пользователем/Pass. Итак, мои вопросы: при внедрении защищенного приложения PA-DSS:

1. Для аутентификации и безопасности общения достаточно, чтобы иметь TLS + пользователь/Pass?

2. Какая часть (ы) стандарта PA-DSS оправдывает необходимость реализации хэш-хэша сообщений и проката между вызовами веб-методов? TLS реализует надежные сообщения, но не катаясь хэши и постоянные вызывающие абоненты между сообщениями. Сделает ли внедрение каллинг-хэша?

3. Если приложение для обработки платежей хранит информацию PII и обслуживает различные компании (что означает, что компания A и компания B может иметь счета в таком приложении), нет особого требования, согласно которому информация PII не может быть сохранена в одном и том же БД, но в прошлом , PA-QSAS настаивали на том, что это проблема. Вопрос в том, действительно ли это действительно необходимо? Я не могу думать, что Authorize.net, компания с тысячами клиентов и процессоров, имеет разные базы данных для хранения кредитных карт, обработанных через каждую из своих клиентских компаний.

Заранее спасибо!

---

Обновление № 1:

• Предположим, что все страницы и веб -сервисы, как в DMZ, так и в Secure Zone будут иметь HTTPS для всех каналов связи, страниц и услуг.

• На #3 вопрос не о местоположении или безопасности хранения конфиденциальной информации. Вопрос больше направлен на вопрос о способности обмена конфиденциальной информацией из разных источников (например, клиентов, таких как AT & T и Verizon) в одной и той же базе данных.

Answer 1

Здесь есть несколько проблем.

1) Использование TLS только для имени пользователя+пароль по -прежнему остается уязвимостью. Это нарушение OWASP A9 И это тривиально угнать любую учетную запись в вашей системе, используя атаку в стиле Firehseep.

Я знаю, что PA-DSS 2.0 не воплощает всю топ 10 OWASP, но следует отметить требование 12.1:

12.1 Поручите клиентам шифровать весь административный доступ не Console с помощью сильной криптографии, используя такие технологии, как SSH, VPN или SSL/TLS для управления веб-сайтом и другого административного доступа, не связанного с Console.

Который будет включать в себя административный интерфейс HTTP.

2) PA-DSS рекомендуется с использованием реальной безопасности транспортного уровня, такой как: VPNS и TLS/SSL. Я не верю, что существует требование для катящихся хэшей, и, честно говоря, это не очень безопасный дизайн. Такое движение нуждается в полной защите транспортных слоев.

3) Не забывайте о требовании 9:

9. Данные держателя карты никогда не должны храниться на сервере, подключенном к Интернету