сертификат pci dss что это

Сертификация PCI DSS

Соответствие ЦОД DataSpace требованиям гарантирует надежность и высокий уровень физической безопасности дата-центра.

Успешное прохождение ежегодной сертификации, начиная с 2015 года

Соответствие ЦОД DataSpace требованиям гарантирует надежность и высокий уровень физической безопасности дата-центра.

Успешное прохождение ежегодной сертификации, начиная с 2015 года

Сертификация PCI DSS

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

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

«Avito — одна из крупнейших IT-компаний, наша деятельность предполагает хранение и обработку и большого объема данных. Мы стремимся предоставлять своим клиентам непрерывный сервис высокого уровня, для чего необходима качественная ИТ-инфраструктура. Avito уже не первый год размещает свое оборудование в ЦОД DataSpace, мы уверены в его надежности, отличной технической оснащенности и главное — безопасности. Успешное прохождение сертификации на соответствие стандарту безопасности данных в очередной раз подчеркивает высокую квалификацию центра и подтверждает наш правильный выбор DataSpace как надежного партнера».

«Avito уже не первый год размещает свое оборудование в ЦОД DataSpace, мы уверены в его надежности, отличной технической оснащенности и главное — безопасности. Успешное прохождение сертификации подчеркивает высокую квалификацию дата-центра, и подтверждает наш правильный выбор DataSpace, как надежного партнера».

«Прохождение DataSpace сертификации по стандарту PCI DSS v3.2 для нас, как поставщика облачных услуг, является гарантией надежности и наглядным доказательством высоких стандартов работы, которых придерживается DataSpace. Получив данный сертификат, компания DataSpace берет на себя ответственность по выполнению требований физической безопасности ЦОД и выступает надежным партнером, что позволяет нам оказывать полный спектр PCI DSS-услуг собственным клиентам».

«Прохождение DataSpace сертификации по стандарту PCI DSS v3.2 для нас, как поставщика облачных услуг, является гарантией надежности и наглядным доказательством высоких стандартов работы, которых придерживается DataSpace».

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

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

Источник

PCI DSS – как и зачем получать сертификат соответствия

Привет, %username%!
Этот пост мы подготовили для тех, кто работает в сфере интернет-коммерции и планирует принимать (или уже принимает) платежи на собственном сайте. Мы расскажем о международном стандарте безопасности данных PCI DSS. Поговорим о его основных требованиях к информационной инфраструктуре, которая обеспечивает обработку и обеспечение безопасности данных банковских карт. Также мы рассмотрим основные причины прохождения сертификации и возможности, которые получает сертифицированная компания.

PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных индустрии платежных карт. Стандарт разработан международными платежными системами Visa и MasterCard. Любая организация, планирующая принимать и обрабатывать данные банковских карт на своем сайте, должна соответствовать требованиям PCI DSS.

Но самостоятельная работа с банками дает компании не только преимущество в адаптации платежной системы «под себя». Она обязывает компанию взять на себя борьбу с мошенническими операциями при обработке данных банковских карт на своем сайте. Иными словами, компании необходимо построить собственную систему мониторинга и борьбы с мошенническими операциями (анти-фрод). Задача анти-фрод системы – фильтрация операций, определяемых как мошеннические, по ряду признаков (например, несовпадение банка-эмитента со страной оплаты или проживания плательщика).

На стадии построения и отладки анти-фрод системы много времени «съест» сбор и анализ данных об операциях по банковским картам. Цель сбора данных – выявление отличительных признаков мошеннических операций. В процессе сбора статистики компании придется столкнуться с большим объемом «charge-back» операций.

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

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

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

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

К компаниям, работающим только с платёжным шлюзом и не принимающих на своем данных банковских карт клиентов, относятся только требования департамента рисков платежного шлюза (ПЦ). Они касаются сайта предприятия e-commerce, корректности контента и ценовых предложений, организационной формы компании.

Если после прочтения этого поста у Вас появились вопросы – пишите в комментарии. Со стороны аудитора и специалиста по требованиям стандарта PCI DSS Вас проконсультирует Евгений Безгодов aka Bezgodov, исполнительный директор компании Deiteriy, CISA, PCI QSA. Со стороны платежного шлюза как всегда на связи специалисты процессингового центра PayOnline.

Источник

Сертификация 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. Обращение к сертифицированным поставщикам услуг помогает существенно упростить процесс сертификации для торгово-сервисных предприятий и обеспечить защиту данных платежных карт на должном уровне.

Источник

PCI DSS: что это такое и как под него сертифицироваться + наш опыт

— Хорошо, теперь покажите ваш статический анализатор кода.
— Знакомьтесь, это Пётр.
— Приятно познакомиться, но…
— Пётр и есть наш статический анализатор кода.

Когда вы работаете с платёжными данными, то должны обеспечивать определённый уровень безопасности. Этот уровень описан в стандарте PCI DSS, разработанном Visa, MasterСard и другими платёжными системами. Он важен, поскольку применяется ко всем участникам процесса работы с данными держателей карт, но есть дополнительные требования для поставщиков услуг.

В стандарте 12 разделов — начиная от того, что служба безопасности должна следить за сменой доступов и изъятием пропусков после увольнения сотрудников, и заканчивая тем, как и куда должны писаться всевозможные логи.

Расскажу, как мы сертифицировали нашу облачную платформу и сколько нервов это вымотало.

Проблема коротко

Изначально у каждой платёжной системы — Visa, MasterCard, American Express, JCB и Discover — имелись свои программы с минимальным набором требований по безопасности при работе с данными держателей карт, и эти требования пересекались. Затем был сформирован Совет Payment Card Industry Security Standards Council (PCI SSC), в который вошли платёжные системы, указанные раньше. В 2004 году была выпущена первая версия PCI DSS 1.0. В ней были описаны минимальные требования ко всем участникам процесса хранения, обработки и передачи данных держателей карт.

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

В целом все пункты очень здравые и на первый взгляд понятные. Вот прямо взять и сделать. Но когда начинаешь делать — начинаются сложности и толкования. Например, в требованиях стандарта есть пункт о необходимости статического анализа кода. У нас большая часть кода написана на языке Python, в настоящий момент статических анализаторов кода нет — точнее, есть, например, Bandit, но конкретно к нашей истории он не подходил. Поэтому выполнять анализ кода на безопасность стал человек Пётр. Именно его мы сдавали как статический анализатор. Человек Пётр требованиям к анализатору соответствовал. Примерно в том же ключе шли некоторые другие пункты.

Зачем сертифицировать облако

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

Но просто так взять и встать в облако нельзя — площадка облачного провайдера (то есть в данном случае наша), на которой заказчики хранят, обрабатывают и передают данные держателей карт платёжных систем Visa и MasterСard, должна соответствовать стандарту PCI DSS. Иначе с ним нельзя работать. Если клиент не работает с такими данными, то сертификация ему не нужна.

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

Нашим заказчикам наша же сертификация позволяет быстрее мигрировать и проходить свои аудиты. Этот сертификат закрывает все требования, предъявляемые к ЦОДу (точнее, в нашем случае — ЦОДам) и к инфраструктуре облака, включая все технические и организационные процессы. В реалиях сокращает заказчикам время на прохождение уже своего аудита и на пояснительную документацию, часть которой уже готова у нас.

Как шёл аудит

Мы готовились к аудиту больше года.

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

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

По всем сложным моментам история такая: есть требования. Не важно, как устроена система, главное, чтобы требования выполнялись. Если непонятно толкование и как приземлять его на свою инфраструктуру — можно попросить аудитора оценить, подходит решение или нет. Зачастую при этом приходилось вступать в дискуссию, доказывая специфику платформы и правильность выбранного решения, которое не всегда очевидно. Обязательным требованием сертификации является ежегодное прохождение пентеста. Для себя мы выбрали несколько моделей нарушителей: внешний злоумышленник, скомпрометированный сотрудник (он же зловредный сотрудник) или клиент.

Одна из ярких проблем для облака — нужно обеспечить функционирование DMZ. В нашей концепции очень сложно определить, что именно есть DMZ, т. к. в классическом варианте оно не вписывается в платформу. Пришлось сделать несколько микроDMZ на каждом сервере, доступном из Internet или граничным с внешними локальными сетями.

Вот, например, нужно вести учёт всех системных компонентов документированно. Сюда входит всё, что относится к платформе: сетевое оборудование, средства мониторинга, все инфраструктурные серверы, средства защиты и т. д. Для каждого компонента требуется указать его расположение, версию ПО, IP-адрес. Когда у тебя таких компонентов 50 — проблем нет, но что делать, если их 500? Вдобавок количество компонентов постоянно меняется — и не только в разрезе числа серверов, но и по ролям на каждом сервере. Всё облако построено на ролях, может добавиться сервер с ролью, может добавиться роль к серверу. И всё это многообразие постоянно движется, причём, как правило, в большую сторону. Понятное дело, что ручным трудом тут не обойдёшься, пока будешь составлять актуальный список, он уже изменится, возможно, несколько раз. Пришлось внедрять самописную автоматизацию — систему сбора данных по облаку, чтобы в любой момент времени получить подробный отчёт о всех компонентах. Такая же была проблема с сетевыми схемами. Стандарт требует отображения всех компонентов на уровне L2-L3-модели модели OSI. Их также больше 500, и их тяжело отобразить на одной схеме. А главное, схема будет совсем нечитаемой. Искали варианты, как сгруппировать, чтобы просто это можно было охватить взглядом. Схему сделать надо, а это сложно (и порой кажется почти нереализуемым). Тоже нашли выход.

Есть проблемы мониторинга — расширенные журналы регистрации событий и система контроля целостности на всех компонентах.

Согласно требованиям стандарта, нужно вести логирование действий всех пользователей, а также собирать все логи критичных компонентов на внешнем сервере и анализировать их. Первая часть задачи не выглядит страшной, даже с учётом большого числа компонентов, т. к. умеем управлять такой большой инфраструктурой. Но вот с анализом возникают трудности. Логи прилетают в огромном количестве, если просматривать вручную, то на это уйдут недели. Может, даже месяцы. Для решения этой задачи внедряли специальный механизм сбора и анализа логов, который позволил мониторить логи в режиме реального времени и выдавать алармы в случае срабатывания тригерров. Естественно, с тригеррами пришлось попотеть…

Вторая проблема — механизм контроля целостности. Для начала нужно было определить список критичных конфигураций и логов, за которыми нужно следить, создать под них шаблоны и разлить согласно ролям. В принципе задача достаточно тривиальная — за одним но… Из-за объёма триггер может сработать на автоматизированный процесс. Поначалу мы получали тонны писем о срабатывании системы контроля со всех компонентов. Ушло немало трудочасов, чтобы всё настроить.

Перед проведением внутреннего сканирования в первый раз надо очень аккуратно настроить профили сканирования и прогнать их на тестинге по многу раз, чтобы выявить любые отклонения от нормальной работы сервисов. Расчётная часть была довольно интересная. То же касается и тестирования на проникновение — нужно обговорить все детали, прежде чем начнут ломать прод. Во время теста пришлось пристально смотреть на системы мониторинга, чтобы заметить любые отклонения.

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

И так далее. В целом все требования, повторюсь, достаточно понятные и очевидные. Сложности возникают при наложении на реальную инфраструктуру, все подводные камни видно не сразу. Изначально нужно чётко определить зоны ответственности между облачным провайдером и клиентом, отсюда формируется список предъявляемых требований. А это не так просто и очевидно. Только после этого можно приступать к их выполнению. Как показывает практика, большая часть требований предъявляется как к площадке, так и к клиенту. Например, требования к межсетевому экранированию предъявляются как к защите самого облака, так и к виртуальной инфраструктуре клиента. А это совсем разная реализация и ответственность.

В итоге в проекте было поставлено 478 Jira-тикетов, потребовался 1 год. Аудитора мы постоянно дёргали вопросами, он отвечал, толковал и делился мировым опытом. Результат — сертификат на облачную платформу на базе KVM. И сразу несколько заказчиков, которые хотят обрабатывать свои платёжные данные там.

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

Источник