У слова «тестовый» есть опасное свойство: оно успокаивает. Раз окружение тестовое, кажется, что строгие требования к данным карт на него не распространяются. Это неверное представление, и оно дорого стоит: тестовые данные PCI DSS подчиняются тем же правилам, что и рабочие, если в них есть настоящие реквизиты. Ниже — почему тестовый контур попадает в область действия стандарта, что именно запрещено хранить, чем синтетические данные отличаются от токенов и как выстроить работу, чтобы стенд не стал слабым звеном.
Почему тестовый стенд попадает под требования
Стандарт описывает требования к защите данных держателей карт. Ключевое слово — данные, а не среда, в которой они лежат. Если на стенде хранится номер настоящей карты, этот стенд обрабатывает данные держателей карт, и требования к нему применяются в полном объёме.
Более того, стенд почти всегда слабее рабочей системы. На нём проще доступ, слабее контроль прав, чаще включено подробное логирование, а базу регулярно перезаливают из рабочей копии. Именно так настоящие реквизиты и попадают туда, откуда их никто не собирался вычищать.
Что стандарт запрещает хранить?
Запреты касаются в первую очередь данных аутентификации. Код проверки карты и содержимое магнитной полосы нельзя сохранять после того, как операция авторизована, — ни в базе, ни в архиве, ни в резервной копии, ни в журналах. Это требование распространяется и на тестовые окружения: исключений для стендов не существует.
Второе правило касается разработки и тестирования: использовать реальные данные держателей карт в этих целях не разрешается. Разрешены синтетические данные, то есть искусственно созданные значения, либо токены — ссылки, за которыми реальный номер хранит поставщик платежей, а вы видите только идентификатор.
Третье правило относится к хранению: если вы всё же храните данные счёта, они должны быть защищены, а при отображении — маскированы. Обычная практика маскирования: показывать первые несколько цифр и последние четыре, а середину заменять символами.
Сказанное выше удобно свести к короткому перечню:
- Данные аутентификации — код проверки карты и содержимое магнитной полосы — после авторизации операции не сохраняют ни в базе, ни в архиве, ни в резервной копии, ни в журналах.
- То же правило действует и на тестовых стендах: исключений для них не существует.
- Реальные данные держателей карт в разработке и тестировании не используют.
- Разрешённая замена — синтетические значения и токены, то есть ссылки, за которыми реальный номер хранит поставщик платежей.
- Данные счёта, если вы их всё же храните, должны быть защищены, а при отображении маскированы.
Что такое токенизация простыми словами?
Токен — это заменитель номера карты. Настоящий номер остаётся у поставщика платежей, а ваша система работает со ссылкой на него. Для отчётности и повторных операций этой ссылки достаточно, а ценности для злоумышленника она не представляет: восстановить по ней номер нельзя.
Практическая выгода в том, что объём требований резко сокращается. Если настоящие номера не проходят через вашу инфраструктуру и не оседают в базе, то и защищать становится почти нечего. Именно поэтому токенизация считается основным способом упростить соответствие, а не просто удобной технической надстройкой.
Синтетические данные против реальных
Синтетические данные — это значения, созданные искусственно. Они проходят проверки формата: правильная длина, известное начало, сходящаяся контрольная цифра. При этом за ними не стоит ни один счёт, поэтому их можно свободно хранить, копировать между стендами, использовать в демонстрациях и в наполнении тестовых баз.
Именно такие значения выдаёт генератор: номера в нём структурно корректны, но никогда не выпускались ни одним банком и не принадлежат никому. Для тестового контура это лучший вариант: данные выглядят как настоящие для всех проверок формы, но не являются платёжными реквизитами и по ним невозможно провести операцию.
Небольшая оговорка, которую стоит помнить: синтетические номера тоже не стоит публиковать в открытых репозиториях без разбора. Не потому, что они опасны, а потому, что привычка копировать данные карт в код приводит к тому, что однажды туда попадает настоящее значение.
Можно ли просто замаскировать рабочие данные
Маскирование — полезная мера, но она не заменяет запрет на использование реальных данных в тестировании. Если номер попал на стенд целиком, а показывается в интерфейсе частично, он всё равно остался на стенде: в базе, в индексах, в журналах, в дампах и в резервных копиях. Маскирование снижает риск случайного раскрытия, но не отменяет требования.
Кроме того, маскированные данные плохо подходят для тестирования. Если середина номера заменена одинаковыми символами, вы не проверите ни подсветку неизвестного начала, ни поведение формы на разных платёжных системах. Именно поэтому вместо маскирования рабочих значений берут синтетические: они полны, разнообразны и безопасны.
Что меняется, когда вы работаете с поставщиком
Многие решают, что раз оплату обрабатывает сторонняя платформа, требования к ним самим больше не относятся. Это не так. Часть обязанностей действительно переходит к поставщику, но только та, которую он выполняет физически: приём данных, их хранение, защита своего контура. Ваша сторона остаётся вашей.
На практике это означает три вещи. Первая: у вас должен быть письменный договор, в котором зафиксированы обязанности по защите данных держателей карт, — стандарт этого прямо требует, и наличие договора проверяется в первую очередь. Вторая: вы должны понимать, какие данные реально проходят через вашу инфраструктуру. Если вы передаёте номер напрямую поставщику и не сохраняете его, объём вашей ответственности один; если вы его сохраняете, он совсем другой. Третья: поставщик не обязан следить за тем, что происходит на вашем стенде, — эту часть закрываете вы сами.
Стандарт обновляется, и требования со временем меняются. Актуальную редакцию и официальные разъяснения стоит брать на сайте совета по стандартам безопасности платёжной индустрии, а не из пересказов в блогах: пересказ быстро устаревает, а расхождение с первоисточником обнаруживается в самый неудачный момент.
Что важно разработчику
Начните с инвентаризации. Пройдите по всем окружениям и выясните, где вообще встречаются данные карт: база, кэш, файлы выгрузок, логи приложений, журналы доступа веб-сервера, тела событий в очередях, вложения в письмах об ошибках, резервные копии. Практика показывает, что настоящие реквизиты находятся минимум в одном месте, о котором никто не помнил.
Дальше закройте источники появления. Автоматическая перезаливка рабочей базы на стенд должна быть исключена полностью — это самый частый канал попадания реальных номеров в тестовый контур. Если такая выгрузка кому-то нужна, наполняйте стенд синтетическими данными по тому же расписанию.
Отдельно проверьте логирование. Подробные журналы, удобные при отладке, часто пишут тело запроса целиком, вместе с кодом проверки карты и полным номером. Это нарушение, причём незаметное, потому что логи никому не показываются до инцидента. Полезно завести правило: всё, что может содержать платёжные данные, пишется в журнал только в усечённом виде.
И последнее — доступы. Тестовые окружения обычно защищены слабее рабочих, а данные в них могут быть почти такими же чувствительными, если туда что-то просочилось. Ограничение прав и список тех, у кого есть доступ к данным карт, стоит пересматривать так же регулярно, как на рабочем контуре.
Что делать дальше
Проведите быструю проверку прямо сейчас: возьмите любое тестовое окружение и попробуйте найти в его базе и логах строку из шестнадцати цифр. Если найдёте настоящий номер — это задача с высоким приоритетом. Для наполнения стендов используйте значения из генератора, а связанные сценарии проверки собраны в чек-листе платёжной формы и в материале про хранение кода проверки.