Payment card industry security standards council что это

Обновлено: 30.06.2024

PCI DSS (Payment Card Industry Data Security Standard) — общепринятый стандарт безопасности, которому должны соответствовать поставщики товаров и услуг, принимающих в качестве средства оплаты платёжные карты. Если говорить проще, то PCI DSS представляет собой документ с длинным списком критериев, которым должен соответствовать бизнес, если он так или иначе управляет данными банковских карт. Номером, сроком действия, CVV-кодом и т.д.

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

Всего в документе несколько сотен критериев, разбитых на 12 подгрупп:

Защита вычислительной сети.
Конфигурация компонентов информационной инфраструктуры.
Защита хранимых данных о держателях карт.
Защита передаваемых данных о держателях карт.
Антивирусная защита информационной инфраструктуры.
Разработка и поддержка информационных систем.
Управление доступом к данным о держателях карт.
Механизмы аутентификации.
Физическая защита информационной инфраструктуры.
Протоколирование событий и действий.
Контроль защищенности информационной инфраструктуры.
Управление информационной безопасностью.

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

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

Что такое mPOS

Мобильное платежное решение (mPOS) состоит из следующих основных компонентов:

мобильное устройство – смартфон или планшет, к которому подключается считывающее устройство;
платежное приложение для мобильного устройства – программное обеспечение, через интерфейс которого продавец производит ввод данных для оплаты и обмен данными с процессингом. Также через данное ПО возможна верификация владельца карты с использованием подписи;
считывающее устройство – выделяются два вида считывающих устройств: Pin Entry Device (PED), устройство считывания карты и ввода PIN-кода. Подключается к мобильному устройству посредством Bluetooth, через аудиоразъем или mini-USB; Secure Card Reader (SCR), устройство считывания карты. Обычно подключается к мобильному устройству через аудиоразъем.

Под мобильным платежным решением будем понимать программно-аппаратную платформу для торгово-сервисных предприятий (далее – ТСП), позволяющую принимать платежи от физических лиц посредством смартфона/планшета и подключенного к нему считывающего устройства. Посредством mPOS возможно принимать оплату как бесконтактным способом (банковской картой, загруженной в мобильный телефон клиента с поддержкой NFC (далее – NFC-карта), или бесконтактной банковской картой), так и по обычным пластиковым картам (с магнитной полосой и/или EMV-чипом).

Кроме функций защищенного чтения карты и ввода PIN-кода у mPOS должна быть поддержка всех основных способов верификации владельца карты, шифрования данных при передаче между компонентами и процессинговой частью системы, а также возможность печати чеков или их отправки по SMS и электронной почте.

На стороне сервис-провайдера или банка-эквайера, которые занимаются приемом и дальнейшей обработкой данных при mPOS-платежах, используется back-end система (платежный шлюз), схожая с теми, что используются при интернет- или обычном POS-эквайринге.

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

Схема информационных потоков содержит 8 основных этапов (см. рис. 1):

этап 1. Сотрудник ТСП подключает считывающее устройство к мобильному устройству (смартфону или планшету), имеющему интернет-соединение. Запускает специальное мобильное приложение и в нем вводит сведения о покупке и сумму платежа;
этап 2. Клиент вставляет, прокатывает или подносит банковскую карту к считывающему устройству. В случае NFC-карты клиент на своем смартфоне открывает приложение "Кошелек" (Walet), выбирает действующую банковскую карту и подносит смартфон к считывающему устройству. В зависимости от параметров, заданных в карте, запрашивается ввод PIN-кода. В этом случае клиент вводит PIN-код посредством PIN-pad, который может быть встроен в считывающее устройство;
этап 3. Считывающее устройство считывает карточные данные, шифрует их и передает в мобильное устройство сотрудника ТСП;
этап 4. Мобильное устройство сотрудника отправляет зашифрованные данные в платежный шлюз, и из платежного шлюза данные передаются в эквайринговую систему. Кроме карточных данных, в зависимости от настроек, дополнительно могут быть переданы сведения о mPOS, транзакции, покупаемом товаре или услуге;
этап 5. Авторизационный запрос из эквайринговой системы передается в МПС. После обработки запроса результат (принято или отклонено) возвращается в эквайринговую систему. Если карта, по которой происходит оплата, выпущена тем же банком, через который осуществляется эквайринг, то запрос в МПС не передается;
этап 6. Результат авторизационного запроса передается в мобильное устройство;
этап 7. Если для карты требуется подпись ее владельца, то в мобильном приложении выводится соответствующая форма, и клиент расписывается (стилусом или пальцем);
этап 8. Сотрудник ТСП в мобильном платежном приложении выбирает метод отправки чека клиенту. Возможна отправка по SMS, электронной почте или на печать на локальное кассовое устройство.

В реализации описанного выше процесса могут участвовать следующие компании:

разработчики mPOS-устройств – осуществляют разработку и выпуск аппаратных средств, которые безопасно считывают карточные данные и PIN-код;
разработчики платежного ПО для мобильного устройства и/или платежного шлюза – разрабатывают клиентское ПО для ТСП и, возможно, ПО платежного шлюза;
разработчики платформы – компании-разработчики, создающие единую аппаратную и программную часть mPOS-решения для ее дальнейшей продажи сервис-провайдерам mPOS-решений или эквайерам;
сервис-провайдеры mPOS-решений – компании, выпускающие конечный продукт для ТСП. Компаниями данного типа являются банки-эквайеры или так называемые платежные посредники (payment facilitators). Эти компании могут либо самостоятельно разрабатывать все компоненты мобильного платежного решения, либо лицензировать отдельные компоненты разных производителей и интегрировать их между собой. Платежные посредники, за исключением банков-эквайеров, являются чем-то средним между сервис-провайдером и ТСП. Их клиентами являются ТСП, для которых взаимодействие с банком-эквайером становится прозрачным процессом, так как ответственность за расчеты с ТСП ложится на платежного посредника;
дистрибьюторы – компании, продвигающие на рынке те или иные mPOS-решения различных производителей и выполняющие функцию перепродажи mPOS-решения ТСП;
платежный сервис-провайдер (процессинговая компания, платежный шлюз) – компания, которая является посредником между сервис-провайдером mPOS-решений и банком-эквайером. Он обеспечивает информационное взаимодействие между мобильным устройством ТСП и эквайером;
эквайер – банк-эквайер или процессинговый центр, подключенный к МПС, обеспечивающий авторизацию платежей. Банки-эквайеры, с которыми сотрудничают сервис-провайдеры mPOS-решений, могут использоваться для расчетов с ТСП.

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

Перечни основных компонентов и типов бизнес-моделей приведены для того, чтобы понять, как должна разграничиваться ответственность за выполнение требований безопасности между всеми участниками экосистемы mPOS.

Стандарты PCI SSC

PCI DSS
В новой версии стандарта появились новые требования, которые как нельзя кстати относятся к безопасности mPOS. В частности, в разделе 9 добавился пункт 9.9, согласно которому необходимо вести учет устройств считывания карт, а также проводить периодическое обучение сотрудников/пользователей, обслуживающих устройства, для того чтобы они умели определять подмену mPOS или иные признаки скимминга. В случае с сервис-провайдерами mPOS-решений или эквайрингами при предоставлении клиентам считывающих устройств они должны будут разработать рекомендации и инструкции по защите от скимминга и довести их до сведения сотрудников ТСП. В рамках выполнения требования 12.8 сервис-провайдеры и эквайеры на уровне договорных отношений могут обязать ТСП выполнять соответствующие требования по безопасности mPOS.

Несмотря на то, что выполнение большинства требований безопасности ложится на различных сервис-провайдеров и банки, банки-эквайеры вправе потребовать от ТСП заполнения листов самооценки (SAQ) соответствующего типа (SAQ P2PE-HW в случае использования ТСП P2PE-решения, SAQ B-IP в случае использования mPOS со считывателем, сертифицированным по PCI PTS). В таблице указаны компоненты mPOS-решений, соответствующий стандарт, которому компонент должен соответствовать, и компания, ответственная за реализацию требований.

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

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

PCI PTS
Стандарт PCI PTS регламентирует требования к безопасности для Point of interaction devices (POI) и Hardware Security Modules (HSM). Считывающее устройство, подключаемое к мобильному устройству, является POI. Как упоминалось выше, в mPOS-решениях используется два класса POI: PIN Entry Device (PED) и Secure Card Reader (SCR). В зависимости от того, к POI какого типа относится считывающее устройство, определяются группы требований PCI PTS, которым устройство должно соответствовать.

В настоящий момент в некоторых предлагаемых на отечественном рынке mPOS-решениях используются считыватели no-name-производителей. Использование таких считывателей не гарантирует безопасной передачи данных между устройствами и делает возможным передачу в мобильное устройство номера карты в открытом виде. Поэтому, выбирая mPOS-решение, необходимо убедиться, что сервис-провайдер предлагает сертифицированное по PCI PTS считывающее устройство.

Существуют две бизнес-модели разработки клиентского ПО: разработка для собственного проекта, когда разработчик создает mPOS-решение и выводит его на рынок под собственным брендом: в этом случае разработчик будет являться сервис-провайдером mPOS-решения; – и разработка конечного решения для дальнейшего лицензирования компаниями, которые интегрируют компоненты разных производителей между собой и на их основе создают свои mPOS-решения.

PA-DSS
Для mPOS-решений PA-DSS в обязательном порядке применим к прошивкам устройств, считывающим карточные данные. Для программного обеспечения, устанавливаемого на мобильное устройство сотрудника ТСП, данный стандарт является рекомендательным. Это связано с тем, что мобильное устройство является недоверенной и слабоконтролируемой средой. Например, на устройстве может быть выполнен jailbreak, который на порядок снижает безопасность устройства и не гарантирует безопасности установленного платежного приложения. Именно поэтому МПС запрещают использовать мобильные устройства для ввода PIN-кода и требуют, чтобы данные от считывающего устройства приходили в мобильное ПО в зашифрованном виде и далее в том же виде передавались в эквайринг. В этом случае данные платежных карт не будут в открытом виде обрабатываться и храниться в мобильном устройстве, а значит, и требования PA-DSS не применимы.

В версии 3.0 стандарта появились новые требования, на которые разработчикам прошивок для считывающих устройств и коробочных платежных приложений следует обратить внимание в первую очередь. Во-первых, каждое выпускаемое обновление должно проходить отдельную сертификацию. Во-вторых, теперь клиенты должны использовать только те версии (обновления) ПО, которые являются сертифицированными и приведены на сайте Совета PCI.

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

В перечень всех основных компонентов экосистемы mPOS входит:

считывающее устройство;
платежное приложение для мобильного устройства;
платежный шлюз;
эквайринговая система, подключенная к МПС.

В отличие от PCI DSS, который распространяется только на информационную инфраструктуру, PCI P2PE является более комплексным и распространяется не только на инфраструктуру, но и на считывающие устройства и программное обеспечение POI-терминалов (в приложении к mPOS – это считывающие устройства). Стандарт состоит из 6 доменов, требования которых основаны на действующих стандартах PCI: считывающие устройства должны удовлетворять требованиям PCI PTS SRED; программное обеспечение считывающих устройств – PA-DSS; управление ключами шифрования – PCI PIN Security Requirements; платежная информационная инфраструктура ТСП – PCI DSS. Если решение сертифицировано по PCI P2PE, это значит, что данные между всеми подсистемами (от считывателя к мобильному устройству в ПО, от ПО в процессинг и далее) передаются в шифрованном виде, и все подсистемы выполняют требования соответствующих стандартов PCI.

По требованиям P2PE могут быть сертифицированы как отдельные компоненты, так и готовые решения.

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

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

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

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

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

Можно ли не проходить сертификацию PCI DSS

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

Кому нужно получать сертификат PCI DSS и что будет, если этого не сделать

Ответ на вопрос «кому?» очень прост: каждой организации, обрабатывающей данные платёжных карт. Даже если компания не хранит эти данные, но передаёт их по сети, использует эти данные или может получить доступ к ним, то она автоматически становится участником платёжной системы. И обязана пройти сертификацию PCI DSS.

Что будет, если не получать сертификат PCI DSS. Если проигнорировать требования стандарта, компанию ждут неприятности. Ей грозит расторжение или отказ в заключении договора на приобретение услуг международных платежных систем. Другими словами, невозможно будет работать с карточными платежами.

Мобильные платежные технологии и требования по безопасности PCI SSC

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

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

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

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

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

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

Изначально у каждой платёжной системы — 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, но конкретно к нашей истории он не подходил. Поэтому выполнять анализ кода на безопасность стал человек Пётр. Именно его мы сдавали как статический анализатор. Человек Пётр требованиям к анализатору соответствовал. Примерно в том же ключе шли некоторые другие пункты.

Мобильные платежные технологии и требования по безопасности PCI SSC

Мобильные платежные решения еще недостаточно широко представлены на мировом рынке и в нашей стране в частности. Тем не менее, интерес к подобным решениям со стороны fintech-разработчиков, бизнеса и торгово-сервисных предприятий с каждым годом растет.

Андрей Гайко
Сертифицированный QSA-аудитор Digital Security

Как шёл аудит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Виды сертификации

Первые рекомендации по безопасности мобильных платежных решений были выпущены Visa в 2011 г. В них содержались общие рекомендации для разработчиков и ТСП в части безопасности использования мобильных платежных решений. В 2012 г. Советом PCI SSC были выпущены более детальные рекомендации для разработчиков. На сегодняшний день МПС и PCI SSC почти каждый год выпускают обновленные рекомендации по безопасности mPOS.

Кроме рекомендаций Visa и MasterCard разработали программы сертификации поставщиков мобильных платежных решений. По сути, обе программы достаточно похожи, и с большой вероятностью можно утверждать, что разработка решения согласно требованиям одной из МПС может быть сертифицирована у другой. Обе МПС ведут реестры сертифицированных компаний и mPOS-решений.

Далее будут описаны особенности применения каждого из стандартов PCI SSC к mPOS-решениям.

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