Данные требования применяются к поставщикам платежных приложений.
Семейство стандартов и требований PCI (индустрии платежных карт) состоит из трех документов:
1. PCI PIN Transaction Security (PTS) Point of Interaction (POI) v. 4.0
- требования к POI-устройству по безопасности транзакций с использованием PIN-кода (требования к аппаратным терминалам)
2. PA-DSS v. 3.0 - требования к приложениям, обрабатывающим платежную информацию.
3. PCI DSS v. 3.0 - требования к среде, обрабатывающей информацию платежных карт.
Обзор стандарта PCI DSS v. 3.0
Стандарт PA-DSS применяется для платежных приложений, которые распространяются на рынке. То есть в случае, если приложение разрабатывается для использования в личных целях или для использования одним заказчиком, то можно добиваться соответствия сразу PCI DSS.
Сертификат PA-DSS гарантирует то, что приложение, установленное правильным образом в среду, удовлетворяющую требованиям PCI DSS не нарушит безопасность этой среды. Это гарантия того, что среда сохранит соответствие PCI DSS.
Именно поэтому вместе с самим сертифицированным приложением в комплект поставки должен входить документ "Руководство по внедрению стандарта PA-DSS", который говорит о том, как правильным образом устанавливать и эксплуатировать приложение.
Причем не обязательно выполнять все требования стандарта PA-DSS. Если приложение планируется использовать на конкретном POI-устройстве, прошедшем сертификацию по PCI PTS, то требования можно закрыть с использованием функционала POI.
Тогда в перечне приложений, сертифицированных по PA-DSS, наше приложение будет идти с пометкой, что его необходимо использовать только в связке с конкретным POI-устройством.
Аудит приложения производится сертифицированным аудитором платежных приложений (PA-QSA) в лаборатории, требования к которой приведены в приложении В к стандарту.
Причем по возможности PA-QSA должен использовать свою лабораторию.
Если в лаборатории PA-QSA отсутствует необходимое железо, то необходимо запросить железо у разработчика ПО либо, если это сделать невозможно, проводить аудит в лаборатории разработчика.
По результатам аудита оформляется отчет о проверке PA-DSS (называемый ROV) и направляется в PCI SSC.
PA-DSS состоит из 14 требований:
1. Не хранить полные данные магнитной дорожки, код или значение проверки подлинности карты (CAV2, CID, CVC2, CVV2), или данные PIN-блока
2. Обеспечить безопасное хранение данных держателей карт
3. Предоставление функций безопасной аутентификации
4. Следует вести журнал активности платежного приложения
5. Необходимо разработать безопасные платежные приложений
6. Защита беспроводной передачи данных
7. Необходимо тестировать платежные приложения с целью устранения уязвимостей и регулярного обновления приложений
8. Необходимо обеспечить возможность внедрения в безопасные сетевые среды
9. Данные держателей карт ни в коем случае не должны храниться на сервере, подключенном к Интернету
10. Необходимо обеспечить безопасный удаленный доступ к платежному приложению
11. Необходимо шифровать конфиденциальный трафик в общедоступных сетях
12. Необходимо шифровать неконсольный административный доступ
13. Необходимо составить Руководство по внедрению стандарта PA-DSS для клиентов, реселлеров и интеграторов
14. Необходимо назначить сотрудникам обязанности по стандарту PA-DSS и обеспечить программы обучения сотрудников, реселлеров и интеграторов.
Требования стандарта PA-DSS во многом пересекаются с требованиями его большого брата PCI DSS.
Из нового можно отметить требования к управлению версиями (5.4) и требование к разработке сопроводительного документа "Руководство по внедрению стандарта PA-DSS". О необходимости составления такого документа говорится практически в каждом требовании, также ему посвящено требование 13, кроме того существует Приложение А, которое еще раз говорит о том, что должно быть в документе.
Любопытно то, что согласно PA-DSS ответственность за обучение и предоставление информации реселлерам и интеграторам, которые будут внедрять ПО, ложится на разработчика ПО (требование 14).
Стандарт, безусловно, будет полезен разработчикам платежных приложений, даже если они не собираются сертифицировать свои продукты. Он детален, охватывает все аспекты безопасности приложений и хорошо структурирует подход к разработке и внедрению безопасного ПО.
Комментариев нет:
Отправить комментарий