PCI DSS для сайта объявлений для взрослых: что на самом деле определяет объем работы по соответствию
Добиться, чтобы платежный провайдер принял сайт объявлений для взрослых, само по себе непростая борьба, и когда она выиграна, почти каждый оператор считает, что самое трудное позади. Это не так. Счет, который наконец открыт, несет с собой постоянное обязательство, никак не связанное с проверкой возраста, модерацией или правилами, которые может установить государство или поисковая система. Это стандарт безопасности, написанный самими платежными системами, и он действует с момента, когда номер карты касается любой части бизнеса, независимо от его размера.
Дальше не юридическая консультация, и любому, кто реально работает с данными карт, стоит показать свою ситуацию Qualified Security Assessor. Это форма решения, которое почти ни один оператор не осознает как решение, потому что принимает его обычно разработчик, желающий сделать страницу оплаты покрасивее, задолго до того, как вопрос доходит до коммерческой стороны компании.
Правило, которое вы подписали не читая
PCI DSS, стандарт безопасности данных индустрии платежных карт, не государственный закон, и ни одно государственное ведомство его не контролирует. Это договорное обязательство, прописанное в соглашении, которое каждый продавец подписывает с банком-эквайером или платежным посредником, и существует оно потому, что Visa, Mastercard и другие системы требуют от своих эквайеров передавать его любому бизнесу, который хранит, обрабатывает или передает номер карты. Сама организация, отвечающая за стандарт, прямо указывает: он применяется к любой стороне, работающей с данными карт, напрямую или через третье лицо, без исключений по размеру или объему транзакций.
Это другой вопрос, чем тот, что задает платежный провайдер перед тем как согласиться открыть счет. Что провайдер хочет узнать, прежде чем согласиться работать с вами, касается самого бизнеса: кому он принадлежит, как проверяются объявления, как верифицируются рекламодатели. PCI DSS начинается после того, как этот счет уже существует, и по сути никогда не заканчивается. Он продлевается каждый год, пока бизнес принимает карты, и меняет форму всякий раз, когда меняется способ приема карт.
Объем транзакций действительно имеет значение, только не так, как обычно думают. Он определяет "уровень" продавца, от одного до четырех, и этот уровень решает, как проверяется соответствие: небольшой оператор заполняет анкету самооценки, а бизнес, обрабатывающий миллионы транзакций в год, нуждается во внешнем аудиторе. Чего объем не делает, так это не освобождает никого. Продавец высокого риска с несколькими сотнями транзакций в месяц подчиняется ровно тому же базовому стандарту, что и крупная сеть, только проверяется по более короткой форме.
Единственное решение, которое определяет нагрузку на годы вперед
Форма, применимая к конкретному бизнесу, выбирается не свободно. Она полностью определяется техническим фактом: проходит ли номер карты в какой-то момент через систему, которую контролирует оператор. Отправить клиента на страницу оплаты, размещенную провайдером, или встроить правильно изолированный платежный iframe, предоставленный этим провайдером, значит, что номер карты никогда не коснется собственного сервера оператора. Построить вместо этого форму оплаты, которая собирает номер карты и отправляет его на собственный бэкенд перед пересылкой дальше, пусть даже на мгновение, значит, что коснется.
Этот единственный факт разделяет самую легкую анкету и самую тяжелую на порядок величины. Полностью аутсорсинговый путь, известный как SAQ A, насчитывает около двадцати требований. Путь, при котором собственная страница оператора предоставляет или влияет на часть процесса оплаты, даже не касаясь номера карты напрямую, например форма, размещенная самим оператором, чьи поля пересылают данные дальше, попадает в SAQ A-EP, около двухсот требований. Реальное хранение, обработка или передача данных карты на собственных системах попадает в SAQ D, который охватывает весь набор контролей стандарта: шифрование, управление ключами, сегментацию сети, журналирование доступа, контроль доступа, все это, несколько сотен пунктов.
Стоит сразу развеять распространенное заблуждение. Использование iframe от соответствующего требованиям провайдера не переводит сайт автоматически в более тяжелый уровень SAQ A-EP: правильно изолированный сторонний iframe, в который собственная страница оператора не добавляет никакого кода, способного видеть или касаться полей оплаты, обычно по-прежнему квалифицируется для легкого пути SAQ A. Что действительно поднимает бизнес на уровень выше, так это собственный код оператора, проникающий на эту страницу, будь то самодельная форма, скрипт, добавленный для "улучшения" оплаты, или интеграция старого образца, где браузер отправляет данные карты через код, написанный оператором, а не провайдером.
Что легкий путь по-прежнему требует, с прошлого года
Стоит исправить убеждение, которое раньше было верным, а теперь нет. Операторы, выбравшие аутсорсинговый путь, справедливо усвоили, что это избавляет их от большей части технической нагрузки стандарта, и некоторые до сих пор считают, что это означает вообще никаких регулярных проверок безопасности. С версии PCI DSS 4.0.1, обязательной с апреля 2025 года, это уже не так. SAQ A теперь включает требование ежеквартального внешнего сканирования уязвимостей силами Approved Scanning Vendor, проводимого против собственного сайта оператора, того самого, что размещает перенаправление или iframe, даже если этот сайт сам никогда не видит номер карты.
Логика изменения проста, стоит только ее озвучить: страница, отправляющая клиента к платежному процессору, все равно остается частью поверхности атаки. Взломанная страница оплаты может перенаправить клиента куда-то помимо настоящего платежного процессора или загрузить вредоносный скрипт, который считывает данные карты прямо из браузера еще до загрузки iframe, паттерн атаки, уже поражавший реальных продавцов. Из той же логики вытекают два связанных требования: оператор обязан вести учет каждого скрипта, работающего на странице оплаты, и обнаруживать несанкционированные изменения содержимого этой страницы, обязательства, действующие в SAQ A именно потому, что страница оплаты принадлежит оператору, даже когда номер карты никогда ему не принадлежал.
Чего легкий путь по-прежнему избегает, и вот этот разрыв действительно важен, так это ежегодного теста на проникновение, требуемого SAQ A-EP и SAQ D, вместе с глубокими внутренними контролями, которые требуют эти уровни: шифрование хранимых данных карты, управление ключами, которые их защищают, сегментация сети вокруг любой системы, которая их касается, и подробное журналирование каждого доступа. Выбор аутсорсингового пути не означает отсутствие работы по безопасности вовсе. Это означает несколько часов сканирования и гигиены скриптов в год вместо постоянной программы безопасности, построенной вокруг данных, которые бизнес иначе хранил бы сам.
Во что обходится ошибка здесь
Ничто из этого не принуждается судом или регулятором, и отчасти поэтому это легко недооценить. Платежные системы штрафуют банк-эквайер, когда продавец из его портфеля не соответствует требованиям, а эквайер перекладывает эту стоимость прямо на продавца через договор, обычно начиная со скромных сумм и увеличивая их по мере того, как несоответствие продолжается. Не существует публичной таблицы, устанавливающей эти суммы для каждого эквайера, потому что договоренность лежит внутри частных контрактов, а не публичных правил, но направление постоянно: штраф растет со временем, а не в зависимости от того, насколько хорошо бизнес объясняет задержку.
Это цена простого несоответствия. Реальный инцидент, при котором хранимые номера карт оказываются раскрыты, потому что оператор обрабатывал данные, которых SAQ A как раз призван был избежать, это расход совершенно другого порядка. Платежные системы могут потребовать судебно-техническое расследование специализированной фирмой, прежде чем кому-либо разрешат снова открыть счет, оплаченное продавцом независимо от результата, а затронутые карты перевыпускаются за счет продавца. Страхование киберответственности редко закрывает подобный пробел для такого бизнеса, поскольку контент для взрослых числится в списке исключенных отраслей у не одной крупной страховой компании в киберполисах, а значит, описанный здесь риск очень часто остается незастрахованным, а не просто дорогим.
Самое устойчивое последствие не штраф и даже не расследование. Это решение эквайера, как только инцидент или длительное несоответствие оказывается зафиксировано, закрыть счет вместо того, чтобы продолжать нести риск, и зафиксировать это закрытие так, чтобы другие эквайеры могли увидеть это прежде, чем откроют новый. Платежные отношения, на построение которых впервые ушли месяцы, значительно труднее восстановить с такой историей, привязанной к бизнесу.
Что сделать в этом месяце
Начните с того, чтобы выяснить письменно, какая анкета действительно применима сегодня. Спросите напрямую у платежного провайдера, а не предполагайте ответ: подтвердите, является ли текущая оплата перенаправлением, правильно изолированным iframe, или чем-то, что касается собственного сервера оператора в какой-либо точке пути, потому что ответ на этот вопрос это вся программа соответствия в одном предложении. Получите это по электронной почте, а не по телефону, поскольку это точка отсчета для каждого следующего решения.
Относитесь к любому запросу изменить способ приема карт как к вопросу соответствия прежде, чем к вопросу дизайна. Разработчик, желающий построить кастомную форму оплаты, потому что размещенная страница выглядит слишком обычной, или добавляющий чат или скрипт аналитики на ту же страницу, где размещен платежный iframe, принимает решение по PCI, независимо от того, называет ли кто-то это так. Проверяйте подобные изменения до их запуска, а не после того, как их обнаружит сканирование.
Подавайте ежегодную аттестацию вовремя и храните результаты каждого квартального сканирования, даже самых скучных, где ничего не меняется, потому что просроченная аттестация в глазах эквайера читается точно так же, как если бы ее никогда не подавали. Ничто из этого не сложно, когда базовая архитектура выбрана правильно. Оплата, построенная однажды вокруг размещенной страницы или правильно изолированного iframe, превращает все это в один вечер бумажной работы, повторяемый раз в год. Оплата, которая незаметно приобрела привычку касаться данных карты, превращает то же самое обязательство в постоянную программу безопасности, которую бизнес никогда не планировал вести.
