> ## Content Index
> Fetch the complete content index at: https://admin.kod.ru/llms.txt
> Use this file to discover other available public pages before exploring further.

# Показ реквизитов карты в ДБО: архитектурная задача и пути реализации
- URL: https://admin.kod.ru/rekviziti-karti-v-dbo-zadacha-otp-bank/
- Published: 2025-09-29T09:50:36.000Z
- Updated: 2025-09-29T09:51:53.000Z
- Description: Команда ОТП Банка провела архитектурное исследование, посвящённое тому, как безопасно передавать и отображать карточные данные клиента из процессинга на устройстве, не выходя за рамки PCI DSS.
- Author: OTP Bank
- Tags: Блоги

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

Команда ОТП Банка провела архитектурное исследование, посвящённое тому, как безопасно передавать и отображать карточные данные клиента из процессинга на устройстве, не выходя за рамки 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 нельзя сохранять ни при каких условиях, так как именно он несёт наибольший риск компрометации.

![](https://admin.kod.ru/content/images/2025/09/image-56.png)

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

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

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

![](https://admin.kod.ru/content/images/2025/09/image-57.png)

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

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.

![](https://admin.kod.ru/content/images/2025/09/image-58.png)

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

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, этот подход выглядит более строгим с точки зрения безопасности. Ключевое преимущество в том, что закрытый ключ генерируется и хранится только на стороне клиента. Таким образом, расшифровка выполняется исключительно на его устройстве, а банковские системы работают лишь с зашифрованными данными.

![](https://admin.kod.ru/content/images/2025/09/image-59.png)

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

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, где закрытый ключ генерируется и хранится.

![](https://admin.kod.ru/content/images/2025/09/image-60.png)

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

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 требует установки плагинов, настройки и генерации ключей. Для массового клиента этот процесс избыточно сложен, поэтому схема может быть применима в сегменте юридических лиц, но практически не подходит для физлиц.

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