Mastercard правила размещения логотипа если компания имеет сертификат pci dss

Обновлено: 09.01.2025

В разделе приведены сценарии выпуска сертификата:

Перед началом интеграции Администратору DSS необходимо:

Выпустить и зарегистрировать на DSS cертификат аутентификации Оператора DSS
Зарегистрировать OAuth-клиента
Подключить к Сервису Подписи модуль взаимодействия с УЦ

Общий подход для Пользователей и Операторов при выпуске сертификата:

Аутентификация на Центре Идентификации
Получение параметров выпуска запроса на сертификат
Создание запроса на сертификат
Подтверждение создания запроса на сертификат (для пользователей)
Установка сертификата

Примечание

Создание запроса на сертификат

Параметры выпуска запроса на сертификат можно получить из политики Сервиса Подписи (метод /policy). Политика Сервиса Подписи содержит:

список параметров Удостоверяющих Центров, подключенных к DSS;
список криптопровайдеров, подключенных к DSS.

Каждый элемент списка параметров УЦ содержит:

Идентификатор УЦ
Тип УЦ
Шаблон различительного имени (Distinguished Name)
Список шаблонов сертификатов
Отображаемое имя

В интерфейсе интегрируемой системы должна быть возможность выбора Удостоверяющего Центра, для которого будет создан запрос на сертификат. Для каждого Удостоверяющего Центра Сервис Подписи передаёт отображаемое имя (DSSCAPolicy -> Name ), которое может быть показано пользователю.

Для выбранного пользователем Удостоверяющего Центра в интерфейсе интегрируемой системы должна отображаться форма для заполнения идентифицирующих данных. Форма составляется в соответстии с шаблоном имени (DSSCAPolicy -> NamePolicy ). У каждого компонента имени в шаблоне есть отображаемое имя ( Name ), строковый идентификатор ( StringIdentifier ) и требование к заполнению ( IsRequired ).

Также на форме создания запроса должен быть отображен спискок шаблонов сертификатов ( EkuTemplates ). Каждый шаблон сертификата имеет отображаемое имя.

Если политика Сервиса Подписи содержит более одного криптопровайдера, необходимо предоставить пользователю возможность выбора.

Данные с формы передаются в метод /requests для создания запроса на сертификат:

Идентификатор Удостоверяющего Центра
Различительное имя
Шаблон сертификата
ПИН-код на закрытый ключ (опционально)
Идентификатор криптопровайдера (опционально)

Данные передаются в структуре CertificateRequest.

Идентификатор Удостоверяющего Центра ( AuthorityId ) является константой. Он может быть получен от Администратора DSS и зафиксирован в настройках интегрируемой системы.

Примечание

Если Удостоверяющий Центр с заданным идентификатором отсутствует в Политике Сервиса Подписи, то либо он недоступен в данный момент, либо был отключен Администратором DSS. Для выяснения причин недоступности Удостоверяющего Центра следует обратиться к Администратору DSS.

Различительное имя может быть передано в двух форматах:

Список пар oid:value ( DistinguishedName )
Строковое представление ( RawDistinguishedName )

Объектные идентификаторы (OID) компонентов имени указаны в шаблоне имени.

Примечание

Строковое представление различительного имени кодируется согласно RFC 1779.

Шаблон сертификата представляет собой набор объектных идентификаторов, которые попадут в расширение Enhanced Key Usage (EKU) запроса на сертификат, или идентификатор шаблона сертификата КриптоПро УЦ 2.0, который попадёт в расширение Certificate Template (1.3.6.1.4.1.311.21.7).

Шаблон передаётся через разные поля запроса на сертификат в зависимости от типа:

Enhanced key usage - передаётся в дополнительных параметрах запроса Parameters в ключе EkuString в формате oid1,oid2. oidN.

Примечание

Данный шаблон используется при создании запроса на сертификат к Удостоверяющему Центру типа 0 (КриптоПро УЦ 1.5) и 2 (Сторонний УЦ).

Certificate Template - передаётся в параметре Template запроса на сертификат.

Примечание

Данный шаблон используется при создании запроса на сертификат к Удостоверяющему Центру типа 1 (КриптоПро УЦ 2.0) и 2 (Сторонний УЦ).

Идентификатор криптопровайдера должен быть задан, если в Политике Сервиса Подписи доступно более одного криптопровайдера. Идентификатор криптопровайдера (DSSCSPPolicy -> GroupId ) передаётся в дополнительных параметрах запроса в ключе GroupId

Создание запроса на сертификат с подтверждением при помощи вторичной аутентификации

При создании запроса на сертификат с подтверждением при помощи вторичной аутентификации требуется выполнить следующую последовательность действий (шагов):

При этом в массиве параметров транзакции метода /transactions должны быть отображены следующие поля запроса на сертификат:

CertificateRequest	Параметры транзакции
AuthorityId	CAId
PinCode	Не используется
Template	CertTemplateOid
DistinguishedName	Не используется
RawDistinguishedName	CertSubjectName
Parameters ->EkuString	EkuString
Parameters ->GroupId	GroupId

Примечание

При создании запроса на сертификат с подтверждением с подтверждением при помощи вторичной аутентификации различительное имя может быть передано только в строковом представлении.

Примеры запросов

Пример запроса с указанием различительного имени в строковом представлении:

Пример запроса с указанием различительного имени в виде набора компонентов:

Пример запроса с указанием шаблона сертификата:

Запрос на сертификат с подтверждением:

Типовые ошибки

Обработка ответа Сервиса Подписи

При успешном создании запроса на сертификат Сервис Подписи в ответе вернёт структуру DSSCertRequest.

Дальнейшее поведение пользователя зависит от значения поля Status в структуре DSSCertRequest и типа УЦ, на котором создавался запрос на сертификат.

ACCEPTED - запрос на сертификат принят и обработан УЦ. В данном случае в поле CertificateID будет записан идентификатор выпущенного сертификата.

REGISTRATION - запрос на сертификат принят в КриптоПро УЦ 2.0 и находится на этапе регистрации пользователя УЦ.

В зависимости от настроек подключения DSS к КриптоПро УЦ 2.0, необходимо:

ожидать одобрения запроса на сертификат Администратором УЦ;
одобрить запрос Оператором DSS.

PENDING - запрос на сертификат находится в обработке.

Если запрос отправлен на КриптоПро УЦ 2.0, то в зависимости от настроек подключения DSS к КриптоПро УЦ 2.0 необходимо:

ожидать одобрения запроса на сертификат Администратором УЦ;
одобрить запрос Оператором DSS.

Если запрос создавался через "Сторонний Удостоверяющий Центр", необходимо:

скачать запрос на сертификат по идентификатору /requests;
передать запроса на сертификат в УЦ;
выпущенный сертификат установить в DSS.

REJECTED - запрос отклонён. Дальнейшая обработка запроса невозможна. Для выяснения причин отклонения запроса необходимо обратиться к Администратору УЦ.

Выпуск сертификата Оператором DSS

Аутентификация Оператора DSS на Центре Идентификации

Для получения AccessToken используется OAuth сценарий с использованием кода авторизации. Подробная информация по протоколу аутентификации: The OAuth 2.0 Authorization Framework

Администратор DSS должен предварительно настроить OAuth клиента на сервере DSS:

создав нового клиента:

измененив настройки существующего клиента:

Примечание

Значение RedirectUri urn:ietf:wg:oauth:2.0:oob:auto говорит серверу DSS о том, что AccessToken необходимо вернуть непосредственно в ответе на запрос клиента. Данное значение используется в тех случаях, когда для клиента трудозатратно открыть слушателя на другом URL.

AccessToken , полученный на шаге 3, позволит Оператору DSS получить Политику Сервиса Подписи.

Для выполнения действий от имени пользователя на Сервисе Подписи необходимо получить делегирующий AccessToken. Делегирующий AccessToken позволит Оператору DSS выпустить сертификат пользователя, просмотреть список сертификатов и запросов пользователя и т.п.

Инициация аутентификации

Конечная точка для аутентификации Оператора DSS: /authorize/certificate

Примеры запросов

Получение кода авторизации

В случае успешной аутентификации

Т.е. в примере используется специальное значение redirect_uri , то клиенту необходимо из заголовка Location извлечь значение параметра code. Значение параметра code будет использовано для получения AccessToken на следующем шаге.

Пример ответа

Типовые ошибки

Получение AccessToken

Для получения маркера доступа используется конечная точка oauth/token.

Пример запроса

В случае успешной аутентификации ответ будет содержать:

access_token - AccessToken, выпущенный Центром Идентификации DSS
token_type - Тип токена
expires_in - Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи.

Примечание

Данный access_token не даёт право Оператору DSS выполнять операции на Сервисе Подписи от имени пользователей. access_token может быть использован для получения Политики Сервиса Подписи.

Получение делегирующего AccessToken

Для получения AccessToken для делегирования используется конечная точка oauth/token. Подробная информация по протоколу получения AccessToken для делегирования: OAuth 2.0 Token Exchange.

grant_type - тип разрешения, в данном сценарии равен urn:ietf:params:oauth:grant-type:token-exchange.
resource – идентификатор Сервиса Подписи.
actor_token - AccessToken, полученный на предыдущем шаге
actor_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
subject_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
subject_token – неподписанный JWT-токен, содержащий логин управляемого пользователя.

В декодированном виде subject_token имеет вид:

Пример кодирования JWT-токена можно посмотреть по ссылке.

Первая часть (до точки) называется header, вторая – payload. Для получения закодированного значения необходимо выполнить следующее преобразование:

Внимание!

Символ “.” в конце получившегося значения является обязательным.

Пример запроса

В случае успешной аутентификации ответ будет содержать:

access_token - делегирующий AccessToken, выпущенный Центром Идентификации DSS
token_type - Тип токена
expires_in - Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи.

Пример ответа

Получение Политики Сервиса Подписи

Пример запроса

Пример ответа

Создание запроса на сертификат

Пример запроса

Согласно параметрам УЦ из Политики Сервиса Подписи Оператор формирует запроса на сертификат.

Пример ответа

Установка сертификата

Сервер вернул запрос на сертификат в поле Base64Request . Запрос на сертификат необходимо передать в Удостоверяющий Центр для выпуска сертификата.

Пример запроса

Пример ответа

Выпуск сертификата Пользователем DSS

Аутентификация пользователя на Центре Идентификации

В примере рассматривается авторизация с использованием учётных данных пользователя (логин/пароль). Подробная информация по протоколу аутентификации: The OAuth 2.0 Authorization Framework

grant_type - тип разрешения, в данном сценарии равен password.
password – пароль пользователя.
resource – идентификатор Сервиса Подписи.

Примечание

В примере значение параметр password оставлено пустым, так как пользователю в качестве первичной аутентификации назначен метод "Только Идентификация"

Примеры запросов

В случае успешной аутентификации ответ будет содержать:

access_token - AccessToken, выпущенный Центром Идентификации DSS
token_type - Тип токена
expires_in - Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи и Сервису Подтверждения Операций.

Этот стандарт должен применяться всеми организациями, которые хранят, обрабатывают и передают данные карт «Мир». К таким организациям относятся и торгово-сервисные предприятия, которые принимают к оплате карты «Мир».

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

Требования

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

Установить и поддерживать конфигурацию межсетевых экранов для защиты данных

Не использовать пароли и другие системные параметры безопасности, заданные производителем по умолчанию

Защищать хранимые данные держателей карт

Шифровать данные держателей карт при их передаче в открытых общедоступных сетях

Защищать все системы от вредоносного ПО и регулярно обновлять антивирусное ПО или программы

Разрабатывать и поддерживать безопасные системы и приложения

Ограничить доступ к данным держателей карт в соответствии со служебной необходимостью

Определять и подтверждать доступ к системным компонентам

Ограничить физический доступ к данным держателей карт

Контролировать и отслеживать любой доступ к сетевым ресурсам и данным держателей карт

Регулярно выполнять тестирование систем и процессов обеспечения безопасности

Разработать и поддерживать политику обеспечения информационной безопасности для всех сотрудников организации

Самооценка PCI DSS

Может проводиться ТСП самостоятельно. ТСП вправе привлекать QSA для помощи в проведении самооценки. QSA должен быть привлечен для проведения оценки ТСП на соответствие набору требований PCI DSS, указанных в соответствующем Листе самооценки (SAQ), если того потребует Банк-эквайрер.

Программа безопасности ПС «Мир» определяет контрольные процедуры по соответствию Участников ПС «Мир» и организаций, с которыми они взаимодействуют, требованиям PCI DSS. Форма подтверждения соответствия зависит от категории организации и ее уровня. Требования к типам и уровням ТСП указаны на странице Программа безопасности. Подтверждение соответствия организаций требованиям Стандарта PCI DSS может выполняться путем проведения сертификационного аудита или проведения самооценки.

Сертификационный аудит в ТСП имеет право проводить организация, имеющая статус Qualified Security Assessor (QSA) и указанная в списке или сертифицированный внутренний аудитор, имеющий статус Internal Security Assessor (ISA) и указанный в списке.

Стандарт PCI DSS подтверждает, что компания отвечает отраслевым требованиям обработки платежей. Требования в 2005 году разработал Совет по стандартам безопасности данных индустрии платежных карт, учрежденный мировыми платежными компаниями — Visa, MasterCard, American Express и другими. Сертификация стала обязательной с 2012 года для организаций, работающих с банковскими картами. Этим документом компания дает понять участникам рынка, что безопасность данных клиентов для нее — на первом месте.

Требования PCI DSS

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

Конкретно это выражено в шести официальных пунктах:

Корпоративная сеть должна быть надежно защищена, а трафик — фильтроваться межсетевыми экранами. Участки, в которых обрабатываются данные клиентов, нужно разбить на изолированные сегменты. Виртуальные машины должны выполнять одну серверную функцию. Это нужно, чтобы на одной ВМ не выполнялось несколько функций, требующих разных степеней защиты. Такая схема затруднит для потенциального взломщика доступ ко всей системе. Пароли в сети должны быть надежными и не стандартными.
Важное требование PCI DSS — информация в сети должна быть надежно зашифрована с помощью ключей не меньше 128 бит.
В организации нужно использовать актуальные антивирусные программы. А процесс обновления уязвимого ПО должен быть документально регламентирован.
Доступ к критически важным частям инфраструктуры — только через многофакторную аутентификацию. Физический доступ к серверам, на которых хранятся данные клиентов должен быть ограничен соответствующими; политиками. И они должны меняться после каждой кадровой перестановки.
Для всех операций в инфраструктуре должны постоянно вестись логи. Это необходимо, чтобы быстро находить следы взломов. Необходимо регулярно тестировать инфраструктуру на предмет уязвимостей.
Нужна описанная корпоративная политика информационной безопасности. Необходимо определить общие принципы и порядок доступа к персональным данным пользователей. Также важно спланировать шаги в случае обнаруженного взлома. Все эти документы необходимо обновлять каждый год, в соответствии с изменениями в компании.

Как получить сертификат PCI DSS

Есть два варианта — самостоятельное заполнение листа самооценки или внешний QSA-аудит. Решить задачу самим разрешается в двух случаях:

сервис-провайдерам, если годовое количество транзакций не превышает 300 тысяч;
мерчантам, если количество транзакций не превышает миллиона в год.

А вот как все пройдет, если нужно обратиться к аудиторам:

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

Можно ли не выполнять требования PCI DSS

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

Можно ли получить сертификат PCI DSS проще и быстрее

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

Разумеется, все будет организовано так, чтобы не отвлекать ваших сотрудников от работы. Кроме того, мы сами много раз проходили такой аудит и досконально знаем этот процесс изнутри. И наши специалисты готовы облегчить этот процесс для вас.

В первую очередь стандарт определяет требования к организациям, в информационной инфраструктуре которых хранятся, обрабатываются или передаются данные платёжных карт, а также к организациям, которые могут влиять на безопасность этих данных. Цель стандарта достаточно очевидна — обеспечить безопасность обращения платёжных карт. С середины 2012 года все организации, вовлечённые в процесс хранения, обработки и передачи ДПК должны соответствовать требованиям PCI DSS, и компании на территории Российской Федерации не являются исключением.

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

Рисунок 1. Определение необходимости соответствия стандарту PCI DSS

Хранятся, обрабатываются или передаются ли данные платежных карт в вашей организации?
Могут ли бизнес-процессы вашей организации непосредственно влиять на безопасность данных платежных карт?

Таблица 1. Верхнеуровневые требования стандарта PCI DSS

Требования стандарта PCI DSS
1. Защита вычислительной сети	7. Управление доступом к данным о держателях карт
2. Конфигурация компонентов информационной инфраструктуры	8. Механизмы аутентификации
3. Защита хранимых данных о держателях карт	9. Физическая защита информационной инфраструктуры
4. Защита передаваемых данных о держателях карт	10. Протоколирование событий и действий
5. Антивирусная защита информационной инфраструктуры	11. Контроль защищённости информационной инфраструктуры
6. Разработка и поддержка информационных систем	12. Управление информационной безопасностью

Если же несколько углубиться, стандарт требует прохождения порядка 440 проверочных процедур, которые должны дать положительный результат при проверке на соответствие требованиям.

Таблица 2. Способы подтверждения соответствия стандарту PCI DSS

Внешний аудит QSA (Qualified Security Assessor)	Внутренний аудит ISA (Internal Security Assessor)	Самооценка SAQ (Self Assessment Questionnaire)
Выполняется внешней аудиторской организацией QSA , сертифицированной Советом PCI SSС.	Выполняется внутренним прошедшим обучение и сертифицированным по программе Совета PCI SSC аудитором .Может быть проведен только в случае, если первично соответствие было подтверждено QSA-аудитом.	Выполняется самостоятельно путём заполнения листа самооценки.
В результате проверки QSA -аудиторы собирают свидетельства выполнения требований стандарта и сохраняют их в течение трёх лёт.	В результате проверки ISA -аудиторы , как и при внешнем аудите, собирают свидетельства выполнения требований стандарта и сохраняют их в течение трёх лёт.	Сбор свидетельств выполнения требований стандарта не требуется.
По результатам проведённого аудита подготавливается отчёт о соответствии — ROC (Report on Compliance).	Самостоятельно заполняется лист самооценки SAQ .

Несмотря на кажущуюся простоту представленных способов, клиенты зачастую сталкиваются с непониманием и затруднениями при выборе соответствующего способа. Примером тому являются возникающие вопросы, приведенные ниже.

Ответы на эти вопросы зависят от типа организации и количества обрабатываемых транзакций в год. Нельзя руководствоваться случайным выбором, поскольку существуют документированные правила, регулирующие, какой способ подтверждения соответствия стандарту будет использовать организация. Все эти требования устанавливаются международными платёжными системами, наиболее популярными из них в России являются Visa и MasterCard. Даже существует классификация, согласно которой выделяют два типа организаций: торгово-сервисные предприятия (мерчанты) и поставщики услуг.

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

Допустим, торгово-сервисное предприятие обрабатывает до 1 млн транзакций в год с применением электронной коммерции. По классификации Visa и MasterCard (рис. 2) организация будет относиться к уровню 3. Следовательно, для подтверждения соответствия PCI DSS необходимо проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV (Approved Scanning Vendor) и ежегодная самооценка SAQ. В таком случае организации не нужно заниматься сбором свидетельств соответствия, поскольку для текущего уровня в этом нет необходимости. Отчётным документом будет выступать заполненный лист самооценки SAQ.

ASV-сканирование (Approved Scanning Vendor) — автоматизированная проверка всех точек подключения информационной инфраструктуры к сети Интернет с целью выявления уязвимостей. Согласно требованиям стандарта PCI DSS, такую процедуру следует выполнять ежеквартально.

Или же рассмотрим пример с поставщиком облачных услуг, который обрабатывает более 300 тысяч транзакций в год. Согласно установленной классификации Visa или MasterCard, поставщик услуг будет относиться к уровню 1. А значит, как указано на рисунке 2, необходимо проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV, а также внешнего ежегодного QSA аудита.

Рисунок 2. Классификация уровней и требования подтверждения соответствия стандарту PCI DSS

Читайте также: