GH GambleHub

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.
💡 Uwaga: dokładne progi i formularze potwierdzenia są ustalane przez marki kart i nabywcę; sprawdź ich politykę.

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.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.