Dane karty, których nie wolno przechowywać.
Wymaganie 3 dotyczy ochrony przechowywanych danych konta i wyznacza twardą granicę. Numer głównego konta (PAN), jeśli jest przechowywany, musi być nieczytelny. Natomiast wrażliwe dane uwierzytelniające, takie jak kod weryfikacyjny karty (trzy lub cztery cyfry), pełne dane z paska magnetycznego lub chipa oraz PIN, nie mogą być przechowywane po autoryzacji płatności. W przypadku typowych przepływów akceptacji płatności, traktuj to jako: nie przechowuj ich, nawet w formie zaszyfrowanej. (Wydawcy kart mają wąskie, kontrolowane wyjątki; większość zespołów nie jest wydawcami). Decyzja zapada w kodzie, w tym, co Twoje procedury zapisują.
The shapes the same control failure takes.
Wymaganie 3 jest naruszane, gdy zmiana zapisuje dane konta, których nie powinna, lub przechowuje je w czytelnej formie. Typowe przypadki:
Wrażliwe dane uwierzytelniające są przechowywane
Kod weryfikacyjny karty, pełne dane z paska magnetycznego lub PIN są zapisywane do bazy danych, pamięci podręcznej lub kolejki po autoryzacji, czego przepływ akceptacji płatności nie powinien robić, nawet w formie zaszyfrowanej.
PAN jest przechowywany w czytelnej formie
Numer głównego konta jest zapisywany bez szyfrowania, skracania lub tokenizacji, przez co pozostaje czytelny w spoczynku.
Dane konta trafiają do nowego magazynu
Dane karty zaczynają być zapisywane w miejscu nieprzystosowanym do ich ochrony (log, zdarzenie analityczne, tabela debugowania), co włącza ten magazyn do zakresu.
Usunięto krok maskowania lub tokenizacji
Krok, który skracał lub tokenizował PAN przed zapisem, został usunięty, przez co pełny numer jest teraz przechowywany.
Dane karty są przechowywane dłużej niż to konieczne
Zmiana usuwa ograniczenia retencji lub czyszczenia, które ograniczały czas przechowywania danych konta, przez co gromadzą się one poza potrzebami biznesowymi.
Zapisywanie kodu weryfikacyjnego karty do ponownych prób.
Płatność czasami wymaga ponownego wysłania, a wygodnie byłoby ponownie przesłać oryginalne dane. Zmiana zapisuje więc całą ładunek płatności, w tym kod weryfikacyjny karty, do tabeli zamówień. Ułatwia to ponowne próby, ale zapisuje dane, których nigdy nie wolno przechowywać po autoryzacji.
- await orders.insert({ id, amount, last4: card.last4 })+ await orders.insert({ id, amount, card }) // full card incl. cvcreturn orderZapisywanie pełnego obiektu karty przechowuje kod weryfikacyjny karty po autoryzacji, czego Wymaganie 3 zabrania w przepływie akceptacji płatności, nawet jeśli kolumna jest zaszyfrowana. Przechowuj tylko to, co jest dozwolone (np. ostatnie cztery cyfry i token od procesora płatności), a nie kod weryfikacyjny, pełne dane z paska magnetycznego ani PIN.
Przechowywane dane konta są wyszukiwane, a nie tylko pyta się o nie.
Ocena PCI DSS sprawdza, jakie dane konta są faktycznie przechowywane i gdzie: weryfikuje, czy wrażliwe dane uwierzytelniające nie są zatrzymywane po autoryzacji oraz czy każdy przechowywany PAN jest nieczytelny. Zmiana, która zaczęła zapisywać kod weryfikacyjny lub nieskrócony PAN, to dokładnie to znalezisko, które się ujawnia, i włącza do zakresu każdy magazyn, którego dotyczy. Najtańszym miejscem do złapania tego błędu jest diff do procedury.
Przegląd, a nie QSA.
heygrc sygnalizuje zmiany, które dotyczą Wymagania 3, i cytuje to wymaganie, aby naprawa nastąpiła w pull request. Nie przeprowadza oceny ani nie wypełnia Twojego Kwestionariusza Samooceny. Wychwytuje moment, w którym zmiana zapisuje dane konta, których nie powinna, na poziomie diff.