Jeśli przechowujesz PAN (numer karty), to bezwzględnie musi być zaszyfrowany.
Jeśli przechowujesz imię i nazwisko posiadacza karty, datę ważności, numer wydania (i można je połączyć z PAN), to powinni być zaszyfrowane, ale (w moim rozumieniu) nie jest to absolutnie konieczne. PCI-DSS stwierdza tylko, że przynajmniej PAN musi być zaszyfrowany.
Kod CV2/AVS/CSC nie może być przechowywany po autoryzacji, a najlepiej byłoby udowodnić, że w ogóle nie jest przechowywany (np. - przechowywany tylko w pamięci podczas wykonywania autoryzacji)
Jeśli chodzi o certyfikaty/klucze - wystarczy użyć jednego klucza do szyfrowania wszystkich danych związanych z kartą. Najlepszą praktyką jest nieużywanie kluczy do wielu celów, więc jeśli masz inne (niezwiązane z kartą) dane, które są zaszyfrowane, użyj do tego oddzielnego klucza.
Najtrudniejszą częścią jest ta, o której tak naprawdę nie wspomniałeś szczegółowo - i to jest zarządzanie kluczami. Aby spełnić wymagania PCI, klucz musi być przechowywany w osobnym fizycznym pudełku do bazy danych i potrzebna jest możliwość zmiany klucza co najmniej raz w roku. SQL 2008 obsługuje to za pomocą Extensible Key Management (EKM)
Wszystkie te punkty najlepiej omówić z niezależnym QSA (Qualified Security Assessor), z którym w pewnym momencie będziesz musiał się zaangażować, aby spełnić wymagania PCI. Twój QSA będzie w stanie udzielić Ci odpowiedzi na takie pytania, a ostatecznie jego rady, których powinieneś przestrzegać, aby spełnić wymagania.
Warto wspomnieć, że większość ludzi wkrótce zdaje sobie sprawę, jak dużym obciążeniem może być zgodność z PCI, i starają się zminimalizować to obciążenie, korzystając z bramki płatniczej innej firmy. Większość bramek płatniczych umożliwia przeprowadzanie autoryzacji/rozliczenia i przechowywanie danych karty na ich (już zgodnych z PCI) serwerach. Następnie wystarczy przechowywać identyfikator TokenId, który odwołuje się do tych szczegółów płatności, jeśli konieczne będzie wykonanie dalszych opłat/zwrotów na tej karcie.
Powodzenia!
