Kas yra PCI DSS
- PCI DSS v4.0.1 paskelbta 2024 m. birželį; v4.0 nustojo galioti 2024 m. gruodžio 31 d.
- PCI DSS v4.0.1 ateities datos reikalavimai, įskaitant mokėjimo puslapio skriptų kontrolę (6.4.3 ir 11.6.1), privalomi nuo 2025 m. kovo 31 d.
- 2025 m. sausio 30 d. PCI SSC iš SAQ A pašalino 6.4.3, 11.6.1 ir 12.3.1 reikalavimus, bet pridėjo kriterijų patvirtinti, kad svetainė nepažeidžiama skriptų atakomis.
- Pagal Visa kriterijus prekybininkas, turintis iki 20 000 el. prekybos operacijų per metus, priskiriamas 4 lygiui ir atitiktį tvirtina SAQ klausimynu.
- Po autorizacijos negalima saugoti kortelės saugos kodo (CVC2/CVV2), PIN ir visos magnetinės juostos ar lusto informacijos.
- PCI DSS nėra įstatymas – jis taikomas per mokėjimų tiekėjų sutartis, o kortelių duomenų nutekėjimas kartu yra BDAR pažeidimas.
PCI DSS išsamiai
Kas yra PCI DSS paprastais žodžiais
PCI DSS (angl. Payment Card Industry Data Security Standard) – tai mokėjimo kortelių duomenų saugumo standartas, kurį privalo taikyti kiekviena įmonė, priimanti, apdorojanti, sauganti ar perduodanti Visa, Mastercard, American Express, Discover ar JCB kortelių duomenis. Jį kuria ir prižiūri PCI Security Standards Council (PCI SSC), kurį 2006 m. įkūrė didžiosios kortelių schemos.
PCI DSS nėra įstatymas – tai sutartinis reikalavimas. Jūsų mokėjimų tiekėjas (ekvairis) sutartyje įsipareigoja, kad jo prekybininkai atitiks standartą, o kortelių schemos gali bausti tiekėją, jei jo klientas nutekina kortelių duomenis. Todėl kiekvienas tiekėjas – Stripe, Paysera, Montonio, Adyen – tikisi, kad patvirtinsite atitiktį, dažniausiai užpildydami trumpą savęs vertinimo klausimyną.
PCI DSS v4.0.1: dabartinė versija ir svarbios datos
| Data | Kas įvyko |
|---|---|
| 2022 m. kovas | Paskelbta PCI DSS v4.0 |
| 2024 m. birželis | Paskelbta ribota peržiūra v4.0.1 (paaiškinimai, klaidų taisymai, be naujų reikalavimų) |
| 2024 m. gruodžio 31 d. | v4.0 nustojo galioti, v4.0.1 – vienintelė aktyvi versija |
| 2025 m. sausio 30 d. | PCI SSC paskelbė pakeistą SAQ A: pašalinti 6.4.3, 11.6.1 ir 12.3.1 reikalavimai, pridėtas naujas tinkamumo kriterijus |
| 2025 m. kovo 31 d. | Ateities datos reikalavimai (angl. future-dated) tapo privalomi; įsigaliojo naujas SAQ A |
| 2026 m. spalis | Galioja v4.0.1; naujos pagrindinės versijos PCI SSC nėra paskelbusi |
12 PCI DSS reikalavimų
Standartas suskirstytas į 6 tikslus ir 12 pagrindinių reikalavimų:
- Įdiegti ir prižiūrėti tinklo saugumo kontrolės priemones (ugniasienes).
- Taikyti saugias visų sistemos komponentų konfigūracijas (be numatytųjų slaptažodžių).
- Apsaugoti saugomus kortelių duomenis (šifravimas, maskavimas).
- Šifruoti kortelių duomenis, perduodamus viešais tinklais (TLS).
- Apsaugoti sistemas nuo kenkėjiškos programinės įrangos.
- Kurti ir prižiūrėti saugias sistemas ir programinę įrangą (atnaujinimai, saugus kodas, mokėjimo puslapio skriptų kontrolė).
- Riboti prieigą prie kortelių duomenų pagal verslo poreikį.
- Identifikuoti naudotojus ir patvirtinti prieigą (unikalios paskyros, daugiaveiksnis autentiškumo patvirtinimas).
- Riboti fizinę prieigą prie kortelių duomenų.
- Registruoti ir stebėti visą prieigą prie sistemų ir kortelių duomenų.
- Reguliariai testuoti sistemų ir tinklų saugumą (pažeidžiamumų skenavimas, įsiskverbimo testai, pakeitimų aptikimas mokėjimo puslapiuose).
- Palaikyti informacijos saugumo politiką ir programas.
Kai kurie duomenys niekada negali būti saugomi po autorizacijos, net užšifruoti: visas magnetinės juostos ar lusto turinys, kortelės saugos kodas (CVC2/CVV2) ir PIN. Rodomas kortelės numeris turi būti maskuojamas – matyti ne daugiau kaip pirmi 6 ir paskutiniai 4 skaitmenys.
Kokį PCI DSS klausimyną (SAQ) pildyti el. parduotuvei
Smulkiems ir vidutiniams prekybininkams atitiktis tvirtinama savęs vertinimo klausimynu (angl. Self-Assessment Questionnaire, SAQ). Jo tipą lemia ne parduotuvės dydis, o tai, kaip techniškai priimami kortelių duomenys:
| SAQ | Kada taikomas | Tipiniai pavyzdžiai |
|---|---|---|
| A | Visas kortelės duomenų priėmimas perduotas PCI DSS atitinkančiam tiekėjui; visi mokėjimo puslapio elementai ateina tik iš jo; svetainė neatakuojama skriptais, galinčiais paveikti el. prekybos sistemas | Nukreipimas į tiekėjo mokėjimo puslapį (Stripe Checkout, Paysera, Montonio), tiekėjo iframe laukai |
| A-EP | Kortelės duomenis gauna tiekėjas, bet jūsų svetainė valdo mokėjimo puslapį ir gali paveikti duomenų saugumą | Tiesioginis formos siuntimas (Direct Post), JavaScript forma jūsų puslapyje, siunčianti duomenis tiekėjui |
| D (prekybininkams) | Kortelių duomenys pasiekia, apdorojami ar saugomi jūsų sistemose | Savas mokėjimų serveris, „Direct“ integracija su kortelės numeriu jūsų serveryje |
| C-VT | Kortelės duomenys rankiniu būdu suvedami į tiekėjo virtualų terminalą | Užsakymai telefonu |
| B, B-IP, P2PE | Fizinės prekybos terminalai | POS terminalai parduotuvėje |
Pavyzdžiui, Google Pay integracija „Gateway“ režimu leidžia likti paprastame SAQ, o „Direct“ režimas, kai jūs patys iššifruojate kortelės duomenis, reikalauja visos PCI DSS atitikties.
Prekybininkų lygiai: kada reikia išorinio audito
Kortelių schemos prekybininkus skirsto į lygius pagal metinį kortelių operacijų skaičių. Visa kriterijai:
| Lygis | Visa operacijų per metus | Kaip tvirtinama atitiktis |
|---|---|---|
| 1 | Daugiau nei 6 mln. (visais kanalais) | Metinis kvalifikuoto auditoriaus (QSA) atitikties ataskaita (ROC) |
| 2 | 1–6 mln. | SAQ arba ROC, pagal ekvairio reikalavimą |
| 3 | 20 000 – 1 mln. el. prekybos | SAQ |
| 4 | Iki 20 000 el. prekybos arba iki 1 mln. visų | SAQ, jei reikalauja ekvairis |
Daugumai Lietuvos el. parduotuvių taikomas 4 lygis, o tiekėjai dažnai patys pateikia supaprastintą klausimyną skydelyje arba laiko, kad naudojant jų mokėjimo puslapį atitiktis patvirtinta automatiškai. Tai nereiškia, kad svetainės saugumas nebesvarbus.
Kodėl svetainės skriptai svarbūs net su SAQ A
Dažniausia el. parduotuvių kortelių nutekėjimo priežastis – skriptų injekcija (vadinama ir „Magecart“ ar e. skimingu): įsilaužėlis į svetainę įterpia kodą, kuris pakeičia mokėjimo mygtuką ar formą ir nukopijuoja kortelės duomenis prieš jiems patenkant pas tiekėją. Todėl PCI DSS v4.0.1 6.4.3 ir 11.6.1 reikalavimai įpareigoja kontroliuoti mokėjimo puslapio skriptus ir aptikti jų pakeitimus. SAQ A prekybininkams šie reikalavimai 2025 m. pašalinti, bet vietoj jų reikia patvirtinti, kad visa svetainė nėra pažeidžiama tokiomis atakomis. Praktiškai tai reiškia: atnaujinta platforma ir papildiniai, administratoriaus paskyros su dviejų veiksnių patvirtinimu, minimalus trečiųjų šalių skriptų kiekis, turinio saugumo politika (CSP) ir reguliarus pakeitimų stebėjimas.
Kaip patvirtinti PCI DSS atitiktį: žingsniai
- Nustatykite, kur keliauja kortelės duomenys – nubraižykite atsiskaitymo srautą nuo krepšelio iki tiekėjo patvirtinimo.
- Paklauskite tiekėjo, kokį SAQ jis tikisi ir ar priima jį per savo skydelį. Stripe, Adyen ir kiti dažnai pateikia klausimyną tiesiogiai paskyroje.
- Užpildykite SAQ ir atitikties patvirtinimą (angl. Attestation of Compliance, AOC) – juos pasirašo įmonės atsakingas asmuo.
- Atlikite reikalaujamus patikrinimus – A-EP ir D klausimynams reikia ketvirtinių išorinių pažeidžiamumų skenavimų, kuriuos atlieka PCI SSC patvirtintas skenavimo tiekėjas (ASV).
- Kartokite kasmet ir kiekvieną kartą, kai keičiate platformą, temą ar mokėjimų integraciją.
PCI DSS ir platformos: Shopify, WooCommerce, PrestaShop
| Platforma | Kas atsako už PCI DSS | Ką daryti jums |
|---|---|---|
| Shopify | Shopify yra 1 lygio paslaugų teikėjas; atsiskaitymą ir Shopify Payments valdo platforma | Saugoti administratorių paskyras, riboti programėles su prieiga prie atsiskaitymo |
| WooCommerce | Jūs – serveris, tema ir papildiniai jūsų atsakomybė | Naudoti tiekėjo nukreipimą ar iframe, atnaujinti WordPress, riboti papildinius, stebėti failų pakeitimus |
| PrestaShop | Jūs, kaip ir WooCommerce | Tie patys žingsniai; ypatingas dėmesys moduliams iš neoficialių šaltinių |
| Wix, Squarespace | Platforma | Saugoti paskyrą, naudoti integruotus mokėjimus |
Pavyzdys: koks PCI DSS lygis ir SAQ tinka parduotuvei su 259 200 € kortelių apyvarta
Lietuvos el. parduotuvė per mėnesį gauna 1 200 užsakymų, 40 % jų apmokama kortele, vidutinis krepšelis – 45 €. Parduotuvė veikia WooCommerce ir svarsto tris integracijos būdus su tuo pačiu tiekėju.
| Rodiklis | Skaičiavimas | Rezultatas |
|---|---|---|
| Kortelių operacijų per metus | 1 200 × 40 % × 12 | 5 760 |
| Kortelių apyvarta per metus | 5 760 × 45 € | 259 200 € |
| Visa prekybininko lygis | iki 20 000 el. prekybos operacijų | 4 lygis – užtenka SAQ |
| Integracijos būdas | SAQ | Ką reikia daryti |
|---|---|---|
| Nukreipimas į tiekėjo mokėjimo puslapį | A | Patvirtinti tinkamumo kriterijus, saugoti svetainę nuo skriptų atakų |
| Tiekėjo iframe laukai jūsų atsiskaitymo puslapyje | A (jei visi mokėjimo elementai iš tiekėjo) | Tas pats + patikrinti, ar jokie jūsų skriptai neliečia mokėjimo laukų |
| Sava JavaScript forma, siunčianti duomenis tiekėjui | A-EP | Ženkliai daugiau reikalavimų: pažeidžiamumų skenavimai, skriptų inventorius, pakeitimų aptikimas, žurnalai |
Išvada. Su 259 200 € kortelių apyvarta parduotuvė yra 4 lygio prekybininkas, o PCI DSS darbų apimtį lemia integracijos būdas, ne apyvarta. Jei kortelių mokėjimų tiekėjas ima 1,5 % + 0,25 €, metinės kortelių mokėjimų išlaidos sudaro 5 760 × (45 × 1,5 % + 0,25) = 5 760 × 0,93 € = 5 356,80 €. Iš šių pinigų dalis jau apmoka tiekėjo PCI DSS atitiktį – rinkdamiesi nukreipimą ar iframe, perkeliate didžiąją dalį saugumo naštos tiekėjui. Sava forma (A-EP) sutaupo vieną ar du ekranus pirkėjui, bet prideda nuolatinių saugumo darbų.
Dažniausios klaidos
- Manoma, kad naudojant Stripe ar Paysera PCI DSS jūsų visai neliečia. Net su SAQ A turite patvirtinti tinkamumo kriterijus ir apsaugoti svetainę nuo skriptų injekcijos.
- Mokėjimo puslapyje laikoma daug trečiųjų šalių skriptų (pokalbių langai, analitika, reklamos žymos). Kiekvienas jų – potencialus kortelės duomenų nutekėjimo kelias.
- Kortelės numeriai ar CVC kodai renkami el. paštu, pokalbiuose ar užsakymo pastabose. Tada kortelės duomenys patenka į jūsų sistemas ir SAQ A nebetinka.
- Pasirenkama „Direct“ integracija dėl dizaino, neįvertinus, kad tai reiškia visos PCI DSS atitikties įgyvendinimą ir auditą.
- WooCommerce ar PrestaShop papildiniai neatnaujinami mėnesiais. Pasenę moduliai – dažniausias kelias įterpti kenkėjišką kodą į atsiskaitymo puslapį.
- Administratoriaus paskyros be dviejų veiksnių patvirtinimo ir su bendrais slaptažodžiais. PCI DSS v4.0.1 reikalauja unikalių paskyrų ir daugiaveiksnio patvirtinimo prieigai prie kortelių duomenų aplinkos.
- PCI DSS laikomas vienkartiniu darbu. Atitiktis tvirtinama kasmet, o pasikeitus integracijai ar platformai SAQ tipas gali pasikeisti.
PCI DSS Lietuvoje
Lietuvoje PCI DSS nėra įtvirtintas įstatymu – jį taiko mokėjimų tiekėjai per sutartis su prekybininkais. Tačiau kortelių duomenų nutekėjimas Lietuvoje yra ir asmens duomenų saugumo pažeidimas pagal BDAR: apie jį per 72 valandas reikia pranešti Valstybinei duomenų apsaugos inspekcijai, o didelės rizikos atveju – ir paveiktiems pirkėjams. Mokėjimų tiekėjai, kurie licencijuoti Lietuvos banke (pvz., Paysera, Neopay, SumUp, Montonio), patys privalo atitikti PCI DSS kaip paslaugų teikėjai ir taikyti PSD2 saugumo reikalavimus.
Daugumai Lietuvos el. parduotuvių PCI DSS klausimas aktualus mažiau nei kitose šalyse, nes didelė dalis pirkėjų moka banko mokėjimais per mokėjimo inicijavimo paslaugas, kuriuose kortelės duomenys nenaudojami. Tačiau kortelėmis mokantiems pirkėjams ir eksportui standartas taikomas pilnai, o skriptų injekcijos atakos vienodai pavojingos ir banko mokėjimų puslapiams – įsilaužėlis gali pakeisti nukreipimo adresą į netikrą banko puslapį.
Lietuvos parduotuvių praktikoje paprasčiausias kelias – mokėjimų tiekėjo nukreipimas ar iframe (SAQ A), atnaujinta platforma ir papildiniai, dviejų veiksnių patvirtinimas visoms administratorių paskyroms ir reguliari svetainės priežiūra.
Susiję terminai
- Integruojame kortelių mokėjimus per tiekėjo nukreipimą ar iframe, kad parduotuvei tiktų paprasčiausias SAQ A.
- Peržiūrime atsiskaitymo puslapio skriptus ir pašaliname nereikalingus trečiųjų šalių kodus.
- Įdiegiame turinio saugumo politiką (CSP), dviejų veiksnių patvirtinimą administratoriams ir failų pakeitimų stebėjimą.
- Prižiūrime platformos ir papildinių atnaujinimus, kad atsiskaitymo puslapis išliktų saugus.
Dažni klausimai
Kas yra PCI DSS?
PCI DSS – mokėjimo kortelių duomenų saugumo standartas, kurį turi taikyti visos įmonės, priimančios, apdorojančios, saugančios ar perduodančios kortelių duomenis. Jį prižiūri PCI Security Standards Council.
Kokia dabartinė PCI DSS versija?
2026 m. spalį galioja PCI DSS v4.0.1, paskelbta 2024 m. birželį. Nuo 2025 m. sausio 1 d. ji vienintelė aktyvi versija, o ateities datos reikalavimai privalomi nuo 2025 m. kovo 31 d.
Ar PCI DSS privalomas mažai el. parduotuvei?
Taip, jei priimate korteles. Tačiau mažai parduotuvei, naudojančiai tiekėjo mokėjimo puslapį ar iframe, dažniausiai užtenka trumpo SAQ A klausimyno.
Kas yra SAQ A ir SAQ A-EP?
SAQ A taikomas, kai visą kortelės duomenų priėmimą atlieka PCI DSS atitinkantis tiekėjas. SAQ A-EP – kai duomenis gauna tiekėjas, bet jūsų svetainė valdo mokėjimo puslapį; jame gerokai daugiau reikalavimų.
Ar PCI DSS yra įstatymas?
Ne. Tai kortelių schemų standartas, taikomas per mokėjimų tiekėjų sutartis. Tačiau kortelių duomenų nutekėjimas kartu yra ir BDAR pažeidimas.
Kiek kainuoja PCI DSS atitiktis?
Mažai parduotuvei su SAQ A papildomų tiesioginių kaštų dažnai nėra – reikia laiko klausimynui ir svetainės saugumo priežiūros. 1 lygio prekybininkams kasmetinis QSA auditas yra atskiras didelis kaštas.
Ar galima saugoti kortelės CVC kodą?
Ne. Po autorizacijos kortelės saugos kodo (CVC2/CVV2), PIN ir visos magnetinės juostos ar lusto informacijos saugoti negalima net užšifruotos.
Kas nutinka, jei PCI DSS nesilaikoma?
Įvykus nutekėjimui kortelių schemos gali bausti jūsų tiekėją, o šis – perkelti baudas, sustabdyti kortelių priėmimą ar nutraukti sutartį. Papildomai taikoma atsakomybė pagal BDAR.
Šaltiniai
- Just Published: PCI DSS v4.0.1 – PCI Security Standards Council
- Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A – PCI Security Standards Council
- Document Library – PCI Security Standards Council
- Guidance for PCI DSS e-commerce requirements effective after 31 March 2025 – PCI Security Standards Council
- Integration checklist (Gateway ir Direct integracijos) – Google for Developers
- Reglamentas (ES) 2016/679 (BDAR) – EUR-Lex
- Integration security guide – Stripe Docs