Procesowanie numeru PIN w chmurze

Czy można procesować numer PIN w chmurze? Tak – pod warunkiem, że operacje kryptograficzne na blokach PIN wykonują certyfikowane płatnicze moduły HSM, a podział odpowiedzialności między dostawcę chmury i klienta pokrywa wszystkie wymogi PCI PIN Security. AWS oferuje w tym celu zarządzaną usługę Payment Cryptography, Azure – dedykowane moduły payShield 10K, a Google Cloud wymaga płatniczego HSM strony trzeciej.

Definicja kanoniczna: Procesowanie numeru PIN w chmurze to wykonywanie operacji kryptograficznych na blokach PIN (translacja, weryfikacja, generowanie) w płatniczych modułach HSM udostępnianych w modelu chmurowym, z zachowaniem wymogów standardu PCI PIN Security.

Dla acquirerów, procesorów i fintechów budujących switch transakcyjny to jedna z ostatnich barier pełnej migracji do chmury – i decyzja, którą warto podjąć na danych, nie na materiałach marketingowych.

PIN w chmurze – w skrócie:

AWS Payment Cryptography to w pełni zarządzana usługa API oparta na modułach HSM z certyfikacją PCI PTS HSM; posiada własną atestację PCI PIN (AOC) oraz atestacje komponentów P2PE typu DMCP, KMCP i KLCP (AWS Security Blog).
AWS figuruje w Visa Global Service Provider Registry jako ESO i PIN-Acquiring TPS, co pozwala QPA klienta powoływać się na zgodność usługi bez ponownej oceny jej wnętrza (dokumentacja AWS).
Azure Payment HSM to usługa bare-metal z dedykowanymi, jednodostępowymi modułami Thales payShield 10K (FIPS 140-2 poziom 3, PCI HSM v3), nad którymi wyłączną kontrolę administracyjną ma klient; usługa posiada certyfikacje PCI PIN, PCI DSS i PCI 3DS (Microsoft Azure Blog).
Google Cloud nie oferuje własnego płatniczego HSM – Cloud HSM to moduły ogólnego przeznaczenia bez funkcji płatniczych; procesowanie PIN na GCP wymaga płatniczego HSM strony trzeciej (np. usługi subskrypcyjnej payShield Cloud HSM Thales, integrującej się z AWS, Azure i GCP – komunikat Thales).
Niezależnie od dostawcy klient odpowiada za swoją część wymogów PCI PIN: konfigurację dostępu, polityki kluczy, a w modelu Azure także za pełne operacje zarządzania kluczami i ceremonie.
Patronusec jako akredytowany QSA weryfikuje architektury PIN w chmurze pod kątem PCI PIN – od mapowania podziału odpowiedzialności po przygotowanie do oceny QPA.

Spis treści

Czy przetwarzanie numeru PIN w chmurze jest zgodne z PCI PIN?

Tak, standard PCI PIN nie zakazuje chmury – wymaga, aby operacje na PIN wykonywały certyfikowane urządzenia SCD, a każdy wymóg miał właściciela. Dostawcy chmury zamykają swoją część własnymi atestacjami AOC i przewodnikami podziału odpowiedzialności, a klient odpowiada za konfigurację i procesy po swojej stronie.

Mechanizm formalny działa analogicznie jak w PCI DSS: dostawca przechodzi własną ocenę QPA i publikuje AOC wraz z Shared Responsibility Guide, a QPA klienta traktuje zgodność dostawcy jako spełnienie wymogów, które ten dostawca pokrywa. Dokumentacja AWS opisuje wprost, że asesorzy klientów przyjęli tu model znany z PCI DSS: AOC dostawcy plus przewodnik odpowiedzialności zamykają wymogi po stronie usługi.

Drugim filarem jest rejestr organizacji płatniczych. AWS Payment Cryptography figuruje w Visa Global Service Provider Registry jako ESO (Encryption and Support Organization) oraz PIN-Acquiring TPS – co według dokumentacji AWS pozwala uczestnikom programu korzystać z usługi bez dodatkowej oceny jej wnętrza przez QPA klienta.

W chmurze zgodność z PCI PIN nie jest cechą platformy, lecz sumą dwóch połówek: atestacji dostawcy pokrywającej sprzęt i operacje HSM oraz kontroli klienta pokrywających dostęp, polityki kluczy i integrację z resztą środowiska.

W praktyce oznacza to: pytanie brzmi nie „czy chmura może”, tylko „gdzie dokładnie przebiega granica odpowiedzialności w wybranym modelu” – a ta granica w AWS i Azure przebiega w zupełnie innych miejscach.

Jak działa AWS Payment Cryptography i co pokrywa jego atestacja?

AWS Payment Cryptography to w pełni zarządzana usługa API: klient wywołuje operacje płatnicze (translacja PIN, weryfikacja PVV, generowanie kluczy), a AWS utrzymuje w tle moduły HSM certyfikowane w programie PCI PTS HSM wraz ze zgodnym z PCI PIN zarządzaniem kluczami. Klient nie administruje żadnym urządzeniem.

Zakres funkcjonalny według dokumentacji AWS obejmuje m.in.:

translację PIN między formatami bloków ISO 9564 (0, 1, 3, 4) i między kluczami PEK a DUKPT, w całości wewnątrz granicy HSM – blok PIN nigdy nie opuszcza usługi jawnie, a translacja między różnymi PAN jest zablokowana zgodnie z PCI,
generowanie i weryfikację PIN oraz wartości PVV (funkcje wydawcy) z rekomendacją rozdzielenia uprawnień od funkcji acquirerskich,
wymianę kluczy w key blocks TR-31 (w tym klucze dynamiczne przekazywane per transakcja), dystrybucję TR-34, wymianę ECDH oraz fizyczną wymianę kluczy na potrzeby key injection.

Zakres atestacyjny: usługa posiada własny pakiet zgodności PCI PIN (AOC, według AWS Security Blog zamknięty bez ustaleń) oraz atestacje komponentów P2PE – deszyfracji (DMCP), zarządzania kluczami (KMCP) i ładowania kluczy (KLCP); pakiety obejmują też przewodnik podziału odpowiedzialności dostępny w AWS Artifact. AWS oferuje również osobny przewodnik „PIN Compliance Planning” opisujący dowody, które klient musi przygotować do własnej oceny.

Ograniczenia do świadomego przyjęcia: interfejs jest natywny dla AWS (aplikacje pisane pod klasyczne komendy hostowe payShield wymagają przepisania warstwy integracji), a dostępność regionalna rośnie stopniowo – AWS ogłaszał rozszerzenia m.in. o regiony São Paulo i Sydney. Uwaga na mylenie usług: AWS CloudHSM ma własną atestację PCI PIN, ale to moduł ogólnego przeznaczenia – sam AWS wskazuje Payment Cryptography jako właściwe narzędzie do operacji płatniczych takich jak translacja PIN.

Patronusec Insight: Z naszego doświadczenia projektowego wynika, że zespoły wybierające zarządzane API najbardziej nie doceniają jednego artefaktu: mapy wymogów PCI PIN z przypisaniem „AWS / klient / wspólne” zrobionej przed rozpoczęciem budowy. Przewodnik podziału odpowiedzialności dostawcy opisuje jego połowę, ale nie zaprojektuje za Ciebie kontroli dostępu IAM do operacji kluczowych, separacji ról wydawca/acquirer ani procesu reagowania na kompromitację klucza. Te elementy QPA oceni u Ciebie – i to o nie najczęściej rozbijają się pierwsze oceny środowisk chmurowych.

Jak działa Azure Payment HSM i czym różni się model odpowiedzialności?

Azure Payment HSM to usługa bare-metal: klient otrzymuje dedykowane, jednodostępowe moduły Thales payShield 10K podpięte bezpośrednio do jego sieci wirtualnej, z wyłączną kontrolą administracyjną po swojej stronie. Microsoft utrzymuje infrastrukturę i centra danych, ale nie ma dostępu do urządzeń ani danych klienta.

Charakterystyka według Microsoft Azure Blog i dokumentacji Microsoft Learn:

moduły payShield 10K certyfikowane do FIPS 140-2 poziom 3 i PCI HSM v3, prowizjonowane parami pod wysoką dostępność,
zdalna administracja przez payShield Manager (karty inteligentne, zdalne ceremonie) – klient zarządza kluczami LMK, konfiguracją i firmware jak we własnej serwerowni,
usługa certyfikowana w zakresie PCI PIN, PCI DSS i PCI 3DS; klient korzysta z macierzy podziału odpowiedzialności z AOC Azure,
pełna kompatybilność z istniejącym oprogramowaniem hostowym payShield – migracja z on-premises często nie wymaga zmian w warstwie komend.

Model odpowiedzialności jest lustrzanym odbiciem AWS: Microsoft pokrywa fizyczne bezpieczeństwo, zasilanie i sieć centrum danych, natomiast operacje zarządzania kluczami – ceremonie, kustosze, komponenty LMK, polityki, rotacje – pozostają w całości po stronie klienta. To atut dla organizacji z dojrzałym zespołem kryptooperacyjnym i istniejącymi procedurami; dla firmy budującej kompetencje od zera oznacza, że wraz z HSM „kupuje” także cały rozdział 6 wymogów PCI PIN do samodzielnego spełnienia.

Wybór między zarządzanym API a dedykowanym payShield w chmurze to w istocie wybór, kto prowadzi ceremonie kluczy: dostawca w ramach swojej atestacji czy Twój zespół kustoszy w ramach Twojej oceny QPA.

Wybrałeś model (zarządzane API albo dedykowany HSM) i chcesz sprawdzić, czy architektura obroni się przed QPA?

Patronusec wykonuje review architektury PIN w chmurze: mapujemy wszystkie wymogi PCI PIN na strony odpowiedzialności (dostawca / Twoja organizacja / wspólne) i wskazujemy brakujące kontrole. W ciągu 10 dni roboczych otrzymujesz pisemną macierz odpowiedzialności i listę luk do zamknięcia przed oceną.

Zamów review architektury PIN

Co oferuje Google Cloud dla przetwarzania numeru PIN?

Google Cloud nie posiada natywnej usługi płatniczego HSM – Cloud HSM to moduły ogólnego przeznaczenia (FIPS 140-2 poziom 3) bez funkcji płatniczych takich jak translacja bloków PIN czy zarządzanie kluczami strefowymi. Procesowanie PIN w architekturze opartej o GCP wymaga płatniczego HSM dostarczonego przez stronę trzecią.

Realne warianty dla organizacji związanych z GCP:

Płatniczy HSM jako usługa strony trzeciej. Thales oferuje payShield Cloud HSM – subskrypcyjną usługę zbudowaną na payShield 10K, hostowaną w centrach danych Thales zgodnych z wymogami PCI PIN i integrującą się z AWS, Azure i GCP (komunikat prasowy Thales). Aplikacja działa w GCP, a operacje PIN wykonuje zdalny payShield po łączu prywatnym.
Model hybrydowy. Warstwa aplikacyjna i dane w GCP, a płatnicze HSM we własnej serwerowni lub kolokacji, połączone przez Interconnect/VPN. To najczęstsza konfiguracja przejściowa przy migracjach.
Architektura multi-cloud. Operacje PIN delegowane do AWS Payment Cryptography lub Azure Payment HSM wywoływanych z aplikacji w GCP – technicznie wykonalne, ale dokłada opóźnienia między chmurami i drugiego dostawcę do oceny.

Konsekwencja dla zgodności: w każdym z wariantów rośnie liczba podmiotów w łańcuchu odpowiedzialności (GCP za infrastrukturę aplikacyjną, dostawca HSM za operacje płatnicze, operator łącza za transmisję), a QPA oceni styk każdego z nich. Brak natywnej usługi nie dyskwalifikuje GCP – podnosi natomiast koszt architektury i dokumentacji względem scenariuszy jednochmurowych.

Jak porównać trzy podejścia w praktyce?

Trzy platformy reprezentują trzy różne modele operacyjne: zarządzane API (AWS), dedykowany sprzęt w chmurze (Azure) i integrację z HSM strony trzeciej (GCP). Porównanie ma sens dopiero na poziomie modelu odpowiedzialności, kompatybilności i dowodów zgodności – nie samych funkcji kryptograficznych.

Kryterium	AWS Payment Cryptography	Azure Payment HSM	Google Cloud + HSM strony trzeciej
Model usługi	W pełni zarządzane API (serverless)	Bare-metal, dedykowany payShield 10K w parze HA	Aplikacja w GCP + płatniczy HSM u strony trzeciej
Certyfikacja sprzętu	HSM zarządzane przez AWS, certyfikowane PCI PTS HSM	FIPS 140-2 poziom 3, PCI HSM v3	Zależnie od dostawcy (payShield Cloud HSM: payShield 10K)
Dowody zgodności usługi	AOC PCI PIN + atestacje komponentów P2PE (DMCP, KMCP, KLCP), przewodnik odpowiedzialności w AWS Artifact	Certyfikacje PCI PIN, PCI DSS i PCI 3DS usługi; macierz odpowiedzialności z AOC Azure	AOC dostawcy HSM + odpowiedzialność GCP za warstwę aplikacyjną (osobno)
Zarządzanie kluczami i ceremonie	Po stronie AWS (w zakresie atestacji usługi); klient zarządza politykami i dostępem	W całości po stronie klienta (LMK, kustosze, payShield Manager)	Zależnie od umowy z dostawcą HSM
Kompatybilność z legacy hostem payShield	Wymaga przepisania integracji na API AWS	Natywna – te same komendy hostowe	Natywna przy payShield Cloud HSM
Status w rejestrze Visa	ESO + PIN-Acquiring TPS (Visa Global Service Provider Registry)	Klient rejestruje własną usługę zgodnie ze swoją rolą	Zależnie od dostawcy HSM
Model rozliczeń	Za użycie (klucze i wywołania API)	Subskrypcja za dedykowane urządzenia	Subskrypcja u strony trzeciej + koszty GCP i łączy
Najlepiej pasuje do	Nowe platformy budowane cloud-native, minimalizacja operacji HSM	Migracja istniejącego switcha payShield, pełna kontrola nad kluczami	Organizacje strategicznie związane z GCP

Patronusec Insight: W projektach migracyjnych najczęściej rozstrzygający okazuje się jeden techniczny szczegół: format komend hostowych. Organizacja z dekadą logiki zbudowanej na komendach payShield wybiera zwykle Azure lub payShield Cloud HSM, bo przepisanie switcha na nowe API to projekt liczony w latach, nie miesiącach. Organizacja budująca od zera nie ma tego balastu i częściej wybiera zarządzane API, przenosząc na dostawcę cały rozdział operacji HSM. Rekomendujemy zaczynać analizę nie od cennika, lecz od inwentaryzacji zależności od komend hostowych.

Na co musi zwrócić uwagę firma planująca procesowanie PIN w chmurze?

Osiem pytań poniżej odpowiada perspektywie asesora QPA – to one wyznaczają, czy architektura obroni się w ocenie. Checklist warto przejść przed podpisaniem umowy z dostawcą, bo część odpowiedzi determinuje wybór platformy, a nie tylko konfigurację.

Checklist audytora – PIN w chmurze:

Czy dostawca posiada aktualną atestację AOC PCI PIN obejmującą dokładnie te usługi i regiony, których planujesz użyć?
Czy istnieje przewodnik podziału odpowiedzialności i czy każda pozycja wymogów PCI PIN ma jednoznacznego właściciela (dostawca / klient / wspólnie)?
Kto pełni role kustoszy kluczy i jak wyglądają ceremonie – zdalne (karty payShield Manager), po stronie dostawcy w ramach jego atestacji, czy hybrydowo?
Czy wymiana kluczy odbywa się wyłącznie w key blocks (TR-31, TR-34) i czy platforma wspiera AES oraz format ISO 4 bloku PIN na kierunku migracji z TDEA?
Jak wygląda droga sieciowa do organizacji płatniczych i acquirerów – łącza prywatne, opóźnienia, redundancja – i kto odpowiada za jej zgodność?
Czy rezydencja danych i lokalizacja HSM spełniają wymogi regulacyjne Twojej jurysdykcji (w UE m.in. oczekiwania nadzorcze wobec outsourcingu, w tym DORA dla podmiotów finansowych)?
Jaka jest strategia wyjścia: czy klucze da się wyeksportować w key blocks do innego środowiska, czy trzeba planować ponowną generację i wymianę z partnerami?
Czy logi operacji HSM i zdarzeń kluczowych są dostępne dla Twojego zespołu i wystarczające jako dowód w ocenie QPA?

Organizacjom podlegającym jednocześnie wymogom sektorowym pomagamy spiąć te odpowiedzi z szerszym programem zgodności – od certyfikacji PCI DSS środowiska aplikacyjnego po wymogi DORA dla instytucji finansowych outsourcujących funkcje krytyczne.

Planujesz migrację przetwarzania PIN do chmury i nie wiesz, od czego zacząć?

Patronusec prowadzi scope-assessment migracji PIN: w 30-minutowej bezpłatnej rozmowie klasyfikujemy Twoją rolę (procesor, ESO, TPS), przechodzimy 8 pytań kontrolnych dla wybranej platformy i wskazujemy wymogi PCI PIN pozostające po Twojej stronie. Po rozmowie otrzymujesz pisemne podsumowanie z rekomendowaną ścieżką.

Umów bezpłatny scope-assessment

FAQ

Czy QPA zaakceptuje atestację AOC dostawcy chmury?

Tak, to ugruntowany model: QPA klienta powołuje się na AOC dostawcy dla wymogów, które ten pokrywa, analogicznie jak w ocenach PCI DSS. Dokumentacja AWS opisuje tę praktykę wprost, a dodatkowo status ESO/TPS w rejestrze Visa formalizuje korzystanie z usługi przez uczestników programu.

Czym różni się AWS Payment Cryptography od AWS CloudHSM?

Payment Cryptography to zarządzana usługa płatnicza z funkcjami PIN (translacja, PVV, DUKPT, TR-31/TR-34) na modułach z certyfikacją PCI PTS HSM. CloudHSM to moduły ogólnego przeznaczenia bez komend płatniczych – AWS sam rekomenduje Payment Cryptography do operacji takich jak translacja PIN.

Czy na Google Cloud da się zbudować zgodne przetwarzanie PIN?

Tak, ale z płatniczym HSM strony trzeciej: usługą typu payShield Cloud HSM (Thales), HSM w kolokacji połączonym przez Interconnect albo wywołaniami do płatniczej usługi w innej chmurze. Google Cloud HSM nie oferuje funkcji płatniczych, więc samodzielnie nie wystarczy do translacji PIN.

Kto prowadzi ceremonie kluczy w Azure Payment HSM?

Klient – moduły payShield 10K pozostają pod jego wyłączną kontrolą administracyjną, a ceremonie prowadzi się zdalnie przez payShield Manager z użyciem kart inteligentnych. Microsoft nie ma dostępu do urządzeń ani materiału kluczowego. Wymogi kustoszy, podwójnej kontroli i dokumentacji ceremonii pozostają w całości po stronie klienta.

Czy migracja PIN do chmury wymaga nowej oceny QPA?

Tak. Przeniesienie ośrodka przetwarzania i istotna zmiana środowiska (nowe HSM, nowy model operacyjny) to klasyczne przesłanki ponownej oceny, wskazywane m.in. w dokumentacji programowej Visa. Migrację warto zaplanować tak, aby ocena QPA zamykała projekt, a nie odkrywała jego braki.

Ile kosztuje wsparcie Patronusec przy migracji PIN do chmury?

Cena zależy od roli organizacji (procesor, ESO, TPS), wybranej platformy i tego, czy budujemy macierz odpowiedzialności od zera, czy weryfikujemy istniejącą architekturę. Po bezpłatnej rozmowie scope-assessment przedstawiamy stałą wycenę obejmującą review architektury, analizę luk i przygotowanie do oceny QPA.

Jak rozpocząć współpracę z Patronusec w tym obszarze?

Pierwszym krokiem jest bezpłatna 30-minutowa rozmowa scope-assessment: klasyfikujemy rolę, platformę i stan przygotowań, a następnie proponujemy ścieżkę – od macierzy odpowiedzialności, przez analizę luk, po asystę przy ocenie. Formularz kontaktowy znajdziesz na stronie usługi PCI PIN Security.

Warto przeczytać

Ścieżka lektury dla tematu PIN i kluczy w chmurze:

PCI PIN Security – dla kogo jest standard – fundament: role, cele kontrolne i harmonogram wymogów.
Zarządzanie kluczami zgodne z PCI PIN Security – top 5 zasad i top 5 błędów – operacje, które w chmurze dzielisz z dostawcą.
Komponent P2PE, rozwiązanie P2PE i aplikacja P2PE – jak atestacje komponentów (DMCP, KMCP, KLCP) działają w praktyce.
Jak zastosować standard PCI DSS do środowiska używającego technologii konteneryzacji – warstwa aplikacyjna tej samej migracji.

Procesowanie PIN w chmurze – bezpłatna konsultacja

Patronusec jako akredytowany QSA łączy kompetencje audytora PCI z doświadczeniem projektowym w środowiskach chmurowych – pracujemy z klientami z sektorów fintech, e-commerce i finansowego. W bezpłatnej 30-minutowej konsultacji pomożemy Ci:

sklasyfikować rolę Twojej organizacji względem PCI PIN (procesor, ESO, TPS) i wynikający z niej zakres oceny,
porównać modele AWS, Azure i GCP względem Twoich zależności technicznych (komendy hostowe, opóźnienia, regiony),
zbudować macierz podziału odpowiedzialności dostawca/klient dla wybranej platformy,
zaplanować ścieżkę do oceny QPA wraz z realistycznym harmonogramem migracji.

Umów konsultację | PCI PIN Security | Analiza luk PCI | Certyfikacja PCI DSS | DORA

Blog space

Procesowanie numeru PIN w chmurze – porównanie AWS, Azure i Google Cloud oraz 8 pytań przed decyzją

W tym artykule znajdziesz: