Мобильные платежные решения еще недостаточно широко представлены на мировом рынке и в нашей стране в частности. Тем не менее, интерес к подобным решениям со стороны fintech-разработчиков, бизнеса и торгово-сервисных предприятий с каждым годом растет.
Андрей Гайко
Сертифицированный QSA-аудитор Digital Security
Мобильное платежное решение (mPOS) состоит из следующих основных компонентов:
Под мобильным платежным решением будем понимать программно-аппаратную платформу для торгово-сервисных предприятий (далее – ТСП), позволяющую принимать платежи от физических лиц посредством смартфона/планшета и подключенного к нему считывающего устройства. Посредством mPOS возможно принимать оплату как бесконтактным способом (банковской картой, загруженной в мобильный телефон клиента с поддержкой NFC (далее – NFC-карта), или бесконтактной банковской картой), так и по обычным пластиковым картам (с магнитной полосой и/или EMV-чипом).
Кроме функций защищенного чтения карты и ввода PIN-кода у mPOS должна быть поддержка всех основных способов верификации владельца карты, шифрования данных при передаче между компонентами и процессинговой частью системы, а также возможность печати чеков или их отправки по SMS и электронной почте.
На стороне сервис-провайдера или банка-эквайера, которые занимаются приемом и дальнейшей обработкой данных при mPOS-платежах, используется back-end система (платежный шлюз), схожая с теми, что используются при интернет- или обычном POS-эквайринге.
Для того, чтобы понять, какие требования по безопасности должны предъявляться, на техническом уровне необходимо определить основные компоненты экосистемы mPOS и существующие информационные потоки. Для понимания ответственности субъектов экосистемы mPOS за безопасность платежей на бизнес-уровне необходимо определить существующие бизнес-модели участников платежного процесса.
Схема информационных потоков содержит 8 основных этапов (см. рис. 1):
В реализации описанного выше процесса могут участвовать следующие компании:
Следует отметить, что компания может выполнять не только одну из указанных ролей. Возможна ситуация, когда компания может полностью разработать все программные и аппаратные компоненты mPOS-решения. В зависимости от того, какие функции будут выполняться компанией, зависит, какие требования по безопасности ею должны соблюдаться.
Перечни основных компонентов и типов бизнес-моделей приведены для того, чтобы понять, как должна разграничиваться ответственность за выполнение требований безопасности между всеми участниками экосистемы mPOS.
Первые рекомендации по безопасности мобильных платежных решений были выпущены Visa в 2011 г. В них содержались общие рекомендации для разработчиков и ТСП в части безопасности использования мобильных платежных решений. В 2012 г. Советом PCI SSC были выпущены более детальные рекомендации для разработчиков. На сегодняшний день МПС и PCI SSC почти каждый год выпускают обновленные рекомендации по безопасности mPOS.
Кроме рекомендаций Visa и MasterCard разработали программы сертификации поставщиков мобильных платежных решений. По сути, обе программы достаточно похожи, и с большой вероятностью можно утверждать, что разработка решения согласно требованиям одной из МПС может быть сертифицирована у другой. Обе МПС ведут реестры сертифицированных компаний и mPOS-решений.
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 (Payment Card Industry Data Security Standard) - стандарт безопасности данных индустрии платёжных карт, разработанный Советом по стандартам безопасности индустрии платёжных карт (Payment Card Industry Security Standards Council, PCI SSC), который учредили Visa, MasterCard, American Express, JCB и Discover.
Требования стандарта распространяются на все компании, работающие с международными платёжными системами: банки, торгово-сервисные предприятия, поставщиков технологических услуг и другие организации, деятельность которых связана с обработкой, передачей и хранением данных о держателях платёжных карт.
Стандарт PCI DSS выдвигает требования к защищённости компонентов инфраструктуры, в которой передаётся, обрабатывается или хранится информация о платёжных картах. Проверка платёжной инфраструктуры на соответствие этим требованиям выявляет причины, которые значительно снижают уровень её защищённости. Тесты на проникновение , которые входят в список обязательных мероприятий, регламентированных стандартом PCI DSS, показывают реальный уровень защищённости информационных ресурсов компании как с позиции злоумышленника, находящегося за пределами исследуемого периметра, так и с позиции сотрудника компании, имеющего доступ «изнутри».
Совет PCI DSS сформулировал ключевые требования по организации защиты данных в документе «Стандарт безопасности данных индустрии платёжных карт (PCI DSS). Требования и процедуры оценки безопасности. Версия 3.0». Эти требования сгруппированы таким образом, чтобы упростить процедуру аудита безопасности.
Скачать PCI DSS на русском языке.
Построить и поддерживать защищённые сети и системы
Защищать данные о держателях карт
Поддерживать программу управления уязвимостями
Внедрять строгие меры контроля доступа
Осуществлять регулярный мониторинг и тестирование сетей
Поддерживать политику информационной безопасности
«Перспективный мониторинг» помогает банкам, торгово-сервисным предприятиям, разработчикам финансовых сервисов подготовится к аудиту на соответствие PCI DSS и оказывает экспертную поддержку по выполнению требований стандарта.
В последнее время Visa и MasterCard все более активно требуют соответствия стандарту PCI DSS от платежных шлюзов, торгово-сервисных предприятий, подключенных к ним, а также от поставщиков услуг, которые могут влиять на безопасность карточных данных. В связи с этим вопрос соответствия требованиям стандарту PCI DSS становится важным не только для крупных игроков индустрии платежных карт, но и для небольших торгово-сервисных предприятий. В этой статье мы ответим на основные вопросы, которые волнуют организации, перед которыми встала задача сертификации по стандарту PCI DSS.
FAQ по PCI DSS для тех, кто интересуется сертификацией
# На кого распространяются требования стандарта PCI DSS?
В первую очередь стандарт определяет требования к организациям, в информационной инфраструктуре которых хранятся, обрабатываются или передаются данные платёжных карт, а также к организациям, которые могут влиять на безопасность этих данных. Цель стандарта достаточно очевидна - обеспечить безопасность обращения платёжных карт. С середины 2012 года все организации, вовлечённые в процесс хранения, обработки и передачи ДПК должны соответствовать требованиям PCI DSS, и компании на территории Российской Федерации не являются исключением.
Чтобы понять, попадает ли ваша организация под обязательное соблюдение требований стандарта PCI DSS, предлагаем воспользоваться несложной блок-схемой.
Рисунок 1. Определение необходимости соответствия стандарту PCI DSS
# Каковы требования стандарта PCI DSS?
Для соответствия стандарту необходимо выполнение требований, которые в общих чертах представлены двенадцатью разделами, приведёнными в таблице ниже.
Таблица 1. Верхнеуровневые требования стандарта PCI DSS
Если же несколько углубиться, стандарт требует прохождения порядка 440 проверочных процедур, которые должны дать положительный результат при проверке на соответствие требованиям.# Как можно подтвердить соответствие стандарту PCI DSS?
Существуют различные способы подтверждения соответствия требованиям стандарта PCI DSS, которые заключаются в проведении внешнего аудита (QSA), внутреннего аудита (ISA) или самооценки (SAQ) организации.
Особенности каждого из них проиллюстрированы в таблице.
Таблица 2. Способы подтверждения соответствия стандарту PCI DSS
Внешний аудит QSA (Qualified Security Assessor) | Внутренний аудит ISA (Internal Security Assessor) | Самооценка SAQ (Self Assessment Questionnaire) |
| Выполняется внешней аудиторской организацией QSA , сертифицированной Советом PCI SSС. | Выполняется внутренним прошедшим обучение и сертифицированным по программе Совета PCI SSC аудитором .Может быть проведен только в случае, если первично соответствие было подтверждено QSA-аудитом. | Выполняется самостоятельно путём заполнения листа самооценки. |
| В результате проверки QSA -аудиторы собирают свидетельства выполнения | В результате проверки ISA -аудиторы , как и при внешнем аудите, собирают свидетельства выполнения требований стандарта и сохраняют их в течение трёх лёт. | Сбор свидетельств выполнения требований стандарта не требуется. |
| По результатам проведённого аудита подготавливается отчёт о соответствии - ROC (Report on Compliance). | Самостоятельно заполняется лист самооценки SAQ . |
# В какой ситуации необходимо проводить внешний аудит, а в какой - внутренний? Или же достаточно ограничиться самооценкой организации?
Ответы на эти вопросы зависят от типа организации и количества обрабатываемых транзакций в год. Нельзя руководствоваться случайным выбором, поскольку существуют документированные правила, регулирующие, какой способ подтверждения соответствия стандарту будет использовать организация. Все эти требования устанавливаются международными платёжными системами, наиболее популярными из них в России являются Visa и MasterCard. Даже существует классификация, согласно которой выделяют два типа организаций: торгово-сервисные предприятия (мерчанты) и поставщики услуг.
В зависимости от количества обрабатываемых в год транзакций, мерчанты и поставщики услуг могут быть отнесены к различным уровням.
Допустим, торгово-сервисное предприятие обрабатывает до 1 млн транзакций в год с применением электронной коммерции. По классификации Visa и MasterCard (рис. 2) организация будет относиться к уровню 3. Следовательно, для подтверждения соответствия PCI DSS необходимо проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV (Approved Scanning Vendor) и ежегодная самооценка SAQ. В таком случае организации не нужно заниматься сбором свидетельств соответствия, поскольку для текущего уровня в этом нет необходимости. Отчётным документом будет выступать заполненный лист самооценки SAQ.
Или же рассмотрим пример с поставщиком облачных услуг, который обрабатывает более 300 тысяч транзакций в год. Согласно установленной классификации Visa или MasterCard, поставщик услуг будет относиться к уровню 1. А значит, как указано на рисунке 2, необходимо проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV, а также внешнего ежегодного QSA аудита.
Рисунок 2. Классификация уровней и требования подтверждения соответствия стандарту PCI DSS
# Представляет ли однократное нарушение сроков ASV-сканирования серьёзный риск с точки зрения соответствия PCI DSS?| «Несмотря на то, что на территории Российской Федерации уже начала функционировать своя Национальная система платежных карт (НСПК), требования международных платежных систем не упразднили. Наоборот, в последнее время от Visa и MasterCard участились письма банкам-эквайерам о том, чтобы последние требовали соответствия стандарту PCI DSS от платежных шлюзов, торгово-сервисных предприятий, подключенных к ним, а также от поставщиков услуг, которые могут влиять на безопасность карточных данных. В связи с этим вопрос соответствия требованиям стандарту PCI DSS становится важным не только для крупных игроков индустрии платежных карт, но и для небольших торгово-сервисных предприятий. Актуальной для российского рынка сейчас является услуга по управляемым сервисам. Заключается она в том, что поставщик услуг предоставляет клиентам не только оборудование или виртуальную информационную инфраструктуру в аренду, но и услуги по ее администрированию в соответствии с требованиями стандарта PCI DSS. Особенно полезно это для небольших торгово-сервисных предприятий, которые не имеют своих подразделений информационных технологий и информационной безопасности. Обращение к сертифицированным поставщикам услуг помогает существенно упростить процесс сертификации по стандарту PCI DSS для торгово-сервисных предприятий и обеспечить защиту данных платежных карт на должном уровне». |
Друзья, мы расширяем ассортимент предоставляемых услуг и в ближайшее время добавим на наш сайт возможность заказывать сервисы по сканированию сайтов на наличие вредоносного кода (ASV-сканирование), которые требует сертификация PCI DSS. В связи с этим мы начинаем новую рубрику публикаций, связанных со стандартами и требованиями безопасности данных. И в первую очередь мы хотим поговорить о сертификации PCI DSS. Использование оплаты кредитными и дебетовыми картами предусматривает возможную передачу, хранение и обработку данных платежных карт, что повышает риски киберпреступности. В связи с этим MasterCard, Visa, American Express и другие платежные системы выдвигают определенные требования по безопасности к торговым предприятиям и поставщикам услуг, которые работают с данными платежных карт. Эти требования описаны в стандарте PCI DSS. Давайте разберемся, что такое сертификация PCI DSS и какие основные положения нужно знать.
Таким образом, требования стандартов PCI DSS применяются ко всем организациям, независимо от их размера или количества проводимых транзакций, которые принимают, передают, обрабатывают или хранят любую информацию держателей кредитных карт, или же если бизнес-процессы в этих организациях могут влиять на безопасность платежных карт.
| Контрольные объекты | Требования PCI DSS |
|---|---|
| Создание и поддержка безопасной сети | 1. Установка и поддержка конфигурации файервола для защиты данных владельцев платежных карт |
| 2. Отказ от использования,параметров по умолчанию для систем паролей и других параметров безопасности | |
| Защита данных владельцев платежных карт | 3. Защита полученных данных владельцев платежных карт |
| 4. Шифрование передачи данных владельцев платежных карт по открытым публичным сетям | |
| Поддержка программы по управлению уязвимостями | 5. Использование и регулярное обновление антивирусного ПО на всех системах, которые обычно подвергаются действию вредоносных программ |
| 6. Разработка и поддержка защищенных систем и приложений | |
| Внедрение строгого контроля доступа | 7. Ограничение доступа к данным владельцев платежных карт по принципу служебной необходимости |
| 8. Присвоение уникального идентификационного номера каждому человеку с доступом к ЭВМ | |
| 9. Ограничение физического доступа к данным владельцев платежных карт | |
| Регулярный мониторинг и проверка сетей | 10. Отслеживание и мониторинг доступа к ресурсам сетей и данным владельцев платежных карт |
| 11. Регулярная проверка систем и процессов безопасности | |
| Поддержка политики безопасности информации | 12. Поддержка политики, адресованной на обеспечение безопасности данных |
| Уровень | Описание | Сертификация PCI DSS включает: |
|---|---|---|
| 4 | Торгово-сервисные предприятия, обрабатывающие менее 20 тыс. транзакций в год в области электронной торговли, а также Все остальные торгово-сервисные предприятия, не перечисленные в остальных уровнях, которые обрабатывают до 1 млн. транзакций в год, независимо от канала их получения. | Ежегодно: рекомендовано заполнение анкеты самооценки безопасности (SAQ); Ежеквартально: рекомендовано ASV-сканирование; Банк-эквайер определяет требования соответствия. |
| 3 | Торгово-сервисные предприятия, обрабатывающие 20 тыс. - 1 млн. транзакций в области электронной торговли в год. | |
| 2 | Торгово-сервисные предприятия, обрабатывающие 1-6 млн. транзакций в год, независимо от канала их получения. | Ежегодно: заполнение анкеты самооценки безопасности (SAQ); Ежеквартально: рекомендовано ASV-сканирование. |
| 1 | Торгово-сервисные предприятия, которые обрабатывают более 6 млн. транзакций в год, независимо от канала их получения. | Ежегодно: аудит, выполняемый утвержденным аудитором систем безопасности (QSA-аудит); Ежеквартально: ASV-сканирование на наличие уязвимостей. |
Внимание! Эта статья о шине PCI и её производных PCI64 и PCI-X("Пи-си-ай Икс")! Не путайте её с более новой шиной ("Пи-си-ай Экспресс"), которая полностью несовместима с шинами, описанными в данном FAQ.
PCI 2.0
- первая версия базового стандарта, получившая широкое распространение, использовались как карты, так и слоты с сигнальным напряжением только 5В.PCI 2.1 - отличалась от 2.0 возможностью одновременной работы нескольких bus-master устройств (т.н. конкурентный режим), а также появлением универсальных карт расширения, способных работать как в 5В, так и в 3.3В слотах. Способность работать с 3.3В картами и наличие соответствующих линий питания в версии 2.1 являлась опциональной.Появились расширения PCI66 и PCI64.
PCI 2.2
- версия базового стандарта шины, допускающая подключение карт расширения с сигнальным напряжением как 5В, так и 3.3В. 32-битные версии этих стандартов являлись наиболее распространённым типом слотов на на момент написания FAQ. Используются слоты типа 32-бита, 5В.
Cделанные в соответствии с этими стандартами карты расширения имеют универсальный разъём и способны работать практически во всех более поздних разновидностях слотов шины PCI, а также, в некоторых случаях, и в слотах 2.1.
PCI 2.3
- следующая версия общего стандарта на шину PCI, слоты расширения, соответствующие этому стандарту, несовместимы с картами PCI 5В, несмотря на продолжающееся использование 32-битных слотов с 5В-ключом. Карты расширения имеют универсальный разъём, но не способны работать в 5В-слотах ранних версий (до 2.1 включительно).
Напоминаем, что напряжение питания (не сигнальное!) 5В сохраняется абсолютно на всех версиях разъёмов шины PCI.
PCI 64
- расширение базового стандарта PCI, появившееся в версии 2.1, удваивающее число линий данных, и, следовательно, пропускную способность. Cлот PCI64 является удлинённой версией обычного PCI-слота.
Формально совместимость 32-битных карт с 64-битным слотами (при условии наличия общего поддерживаемого сигнального напряжения) полная, а совместимость 64-битной карты с 32-битным слотами является ограниченной (в любом случае произойдёт потеря производительности), точные данные в каждом конкретном случае можно узнать из спецификаций устройства.
Первые версии PCI64 (производные от PCI 2.1)использовали слот PCI 64-бита 5В и работали на тактовой частоте 33МГц.
PCI 66 - появившееся в версии 2.1 расширение стандарта PCI с поддержкой тактовой частоты 66МГц, также, как и PCI64 позволяет удвоить пропускную способность. Начиная с версии 2.2 использует 3.3В-слоты (32-битный вариант на ПК практически не встречается), карты имеют универсальный либо 3.3В форм-фактор. (Имелись и основанные на версии 2.1 казуистически редкие на рынке ПК 5В 66МГц решения, подобные слоты и платы были совместимы только между собой)
PCI 64/66
- комбинация двух вышеописанных технологий, позволяет учетверить скорость передачи данных по сравнению с базовым стандартом PCI, и использует 64 бита 3.3В слоты, совместимые только с универсальными и 3.3В 32-битными картами расширения. Карты стандарта PCI64/66 имеют универсальный (имеющий ограниченную совместимость с 32-битными слотами) либо 3.3В форм-фактор(последний вариант принципиально не совместим с 32-битными 33МГц слотами популярных стандартов)
В настоящее время под термином PCI64 подразумевается именно PCI64/66, поскольку 33МГц 5В 64-битные слоты не применяются уже достаточно давно.
PCI-X 1.0
- Расширение PCI64 с добавлением двух новых частот работы, 100 и 133МГц, а также механизма раздельных транзакций для улучшения производительности при одновременной работе нескольких устройств. Как правило, обратно совместима со всеми 3.3В и универсальными PCI-картами.
PCI-X карты обычно выполняются в 64-бит 3.3В формате и имеют ограниченную обратную совместимость со слотами PCI64/66, а некоторые PCI-X карты - в универсальном формате и способны работать (хотя практической ценности это почти не имеет) в обычном PCI 2.2/2.3.
В сложных случаях для того, чтобы быть полностью уверенным в работоспособности выбранной вами комбинации из мат.платы и карты расширения, случае надо посмотреть таблицы совместимости (compatibility lists) производителей обоих устройств.
PCI-X 2.0 - дальнейшее расширение возможностей PCI-X 1.0, добавлены скорости в 266 и 533МГц, а также коррекция ошибок чётности при передаче данных.(ECC). Допускает расщепление на 4 независимых 16-битных шины, что применяется исключительно во встраиваемых и промышленных системах, сигнальное напряжение снижено до 1.5В, но сохранена обратная совместимость разъёмов со всеми картами, использующими сигнальное напряжение 3.3В.
PCI-X 1066/PCI-X 2133 - проектируемые будущие варианты шины PCI-X, c результирующими частотами работы 1066 и 2133МГц соответственно, изначально предназначенные для подключения 10 и 40Гбит Ethernet адаптеров.
Для всех вариантов шины PCI-X существуют следующие ограничения по количеству подключаемых к каждой шине устройств:
66МГц - 4
100МГц - 2
133МГц - 1 (2, если одно или оба устройства не находятся на платах расширения, а уже интегрированы на одну плату вместе с контроллером)
266,533МГц и выше -1.
Вот почему в некоторых ситуациях для обеспечения стабильности работы нескольких установленных устройств необходимо ограничивать максимальную частоту работы использованной шины PCI-X (обычно это делается джамперами)
СompactPCI - стандарт для разъёмов и карт расширения, применяемый в промышленных и встраиваемых компьютерах. Механически не совместим ни с одним из "общих" стандартов.
MiniPCI - стандарт для плат и разъёмов для интеграции в ноутбуки (обычно используется для адаптеров беспроводной сети) и непосредственно на поверхность . Также механически ни с чем кроме себя не совместим.
Типы PCI-карт расширения:
Сводная таблица конструктивов карт и слотов в зависимости от версии стандарта:
Cводная таблица совместимости карт и слотов в зависимости от версии и конструктива:
| Карты | ||||||||
| Слоты | PCI 2.0/2.1 5B | PCI 2.1 универсальный | PCI 2.2/2.3 универсальный | PCI64/5B (33МГц) |
PCI64/универсальный | PCI64/3.3B | PCI-X/3.3B | PCI-X универсальный |
| PCI 2.0 | Совместимы | Совместимы | Несовместимы | Ограниченно совместимы с потерей производительности | Несовместимы | |||
| PCI 2.1 | Совместимы | Совместимы | Ограниченно совместимы | Ограниченно совместимы с потерей производительности | Ограниченно совместимы с потерей производительности | Несовместимы | ||
| PCI 2.2 | Совместимы | Ограниченно совместимы с потерей производительности | Ограниченно совместимы с потерей производительности | Несовместимы | Несовместимы | Ограниченно совместимы с потерей производительности | ||
| PCI 2.3 | Несовместимы | Ограниченно совместимы | Совместимы | Несовместимы | Ограниченно совместимы с потерей производительности | Несовместимы | Несовместимы | Ограниченно совместимы с потерей производительности |
| PCIБ 64/5B(33МГц) |
Совместимы | Совместимы | Ограниченно совместимы | Совместимы | Ограниченно совместимы с потерей производительности | Несовместимы | Несовместимы | Ограниченно совместимы с потерей производительности |
| PCI64/3.3B | Несовместимы | Ограниченно совместимы | Совместимы | Несовместимы | Совместимы | Совместимы | Ограниченно совместимы с потерей производительности | Ограниченно совместимы с потерей производительности |
| PCI-X | Несовместимы | Ограниченно совместимы | Совместимы | Несовместимы | Совместимы | |||
