То, как 'обрабатывает данные кредитной карты', определило (PCI)?
Если у меня есть веб-приложение, и я получаю данные кредитной карты, переданные через запрос POST веб-браузером по HTTPS, и немедленно открываю сокет (SSL) для удаленного PCI совместимый процессор карты, чтобы передать данные и ожидать ответа, мне разрешают сделать это? или это получает данные с моим приложением и уже передает ему предмет "обработки данных кредитной карты"?
если я создаю iframe, который отображен в клиентском браузере для ввода cc данных, и этот iframe отправляет данные через HTTPS к удаленному процессору карты (непосредственно!) это уже - случай обработки данных кредитной карты? даже если мой код приложения 'не касается' вводимых данных ни с какими обработчиками событий?
я интересуюсь определением "обработка данных кредитной карты". когда это начинает быть cc приложением обработки данных? кто-то может, возможно, указать на меня на тот раздел в стандарте PCI-DSS, который ясно определяет, когда Вы начинаете 'быть приложением обработки'?
Спасибо,
3 ответа
Это хороший вопрос, и я бы хотел услышать авторитетные ответы - либо от кого-то, непосредственно представляющего PCI-DSS, либо хотя бы от QSA с доступом к членам PCI.
Мой неавторитетный ответ заключается в том, что веб-сервер, на котором размещен iframe, будет находиться в сфере действия PCI, а вы будете классифицироваться как поставщик услуг. Это основано на моей интерпретации стандарта PCI, где в глоссарии говорится:
Поставщик услуг Коммерческая организация, которая не является членом бренда платежной карты или торговцем непосредственно членом или торговцем, непосредственно участвующий в обработке, хранении, передачей и коммутацией данных транзакций и держателей карт или информации о держателях карт, или того и другого (*1). Это также включает компании, которые предоставляют услуги торговцам, поставщикам услуг провайдеров или участников, которые контролируют или могут влиять на безопасность данных держателей карт (*2). Примеры включают поставщики управляемых услуг, которые предоставляют управляемые межсетевые экраны, IDS и другие услуги, а также хостинг провайдеры и другие организации. Такие организации, как телекоммуникационные компании, которые только предоставляют каналы связи без доступа к прикладной уровень исключены (*3)
*1. Вы явно не являетесь брендом платежной карты (например, Visa), равно как и торговцем (которому вы предоставляете эту услугу)
*2. Ваша роль вполне очевидна - вы предоставляете услугу
*3. К сожалению, я не думаю, что вы соответствуете этому исключению, поскольку у вас есть доступ к данным прикладного уровня.
Хорошая новость заключается в том, что подход, который вы выбрали, вероятно, лучшее, что вы можете сделать, чтобы минимизировать головную боль.
В идеале вы должны сегментировать этот сервер так, чтобы доступ к более широкой (внутренней) сети был очень ограничен. Убедитесь, что единственным "приложением", которое предоставляет веб-сервер, является этот iframe (т.е. не запускайте другие веб-страницы с сервера). Убедитесь, что журнал, который генерирует сервер/iframe/etc, не содержит никаких данных, связанных с картой
К сожалению, я считаю, что это означает необходимость участия QSA, поскольку вы обрабатываете транзакции через Интернет.
Вы передаете данные, даже если сами ничего с ними не делаете. Следовательно, вы подпадаете под правила соответствия PCI.
PCI DSS v .2.1, стр. 5, в разделе «Информация о применимости PCI DSS»:
Требования PCI DSS применимы, если основной номер учетной записи (PAN) сохраняется, обрабатывается или передается. Если PAN не сохраняется, не обрабатывается, или не передается, требования PCI DSS не применяются.
Раздел 4.1 PCI DSS, например, требует шифрования при передаче по общедоступным / открытым сетям, которые вы покрыли с помощью SSL и HTTPS на обоих концах.
Но это не только требования, касающиеся прямого обращения с карточными данными. Также есть элементы управления аутентификацией пользователей, например, в разделе 8.x PCI DSS, особенно для пользователей с доступом к данным о держателях карт или административными возможностями.
Хотя есть разделы, которые вы можете игнорировать, поскольку вы не храните данные карты, есть другие разделы, которые касаются таких вещей, как сетевая безопасность, брандмауэры, антивирус, контроль доступа, мониторинг и отслеживание, тестирование и т. Д.
Думайте, как хакер: если хакер получил доступ к вашему сайту / серверу, может ли он подделать его таким образом, чтобы iframe перешел на злонамеренный платеж шлюз. Есть QSA (аудиторы PCI), которые будут настаивать на том, что это входит в рамки, и все, что связано с веб-сайтом (разработка, поддержка, тестирование, операции), должно проводиться в соответствии с требованиями PCI.