Банковское обозрение

Финансовая сфера


24.03.2020 Best-practice
PCI DSS не враг

Амбициозная цель сертификации эмиссии в крупных банках требует готовности к большому объему работы. Так, необходимо учитывать особенности сертификации по PCI DSS эмиссионной части процессинга


Ян Коршунов
Директор проектов Дирекции программ кибербезопасности Сбербанка

Cертификация на соответствие стандарту PCI DSS начинается с определения области применимости, обычно описываемой перечнем бизнес-процессов. Если говорить о банках и финансовых организациях, то можно четко выделить эмиссионные и эквайринговые процессы.

Эмиссионные процессы — те, в рамках которых обрабатываются данные карт, выпущенных самим банком: например, учетные системы персонализации, выдачи и логистики, АБС и CRM, использующие номера карт при расчетах или идентификации клиентов.

К эквайринговым процессам относят те, которые обрабатывают транзакции от банкоматов или POS-терминалов, содержащие данные любых карт, в том числе других банков, входящие запросы от международных платежных систем (МПС) и переводы с карты на карту между банками.

Эквайринг находится в зоне особого внимания

Какие процессы нужно включать в область аудита? Если банк начал свой карточный бизнес недавно, когда стандарт PCI DSS уже существовал и МПС предъявляли свои требования к процессингу, то у банка есть все шансы построить свои бизнес-процессы в полном соответствии со стандартом. У большинства коробочных решений на рынке уже есть готовые интерфейсы работы с другими автоматизированными системами, исключающие использование данных карт в открытом виде в интеграциях.

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

Стандарт PCI DSS непосредственно не делит карты на собственные и сторонние, поэтому распространяется на все бизнес-процессы, включая и эквайринг, и эмиссию. Но представители МПС, как правило, не настаивают на сертификации эмиссионной части, и QSA-аудиторы следуют такой же логике. При этом банк обязан явно взять на себя риски компрометации данных по своим картам. Технически проблем здесь, по большому счету, нет. При допущении компрометации данных своих карт их можно быстро заблокировать, оперативно провести мероприятия с клиентами и на этом считать инцидент исчерпанным. Издержки такого подхода могут покрываться доходом от карточного бизнеса, и обычно банки принимают на себя такие риски. Конечно, это не значит, что системы, обрабатывающие данные карт своего банка, можно никак не защищать. Защищать нужно, и требования стандарта выполнять необходимо, но сертифицировать необязательно — достаточно принять риски.

В отношении же данных карт сторонних банков ситуация другая: ведь речь идет о чужих активах, которыми рискует банк. Просчитать все последствия компрометации не удастся, так как банк не может предсказать результаты утечки данных, отследить реальные потери держателей скомпрометированных карт, и для идентификации и блокировки карт он вынужден обращаться в сторонние банки, в том числе и через МПС. Более того, банк обязан сообщать в МПС обо всех фактах таких утечек. Поэтому эквайринговый процесс всегда находится в зоне особого внимания МПС и совета PCI SSC.

Сертификация эмиссии — желания недостаточно

Нужно ли сертифицировать эмиссию? Если да, то как избавиться от данных платежных карт в исторических данных и бурно развивающихся бизнес-процессах?

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

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

Вариантов сертификации всех бизнес-процессов банка по PCI DSS немного. Первый — применить требования стандарта ко всей инфраструктуре банка. Это значит, что в область аудита должны попасть все системы. Звучит просто, но при реализации есть нюансы. Большое количество систем в скоупе будет означать множество людей, имеющих легитимный доступ к данным платежных карт, и порождать массу событий безопасности, которые должны регистрироваться и обрабатываться для выявления инцидентов. А это существенные затраты на программно-аппаратные комплексы для их обработки и на сотрудников службы ИБ, которые должны эти данные интерпретировать. Представьте себе тысячу высоконагруженных серверов. Сколько нужно ресурсов, чтобы «переварить» все, что на этих серверах происходит? Сравнимое по мощности оборудование для построения подсистем, огромный штат сотрудников, большое количество событий и высокий риск пропустить инцидент среди них. Конечно, сложные системы фильтрации и корреляции событий способны снизить нагрузку на отделы ИБ, но их развитие и поддержание — также непростая задача, в свою очередь, требующая ресурсов.

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

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

Где можно обрабатывать номера карт?

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

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

Также можно выделить системы по претензионной работе, где есть сценарии проверки каждой цифры номера карты при осуществлении переводов клиентами банка (например, при переводе сделана опечатка, и необходимо сравнить введенный номер карты с оригиналом).

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

Отдельным пунктом нужно выделить пласт задач по работе с обращениями государственных органов: судов, МВД, служб финансового мониторинга, судебных приставов и т.п. Традиционно государственные регуляторы требуют предоставления информации по данным карт. Совет PCI SSC здесь придерживается гибкой позиции: все локальные нормативные акты и законы имеют приоритет над международными требованиями. Стандарт PCI DSS не замещает локальное законодательство. В российских законах про защиту данных при передаче информации ничего не сказано, но, как правило, существуют договоры по обмену информацией, где защита передаваемых данных требуется в явном виде. Поэтому никакого конфликта между PCI DSS и локальными законами нет: они друг другу не противоречат, а наоборот, дополняют друг друга. И если сама справка для запрашивающего органа действительно может быть составлена с содержанием полных номеров карт и даже отправлена заинтересованным лицам по открытым каналам, например по электронной почте, это не значит, что документ не нужно защищать при передаче и хранении.

Замена номеров карт: каким путем идти?

Мы ограничили область аудита. Теперь нужно решить другую важную задачу: чем заменить номера карт в автоматизированных системах и какие будут к этому заменителю требования? Решение зависит от архитектурного принципа перехода. Основной вопрос: это будет дополнительный атрибут карты или замена самого номера другим значением? В обоих случаях есть свои плюсы и минусы.

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

Если не вводить дополнительный атрибут, а заменить номер карты новой сущностью, то указанная проблема не встанет так остро. Строго говоря, в момент замены также можно допустить накопление локальных кэшей, но отследить его существенно проще, так как операция ограничена местом и временем. Правда, при вводе новой сущности нужно обеспечить единовременную замену во всех интегрированных системах, что существенно повышает требования к синхронности процедур миграции либо затягивает эту миграцию на годы. Так что, каким путем идти — нужно решать коллегиально с привлечением архитектуры, IT, ИБ и бизнеса.

Чем должен быть токен?

Назовем для простоты новую сущность токеном и попробуем сформировать для него критерии. Чем должен быть токен: случайной величиной, неким хешем или иной криптографической производной от номера карты? Какова должна быть его длина? Допустимы ли в нем буквы или шестнадцатеричные цифры?

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

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

Преобразовывать номер карты в токен необходимо на границе сетевых зон безопасности контура PCI DSS и остальной сети, если централизованно автоматизировать замену номера карты токеном при интеграциях

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

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

Будет ли этого достаточно? Давайте посчитаем емкость данных. Для 16-значного, наиболее популярного номера карты, маскируется шесть цифр, и именно они должны стать базой для токена, так как остальные остаются неизменными. Шесть цифр — это миллион значений, а для шестнадцатеричных цифр — 16,8 млн. Вычтем один миллион значений, не содержащих шестнадцатеричных цифр: A-F (000 000 — 999 999), остается 15,8 млн значений. Используя первые шесть и последние четыре цифры в качестве значения для вычисления сдвига по таблице замены (по модулю 15), можно реализовать токенизацию с уникальными токенными значениями для всех токенизируемых шести цифр с пятнадцатикратным запасом, случайно распределенным по всем совпадающим токенизированным данным.

Токен и номер карты. Сходства и различия. Источник: Сбербанк, 2020 год

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

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

Миграция данных требует проработки

Процедура миграции с номеров карт на токены также требует проработки. Большим банкам осуществить синхронную доработку, а тем более миграцию накопленных данных очень сложно, поэтому важно предусмотреть поэтапную миграцию. Этапы могут быть как в разрезе автоматизированных систем, так и номеров карт: например, по диапазонам BIN. А можно реализовать и комплексный подход — выбор должен учитывать все архитектурные особенности инфраструктуры, готовность всех участников к синхронизации и приоритизации своих планов.

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

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

Использование токенизации на границе контура PCI DSS и остальным банком. Источник: Сбербанк, 2020 год

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




Присоединяйся к нам в телеграмм
Сейчас на главной