Sześć mitów o PCI DSS w procesie wydawania kart

Zapytaj w banku o PCI DSS i wydawanie kart, a usłyszysz szereg wygodnych założeń powtarzanych z pełnym przekonaniem. Większość z nich jest tylko częściowo prawdziwa — i właśnie dlatego są niebezpieczne. Brzmią na tyle uspokajająco, że nikt nie zadaje trudniejszych pytań, a pozostawiona luka ujawnia się w najgorszym momencie: podczas oceny zgodności albo po tym, jak karta trafi w niepowołane ręce.

Przyjrzyjmy się sześciu takim założeniom i temu, czego naprawdę wymaga każde z nich. Jeśli odpowiadasz za program kartowy, warto porównać z nimi własne rozwiązanie.

Mit 1: „Jesteśmy zgodni z PCI, więc proces wydawania kart jest zabezpieczony”.

O zgodności często mówi się jak o jednym statusie lub odznace, którą instytucja posiada albo nie. Takie ujęcie ukrywa prawdziwe źródła ryzyka w procesie wydawania kart.

W rzeczywistości PCI DSS na poziomie wydawania kart nie jest jednym statusem, lecz serią odrębnych decyzji projektowych. Każda zamyka konkretną drogę wycieku danych wrażliwych lub utraty rozliczalności. Szyfrowanie numeru karty to jedna decyzja, nieprzechowywanie zabronionych danych — druga, a ścisła kontrola dostępu — trzecia. Instytucja może być zgodna na poziomie sieci, a jednocześnie korzystać z aplikacji wydawniczej, która nie spełnia kilku z tych wymagań. Właściwe pytanie nie brzmi ogólnie „czy jesteśmy zgodni?”, lecz „co konkretnie robi nasz system wydawania kart wobec każdego wymagania standardu?”.

Mit 2: „O zgodności decyduje sieć”.

Zapory sieciowe, segmentacja, szyfrowanie transmisji i coroczna ocena — na tym skupia się większość rozmów o PCI i wszystkie te elementy są ważne. Takie podejście zakłada jednak, że ryzyko znajduje się wyłącznie w infrastrukturze przesyłowej.

W rzeczywistości znaczna część ryzyka znajduje się w aplikacji obsługującej karty podczas ich wydawania. Przez kilka dni przetwarza ona prawdziwe dane kart, tożsamości klientów i informacje o fizycznych kartach przemieszczających się od personalizacji przez kuriera do klienta. To, co przechowuje i wyświetla, kogo dopuszcza oraz co rejestruje, decyduje o kontroli tego okresu. Sieć może być bezbłędna, a aplikacja nadal ujawniać pełne numery kart w raporcie oddziałowym. Zgodność na poziomie aplikacji jest mniej widoczna niż bezpieczeństwo sieci, ale równie istotna.

Mit 3: „Pracownicy wiedzą, że nie wolno ujawniać numerów kart”.

Każdy bank szkoli pracowników. Zakłada się, że ostrożny personel i jasna polityka wystarczą, aby zapobiec ujawnieniu podstawowego numeru rachunku, czyli długiego numeru na przedniej stronie karty.

Każda kontrola zależna od pamiętania o redagowaniu danych w końcu zawiedzie — wystarczy jedno męczące popołudnie. Trwałe rozwiązanie ma charakter strukturalny: pełny numer jest szyfrowany w spoczynku, a wszędzie tam, gdzie widzi go człowiek lub system podrzędny, pojawia się wyłącznie wersja zamaskowana. Na ekranach, w raportach, plikach Excel dla oddziałów i plikach przekazywanych kurierom widoczne jest tylko tyle cyfr, ile potrzeba do identyfikacji karty. Gdy pracownicy operacyjni nie potrzebują pełnego numeru, nigdy go nie widzą i nie muszą pamiętać o jego ukrywaniu. Taką gwarancję PCI Tracker wymusza domyślnie w systemie, a nie przez samo szkolenie.

Mit 4: „Przechowujemy dane karty na wypadek, gdyby były później potrzebne”.

Zachowywanie danych może wydawać się rozsądne: skoro kiedyś trzeba będzie coś sprawdzić, lepiej je mieć. W procesie wydawania kart taki odruch staje się jednak źródłem odpowiedzialności i ryzyka.

Niektórych danych po autoryzacji karty po prostu nie wolno przechowywać: kodu bezpieczeństwa z rewersu, kodu PIN ani pełnych danych ścieżki paska magnetycznego. Dobrze zaprojektowany system wydawniczy nie zachowuje ich „na wszelki wypadek”. System śledzenia wydawania kart ma rejestrować zdarzenia — przejścia karty między etapami, osoby odpowiedzialne i czas — a nie przechowywać sekrety. Nie ma powodu zapisywać wartości zabronionych przez standard, więc tego nie robi. Najbezpieczniejsze są dane, których nigdy nie zatrzymano.

Porównaj własne rozwiązanie ze wszystkimi sześcioma punktami. Zobacz, jak PCI Tracker domyślnie wbudowuje te decyzje w warstwę wydawania kart.

Poznaj PCI Tracker

Mit 5: „Każdy pracownik operacyjny potrzebuje pełnego dostępu”.

Szeroki dostęp może wyglądać na efektywny: jeśli zespół widzi wszystko, nikt nie czeka na uprawnienia. W programie kartowym właśnie tak drobny incydent przeradza się w poważny.

Właściwą zasadą są najmniejsze uprawnienia: każdy użytkownik uzyskuje dostęp wyłącznie do informacji wymaganych przez jego rolę. Pracownik oddziału widzi karty własnego oddziału, nie całej instytucji. Dostęp jest uwierzytelniany w centralnym katalogu banku zamiast na osobnej liście haseł. Nieaktywne sesje wygasają, a kolejne nieudane logowania blokują konto. Każdy z tych środków jest niewielki, lecz razem sprawiają, że dostęp jest świadomie nadawany i ograniczają zasięg przejętego konta.

Mit 6: „Jeśli coś pójdzie nie tak, odtworzymy przebieg zdarzeń”.

Plan po incydencie często zakłada odtworzenie historii z dostępnych dzienników. Działa to tylko do chwili, gdy naprawdę jest potrzebne — wtedy okazuje się, że luki dotyczą właśnie najważniejszych zdarzeń.

Ścieżka audytowa obejmująca tylko część działań jest niewiele lepsza niż jej brak, ponieważ problemy ukrywają się w niezarejestrowanych miejscach. Pełne rejestrowanie obejmuje logowania, dostęp do ekranów, przesyłanie plików, nieudane próby i blokady — zawsze z użytkownikiem, adresem IP, działaniem i znacznikiem czasu. Na poziomie pojedynczej karty zapisuje się każdą zmianę statusu, wiadomość, notatkę, załącznik i próbę doręczenia. PCI Tracker działa według tej zasady produkcyjnie w QNB ALAHLI Egypt, gdzie każde działanie kontrolera otrzymuje użytkownika, adres IP i czas. Nic istotnego nie dzieje się anonimowo, więc nie trzeba później rekonstruować historii — zapis od początku jest kompletny.

Jeszcze jedno założenie, z którego warto zrezygnować

Pod sześcioma mitami kryje się jedno głębsze założenie: że zgodność można nałożyć na system jako warstwę polityk i czujności, zamiast wbudować ją w sam system. To rzadko się sprawdza. Maskowanie zależne od ludzkiej pamięci, zasady dostępu egzekwowane zaufaniem zamiast oprogramowaniem i ścieżki audytowe składane po fakcie wyglądają dobrze tylko do dnia prawdziwego testu.

Alternatywą jest uczynienie zgodnego działania ścieżką domyślną i najprostszą poprzez wbudowanie tych decyzji w aplikację wydawniczą. Wtedy prawidłowe wykonanie pracy i wykonanie jej zgodnie ze standardem stają się tym samym działaniem. Niezależnie od tego, czy oceniasz PCI Tracker, czy własne rozwiązanie, to jest właściwy test: nie obietnica zgodności wokół systemu, lecz zgodność wbudowana w jego działanie.

Praktyczny wniosek

Zgodność na poziomie aplikacji nie rzuca się w oczy. Widać ją w zamaskowanym numerze, wartości, której nigdy nie zapisano, wygasłej sesji i wpisie dziennika przypisującym działanie konkretnej osobie. Każda decyzja jest dyskretna, ale razem odróżniają program kartowy odporny na kontrolę od takiego, który jedynie sprawia takie wrażenie.

Od dwudziestu pięciu lat budujemy systemy dla banków i instytucji, w których taka dyscyplina jest obowiązkowa. Należy do nich PCI Tracker, działający produkcyjnie w QNB ALAHLI Egypt jako system ewidencji wydawania kart i kodów PIN. Jeśli sprawdzasz odporność własnego procesu wydawania na poziomie aplikacji, chętnie przejdziemy przez tę ocenę razem z Tobą.

Najczęściej zadawane pytania

Rozwiązanie stojące za tym podejściemPCI Tracker — wydawanie kartMaskowanie, najmniejsze uprawnienia i pełne ścieżki audytowe domyślnie wbudowane w warstwę wydawania kart.