pci compliance что это
PCI DSS
Обзор
Стандарт безопасности данных индустрии платежных карт (PCI DSS) – это проприетарный стандарт в области информационной безопасности. Он находится под административным управлением Совета по стандартам безопасности данных индустрии платежных карт, основанного компаниями American Express, Discover Financial Services, JCB International, MasterCard Worldwide и Visa Inc.
Стандарт PCI DSS распространяется на юридические лица, которые занимаются хранением, обработкой или передачей данных владельцев карт (CHD) или конфиденциальных данных аутентификации (SAD), в том числе на торговые компании, процессинговые центры, эквайеров, эмитентов карт и поставщиков услуг. Стандарт PCI DSS утверждается платежными системами, а его администрированием занимается Совет по стандартам безопасности данных индустрии платежных карт.
Сертификат соответствия требованиям (AOC) PCI DSS и обзор сферы ответственности можно получить с помощью AWS Artifact, портала самообслуживания для доступа по требованию к отчетам AWS по соответствию требованиям. Войдите в раздел AWS Artifact в Консоли управления AWS или см. подробности на странице Начало работы с AWS Artifact.
Получила ли AWS сертификацию PCI DSS?
Да, Amazon Web Services (AWS) является сертифицированным поставщиком услуг PCI DSS Level 1 – самого высокого уровня оценки из существующих. Оценка соответствия проводилась компанией Coalfire Systems Inc., независимым квалифицированным инспектором безопасности (QSA). Сертификат соответствия требованиям (AOC) PCI DSS и обзор сферы ответственности можно получить с помощью AWS Artifact, портала самообслуживания для доступа по требованию к отчетам AWS по соответствию требованиям. Войдите в раздел AWS Artifact в Консоли управления AWS или см. подробности на странице Начало работы с AWS Artifact.
Какие сервисы AWS соответствуют требованиям PCI DSS?
Перечень сервисов AWS, соответствующих требованиям PCI DSS, см. на вкладке PCI на странице Сервисы AWS в программе обеспечения соответствия. Свяжитесь с нами, чтобы получить дополнительную информацию об использовании этих сервисов.
Что это значит для меня, если я являюсь торговой компанией или поставщиком услуг в сфере PCI DSS?
При использовании сервисов AWS для хранения, обработки и передачи данных владельцев платежных карт вы можете полагаться на нашу технологическую инфраструктуру в ходе прохождения собственной сертификации на соответствие требованиям PCI DSS.
AWS не занимается непосредственным хранением, передачей или обработкой данных владельцев карт для своих клиентов. Однако с помощью сервисов AWS клиенты могут создавать собственные среды для данных платежных карт, в которых будут происходить процессы хранения, передачи или обработки данных владельцев платежных карт.
Что это значит для меня, если я не являюсь торговой компанией и не использую PCI DSS?
Даже если у вас нет сертификации PCI DSS, соответствие наших сервисов требованиям PCI демонстрирует нашу приверженность информационной безопасности на всех уровнях. Поскольку соответствие стандарту PCI DSS проверяется независимой сторонней компанией, это означает, что наша программа управления безопасностью является всесторонней и соответствует передовым отраслевым практикам.
Могу ли я как клиент AWS положиться на сертификат соответствия, выданный AWS, или для подтверждения полного соответствия мне необходимо пройти дополнительную проверку?
Клиенты должны проходить собственную сертификацию на соответствие требованиям PCI DSS, поэтому для подтверждения того, что конкретная среда удовлетворяет всем требованиям PCI DSS, может потребоваться дополнительное тестирование. Однако в отношении среды для работы с данными владельцев карт (CDE), развернутой на AWS, квалифицированный инспектор безопасности (QSA) может положиться на сертификат соответствия (AOC), полученный AWS, без дополнительного тестирования.
Как узнать, за какие средства управления PCI DSS ответственность лежит на мне?
Для получения дополнительной информации см. документ с обзором сферы ответственности AWS по обеспечению соответствия требованиям PCI DSS из пакета по соответствию AWS требованиям PCI DSS (доступен с помощью AWS Artifact, портала самообслуживания для доступа по требованию к отчетам AWS по соответствию требованиям). Войдите в раздел AWS Artifact в Консоли управления AWS или см. подробности на странице Начало работы с AWS Artifact.
Где можно получить пакет документов по соответствию AWS требованиям PCI?
Доступ к пакету соответствия AWS PCI можно получить с помощью AWS Artifact, портала самообслуживания для доступа по требованию к отчетам AWS по соответствию требованиям. Войдите в раздел AWS Artifact в Консоли управления AWS или см. подробности на странице Начало работы с AWS Artifact.
Что входит в состав пакета по соответствию AWS требованиям PCI DSS?
Пакет по соответствию AWS требованиям PCI включает:
Входит ли AWS в глобальный реестр поставщиков услуг Visa или в список одобренных поставщиков услуг MasterCard?
Да, AWS входит в глобальный реестр поставщиков услуг Visa и в список одобренных поставщиков услуг MasterCard. Эти списки поставщиков услуг еще раз демонстрируют, что AWS успешно прошла сертификацию на соответствие требованиям PCI DSS и удовлетворяет всем применимым программным требованиям Visa и MasterCard.
Требуется ли для работы по стандарту PCI DSS среда, выделенная для одного клиента?
Нет. Платформа AWS – это виртуальная многопользовательская среда. В AWS реализованы эффективные процессы управления безопасностью, соответствия требованиями PCI DSS и другие средства управления, которые безопасно изолируют клиентов в собственных защищенных средах. Эта безопасная архитектура была протестирована независимым инспектором QSA, который установил, что она соответствует всем применимым требованиям стандарта PCI DSS.
Совет по стандартам безопасности PCI опубликовал документ PCI DSS Cloud Computing Guidelines для клиентов, поставщиков услуг и проверяющих в сфере облачных вычислительных сервисов. В нем описаны возможные модели сервисов и распределение между поставщиками и клиентами ролей и обязанностей в части обеспечения соответствия требованиям.
Требуется ли торговой компании уровня Level 1 предоставлять своим QSA физические схемы ЦОД AWS?
Нет. Сертификат соответствия, выданный AWS, – это показатель всесторонней оценки методов управления физической безопасностью в ЦОД AWS. QSA торговой компании может не проводить проверку безопасности ЦОД AWS.
Поддерживает ли AWS проведение следственных мероприятий?
AWS не считается «Поставщиком совместно используемого хостинга» по стандарту PCI-DSS. Поэтому требование DSS A1.4 неприменимо. Согласно нашей Модели общей ответственности мы предоставляем пользователям возможность проводить следственные мероприятия в собственной среде AWS без дополнительной помощи со стороны AWS. Эта возможность обеспечивается через сервисы AWS и сторонние решения, доступные на AWS Marketplace. Дополнительные сведения см. в следующих ресурсах.
Существует ли специальная среда соответствия PCI DSS, которую необходимо указывать при запуске серверов или загрузке объектов для хранения?
Если используемые сервисы AWS соответствуют требованиям PCI DSS, вся инфраструктура, поддерживающая соответствующие сервисы, удовлетворяет требованиям. Отдельной среды или специального API нет. Любой сервер или объект данных, который развернут в этих сервисах или использует их, находится в среде, соответствующей требованиям PCI DSS, независимо от региона. Перечень сервисов AWS, соответствующих требованиям PCI DSS, см. на вкладке PCI на странице Сервисы AWS в программе обеспечения соответствия.
Признается ли соответствие AWS на международном уровне?
Да. См. новейшую версию AOC PCI DSS на портале AWS Artifact, чтобы получить полный список местоположений, которые соответствуют требованиям.
Является ли стандарт PCI DSS публичным?
Есть ли организации, которые уже прошли сертификацию PCI DSS на платформе AWS?
Да, многие клиенты уже выполнили развертывание в AWS сред для обслуживания владельцев карт (полное или частичное) и успешно сертифицировали эти среды. AWS не раскрывает информацию о клиентах, прошедших сертификацию PCI DSS, но регулярно сотрудничает с клиентами и организациями, выполняющими их оценку на соответствие PCI DSS, в вопросах планирования, развертывания, сертификации и выполнения ежеквартального анализа среды обработки информации о владельцах карт на AWS.
Каким образом компании обеспечивают соответствие PCI DSS?
Существует два основных подхода к ежегодному подтверждению соответствия требованиям PCI DSS. Первый – поручить внешнему квалифицированному инспектору безопасности (QSA) провести оценку связанных частей среды и представить отчет о соответствии требованиям (ROC) и сертификат соответствия (AOC). Такой подход чаще применяется организациями, которые обрабатывают большие объемы транзакций. Второй – заполнить анкету самооценки (SAQ). Этот подход обычно применяется организациями, которые обрабатывают меньшие объемы транзакций.
Важно помнить, что ответственность за поддержание соответствия требованиям несут платежные системы и эквайеры, а не Совет по стандартам безопасности PCI.
Что необходимо для соответствия требованиям PCI DSS?
Ниже приведен краткий обзор требований PCI DSS.
1. Установка и поддержка настроек брандмауэра, необходимых для защиты данных владельцев карт.
2. Замена установленных на заводе системных паролей и прочих параметров безопасности по умолчанию.
3. Защита данных владельцев карт при хранении.
4. Шифрование данных владельцев карт при передаче по открытым публичным сетям.
5. Защита всех систем от вредоносного ПО и регулярное обновление антивирусных программ.
6. Разработка и поддержка безопасных систем и приложений.
7. Ограниченный доступ к данным владельцев карт, строго в рамках практической необходимости.
8. Идентификация и аутентификация доступа к компонентам системы.
9. Ограничение физического доступа к данным владельцев карт.
10. Идентификация и мониторинг всех обращений к сетевым ресурсам и данным владельцев карт.
11. Регулярное тестирование систем и процессов, связанных с безопасностью.
12. Обеспечение политики информационной безопасности в отношении всех сотрудников.
Какой позиции придерживается AWS в отношении дальнейшей поддержки протокола TLS 1.0?
AWS не ведет кампанию по назначению протокола TLS 1.0 устаревшим для всех сервисов, так как некоторым клиентам (не подпадающим под требования PCI) данный протокол требуется. Однако сервисы AWS оценивают воздействие отключения TLS 1.0 на клиентов в индивидуальном порядке и в некоторых случаях могут назначить этот протокол устаревшим. Также клиенты могут использовать конечные точки FIPS, чтобы использовать надежную криптографию. AWS будет обновлять все конечные точки FIPS минимум до версии TLS 1.2. Подробные сведения приведены в этой публикации в блоге.
Каким образом клиент может настроить архитектуру AWS для обеспечения соответствия требованиям PCI к защищенному протоколу TLS?
Все сервисы AWS, соответствующие требованиям PCI, поддерживают TLS 1.1 или более новых версий. Некоторые из этих сервисов также поддерживают TLS 1.0 для клиентов (не подпадающих под требования PCI), которым нужен данный протокол. Клиенты должны самостоятельно обновить свои системы, чтобы обеспечить взаимодействие с сервисами AWS, использующими защищенный протокол TLS, например TLS 1.1 или выше. От клиентов требуется использовать и настроить балансировщики нагрузки AWS (Application Load Balancer или Classic Load Balancer) для защищенного обмена данными по протоколу TLS 1.1 или более новой версии. Для этого им нужно выбрать предопределенную политику безопасности AWS, способную обеспечить обмен данными с применением протокола шифрования между клиентом и балансировщиком нагрузки, например TLS 1.2. К примеру, политика безопасности балансировщика нагрузки AWS ELBSecurityPolicy‑TLS‑1‑2‑2018‑06 поддерживает только TLS 1.2.
Что нужно делать клиенту, если в результатах сканирования отобразится TLS 1.0?
Если сканирование, выполненное утвержденным поставщиком услуг сканирования (ASV) клиента, выявит наличие TLS 1.0 в конечной точке API AWS, это значит, что API все еще поддерживает TLS 1.0, а также TLS 1.1 и более поздние версии. Некоторые сервисы AWS, соответствующие требованиям PCI, по‑прежнему поддерживают TLS 1.0 для клиентов, которым необходим этот протокол для рабочих нагрузок вне сферы PCI. Клиенты могут доказать ASV, что конечная точка API AWS поддерживает TLS 1.1 и более новых версий с помощью инструмента, например Qualys SSL Labs, для определения используемого протокола. Клиенты могут также доказать, что они используют защищенный обмен данными по протоколу TLS, при подключении с помощью балансировщика нагрузки AWS Elastic Load Balancer, который настроен с помощью соответствующей политики безопасности балансировщиков нагрузки AWS, поддерживающей TLS 1.1 или выше (например, ELBSecurityPolicy‑TLS‑1‑2‑2017‑01 поддерживает только v1.2). ASV может потребовать от клиента пройти через процесс спора о наличии уязвимости, и представленные доказательства могут выступить в качестве подтверждения соответствия требованиям. Раннее обращение в ASV и предоставление ему доказательств перед выполнением сканирования также может упростить процесс оценки и поможет успешно пройти сканирование.
Что такое PCI DSS и как происходит проверка на соответствие стандарту?
В конце 2015 года система электронных платежей PayOnline уже в восьмой раз доказала, что мерчанты и плательщики находятся под надежной защитой. А в мае 2016 года компания получила физический сертификат соответствия требованиям стандарта PCI DSS версии 3.1, подтверждающий высший мировой уровень безопасности.
На фоне этого события мы бы хотели подробнее рассказать, что такое PCI DSS, по каким критериям осуществляется проверка на соответствие стандарту и как, не имея собственного сертификата, интернет-магазин может обеспечить безопасность финансовых данных пользователей.
Если попробовать забить аббревиатуру PCI DSS в Google или поискать по ней на Хабре, то можно обнаружить достаточно много статей, описывающих этот стандарт. Тут же выяснится, что целевой аудиторией всех этих материалов будут те, кто так или иначе связан с электронной коммерцией. Главным образом это платёжные агрегаторы и процессинговые центры, а уже потом разработчики интернет-магазинов.
Любой вид электронной коммерции так или иначе основан на том, что покупатели, желающие приобрести товар, должны будут расплатиться за него. Несмотря на то, что возможность расплатиться архаичным способом (отдать деньги курьеру при встрече) наиболее популярна в России, есть большая вероятность, что покупатель предпочтет воспользоваться своей платёжной картой. Тут разработчикам магазина придётся иметь дело с такой деликатной материей как личные данные пользователей, которые ещё и связаны с их финансами. Вряд ли кто-то из клиентов магазина захочет, чтобы все это стало достоянием общественности, поэтому здесь приходится прибегать к продуманным и многократно проверенным решениям.
Создание целого интернет-магазина с нуля — мягко говоря, задача непростая. Поэтому на рынке довольно много фреймворков, помогающих разработчикам с этим (у всех на слуху Magento, к примеру). Задачу приема платежей, как одну из самых важных, потому что она связана с деньгами, включают в себя все решения для электронной коммерции. Разработчики, имевшие с этим дело, знают, что это достаточно простая последовательность шагов, которая часто выглядит как «качаем код библиотеки для платёжного шлюза XYZ», «настраиваем его» (все обычно сводится к получению и использованию специального ключа, позволяющего шлюзу понять с каким магазином он имеет дело), «немного допиливаем» и «выгружаем на продакшн».
Как правило, это не вызывает существенных проблем. Правда, после того, как пользователь вашего магазина перешел на страницу оплаты выбранного платежного шлюза, ввел данные своей платежной карты и нажал на кнопку «Оплатить», вмешаться в процесс уже не получится — разве только обработать ответ шлюза на своей стороне и показать пользователю красивую страничку с благодарностью (если всё прошло нормально) или извиниться (если что-то пошло не так).
Квалифицированный пользователь знает, к примеру, что https лучше http и проверяет это, многие браузеры будут показывать в адресной строке данные сертификата сайта. Однако когда платёжный шлюз начнёт свои «внутренние» транзакции с банком-эмитентом (тот, который выдал карту) и с банком-эквайером (тот, который должен получить оплату), то может возникнуть вполне закономерный вопрос — а насколько это всё вообще безопасно? Ведь передача данных по протоколу https — еще не гарантия безопасности, а лишь один из сотен параметров, обеспечивающих защиту информации.
Может быть ребята из этого шлюза и смогли настроить себе https, купили сертификат и даже большими буквами написали на своём сайте, что всё очень хорошо и всё очень защищено. Но единственным по-настоящему надёжным способом убедиться в этом является выполнение каких-то процедур, удостоверяющих безопасность внутреннего кода платежного шлюза. И, конечно, желательно, чтобы пройти такую проверку было бы сложнее, чем написать на своём сайте немного красивого HTML — «100% гарантия безопасности».
Мы опишем такую процедуру и попробуем понять, почему она является стандартом в индустрии электронной коммерции. Всё это будет скрываться под аббревиатурой PCI DSS, и именно наличие этого сертификата у платёжного шлюза вполне может означать, что данные платёжной карты (да что там, проще говоря, деньги плательщика) дойдут до адресата без проблем.
Что такое PCI DSS?
PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных индустрии платежных карт. Другими словами, это документация со списком критериев, которому должен удовлетворять сервис, если он как-то управляет такими вещами, как номер карты, срок её действия и CVV-код.
Платёжных карт можно насчитать довольно много (все знают Visa и MasterCard), а поскольку речь идёт о стандарте индустрии, то было бы нелишним всем компаниям договориться между собой о том, что они будут считать безопасным. Для этого существует Совет PCI SSC (Payment Card Industry Security Standards Council) — Совет по стандартам безопасности индустрии платежных карт, образованный пятью крупнейшими платёжными системами. Именно он создаёт правила «безопасной игры», и именно его правилам должны следовать компании, желающие получить заветный шильдик «Сертифицировано PCI-DSS». Проходить сертификацию необходимо каждый год.
Что именно проверяют?
На самом деле описать все критерии проверки будет сложно — их 288. Сама процедура довольно длительная, потому что затрагивает проверку ряда сложных технических моментов. Полностью список критериев, разбитый на 12 групп, выглядит следующим образом:
Сам программный код библиотек проверяется выборочно, наибольшее внимание уделяют ядру, непосредственно обрабатывающему данные платёжных карт, при этом внимание обращают на соответствие внешнему стандарту безопасности OWASP, который описывает основные требования к поиску и исключению в коде уязвимостей. Также в бизнес-процессе разработки присутствует звено Code Review, на котором, собственно, проходит дополнительная проверка другим разработчиком, не участвующим в самом написании кода.
Все взаимоотношения и ответственность в рамках требований PCI DSS между сервис-провайдерами, а именно между процессинговым центром и датацентром, а также банками-эквайерами, фиксируются в так называемых матрицах ответственности. Наличие подписанных матриц ответственности между сервис-провайдерами стало обязательным требованием с версии 3.1 стандарта PCI DSS. Помимо прочего, разумеется, у датацентра должен быть также актуальный сертификат соответствия PCI DSS на компоненты инфраструктуры, которые использует в работе процессинговый центр — виртуализация, сервисы, физическое оборудование и так далее.
Сами серверы, так же как и все остальные компоненты инфраструктуры, например, сетевое оборудование, также подлежат обязательной проверке. Основным требованием здесь является актуальность статуса PCI-DSS, который ставится в прямую зависимость от частоты изменений программного обеспечения, конфигураций оборудования или/и виртуальных машин и, что не менее важно, от ставших известными уязвимостей, таких как печально известный HeartBleed. Администраторы инфраструктуры обязаны проводить аудит системы на предмет поиска внутренних/внешних уязвимостей и приводить компоненты инфраструктуры в соответствие стандарту PCI DSS.
Аудит безопасности выполняется дважды. Первый раз используется автоматический сканер на известные уязвимости, который предоставляет сертифицированная организация ASV (Approved Scanning Vendor). В случае успешного прохождения этого теста, система проверяется на безопасность второй раз экспертами, что называется, вручную, с вынесением официального заключения.
Возможные трудности
Здесь хотелось бы привести пример из личного опыта. Во время последней сертификации PCI-DSS наши специалисты организовали специальную службу мониторинга, которая следила за тем, чтобы транзакции между нашим дата-центром и банками выполнялись непрерывно. Источником потенциальных проблем было то, что некоторые банки сообщают о том, что их сертификат TLS 1.0 был обновлён до версии 1.2 уже постфактум. Потенциально могло произойти так, что мы пытаемся общаться с банком, имея старый сертификат, тогда как на их стороне он уже обновлён. Благодаря тому, что теперь у нас отдельная служба мониторинга непрерывности транзакций, такая проблема больше невозможна.
Вообще можно привести несколько примеров, как работает проверка, и как мы приводили нашу инфраструктуру в соответствие с требованиями. Как известно, согласно PCI-DSS, платёжная система не должна хранить у себя так называемые Критичные аутентификационные данные (КАД), к которым относят, к примеру, CVV или PIN-код (последний обычно поступает из POS-терминалов супермаркетов). Реализовано это таким образом:
Когда транзакция получает от процессингового центра специальный статус, говорящий о том, что она завершена (независимо от того успешно или нет), то в системе инициируется специальный программный код, решающий две задачи. Если во время транзакции по какой-либо причине её данные были записаны на диск, то специальная операция, удаляющая эту запись, получает максимальный приоритет и выполняется специальным воркером. Если обращения к диску не было, то всё еще проще: процесс транзакции удаляется из памяти сервера и таким образом фиксации КАД не происходит. Единственные данные, которые можно хранить — это номер карты PAN (Primary Account Number), и то исключительно в зашифрованном виде.
Еще один пример напрямую связан с одним из наших пользователей (хотя на самом деле таких историй много, просто эта последняя по времени), который покупал товар в интернет-магазине. После того, как что-то «пошло не так», он не стал читать достаточно подробные сообщения об ошибке, а просто сфотографировал свою платёжную карту с обеих сторон (наверно, потому, что в форме платежа ему объяснили, что надо вводить три последние цифры после магнитной полосы на оборотной стороне) и прислал её нам в службу поддержки. По мнению покупателя, это должно было помочь нам выяснить статус его платежа — «снялись деньги» или нет. Надо сказать, что даже такие курьёзные и одновременно печальные случаи оговорены стандартом PCI-DSS.
В случае компрометации данных пользователя платёжная система обязана уведомить его самого и банк-эмитент, выпустивший «засвеченную» карту. Кроме того, необходимо было удалить письмо с вложениями-картинками из клиентской почтовой программы оператора службы поддержки, а также на почтовом сервере. Всё это делалось для того, чтобы следовать золотому правилу обеспечения безопасности индустрии платёжных карт — «Если тебе не нужна эта информация, то не храни её».
Интеграция PayOnline с интернет-магазином
Как уже упоминалось выше, задачу интеграции конкретного интернет-магазина с платёжной системой вряд ли можно назвать сложной. В интернете можно найти множество примеров для многих шлюзов. Всё обычно сводится к установке на сервер специально написанной библиотеки (у нас их много и под разные платформы) и написанию какого-то клиентского кода, который будет собирать информацию пользовательской формы и отправлять её платёжному шлюзу. Единственным моментом, на который хотелось бы обратить внимание, должно быть месторасположение самой платёжной формы — будет она находиться на стороне интернет-магазина или будет работать на стороне PayOnline. Несмотря на то, что многие решения вполне могут позволить принимать платежи прямо на своём сайте, в случае отсутствия у мерчанта собственного сертификата PCI-DSS, необходимо будет организовать всё так, чтобы платежи выполнялись на стороне платёжного шлюза. Обоснование тут одно — это безопасность финансовых данных пользователя. При этом платёжную форму можно кастомизировать под компанию, так что отторжения у конечного пользователя не возникнет.
Что получает интернет-магазин
Среди основных преимуществ системы электронных платежей PayOnline мы можем выделить особо наши технические возможности, нацеленные на увеличение конверсии в успешные платежи. В первую очередь, конечно, это тонкая работа с 3-D Secure, позволяющая сохранить высокий уровень защиты от мошеннических операций и одновременно увеличить платежную конверсию.
Мы внимательно изучаем поведение плательщиков, которое из года в год меняется вслед за технологическим прогрессом. Благодаря возможности измерять конверсию и поведение человека на платёжной странице в момент заполнения данных и совершения платежа, мы технологически позволяем своим клиентам шаг за шагом отследить путь покупателя, представить себя на его месте и максимально упростить его пользовательский опыт на основе полученной статистики. В случае же, если при совершении платежа у покупателя по какой-то причине не получается провести оплату, магазин получает от процессингового центра точную причину отклонения, далее магазин транслирует причину отклонения плательщику в любом кастомизированном виде. Таким образом, клиент сразу понимает, почему платеж не прошел и что ему необходимо сделать, чтобы приобрести товар или услугу.
Если вас заинтересовала такая возможность, обращайтесь, наши специалисты предоставят дополнительную информацию и, в случае необходимости, помогут настроить прием платежей на сайте и в мобильном приложении по защищенному шлюзу, отвечающему требованиям стандарта PCI DSS 3.1.