Сертификация pci dss что это
Как пройти сертификацию PCI DSS: опыт ИТ-ГРАД
В одном из прошлых постов мы отметили, что успешно ресертифицировали свою инфраструктуру по PCI DSS и рассказали о видах хостинга PCI DSS: co-location, IaaS Basic и IaaS Advanced. Сегодня мы подробнее поговорим о самом процессе сертификации и собственном опыте прохождения аудита.
Кому нужно проходить сертификацию
Требования стандарта распространяются на все предприятия, которые обрабатывают, передают или хранят данные хотя бы одной кредитной карты. В одном из наших предыдущих материалов мы приводили простую блок-схему, помогающую понять, кому нужна сертификация PCI DSS.
Суть её заключается в том, что руководству организации достаточно ответить на эти вопросы:
Далее мы расскажем, как проходил этот процесс.
Этап 1: подготовка документации
Перед тем как пройти аудит, компания должна подготовить нормативно-распорядительные документы по ИБ (инструкции, регламенты, политики). На момент первой сертификации большинство из них уже были нами разработаны, но некоторые все же пришлось дорабатывать.
Например, нам пришлось править политику, которая содержит цели, задачи и способы обеспечения информационной безопасности на предприятии. Мы также корректировали регламенты, определяющие принципы управления уязвимостями и инцидентами. Например, мы сформировали «Регламент управления доступом к информационным активам» — в нем описаны правила работы с правами доступа и требования к учетным данным пользователей.
Отметим, что все документы нужно пересматривать и корректировать ежегодно. Особенно если были изменения в ИТ-структуре компании.
Этап 2: построение ИТ-инфраструктуры
Следующий этап — подготовка инфраструктуры. Если организация проходит аудит впервые, то руководству нужно определить скоп, который будет сертифицироваться, то есть ограничить отдельный инфраструктурный блок, который будет поддерживать все процессы, подлежащие сертификации. Это нужно для того, чтобы не приходилось сопровождать любое внесение изменений в инфраструктуру новыми тестами на соответствие требованиям стандарту.
Для этого нам пришлось организовать отдельную инфраструктуру с выделенной сетью, развернуть серверы ESX, vSphere и vCenter, установить свитчи и сетевой экран, чтобы предотвратить атаки злоумышленников. Всё это оборудование мы задублировали, а затем составили схемы сервисов, сети и бизнес-процессов.
Сертифицируемая инфраструктура должна быть отделена от других сетей организации — доступ к ней обязан предоставляться через изолированный интерфейс. Чтобы выполнить это требование, мы используем VPN с 2FA и изолируем сегмент каждого клиента.
Внутри периметра располагается NTP-сервер, сервисы логирования, антивирус, файрвол, а также решения для предотвращения кибератак и контроля сохранности данных. Схему нашей сети можно посмотреть здесь.
Этап 3: прохождение пентеста
Пентест проводит специальная команда от лица аудиторской компании. Аудиторы проверяют работу решений, которые применяются для защиты данных владельцев карт, и выявляют потенциальные «дыры» в безопасности.
Перед тем как начать проверку инфраструктуры на устойчивость к проникновению, наша команда подготовила два скопа. Первый со служебными сервисами и приложениями, участвующими в тестировании. На второй была настроена ВМ с ОС, назначены необходимые права соответствующим учетным записям.
/ Пример скопа с размещенными сервисами и приложениями
Пентест нашей инфраструктуры проводился в несколько этапов.
Сканирование утилитой nmap
Аудиторы проверяли белые IP-адреса нашей компании. На машинах с публичными IP-адресами открытые порты им найти не удалось (открыты были только те, которые отвечают за функционирование нашей инфраструктуры).
Подключение по VPN и проверка внутренней сети
Пентест-команда попыталась получить доступ из недоверенной сети. Результаты теста показали, что проникнуть в инфраструктуру «ИТ-ГРАД» по VPN без 2FA нельзя. Проверка внутренней сети также не выявила нарушений.
Попытка доступа подключения к инфраструктуре по учетной записи
На стороннем ресурсе (этим ресурсом был iaas-blog.it-grad.ru) эксперты получили учетные данные одного из наших коллег. Этот коллега также имел учетку в тестируемой инфраструктуре «ИТ-ГРАД». Аудиторы попытались авторизоваться, используя его аккаунт и пароль, но у них это не получилось, так как сеть была достаточно сегментирована.
Всего по итогам проверки у нас обнаружили 7 уязвимостей разной степени критичности: одну высокого и по 3 среднего и низкого уровня «опасности».
Наша самая критичная уязвимость — неправильная работа WAF — возникла из-за того, что используемый межсетевой экран не справлялся со сложными атаками. Для того чтобы устранить уязвимость мы развернули веб-сервер Apache с модулем Modsecurity, а затем обновили БД сигнатур WAF.
Уязвимостей среднего уровня было три. Первая — включенный метод TRACE, который злоумышленники могут использовать, например, для межсайтового скриптинга. Чтобы устранить уязвимость, мы деактивировали метод TRACE.
Второе несоответствие — отсутствие безопасных HTTP-заголовков. Уязвимость может стать причиной атак злоумышленников на пользовательский интерфейс. Эту задачу мы решили с помощью включения безопасных заголовков на соответствующем сервере приложений.
И третья уязвимость — незащищенность программного обеспечения на одном из хостов (из-за устаревшей версии ПО). Для устранения этой уязвимости мы настроили регулярные обновления ПО на всех узлах.
Среди уязвимостей низкой критичности аудиторы обнаружили тестовые данные с хэшами паролей в продакшн-среде. Нам также указали на ненадежные пароли и лишнее ПО. Мы заменили уязвимые пароли на безопасные и удалили неиспользуемые данные и программное обеспечение. После исправления всех уязвимостей, мы успешно прошли повторный пентест.
Этап 4: финальный аудит
На последнем этапе проверки аудитор оценивает комплектность и параметры ПО и железа, топологию сети, конфигурацию ОС, изолированность сегментов инфраструктуры и другие характеристики. Кроме того, он может проверить документацию и знания сотрудников, задать вопросы организационного или технического характера.
Если у вашей компании обнаружатся незначительные отклонения от требований стандарта, их можно устранить во время аудита. Например, у нас нашли неактивную учетную запись компьютера в Active Directory, которую мы оперативно удалили.
Если вам потребовалось что-то поменять до или во время аудита, это тоже не проблема. Главное здесь — вносить изменения так, как этого требует PCI DSS.
Например, перед аудитом нам в «ИТ-ГРАД» понадобилось отследить загрузку и выгрузку файлов на SFTP-сервере. Для этого мы должны были срочно написать декодер для сервера avusm. Без декодера сервер не сохранял нужные сообщения, поскольку не мог «разбирать» логи и формировать оповещения.
В конечном счете мы получили сертификат соответствия требованиям PCI DSS и стали одним из первых IaaS-провайдеров в России, который оказывает услугу хостинга PCI DSS.
Что такое 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.
Сертификация PCI DSS проще и дешевле, чем кажется
Если вы хотите, чтобы ваши клиенты могли расплачиваться банковской картой, вам не обойтись без сертификации PCI DSS. Она нужна для подтверждения того, что вы проводите операции с платежами с учетом самых строгих требований безопасности.
Вы можете не получать сертификацию, но тогда вам придется пользоваться «костылями» наподобие встраивания iframe платежной страницы банка-эквайера на сайте или редиректа на его сайт. А это — ухудшение пользовательского опыта, то есть потенциально упущенные клиенты и прибыль. Вывод: сертификация все-таки пригодится.
После консультаций со своим эквайером и QSA-компаниями легко подумать, что такая сертификация — процесс сложный, долгий и дорогой. Но на самом деле это не всегда так.
Сертифицируй себя сам
По правилам платежных систем Visa и MasterCard, если вы сервис-провайдер и обрабатываете, храните или передаете данные менее чем о 300 000 транзакциях в год, для успешной сертификации можно обойтись заполнением специального листа самооценки (SAQ), то есть без QSA-аудита. Если же вы — мерчант, то планка — от 1 млн транзакций в год.
Аудит проводит Qualified Security Assessor — компания, которой Совет PCI SSC предоставил право проведения оценки на соответствие стандарту. В ходе проверки тестируется соответствие бизнес-процессов, процессов по безопасности, средств защиты информации и ИТ-инфраструктуры вашей компании требованиям безопасности.
Вот основные отличия аудита от самооценки (обратите внимание на стоимость):
Недавно к нам обратился клиент, который считал, что ему нужно пройти полноценный QSA-аудит. Компания обрабатывает данные банковских карт в мобильном приложении, для этого люди перенаправлялись на платежную страницу банка-эквайера. Чтобы повысить качество пользовательского опыта клиент хотел сделать в мобильном приложении собственную платежную форму. Но для этого надо было предоставить банку-эквайеру сертификат. На вопрос клиента «В каком формате нужна сертификация?» специалисты банка просто отправили ссылку на сайт стандартов PCI DSS.
Когда клиент обратился к нам, сразу выяснилось, что он может подтвердить соответствие требованиям PCI DSS, заполнив лист самооценки (SAQ). Наши специалисты провели аудит бизнес-процессов и инфраструктуры компании, разработали план того, как привести всё это в соответствие требованиям PCI DSS, а также разработали необходимые нормативные документы. Кроме того, они проконтролировали выполнение всех требований.
Затем клиент с нашей помощью заполнил лист самооценки и отправил его банку-эквайеру. После некоторых раздумий (похоже, банк-эквайер редко сталкивался с SAQ) лист самооценки был принят в качестве подтверждения соответствия требованиям PCI DSS. Клиент смог встроить в мобильное приложение собственную платежную форму.
А можно без сертификации?
Сертификат PCI DSS — свидетельство того, что вы серьезно относитесь к работе и данным банковских карт клиентов, строго соблюдая международные стандарты безопасности. Конечно, теоретически вы можете работать без нее, но за это предусмотрен крупный штраф. Кроме того, вам придется работать с не очень ответственными банками или платежными шлюзами, игнорирующими требования безопасности, что делает вас более уязвимым перед мошенниками. В случае обнаружения в транзакциях фрода, случившегося по вашей вине, компенсировать последствия вам придется самостоятельно.
И напоследок напомним о стоимости аудита и самооценки. Средние цены на оба варианта сертификации на российском рынке такие:
Таким образом, на самооценке вы сэкономите, как минимум, вдвое.
Первый шаг в деле сертификации PCI DSS вы можете сделать прямо сейчас, посчитав количество ваших транзакций в год. Скорее всего, логотип «PCI DSS Certified» на вашем сайте намного ближе, чем кажется.
Сертификация PCI DSS: Что это и с чем её едят
Последнее время Visa и MasterCard начали требовать от торговых предприятий и поставщиков услуг, работающих с карточными данными, соответствия стандарту PCI DSS. В этой связи вопрос требований этого стандарта становится важным не только для крупных игроков на рынке, но и для небольших торгово-сервисных предприятий.
Стандарт PCI DSS был разработан Советом по стандартам безопасности данных индустрии платежных карт PCI SSC (Payment Card Industry Security Standards Council) и регламентирует определенный перечень требований к обеспечению безопасности данных платежных карт (ДПК), которые затрагивают как техническую, так и организационную сторону организаций.
В первую очередь стандарт определяет требования к организациям, в информационной инфраструктуре которых хранятся, обрабатываются или передаются данные платёжных карт, а также к организациям, которые могут влиять на безопасность этих данных. Начиная с середины 2012 года все организации, вовлечённые в процесс хранения, обработки и передачи ДПК должны соответствовать требованиям, определяемым PCI DSS, и компании на территории Российской Федерации не являются исключением.
Чтобы понять, необходимо ли вашей компании соблюдать требования стандарта PCI DSS, следует ответить на два главных вопроса: хранятся, обрабатываются или передаются ли данные платежных карт в вашей организации? И могут ли бизнес-процессы вашей организации повлиять на безопасность этих платежных карт? Если ответ на оба вопроса отрицательный, то сертифицироваться по PCI DSS нет нужды.
Очевидно, что для соответствия стандарту необходимо выполнение определенных требований, вот некоторые из них: защита вычислительной сети, управление доступом к данным о держателях карт, конфигурация компонентов информационной инфраструктуры, механизмы аутентификации, физическая защита информационной инфраструктуры, защита передаваемых данных о держателях карт и так далее. В общем, стандарт требует прохождения порядка 440 проверочных процедур.
Существуют различные способы подтверждения соответствия требованиям стандарта PCI DSS, которые заключаются в проведении внешнего аудита (QSA), внутреннего аудита (ISA) или проведении организацией самооценки (SAQ).
Внешний аудит QSA выполняется внешней аудиторской организацией, сертифицированной Советом PCI SSС. В ходе проверки аудиторы собирают свидетельства выполнения требований стандарта и сохраняют их на период длительностью в три года.
Внутренний аудит ISA выполняется внутренним, прошедшим обучение и сертифицированным по программе Совета PCI SSC, аудитором. Что касается самооценки SAQ, то она выполняется самостоятельно путём заполнения листа самооценки. В этом случае сбор свидетельств выполнения требований стандарта не требуется.
Чтобы ответить на вопрос, в какой ситуации необходимо проводить внешний аудит, а в какой – внутренний, и стоит ли это вообще делать, нужно взглянуть на тип организации и оценить количество обрабатываемых транзакций в год. Существует классификация, согласно которой выделяют два типа организаций: торгово-сервисные предприятия и поставщики услуг.
Торгово-сервисное предприятие является организацией, принимающей для оплаты товаров и услуг платежные карты (магазины, рестораны, интернет-магазины и другие).
Поставщик услуг же, в свою очередь, является организацией, оказывающей услуги в индустрии платежных карт, связанные с обработкой транзакций (это дата-центры, хостинг-провайдеры, международные платежные системы и другие).
В зависимости от количества обрабатываемых в год транзакций, торгово-сервисные предприятия и поставщики услуг могут быть отнесены к различным уровням. Например, торгово-сервисное предприятие обрабатывает до 1 млн транзакций в год с применением электронной коммерции.
По классификации Visa и MasterCard организация будет относиться к уровню 3. Следовательно, для подтверждения соответствия PCI DSS нужно проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV (Approved Scanning Vendor) и ежегодной самооценки SAQ.
Что касается поставщиков услуг, то количество сервисов, предлагаемых облачными провайдерами, растет ежегодно. Потому для организаций, использующих облачную инфраструктуру, становится актуальным вопрос PCI DSS-хостинга.
PCI DSS-хостинг – это услуга, обеспечивающая безопасное обращение платежных карт для организаций, разместивших свою инфраструктуру на стороне сертифицированного PCI DSS хостинг-провайдера, внутри которой хранятся, обрабатываются или передаются данные платежных карт.
Выбрав такую услугу, организация автоматически закрывает значительную часть требований стандарта PCI DSS – это означает, что провайдер берет на себя выполнение части требований, например, физическую защиту размещаемых северов и администрирование операционных систем.
Как известно, аутсорсинг решает множество задач, облегчая и упрощая жизнь организациям. Если раньше многие компании разворачивали информационную инфраструктуру в собственном серверном помещении и выполняли все требования соответствия стандартам самостоятельно, то сейчас многие отдают эти задачи на откуп сертифицированным поставщикам услуг, тем самым повышая уровень защищенности среды обработки карточных данных и снижая риски финансовых потерь от возможных инцидентов информационной безопасности.
Любая организация, использующая собственный карточный процессинг, рано или поздно сталкивается с необходимостью сертификации по стандарту PCI DSS. Обращение к сертифицированным поставщикам услуг помогает существенно упростить процесс сертификации для торгово-сервисных предприятий и обеспечить защиту данных платежных карт на должном уровне.