Привет, Хабр! Я работаю на должности главного солюшн архитектора трайба в ОТП Банке. В своей работе часто сталкиваюсь с интересными архитектурными вызовами, которые возникают на стыке технологий, безопасности и бизнес-требований. Часть из них я уже описал в предыдущей статье, посвященной интеграции системы дистанционного банковского обслуживания (RBS) с бэкофисом (Event-Driven Architecture в высоконагруженном ДБО: наш опыт.)

В этой статье я проведу архитектурное исследование возможных вариантов реализации получения карточных данных клиента из процессинга с последующим отображением этих данных на устройстве клиента, не нарушая требований стандарта PCI DSS (Payment Card Industry Data Security Standard). Этот стандарт является ключевым для любой организации, работающей с платежными картами, и его несоблюдение может привести к серьезным последствиям, включая штрафы от платежных систем (до миллионов долларов), потерю доверия клиентов и даже приостановку операций.

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

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

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

• Запрещено хранить и обрабатывать данные платежных карт (cardholder data) вне зоны CDE (Cardholder Data Environment) - это сегментированная среда, где такие данные могут быть защищены.

• Запрещен прямой доступ к системам в CDE; взаимодействие должно осуществляться через интеграционные системы в сегменте Connected-to, которые обязаны проводить автоматический анализ на наличие запрещенных к передаче данных, чтобы минимизировать риски утечек.

• CVV/CVV2 являются вычисляемыми значениями и не могут храниться даже в системах зоны CDE после авторизации транзакции. При этом CVV2 (статический код на обороте карты) представляет наибольший риск и его хранение запрещено в любом случае после завершения авторизации.

• Вне зоны CDE допускается оперировать только маскированным PAN (Primary Account Number), таким как PPAN (Pseudo PAN), DPAN (Digital PAN) или аналогичными (терминология может варьироваться в зависимости от банка), что позволяет идентифицировать карту без раскрытия полного номера.

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

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

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

Порядок действий в этом подходе выглядит так:

1. Клиент запрашивает данные по своей карте через RBS (ДБО).

2. RBS генерирует одноразовый ключ (OTP) и отправляет его в процессинг.

3. Процессинг шифрует данные карты (PAN, CVV2, срок действия) этим ключом и возвращает зашифрованные данные в RBS.

4. RBS отправляет ключ клиенту по SMS и передает зашифрованные данные на устройство клиента (например, в мобильное или web приложение).

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

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

1. Недостаточная криптостойкость OTP и уязвимость канала SMS.

    *   Стандартный SMS-OTP состоит всего из 4–6 цифр, что делает его крайне уязвимым к brute-force атакам (перебору). Взлом такого ключа силами современного мобильного устройства измеряется секундами.

    *   Канал SMS сам по себе небезопасен: он уязвим к перехвату (MITM-атаки), SIM-своппингу. Требование PCI DSS 8.3.1 прямо предписывает использовать безопасные каналы для передачи аутентификационных данных.

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

2. Компрометация RBS и неконтролируемое расширение периметра CDE.

    *   В данной схеме система RBS одновременно получает и зашифрованные данные, и ключ для их расшифровки. Это означает, что в системе теоретически существует момент, когда возможна расшифровка данных. Согласно PCI DSS Guidance, любая система, которая может повлиять на безопасность данных держателей карт (CHD) или имеет к ним подключение, попадает в область действия стандарта.

    *   Фактически, это автоматически включает всю систему RBS в зону CDE. Последствия этого драматичны: весь комплекс RBS должен будет соответствовать всем строжайшим требованиям PCI DSS (сегментация сети, ежегодный аудит SAQ D, мониторинг, политики безопасности и т.д.), что влечет за собой колоссальные операционные и финансовые издержки. Невыполнение требований для вновь образованной CDE-зоны грозит многомиллионными штрафами от платежных систем.

3. Прямое нарушение запрета на хранение Sensitive Authentication Data (SAD).

    *   Самое критичное нарушение - передача и потенциальное хранение кода CVV2 даже в зашифрованном виде за пределами защищенной среды процессинга. Требование PCI DSS Requirement 3.3.1 категорически запрещает хранение данных SAD (к которым относится CVV2) после авторизации транзакции даже в зашифрованном виде. Сам факт такой передачи является грубейшим нарушением.

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

Вариант 2: Использование асимметричного шифрования на клиенте

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

Последовательность операций в данном подходе:

1. После успешной аутентификации в RBS клиентское приложение или браузер генерирует пару ключей (открытый и закрытый) для текущей сессии. Закрытый ключ хранится в памяти устройства (например, в Session Storage) и никуда не передается.

2. При запросе данных карты клиентское приложение включает в запрос свой открытый ключ.

3. RBS перенаправляет запрос вместе с открытым ключом в процессинг.

4. Процессинг шифрует данные карты (PAN, CVV2, срок действия) полученным открытым ключом и возвращает зашифрованные данные в RBS.

5. RBS, стремясь добавить фактор аутентификации, инициирует дополнительную проверку через OTP-код по SMS, чтобы подтвердить, что запрос инициирован с привязанного к клиенту номера телефона.

6. После успешной проверки OTP RBS передает зашифрованные данные клиентскому приложению.

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

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

1. Производительность и пользовательский опыт (UX).

    *   Генерация пары RSA-ключей достаточной длины (рекомендуется 3072 бит) в браузере или мобильном приложении - это ресурсоемкая операция, вызывающая заметные задержки (сотни миллисекунд или даже секунды). Если клиент сразу после входа запросит данные, он столкнется с длительным ожиданием, что негативно скажется на его опыте и может привести к оттоку.

2. Критический риск атаки «человек посередине» (MITM) со стороны RBS.

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

Сценарий атаки: RBS принимает открытый ключ от клиента, но вместо его пересылки в процессинг подставляет свой собственный открытый ключ. Процессинг честно шифрует данные ключом RBS и возвращает зашифрованные данные. RBS легко расшифровывает ее своим закрытым ключом, получая данные в чистом виде. Затем RBS зашифровывает данные настоящим* открытым ключом клиента и отправляет ему. Для клиента процесс выглядит корректным.

    *   Последствие: Данный сценарий означает, что RBS получает доступ к данным карты в незашифрованном виде. Согласно PCI DSS Requirement 4.1 и принципам определения периметра, это автоматически переклассифицирует RBS в зону CDE, со всеми вытекающими последствиями.

3. Нарушение принципа минимизации хранения SAD.

    *   Несмотря на шифрование, сам факт передачи CVV2 за пределы CDE (пусть и в зашифрованном виде для стороннего субъекта - клиента) может быть трактован аудитором как нарушение требования 3.3.1, которое запрещает хранение Sensitive Authentication Data после авторизации. Безопаснее и корректнее никогда не извлекать CVV2 из CDE вообще.

Вывод: Хотя этот подход технологически сложнее первого, он не решает главной проблемы - риска компрометации данных на промежуточном звене (RBS). Архитектура, допускающая потенциальную возможность MITM-атаки со стороны внутренней системы, не может считаться безопасной и не соответствует духу и букве PCI DSS, который предписывает использовать методы, исключающие саму возможность несанкционированного доступа, а не полагаться на доверие к системам.

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

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

Суть: Чувствительные данные шифруются в процессинге на заранее зарегистрированный и верифицированный открытый ключ клиента. Расшифровка происходит внутри изолированной vHSM-среды на устройстве клиента, куда закрытый ключ не импортируется, а генерируется и хранится внутри нее.

Последовательность операций:

1. (Предварительный этап) При первичной настройке или выдаче карты клиент через RBS инициирует регистрацию vHSM. На его устройстве генерируется ключевая пара внутри защищенной среды vHSM. Открытый ключ по защищенному каналу передается в банк и сохраняется в CDE (процессинге), привязываясь к учетной записи и карте клиента.

2. Клиент запрашивает данные карты в RBS. RBS перенаправляет запрос в процессинг.

3. Процессинг в CDE шифрует данные карты (PAN, срок действия, CVV2) на сохраненном открытом ключе конкретного клиента и возвращает шифрованные данные в RBS.

4. RBS передает зашифрованный пакет клиентскому приложению.

5. Клиентское приложение перенаправляет полученную зашифрованные данные на обработку в vHSM (плагин/SDK).

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

Критика подхода и практические ограничения

Хотя эта архитектура технологически закрывает уязвимость MITM (RBS не может подменить ключ, так он заранее известен процессингу), она сталкивается с непреодолимыми практическими и организационными барьерами.

1. Ухудшение пользовательского опыта (UX) и высокая стоимость внедрения.

    *   Процесс первоначальной регистрации vHSM крайне сложен для рядового пользователя (установка плагинов, настройка, генерация ключей). Поэтому он может быть актуален лишь для клиентов ЮЛ (юридические лица), которые обычно уже используют HSM для входа в RBS и подписания платежных документов. Для ФЛ (физлиц) обычно этот функционал не нужен.

2. Нарушение принципа минимизации хранения SAD и вопросы соответствия.

    *   Главная проблема: Сам факт передачи CVV2 (даже в зашифрованном виде) за пределы CDE для конечного субъекта (клиента) является спорным с точки зрения требования PCI DSS 3.3.1. Аудитор может счесть, что это нарушает принцип запрета на хранение SAD после авторизации, так как клиентская среда не контролируется банком и не является частью CDE. Безопаснее вообще не извлекать CVV2 из-под контроля банка.

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

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

Данный подход напрямую следует рекомендациям PCI DSS и является отраслевым best practice для безопасного отображения чувствительных данных. Его суть заключается в том, что компонент, отвечающий за рендеринг конфиденциальной информации, полностью располагается внутри защищенной среды CDE, а клиенту передается только ссылка для его встраивания (iframe). Данные карты никогда не покидают периметр CDE.

Последовательность операций:

1. Клиент инициирует запрос на просмотр данных карты в системе ДБО (RBS).

2. RBS выполняет усиленную аутентификацию клиента, например, с помощью OTP по SMS. (Этот шаг выполняется параллельно следующим).

3. RBS генерирует высокоэнтропийный (256 бит) одноразовый токен доступа (session token) и передает его клиентскому приложению.

4. Параллельно: RBS отправляет запрос на генерацию контента в Secure Render Service (SRS) (находится в CDE). Запрос включает в себя одноразовый токен и идентификатор карты.

5. Secure Render Service (SRS) запрашивает у процессинга актуальные данные карты (PAN, срок действия, CVV2).

6. Secure Render Service (SRS) рендерит изображение или HTML-страницу с данными карты и регистрирует этот контент в Secure Content Delivery Proxy(SCDP) (шлюзе в зоне Connected-to), привязывая его к полученному одноразовому токену.

7. Тем временем клиентское приложение, получив токен, направляет запрос на Secure Content Delivery Proxy(SCDP), передавая этот токен.

8. Secure Content Delivery Proxy(SCDP) ожидает, пока от Secure Render Service (SRS) не поступит контент, связанный с переданным токеном. Как только контент готов, Secure Content Delivery Proxy(SCDP) возвращает его клиенту в виде iFrame по защищенному TLS-соединению.

9. Клиентский браузер отображает iFrame с данными, источником которого является ресурс внутри контролируемого банком периметра (Secure Content Delivery Proxy(SCDP)).

Анализ подхода и соответствие PCI DSS

Данная архитектура является надежной и соответствует стандарту, так как:

*   Данные не покидают CDE: Чувствительные данные карты (включая CVV2) остаются внутри защищенной среды (Secure Render Service (SRS) + Процессинг). В зону DMZ и к клиенту передается только готовое изображение или сгенерированная страница.

*   Минимизация рисков: iFrame изолирован от основной DOM страницы RBS, что затрудняет межсайтовые атаки (XSS). Одноразовый токен исключает повторный доступ к данным.

*   Соответствие требованиям: Подход напрямую реализует принцип изоляции CDE и исключает хранение SAD вне ее периметра, удовлетворяя требованиям 3.3.1, 1.2, 1.3.

Критика подхода и практические ограничения

Несмотря на высокую безопасность, архитектура имеет ряд сложностей:

1. Риск таймаута HTTP-запроса. Цепочка взаимодействия (Клиент -> RBS -> Secure Render Service (SRS) -> Процессинг -> Secure Render Service (SRS) -> Secure Content Delivery Proxy(SCDP) -> Клиент) длинна и включает несколько сетевых переходов. Если генерация данных в CDE или их доставка займет больше времени, чем таймаут HTTP-соединения клиента (обычно 30-60 секунд), запрос завершится ошибкой. Это приведет к плохому пользовательскому опыту. Мы частично уйдем от этой проблемы запустив проверку ОТП кода паралельно обработке данных внутри. В 99% случаев для клиента показ будет мгновенен сразу после ввода СМС кода. 

2. Сложность реализации и отладки. Архитектура распределенная, включает несколько компонентов (Secure Render Service (SRS), Secure Content Delivery Proxy(SCDP)). Необходимо обеспечить надежное и безопасное взаимодействие между ними, организовать механизм ожидания в DMZ и очистки невостребованных данных. Это усложняет разработку и поддержку.

3. Зависимость от клиентской сети. Настройки браузеров или корпоративные proxy-серверы на стороне клиента могут блокировать встраивание iFrame из внешнего источника (DMZ), что приведет к невозможности отображения данных.

Вывод: Подход с iFrame является одним из наиболее корректных с точки зрения PCI DSS, поскольку полностью изолирует чувствительные данные в CDE. Однако его реализация требует тщательного проектирования для обеспечения отказоустойчивости и производительности. Необходимо:

*   Реализовать механизм long-polling или webhooks на стороне клиента, чтобы избежать таймаутов 

*   Провести нагрузочное тестирование всей цепочки для выявления и устранения "узких мест".

*   Иметь fallback-сценарий для клиентов, у которых не грузится iFrame.

Заключение

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

В итоге наиболее надёжным и проверенным подходом выглядит вариант с генерацией данных прямо в защищённой зоне (CDE) и отображением через iframe. Это может быть не самое простое решение «под капотом», но зато оно позволяет уверенно отвечать на самые строгие вопросы аудиторов.

Важно помнить, что эта статья — моё личное архитектурное исследование, а не официальное руководство от PCI DSS Officer. Я не являюсь сертифицированным офицером PCI DSS, и мои размышления — это всего лишь попытка разобраться в интересной теме и поделиться выводами. Любые правки, уточнения и особенно рассказы о более элегантных решениях более чем приветствуются в комментариях! ?