Токенизация (информационная безопасность)

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Это схематический пример того, как токенизация используется в мобильных платежах при оплате с кредитной карты в мобильном приложении.[1][2] В платежных терминалах также могут быть использованы иные методы, кроме сканирования отпечатков пальцев или PIN-кодов.

Токенизация, применяемая в области информационной безопасности, представляет собой процесс замены конфиденциального элемента данных на неконфиденциальный эквивалент, называемый токеном, который не имеет самостоятельного смысла/значения для внешнего или внутреннего использования. Токен — это ссылка (то есть идентификатор), которая сопоставляется с конфиденциальными данными через систему токенизации. Сопоставление исходных данных с токеном использует методы, которые делают невозможным обратное преобразование токенов в исходные данные вне системы токенизации, например, с использованием токенов, созданных при помощи случайных чисел.[3] Система токенизации должна быть защищена и проверена на основе самых эффективных мер[4] по обеспечению безопасности, применяемых к защите конфиденциальных данных, хранению, аудиту, аутентификации и авторизации. Система токенизации предоставляет приложениям обработки данных полномочия и интерфейсы для запроса токенов или расшифровку конфиденциальных данных из токенов.

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

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

Токенизация может быть использована для защиты таких конфиденциальных данных, как банковские счета, финансовые ведомости, медицинские карты, судимости, водительские удостоверения, сcуды, биржевые сделки, регистрация избирателей и прочая личная информация. Токенизация часто используется при оформлении кредитных карт. Совет PCI DSS определяет токенизацию как «процесс, при котором первичный номер счета (PAN-кода) заменяется суррогатным значением, называемым токеном. Детокенизация — это обратный процесс получения значения PAN-кода по целевому токену. Безопасность отдельного токена зависит, главным образом, от невозможности определения исходного PAN-кода, зная только суррогатное значение».[5] Выбор токенизации в качестве альтернативы другим методам, например, таким, как шифрование, зависит от конкретных нормативных требований и стандартов, принятых соответствующими органами аудита или оценки. Существуют и прочие технические, архитектурные и эксплуатационные ограничения, которые возникают при практическом применении токенизации.

Понятия и истоки

[править | править код]

Alex Rofle «Падение и рост токенизации», Май 13, 2015:

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


В цифровом мире аналогичные методы замещения использовались с 1970-х годов в качестве средства изоляции элементов реальных данных от воздействия других систем данных. Например, в базах данных значения суррогатных ключей используются с 1976 года для изоляции данных, связанных с внутренними механизмами баз данных и их внешними эквивалентами, для различного применения в обработке данных. В последнее время эти концепции были расширены для обеспечения тактики изоляции и выполнения мер безопасности, применяемых в целях защиты данных.[6]

В индустрии платежных карт токенизация является одним из средств защиты конфиденциальных данных о держателях карт в целях соответствия отраслевым стандартам и государственным нормам.

В 2001 году TrustCommerce создал концепцию токенизации для защиты конфиденциальных платежных данных клиентов компании Classmates.com.[7] Компания привлекла TrustCommerce, потому что риск хранения данных держателя карты был слишком велик, если бы вдруг их системы подверглись взлому. TrustCommerce разработал систему TC Citadel®, благодаря которой покупатели могли ссылаться на токен вместо данных держателя карты, а TrustCommerce обрабатывал платеж от имени продавца.[8] Такая система защиты позволила клиентам надежно и безопасно совершать повторяющиеся платежи без необходимости хранить платежную информацию о держателе карты. Токенизация заменяет основной номер счета (PAN-код) на безопасные, случайно сгенерированные токены. В случае перехвата данные не содержат информации о держателях карт, что делает их бесполезными для хакеров. PAN-код не может быть получен, даже если токен и системы, в которых он находится, взломаны, и токен не может быть обратно преобразован в PAN-код.

Токенизация была применена к данным платежных карт компанией Shift4 Corporation[9] и обнародована во время отраслевого саммита по безопасности в Лас-Вегасе, штат Невада, в 2005 году.[10] Технология предназначена для предотвращения кражи информации о кредитной карте на запоминающем устройстве. Shift4 определяет токенизацию, как «концепцию использования неуязвимого к расшифровке фрагмента данных для представления конфиденциальных или секретных данных посредством ссылки на него. В контексте индустрии платежных карт (PCI DSS) токены используются для ссылки на данные о держателях карт, которые управляются в системе токенизации, приложении или на удаленном безопасном сервере.»[11]

Для обеспечения защиты данных на протяжении всего жизненного цикла токенизация часто комбинируется со сквозным шифрованием при передаче данных в систему или службу токенизации, включая обратное преобразование токена в исходные данные. Например, чтобы избежать риска кражи вредоносными программами из систем с низким уровнем доверия, таких как точки продаж (POS), как в случае хакерской атаки 2013 года, шифрование данных о держателях карт должно выполняться до ввода данных карт в POS, а не после. Шифрование происходит в рамках защищенного и проверенного устройства для чтения карт, и данные остаются зашифрованными до тех пор, пока не будут получены хостом обработки. Подход, впервые примененный платежными системами Heartland Payment Systems[12] в качестве средства защиты платежных данных от продвинутых угроз, в настоящее время широко используется технологическими и промышленными компаниями по обработке платежей.[13] Совет PCI DSS также в соответствующих документах определил специфические требования к сквозному шифрованию (сертифицированное шифрование вида точка-точка — P2PE) для различных сфер применения.

Отличие от шифрования

[править | править код]

Токенизация и «классическое» шифрование эффективно защищают данные, если они реализованы должным образом, и идеальное решение для обеспечения безопасности будет использовать оба этих метода. Несмотря на сходство в некоторых отношениях, токенизация и классическое шифрование различаются в некоторых ключевых аспектах. Оба эти метода обеспечивают криптографическую защиту данных и выполняют по существу одну и ту же функцию, однако делают они это различными способами и оказывают различное влияние на данные, которые защищают.[14]

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

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

Типы токенов

[править | править код]

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

В контексте платежей важную роль играет разница между большой и маленькой разрядностью токенов.[16]

Многоразрядные токены

[править | править код]

Многоразрядные токены служат в качестве суррогатов для фактических PAN-кодов в платежных операциях и используются в качестве инструмента для завершения платежной операции. Чтобы функционировать они должны выглядеть как настоящие PAN-коды. Несколько таких токенов могут сопоставляться с одним PAN-кодом и одной физической кредитной картой без ведома владельца.[17]

Кроме того, многоразрядные токены могут быть ограничены определенной сетью и/или продавцами, а PAN-коды нет.

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

Малоразрядные токены или токены безопасности

[править | править код]

Малоразрядные токены также действуют как суррогаты для фактических PAN-кодов в платежных транзакциях, однако, они служат для другой цели. Такие токены не могут быть использованы для завершения платежной транзакции. Для того чтобы малоразрядный токен функционировал, должна быть возможность сопоставить его с фактическим PAN-кодом, который он представляет, но только строго контролируемым образом. Использование токенов для защиты PAN-кодов становится неэффективным, если нарушена система токенизации, поэтому крайне важно обеспечить безопасность самой системы токенизации.[18]

Система операций, ограничения и эволюция

[править | править код]

Системы токенизации первого поколения используют базу данных для сопоставления реальных данных с замещающими их токенами и обратно. Чтобы избежать потери данных это требует хранения, управления и непрерывного резервного копирования для каждой новой транзакции, добавленной в базу данных токенов. Другой проблемой является обеспечение согласованности между центрами обработки данных, что требует непрерывной синхронизации баз данных токенов. При таком подходе неизбежны значительные компромиссы между согласованностью, доступностью и производительностью в соответствии с теоремой CAP. Эти накладные расходы усложняют обработку транзакций в реальном времени, чтобы избежать потери данных и обеспечить целостность данных в центрах обработки данных, а также ограничивают масштаб. Хранение всех конфиденциальных данных в одном месте создает привлекательную цель для атаки и нанесения ущерба, а также приводит к появлению юридических рисков обобщения данных, конфиденциальных в Интернете, в частности в ЕС.

Другим ограничением технологий токенизации является измерение уровня безопасности для данного решения путем независимой проверки. С отсутствием стандартов, последнее имеет решающее значение для установления надежности токенизации, предлагаемой, когда токены используются для соответствия нормативным требованиям. Совет PCI DSS рекомендует независимую проверку и подтверждение всех требований безопасности и соответствия: «Продавцы, рассматривающие использование токенизации, должны провести тщательную оценку и анализ рисков для выявления и документирования уникальных характеристик их конкретной реализации, включая все взаимодействия с данными платежных карт и конкретными системами и процессами токенизации».[5]

Метод создания токенов также может иметь ограничения с точки зрения безопасности. Что же касается безопасности и атак на генераторы случайных чисел, которые обычно используются для создания токенов и таблиц их сопоставления, то необходимо провести тщательное исследование, чтобы гарантировать, что используется действительно проверенный и надежный метод.[19] Генераторы случайных чисел имеют ограничения с точки зрения скорости, энтропии, отбора и смещения, и свойства безопасности должны быть тщательно проанализированы и измерены для предотвращения предсказуемости и компромисса.

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

В ноябре 2014 года American Express выпустила сервис токенов, который соответствует стандарту токенов EMV.[22]

Применение к альтернативным платежным системам

[править | править код]

Создание альтернативной платежной системы требует совместной работы ряда организаций для предоставления конечным пользователям коммуникации ближнего поля (NFC) или других технологий, основанных на платежных сервисах. Одной из проблем является совместимость между участниками. Для решения этой проблемы предлагается роль доверенного менеджера услуг (TSM) для установления технической связи между операторами сотовой связи (ОСС) и поставщиками услуг, чтобы эти субъекты могли работать вместе. Токенизация может играть посредническую роль для таких субъектов.

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

Применение к стандартам PCI DSS

[править | править код]

Payment Card Industry Data Security Standard, отраслевой набор требований, необходимых для соблюдения любой организацией, которая хранит, обрабатывает или передает данные о держателях карт, предписывает, что данные кредитных карт должны быть защищены при хранении.[23] Токенизация, применяемая к данным платежных карт, часто реализуется для выполнения этого стандарта, заменяя номера кредитных карт и ACH в некоторых системах случайным значением или строкой символов.[24] Токены могут быть отформатированы различными способами. Некоторые поставщики токенов или системы токенизации создают суррогатные значения таким образом, чтобы они соответствовали формату исходных конфиденциальных данных. В случае данных платежной карты токен может иметь ту же длину, что и основной номер счета (банковской карты), и содержать такие элементы исходных данных, как последние четыре цифры номера карты. При запросе авторизации платежной карты для проверки законности транзакции вместо номера карты продавцу может быть возвращен токен, а также код авторизации транзакции. Токен хранится в принимающей системе, а фактические данные о держателе карты сопоставляются с токеном в защищенной системе токенизации. Хранение токенов и данных платежных карт должно соответствовать действующим стандартам PCI DSS, включая использование надежной криптографии.[25]

Стандарты (ANSI, Совет PCI DSS, Visa, и EMV)

[править | править код]

В настоящее время токенизация находится в определении стандартов в ANSI X9 как Х9.119 часть 2. X9 отвечает за отраслевые стандарты финансовой криптографии и защиты данных, включая управление PIN-кодами платежных карт, шифрование кредитных и дебетовых карт, а также связанные с ними технологии и процессы.

Совет PCI DSS также заявил о поддержке токенизации для снижения риска утечки данных в сочетании с другими технологиями, такими как двухточечное шифрование (P2PE), и оценками соответствия рекомендациям PCI DSS.[26]

Visa Inc. выпустила Visa Tokenization Best Practices[27] для использования токенизации в приложениях и услугах по обработке кредитных и дебетовых карт.

В марте 2014 года, EMVCo LLC выпустила свою первую спецификацию оплаты токена для EMV.[28]

NIST стандартизировал алгоритмы шифрования с сохранением формата FF1 и FF3 в своей специальной публикации 800-38G.[29]

Снижение риска

[править | править код]

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

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

Примечания

[править | править код]
  1. Архивированная копия. Дата обращения: 22 декабря 2018. Архивировано из оригинала 26 января 2018 года.
  2. Payment Tokenization Explained (англ.). Square. Дата обращения: 22 декабря 2018. Архивировано 2 января 2018 года.
  3. Tokenization 101: Understanding the Basics - WEX Corporate Payments Edge (англ.). WEX Inc. (27 июля 2017). Дата обращения: 22 декабря 2018. Архивировано 22 декабря 2018 года.
  4. Category:OWASP Top Ten Project - OWASP. www.owasp.org. Дата обращения: 22 декабря 2018. Архивировано из оригинала 1 декабря 2019 года.
  5. 1 2 PCI DSS Tokenization Guidelines. www.pcisecuritystandards.org. Дата обращения: 22 декабря 2018. Архивировано 10 ноября 2013 года.
  6. The fall and rise of Tokenization (англ.). Payments Cards & Mobile (13 мая 2015). Дата обращения: 23 декабря 2018. Архивировано 23 июля 2016 года.
  7. TrustCommerce Staff. Where Did Tokenization Come From? (англ.). TrustCommerce. Дата обращения: 22 декабря 2018. Архивировано 23 декабря 2018 года.
  8. TrustCommerce. web.archive.org (5 апреля 2001). Дата обращения: 22 декабря 2018. Архивировано 5 апреля 2001 года.
  9. Shift4 Corporation Releases Tokenization in Depth White Paper | Reuters. web.archive.org (13 марта 2014). Дата обращения: 22 декабря 2018. Архивировано 13 марта 2014 года.
  10. Internet Retailer | E-Commerce | Online Retailing | Top 500 | Online Sales (англ.). Digital Commerce 360. Дата обращения: 22 декабря 2018. Архивировано 24 января 2017 года.
  11. Shift4 Corporation. Credit Card Payment Gateway - Fast, Reliable, and Secure Credit, Debit, Check, and Gift Card Processing with Tokenization | Shift4 (англ.). https://www.shift4.com/.+Дата обращения: 22 декабря 2018. Архивировано 6 ноября 2018 года.
  12. https://philadelphiafed.org/-/media/consumer-finance-institute/payment-cards-center/publications/discussion-papers/2010/D-2010-January-Heartland-Payment-Systems.pdf
  13. Voltage, Ingencio Partner on Data Encryption Platform. eWEEK. Дата обращения: 22 декабря 2018.
  14. What is Tokenization vs Encryption - Benefits & Uses Cases Explained (англ.). Skyhigh. Дата обращения: 24 декабря 2018. Архивировано 25 декабря 2018 года.
  15. Tokenization vs Encryption: Understanding the Difference (англ.). Liaison Technologies (3 февраля 2017). Дата обращения: 24 декабря 2018. Архивировано 25 декабря 2018 года.
  16. Источник. Дата обращения: 24 декабря 2018. Архивировано 25 декабря 2018 года.
  17. Tokenization: The differences between Tokenization and Encryption? |. Дата обращения: 24 декабря 2018. Архивировано 25 декабря 2018 года.
  18. Demystifying Tokenization: Payment Versus Security Tokens (англ.). Connect Worldwide. Дата обращения: 24 декабря 2018.
  19. How do you know if an RNG is working? (англ.). A Few Thoughts on Cryptographic Engineering (19 марта 2014). Дата обращения: 22 декабря 2018. Архивировано 22 декабря 2018 года.
  20. Jaikumar Vijayan. Banks push for tokenization standard to secure credit card payments (англ.). Computerworld (12 февраля 2014). Дата обращения: 22 декабря 2018. Архивировано 27 июля 2018 года.
  21. Data Security & Data Encryption Software (англ.). Micro Focus. Дата обращения: 22 декабря 2018. Архивировано 21 декабря 2018 года.
  22. American Express Introduces New Online and Mobile Payment Security Services. web.archive.org (4 ноября 2014). Дата обращения: 22 декабря 2018. Архивировано 4 ноября 2014 года.
  23. Official PCI Security Standards Council Site - Verify PCI Compliance, Download Data Security and Credit Card Security Standards. www.pcisecuritystandards.org. Дата обращения: 22 декабря 2018. Архивировано 10 декабря 2015 года.
  24. Payment Tokenization: PCI DSS Compliant Data Tokenization (англ.). Bluefin. Дата обращения: 22 декабря 2018. Архивировано 22 декабря 2018 года.
  25. Wayback Machine. web.archive.org (31 июля 2009). Дата обращения: 22 декабря 2018. Архивировано 31 июля 2009 года.
  26. Источник. Дата обращения: 22 декабря 2018. Архивировано 7 апреля 2014 года.
  27. Access Denied. usa.visa.com. Дата обращения: 22 декабря 2018. Архивировано 24 октября 2020 года.
  28. Payment Tokenisation (англ.). EMVCo. Дата обращения: 22 декабря 2018. Архивировано 25 декабря 2018 года.
  29. Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption. nvlpubs.nist.gov. Дата обращения: 22 декабря 2018. Архивировано 25 июня 2019 года.
  30. Guide to Cryptography - OWASP. www.owasp.org. Дата обращения: 22 декабря 2018. Архивировано из оригинала 7 апреля 2014 года.