Для B2C-сектора возможность принять оплату картой через терминал либо онлайн — уже давно базовый минимум. Поскольку финансовая сфера очень требовательна к безопасности данных, когда-то международная организация, в которую вошли крупнейшие платежные системы (MasterCard, Visa и ряд других), систематизировала все эти требования в виде международного стандарта PCI DSS.
Существует расхожее мнение, что бизнесу достаточно делегировать функцию приема платежей подрядчикам: онлайн-кассам, облачному провайдеру и т.д., и это автоматически избавляет от лишней ответственности и снимает все обязанности. Давайте разберемся, всегда ли это так на самом деле, и кто за что отвечает?
Всем привет, меня зовут Анастасия Ильханова, я работаю ведущим юрисконсультом в Cloud.ru. Мне частенько приходится взаимодействовать с потенциальными клиентами на стадии согласования договора и отвечать на вопросы о наших сертификатах и лицензиях, в том числе о PCI DSS. До этого я работала с электронной коммерцией, где тоже периодически возникали вопросы, касающиеся платежных данных. Поэтому моя статья адресована в первую очередь компаниям, которые используют облако, при этом продают что-то онлайн и принимают платежи онлайн самостоятельно, без посредников. Но обо всем по порядку.
Теория: что такое PCI DSS
PCI DSS (Payment Card Industry Data Security Standard) — это международный стандарт, содержащий свод технических, организационных и других требований информационной безопасности для всех, кто обрабатывает данные платежных карт. К таким данным относятся сведения:
о держателях карт: основной номер держателя карты, номер самой карты, имя держателя, срок действия, сервисный код;
а также критичные аутентификационные данные: данные магнитной полосы и чипа, ПИН-код, CVV/ CVC и другие трехзначные коды безопасности.
Теперь пару слов о правовом статусе PCI DSS. Конечно, он не является нормативно-правовым актом, и ни в одном законе или постановлении Правительства вы не найдете прямого упоминания и ссылки на него. Тем не менее, его обязательность реализована через условия в договорах эквайринга между банками и клиентами. То есть, все устроено зеркально: исполнение требований PCI DSS является обязательным изначально для самого банка, так как при заключении договора на обслуживание с любой из платежных систем любой банк обязан выполнять требования этого стандарта.
За невыполнение требований банк будет нести ответственность: уплачивать штрафы, неустойки и т.д. В каждой платежной системе есть своя матрица штрафов. К примеру, у VISA когда-то за первое нарушение давалось предупреждение, потом штраф в размере $1 000, а далее штрафы росли в геометрической прогрессии вплоть до десятков тысяч долларов. Соответственно, в договорах между банком и клиентом эта ответственность также предусмотрена. Банк заинтересован в том, чтобы в случае наступления инцидента и взыскания с него штрафа платежной системой иметь возможность взыскать штраф с клиента, если на его стороне имели место нарушения стандарта.
Также содержание стандарта пересекается с Положением Банка России от 17.08.2023 N 821-П и ГОСТ Р 57580.1-2017, а также с законодательством о персональных данных: если данные платежной карты (будучи привязанными к конкретному физлицу) утекут, это повлечет административную или уголовную ответственность.
Для наглядности привожу выдержку из Программы безопасности Платежной системы «Мир» (неотъемлемая часть правил платежной системы), где есть прямые ссылки на PCI DSS:
Есть в них и раздел об ответственности, из которого прямо следует, что нарушение требований обеими сторонами, в т.ч. несоблюдение требований PCI DSS, влечет применение санкций:
И еще в качестве примера покажу выдержку из договора на эквайринг одного из системообразующих банков:
Таким образом, нарушение требований PCI DSS грозит компании штрафами от платежных систем, потерей возможности принимать оплату через карты и судебным разбирательством в случае утечки данных.
В актуальной версии стандарта описаны четыре уровня соблюдения PCI DSS в зависимости от объема операций с картами. Каждому уровню соответствуют определенные требования к процессу сертификации: если объем платежей минимален, достаточно заполнить лист самооценки и предоставить его обслуживающему банку-эквайеру, а для 1 и 2 уровня уже нужен полноценный внешний аудит сертифицированной аудиторской компанией.
Но все эти детали относятся больше к информационной безопасности, мне же как юристу интереснее и привычнее оперировать понятиями обязанностей и ответственности.
Для удобства я решила сделать две вещи:
Разделить клиентов облачного провайдера на категории в зависимости от того, как они принимают платежи, чтобы проанализировать, кому из них все же нужно облако с сертификатом, и кто что из них должен в разрезе PCI DSS;
Посмотреть поближе на распределение ответственности между облачным провайдером и клиентом.
Как клиенты облака принимают платежи и кому из них нужен PCI DSS
Выставляют счет по электронной почте
Покупатель получает письмо, переходит по ссылке на страницу оплаты и совершает платеж. Для этого никаких дополнительных действий в рамках PCI DSS не требуется.
Проводят оплату через POS-терминал
Такие компании могут использовать облако, но при этом оплату принимают только физически с помощью POS-терминалов. Им стандарт предписывает соблюдать правила физической безопасности (раздел 9 PCI DSS), заполнять листы самооценки и т.д., но детальнее углубляться в это нет смысла. Для целей этой статьи эта категория нас интересует мало, т.к. тема все-таки связана с облачными технологиями.
Принимают платежи в облаке через третьи лица
Третьи лица здесь — это платежные агрегаторы (например, ЮKassa, Робокасса, Тинькофф Касса и т.д.) или банки, которые, в свою очередь, сами уже имеют сертификат безопасности PCI DSS и несут ответственность за сохранность платежных данных. Клиенты сами эти данные никак не видят, не обрабатывают и не хранят, все данные покупатель вводит на странице онлайн-кассы или банка.
Тут, казалось бы, все просто: услуга полностью делегирована, у платежного агрегатора есть сертификат PCI DSS нужного уровня, у облака тоже есть, и самому клиенту можно как будто бы не думать об этом. Но минимальные требования все же существуют: такому клиенту нужен SAQ (Self-Assessment Questionnaire — анкета самооценки) для подтверждения соответствия стандарту PCI DSS, таковы требования платежных систем (Visa, Mastercard, Мир) и банков-эквайеров.
Какой именно тип SAQ нужен, зависит от того, как именно принимаются платежи: подробнее об этом можно прочесть в самих требованиях PCI DSS, либо на сайте НСПК.
Принимают оплату банковскими картами на сайте
Такие клиенты в рамках статьи представляют наибольший интерес: они принимают оплату картами напрямую на своих сайтах или являются сервис-провайдерами в терминологии PCI DSS. У таких клиентов есть собственные платежные страницы для сбора данных карт непосредственно через свой сайт: покупатель вводит номер карты, срок действия и CVV-код прямо в поля на сайте компании, и только потом данные отправляются в банк.
И вот тут PCI DSS обязателен уже в полной мере как для клиента (в зависимости также от объема транзакций в год), так и для облака (если инфраструктура клиента в облаке).
Смысл использования облака при таком сценарии в том, что услуги облачного провайдера с сертификатом снимают с бизнеса часть задач по аттестации собственного оборудования (серверов и проч.), экономит время и сокращает затраты на аудит.
Тут уже уместно говорить о распределении ответственности в разрезе PCI DSS.
Кто отвечает за PCI DSS — облачный провайдер или клиент
Многие наши клиенты — пользователи облачной платформы Cloud.ru Evolution. По сути, это публичное облако, в котором есть IaaS- и PaaS-сервисы, с ними можно построить как очень простую, так и очень сложную инфраструктуру. И эта инфраструктура будет отвечать требованиям PCI DSS, потому что им отвечает само облако.
Надо понимать, что ответственность за соблюдение стандарта не перекладывается полностью на облачного провайдера, а делится между ним и клиентом. С Cloud.ru Evolution ситуация аналогичная: детальное распределение ответственности зависит от продукта и модели сервиса. Все четко указано в матрице.
Глобально разделение ответственности за выполнение большинства требований каждого раздела PCI DSS зависит от модели использования облачных сервисов: IaaS, PaaS или SaaS. В рамках модели IaaS облачный провайдер всегда сам обеспечивает безопасность физических ЦОД и базового виртуального слоя (гипервизора), все остальное — контроль доступа к виртуальной инфраструктуре, дополнительные средства шифрования и т.д. — клиент настраивает самостоятельно, тем самым управляя частью среды.
В моделях PaaS и SaaS уровень «готовности» сервисов выше и, соответственно, меньше зона технической ответственности клиента, но даже в таком случае за доступ пользователей, конфиденциальность и логику работы с данными, дополнительное шифрование, аутентификацию внутри приложения всегда отвечает только сам клиент.
А вот за соблюдение требований в части предоставления механизмов управления доступом, обеспечивающих изоляцию разных клиентов, и разграничения сред разных клиентов, всегда вне зависимости от модели сервиса отвечает провайдер.
Важный момент: в любой ситуации провайдер не имеет доступа к информации, хранящейся в тенанте клиента. Если клиент по каким-то причинам хранит у себя те данные, которые PCI DSS в принципе запрещает хранить после проведения транзакции где бы то ни было (например, CVV-коды), и если неправомерный доступ в тенант клиента произошел ввиду нарушения клиентом договора с провайдером (например, если были скомпрометированы аутентификационные данные), то ответственным за утечку этих данных будет сам клиент. Если же клиент неправомерно хранил данные, но доступ в тенант произошел по вине провайдера, ответственность несут оба: провайдер – за нарушение договора оказания своих услуг, клиент – за нарушение PCI DSS и, вероятно, за нарушение 152-ФЗ (в зависимости от состава «утекших» данных).
Например, если клиент, относящийся к 4 категории, развернул в облаке свое приложение и через него принимает оплату, не прибегая ни к каким онлайн-кассам и иным посредникам, он отвечает за регулярное проведение внешних ASV-сканирований, внутренних сканирований безопасности и pentest, а также устранение найденных уязвимостей для самих компонентов, развернутых в облаке Cloud.ru Evolution. Провайдер же в таком случае тоже будет проводить сканирования, но только тех системных компонентов, которые обеспечивают функционирование клиентских сервисов.
Если клиент не обеспечил какое-то периодическое ASV-сканирование и в результате этого сертификат PCI DSS был отозван или прекратил действие без продления, произошла компрометация данных — отвечать за это будет клиент. Если то же самое имело место на стороне провайдера — провайдер будет нести ответственность перед клиентом в рамках договора и возмещать убытки.
Вообще во всех ситуациях, когда по вине облачного провайдера ущерб возникает у клиента, эти убытки подлежат компенсации провайдером. Детали при этом зависят от содержания договора: кто-то ограничивает ответственность, кто-то нет.
Если посмотреть на ситуацию с платежными данными сквозь призму ФЗ «О персональных данных», то платежные данные, если они связаны с конкретным физическим лицом, являются персональными данными. И если клиент собирает персональные данные и собирается хранить их в облаке, то именно он, а не облачный провайдер, будет оператором персональных данных по смыслу законодательства. То есть именно пользователь облака определяет политику обработки ПДн, получает от своих клиентов подписанные согласия на обработку, несет иную ответственность в рамках законодательства о персональных данных как оператор. Провайдер же помогает оператору тем, что обеспечивает соответствие требованиям закона облачной инфраструктуры, в которой размещаются данные.
Если вы обрабатываете платежные данные в сертифицированном облаке, вам все равно придется проходить аудит PCI DSS, внедрять необходимые меры, регулярно сканировать сеть на уязвимости.
Аудит проходит в несколько этапов:
определение области оценки;
инвентаризация всех систем и оценка уровня соответствия требованиям PCI DSS;
предварительный аудит (по желанию);
ASV-сканирование, тестирование на проникновение (пен-тест);
устранение несоответствий;
финальный аудит.
Сертификационный аудит могут проводить организации, имеющие статус QSA и находящиеся в Списке квалифицированных аудиторов по безопасности. Стоимость полной сертификации начинается от 500 000 рублей и может превышать 1,5 миллиона, плюс ежегодные расходы на поддержание соответствия.
Важно отметить, во-первых, что при аудите во внимание берется не только то, что «на бумаге», но и проверяется, как конкретно те или иные меры реализованы на практике. Когда мы сами проходили сертификацию, то предоставляли аудиторам даже статистические данные о прохождении сотрудниками курсов по информационной безопасности. Во-вторых, важно понимать, что процедуру сертификации проходит не столько облако и «железо», а организация: никакое дорогостоящее и формально соответствующее всем требованиям оборудование, защищенные сети и т.д. не обеспечивает по умолчанию безопасность и соответствие всем правилам. Нужна еще большая зрелость внутренних процессов компании, организационные и юридические аспекты также должны быть на должном уровне.
Александр Юдин, руководитель проектов Cloud.ru
Как проверить подлинность сертификата
Допустим, вы выбрали сертифицированное облако или платежный агрегатор. Как удостовериться в том, что представленные документы достоверны, если единой базы выданных сертификатов PCI DSS просто нет?
Проверка подлинности строится на запросе и анализе официальных документов, подтверждающих соответствие. Поэтому остается проверять детали в самом документе: подписан ли документ уполномоченным QSA-аудитором, не истек ли срок действия сертификата, включает ли область проверки (Scope) именно те сервисы или программные продукты, которые планируется использовать.
Можно также проверить статус аудитора или провайдера на официальном сайте PCI DSS. Если он также предоставляет услуги сканирования, можно проверить его в Списке одобренных ASV-вендоров PCI SSC.
Если даже после указанных проверок остались сомнения, можно направить запрос в аккредитованную аудиторскую компанию.
Необходимо также упомянуть о таких документах, как ROC и AOC.
ROC (Report on Compliance) — это технический отчет о соответствии, в котором подробно описывается, как именно инфраструктура и процессы компании соответствуют каждому из 12 требований PCI DSS. Описание систем, результаты сканирования уязвимостей, скриншоты, конфигурации и доказательства безопасности — это все содержится в нем. Это строго конфиденциальный внутренний документ организации и аудиторов, его не передают клиентам или партнерам.
А вот AOC (Attestation of Compliance) — это краткое резюме отчета ROC. Он содержит сводную информацию о компании, проверяемых системах и итоговый вердикт: соответствует или не соответствует требованиям стандарта PCI DSS. Выписку из него, как правило, можно получить банкам-эквайерам, платежным системам, а также партнерам или клиентам по запросу на основании NDA.
Какие выводы можно сделать
Я бы сказала, что главных вывода два.
Если вы принимаете платежи в облаке онлайн, но эта услуга делегирована третьим лицам:
убедитесь в подлинности сертификата PCI DSS вашего посредника;
корректно отразите все моменты, связанные с порядком оплаты, в вашей оферте/пользовательском соглашении и политике обработки персональных данных, четко и достоверно объясните вашим клиентам, какие данные вы обрабатываете, а к каким у вас доступа нет;
заполните лист самооценки согласно требованиям стандарта.
Если вы обрабатываете платежные данные в облаке самостоятельно и это никому не делегировано:
убедитесь в подлинности сертификата PCI DSS вашего провайдера;
определите, к какой категории из перечисленных в PCI DSS, вы относитесь, заполните листы самооценки или пройдите полноценный аудит;
корректно отразите все моменты, связанные с обработкой платежных данных, во всех ваших документах с клиентами: оферте/пользовательском соглашении, политике обработки персональных данных;
при возникновении любых технических вопросов о реализации конкретных мер PCI DSS – задайте их напрямую аудитору, провайдеру или НСПК.