PWZ DSS: poziomy i zgodność
1) Co to jest PCI DSS i kto go potrzebuje
PCI DSS (Payment Card Industry Data Security Standard) to przemysłowy standard bezpieczeństwa kart płatniczych (Visa, Mastercard, AmEx, Discover, JCB). Dla iGaming jest wymagane, jeśli:- akceptuje płatności kartami (bezpośrednio lub za pośrednictwem PSP/bramy),
- przetwarzanie/przechowywanie/przesyłanie danych kart (PAN, term, CVV) lub ich skrócone/zaszyfrowane formularze,
- są dostawcą usług dla innych handlowców (hosting, przetwarzanie, zwalczanie oszustw, orkiestra płatności itp.), jeśli możesz wpłynąć na bezpieczeństwo tych kart.
Wersja i czas: aktualna wersja to PCI DSS v4. 0. Wymagania v3. 2. 1 na emeryturze; pozycje „future-dated” v4. 0 jest obecnie w mocy. Nowy w v4. 0: ulepszone MFA, „Dostosowane podejście”, ukierunkowana analiza ryzyka częstotliwości procedur, segmentacji i udoskonaleń szyfrowania.
2) Poziomy zgodności: handlowcy i usługodawcy
2. 1 Handlowcy (handlowcy)
Poziom jest określany przez roczny wolumen transakcji kartą (wszystkie kanały) i/lub incydenty kompromisowe. Typowy model (według największych systemów płatności):- Poziom 1:> 6 mln transakcji rocznie lub zostało naruszone. Wymaga rocznych ROC (Raport o zgodności) od QSA lub wewnętrznej ISA przy uzgodnieniu, + kwartalne skany ASV.
- Poziom 2: ~ 1-6 milionów rocznie. Zazwyczaj - SAQ (samoocena) + skany ASV; niektóre programy/podmioty przejmujące mogą wymagać ROC.
- Poziom 3: ~ 20k-1 mln e-commerce/rok. Zazwyczaj - SAQ + ASV skanuje.
- Poziom 4: poniżej progów L3. SAQ; wymogi mogą się różnić w zależności od nabycia banku.
2. 2 Usługodawcy
Zwykle 2 poziomy; dla poziomu 1 (duża wielkość/kluczowa rola w łańcuchu) wymagana jest ROC z QSA, dla poziomu 2 - SAQ-D SP (czasami - ROC na żądanie kontrahentów/programów). W iGaming wiele PSP/bram/partnerów hostingowych to SP Level 1.
3) SAQ vs ROC: Jak wybrać
ROC jest obowiązkowy dla L1 metrów i L1 SP. W innych przypadkach - jeden z SAQ:- SAQ A - tylko pola przekierowania/iframe/hostingu; nie ma przetwarzania/transferu/przechowywania kart z Tobą.
- SAQ A-EP jest e-commerce, gdzie witryna wpływa na bezpieczeństwo strony płatności (na przykład skryptów hostów), ale PAN jest wprowadzany w środowisku dostawcy.
- SAQ B/B-IP - terminale/imprintery bez elektronicznej pamięci; B-IP - podłączone terminale.
- SAQ C-VT/C - terminale wirtualne/małe środowisko przetwarzania, brak pamięci masowej.
- SAQ P2PE to tylko certyfikowane przez PCI rozwiązanie P2PE.
- SAQ D (Merchant/Service Provider) - „szeroka” opcja dla dowolnego przetwarzania/transferu/przechowywania, niestandardowych integracji, orkiestry itp.
Praktyka dla iGaming: ścieżką docelową jest SAQ A/A-EP ze względu na bezpieczne strumienie, tokenizację i pola hostowane. Jeśli masz własne usługi płatnicze/walty - zwykle SAQ D lub ROC.
4) Scoping: Co idzie do CDE i jak ją zawęzić
CDE (Cardholder Data Environment) - systemy, w których dane kart są przetwarzane/przechowywane/przesyłane oraz wszystkie połączone/wpływowe segmenty.
Skrót od zakresu:- Pola hosted/iframe/TSP - Wprowadź PAN poza domeną.
- Tokenizacja i żetony sieciowe: Twoje usługi działają na żetonach, nie PAN.
- P2PE: szyfrowanie typu end-to-end z certyfikowanym rozwiązaniem.
- Segmentacja sieci: twarde ACL, izolacja CDE od reszty środowiska.
- Obowiązkowe DLP i maskowanie dziennika, zakaz porzucania z PAN/CVV.
W v4. 0 dodaje elastyczności metod osiągania celów, ale dowody skuteczności i ukierunkowanej analizy ryzyka są obowiązkowe.
5) Wymagania PCI DSS v4 "12. "0 (co oznacza bloki)
1. Bezpieczeństwo sieci i segmentacja (zapory, ACL, izolacja CDE).
2. Bezpieczna konfiguracja hosta/urządzenia (utwardzanie, linie podstawowe).
3. Ochrona danych posiadacza karty (pamięć masowa PAN - tylko w razie potrzeby, silna kryptografia).
4. Ochrona danych podczas transmisji (TLS 1. 2 + i ich odpowiedniki).
5. Antywirusowe/anty-malware i kontrola integralności.
6. Bezpieczny rozwój i modyfikacja (SDLC, SAST/DAST, kontrola biblioteki).
7. Dostęp w razie potrzeby (najmniejszy przywilej, RBAC).
8. Identyfikacja i uwierzytelnianie (MFA dla administratora i zdalnego dostępu, hasła przez v4. 0).
9. Bezpieczeństwo fizyczne (centra danych, biura, terminale).
10. Rejestrowanie i monitorowanie (centralizacja kłód, immutability, alerty).
11. Badanie bezpieczeństwa (ASV skanuje co kwartał, pentests rocznie i po zmianach, test segmentacji).
12. Polityka i zarządzanie ryzykiem (procedury, szkolenia, reakcja na incydenty, oceny ryzyka, dokumenty „Podejście dostosowane”).
6) Obowiązkowe działania i częstotliwość
Skany ASV (zewnętrzne) - co kwartał i po istotnych zmianach.
Luki/łatanie - cykle regularne (częstotliwości są uzasadnione przez TRA - ukierunkowana analiza ryzyka).
Badania penetracyjne (wewnętrzne/zewnętrzne) - corocznie i po istotnych zmianach; kontrola segmentacji jest obowiązkowa.
Dzienniki i monitoring - stale, z zachowaniem i ochroną przed modyfikacjami.
Szkolenie personelu - przy zatrudnianiu, a następnie regularnie.
MSZ - dla wszystkich administratorów i zdalnego dostępu do CDE.
Spis systemów/strumieni danych - stale aktualizuj.
7) matryca wyboru SAQ (krótka)
Tylko iframe/przekierować, bez PAN ciebie → SAQ A.
E-commerce, Twoja strona wpływa na stronę płatności → SAQ A-EP.
Terminale/imprintery → SAQ B/B-IP.
Terminal wirtualny → SAQ C-VT.
Mała sieć "kart' bez przechowywania → SAQ C.
P2PE rozwiązanie → SAQ P2PE.
Inne/złożone/przechowywanie/przetwarzanie → SAQ D (lub ROC).
8) Artefakty i dowody do audytu
Przygotować i utrzymać:- Schematy przepływu sieci i danych, rejestr aktywów, rejestr sprzedawcy, rejestr księgowy/dostępowy.
- Zasady/procedury: bezpieczny rozwój, zarządzanie zmianami, rejestrowanie, incydenty, luki, klucze/krypto, zdalny dostęp, kopie zapasowe.
- Raporty: ASV, pentests (segmentacja włącznie), skany wrażliwości, wyniki korekcji.
- Dzienniki/wpisy: scentralizowany system, immutability, analiza incydentów.
- Zarządzanie kryptami: procedury KMS/HSM, rotacje, inwentaryzacja kluczy/certyfikatów.
- Dowody „niestandardowego podejścia” (jeśli stosowane): cele kontroli, metoda, wskaźniki wydajności, TRA.
- Zakres odpowiedzialności stron trzecich: partnerzy AoC (PSP, hosting, CDN, zwalczanie nadużyć finansowych), macierz wspólnej odpowiedzialności.
9) Projekt zgodności (krok po kroku)
1. Kopiowanie i analiza Gap-Zdefiniuj CDE, sąsiednie segmenty, prądowe przerwy.
2. Szybkie wygrane: strumień PAN-safe (iframe/hosted fields), tokenizacja, zakaz logowania PAN, zamknięcie „zewnętrznych” luk w krecie.
3. Segmentacja i sieć: izolacja CDE, mTLS, firewall-ACL, dostęp najmniej uprzywilejowany, MFA.
4. Obserwowalność: scentralizowane rejestrowanie, zatrzymywanie/łańcuch opieki, wpisy.
5. Luka i zarządzanie kodem: SAST/DAST, plastry, SBOM, kontrola zależności.
6. Testy: skany ASV, wewnętrzne/zewnętrzne badania penetracyjne, kontrola segmentacji.
7. Dokumenty i szkolenia: procedury, IR-playbooks, szkolenia, rekordy treningowe.
8. Wybór formularza certyfikacyjnego: SAQ (typ) lub ROC; być uzgodnione z nabywcą/markami.
9. Cykl roczny: wsparcie, dowody, przegląd ryzyka/częstotliwości, repurposing.
10) Integracja z architekturą iGaming
Orkiestra płatnicza pracuje tylko z żetonami; PAN nie widzi.
Multi-PSP: kontrole zdrowotne, inteligentne routing, idempotencja, ретрай; AoC z każdego PSP.
Autobus/DWH napędzany zdarzeniami: brak PAN/CVV; maskowanie ostatnich 4 cyfr; Bramki DLP w CI/CD.
Kontrole 3DS/SCA: przechowywać tylko niezbędne artefakty (identyfikatory transakcji), bez danych wrażliwych.
11) Częste błędy
Rejestrowanie danych PAN/CVV i nieprawidłowe maski.
„Tymczasowe” trasy PAN przez wewnętrzne API/autobusy.
Brak testu segmentacji pentestu.
Nierozsądna częstotliwość zabiegów (brak TRA według v4. 0).
Zależność od jednego PSP bez AoC i bez awaryjnego.
Nieznane „wpływowe” segmenty (admin-jump-hosts, monitoring, kopie zapasowe).
12) Lista kontrolna szybkiego startu (iGaming)
- Przejdź do pól hostowanych/iframe; usunąć dane wejściowe PAN z formularzy.
- Włącz tokenizację/żetony sieciowe; wyłączyć PAN z zdarzeń/dzienników.
- Wykonaj kopiowanie CDE i izolację segmentów (MFA, RBAC, mTLS).
- Skonfiguruj scentralizowane dzienniki i wpisy (immutability, retention).
- Uruchom skany ASV, wyeliminuj krytyczne/wysokie.
- Wykonać badania penetracyjne (wewnętrzne/zewnętrzne) + badanie segmentacyjne.
- Przygotowanie polityk/procedur i dowodów realizacji.
- Uzgodnić formularz kwalifikacji z nabywcą (typ SAQ/ROC).
- Uzyskiwanie i przechowywanie AoC wszystkich sprzedawców na Krecie.
- Zintegruj sterowniki PCI z cyklem uwalniania (SDLC, utwardzanie IaC, DLP w CI/CD).
13) FAQ krótkie
Czy potrzebuję QSA? Dla ROC, tak. Certyfikacja własna jest często wystarczająca dla SAQ, ale wielu nabywców/marek może wymagać partnera QSA/ASV.
Jeśli nie będziemy przechowywać PAN? Nadal należy do PCI DSS, jeśli akceptujesz karty. Cel osiągnięcia SAQ A/A-EP.
Czy 3DS rozwiązuje PCI? Nie, nie jest. 3DS - o uwierzytelnianiu; PWZ - o ochronie danych.
Wystarczy TLS? Nie, nie jest. Potrzebne są wszystkie odpowiednie wymagania v4. 0, w tym procesy i dowody.
14) Streszczenie
Dla iGaming, optymalną strategią jest zminimalizowanie zakresu (PAN-safe, tokenizacja, hosted fields, P2PE gdzie to możliwe), segment twardy CDE, automatyczne rejestrowanie/luki/testy penetracyjne, zebrać pełny pakiet artefaktów i wybrać prawidłową formę potwierdzenia (SAQ lub ROC) na poziomie. Zmniejsza to ryzyko, przyspiesza integrację z PSP i utrzymuje stabilną konwersję i monetyzację, spełniając jednocześnie wymagania marki karty.