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

Last reviewed 2023-11-29 UTC

Questo documento descrive le best practice per la progettazione dell'ambiente cloud ai fini della conformità al Payment Card Industry (PCI) Security Standards Council. Queste best practice sono utili per le organizzazioni che stanno eseguendo la migrazione o la progettazione di sistemi nel cloud soggetti ai requisiti di conformità PCI. Ove applicabile, questo documento fa riferimento ai requisiti PCI DSS 4.0.

Comprensione dell'ambito della valutazione PCI DSS

Se la tua organizzazione opera in 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 sistemi per la valutazione del PCI Data Security Standard (DSS). La definizione dell'ambito ha importanti implicazioni per la sicurezza dei tuoi asset IT e per la tua capacità di supportare e mantenere la conformità PCI. Per garantire che l'ambito del tuo ambiente PCI sia corretto, devi comprendere in che modo i processi aziendali e le decisioni di progettazione influiscono sull'ambito.

Che cos'è l'ambito?

Tutti i sistemi che memorizzano, elaborano o trasmettono 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 in questione può causare una violazione dei dati e l'esposizione di CHD.

Figura 1. Diagramma della definizione dell'ambito PCI DSS.

Nella Figura 1, l'ambiente dei dati dei titolari delle carte (CDE), i sistemi connessi e i sistemi che influiscono sulla sicurezza si trovano all'interno del confine dell'ambito della valutazione, mentre i sistemi attendibili e fuori ambito non rientrano in quest'ultimo.

Secondo lo standard PCI DSS, i sistemi inclusi nell'ambito sono attendibili. I sistemi nell'ambito di applicazione includono il tuo CDE e qualsiasi sistema che sia collegato alla sicurezza del tuo CDE o potrebbe influire sulla sua sicurezza.

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

Un sistema ha un impatto sulla sicurezza se può, se compromesso, consentire a un utente malintenzionato di accedere al CDE. Rientrano nell'ambito tutti i sistemi connessi e che incidono sulla sicurezza.

I sistemi fuori ambito sono untrusted per definizione in PCI DSS e hanno un valore pari a zero per un utente malintenzionato che vuole accedere a dati CHD o di autenticazione sensibili (SAD). Un sistema è fuori ambito se non può influire sulla sicurezza di un sistema che rientra nell'ambito, anche se quest'ultimo è compromesso. Sebbene i sistemi fuori ambito non vengano valutati direttamente, il QSA (QSA) verifica che la definizione dell'ambito sia accurata e protegge il CHD secondo lo standard PCI DSS. Per questo motivo è importante che i confini degli ambiti siano protetti in modo rigoroso, monitorati costantemente e meticolosamente e che siano chiaramente documentati.

Connessioni nel contesto PCI

Diversi requisiti PCI DSS fanno riferimento alle connessioni, ma il modello PCI DSS non definisce le connessioni in modo esplicito. Puoi interpretare il significato delle connessioni in questo contesto comprendendo l'albero decisionale dell'ambito nella guida PCI SSC per la definizione dell'ambito e la segmentazione della rete PCI DSS (PDF).

Al fine di valutare l'ambito PCI, una connessione è definita da quanto segue:

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

Quando documenti il tuo ambiente, è meglio indicare chiaramente quale parte è autorizzata ad avviare una connessione. Un firewall configurato per consentire il traffico solo 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 tutte le seguenti condizioni sono vere:

• La connessione e il database fuori ambito non memorizzano, elaborano o trasmettono CHD o SAD.
• Il database si trova su una rete separata o è segmentato in altro modo dal CDE.
• Il database non può avviare chiamate direttamente o indirettamente a CDE.
• 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:

Figura 2. Diagramma di flusso per determinare 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 inclusi nella CDE per i quali è vera una delle seguenti condizioni:
    • Un componente del sistema archivia, elabora o trasmette CHD o SAD.
    • Un componente di sistema si trova sullo stesso segmento di rete, ad esempio nella stessa subnet o VLAN, dei sistemi che archiviano, elaborano o trasmettono CHD.
  • Sistemi collegati o sistemi che influiscono sulla sicurezza per i quali una delle seguenti condizioni è vera:
    • Un componente del sistema si connette direttamente a CDE.
    • Un componente del sistema influisce sulla configurazione o sulla sicurezza del CDE.
    • Un componente del sistema separa i sistemi CDE da reti e sistemi fuori ambito.
    • Un componente del sistema si connette indirettamente a CDE.
    • Un componente di sistema fornisce servizi di sicurezza al CDE.
    • Un componente di sistema supporta i requisiti PCI DSS.

• I componenti del sistema possono essere considerati non attendibili e fuori ambito per PCI DSS quando tutte le seguenti condizioni sono vere:

  • 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 può connettersi ad alcun sistema nel CDE.
  • Un componente del sistema non soddisfa alcun criterio per i sistemi connessi o che influiscono sulla sicurezza.

  I sistemi fuori ambito possono includere sistemi che si connettono a un componente del sistema connesso o che influisce sulla sicurezza, dove sono in atto dei controlli per impedire al sistema fuori ambito di ottenere l'accesso al CDE utilizzando il componente del sistema nell'ambito.

In termini pratici, la definizione PCI DSS dell'ambito del sistema può significare che il datastore delle sessioni e il database di e-commerce dell'applicazione web potrebbero essere considerati fuori ambito se la segmentazione è implementata e documentata correttamente. Il seguente diagramma mostra come funzionano le connessioni di lettura e scrittura tra i sistemi all'interno e i sistemi fuori ambito:

Figura 3. Applicazioni incluse nell'ambito in grado di richiamare servizi e applicazioni fuori dall'ambito.

La figura 3 mostra le seguenti connessioni:

• Sola lettura:
  • Un'applicazione di elaborazione dei pagamenti nell'ambito legge un ID carrello da un database di carrelli fuori dall'ambito e legge i dati da un DNS e una NTP.
• Solo scrittura:
  • Un'applicazione di elaborazione dei pagamenti nell'ambito scrive in un database principale dell'applicazione fuori ambito e in Cloud Logging.
  • L'applicazione web principale fuori ambito scrive dati in un servizio di logging. Questi dati non includono CHD o SAD.
• Lettura e scrittura:
  • Un utente sul web pubblico legge e scrive i metadati delle richieste come segue:
    • L'utente legge e scrive in un'applicazione di elaborazione dei pagamenti nell'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 fuori ambito. Questi metadati della richiesta sono un ID sessione che non contiene CHD o SAD.
  • L'applicazione web principale fuori ambito legge e scrive i dati in un database di carrelli, un archivio sessioni e un database principale delle applicazioni al di fuori dell'ambito. Questi dati non includono CHD o SAD.
  • Un'applicazione di elaborazione dei pagamenti nell'ambito legge e scrive i dati in un servizio di tokenizzazione delle carte incluso nell'ambito e a un elaboratore delle carte di credito sul web pubblico. Questi dati includono CHD e SAD.

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

I sistemi che rientrano nell'ambito richiamano comunemente sistemi e servizi fuori dall'ambito. Queste connessioni rimangono sicure perché la segmentazione impedisce a qualsiasi chiamante remoto (diverso dal titolare della carta) di avviare una connessione direttamente o indirettamente a CDE. La Figura 3 mostra che l'unico percorso in entrata per l'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 attraverso l'architettura come segue:

1. L'applicazione principale inoltra l'utente all'applicazione di pagamento e utilizza un POST HTTP per trasmettere CartID e uno strumento di convalida chiamato CartAuthKey. CartAuthKey è un hash di CartID e un segreto precondiviso noto solo alle applicazioni principali e di pagamento.
2. L'applicazione di pagamento convalida l'utente eseguendo l'hashing del CartID insieme al secret e confrontando questo valore con il CartAuthKey.
3. Dopo aver autenticato i 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 di pagamento, i dati del titolare della carta vengono memorizzati nel servizio di tokenizzazione.
5. Una volta elaborato il pagamento, il risultato viene inserito nel database dell'applicazione principale con un account di servizio del database di sola scrittura.

Considerazioni sull'ambito

Nelle Linee guida per la definizione dell'ambito e la segmentazione della rete PCI DSS, il PCI Security Standards Council (SSC) consiglia di dare per scontato che tutto rientri nell'ambito finché non viene verificato diversamente. Questo consiglio SSC non implica che tu debba rendere il tuo ambito il più ampio possibile. Piuttosto, significa che il QSA valuta tutti i sistemi come se fossero attendibili, a meno che tu non mostri che un sistema non ha connettività o impatto sulla sicurezza sul tuo CDE. Per soddisfare i requisiti di conformità normativa e proteggere le risorse IT, dovresti definire l'ambito del tuo ambiente in linea con il principio del privilegio minimo, affidandoti al minor numero di sistemi possibile.

Prima della valutazione, valuta il tuo ambiente per comprendere e documentare il confine tra i sistemi all'interno e all'esterno dell'ambito. La prima attività del QSA è verificare che l'ambito documentato includa ragionevolmente i sistemi CDE e collegati. Nell'ambito della valutazione complessiva, il QSA verifica quindi che i sistemi fuori ambito non possano influire negativamente su quelli esterni.

Assicurati di comprendere eventuali circostanze speciali specifiche per il tuo ambiente, ad esempio:

• Se raccogli i dati dei titolari della carta per telefono o tramite un sistema VoIP, valuta gli ulteriori problemi di ambito descritti nella sezione Protezione dei dati delle carte di pagamento telefoniche (PDF).
• Se il tuo fornitore di servizi richiede l'accesso al tuo CDE (PDF) per gestire un sistema point of sale, il sistema utilizzato dal fornitore di servizi potrebbe essere considerato un sistema connesso. Ciò potrebbe richiedere ulteriori considerazioni sull'ambito e sulla due diligence.

Le best practice per la sicurezza di Google possono aiutarti a stabilire e dimostrare un confine chiaro e difendibile tra i sistemi in ambito e quelli non attendibili, che ti aiuterà nella valutazione. Quando gestisci l'accesso e la sicurezza applicando il principio del privilegio minimo, contribuisci a ridurre al minimo il numero di punti di esposizione per i dati dei titolari di carte, minimizza la superficie di attacco del tuo CDE e, di conseguenza, riduci l'ambito di applicazione. Riducendo l'ingombro dei sistemi nell'ambito, puoi ridurre la complessità del sistema e semplificare la valutazione PCI DSS.

Rischi di errata definizione dell'ambito

Un ambito troppo ampio può comportare valutazioni costose e aumentare i rischi di conformità. Per limitare l'ambito, affidati al minor numero di sistemi possibile e concedi l'accesso solo a un numero ristretto di utenti designati. Attraverso una valutazione accurata e un'autovalutazione, puoi identificare i sistemi che non dovrebbero rientrare nell'ambito dello standard PCI DSS, verificare che soddisfino le linee guida per i sistemi fuori ambito e ridurre l'ambito di conseguenza. Questo processo di eliminazione è il modo più sicuro per scoprire quali sistemi non sono attendibili e contribuisce a garantire che non possano influire sui sistemi inclusi nell'ambito.

Se hai bisogno di un'infrastruttura di grandi dimensioni per soddisfare i requisiti di PCI DSS, puoi far sì che i sistemi estranei vengano inclusi nell'ambito della valutazione. L'inclusione di sistemi estranei nell'ambito comporta dei rischi per la capacità di raggiungere la conformità. Può anche peggiorare la tua strategia di sicurezza complessiva ampliando la superficie di attacco del tuo ambiente affidabile nell'ambito.

Un principio fondamentale della sicurezza di rete e dello standard PCI DSS è supporre che una 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 perimetrale in favore di un modello in cui ogni sistema è responsabile della sicurezza se stesso. Il modello di sicurezza di Google è in linea con PCI DSS, che consiglia di eseguire il deployment di CDE e dei suoi sistemi connessi in un piccolo spazio attendibile, segmentato dal più ampio ambiente IT e non mescolato a quest'ultimo.

All'interno dell'ambiente PCI in ambito, non collocare il CDE in un ampio spazio attendibile con un ampio perimetro. Questo può creare un falso senso di sicurezza e compromettere una strategia olistica di difesa in profondità. Se un utente malintenzionato viola la sicurezza del perimetro, può operare con facilità all'interno di una intranet privata e affidabile. Valuta dei modi in cui puoi restringere lo spazio attendibile in modo che contenga solo ciò di cui ha bisogno per funzionare e garantire la sicurezza ed evitare di fare affidamento esclusivamente sulla sicurezza del perimetro. Comprendere e seguire questi principi ti consente di progettare il tuo ambiente cloud per contribuire a proteggere i sistemi critici e ridurre il rischio di contaminazione da sistemi compromessi.

Un ambiente ampio e che include sistemi attendibili richiede apparato di gestione di dimensioni simili per mantenere monitoraggio, manutenzione, controllo e inventario continui di questi sistemi. La complessità dell'architettura di sistema, i processi di gestione delle modifiche e i criteri di controllo dell'accesso possono creare rischi per la sicurezza e la conformità. La difficoltà nel mantenere questi processi di monitoraggio può comportare 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 Supportare la conformità continua più avanti in questo documento.

Servizi Google Cloud nell'ambito di PCI DSS

Prima di iniziare a ridurre l'ambito del tuo ambiente PCI, scopri quali servizi Google Cloud rientrano nell'ambito di PCI DSS. Questi servizi forniscono l'infrastruttura su cui puoi creare il tuo servizio o applicazione per archiviare, elaborare o trasmettere 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 dei Controlli di servizio VPC e tokenizzazione. Anziché scegliere un solo approccio, valuta la possibilità di sfruttare tutte queste strategie per massimizzare la potenziale riduzione dell'ambito.

Non esiste una soluzione universale per la definizione dell'ambito PCI. È possibile che tu abbia una segmentazione esistente in una rete on-premise o una soluzione di elaborazione delle carte che può far sì che la progettazione dell'infrastruttura abbia un aspetto leggermente diverso da quello descritto qui. Utilizza queste strategie come principi da applicare al tuo ambiente.

Stabilisci controlli della gerarchia delle risorse

Le risorse Google Cloud sono organizzate in modo gerarchico come segue:

• La risorsa Organizzazione è il nodo radice nella gerarchia delle risorse Google Cloud. Le risorse dell'organizzazione contengono risorse di cartelle e progetto. I criteri di controllo dell'accesso dell'accesso di Identity and Access Management (IAM) applicati alla risorsa Organizzazione si applicano in tutta la gerarchia di 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 sono comunemente utilizzate per raggruppare progetti simili.
• I progetti sono un confine di attendibilità per tutte le risorse e un punto di applicazione IAM.

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

Figura 4. Un esempio di gerarchia delle risorse per la conformità PCI.

Nella figura 4, tutti i progetti nell'ambito PCI sono raggruppati in un'unica cartella per isolarli a livello di cartella. La cartella con ambito PCI contiene il CDE e un altro progetto che contiene i servizi condivisi. Quando implementi una gerarchia di risorse simile, la cartella con ambito PCI costituisce una radice logica dell'ambito di conformità PCI. Assicurati che solo gli utenti designati abbiano accesso a questa cartella e ai relativi progetti, puoi 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, in base alle esigenze, ti assicuri che solo gli utenti designati abbiano accesso ai componenti inclusi nell'ambito. Questo supporta i requisiti PCI DSS 7.2 e 7.3 (PDF) e altri. Per assicurarti che le autorizzazioni per l'organizzazione e le cartelle padre siano impostate correttamente, comprendi le implicazioni dell'ereditarietà dei criteri. Per supportare il requisito PCI DSS 8.4.1, assicurati di applicare l'autenticazione a più fattori (MFA) per gli utenti designati e consulta l'Integratore 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 aiutarti a proteggere i tuoi ambienti attendibili dall'escalation dei privilegi.

Come per tutta la conformità PCI, sono necessarie un'adeguata logging e monitoraggio dell'ambiente e dei relativi componenti con ambito per stabilire un confine chiaro dell'ambito. La gerarchia delle risorse è indissolubilmente collegata alla gestione di identità e accessi ed è necessario logging, controllo e monitoraggio delle azioni degli utenti efficaci per applicare e mantenere la separazione.

Implementazione della segmentazione della rete

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

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

Il seguente diagramma mostra come la strategia di segmentazione della rete è strettamente correlata alla gerarchia delle risorse. Questo diagramma presuppone una gerarchia di risorse con un'unica cartella per l'ambiente PCI nell'ambito e due progetti in questa cartella per CDE e servizi condivisi.

Figura 5. Gerarchia delle risorse che utilizza la segmentazione della rete per la conformità PCI.

Nella Figura 5, il progetto di servizi condivisi non fa parte del CDE, ma si tratta di un sistema connesso a ed è quindi nell'ambito dello standard PCI. L'accesso a CDE è limitato a livello di rete dalle regole firewall o dal bilanciatore del carico o dai criteri firewall per proteggere queste reti e soddisfare i requisiti PCI DSS 1.2 e 1.3. Il sistema di tokenizzazione e quello di pagamento sono collocati 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 CDE si trovano all'interno di un perimetro di sicurezza dei Controlli di servizio VPC per evitare errori di configurazione accidentali o compromissioni dei controlli di accesso IAM.

Se il deployment avviene 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 controllo dell'accesso grazie al quale gli utenti possono accedere solo a determinati pod, servizi e deployment all'interno del tuo cluster Kubernetes. Ciò è utile per fornire un accesso più granulare a utenti designati.
• I criteri di rete possono isolare i pod e i servizi l'uno dall'altro 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 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 del tuo atteggiamento di sicurezza in profondità e aiuta a restringere il tuo ambito isolando ulteriormente e proteggendo i tuoi componenti attendibili dall'ambiente circostante. Se esegui il deployment di tutto o parte del tuo CDE con Kubernetes, scopri più nel dettaglio come eseguire il tuo ambiente conforme allo standard PCI su GKE.

Implementa la tokenizzazione

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

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

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

Figura 6. Un'architettura tipica per un sistema di tokenizzazione.

Nella Figura 6, l'utente riceve un PAN e altri dati del titolare della carta, che vengono quindi inviati immediatamente al servizio di tokenizzazione. Il servizio di tokenizzazione cripta il PAN, genera un token e quindi li archivia entrambi in un vault sicuro. Solo i servizi designati, come il servizio di liquidazione, possono accedere alla cassaforte sulla rete e sono autorizzati a utilizzare un PAN utilizzando un token generato. Il servizio di liquidazione utilizza il PAN solo per inviarlo all'elaboratore dei pagamenti. Né il PAN né altri dati del titolare della carta si verificano mai al di fuori di questo flusso di dati strettamente controllato. Nell'ambito di una strategia di difesa in profondità, l'architettura utilizza anche la Sensitive Data Protection come ulteriore livello di difesa contro la fuoriuscita involontaria di PAN o di altri dati dei titolari di carte.

Nella figura 6, il sistema di tokenizzazione utilizza Hashicorp Vault, un archivio di segreti molto protetto, per gestire le mappature PAN-to-token. Solo gli utenti e i servizi autorizzati possono utilizzare un PAN da un token utilizzando un processo di ricerca. È possibile concedere un accesso limitato ai componenti autorizzati ad accedere al token vault in modo che il componente possa utilizzare un PAN solo durante la finestra temporale specifica necessaria per svolgere la sua funzione. Anche altri datastore possono essere appropriati, a seconda dei requisiti aziendali. Per ulteriori informazioni su come implementare in modo sicuro la tokenizzazione nel tuo ambiente, consulta Tokenizzazione di dati sensibili dei titolari di carte per PCI DSS.

Architettura di esempio

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

Figura 7. Un'architettura di esempio per l'elaborazione delle transazioni tokenizzate.

Nella Figura 7, il progetto di elaborazione delle transazioni è un sistema connesso a ed interessato dallo standard PCI. Non è un impatto sulla sicurezza, perché la compromissione di qualsiasi componente nel progetto di elaborazione delle transazioni non può fornire a un utente malintenzionato l'accesso a CHD. Il progetto dell'app web non rientra nell'ambito perché non si connette al CDE e interagisce solo con dati sanitizzati.

I dati tokenizzati vengono inviati da CDE a Pub/Sub. Prima che i dati tokenizzati vengano pubblicati per altri abbonati, Sensitive Data Protection verifica che non contengano CHD. I dati tokenizzati vengono elaborati da Dataflow e archiviati nel database delle transazioni di 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 il reporting e l'analisi utilizzando strumenti di business intelligence (BI) come Looker.

Supporto della conformità continua

Sicurezza e conformità sono più che un'architettura corretta e una buona progettazione. Un'architettura corretta può indicare che il tuo ambiente è progettato in modo sicuro in teoria. Sono inoltre necessari processi di controllo, logging, monitoraggio e correzione efficaci per garantire che il tuo ambiente rimanga sicuro in pratica.

Per supportare la conformità con ciascuna delle 12 categorie di requisiti PCI DSS, è necessario monitorare regolarmente l'implementazione di tale requisito. Devi dimostrare a te stesso e al tuo revisore che tutti i componenti inclusi nell'ambito rimarranno sicuri in futuro, molto tempo dopo il completamento della valutazione PCI DSS. Una corretta supervisione associata a un'azione di correzione rapida è chiamata conformità continua. La conformità continua è un requisito dello standard PCI DSS e, se implementata correttamente, può aiutare 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 dei controlli di servizio VPC e i log di Cloud Load Balancing. Puoi monitorare l'attività dei tuoi sistemi e utenti utilizzando Cloud Audit Logs. Il monitoraggio regolare di questi log ti consente di soddisfare il requisito PCI DSS 10.4 e di rispondere rapidamente a potenziali minacce per la sicurezza e risolverle. Per ulteriori informazioni, consulta il Integratore PCI DSS sul monitoraggio giornaliero efficace dei log (PDF).

Security Command Center consente di comprendere la superficie di attacco di dati e sicurezza fornendo servizi di inventario, individuazione, ricerca e gestione degli asset. Security Command Center può analizzare i risultati delle scansioni di Sensitive Data Protection per contribuire a identificare i dati dei titolari della carta divulgati e contribuire a verificare che il tuo sistema di tokenizzazione non venga utilizzato in modo improprio per utilizzare i PAN in modo fraudolento. Grazie a Event Threat Detection, Security Command Center può aiutarti a rilevare in modo proattivo le minacce e le attività insolite sulla tua rete e nelle tue VM, il che potrebbe indicare che un utente malintenzionato potrebbe monitorare il tuo sistema per identificarne le capacità difensive. Security Command Center consente inoltre di creare origini di sicurezza personalizzate specifiche per il tuo ambiente.

Google Cloud Armor può fornire ulteriore protezione per le tue applicazioni web Google Cloud rivolte al pubblico e aiutarti a rispettare il requisito PCI DSS 6.4. Google Cloud Armor valuta le richieste in arrivo per una serie di attacchi web comuni e può aiutarti a evitare revisioni manuali del codice, che richiedono molto lavoro, specificate nel requisito 6.4. La presenza di un WAF consente di mantenere una conformità continua, riducendo al contempo i costi e i rischi di conformità.

Passaggi successivi

• Consulta le best practice per la gestione degli obblighi di conformità.
• Consulta la pagina relativa alla conformità agli standard di sicurezza dei dati PCI su Google Cloud.
• Linee guida del PCI Council per la definizione dell'ambito PCI DSS e la segmentazione della rete (PDF).
• Prova il progetto base PCI su GKE.
• Proteggi i carichi di lavoro Kubernetes per PCI DSS.
• Tokenizzazione di dati sensibili dei titolari di carte per PCI DSS.
• Esegui il deployment del progetto Terraform PCI Starter.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.