PCI DSS

PCI DSS (Payment Card Industry Data Security Standard) to branżowy standard bezpieczeństwa danych kart płatniczych. Według jego wydawcy ma zachęcać do ochrony danych kont kartowych i ułatwiać powszechne stosowanie spójnych środków bezpieczeństwa na całym świecie ^[1]. Standard zawiera bazowy zestaw wymagań technicznych i operacyjnych chroniących dane kont płatniczych ^[1]. Utrzymuje go PCI Security Standards Council, a aktualna jest linia 4.x, obecnie w wersji 4.0.1 ^[3].

Kogo dotyczy

Standard obejmuje wszystkie podmioty zaangażowane w przetwarzanie kart: sprzedawców, centra przetwarzania, agentów rozliczeniowych, wydawców i dostawców usług ^[1]. Dotyczy tych, którzy mają do czynienia z danymi posiadaczy kart, danymi wrażliwymi do uwierzytelnienia albo wpływają na środowisko, w którym te dane się znajdują ^[1].

PCI DSS nie jest aktem prawnym. PCI SSC założyło w 2006 roku pięć organizacji kartowych: American Express, Discover, JCB International, Mastercard i Visa, które na równych prawach współtworzą i nadzorują jego prace ^[2]. Rada podkreśla, że jej rolą jest tworzenie i utrzymywanie standardów, a nie kontrola ich wdrażania ^[2]. O tym, kto musi wykazać zgodność i w jaki sposób, decydują organizacje kartowe, agenci rozliczeniowi i podobne podmioty ^[2]. Obowiązek wynika więc z umów, a nie z ustawy, choć w praktyce jest równie wiążący. Standard należy przez to do obszaru zgodności regulacyjnej (compliance) w szerokim sensie.

Wersje i terminy

Nowe wymagania wchodzą zwykle z odroczonym terminem, by dać firmom czas na wdrożenie. Najważniejsze punkty w historii ostatnich wersji zestawia tabela.

Wersja 4.0.1 poprawiła formatowanie i literówki oraz doprecyzowała intencję części wymagań i wytycznych ^[3]. Nie zmieniła terminu 31 marca 2025 roku dla wymagań odroczonych ^[3].

Strona płatności i e-skimming

Dla sklepów internetowych najważniejsze są dwa wymagania wprowadzone w wersji 4. PCI SSC w marcu 2025 roku opublikowało dokument uzupełniający o bezpieczeństwie strony płatności i zaznaczyło, że ataki e-skimming znacząco przybrały na sile ^[5]. Web skimming polega na wstrzyknięciu do strony zamówienia skryptu, który odczytuje wpisywane dane karty.

• Wymaganie 6.4.3 dotyczy skryptów na stronie płatności: ich spisu, autoryzacji i sprawdzania integralności ^[5].
• Wymaganie 11.6.1 wymaga mechanizmu wykrywania zmian i manipulacji na stronie płatności, w tym kontroli nagłówków HTTP istotnych dla bezpieczeństwa ^[5].

Przebieg płatności, w którym formularz karty pochodzi od operatora, pokazuje schemat poniżej. Dane karty nie trafiają na serwer sklepu, ale strona, która osadza formularz, nadal może zostać zmieniona.

RYS. 1Płatność przez formularz operatora

30 stycznia 2025 roku PCI SSC ogłosiło usunięcie wymagań 6.4.3 i 11.6.1 oraz wymagania 12.3.1 z kwestionariusza SAQ A, ze skutkiem od 31 marca 2025 roku ^[4]. SAQ A przeznaczony jest dla sprzedawców, którzy nie przechowują, nie przetwarzają i nie przesyłają danych kont w postaci elektronicznej, bo całkowicie zlecili te funkcje zgodnym z PCI DSS podmiotom zewnętrznym ^[4]. W zamian dodano warunek kwalifikacji: sprzedawca musi potwierdzić, że jego strona nie jest podatna na ataki skryptów, które mogłyby wpłynąć na jego system sprzedaży ^[4]. Ryzyko e-skimmingu nie zniknęło więc z obowiązków małego sklepu. Zmieniło się tylko miejsce, w którym trzeba je wykazać.

W WordPressie

Sklep na WordPressie to zwykle WooCommerce z wtyczką operatora płatności. Dokumentacja WooCommerce stwierdza, że sama wtyczka WooCommerce nie ma certyfikatu PCI, ponieważ nie obsługuje danych posiadaczy kart ani nie przetwarza płatności bezpośrednio ^[6]. Według tej samej dokumentacji WooCommerce nigdy nie zapisuje danych kart, a oficjalne bramki przechowują tylko dane częściowe, na przykład cztery ostatnie cyfry przy płatnościach tokenami ^[6].

Nie oznacza to, że standard sklepu nie dotyczy. Przy bramkach hostowanych strona nie przetwarza surowych danych kart, ale PCI DSS nadal ma zastosowanie, bo to ona serwuje stronę zamówienia ^[6]. Zakres zgodności może być wtedy znacznie mniejszy ^[6]. Operator płatności może poprosić o wypełnienie kwestionariusza samooceny SAQ ^[6].

Na stronie zamówienia w WordPressie działają skrypty rdzenia, motywu, wtyczek, analityki i reklam. Każdy z nich jest potencjalnym nośnikiem ataku. Typowe zagrożenia to:

• podatność we wtyczce, przez którą atakujący dopisuje skrypt do strony zamówienia;
• fałszywa bramka płatności podstawiona zamiast prawdziwego formularza;
• testowanie kart (card testing), czyli sprawdzanie skradzionych numerów przez formularz sklepu;
• przejęcie konta administratora, który może zmienić kod strony.

Dobre praktyki

• Wybrać model płatności, w którym dane kart nie dotykają serwera sklepu, i ustalić z operatorem, który kwestionariusz SAQ obowiązuje ^[6].
• Prowadzić spis skryptów na stronie płatności i ograniczać je do niezbędnych, zgodnie z intencją wymagania 6.4.3 ^[5]. Pomaga w tym CSP (Content Security Policy).
• Wykrywać zmiany na stronie zamówienia i w nagłówkach HTTP, jak przewiduje wymaganie 11.6.1 ^[5]. Po stronie serwera uzupełnia to monitorowanie integralności plików.
• Stosować uwierzytelnianie wieloskładnikowe (MFA) dla kont administracyjnych; wymóg MFA dla dostępu administracyjnego pojawił się już w wersji 3.2 ^[7].
• Aktualizować wtyczki płatności i sam WooCommerce oraz okresowo zlecać test penetracyjny sklepu.