Mokėjimų sauga Jūsų internetinėje parduotuvėje: PCI, card testing ir ką daro Jūsų prieglobos paslaugų teikėjas

Tie, kurie priima mokėjimus internetu, susiduria su kortelių bendrovių saugumo taisyklėmis (PCI DSS), nusikaltėliais, norinčiais pavogti kortelių duomenis, ir vadinamuoju card testing: pavogtų kortelių bandymu Jūsų parduotuvėje. Šiame straipsnyje paaiškinama, ką tai reiškia mažai internetinei parduotuvei, ką turite daryti patys ir ką Jūsų hostingo paslaugų teikėjas sutvarko, o ko ne.

Pagrindinė taisyklė: kortelių duomenys niekada nepasiekia Jūsų parduotuvės

Kortelės numerį, galiojimo datą ir saugumo kodą klientas įveda pas Jūsų mokėjimų paslaugų teikėją, o ne Jūsų pačios parduotuvėje. Jūsų parduotuvė sužino tik tai, ar mokėjimas atliktas. Tai taip pat reiškia:

• niekada nekurkite atskiro formos lauko kortelių numeriams, net ir telefonu pateikiamam užsakymui;
• niekada nepriimkite kortelių duomenų el. paštu, pokalbių programėlėje ar telefonu ir neįrašykite jų prie užsakymo pastabose;
• nenaudokite papildinio, kuris saugo kortelių duomenis Jūsų pačių duomenų bazėje.

PCI DSS ir SAQ A paprasta kalba

PCI DSS (Payment Card Industry Data Security Standard) yra kortelių bendrovių saugumo standartas; dabartinė versija yra v4.0.1. Įmonei, kuri pati tvarko kortelių duomenis, taikomas gana platus reikalavimų rinkinys. Maža parduotuvė, kuri mokėjimų tvarkymą visiškai perduoda trečiajai šaliai, atitiktį gali įrodyti trumpu klausimynu: SAQ A (Self-Assessment Questionnaire A). Jūsų mokėjimų paslaugų teikėjas kartais to paprašo.

Perdavimą trečiajai šaliai galima atlikti dviem būdais:

1. Peradresavimas: po užsakymo klientas nukreipiamas į paslaugų teikėjo mokėjimo puslapį, o po to grįžta atgal.
2. Įterptas mokėjimo laukas: mokėjimo laukas yra Jūsų apmokėjimo puslapyje, tačiau tai yra paslaugų teikėjo puslapio dalis (iframe).

Nuo 2025 m. kovo 31 d. galioja nauja SAQ A versija. Tie, kurie naudoja įterptą mokėjimo lauką, joje turi patvirtinti, kad jų svetainė nėra pažeidžiama atakų su skriptais, galinčiais paveikti mokėjimą. Tiems, kurie naudoja peradresavimą, ši sąlyga netaikoma. Pasiteiraukite savo mokėjimų paslaugų teikėjo, kuris klausimynas atitinka Jūsų integraciją.

Apmokėjimo puslapio apsauga

• Apmokėjimo puslapį laikykite kuo paprastesnį. Kiekvienas skriptas tame puslapyje iš esmės gali nuskaityti tai, ką klientas įveda (e-skimming): pokalbių valdikliai, žymų tvarkyklės, reklamos pikseliai. Įkelkite tik tai, kas būtina mokėjimui atlikti.
• Kuo mažiau papildinių, ir visada atnaujinti. Kenkėjiški skriptai dažniausiai patenka per papildinio spragą arba pavogtą administratoriaus slaptažodį.
• https visur, su peradresavimu iš http į https ir HSTS. Žr. Privalomas lankytojų peradresavimas į https ir HSTS ir saugumo antraštės Jūsų svetainei.

Card testing atpažinimas ir ribojimas

Atliekant card testing, nusikaltėliai automatiškai pateikia daug mažų užsakymų, siekdami nustatyti, kurios pavogtos kortelės veikia. Tai atpažįstama pagal daug užsakymų per trumpą laiką, dažnai su tuo pačiu pigiu produktu, skirtingais vardais ir daug užsakymų, kurių būsena yra Nepavyko. Tai Jums kainuoja sandorių mokesčius ir grąžinimus, o blogiausiu atveju Jūsų mokėjimų paslaugų teikėjas gali užblokuoti Jūsų paskyrą.

• Rate limiting (užklausų skaičiaus per laiko vienetą ribojimas). WooCommerce turi tai integruota apmokėjimo blokams, tačiau pagal numatytuosius nustatymus ši funkcija išjungta. Įjunkite ją skiltyje WooCommerce > Nustatymai > Išplėstiniai > Funkcijos, parinktis Rate limiting Checkout block and Store API.
• Captcha apmokėjimo metu. Užpuolikai dažnai keičia IP adresus; rate limiting ir captcha kartu veikia geriausiai.
• Jūsų mokėjimų paslaugų teikėjo sukčiavimo filtrai. Įjunkite juos ir stebėkite, ką jie praneša.
• 3-D Secure, papildomas patvirtinimas banko programėlėje, apsunkina pavogtų kortelių naudojimą.

Ką sutvarko Jūsų hostingo paslaugų teikėjas, o ko ne

WebOké sutvarkoma:

• Nemokamas Let's Encrypt sertifikatas https protokolui
• HSTS pagal numatytuosius nustatymus įjungtas daugumoje serverių
• Žiniatinklio aplikacijų ugniasienė (Web Applicatie Firewall) pagal numatytuosius nustatymus įjungta ir sustabdo žinomas atakas
• Imunify360 iš karto patikrina naujus failus dėl kenkėjiškų programų ir reguliariai skenuoja Jūsų paketą
• Kiekvieną naktį sukuriama atsarginė viso Jūsų paketo kopija, saugoma 30 dienų, kitame duomenų centre

Lieka Jūsų (arba Jūsų svetainės kūrėjo) atsakomybe:

• WordPress, WooCommerce, temos ir papildinių atnaujinimas (Installatron tai gali atlikti automatiškai, žr. Naujinimai ir automatiniai naujinimai)
• Integracija ir sukčiavimo nustatymai pas Jūsų mokėjimų paslaugų teikėją
• Kokie skriptai yra Jūsų apmokėjimo puslapyje
• Tvirti slaptažodžiai ir dviejų veiksnių autentifikacija administratoriams
• Rate limiting, captcha ir įtartinų užsakymų peržiūra

Programinę įrangą, kurią įsidiegiate patys, taip pat per Installatron, valdote patys. Jei Jūsų svetainė vis dėlto nulaužiama, vadovaukitės veiksmų planu Mano svetainė nulaužta: veiksmų planas. Jei įsilaužimas paveikia klientų asmens duomenis, taip pat skaitykite Ar tai duomenų saugumo pažeidimas ir ar turiu apie tai pranešti?

Daugiau informacijos

• Nemokamas kursas „Saugumas internete“, pamoka 4.2 Jūsų svetainė: https, HSTS ir saugumo antraštės
• PCI Security Standards Council apie SAQ A (anglų kalba)
• WooCommerce apie card testing ir rate limiting (anglų kalba)