NGNIX, SSL-сертификаты и PC-DSSI 3.1

NGNIX, SSL-сертификаты и PC-DSSI 3.1

Нам придется пройти аудит PCI 3.1 для веб-приложения, которое мы сейчас разрабатываем. Оно находится на Amazon EC2, работает на NGINX под Debian.

Мы сотрудничаем с Symantec по поводу сертификатов, и нас особенно интересуют Secure Site Pro с EV и Wildcard (у нас будет один сервер с динамическими именами поддоменов, поэтому мы думаем о Wildcard).

Я просто хотел убедиться, что не потрачу тысячи долларов и не обнаружу, что они не подходят для PCI 3.1 или что для кого-то комбинация NGINX и Debian не будет работать для этих типов сертификатов.

Есть ли у кого-нибудь опыт обеспечения соответствия PCI-DSS 3.1, который мог бы дать совет относительно того, какие SSL-сертификаты нам следует получить?

решение1

Предостережение: Мне никогда не приходилось проходить сертификацию PCI. Это основано на моем исследовании этой темы для вашего вопроса.

Похоже, что основное различие между PCI3.0 и PCI3.1 в том, что для 3.1 требуется TLS1.1или выше. Невозможно использовать SSL3 или TLS1.0. См.http://www.infosecurity-magazine.com/news/pci-dss-31-forces-move-from-ssl-to/Хотя в некоторых местах даже упоминается, что TLS1.1 не допускается. Однако, имея только TLS1.2, вы бы отсекли потенциально очень большое количество ваших посетителей, таких как Android ниже 4.4 и все IE ниже 11. Если это приемлемо для вашего бизнеса, дерзайте.

Более того, похоже, что сертификаты EV явно не требуются. Они полезны для распознавания сайтов, чтобы помочь предотвратить фишинг, но это не строгое требование для PCI.

Я также не вижу ничего, что запрещало бы использование wildcard-сертификатов.

Вы можете получить любой wildcard сертификат, пока его цепочка доверия является частью браузера вашего посетителя. Это не обязательно должен быть сертификат EV и не обязательно от Symantec.

Важной частью вашей настройки является обеспечение того, чтобы ваш Nginx или другое программное/аппаратное обеспечение, завершающее SSL, использовало правильные настройки шифрования. Mozilla создала отличную страницу, которая позволяет вам выбирать компоненты и их версии, и она сгенерирует для вас конфигурацию "лучших практик". Смотритеhttps://mozilla.github.io/server-side-tls/ssl-config-generator/иhttps://wiki.mozilla.org/Security/Server_Side_TLS

решение2

TL;DR:PCI DSS 3.1вступает в силу немедленно, но требование об отключении TLS 1.0 и SSL 3 вступит в силу после 30 июня 2016 года.


В большинстве случаев вы должны были отключить SSL 3 месяца назад или больше для уязвимости POODLE. Так что это не проблема.

Интересной частью этого требования является невозможность использования TLS 1.0.

Официальное заявление:

SSL и ранний TLS не считаются сильной криптографией и не могут использоваться в качестве контроля безопасности после 30 июня 2016 года. До этой даты существующие реализации, использующие SSL и/или ранний TLS, должны иметь формальный план снижения рисков и миграции. Начиная с этого момента, новые реализации не должны использовать SSL или ранний TLS. Терминалы POS POI (и точки завершения SSL/TLS, к которым они подключаются), которые могут быть проверены как не подверженные каким-либо известным эксплойтам для SSL и раннего TLS, могут продолжать использовать их в качестве контроля безопасности после 30 июня 2016 года.

--Переход с SSL и раннего TLS, Информационное приложение PCI-DSS

Где «ранний TLS» определяется как TLS 1.0. Разрешены будут только TLS 1.1 и 1.2, а 1.2 настоятельно рекомендуется.

Хотя вам по-прежнему будет разрешено использовать TLS 1.0 и SSL 3 для POS-устройств и их бэкэндов, при условии, что вы сможете доказать, что устранили все возможные проблемы, вам следует настоятельно рассмотреть возможность их обновления.

Кстати, это еще один гвоздь в гроб Windows XP...

Связанный контент