Показ реквизитов карты в ДБО: архитектурная задача и пути реализации

OTP Bank -

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

Команда ОТП Банка провела архитектурное исследование, посвящённое тому, как безопасно передавать и отображать карточные данные клиента из процессинга на устройстве, не выходя за рамки PCI DSS.

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

Постановка задачи

Перед нами стояла конкретная задача. В системе ДБО (Remote Banking System) пользователю отображается только маскированный PAN, которого достаточно для базовой идентификации карты. Однако при запросе от клиента необходимо предоставить полный набор реквизитов: номер карты (PAN), срок действия и проверочный код CVV2, используемый для операций формата Card Not Present. При этом сам процессинг остаётся надёжно изолированным, и прямой доступ к нему со стороны клиента невозможен. Любая попытка обойти эту изоляцию означала бы нарушение требований PCI DSS, что автоматически влекло бы аудиторские проверки и риски для безопасности всей системы.

Ограничения PCI DSS

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

Работать с данными карт можно только внутри защищённой зоны CDE, при этом вне её границ допускается использовать лишь маскированные значения вроде PPAN или DPAN. Прямой доступ к системам внутри CDE недопустим, поэтому всё взаимодействие должно идти через интеграционный слой, который отсекает запрещённые данные. Особое внимание уделяется кодам CVV и CVV2, поскольку они не подлежат хранению даже в CDE после авторизации. Кроме того, CVV2 нельзя сохранять ни при каких условиях, так как именно он несёт наибольший риск компрометации.

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

Использование iFrame, сгенерированного в зоне CDE

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

Как это работает:

  1. Пользователь инициирует просмотр реквизитов в ДБО (RBS).
  2. RBS проводит усиленную аутентификацию, например через OTP по SMS, и выполняет её параллельно остальным шагам.
  3. RBS создаёт одноразовый высокоэнтропийный токен доступа и передаёт его клиентскому приложению.
        Одновременно RBS запрашивает у Secure Render Service (SRS) в CDE подготовку контента, передавая токен и идентификатор карты.
  4. SRS запрашивает у процессинга актуальные реквизиты карты, формирует страницу или изображение с данными и регистрирует готовый контент в Secure Content Delivery Proxy (SCDP) в сегменте Connected-to, привязывая его к токену.
  5. Клиентское приложение, имея токен, обращается к SCDP.
  6. SCDP дожидается поступления контента от SRS и по защищённому TLS отдаёт его клиенту в виде iFrame.
  7. Браузер отображает iFrame, источник которого остаётся внутри инфраструктуры банка.

Почему это безопасно и соответствует стандарту

Данные карты, включая CVV2, обрабатываются и остаются в CDE. В DMZ и на клиентскую сторону попадает только уже сгенерированный контент. iFrame изолирован от основной DOM-страницы, что снижает риски XSS. Одноразовый токен исключает повторный доступ. Такой механизм напрямую реализует принцип изоляции CDE и исключает хранение SAD вне её периметра.

Какие есть сложности

Несмотря на безопасность, подход имеет свои ограничения:

  • Возможны тайм-ауты HTTP-запроса из-за длины цепочки взаимодействия. Решение — запускать проверку OTP параллельно обработке данных. В большинстве случаев пользователь увидит результат сразу после ввода кода.
  • Архитектура распределена и опирается на несколько компонентов — SRS и SCDP. Для стабильной работы важно наладить их взаимодействие, предусмотреть механизм ожидания в DMZ и своевременную очистку невостребованных данных. Всё это повышает сложность разработки и дальнейшей поддержки.
  • Зависимость от клиентской сети.     Браузеры или корпоративные прокси могут блокировать iFrame из внешнего источника, и в этом случае понадобится fallback-сценарий.

Чтобы минимизировать риски, необходимо реализовать механизм long-polling или webhooks на стороне клиента, провести нагрузочное тестирование всей цепочки и предусмотреть резервный сценарий для пользователей, у которых не загружается iFrame.

Рассмотрев самую надёжную опцию с iFrame, стоит оценить три других варианта, которые на первый взгляд могли бы подойти. Ниже разберём их по порядку и объясним, почему каждый из них не соответствует требованиям PCI DSS.

Вариант 1. Шифрование с использованием SMS-OTP

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

Как это работает:

  1. Пользователь запрашивает данные через RBS (ДБО).
  2. RBS генерирует одноразовый ключ (OTP) и отправляет его в процессинг.
  3. Процессинг шифрует данные карты этим ключом и возвращает результат в RBS.
  4. RBS передаёт ключ клиенту по SMS и вместе с ним отправляет зашифрованные данные.
  5. На устройстве клиента данные расшифровываются.

Почему не подходит:

  • Слабый уровень защиты. OTP по SMS — это всего 4–6 цифр, которые можно перебрать за секунды. К тому же SMS-канал уязвим для перехвата, MITM-атак или SIM-своппинга. PCI DSS прямо требует использовать защищённые каналы для передачи аутентификационных данных.  
  • Расширение зоны CDE. В такой схеме RBS получает и ключ, и зашифрованные данные, а значит, может их расшифровать. Это автоматически относит всю систему RBS к зоне CDE. Для банка это означает необходимость соответствия самым строгим требованиям PCI DSS, включая сегментацию сети, ежегодный аудит SAQ D и тд., что влечет за собой значительные финансовые издержки.
  • Нарушение запрета на хранение Sensitive Authentication Data (SAD). CVV2 не может храниться за пределами процессинга даже в зашифрованном виде. Передача этих данных уже является грубейшим нарушением требования PCI DSS 3.3.1, и за неё предусмотрены серьёзные штрафы.

Вариант 2. Асимметричное шифрование на клиенте

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

Как это работает:

  1. После входа в RBS клиентское приложение или браузер генерирует пару ключей (открытый и закрытый) для текущей сессии.
  2. Закрытый ключ хранится в памяти устройства и не передаётся наружу.
  3. При запросе данных карты приложение добавляет к нему свой открытый ключ.
  4. RBS пересылает запрос вместе с ключом в процессинг.
  5. Процессинг шифрует данные карты этим ключом и возвращает зашифрованные данные в RBS.
  6. Для дополнительной проверки RBS инициирует SMS-OTP, чтобы подтвердить, что запрос был отправлен с привязанного к клиенту номера телефона.
  7. После успешной проверки зашифрованные данные передаются клиентскому приложению.Приложение расшифровывает их закрытым ключом и показывает пользователю один раз, не сохраняя на устройстве.
  8. В течение сессии может использоваться та же ключевая пара для последующих запросов.

Почему не подходит:

  • Проблемы с производительностью.     Генерация пары RSA-ключей достаточной длины (3072 бит и выше) на клиентском устройстве занимает сотни миллисекунд или даже секунды. Пользователь, который сразу после входа запросит данные карты, получит заметную задержку, что ухудшает опыт работы с сервисом.
  • Риск MITM со стороны RBS.     Система RBS выступает посредником между клиентом и процессингом и теоретически способна подменить открытый ключ клиента своим собственным.
  • Нарушение требований PCI DSS по SAD. Даже в зашифрованном виде CVV2 покидает пределы CDE и оказывается на стороне клиента. Это противоречит требованию 3.3.1, запрещающему хранение Sensitive Authentication Data после авторизации. Корректный подход — никогда не извлекать CVV2 за пределы процессинга.

Вариант 3. Использование виртуального HSM на стороне клиента

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

Как это работает:

  1. На этапе первичной настройки или выдачи карты клиент через RBS инициирует регистрацию vHSM. Внутри защищённой среды vHSM на устройстве генерируется ключевая пара.
  2. Открытый ключ по защищённому каналу передаётся в процессинг и сохраняется в CDE, где он привязывается к карте клиента.
  3. Когда клиент запрашивает данные карты, RBS перенаправляет запрос в процессинг.
  4. Процессинг в CDE шифрует PAN, срок действия и CVV2 на сохранённом открытом ключе и возвращает зашифрованные данные в RBS. RBS пересылает их в клиентское приложение.
  5. Приложение отправляет пакет в vHSM (плагин или SDK), где данные расшифровываются закрытым ключом.
  6. Результат возвращается в приложение и показывается пользователю однократно. Закрытый ключ остаётся внутри vHSM, а сами данные не сохраняются в открытом виде на устройстве.

Почему не подходит:

  • Нарушение требований PCI DSS. Несмотря на использование vHSM, факт передачи CVV2 за пределы CDE остаётся спорным. Аудитор может квалифицировать это как нарушение требования 3.3.1, так как клиентская среда не относится к CDE и не контролируется банком.
  • Сложность для пользователей и высокая стоимость. Первичная регистрация vHSM требует установки плагинов, настройки и генерации ключей. Для массового клиента этот процесс избыточно сложен, поэтому схема может быть применима в сегменте юридических лиц, но практически не подходит для физлиц.

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