Що таке pci dss і як відбувається перевірка на відповідність стандарту

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

Якщо спробувати забити абревіатуру PCI DSS в Google або пошукати по ній на Хабре, то можна виявити досить багато статей, що описують цей стандарт. Тут же з'ясується, що цільовою аудиторією всіх цих матеріалів будуть ті, хто так чи інакше пов'язаний з електронною комерцією. Головним чином це платіжні агрегатори і процесингові центри, а вже потім розробники інтернет-магазинів.

Будь-який вид електронної комерції так чи інакше заснований на тому, що покупці, охочі придбати товар, повинні будуть розплатитися за нього. Незважаючи на те, що можливість розплатитися архаїчним способом (віддати гроші кур'єру при зустрічі) найбільш популярна вУкаіни, є велика ймовірність, що покупець віддасть перевагу скористатися своєю платіжною карткою. Тут розробникам магазину доведеться мати справу з такою делікатною матерією як особисті дані користувачів, які ще й пов'язані з їх фінансами. Навряд чи хтось із клієнтів магазину захоче, щоб все це стало надбанням громадськості, тому тут доводиться вдаватися до продуманим і багаторазово перевіреним рішенням.

Створення цілого інтернет-магазину з нуля - м'яко кажучи, завдання непросте. Тому на ринку досить багато фреймворків, які допомагають розробникам з цим (у всіх на слуху Magento, наприклад). Завдання прийому платежів, як одну з найважливіших, тому що вона пов'язана з грошима, включають в себе всі рішення для електронної комерції. Розробники, що мали з цим справа, знають, що це досить проста послідовність кроків, яка часто виглядає як «качаємо код бібліотеки для платіжного шлюзу XYZ», «налаштовуємо його» (всі зазвичай зводиться до отримання та використання спеціального ключа, що дозволяє шлюзу зрозуміти з яким магазином він має справу), «трохи допілівать» і «вивантажуємо на продакшн».

Як правило, це не викликає істотних проблем. Правда, після того, як користувач вашого магазину перейшов на сторінку оплати обраного платіжного шлюзу, ввів дані своєї платіжної карти і натиснув на кнопку «Оплатити», втрутитися в процес вже не вийде - хіба тільки обробити відповідь шлюзу на своєму боці і показати користувачеві красиву сторінку з вдячністю (якщо все пройшло нормально) або вибачитися (якщо щось пішло не так).

Може бути хлопці з цього шлюзу і змогли налаштувати себе https, купили сертифікат і навіть великими літерами написали на своєму сайті, що все дуже добре і все дуже захищене. Але єдиним по-справжньому надійним способом переконатися в цьому є виконання якихось процедур, що засвідчують безпеку внутрішнього коду платіжного шлюзу. І, звичайно, бажано, щоб пройти таку перевірку було б складніше, ніж написати на своєму сайті трохи красивого HTML - «100% гарантія безпеки».

Що таке 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 груп, виглядає наступним чином:

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

Тут добре помітно, що мова йде і про програмну частину, і про «фізичному компоненті» - простіше кажучи, перевіряється все. При цьому під словом «перевірка» розуміється буквальне присутність того, хто цю перевірку виконує, в офісі тієї компанії, яку перевіряють. Уповноважений аудитор, що володіє статусом QSA (Qualified Security Assessor - а цей статут підтверджується Радою PCI SSC) має право поспілкуватися зі співробітником платіжного шлюзу (для цього є спеціальна процедура інтерв'ю), вивчити налаштування компонентів системи, зробити скріншоти і просто подивитися «як це працює» . Аудитором PayOnline в останні роки виступає компанія Deiteriy. Її висновки визнаються міжнародними платіжними системами Visa, MasterCard, МИР, American Express, Discover і JCB.

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

У разі компрометації даних користувача платіжна система зобов'язана повідомити його самого і банк-емітент, що випустив «засвічену» карту. Крім того, необхідно було видалити лист із вкладеннями-картинками з клієнтської поштової програми оператора служби підтримки, а також на поштовому сервері. Все це робилося для того, щоб слідувати золотому правилу забезпечення безпеки індустрії платіжних карт - «Якщо тобі не потрібна ця інформація, то не зберігай її».

Інтеграція PayOnline з інтернет-магазином

Як уже згадувалося вище, завдання інтеграції конкретного інтернет-магазину з платіжною системою навряд чи можна назвати складною. В інтернеті можна знайти безліч прикладів для багатьох шлюзів. Все зазвичай зводиться до установки на сервер спеціально написаної бібліотеки (у нас їх багато і під різні платформи) і написання якогось клієнтського коду, який буде збирати інформацію для користувача форми і відправляти її платіжному шлюзу. Єдиним моментом, на який хотілося б звернути увагу, має бути місце розташування самої платіжної форми - буде вона знаходитися на стороні інтернет-магазину або буде працювати на стороні PayOnline. Незважаючи на те, що багато рішень цілком можуть дозволити приймати платежі прямо на своєму сайті, в разі відсутності у мерчанта власного сертифіката PCI-DSS, необхідно буде організувати все так, щоб платежі виконувалися на стороні платіжного шлюзу. Обгрунтування тут одне - це безпека фінансових даних користувача. При цьому платіжну форму можна кастомизировать під компанію, так що відторгнення у кінцевого користувача не виникне.

У нас є бібліотеки для організації платежів для десктопних і мобільних рішень, включаючи і Windows Phone (хоча позиції цієї платформи з точки зору популярності у користувачів набагато слабкіше, ніж у тих же Android або iOS). Говорити про бібліотеку для PHP ми навіть не будемо - це практично само собою розуміється. У нас також є SDK для .NET-рішень. Часто запитують, чому для Android обраний не традиційний підхід - бібліотека на Java - а використовується Node.js. Таке рішення було прийнято деякий час назад - інтегрувати такий код трохи простіше, ніж написаний на Java, так само як і відповідати вимогам субстандарта PCI PA-DSS. Що стосується майбутніх інтеграцій, то ми зараз маємо в своєму розпорядженні адаптивними платіжними формами, які чудово працюють в нативних мобільних додатках, інтегрованих в додаток через WebView, і відповідають всім вимогам PCI PA-DSS.

Що отримує інтернет-магазин

Серед основних переваг системи електронних платежів PayOnline ми можемо виділити особливо наші технічні можливості, націлені на збільшення конверсії в успішні платежі. В першу чергу, звичайно, це тонка робота з 3-D Secure, що дозволяє зберегти високий рівень захисту від шахрайських операцій і одночасно збільшити платіжну конверсію.

Ми уважно вивчаємо поведінку платників, яке з року в рік змінюється слідом за технологічним прогресом. Завдяки можливості вимірювати конверсію і поведінку людини на платіжній сторінці в момент заповнення даних і здійснення платежу, ми технологічно дозволяємо своїм клієнтам крок за кроком відстежити шлях покупця, уявити себе на його місці і максимально спростити його призначений для користувача досвід на основі отриманої статистики. У разі ж, якщо при здійсненні платежу у покупця з якоїсь причини не виходить провести оплату, магазин отримує від процесингового центру точну причину відхилення, далі магазин транслює причину відхилення платнику в будь-якому кастомизировать вигляді. Таким чином, клієнт відразу розуміє, чому платіж не пройшов і що йому необхідно зробити, щоб придбати товар або послугу.

Якщо вас зацікавила така можливість, звертайтеся. наші фахівці нададуть додаткову інформацію та, в разі необхідності, допоможуть налаштувати прийом платежів на сайті і в мобільному додатку по захищеному шлюзу, який відповідає вимогам стандарту PCI DSS 3.1.