|
Можно ли говорить о том, что приложения электронной коммерции с открытым исходным кодом, такие как Magento Community, VirtueMart, Ubercart, Zen Cart и другие, еще долго не смогут пройти PA-DSS сертификацию, поскольку, в силу своих особенностей, они свободно модифицируемы и расширяемы плагинами? Означает ли это то, что приложения должны быть защищены от модификации путем шифрования исходного кода для того, чтобы они удовлетворяли требованиям PA-DSS?
14 основных требований, соблюдаемых при PA-DSS Compliance:
• приложение не должно сохранять данные с магнитной полосы карты, значения CAV2, CID, CVC2, CVV2 или PIN-блок;
• должно защищать хранящиеся данные о держателе карты;
• должно обеспечивать безопасную аутентификацию;
• активность платежного приложения должна регистрироваться;
• должна обеспечиваться разработка безопасных платежных приложений;
• должна обеспечиваться защита при беспроводной передаче;
• должно проводиться тестирование платежных приложений на наличие уязвимостей;
• способствовать построению безопасной сети;
• данные о держателях карт никогда не должны храниться на сервере, имеющим прямое соединение с сетью Интернет;
• должно обеспечиваться безопасное удаленное обновление ПО;
• должен обеспечиваться безопасный удаленный доступ к платежным приложениям;
• должно применяться шифрование критичных аутентификационных данных, таких как при их передаче через общедоступные сети;
• должно применяться шифрование при удаленном административном доступе;
• должна обеспечиваться поддержка учебной документации и обучающих программ для клиентов, партнеров и интеграторов;
Эти требования делают почти невозможным прохождение сертификации для «opensource» продуктов. К примеру, требование — разработка безопасных платежных приложений — чаще всего вызывает сложности. Проблема заключается в том, что PA-QSA специалист проверяет всю документацию, общается непосредственно с разработчиками и детально рассматривает (изучает) процесс разработки.
Документация по «opensource» программам, как правило, доступна только в сети Интернет, и может быть, в лучшем случае, неполной. Обычно акцент делается на установке и основных правилах эксплуатации. Согласно требованиям PA-DSS и PCI DSS, необходима документация о правильной инсталляции программы, чтобы убедиться в том, что процесс соответствует PCI DSS. Документация «opensource» решений может и не включать в себя такую информацию.
Одним из самых больших препятствий для открытого ПО будет необходимость документирования цикла разработки данного ПО (SDLC — System Development Life Cycle). Если документация по эксплуатации может быть неполной, то документации по разработке открытого ПО обычно не существует. В результате получается невозможность соответствия требованию SDLC.
Также существует проблема тестирования ПО и подготовки соответствующей документации. Конечно, разработчики свободного ПО проводят тестирование перед его выпуском, но этот процесс еще должен быть документирован в соответствии со стандартом PA-DSS.
А какая организация будет ручаться за приложение? Большинство «opensource» проектов юридически не существуют, в результате, с технической точки зрения, они не могут быть представлены для PA-DSS сертификации. Кому брать на себя ответственность за такой продукт? Кто будет платить за сертификацию? Ведь большинство таких проектов разрабатывается энтузиастами и, понятно, что никто из них не станет платить тысячи долларов для того, чтобы этот продукт был сертифицирован по стандарту PA-DSS.
Наконец, если предположить, что такой открытый продукт получил сертификат PA-DSS, то как узнать, что он будет нетронутым, не модифицированным другими разработчиками? Это значит, что распространять такой продукт надо безопасным образом. То есть организации необходимо иметь свой пункт для безопасного распространения продукта, а значит, такой софт будет доступен не всем. Конечно, возможно использовать алгоритмы хэширования, чтобы подтвердить немодифицируемость версии, однако «opensource» организации придется инвестировать дополнительные средства в безопасность такой системы распространения.
Сообщение в Twitter от ducomputergeek:
«Мы создали новую ветку продукта, потому что нам прямо сказали, что оригинальная версия не может быть сертифицирована по PA-DSS и кажется, посчитали, что стандарт к нему не применим. Сейчас мы проходим сертификационный процесс. Технические изменения в ПО для соответствия требованиям PA-DSS были минимальны и заняли всего пару недель. 5 месяцев написания необходимой документации и мы вскоре будем проходить проверку».
В заключении следует отметить, что стандарт PA-DSS направлен на коммерческое ПО. Возможно, организации начнут выпускать сертифицированные «opensource» приложения, однако такие программы будут доступны только на платной основе. В качестве примера можно привести концепцию Linux версий компаний Red Hat и Novell.
Источники:
http://pa-dss.blogspot.com/2010/04/pa-dss-and-open-source-applications.html
http://slashdot.org/submission/1227990/PA-DSS-and-Opensource-Applications?from=rss&utm_source=twitterfeed&utm_medium=twitter
http://pciguru.wordpress.com/2010/04/10/open-source-pa-dss-certification/ | 
Просто если компания, подпадающая под требования PCI DSS, использует опенсорсный софт, то это будет рассматриваться как in-house разработка или что-то в таком духе при прохождении аудита. Да и ничего не мешает объявить реальный опенсурс (который не GPL) своей разработкой и пройти сертификацию по PA как будто это твой собственно разработанный софт. Ну придется исходники открыть в случае с GPL, но уж документацию своим клиентам уж точно предоставить можно.
Переводчику: английская статья была написана с целью дискредитировать опенсорс, чтобы продавать проприетарный софт, это ж очевидно. Такое впечатление, что про PA вам и сказать то больше нечего.