Архитектурные задачи в финтехе редко бывают простыми. На стыке технологий, требований безопасности и ожиданий бизнеса приходится искать такие решения, которые одновременно отвечают стандартам индустрии и не ломают пользовательский опыт.
Команда ОТП Банка провела архитектурное исследование, посвящённое тому, как безопасно передавать и отображать карточные данные клиента из процессинга на устройстве, не выходя за рамки 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.
Как это работает: Пользователь инициирует просмотр реквизитов в ДБО (RBS). RBS проводит усиленную аутентификацию, например через OTP по SMS, и выполняет её параллельно остальным шагам. RBS создаёт одноразовый высокоэнтропийный токен доступа и передаёт его клиентскому приложению. SRS запрашивает у процессинга актуальные реквизиты карты, формирует страницу или изображение с данными и регистрирует готовый контент в Secure Content Delivery Proxy (SCDP) в сегменте Connected-to, привязывая его к токену. Клиентское приложение, имея токен, обращается к SCDP. SCDP дожидается поступления контента от SRS и по защищённому TLS отдаёт его клиенту в виде iFrame. Браузер отображает 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.
Как это работает: Пользователь запрашивает данные через RBS (ДБО). RBS генерирует одноразовый ключ (OTP) и отправляет его в процессинг. Процессинг шифрует данные карты этим ключом и возвращает результат в RBS. RBS передаёт ключ клиенту по SMS и вместе с ним отправляет зашифрованные данные. На устройстве клиента данные расшифровываются. Почему не подходит: Слабый уровень защиты. 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, этот подход выглядит более строгим с точки зрения безопасности. Ключевое преимущество в том, что закрытый ключ генерируется и хранится только на стороне клиента. Таким образом, расшифровка выполняется исключительно на его устройстве, а банковские системы работают лишь с зашифрованными данными.
Как это работает: После входа в RBS клиентское приложение или браузер генерирует пару ключей (открытый и закрытый) для текущей сессии. Закрытый ключ хранится в памяти устройства и не передаётся наружу. При запросе данных карты приложение добавляет к нему свой открытый ключ. RBS пересылает запрос вместе с ключом в процессинг. Процессинг шифрует данные карты этим ключом и возвращает зашифрованные данные в RBS. Для дополнительной проверки RBS инициирует SMS-OTP, чтобы подтвердить, что запрос был отправлен с привязанного к клиенту номера телефона. После успешной проверки зашифрованные данные передаются клиентскому приложению.Приложение расшифровывает их закрытым ключом и показывает пользователю один раз, не сохраняя на устройстве. В течение сессии может использоваться та же ключевая пара для последующих запросов. Почему не подходит: Проблемы с производительностью. Генерация пары RSA-ключей достаточной длины (3072 бит и выше) на клиентском устройстве занимает сотни миллисекунд или даже секунды. Пользователь, который сразу после входа запросит данные карты, получит заметную задержку, что ухудшает опыт работы с сервисом.Риск MITM со стороны RBS. Система RBS выступает посредником между клиентом и процессингом и теоретически способна подменить открытый ключ клиента своим собственным.Нарушение требований PCI DSS по SAD. Даже в зашифрованном виде CVV2 покидает пределы CDE и оказывается на стороне клиента. Это противоречит требованию 3.3.1, запрещающему хранение Sensitive Authentication Data после авторизации. Корректный подход — никогда не извлекать CVV2 за пределы процессинга.Вариант 3. Использование виртуального HSM на стороне клиента После схемы с асимметричным шифрованием можно рассмотреть ещё один подход. В нём криптографические операции выполняются не в браузере, а во встроенной доверенной среде устройства — виртуальном HSM. В таком случае данные карты шифруются в процессинге на заранее зарегистрированный открытый ключ клиента, а расшифровка происходит внутри vHSM, где закрытый ключ генерируется и хранится.
Как это работает: На этапе первичной настройки или выдачи карты клиент через RBS инициирует регистрацию vHSM. Внутри защищённой среды vHSM на устройстве генерируется ключевая пара. Открытый ключ по защищённому каналу передаётся в процессинг и сохраняется в CDE, где он привязывается к карте клиента. Когда клиент запрашивает данные карты, RBS перенаправляет запрос в процессинг. Процессинг в CDE шифрует PAN, срок действия и CVV2 на сохранённом открытом ключе и возвращает зашифрованные данные в RBS. RBS пересылает их в клиентское приложение. Приложение отправляет пакет в vHSM (плагин или SDK), где данные расшифровываются закрытым ключом. Результат возвращается в приложение и показывается пользователю однократно. Закрытый ключ остаётся внутри vHSM, а сами данные не сохраняются в открытом виде на устройстве. Почему не подходит: Нарушение требований PCI DSS. Несмотря на использование vHSM, факт передачи CVV2 за пределы CDE остаётся спорным. Аудитор может квалифицировать это как нарушение требования 3.3.1, так как клиентская среда не относится к CDE и не контролируется банком.Сложность для пользователей и высокая стоимость. Первичная регистрация vHSM требует установки плагинов, настройки и генерации ключей. Для массового клиента этот процесс избыточно сложен, поэтому схема может быть применима в сегменте юридических лиц, но практически не подходит для физлиц.Наш разбор ещё раз показал, что в финтехе не существует простых решений. То, что кажется очевидным и быстрым, на практике часто приводит к ошибкам или нарушению стандартов. Именно поэтому нужен тщательный анализ, который позволяет выбрать рабочие решения и построить систему, соответствующую требованиям и устойчивую в долгосрочной перспективе.
Комментарии