Платёжная форма: как снизить объём требований PCI DSS

Прямой ответ

Объём требований безопасности определяется тем, проходит ли номер карты через инфраструктуру сервиса. Три схемы дают разный охват.

Хостинг-страница означает, что пользователь вводит данные на странице провайдера, а сервис получает только результат. Поля провайдера размещаются на странице сервиса, но отправляются напрямую провайдеру, поэтому данные не проходят через сервер сервиса.

<!-- Поля провайдера: ввод отправляется провайдеру, не вашему серверу -->
<form id="payment-form">
  <div id="card-element" data-provider-field></div>
  <button type="submit">Оплатить</button>
</form>

# Сервер сервиса получает токен, а не данные карты
payment_method_id = request.json["payment_method_id"]
r = httpx.post(f"{API}/v1/payments", auth=(SHOP_ID, SECRET_KEY),
               json={"amount": {"value": "1500.00", "currency": "RUB"},
                     "payment_method": payment_method_id}, timeout=10.0)

Сервис хранит идентификатор способа оплаты, а не данные карты; о токенизации — в статье про токенизацию банковских карт.

Собственная форма с отправкой номера карты на свой сервер возвращает сервис в полный объём требований, включая защиту среды хранения, журналирование доступа и регулярную оценку. Переход на такую схему без необходимости расширяет обязанности на порядок.

Что возвращает сервис в полный охват требований

Даже при использовании полей провайдера несколько решений возвращают обработку данных карты в инфраструктуру сервиса.

Перехват ввода на своей странице. Скрипт, читающий значение поля карты и передающий его на свой сервер, означает обработку данных карты в инфраструктуре сервиса, независимо от дальнейшего пути.

Журналирование тела запроса. Журнал, содержащий номер карты из запроса, становится хранилищем данных карты. Ограничение состава журнала обязательно при любой схеме.

Промежуточный прокси с доступом к телу запроса. Прокси, расшифровывающий трафик и записывающий тело, обрабатывает данные карты.

Хранение данных карты «временно». Временное хранение для отладки не имеет исключений: данные карты в среде сервиса попадают в охват с момента появления.

Практическое следствие: граница определяется не намерением, а фактом прохождения данных. Проверка выполняется по журналу запросов и по составу сохраняемых данных.

Отдельный аспект — защита страницы оплаты. Политика содержимого ограничивает источники скриптов, поэтому внедрённый скрипт не может перехватить ввод; о политике содержимого — в документации браузера. Ключи API провайдера хранятся вне кода; о хранении — в статье про секреты в разработке.

Передача выполняется только по защищённому соединению, а сертификат поддерживается в действующем состоянии. О схеме интеграции — в статье про интеграцию платёжного шлюза.

Практика: организация формы оплаты

1. Используйте поля провайдера либо хостинг-страницу. Данные карты не проходят через сервер сервиса, что сокращает объём требований.

2. Не перехватывайте ввод поля карты. Скрипт на своей странице, читающий номер карты, возвращает сервис в полный охват.

3. Ограничьте состав журнала. Тело платёжного запроса не сохраняется в журнал ни в каком виде.

4. Настройте политику содержимого страницы оплаты. Ограничение источников скриптов снижает риск перехвата ввода.

5. Проверяйте прокси и промежуточные компоненты. Компонент с доступом к расшифрованному телу запроса обрабатывает данные карты.

6. Храните только токен способа оплаты. Идентификатор у провайдера заменяет данные карты во всех последующих операциях.

7. Фиксируйте принятую схему в документации. Изменение схемы оплаты меняет объём требований, поэтому решение документируется.

Рекомендации:

1. Не сохраняйте данные карты для отладки. Временное хранение не имеет исключений и расширяет охват требований с момента появления данных.
2. Различайте отображаемые сведения и данные карты. Последние четыре цифры и бренд не относятся к данным карты и используются в интерфейсе.
3. Проверяйте состав ошибок, возвращаемых пользователю. Сообщение об ошибке не должно содержать фрагментов данных карты.
4. Учитывайте мобильные приложения. Схема с нативной формой отличается от веб-формы, и объём требований определяется способом ввода.
5. Проверяйте требования при смене провайдера. Способ интеграции определяется провайдером, поэтому смена меняет схему и объём требований.

Практический сценарий: номер карты попал в журнал

Контекст: при разборе обращения в журнале приложения обнаружился номер карты в составе тела запроса.

1. Диагностика. Журнал содержал полный номер карты и срок действия в записи тела входящего запроса. Запись создана стандартным промежуточным слоем журналирования запросов.
2. Причина. Промежуточный слой журналировал тело всех запросов без исключений, а платёжный запрос обрабатывался тем же маршрутом, что и остальные. Данные карты оказались в среде сервиса, что расширило охват требований.
3. Действия. (а) Перевели форму оплаты на поля провайдера, чтобы номер карты не отправлялся на сервер сервиса; (б) исключили платёжные маршруты из журналирования тела запроса; (в) добавили маску для полей, похожих на номер карты, в промежуточном слое журналирования; (г) удалили записи журнала, содержащие данные карты, и проверили резервные копии журнала; (д) добавили проверку состава журнала в список проверок при изменении маршрутов.
4. Результат. Данные карты не проходят через сервер сервиса и не попадают в журнал, а объём требований соответствует схеме с полями провайдера.

Вывод: граница охвата требований определяется фактом прохождения данных карты через инфраструктуру сервиса, а не намерением. Журналирование тела запроса — частая причина непреднамеренного расширения охвата, поэтому исключение платёжных маршрутов и маска полей обязательны.

FAQ

Обязательно ли использовать хостинг-страницу провайдера? Нет. Поля провайдера на своей странице также исключают прохождение данных карты через сервер сервиса и дают тот же эффект.

Относится ли последние четыре цифры к данным карты? Нет. Отображаемые сведения не позволяют выполнить операцию и не входят в охват требований.

Что делать, если данные карты попали в журнал? Удалить записи, проверить резервные копии журнала и устранить причину — журналирование тела платёжного запроса.

Меняется ли объём требований при смене провайдера? Да, если меняется способ интеграции. Схема ввода данных карты определяет охват, поэтому смена провайдера требует пересмотра схемы.

Источники: PCI Security Standards Council, Stripe security guide, MDN Content Security Policy — ссылки в шапке.