Я, конечно, не получаю пачками вопросы по безопасности платежных карт, однако, время от времени кто-нибудь да и задаст мне такой вопрос, который заслуживает отдельной публикации в блоге. Буквально на днях одна читательница, Мишель, задала мне такой вопрос, который, в целом отражает часто встречающееся непонимание в сфере безопасности платежных карт:

Вчера я перечитывала PCI DSS 2.0, требование 3.4, и была немало удивлена тем, что для защиты хранимых номеров PAN не предлагается такая мера как «маскирование».   Правильно ли я понимаю, что эти номера подлежат шифрованию перед помещением их на хранение, а при извлечении, они подлежат расшифрованию и маскированию? И потом, если мы получаем номер PAN уже в маскированном виде, а затем храним его, то попадает ли такое хранение под действие стандарта PCI DSS? С технической точки зрения, как я думаю, не попадает, т.к. PAN уже маскирован при получении, а значит нет возможности найти номер PAN  в незашифрованном виде.  

Вот в этом как раз и кроется основная суть непонимания сути маскирования. Многие люди либо вообще не знают о существовании усечения и полагают, что если они не могут видеть полный номер карты, то это маскирование, либо считают, что усечение и маскирование — это одно и то же.  Несомненно это разные вещи, поэтому я позволю себе процитировать определения маскирования и усечения прямо из Глоссария PCI SSC:

Маскирование (Masking)

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

Усечение (truncation)

Метод приведения номера PAN к нечитаемому виду посредством удаления сегмента данных PAN.

Представьте себе данные о держателе карты (далее – ДДК) в виде цифр на листке бумаги.   При маскировании мы словно берем коррекционную ленту и наносим ее на большую часть цифр таким образом, чтобы человеку, которому передается этот листок, было видно только последние 4 цифры.  Очевидно, что при этой операции данные по прежнему существуют под коррекционной лентой, хотя она их и скрывает.   Разумеется, с этого листка бумаги, приложив некоторые усилия, можно счистить коррекционную ленту, а значит этот лист бумаги по прежнему нуждается в защите, при которой никакие злоумышленники не могли бы восстановить и использовать данные о держателе карты.

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

Если на экране отображаются данные, из которых видна только малая часть, то нельзя знать наверняка, какие именно представлены данные — усеченные или маскированные. Для того, чтобы это узнать, необходимо глубже понимать процессы их обработки.   Только понимая процессы, можно сказать, можно ли каким-либо воссоздать эти данные или же в базе данных хранятся те же данные, которые видны  на экране.  Находясь в обычном магазине, можно увидеть на чеках последние 4 цифры номера карты.   Если платежное приложение написано корректно, то должность персонала – будь то руководитель торгового зала или продавец — не должна иметь значения: в любом случае никто не должен видеть ничего кроме последних 4 цифр номера. Дело в том, что в таком приложении данные не сохраняются, а значит ни у кого из сотрудников магазина нет возможности извлечь данные из системы — данные усечены и их в системе больше нет.

Совсем иная ситуация в бэк-офисе, в бухгалтерии и в службе, отвечающей за предотвращение ущерба.   По умолчанию, сотрудники этих отделов и служб должны видеть только 4 последних цифры номера платежной карты.  Однако при возникновении претензионных платежей или подозрений на вероятное мошенничество, сотрудники компании в рамках расследования должны иметь возможность отменить маскирование полного номера карты.   Эти номера по-прежнему существуют на сервере, однако, они там в основном хранятся в маскированном (скрытом) виде, и отображаются только должным образом уполномоченному персоналу.  Поскольку имеется возможность извлечения этих данных на серверах, они полностью входят в область оценки на соответствие стандарту PCI DSS и подлежат соответствующей защите.

Таким образом, отвечая на вопрос читательницы, я скажу, что хранимые данные не могут быть «маскированы».  Они маскируются только при извлечении и считаются маскированными, если отображены частично. Именно поэтому, в требовании 3.4 отсутствует маскирование.   Если же ТСП получает ДДК, в которых имеется только сегмент номера PAN (например, сегмент из первых 6 или последних 4 цифр), то такие данные являются усеченными.   В таком случае полный номер PAN отсутствует, воссоздание его невозможно, а значит нет необходимости его защищать так же, как и ДДК.   Я не говорю, конечно, о том, что данные, привязанные к этому номеру не имеют ценности и не подлежат защите, просто усеченные данные не входят в область применения требований стандарта.

Если же ТСП получает полный номер PAN, но сотрудникам он отображается в маскированном виде, то, даже если никто в ТСП не имеет доступа к ДДК, оно все равно отвечает за их защиту согласно требованиям стандарта.  Если в этих данных нет необходимости, есть смысл просить о предоставлении усеченных данных, тем самым, сэкономив кучу сил и нервов на общении с аудиторами, выполнении требований стандарта, да и вообще на процессе приведения среды в соответствие со стандартом PCI DSS.  Например,  я приятный в общении человек, но даже самые большие мои поклонники среди клиентов подтвердят, что я становлюсь противным и невыносимым, как минимум, раз в год, когда прихожу к ним для проведения аудита.