Zgodność z PCI DSS w bezpiecznych systemach transferu plików
Jak osiągnąć zgodność z PCI DSS w systemach transferu plików przetwarzających dane kart płatniczych: szyfrowanie i wymagania kontroli dostępu.
PCI DSS 4.0, obowiązkowy od 31 marca 2025 roku, nakłada 12 wymagań na każdy system, który przechowuje, przetwarza lub przesyła dane posiadaczy kart. Dla systemów transferu plików kluczowe kontrole to: Wymaganie 3 (ochrona przechowywanych danych konta przez AES-256 lub silniejsze z właściwym zarządzaniem kluczami), Wymaganie 4 (szyfrowanie transmisji z TLS 1.2 minimum, zalecany TLS 1.3), Wymaganie 8 (MFA dla każdego dostępu do środowiska danych posiadaczy kart), Wymaganie 10 (rejestrowanie każdego dostępu do CDE przez co najmniej 12 miesięcy) i Wymaganie 12 (zarządzanie i nadzór nad dostawcami usług). System transferu plików zawierający choćby jeden arkusz CSV z numerami PAN podlega pełnemu standardowi.
Co wyzwala zakres PCI DSS
PCI DSS stosuje się do każdego komponentu systemu, który przetwarza, przechowuje lub przesyła dane posiadaczy kart (CHD) lub wrażliwe dane uwierzytelnienia (SAD). CHD to podstawowy numer konta (PAN), imię i nazwisko posiadacza karty, data ważności i kod usługi. SAD to CVV, pełne dane ścieżki i kody PIN — nigdy nieprzechowywane po autoryzacji. Narzędzie do transferu plików otrzymujące arkusz kalkulacyjny z numerami PAN od banku partnerskiego podlega zakresowi. Narzędzie do wysyłania raportu zbiorczego zawierającego wyłącznie cztery ostatnie cyfry nie podlega. Tokenizowane lub skrócone numery PAN (pierwsze sześć i ostatnie cztery cyfry maksymalnie) są poza zakresem. Redukcja zakresu to działanie o najwyższym ROI w kontekście PCI — tokenizacja powinna nastąpić możliwie jak najwcześniej.
Nowości w PCI DSS 4.0
Wersja 4.0 (opublikowana w marcu 2022, obowiązkowa od kwietnia 2024 z wymaganiami z datą przyszłą do marca 2025) wprowadza: dostosowane podejście (alternatywa dla podejścia zdefiniowanego, wymaga ukierunkowanej analizy ryzyka), rozszerzone wymagania MFA dla wszystkich dostępów do CDE (nie tylko administratorów), bardziej rygorystyczne reguły dotyczące haseł (12+ znaków od stycznia 2025 roku zgodnie z 8.3.6), zwiększona częstotliwość wielu zadań (kwartalne skanowania, roczne testy penetracyjne) oraz wyraźne wymagania dla stron płatności po stronie klienta (6.4.3, 11.6.1 dla wykrywania skimmingu). Systemy transferu plików odczuwają 8.3.6 i wymaganie 10 najbardziej — surowsze uwierzytelnianie i logowanie.
Wymaganie 3: ochrona przechowywanych numerów PAN
Wymaganie 3 zakazuje przechowywania SAD po autoryzacji i nakazuje silną ochronę przechowywanych numerów PAN. Dopuszczalne metody: jednokierunkowe hasze z silną solą (SHA-256 z solą per-PAN o długości 128+ bitów), skrócenie (maksymalnie pierwsze sześć i ostatnie cztery cyfry), tokeny indeksowe z bezpiecznie przechowywanymi podkładkami, lub silne szyfrowanie z powiązanym zarządzaniem kluczami. Dla systemów transferu plików najczystszym podejściem jest tokenizacja przed wejściem pliku do potoku transferu — użyj certyfikowanej usługi tokenizacji PCI (Braintree, Stripe Radar, VGS) i transferuj wyłącznie tokeny. Jeśli surowe numery PAN muszą przejść przez system, użyj AES-256-GCM z kluczami w HSM na poziomie FIPS 140-2 Level 2+.
Wymaganie 4: szyfrowanie transmisji
4.2.1 wymaga silnej kryptografii dla transmisji numerów PAN przez otwarte sieci publiczne. „Silna kryptografia" zgodnie ze słowniczkiem PCI odnosi się do NIST SP 800-57 — AES-256 dla symetrycznej, RSA 3072+ dla asymetrycznej, TLS 1.2+ dla transportu. Należy wyłączyć TLS 1.0 i 1.1 całkowicie (przestarzałe w 2018 roku i zakazane przez wersję 4.0). Konfigurację należy weryfikować kwartalnie za pomocą SSL Labs lub Qualys SSL Test. E-mail jest szczególnie problematyczny — 4.2.2 wymaga, aby numery PAN wysyłane przez technologie wiadomości użytkowników końcowych były nieczytelne przed transmisją. Numer PAN w zwykłym tekście w e-mailu narusza PCI. Zamiast tego należy wysłać bezpieczny link do zaszyfrowanego pliku do pobrania.
Wymaganie 8: MFA w całym CDE
8.4 i 8.5 w PCI DSS 4.0 wymagają MFA dla: (a) całego niezdejnego dostępu do CDE przez personel administracyjny oraz (b) całego zdalnego dostępu do CDE przez jakikolwiek personel. Słowo „cały" jest kluczowe w porównaniu z poprzednimi wersjami — podwykonawcy, audytorzy, użytkownicy wsparcia, nie tylko administratorzy. Dopuszczalne czynniki MFA: coś, co wiesz (hasło), coś, co masz (token sprzętowy, aplikacja telefoniczna), coś, czym jesteś (biometria). Dwa czynniki muszą być niezależne; dwa hasła nie wystarczą. Klucze sprzętowe (YubiKey, Feitian) przez FIDO2 spełniają wymaganie 8.5 bez komplikacji. SMS OTP jest odradzany — NIST SP 800-63B obniżył jego ocenę bezpieczeństwa w 2016 roku.
Wymaganie 10: logowanie i retencja 12-miesięczna
10.2 wymaga dzienników audytu rejestrujących: dostęp poszczególnych użytkowników do CHD, działania użytkowników z uprawnieniami administratora, dostęp do ścieżek audytu, nieprawidłowe próby logicznego dostępu, mechanizmy identyfikacji i uwierzytelniania, inicjalizację dzienników audytu, tworzenie i usuwanie obiektów systemowych. 10.5.1 wymaga retencji przez co najmniej 12 miesięcy z trzema miesiącami natychmiast dostępnymi. 10.7 dodał wymagania dotyczące wykrywania i reagowania na krytyczne awarie kontroli bezpieczeństwa w ciągu 24 godzin. Dla systemów transferu plików CDE należy używać niezmiennego magazynu logów — AWS CloudWatch Logs z CloudTrail, Azure Monitor z politykami niezmiennymi lub Splunk z konfiguracją write-once na poziomie indeksera.
Wymaganie 12: zarządzanie dostawcami
12.8 obejmuje zarządzanie dostawcami usług. Należy prowadzić listę dostawców z opisami usług i zakresem PCI DSS, posiadać pisemne umowy z każdym dostawcą potwierdzające ich odpowiedzialność za bezpieczeństwo CHD, dokumentować, które wymagania PCI zarządza każdy dostawca, i corocznie monitorować status zgodności dostawców. Dla dostawców transferu plików należy zażądać Attestation of Compliance (AOC) zgodnie z PCI DSS. Poziomy: dostawcy Level 1 (przechowujący/przetwarzający/przesyłający 300 tys.+ transakcji/rok) przechodzą roczną ocenę na miejscu; mniejsi dostawcy mogą przeprowadzać samodzielną ocenę.
Redukcja zakresu przez szyfrowanie po stronie klienta
Jeśli dostawca transferu plików nigdy nie widzi numerów PAN w jawnym tekście, ponieważ szyfrowanie zachodzi po stronie klienta przed przesłaniem, dostawca może być poza zakresem PCI. Wytyczne PCI dotyczące tego są niuansowe — PCI SSC Cloud Computing Guidelines z 2019 roku uznają redukcję zakresu przez szyfrowanie pod warunkiem, że: (a) dostawca chmury nie ma dostępu do kluczy, (b) klient zachowuje wyraźną kontrolę nad kluczami, (c) kryptografia jest silna. Usługi z architekturą szyfrowania AES-256-GCM po stronie klienta — HexaTransfer i podobne — mogą służyć jako kanały transferu poza zakresem CDE merchantów przy starannym wdrożeniu. Architekturę należy udokumentować w System of Record.
Testy penetracyjne i zarządzanie podatnościami
11.4 wymaga testów penetracyjnych corocznie i po znaczących zmianach. Dla systemów transferu plików zakres testu penetracyjnego obejmuje: punkty końcowe przesyłania i pobierania, przepływ uwierzytelniania, segment sieci CDE oraz wszelkie API używane do operacji na plikach. Należy zaangażować testera certyfikowanego przez CREST lub zatwierdzonego przez PCI. 11.3 wymaga kwartalnego skanowania podatności przez Approved Scanning Vendor (ASV) dla komponentów zewnętrznych. Skany wewnętrzne są przeprowadzane samodzielnie co kwartał. Ustalenia wysokie i krytyczne należy naprawić w ciągu 30 dni.
Segmentacja sieci i granica CDE
Segmentacja sieci izoluje CDE od sieci poza CDE, zmniejszając zakres. Segmentację należy weryfikować corocznie (11.4.5) testami pokazującymi, że izolacja działa w trybach awarii. Dla systemu transferu plików obsługującego numery PAN należy podzielić potok przesyłania, zaszyfrowany magazyn obiektów, punkty końcowe KMS i potok logowania na dedykowane VPC bez połączeń east-west z ogólnymi sieciami korporacyjnymi. Należy używać prywatnych podsieci, grup bezpieczeństwa z domyślnym odrzuceniem i punktów końcowych VPC do usług chmurowych.
Kompensacyjne kontrole i dostosowane podejście
Dostosowane podejście PCI DSS 4.0 pozwala na alternatywne kontrole, jeśli spełniają cel standardowego wymagania. Wymaga ukierunkowanej analizy ryzyka dokumentującej ryzyko, dostosowaną kontrolę, sposób spełnienia celu i metodę testowania. Dostosowane podejście wymaga akceptacji QSA; nie jest to ćwiczenie DIY. Podejście zdefiniowane jest prostsze; dostosowane należy stosować wyłącznie tam, gdzie zdefiniowane nie pasuje do technologii.
Przygotowanie do oceny
Ocena QSA dla systemu transferu plików obejmuje: wywiady dotyczące zakresu (1–2 dni), próbkowanie dowodów (2–3 tygodnie), wywiady z właścicielami kontroli (3–5 dni), testy techniczne (1 tydzień) i opracowanie raportu (2–4 tygodnie). Należy dostarczyć: diagramy sieciowe, diagramy przepływu danych, inwentarz systemów CDE, próbki przeglądów dostępu, raporty kwartalnych skanów, roczny raport z testów penetracyjnych, procedury zarządzania kluczami, plan reagowania na incydenty z dowodami testowania i listę dostawców z AOC.
Zgodność PCI na poziomie transferu to głównie redukcja zakresu plus dobra higiena kryptograficzna. Tokenizuj numery PAN jak najwcześniej. Wypróbuj na hexatransfer.com — bezpłatnie, bez rejestracji, do 10 GB.
Wysyłaj duże pliki bezpiecznie z szyfrowaniem end-to-end
Przesyłaj pliki do 10 GB za darmo z szyfrowaniem end-to-end. Bez rejestracji. Twoje pliki są szyfrowane w przeglądarce przed przesłaniem — nikt inny nie może ich odczytać.
Wyślij plik