Limitazione dell'ambito di conformità per gli ambienti PCI in Google Cloud

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento descrive le best practice per progettare l'architettura dell'ambiente cloud per la conformità al Payment Card Industry (PCI) Security Standards Council. Queste best practice sono utili per le organizzazioni che eseguono la migrazione o progettano sistemi nel cloud soggetti ai requisiti di conformità PCI. Questo documento fa riferimento ai requisiti PCI DSS 4.0, ove applicabili.

Informazioni sull'ambito della valutazione PCI DSS

Se la tua organizzazione si occupa di commercio su internet, devi supportare e mantenere la conformità PCI. Il modo in cui progetti e gestisci il tuo ambiente cloud influisce sull'ambito dei tuoi sistemi per la valutazione del PCI Data Security Standard (DSS). L'ambito ha implicazioni importanti per la sicurezza delle risorse IT e per la tua capacità di supportare e mantenere la conformità PCI. Per assicurarti che il tuo ambiente PCI sia definito correttamente, devi capire in che modo i tuoi processi aziendali e le tue decisioni di progettazione influiscono sull'ambito.

Che cos'è l'ambito?

Tutti i sistemi che archiviano, elaborano o trasmettono i dati dei titolari di carte (CHD) rientrano nell'ambito della valutazione PCI DSS. La sicurezza è importante per l'intero ambiente cloud, ma la compromissione dei sistemi inclusi nell'ambito può causare una violazione dei dati e l'esposizione di dati sanitari sensibili.

Nella figura 1, l'ambiente dei dati dei titolari della carta (CDE), i sistemi collegati e i sistemi che influiscono sulla sicurezza si trovano all'interno del confine dell'ambito della valutazione, mentre i sistemi non attendibili e non inclusi nell'ambito si trovano al di fuori del confine dell'ambito della valutazione.

Secondo PCI DSS, i sistemi inclusi nell'ambito sono attendibili. I sistemi inclusi nell'ambito includono la tua CDE e qualsiasi sistema connesso o che potrebbe influire sulla sicurezza della tua CDE.

Un sistema è collegato se si trova sulla stessa rete, condivide database o archiviazione di file o ha accesso o connettività a qualsiasi sistema o processo che risiede all'interno del CDE, ma non ha accesso diretto al CHD.

Un sistema ha impatto sulla sicurezza se, in caso di compromissione, può consentire a un malintenzionato di accedere al CDE. Tutti i sistemi collegati e che influiscono sulla sicurezza rientrano sempre nell'ambito.

I sistemi non inclusi nell'ambito sono non attendibili per definizione nei PCI DSS e non hanno alcun valore per un malintenzionato che vuole ottenere l'accesso a CHD o a dati di autenticazione sensibili (SAD). Un sistema è fuori ambito se non può influire sulla sicurezza di un sistema ambito, anche se il sistema fuori ambito è compromesso. Anche se i sistemi non inclusi nell'ambito non vengono valutati direttamente, il Qualified Security Assessor (QSA) PCI verifica che l'ambito sia accurato e protegga i dati sensibili relativi alla salute in base ai PCI DSS. È quindi importante che i confini dell'ambito siano fortemente protetti, monitorati continuamente e in modo approfondito e documentati chiaramente.

Connessioni nel contesto PCI

Diversi requisiti PCI DSS fanno riferimento alle connessioni, ma il PCI DSS non le definisce esplicitamente. Per interpretare il significato delle connessioni in questo contesto, è necessario comprendere la struttura ad albero decisionale per l'ambito riportata nella PCI SSC Guidance for PCI DSS scoping and network segmentation (PDF).

Ai fini della valutazione dell'ambito PCI, una connessione è definita da quanto segue:

• Un trasferimento attivo di informazioni che collega due computer o sistemi
• Quale delle due parti avvia la chiamata

Quando documenti il tuo ambiente, è meglio indicare chiaramente la parte autorizzata a avviare una connessione. Un firewall configurato per consentire solo il traffico in una direzione può applicare una connessione unidirezionale. Ad esempio, un'applicazione di elaborazione dei pagamenti in ambito può eseguire query su un server di database fuori ambito senza che il server fuori ambito entri nell'ambito se si verificano tutte le condizioni seguenti:

• La connessione e il database fuori ambito non archiviano, elaborano o trasmettono CHD o SAD.
• Il database si trova su una rete separata o è comunque separato dal CDE.
• Il database non può avviare chiamate al CDE direttamente o indirettamente.
• Il database non fornisce servizi di sicurezza al CDE.
• Il database non influisce sulla configurazione o sulla sicurezza del CDE.
• Il database supporta i requisiti PCI DSS.

Il seguente diagramma mostra i fattori che determinano l'ambito del sistema:

Nella figura 2, l'ambito del sistema è determinato come segue:

• Componenti di sistema che rientrano nell'ambito di PCI DSS:

  • Sistemi che si trovano nel CDE per i quali è vera una delle seguenti condizioni:
    • Un componente di sistema memorizza, elabora o trasmette CHD o SAD.
    • Un componente di sistema si trova nello stesso segmento di rete, ad esempio nella stessa subnet o VLAN, dei sistemi che archiviano, elaborano o trasmettono i dati sanitari sensibili.
  • Sistemi connessi o che influiscono sulla sicurezza per i quali è vera una delle seguenti condizioni:
    • Un componente di sistema si connette direttamente al CDE.
    • Un componente di sistema influisce sulla configurazione o sulla sicurezza del CDE.
    • Un componente di sistema segmenta i sistemi CDE dai sistemi e dalle reti non coperti.
    • Un componente di sistema si connette indirettamente al CDE.
    • Un componente di sistema fornisce servizi di sicurezza al CDE.
    • Un componente di sistema supporta i requisiti PCI DSS.

• I componenti di sistema possono essere considerati non attendibili e non coperti dal PCI DSS quando tutti i punti seguenti sono veri:

  • Un componente di sistema non memorizza, elabora o trasmette CHD o SAD.
  • Un componente di sistema non è lo stesso segmento di rete, ad esempio nella stessa subnet o VLAN, dei sistemi che archiviano, elaborano o trasmettono CHD o SAD.
  • Un componente di sistema non riesce a connettersi a nessun sistema nel CDE.
  • Un componente di sistema non soddisfa nessuno dei criteri per i sistemi collegati o che influiscono sulla sicurezza.

  I sistemi non inclusi nell'ambito possono includere sistemi che si connettono a un componente di sistema collegato o che influisce sulla sicurezza, in cui sono presenti controlli per impedire al sistema non incluso nell'ambito di accedere al CDE utilizzando il componente di sistema incluso nell'ambito.

In termini pratici, la definizione di ambito di sistema del PCI DSS può significare che il database di e-commerce e l'area di archiviazione delle sessioni dell'applicazione web potrebbero essere considerati al di fuori dell'ambito se la segmentazione è implementata e documentata correttamente. Il seguente diagramma mostra il funzionamento delle connessioni di lettura e scrittura tra i sistemi in ambito e quelli fuori ambito:

La Figura 3 mostra le seguenti connessioni:

• Di sola lettura:
  • Un'applicazione di elaborazione dei pagamenti in ambito legge un ID carrello da un database di carrelli fuori ambito e legge i dati da un DNS e da un NTP.
• Solo scrittura:
  • Un'applicazione di elaborazione dei pagamenti in ambito scrive in un database principale dell'applicazione fuori ambito e in Cloud Logging.
  • L'applicazione web principale fuori ambito scrive i dati in un servizio di registrazione. Questi dati non includono malattie cardiache o disturbi affettivi stagionali.
• Lettura e scrittura:
  • Un utente sul web pubblico legge e scrive i metadati della richiesta come segue:
    • L'utente legge e scrive in un'applicazione di elaborazione dei pagamenti in ambito. Questi metadati della richiesta sono l'ID carrello e la chiave di autenticazione del carrello che contengono CHD e SAD.
    • L'utente legge e scrive nell'applicazione web principale non inclusa nell'ambito. Questi metadati della richiesta sono un ID sessione che non contiene CHD o SAD.
  • L'applicazione web principale fuori ambito legge e scrive dati in un database del carrello, in un archivio sessioni e nel database principale dell'applicazione fuori ambito. Questi dati non includono malattie cardiache o disturbi affettivi stagionali.
  • Un'applicazione di elaborazione dei pagamenti in ambito legge e scrive i dati in un servizio di tokenizzazione delle carte in ambito e in un elaboratore di carte di credito sul web pubblico. Questi dati includono le malattie coronariche e la depressione stagionale.

L'architettura in figura 3 descrive due applicazioni web distinte: l'applicazione web principale (applicazione principale), che non rientra nell'ambito del PCI, e l'applicazione di elaborazione dei pagamenti (applicazione di pagamento), che rientra nell'ambito. In questa architettura, è possibile avviare una connessione tra due entità solo nelle direzioni descritte dall'elenco precedente. Le connessioni tra entità possono essere di sola lettura, di lettura e scrittura o di sola scrittura dal punto di vista dell'utente chiamante. Qualsiasi percorso o direzione della richiesta non descritto esplicitamente viene bloccato dalla segmentazione. Ad esempio, l'applicazione di elaborazione dei pagamenti può leggere dal database del carrello e scrivere nel servizio di registrazione, il che comporta l'avvio di una connessione a queste entità.

I sistemi inclusi nell'ambito chiamano comunemente sistemi e servizi non inclusi nell'ambito. Queste collegamenti rimangono sicuri perché la segmentazione impedisce a qualsiasi chiamante remoto (diverso da un titolare della carta) di avviare una connessione al CDE direttamente o indirettamente. La Figura 3 mostra che l'unico percorso di accesso all'applicazione di pagamento proviene dall'utente.

Nella figura 3, nessun servizio o applicazione fuori ambito fornisce dati di configurazione o sicurezza all'applicazione di elaborazione dei pagamenti. I dati fluiscono nell'architettura come segue:

1. L'applicazione principale inoltra l'utente all'applicazione di pagamento e utilizza un POST HTTP per trasmettere il CartID e un validatore chiamato CartAuthKey. CartAuthKey è un hash di CartID e una secret pre-condivisa nota solo alle applicazioni principali e di pagamento.
2. L'applicazione di pagamento convalida l'utente sottoponendo ad hashing il CartID insieme al segreto e confrontando il valore con il CartAuthKey.
3. Dopo l'autenticazione dei dati utente, CartID viene utilizzato per leggere i contenuti del carrello dal database del carrello. Tutti i dati del titolare della carta vengono inviati dall'utente direttamente all'applicazione di pagamento.
4. Se vengono utilizzati profili pagamenti, i dati del titolare della carta vengono memorizzati nel servizio di tokenizzazione.
5. Dopo l'elaborazione del pagamento, il risultato viene inserito nel database dell'applicazione principale con un account di servizio database di sola scrittura.

Considerazioni relative all'ambito

Nelle linee guida per l'ambito e la segmentazione della rete PCI DSS, il PCI Security Standards Council (SSC) consiglia di presumere che tutto rientri nell'ambito, fino a prova contraria. Questo consiglio del Centro assistenza sui prodotti non significa che devi ampliare l'ambito il più possibile. Significa piuttosto che il QSA valuta tutti i sistemi come se fossero attendibili, a meno che tu non possa dimostrare che un sistema non ha connettività con il tuo CDE o non ha impatto sulla sicurezza. Per soddisfare i requisiti di conformità normativa e mantenere al sicuro le risorse IT, devi definire l'ambito del tuo ambiente in linea con il principio del privilegio minimo fidandoti del minor numero possibile di sistemi.

Prima della valutazione, valuta il tuo ambiente per comprendere e documentare il confine tra i sistemi inclusi e non inclusi nell'ambito. Il primo compito dell'QSA è verificare che l'ambito documentato inglobi ragionevolmente il CDE e i sistemi collegati. Nell'ambito della valutazione complessiva, l'ASQ verifica quindi che i sistemi non inclusi nell'ambito non possano influire negativamente su quelli inclusi nell'ambito.

Assicurati di conoscere eventuali circostanze speciali specifiche del tuo ambiente, ad esempio:

• Se raccogli i dati del titolare della carta per telefono o tramite un sistema VoIP, tieni conto dei problemi di ambito aggiuntivi descritti in Protezione dei dati delle carte di pagamento basate su telefono (PDF).
• Se il tuo fornitore di servizi richiede l'accesso al tuo CDE (PDF) per gestire un sistema POS, il sistema utilizzato dal fornitore di servizi potrebbe essere considerato un sistema collegato. Ciò potrebbe richiedere ulteriori considerazioni di ambito e due diligence.

Le best practice di sicurezza di Google possono aiutarti a stabilire e dimostrare un confine chiaro e difendibile tra i sistemi inclusi nell'ambito e quelli non attendibili, che ti aiuteranno nella valutazione. Quando gestisci l'accesso e la sicurezza adottando il principio del privilegio minimo, contribuisci a ridurre al minimo il numero di punti di esposizione per i dati dei titolari della carta, la superficie di attacco del tuo CDE e, di conseguenza, il tuo ambito. Se riduci l'impronta dei sistemi inclusi nell'ambito, contribuisci a ridurre la complessità del sistema e snellire la valutazione PCI DSS.

Rischi di un ambito errato

Un ambito eccessivamente ampio può comportare valutazioni costose e maggiori rischi di conformità. Per mantenere un ambito ristretto, attendi il minor numero possibile di sistemi e concedi l'accesso solo a pochi utenti designati. Attraverso valutazioni e autovalutazioni scrupolose, puoi identificare i sistemi che non rientrano nell'ambito del PCI DSS, verificare che soddisfino le linee guida per i sistemi non inclusi nell'ambito e ridurre di conseguenza l'ambito. Questo processo di eliminazione è il modo più sicuro per scoprire quali sistemi non sono attendibili e contribuire ad assicurarsi che non possano influire sui sistemi inclusi nell'ambito.

Se hai bisogno di un'impronta di infrastruttura di grandi dimensioni per soddisfare i requisiti PCI DSS, puoi causare l'inclusione di sistemi estranei nell'ambito della valutazione. Se includi sistemi estranei nell'ambito, rischi di non riuscire a garantire la conformità. Inoltre, può peggiorare la tua postura di sicurezza complessiva ampliando la superficie di attacco del tuo ambiente attendibile ambito.

Un principio fondamentale della sicurezza di rete e dei PCI DSS è assumere che parte o tutta la rete sia già stata compromessa. Questo principio è sancito nel modello di sicurezza Zero Trust di Google, che rifiuta la sicurezza solo per il perimetro a favore di un modello in cui ogni sistema è responsabile della propria sicurezza. Il modello di sicurezza di Google è in linea con il PCI DSS, che consiglia di implementare il CDE e i relativi sistemi collegati in un piccolo spazio attendibile separato dall'ambiente IT più ampio e non mescolati con esso.

Nell'ambiente PCI ambito, non posizionare il CDE in uno spazio grande e attendibile con un perimetro ampio. Ciò può creare un falso senso di sicurezza e mettere in discussione una strategia di difesa in profondità olistica. Se un utente malintenzionato viola la sicurezza del perimetro, può operare facilmente all'interno di un'intranet privata attendibile. Valuta i modi in cui puoi rafforzare lo spazio attendibile in modo che contenga solo ciò che è necessario per il suo funzionamento e la sua protezione ed evita di fare affidamento esclusivamente sulla sicurezza perimetrale. Comprendendo e seguendo questi principi, puoi progettare il tuo ambiente cloud per proteggere i tuoi sistemi critici e ridurre il rischio di contaminazione da sistemi compromessi.

Un ambiente di sistemi attendibili di grandi dimensioni e in ambito richiede un apparato di gestione altrettanto grande per mantenere il monitoraggio, la manutenzione, il controllo e l'inventario continui di questi sistemi. La complessità dell'architettura di sistema, delle procedure di gestione del cambiamento e dei criteri di controllo dell'accesso può creare rischi per la sicurezza e la conformità. La difficoltà di gestire queste procedure di monitoraggio può portare a difficoltà nel soddisfare i requisiti PCI DSS 10 e 11. È importante comprendere questi rischi e implementare strategie per limitare l'ambito dell'ambiente valutato. Per ulteriori informazioni, consulta la sezione Supportare la conformità continua più avanti in questo documento.

Google Cloud servizi che rientrano nell'ambito di PCI DSS

Prima di iniziare a ridurre l'ambito del tuo ambiente PCI, scopri quali Google Cloud servizi rientrano nell'ambito di PCI DSS. Questi servizi forniscono l'infrastruttura su cui puoi creare un tuo servizio o un'applicazione che archivi, elabori o trasmetta i dati dei titolari di carte.

Strategie per ridurre l'ambito

Questa sezione illustra le seguenti strategie per ridurre l'ambito della valutazione: controlli della gerarchia delle risorse, segmentazione e tokenizzazione di Controlli di servizio VPC. Anziché scegliere un approccio, valuta la possibilità di impiegare tutte queste strategie per massimizzare la potenziale riduzione dell'ambito.

Non esiste una soluzione universale per l'ambito PCI. Potresti avere già implementato una segmentazione in una rete on-premise o una soluzione di elaborazione delle carte che può far sì che il design dell'infrastruttura sia leggermente diverso da quello descritto qui. Utilizza queste strategie come principi che puoi applicare al tuo proprio ambiente.

Stabilire i controlli della gerarchia delle risorse

Le risorseGoogle Cloud sono organizzate in modo gerarchico come segue:

• La risorsa Organizzazione è il nodo radice della gerarchia delle risorse. Google Cloud Le risorse dell'organizzazione contengono risorse di cartelle e progetti. I criteri di controllo dell'accesso degli accessi Identity and Access Management (IAM) applicati alla risorsa Organizzazione si applicano in tutta la gerarchia a tutte le risorse dell'organizzazione.
• Le cartelle possono contenere progetti e altre cartelle e controllare l'accesso alle relative risorse utilizzando le autorizzazioni IAM a livello di cartella. Le cartelle vengono spesso utilizzate per raggruppare progetti simili.
• I progetti rappresentano un confine di attendibilità per tutte le tue risorse e sono un punto di applicazione di IAM.

Per ridurre l'ambito della valutazione, segui le best practice di Google per la definizione della gerarchia delle risorse. L'immagine seguente mostra un esempio di gerarchia delle risorse per la conformità PCI:

Nella figura 4, tutti i progetti che rientrano nell'ambito PCI sono raggruppati in un'unica cartella per essere isolati a livello di cartella. La cartella con ambito PCI contiene il CDE e un altro progetto che contiene servizi condivisi. Quando implementi una gerarchia di risorse simile, la cartella con ambito PCI costituisce la radice logica dell'ambito di conformità PCI. Assicurati che solo gli utenti designati abbiano accesso a questa cartella e ai relativi progetti, in modo da escludere altre cartelle, progetti e risorse nella gerarchia dall'ambito della valutazione.

Quando concedi agli utenti l'accesso solo alle cartelle e ai progetti di cui hanno bisogno, assicuri che solo gli utenti designati abbiano accesso ai componenti inclusi nell'ambito. Sono supportati i requisiti PCI DSS 7.2 e 7.3 (PDF) e altri. Per assicurarti che le autorizzazioni per l'organizzazione e le cartelle principali siano impostate correttamente, comprendi le implicazioni dell'ereditarietà dei criteri. Per supportare il Requisito 8.4.1 del PCI DSS, assicurati di applicare l'autenticazione a più fattori (MFA) per gli utenti designati e consulta il supplemento del PCI DSS sulle indicazioni per l'autenticazione a più fattori (PDF). Per applicare la conformità nella gerarchia delle risorse, assicurati di comprendere come impostare i vincoli dei criteri dell'organizzazione. Questi vincoli supportano la conformità continua e possono contribuire a proteggere i tuoi ambienti attendibili dall'escalation dei privilegi.

Come per tutta la conformità PCI, sono necessari un monitoraggio e un logging adeguati dell'ambiente e dei relativi componenti a livello di ambito per stabilire un confine dell'ambito chiaro. La gerarchia delle risorse è indissolubilmente legata alla gestione dell'identità e dell'accesso e sono necessari registri, controlli e monitoraggio efficaci delle azioni degli utenti per applicare e mantenere la separazione.

Implementa la segmentazione della rete

La segmentazione della rete è un pattern di architettura importante per proteggere il CDE e i sistemi connessi, come descritto dalla guida supplementare della PCI SSC sulla segmentazione della rete (PDF). Se implementata correttamente, la segmentazione della rete restringe l'ambito della valutazione rimuovendo i percorsi di rete che i sistemi non attendibili potrebbero utilizzare per accedere al tuo CDE o ai suoi componenti connessi. Definisci solo le route necessarie per consentire la comunicazione tra i componenti attendibili. Quando i sistemi non attendibili non hanno una route per inviare o ricevere pacchetti da sistemi attendibili, i sistemi non attendibili sono fuori ambito e non possono influire sulla sicurezza dei componenti in ambito.

Per implementare la segmentazione della rete, posiziona il tuo CDE in un Virtual Private Cloud (VPC) dedicato con i Controlli di servizio VPC abilitati. Crea questa VPC in modalità personalizzata per assicurarti che non vengano create subnet o route estranee che potrebbero attivare l'accesso predefinito alle reti attendibili. Implementa vincoli dei criteri dell'organizzazione per assicurarti che questa VPC non possa essere condivisa con altri progetti e possa essere in peering solo con altre reti attendibili.

Il seguente diagramma mostra la stretta correlazione tra la strategia di segmentazione della rete e la gerarchia delle risorse. Questo diagramma presuppone una gerarchia delle risorse con una singola cartella per l'ambiente PCI ambito e due progetti in quella cartella per il CDE e i servizi condivisi.

Nella figura 5, il progetto di servizi condivisi non fa parte del CDE, ma è un sistema collegato e pertanto rientra nell'ambito di PCI. L'accesso al CDE è limitato a livello di rete dal bilanciatore del carico e dalle regole firewall o dai criteri firewall per proteggere queste reti e soddisfare i requisiti PCI DSS 1.2 e 1.3. Il sistema di tokenizzazione e il sistema di pagamento sono posizionati in subnet separate e la loro comunicazione è regolata da regole firewall tra ciascuna subnet per consentire solo le comunicazioni necessarie. Le funzioni di logging, monitoraggio e avviso necessarie che soddisfano i requisiti PCI DSS 10.2, 10.4 e 10.5 si trovano in un progetto separato. I servizi condivisi e la CDE si trovano all'interno di un perimetro di sicurezza dei Controlli di servizio VPC per proteggersi da configurazioni errate accidentali o compromissione dei controlli di accesso IAM.

Se il tuo deployment è su Google Kubernetes Engine (GKE), di seguito sono riportati altri modi per segmentare il tuo CDE e proteggere i dati dei titolari di carte da sistemi non attendibili:

• Gli spazi dei nomi offrono un ulteriore livello di isolamento del controllo dell'accesso dell'accesso, in modo che agli utenti possa essere fornito accesso solo a determinati pod, servizi e deployment all'interno del tuo cluster Kubernetes. Questo è utile per fornire un accesso più granulare agli utenti designati.
• I criteri di rete possono isolare i pod e i servizi tra loro per limitare i flussi di dati e possono fornire un ulteriore livello di segmentazione della rete all'interno del cluster.
• PodSecurity è un controller di ammissione Kubernetes che ti consente di applicare gli standard di sicurezza dei pod ai pod in esecuzione sul tuo cluster GKE.

Ciascuno di questi livelli costituisce una parte importante della tua strategia di sicurezza difensiva e ti aiuta a restringere l'ambito isolando e proteggendo ulteriormente i componenti attendibili dall'ambiente circostante. Se esegui il deployment di tutto o parte del tuo CDE con Kubernetes, scopri di più su come eseguire il tuo ambiente conforme a PCI su GKE.

Implementare la tokenizzazione

La tokenizzazione è il processo di oscuramento irreversibile di un numero di conto principale (PAN). Un PAN tokenizzato o token non può essere utilizzato per un PAN tramite metodi matematici. Il PCI SSC offre indicazioni sull'impatto dell'ambito della tokenizzazione nel Capitolo 3 del supplemento alle linee guida sulla tokenizzazione (PDF). L'ambito dei PCI DSS è fortemente influenzato dall'insieme di componenti che archiviano e trasmettono i dati dei titolari di carte. Se implementata correttamente, la tokenizzazione può contribuire a ridurre l'ambito della valutazione riducendo al minimo l'occorrenza e la trasmissione dei numeri di conto principali.

La tokenizzazione è anche una forma di segmentazione in base al flusso di dati, perché separa i sistemi che archiviano e trasmettono i dati dei titolari delle carte da quelli che possono eseguire operazioni utilizzando solo token. Ad esempio, i sistemi che analizzano l'attività dei consumatori per rilevare attività fraudolente potrebbero non aver bisogno dei PAN, ma possono eseguire queste analisi utilizzando dati tokenizzati. La tokenizzazione aggiunge anche un livello di separazione tra i sistemi che memorizzano e trasmettono i PAN e la tua applicazione web di e-commerce. Quando la tua applicazione web interagisce solo con sistemi che utilizzano token, può essere potenzialmente rimossa dall'insieme di sistemi collegati, riducendo così l'ambito.

Il seguente diagramma mostra come vengono gestiti i dati CHD, un PAN e i dati tokenizzati in un tipico sistema di tokenizzazione:

Nella figura 6, un PAN e altri dati del titolare della carta vengono ricevuti dall'utente, quindi vengono inviati immediatamente al servizio di tokenizzazione. Il servizio di tokenizzazione cripta il PAN, genera un token e poi li memorizza entrambi in una cassetta di sicurezza per i token sicura. Solo i servizi designati, come il servizio di regolamento, possono accedere alla cassetta di sicurezza sulla rete e sono autorizzati a utilizzare un token generato per riscattare un PAN. Il servizio di regolamento utilizza il PAN solo per inviarlo all'elaboratore dei pagamenti. Né il PAN né altri dati del titolare della carta vengono mai visualizzati al di fuori di questo flusso di dati strettamente controllato. Nell'ambito di una strategia di difesa in profondità, l'architettura utilizza anche Sensitive Data Protection come un altro livello di difesa contro la fuga involontaria di PAN o altri dati del titolare della carta.

Nella figura 6, il sistema di tokenizzazione utilizza Hashicorp Vault, un archivio segreto strettamente sorvegliato, per gestire le mappature PAN-to-token. Solo gli utenti e i servizi autorizzati possono utilizzare un token per riscattare un PAN tramite una procedura di ricerca. Ai componenti autorizzati ad accedere alla cassetta dei token può essere concesso un accesso con limitazioni di tempo, in modo che il componente possa utilizzare un PAN solo durante la finestra di tempo specifica necessaria per svolgere la sua funzione. Anche altri datastore possono essere appropriati, a seconda dei requisiti della tua attività.

Architettura di esempio

Il seguente diagramma mostra un'architettura di esempio per l'elaborazione delle transazioni tokenizzate utilizzando Pub/Sub e Dataflow, nonché per l'archiviazione dei record delle transazioni tokenizzate in Spanner.

Nella figura 7, il progetto di elaborazione delle transazioni è un sistema collegato ed rientra nell'ambito del PCI. Non ha impatto sulla sicurezza, perché la compromissione di qualsiasi componente del progetto di elaborazione delle transazioni non può fornire a un malintenzionato l'accesso ai dati CHD. Il progetto della web app non rientra nell'ambito perché non si connette al CDE e interagisce solo con dati sottoposti a convalida come corretti.

I dati tokenizzati vengono inviati dall'CDE a Pub/Sub. Prima che i dati tokenizzati vengano pubblicati per altri abbonati, la funzionalità Protezione dei dati sensibili verifica che non contengano CHD. I dati tokenizzati vengono elaborati da Dataflow e archiviati nel database delle transazioni Spanner. Le transazioni possono essere associate a utenti specifici tramite token senza accedere ai PAN. Il database delle transazioni di Spanner può essere utilizzato anche per la generazione di report e l'analisi utilizzando strumenti di business intelligence (BI) come Looker.

Supportare la conformità continua

La sicurezza e la conformità sono più di un'architettura corretta e di una buona progettazione. Un'architettura corretta può dimostrare che il tuo ambiente è progettato in modo sicuro in teoria. Inoltre, sono necessari processi di controllo, registrazione, monitoraggio e correzione efficaci per contribuire a garantire che l'ambiente rimanga sicuro nella pratica.

Per supportare la conformità a ciascuna delle 12 categorie di requisiti PCI DSS, devi monitorare l'implementazione di quel requisito su base continuativa. Devi dimostrare a te stesso e al tuo valutatore che qualsiasi componente ambito rimarrà sicuro in futuro, molto tempo dopo il completamento della valutazione PCI DSS. La supervisione corretta abbinata a un'azione di correzione rapida è chiamata conformità continua. La conformità continua è un requisito del PCI DSS e, se implementata correttamente, può contribuire a massimizzare l'effetto delle altre strategie di riduzione dell'ambito.

Google Cloud ti consente di registrare tutto ciò che accade nella tua rete utilizzando il logging delle regole firewall, i log di flusso VPC, i log di VPC Service Controls e i log di Cloud Load Balancing. Puoi monitorare l'attività dei tuoi sistemi e utenti utilizzando Audit log di Cloud. Il monitoraggio regolare di questi log ti aiuta a rispettare il Requisito 10.4 del PCI DSS e ti consente di rispondere e correggere rapidamente potenziali minacce alla sicurezza. Per maggiori informazioni, consulta il supplemento PCI DSS sul monitoraggio giornaliero efficace dei log (PDF).

Security Command Center ti consente di comprendere la tua superficie di attacco per dati e sicurezza fornendo servizi di individuazione, ricerca, gestione e inventario degli asset. Security Command Center può analizzare i risultati della scansione di Sensitive Data Protection per aiutarti a identificare i dati dei titolari di carte trapelati e a verificare che il tuo sistema di tokenizzazione non venga utilizzato in modo improprio per riscattare in modo fraudolento i PAN. Con Event Threat Detection, Security Command Center può aiutarti a rilevare in modo proattivo minacce e attività insolite sulla tua rete e nelle tue VM, il che potrebbe indicare che un malintenzionato potrebbe eseguire sondaggi sul tuo sistema per identificare le sue capacità difensive. Security Command Center consente inoltre di creare origini di sicurezza personalizzate specifiche per il tuo ambiente.

Google Cloud Armor può fornire una protezione aggiuntiva per le tue applicazioni web Google Cloud rivolte al pubblico e aiutarti a rispettare il requisito 6.4 del PCI DSS. Google Cloud Armor esamina le richieste in arrivo per rilevare una serie di attacchi web comuni e può aiutarti a evitare le revisioni manuali del codice laboriose specificate nel requisito 6.4. L'implementazione di un WAF ti consente di mantenere la conformità in modo continuo, riducendo al contempo i costi e i rischi della conformità.

Passaggi successivi

• Consulta le best practice per la gestione degli obblighi di conformità.
• Leggi informazioni sulla conformità allo standard di sicurezza dei dati PCI su Google Cloud.
• Linee guida del PCI Council per l'ambito e la segmentazione della rete PCI DSS (PDF).
• Prova il blueprint PCI su GKE.
• Proteggi i tuoi workload Kubernetes per PCI DSS.
• Esegui il deployment del progetto Terraform PCI Starter.
• Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.