PCI-DSS

PCI DSS (Payment Card Industry Data Security Standard, czyli standard bezpieczeństwa danych w branży kart płatniczych) to zbiór zasad, które musi spełnić każda firma mająca do czynienia z danymi kart. Tworzy go i utrzymuje PCI Security Standards Council (PCI SSC) — rada założona przez Visa, Mastercard, American Express, Discover i JCB. Standard mówi, jak chronić dane posiadaczy kart (ang. cardholder data) w firmach, które te dane przechowują, przetwarzają lub przesyłają. Obowiązuje wersja PCI DSS v4.0.1, opublikowana 11 czerwca 2024 r.; zastąpiła ona v4.0, wycofaną 31 grudnia 2024 r. Wszystkie zasady są ujęte w 12 wymagań pogrupowanych w 6 celów (control objectives).

Czym jest PCI DSS i kto go egzekwuje?

PCI DSS nie jest prawem — to standard wynikający z umów. Firma musi go przestrzegać, bo zobowiązała się do tego w kontrakcie z organizacją płatniczą i bankiem rozliczeniowym (acquirerem). Sam standard pisze i aktualizuje PCI SSC, ale pilnowaniem zgodności i karami zajmują się poszczególne organizacje płatnicze (Visa, Mastercard i inne) oraz acquirerzy.

Standard dotyczy dwóch grup. Merchanci to sprzedawcy, którzy przyjmują płatności kartą. Service providerzy to dostawcy usług wpływających na bezpieczeństwo danych kart — na przykład bramki płatnicze, procesory transakcji czy firmy hostingowe.

Ważne jest pojęcie CDE (Cardholder Data Environment), czyli środowisko danych posiadaczy kart. Są to wszystkie systemy, sieci i komponenty, które przechowują, przetwarzają lub przesyłają dane kart (numer karty oraz wrażliwe dane uwierzytelniające), a także systemy bezpośrednio z nimi połączone lub mogące na nie wpływać. Każda ocena zgodności zaczyna się od dokładnego wyznaczenia granic CDE (tzw. scoping).

Jakie dane chroni PCI DSS?

Standard dzieli chronione dane na dwie kategorie:

• Cardholder data (CHD) — dane posiadacza karty: pełny numer karty (PAN, Primary Account Number), imię i nazwisko, data ważności i kod usługi (service code). PAN można przechowywać tylko w postaci nieczytelnej — zamaskowanej, stokenizowanej albo zaszyfrowanej zgodnie z wymaganiem 3.
• Sensitive authentication data (SAD) — wrażliwe dane uwierzytelniające: pełne dane ścieżki magnetycznej, kod weryfikacyjny (CAV2/CVC2/CVV2/CID) oraz PIN lub blok PIN. SAD nie wolno przechowywać po autoryzacji transakcji — nawet zaszyfrowanych.

Jakie są 12 wymagań PCI DSS i 6 celów?

Wymagania PCI DSS v4.0.1 są pogrupowane w sześć nadrzędnych celów:

Cel 1 — Budowa i utrzymanie bezpiecznej sieci i systemów

1. Wymaganie 1: kontrola bezpieczeństwa sieci (network security controls — m.in. firewalle i segmentacja).
2. Wymaganie 2: bezpieczne konfiguracje wszystkich komponentów (usunięcie domyślnych haseł i ustawień).

Cel 2 — Ochrona danych konta

1. Wymaganie 3: ochrona przechowywanych danych konta (szyfrowanie, maskowanie, tokenizacja, zarządzanie kluczami).
2. Wymaganie 4: ochrona danych podczas przesyłania przez otwarte sieci publiczne za pomocą silnej kryptografii (np. TLS).

Cel 3 — Utrzymanie programu zarządzania podatnościami

1. Wymaganie 5: ochrona systemów i sieci przed złośliwym oprogramowaniem.
2. Wymaganie 6: rozwijanie i utrzymywanie bezpiecznych systemów i oprogramowania (poprawki, bezpieczne tworzenie kodu).

Cel 4 — Silna kontrola dostępu

1. Wymaganie 7: dostęp do systemów i danych kart tylko dla tych, którzy go naprawdę potrzebują (zasada need-to-know).
2. Wymaganie 8: identyfikacja użytkowników i uwierzytelnianie dostępu (w tym MFA, czyli uwierzytelnianie wieloskładnikowe).
3. Wymaganie 9: ograniczenie fizycznego dostępu do danych posiadaczy kart.

Cel 5 — Regularne monitorowanie i testowanie sieci

1. Wymaganie 10: rejestrowanie i monitorowanie każdego dostępu do systemów i danych kart (logowanie, ścieżki audytu, korelacja zdarzeń).
2. Wymaganie 11: regularne testowanie zabezpieczeń (skanowanie podatności, testy penetracyjne, wykrywanie zmian).

Cel 6 — Polityka bezpieczeństwa informacji

1. Wymaganie 12: wsparcie bezpieczeństwa politykami i programami organizacyjnymi (ocena ryzyka, szkolenia, reagowanie na incydenty, nadzór nad dostawcami).

Co zmieniło się w PCI DSS v4.0 i v4.0.1?

Wersja v4.0 (marzec 2022) była dużą zmianą względem v3.2.1. Wprowadziła m.in.:

• Podejście dostosowane (customized approach): obok klasycznego defined approach (spełnianie wymagań dosłownie) firma może osiągnąć cel bezpieczeństwa własnymi mechanizmami, jeśli poprze to analizą ryzyka (targeted risk analysis).
• Szersze uwierzytelnianie wieloskładnikowe (MFA): MFA jest wymagane przy każdym dostępie do CDE, a nie tylko przy zdalnym dostępie administracyjnym.
• Wymagania z odroczonym terminem (future-dated): część nowych wymagań była zaleceniem (best practice) do 31 marca 2025 r., a od tej daty stała się obowiązkowa — m.in. szersze MFA, dłuższe hasła, ukierunkowane analizy ryzyka i wykrywanie zmian na stronach płatności.

Wersja v4.0.1 to aktualizacja porządkowa (limited revision). Nie dodaje nowych wymagań — poprawia błędy redakcyjne, doprecyzowuje noty stosowalności (m.in. dla wymagań 3, 6, 8 i 12), uściśla obowiązki service providerów wobec klientów i przenosi szablony do biblioteki dokumentów na stronie PCI SSC. Po wycofaniu v4.0 z końcem 2024 r. v4.0.1 jest jedyną obowiązującą wersją.

Jak wygląda walidacja zgodności: poziomy merchantów, SAQ, ROC i AOC?

Sposób potwierdzania zgodności zależy od poziomu merchanta. Poziom wyznacza głównie roczny wolumen transakcji, przy czym szczegółowe progi ustalają poszczególne organizacje płatnicze. Poniżej najczęściej spotykany podział:

• Poziom 1: ponad 6 mln transakcji rocznie, niezależnie od kanału sprzedaży (lub po naruszeniu danych). Wymaga corocznej oceny przez QSA (Qualified Security Assessor, wykwalifikowanego audytora) lub audytora wewnętrznego (ISA) i sporządzenia ROC.
• Poziom 2: od 1 mln do 6 mln transakcji rocznie, niezależnie od kanału sprzedaży.
• Poziom 3: od 20 000 do 1 mln transakcji e-commerce rocznie.
• Poziom 4: poniżej 20 000 transakcji e-commerce rocznie; poziom ten może również obejmować merchantów o niższym łącznym wolumenie transakcji, zgodnie z zasadami danej organizacji płatniczej.

Dokumenty walidacyjne:

• SAQ (Self-Assessment Questionnaire) — kwestionariusz samooceny dla mniejszych podmiotów (zwykle poziomy 2–4). Ma kilka typów (A, A-EP, B, B-IP, C, C-VT, P2PE, D) dobieranych do sposobu przyjmowania płatności i zakresu CDE.
• ROC (Report on Compliance) — pełny raport z oceny, sporządzany przez QSA, wymagany zwykle dla poziomu 1.
• AOC (Attestation of Compliance) — formalne poświadczenie zgodności. Powstaje po SAQ albo po ROC i jest dokumentem przekazywanym acquirerowi lub partnerom.

Niezależnie od poziomu wiele firm musi też prowadzić kwartalne skanowanie podatności przez ASV (Approved Scanning Vendor) dla systemów dostępnych z internetu.

Dlaczego PCI DSS jest istotny dla bezpieczeństwa i monitorowania sieci?

Z perspektywy zespołu bezpieczeństwa PCI DSS zamienia wymagania biznesowe i prawne na konkretne kontrole techniczne. Wiele z nich da się bezpośrednio sprawdzić w SOC/NDR i w monitoringu sieci:

• Segmentacja i kontrola ruchu (wym. 1): dobra segmentacja zmniejsza zakres CDE i utrudnia ruch boczny (lateral movement) atakującego. Dane o przepływach (flow) i logi zapór pozwalają sprawdzić, że granice CDE przekracza tylko autoryzowany ruch — i wykryć próby ich obejścia.
• Logowanie i monitoring (wym. 10): wymaga rejestrowania dostępu do danych kart, synchronizacji czasu, ochrony logów i ich codziennego przeglądu. W praktyce robi się to przez SIEM i korelację zdarzeń. To podstawa wykrywania nadużyć i analizy po włamaniu.
• Testowanie i wykrywanie zmian (wym. 11): skanowanie podatności, testy penetracyjne, IDS/IPS oraz wykrywanie nieautoryzowanych zmian — w tym podmienionych skryptów na stronach płatności (ochrona przed atakami typu e-skimming/Magecart).
• Wykrywanie eksfiltracji: obserwowanie sieci pod kątem nietypowych połączeń wychodzących i transferów danych pomaga wychwycić próby wyprowadzenia danych kart, których standard zabrania przechowywać w czytelnej postaci.

Zgodność to nie to samo co bezpieczeństwo. Spełnienie PCI DSS opisuje stan w jednym punkcie w czasie, a realna ochrona wymaga ciągłej widoczności i monitorowania środowiska — do czego standard wprost nawiązuje w wymaganiach 10 i 11.

Jakie są konsekwencje braku zgodności z PCI DSS?

Kary nie wynikają z przepisów PCI SSC, lecz z umów z organizacjami płatniczymi i acquirerami. W praktyce mogą to być: kary finansowe nakładane przez organizacje płatnicze na acquirera (i przenoszone na merchanta), wyższe opłaty transakcyjne, a w skrajnych przypadkach odebranie możliwości przyjmowania kart. Po naruszeniu danych dochodzą koszty analizy powłamaniowej (forensics), powiadomień, wymiany kart oraz możliwa odpowiedzialność cywilna i sankcje z odrębnych przepisów (np. RODO).

Dowiedz się więcej

• DORA — DORA dotyczy odporności operacyjnej instytucji finansowych, podobnie jak PCI-DSS porządkuje wymagania bezpieczeństwa.
• Automatyzacja sieci: od pojedynczych skryptów do wieloskładnikowej orkiestracji — Automatyzacja pomaga utrzymać zgodność z PCI-DSS przez szybsze wdrażanie i kontrolę konfiguracji.
• Czym jest atak DDoS i jak się przed nim chronić w 2026 roku — Ochrona przed DDoS wspiera ciągłość usług, ważną także dla środowisk objętych PCI-DSS.
• Compliance i regulacje z Sycope — Artykuł pokazuje podejście do zgodności, w tym wymagań takich jak PCI-DSS.