Wyznacz rzeczywistą granicę płatności
Zmapuj ścieżkę kupującego od strony produktu po potwierdzenie. Oznacz miejsce wprowadzania danych karty, przekierowania, ramki (iframe), skrypty, API, wtyczki, menedżery tagów, sieci dostarczania treści i konta administratorów, które mogą na to wpływać. Uwzględnij powiązane logi, narzędzia wsparcia i analitykę. To jest początkowy zapis dla twojego dostawcy lub oceniającego, a nie decyzja o zgodności.
Zanotuj domenę dostarczającą każdy element strony płatności. PCI SSC mówi, że kwalifikowalność do SAQ A wymaga, aby wszystkie elementy strony płatności pochodziły wyłącznie od dostawców zgodnych z PCI DSS i aby żaden element nie pochodził z domeny sprzedawcy. Dla SAQ A-EP każdy element może pochodzić od sprzedawcy lub takiego dostawcy, ale nie z innego źródła. Wszystkie pozostałe kryteria nadal obowiązują.
Repozytorium kodu może pominąć wstrzyknięcia z menedżera tagów i ustawienia platformy. Przejrzyj skrypty, ramki, domeny i nagłówki podczas normalnej sesji checkout w przeglądarce.
Przejrzyj logi, analitykę i procesy wsparcia pod kątem pól płatności. Nigdy nie używaj prawdziwych danych karty w zgłoszeniach testowych ani w dowodach współdzielonych.
Zmniejsz ekspozycję przy pomocy zrozumiałego modelu płatności
Gdzie to praktyczne, używaj integracji, w której dostawca zgodny z PCI DSS zbiera dane karty zamiast twojej aplikacji je odbierać lub przechowywać. Pełne przekierowanie hostowane przez dostawcę jest często prostsze niż formularz własny, ale osadzone pola i iframe nadal mogą pozwolić twojej stronie wpływać na płatność. Dokumentuj rzeczywistą integrację zamiast polegać jedynie na etykiecie „hostowane”.
Unikaj przechowywania numerów kont głównych, kodów weryfikacyjnych, zrzutów ekranu z błędami checkoutu czy kopiowanych danych płatniczych, chyba że zatwierdzony projekt tego wymaga. Szyfrowanie pomaga chronić dane, ale PCI SSC ostrzega, że samo szyfrowanie zwykle nie wyłącza środowiska ze skopu. Potwierdź obsługę tokenów, kluczy, webhooków, zwrotów i podział obowiązków z dostawcą i kwalifikowanymi recenzentami.
Przechowuj przewodnik integracji, informacje o odpowiedzialnościach, odpowiednie dokumenty zgodności i proces powiadamiania o zmianach razem z zapisem architektury.
Nie dodawaj eksperymentów marketingowych, narzędzi do odtwarzania sesji, widżetów czatu ani opcjonalnych bibliotek bez przypisanego właściciela i przeglądu tego, do czego mają dostęp.
Kontroluj skrypty, tagi i nagłówki
Kod przeglądarkowy stron trzecich może wprowadzić niekontrolowane zmiany, dowolne wykonywanie kodu i ujawnianie danych innym podmiotom. Prowadź inwentarz checkoutu z domeną każdego skryptu, jego celem, właścicielem, zatwierdzeniem i miejscem ładowania. Uwzględnij reguły menedżera tagów i kod ładowany przez dostawców, a nie tylko pliki w drzewie źródeł.
PCI SSC koncentruje się na autoryzowanych skryptach, integralności, monitorowaniu manipulacji i nagłówkach wpływających na bezpieczeństwo. Zatwierdź bazę odniesienia, ograniczaj zmiany, wykrywaj różnice i je wyjaśniaj. Content Security Policy (CSP) może ograniczyć źródła zasobów. Tam, gdzie to stosowne, przetestuj CSP w trybie report-only przed wymuszeniem. CSP jest elementem obrony w głębi, a nie zastępstwem bezpiecznego kodowania czy przeglądu.
Subresource Integrity może odrzucić zmieniony skrypt z zewnętrznego źródła, ale wymaga zgodnej konfiguracji cross-origin i może przestać działać po aktualizacjach dostawcy.
Ogranicz role publikowania, wymagaj silnego uwierzytelniania, sprawdzaj możliwość uruchamiania kodu niestandardowego i zachowuj ścieżkę audytu.
Ogranicz dostęp i spraw, by zmiany w checkoutie były odwracalne
Oddziel rutynowe publikowanie treści od kodu checkoutu, administracji dostawcy płatności, hostingu, DNS i zarządzania tagami. Używaj kont z nazwą użytkownika, zasady najmniejszych uprawnień i uwierzytelniania wieloskładnikowego, gdy jest dostępne. Przeglądaj dostęp po zmianach ról i usuwaj byłych pracowników, dostawców i agencje. Dokładne zastosowanie PCI DSS zależy od środowiska, lecz zmniejszenie współdzielonych i stałych uprawnień redukuje ryzyko.
Stosuj proces wydania dla checkoutu: nazwany właściciel, przegląd, testy tam, gdzie to możliwe, metoda rollbacku i kontrola po wydaniu. Testuj ścieżki sukcesu i porażki płatności, przekierowania i zachowanie mobilne. Status Is UP wspiera proaktywne przygotowanie do uruchomienia, optymalizację wydajności i planowanie rollbacku wokół wydań; nie determinuje on zgodności z PCI DSS.
Przechowuj dane uwierzytelniające, kody zapasowe i instrukcje rollbacku w zatwierdzonych systemach z kontrolą dostępu, nigdy w ticketach, zrzutach ekranu czy repozytoriach publicznych.
Po wydaniu porównaj widoczne w przeglądarce skrypty, domeny i nagłówki z zatwierdzonym inwentarzem.
Aktualizuj stos i weryfikuj rezultat
Utrzymuj inwentarz platformy handlowej, wtyczek, motywów, komponentów serwera, bibliotek, SDK płatności, szablonów tagów i usług wpływających na checkout. Subskrybuj krytyczne powiadomienia od dostawców. NIST opisuje zarządzanie poprawkami jako identyfikowanie, priorytetyzowanie, pozyskiwanie, instalowanie i weryfikowanie aktualizacji. Rejestruj zmianę, testuj ścieżkę płatności i potwierdzaj, co zostało wdrożone.
Ustal ścieżkę awaryjną dla wysokiego ryzyka oraz okno konserwacyjne dla rutynowych zmian. Priorytetyzuj komponenty checkoutu narażone na ryzyko, ale nie poprawiaj produkcji na ślepo i nie psuj płatności. Używaj przetestowanego podejścia rollback i wskazówek wydawniczych dostawcy. Nieznany właściciel dla przestarzałego komponentu to ryzyko do rozwiązania.
Przechowuj poradę, decyzję o ryzyku, wynik testu, zapis wdrożenia i końcową weryfikację razem.
Przechowuj dowody i korzystaj z kwalifikowanej pomocy
Przechowuj diagramy, informacje o odpowiedzialności dostawcy, uzasadnienie kwalifikowalności SAQ, inwentarze skryptów i nagłówków, przeglądy dostępu, zatwierdzenia, wyniki testów, zmiany i kontakty do dostawców w kontrolowanym miejscu. Odświeżaj je, gdy zmienia się architektura, własność, skrypty lub dostawcy. Dowody mają ułatwiać pracę uprawnionemu recenzentowi bez ujawniania danych kart, sekretów ani zapisów klientów.
Twój akceptant lub marka płatności ustala obowiązujące oczekiwania walidacyjne. PCI SSC identyfikuje Qualified Security Assessors jako niezależne organizacje uprawnione do przeprowadzania ocen PCI DSS oraz Approved Scanning Vendors jako kwalifikowanych dostawców skanowań zewnętrznych w odpowiednich wymaganiach. Szukaj kwalifikowanej pomocy dla niestandardowego checkoutu, niejasnego zakresu, podejrzenia kompromitacji lub wyboru SAQ.
Przechowuj model checkoutu, właścicieli technicznych, kontakty eskalacyjne, datę ostatniego przeglądu i linki do dowodów razem.