Кратък отговор.
PCI DSS е отрасловият стандарт за защита на данните за платежни карти. Той засяга търговци, доставчици на услуги и системи, които обработват такива данни или влияят върху сигурността им. Актуалната версия е PCI DSS v4.0.1. Платежната среда и ролята определят обхвата; начинът на доказване се съгласува с обслужващата банка или платежната марка, например чрез SAQ или ROC.
PCI DSS 4.0 и актуалната версия.
PCI DSS свързва технически и оперативни изисквания за сигурност на платежни данни. PCI Security Standards Council, съкратено PCI SSC, разработва стандарта и подпомагащите го инструменти. Как се доказва спазването в конкретна платежна програма обаче определят компетентните приемащи страни, обикновено обслужващи банки и платежни марки; PCI SSC FAQ 1473 обяснява това разделение на ролите.
PCI DSS v4.0.1 е версията, посочена в официалната Document Library. Според публикацията на PCI SSC за преработката v4.0 е оттеглена на 31 декември 2024 г. Вече предвидената дата 31 март 2025 г. за новите изисквания на v4 остава непроменена. Към датата на тази страница срокът е в миналото; той не е предстоящ срок за въвеждане.
Успешно приключено доказване не замества текущата защита. За практическата организация промените в платежни потоци, приложения и доставчици трябва да са повод за нов преглед на договорения обхват. Нова интеграция на плащане може да създаде различни зависимости от предходно оцененото решение, въпреки че същото предприятие продължава да приема плащания.
За кого се прилага PCI DSS.
Според прегледа на PCI SSC PCI DSS е насочен не само към организации, които съхраняват, обработват или предават картови данни. Възможното въздействие върху сигурността на средата за данни на картодържатели, Cardholder Data Environment или CDE, също участва в разглеждането. Затова търговци и доставчици на услуги трябва първо да опишат конкретната си роля и действително предоставяните услуги.
Възложено навън обработване на плащания не е автоматично освобождаване. PCI SSC FAQ 1092 разграничава евентуално по-малък пряк обхват на изискванията от продължаващата отговорност за подходящи доставчици, договорени отговорности и изискано доказване. Дори при Hosted Checkout изяснете с компетентната страна какви предпоставки трябва да изпълнява избраното техническо интегриране.
Границата се доказва чрез ефективни мерки, а не само чрез име в архитектурна диаграма. PCI SSC FAQ 1115 пояснява, че трябва да се проверят свързаните системи и действителната ефективност на сегментирането. Преждевременното изключване на административни достъпи, поддържащи услуги или интерфейси може да доведе до непълен обхват на проверката.
Подреждане на изискванията на PCI DSS в експлоатацията.
Прилагането свързва защитата на платежната среда с проследими оперативни процедури. Следните шест работни области са редакционна ориентация за планиране, а не възпроизвеждане на дванадесетте официални изисквания или отделни точки за проверка; конкретната им приложимост се проверява спрямо потвърдения обхват.
Разбираемо представяне на платежните потоци и обхвата.
Проследете на практика къде възниква платежната информация, кои компоненти участват и кои лица или доставчици могат да влияят върху нея. Документирайте потвърдената граница заедно с допусканията ѝ. Разбираемо описание помага на разработката, експлоатацията и приемащата страна да говорят за един и същ платежен поток.
Сигурна експлоатация на системите и промените.
Възложете ясни отговорници на участващите приложения и инфраструктурни компоненти. Свържете промените с въпроса дали нови връзки, функции или зависимости променят потвърдения обхват. За ежедневната работа проследима история на промените е по-полезна от моментна снимка, съставена само за датата на проверката.
Ограничаване на използването и предаването на данни.
Като практическа отправна точка проверете кои платежни данни действително са необходими за избрания процес и къде могат да възникнат копия. Отчетете експорти, дневници и поддържащи процеси. Подробното планиране на сигурността трябва да съответства на видовете данни и целта на употреба; общ етикет за поверителност още не обяснява тези решения.
Проследимо организиране на достъпа.
Свържете служебните отговорности с действително предоставените технически възможности. Освен служителите разгледайте служебните акаунти, административните достъпи и доставчиците. За организацията на работата е препоръчителен ясен отговор кой одобрява достъп, кой обработва промените и по какво се разпознава навреме отнет достъп.
Проверка на експлоатацията и обработване на констатациите.
Планирайте подходящи записи и проверки съвместно с отговорниците за платежната среда. Отделно сканиране или тест за проникване описва само съответния си предмет. При констатации документирайте каква промяна следва и как се проверява ефектът ѝ, вместо да приравнявате резултат от тест с цялото доказване по PCI DSS.
Включване на доставчиците и инцидентите.
Определете оперативни лица за контакт и подхода при отклонения. За възложени навън услуги собствените задачи трябва да остават разбираеми наред с ангажиментите на доставчика. PCI SSC FAQ 1576 обяснява, че доказателство за доставчик трябва да обхваща използваните услуги; произволен фирмен документ не е автоматично достатъчен за това.
Прилагане на PCI DSS като постоянна задача.
Съгласувайте ролята и начина на доказване.
Като практическо начало изяснете с обслужващата банка или платежната марка ролята си, очакваното доказателство и компетентното лице за контакт, преди да изберете формуляр.
Опишете един платежен поток.
Опишете участващите данни, приложения, системи и доставчици от началото на плащането до оставащите оперативни записи.
Потвърдете обхвата.
Проверете относимите връзки и компонентите, влияещи върху сигурността, и възложете експертна оценка на границите, включително възможното сегментиране.
Утвърдете задачите в експлоатацията.
Възложете защитните мерки и споделените отговорности на конкретни лица и свържете прилагането им с подходящи записи.
Подгответе последователни доказателства.
Проверете дали изисканите документи описват една и съща услуга, роля и обхват и дали отворените решения са обработени проследимо.
Проследявайте промените и последващите проверки.
Съгласувайте необходимите интервали за доказване и при промени проверявайте дали обхватът, доказателствата на доставчиците и оперативните отговорности все още съответстват.
PCI сертифициране и действителната форма на доказване.
Признатото доказване по PCI DSS използва предвидените за това официални документи. SAQ документира допустима самооценка, ROC — резултатите от съответния път на проверка, а AOC — свързаното потвърждение. Според PCI SSC FAQ 1220 произволни документи, наречени сертификат за съответствие, не заместват официалните образци.
Приемащата страна определя изисквания начин; при съответна проверка може да участва Qualified Security Assessor, съкратено QSA. Според PCI SSC FAQ 1473 обхватът и приложимостта трябва да се оценят правилно. Затова изборът на име на SAQ още не потвърждава, че критериите му за допустимост са изпълнени или всички относими изисквания са приложени.
Подходящият образец също трябва да се използва в актуалната си версия. PCI SSC промени правилата за SAQ A към 31 март 2025 г. и изрично уточни, че отпаднали отделни точки за проверка във въпросника не отменят основните изисквания на PCI DSS. Съгласувайте датите за доказване и последващите задължения за Вашия случай, вместо да приемате общ срок на сертификат.
Мястото на другите рамки.
ISO 27001 разглежда управлението на информационната сигурност в определения обхват; доказването по PCI DSS е отделно решение за платежната среда. CIS Controls подпомага общото приоритизиране на работата по сигурността, но не определя път за PCI валидиране. ОРЗД се отнася до обработването на лични данни и трябва да се проверява независимо от доказването за платежни данни.
В Secani.
Secani предлага собствен редакционен каталог за предприятията по PCI DSS v4.0.1. Профилът включва наред с друго обхвата на CDE, роля на търговец или доставчик на услуги и договорения път SAQ/ROC. Тези работни данни подпомагат структурираната обработка; те не заместват нито официалните документи за проверка, нито потвърждението на допустимостта или преценката на компетентната страна.
Започнете с конкретен платежен поток.
Изберете действително използван платежен поток и посочете неговата бизнес и техническа отговорност. Документирайте кои услуги предоставяте сами и кои поема доставчик. След това съгласувайте очакваното доказателство с компетентната страна, преди да планирате усилията въз основа на привидно подходящ въпросник.
Източници.
- PCI SSC — преглед на PCI DSS и целева група
- PCI SSC — официална Document Library
- PCI SSC — публикуване на PCI DSS v4.0.1
- PCI SSC FAQ 1473 — компетентни страни и начин на доказване
- PCI SSC FAQ 1092 — възложено навън обработване на плащания
- PCI SSC FAQ 1576 — доказателства на доставчици на услуги
- PCI SSC FAQ 1220 — официални документи вместо сертификати за съответствие
- PCI SSC FAQ 1115 — свързани системи и сегментиране
- PCI SSC — промени в SAQ A към 31 март 2025 г.
- PCI SSC — бюлетин за SAQ от 15 октомври 2024 г.
Често задавани въпроси.
Не, не автоматично. Възлагането може да промени прекия обхват; отговорността за подходящи доставчици, ясни отговорности и изискано доказване трябва да се разгледа отделно.
Не само според желаните усилия. Критериите за допустимост трябва да са изпълнени, а изискваният начин на доказване трябва да се съгласува с приемащата страна.
Произволни сертификати за съответствие не са признат заместител на официалните документи. Определящи са договореният път на проверка и съответните официални доклади или потвърждения.
Не. Сертификат за СУИС се отнася до посочения обхват на системата за управление; изискванията и начинът на доказване за платежната среда трябва да се изяснят отделно.
Определете платежния поток.
Обсъдете как да работите по обхвата, задачите и доказателствата в Secani.
Тази страница представя PCI DSS със собствени думи и не замества официалните документи на PCI SSC или експертна проверка. Изискванията на съответната платежна програма и решенията на компетентната страна трябва да се спазват отделно.