Ktoś przechowuje dane karty kredytowej-Jak to robi?

Aby dostawcy przetwarzali i przechowywali informacje o twojej karcie kredytowej, zazwyczaj muszą uzyskać certyfikat PCI. Wymagania powinny być opisane tutaj. Niektóre wymagania są bardzo proste, a inne niejasne i otwarte na interpretację. Przechodzenie przez ten proces nie jest zabawne, a firma posiadająca certyfikat nie oznacza, że Twoje dane są bezpieczne.

Ale to chyba lepsze niż nic.

Jest to dość łatwe do przechowywania solony hash numeru karty kredytowej, a nie sam numer dla bezpiecznego wyszukiwania. Dla 99% scenariuszy tam, to byłaby wystarczająca karta kredytowa do przechowywania -- szybkie i bardzo bezpieczne.

Jeśli naprawdę potrzebujesz odwracalnego szyfrowania karty kredytowej dla jakiegoś scenariusza (na przykład kontynuowanie rozliczeń), wybrałbym symetryczny klucz przechowywany w bezpiecznym miejscu Inny niż baza danych. Dawno nie patrzyłem na PCI specyfikacje, ale jestem pewien, że jest zgodny z PCI.

Jeśli potrzebujesz szybkiego wyszukiwania wraz z odwracalnym szyfrowaniem, użyj obu opcji: hash i szyfrowanie.

Edit: Moja odpowiedź budzi pewne kontrowersje. Chciałbym zwrócić uwagę na następujący bardzo ciekawy esej z Integrity.com (PDF):

Haszowanie Numerów Kart Kredytowych: Niebezpieczne Praktyki Aplikacyjne

Opisuje wiele problemów związanych z przechowywaniem hash kredytu dane karty, ale jej wniosek potwierdza moją sugestię.

Tak, surowy hash karty nie jest bezpieczny; dlatego solimy nasze hashy! Ale sól statyczna również nie jest Bezpieczna, pozwalają na tworzenie tablic tęczowych dla znanych soli statycznych. Najlepiej więc, aby nasze sole różniły się w sposób nieprzewidywalny. W przypadku haseł wystarczy użyć osobnego, losowego skrótu dla każdego sprawdzanego hasła; może on znajdować się nawet w tej samej tabeli/wierszu co hashowane hasło. Dla sprawy z kart kredytowych, to powinno być to samo -- losowa sól dla każdego przypadku karty kredytowej jest zaszyfrowany. Jeśli numer karty kredytowej jest przechowywany dla każdej transakcji, osobny salt dla każdej transakcji.

Są plusy i minusy tego podejścia, ale jest wystarczająco bezpieczne. Plusy to brak zarządzania kluczami; salt i hash są tam i nie muszą się zmieniać, a jednocześnie pozwalają na kontrolę kontroli hash; np. czy ten hash karty kredytowej pasuje do tej znanej karty kredytowej numer?

Wady są w poszukiwaniu; nie jest możliwe skuteczne wyszukiwanie konkretnego numeru karty kredytowej w wielu transakcjach.

Oczywiście i tak będziesz miał ten problem z zewnętrznym szyfrowaniem; jeśli baza danych nie jest sama zaszyfrowana (coś, co obsługuje tylko niektóre bazy danych), nie będziesz w stanie dobrze wyszukiwać. Nawet wtedy szyfrowanie na poziomie bazy danych lub nawet tabeli znacznie zmniejsza skuteczność wyszukiwania.

Ostatnie kilka razy pracowałem z płatności kartą kredytową, nigdy tak naprawdę przechowywane rzeczywiste informacje CC na własnych serwerach. Pozwoliłeś bramce płatniczej się tym zająć. Otrzymałeś identyfikator transakcji, za pomocą którego możesz sprawdzić, czy karta kredytowa nadal jest ważna i czy dostępna jest żądana kwota gotówki. Następnie po spakowaniu rzeczy, które kupili, wydasz polecenie przechwytywania do bramki płatności.

To podejście znacznie uprościło proces integracja płatności CC na stronie, ponieważ wszystko, co kiedykolwiek trzeba wiedzieć, to identyfikator transakcji dla konkretnego klienta. To oczywiście nie pozwoliło Ci zrobić z amazon - "trick" przechowywania informacji o CC na zakupy 1-click. Jeśli identyfikator transakcji został naruszony, można go jedynie wykorzystać do wcześniejszego odebrania płatności lub całkowitego anulowania transakcji (w takim przypadku dowiesz się o tym, gdy zweryfikujesz, że autoryzacja była nadal ważna przed wysyłką). Transakcja nie mogła być służy do zebrania większej kwoty niż to, co klient wcześniej zatwierdził, ani nie pozwala komuś zebrać na inne konto niż to, do czego skonfigurowano "sklep".

Może nie jest to dokładna odpowiedź, której szukałeś, ale może to rozwiąże Twój ogólny problem bez konieczności wydawania fortuny na dostawców zabezpieczeń.

W niektórych sytuacjach klucze szyfrujące są przechowywane nie na dysku, ale na jakimś urządzeniu sprzętowym. Albo specjalny serwer szyfrujący jest używany do szyfrowania/deszyfrowania, albo deszyfrowanie odbywa się za pomocą klucza przechowywanego na, powiedzmy, klucza sprzętowego. W ten sposób haker nie może ukraść kluczy odszyfrowujących bez kradzieży fizycznego urządzenia, które je zawiera(ponieważ klucz nigdy nie opuszcza urządzenia).

Inną metodą, jaką widziałem, jest przechowywanie zaszyfrowanych danych w bazie danych/centrum danych, które nie ma bezpośredniego połączenia do świata zewnętrznego (nie możesz włamać się do tego, do czego nie masz dostępu). Serwer interfejsu znajduje się między "bezpieczną" częścią sieci a "dostępną przez Internet"/"niebezpieczną" częścią sieci jako proxy. Zmuszanie bezpiecznego ruchu do przechodzenia przez Ten przewód bezpieczeństwa może utrudnić intruzowi dostęp do zabezpieczonych danych.

Żadne z nich nie oznacza, że Twoje dane są oczywiście całkowicie bezpieczne.

Jako sprzedawca możesz przechowywać dane CC we własnej bazie danych lub zlecić je zewnętrznym dostawcom.
Dostawcy zewnętrzni, tacy jak IPPayments lub główne banki, takie jak Westpac w Australii, są zgodne z PCI poziomu 1. W przypadku aplikacji internetowych możesz wybrać stronę akceptującą płatności (prezentowaną gdzieś w obiegu pracy klienta) z nich oznaczoną marką dla Twojej firmy. W przypadku aplikacji windows (np. aplikacji CRM Twojej firmy) i płatności cyklicznych zazwyczaj korzystaj z bramy przy użyciu ich API, które zapewniają usługę tokenizacji, to znaczy akceptują numer CC, rejestrują go i zwracają unikalny token, który wygląda jak numer CC. Token może być bezpiecznie przechowywany w Twoim DB i używany do dalszych transakcji, płatności wsadowych, uzgadniania itp. z bankiem. Oczywiście, że dużym problemem jest koszt operacyjny na transakcję. W przypadku narzędzia, które pobiera miesięczną płatność kartą kredytową od miliona klientów, koszt transakcji może być znaczny.

Jeśli zdecydujesz się przechowywać numer CC we własnym DB potrójne szyfrowanie DES jest wystarczające. Lepszą opcją jest przejrzyste szyfrowanie w DB oferowane przez Oracle advanced security lub SQLServer, gdzie nawet DBA nie może odszyfrować numeru CC. Następnie istnieje uciążliwa odpowiedzialność za zarządzanie kluczami, tworzenie kopii zapasowych, bezpieczeństwo fizyczne, bezpieczeństwo sieci, transmisja SSL, Zmiana domyślnych ustawień wszystkich urządzeń serwerowych i zapory, antywirusy, audyt, kamery bezpieczeństwa i on i on ...

Po pierwsze, jeśli zajmujesz się numerami kart kredytowych, musisz stać się zgodny z PCI-DSS, a po zapisaniu numerów wszystkie 12 sekcji specyfikacji PCI-DSS będą miały zastosowanie do ciebie. To duży koszt dla większości organizacji, a jeśli nie masz czasu, zasobów i środków finansowych, nie powinieneś iść ścieżką przechowywania numerów kart kredytowych.

Uzyskaliśmy zgodność z PCI-DSS w systemie e-commerce opartym na systemie Windows, który przechowuje Karty kredytowe. Wykorzystuje 256-bitowy AES szyfrowanie. Sam klucz jest szyfrowany za pomocą Windows DPAPI, co oznacza, że może być odszyfrowany tylko przez proces działający pod tym samym kontem użytkownika, co ten, który go zaszyfrował. Zaszyfrowany klucz jest przechowywany w rejestrze.

Klucz jest obracany co 12 miesięcy, a kopia zapasowa jest przechowywana w 3 częściach A, B,C i rozłożona na 3 dyski USB, z których każda jest przechowywana przez inną osobę. Dysk 1 mA A + B, Dysk 2 ma B + C, Dysk 3 MA A + C. Więc dowolne 2 napędy są wymagane do zbudowania pełnego klucza (A + B+C). Ten schemat jest tolerancyjny na utratę dowolnego 1 napędów. Same kluczowe części są szyfrowane hasłem znanym tylko właścicielowi dysku.

Twoje założenie, że sprzedawca musi przechowywać kartę jest nieprawidłowe. Najprawdopodobniej sprzedawca przechowuje token, który otrzymał od bramki przetwarzania płatności przy pierwszym użyciu karty. Token jednoznacznie identyfikuje kombinację sprzedawcy i karty. Następnie możesz dokonywać zakupów u tego sprzedawcy bez ponownego podawania numeru karty. Jeśli baza danych sprzedawcy jest zagrożona, tokeny mają niewielką wartość dla atakującego. Są ważne tylko dla tego kupca, a wszystkie mogą zostać anulowane od razu po wykryciu naruszenia.

Aby odpowiedzieć na konkretne pytanie, możliwe jest przechowywanie klucza szyfrowania karty kredytowej zaszyfrowanego na dysku. Klucz szyfrujący może pochodzić z hasła, które należy wprowadzić podczas uruchamiania serwera. Tajny schemat dzielenia Shamira może być użyty tak, aby K Z N akcji były wymagane do skonstruowania tajemnicy, która będzie używana jako klucz szyfrujący. Odszyfrowany klucz/sekret szyfrowania jest następnie przechowywany w pamięci. Jeśli serwer musi zostać ponownie uruchomiony, potrzebujesz akcji K. To jest oczywiście duże koszty i większość sprzedawców, których znam, nie wdraża tego. Zwykle jednak przechowują klucz oddzielnie od zaszyfrowanych danych dla pewnego pośredniego bezpieczeństwa, więc dostęp do jednego nie oznacza automatycznie dostępu do drugiego w całości(nadal bardzo źle).

Usunąłem treść mojego oryginalnego postu, ponieważ nie odpowiedział bezpośrednio na pytanie. Wystarczy powiedzieć, że zarządzanie kluczami i prawidłowe szyfrowanie są ważnym elementem, ale nadal niewielką częścią historia.

Audytorzy PCI nie mogą zapewnić, że wszystko jest zrobione poprawnie.

Jeśli chcesz wyeliminować bóle głowy związane z kradzieżą kart kredytowych, zahaszuj je za pomocą wartości salt nie przechowywanych w bazie danych (Oprócz wartości salt przechowywanych w bazie danych). Hashing je z każdym nowoczesnym algorytmem hashing będzie dość dużo umieścić do końca większość problemów z kradzieżą karty kredytowej, ale to oznacza, że konsumenci muszą ponownie wprowadzić swoją kartę kredytową przy każdym zakupie. Pracując nad projektem, który zajmował się przechowywaniem numerów kart kredytowych, odkryłem, że hashowanie ich obniża koszty przeglądu zabezpieczeń o rząd wielkości (przyznany, że projekt był przed PII obawy).

Jeśli zamierzasz używać szyfrowania symetrycznego, wtedy wkraczasz w nową sferę komplikacji, która sprowadza się do zarządzania i kontroli nad kluczami deszyfrującymi. Powiem, że nawet jeśli hash numery kart kredytowych nadal będziesz musiał radzić sobie z odwracalnym szyfrowaniem, ponieważ wszystkie PII (dane osobowe) muszą być szyfrowane. SQL Server 2008 ma nową rozszerzalną architekturę wtyczek do zarządzania Kluczami który pozwala używać programów innych producentów do zarządzania kontrolą nad kluczami deszyfrującymi, w tym kluczami dzielonymi.

Po więcej informacji: wdrożenie SQL Server 2008 w oparciu o Payment Card Industry Data Security Standards (PCI DSS) w wersji 1.2.

Każdy zautomatyzowany system odszyfrowywania zaszyfrowanych informacji będzie całkowicie niezabezpieczony. Automatyzując proces, pokonujesz szyfrowanie. Wszelkie zaszyfrowane dane powinny być odszyfrowane tylko przez wprowadzony przez użytkownika tajny klucz.