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 del tuo ambiente cloud per la conformità al Payment Card Industry (PCI) Security Standards Council. Queste best practice sono utili per le organizzazioni che stanno migrando o progettando sistemi nel cloud soggetti a requisiti di conformità PCI. Questo documento fa riferimento ai requisiti PCI DSS 4.0, ove applicabili.

Informazioni sull'ambito di valutazione PCI DSS

Se la tua organizzazione si occupa di commercio su internet, devi supportare e mantenere la conformità allo standard PCI. Il modo in cui progetti e gestisci il tuo ambiente cloud influisce sull'ambito dei sistemi per la valutazione dello standard PCI Data Security Standard (DSS). La definizione dell'ambito ha implicazioni importanti per la sicurezza degli asset IT e per la capacità di supportare e mantenere la conformità PCI. Per assicurarti che l'ambito dell'ambiente PCI sia corretto, devi capire in che modo i processi aziendali e le decisioni di progettazione influiscono sull'ambito.

Cos'è l'ambito?

Tutti i sistemi che archiviano, elaborano o trasmettono i dati del titolare della carta (CHD) rientrano nell'ambito della tua 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 della tecnologia CHD.

Quali aspetti rientrano nell'ambito della valutazione rispetto a ciò che non rientra nell'ambito della valutazione?
Figura 1. Diagramma della definizione dell'ambito PCI DSS.

Nella figura 1, l'ambiente dei dati del titolare della carta (CDE), i sistemi connessi e i sistemi che incidono sulla sicurezza si trovano all'interno del confine dell'ambito di valutazione, mentre i sistemi attendibili e fuori dall'ambito sono al di fuori del confine dell'ambito di valutazione.

Secondo PCI DSS, i sistemi inclusi nell'ambito di applicazione sono attendibili. I sistemi nell'ambito includono il tuo CDE e qualsiasi sistema che è collegato alla sicurezza del tuo CDE o potrebbe influire negativamente 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 risiede all'interno del CDE, ma non ha accesso diretto a CHD.

Un sistema ha un impatto sulla sicurezza se può, se compromesso, consentire a un utente malintenzionato di accedere al CDE. Tutti i sistemi connessi e che incidono sulla sicurezza rientrano sempre nel relativo ambito.

I sistemi al di fuori dell'ambito sono untrusted per definizione in PCI DSS e non hanno alcun valore per un utente malintenzionato che vuole accedere a dati CHD o di autenticazione sensibili (SAD). Un sistema è fuori ambito se non può avere un impatto sulla sicurezza di un sistema nell'ambito di applicazione, anche se il sistema al di fuori dell'ambito è compromesso. Sebbene i sistemi fuori ambito non vengano valutati direttamente, PCI qualificati Security Assessor (QSA) verifica che l'ambito sia accurato e protegge la CHD in base allo standard PCI DSS. È quindi importante che i confini dell'ambito siano strettamente protetti, monitorati in modo continuo e rigoroso e chiaramente documentati.

Connessioni nel contesto del PCI

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

Ai fini della valutazione dell'ambito PCI, una connessione viene definita come segue:

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

Quando documenti il tuo ambiente, ti consigliamo di indicare chiaramente la 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 nell'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 archiviano, elaborano o trasmettono CHD o SAD.
  • Il database si trova su una rete separata o è segmentato in altro modo dal CDDE.
  • 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:

Il processo decisionale utilizzato per determinare l'ambito.
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 che si trovano nel CDE per cui si verifica 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 CHD.
    • Sistemi connessi a sistemi o che incidono sulla sicurezza per cui una delle seguenti condizioni è vera:
      • Un componente di sistema si connette direttamente a CDE.
      • Un componente del sistema influisce sulla configurazione o sulla sicurezza del CDE.
      • Un componente di sistema segmenta i sistemi CDE da sistemi e reti fuori ambito.
      • Un componente di sistema si connette indirettamente a CDE.
      • Un componente del 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 fuori ambito per PCI DSS quando tutte le seguenti condizioni sono vere:

    • Un componente del sistema non archivia, 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 di sistema non soddisfa alcun criterio per i sistemi connessi o che incidono sulla sicurezza.

    I sistemi fuori ambito possono includere sistemi che si connettono a un componente di sistema connesso o che incide sulla sicurezza, in cui vengono implementati controlli per impedire al sistema fuori ambito di ottenere l'accesso al CDE utilizzando il componente di sistema nell'ambito.

In termini pratici, la definizione di ambito di sistema PCI DSS può indicare che il negozio di sessioni e il database di e-commerce della tua 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 nell'ambito e quelli fuori ambito:

Identifica le connessioni tra i sistemi in ambito e fuori ambito di sola lettura, sola scrittura o lettura e scrittura.
Figura 3. Applicazioni nell'ambito in grado di chiamare servizi e applicazioni fuori ambito.

La Figura 3 mostra le seguenti connessioni:

  • Sola lettura:
    • Un'applicazione per l'elaborazione dei pagamenti nell'ambito legge un ID carrello da un database del carrello fuori ambito e legge i dati da un DNS e un NTP.
  • Sola scrittura:
    • Un'applicazione di elaborazione dei pagamenti nell'ambito scrive su un database principale dell'applicazione fuori ambito e su 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 della richiesta come segue:
      • L'utente legge e scrive su un'applicazione di elaborazione dei pagamenti nell'ambito di applicazione. 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 dati in un database del carrello fuori ambito, in un sessionstore e in un database principale dell'applicazione. Questi dati non includono CHD o SAD.
    • Un'applicazione di elaborazione dei pagamenti nell'ambito di applicazione legge e scrive dati in un servizio di tokenizzazione delle carte nell'ambito di applicazione e in 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 di applicazione. In questa architettura, è possibile avviare una connessione tra due entità solo nelle direzioni descritte nell'elenco precedente. Le connessioni tra le entità possono essere di sola lettura, lettura e scrittura o di sola scrittura dal punto di vista del chiamante. Qualsiasi direzione di percorso o richiesta che non sia esplicitamente descritta è bloccata dalla segmentazione. Ad esempio, l'applicazione di elaborazione dei pagamenti può leggere dal database del carrello e scrivere nel servizio di logging, il che comporta l'avvio di una connessione a queste entità.

I sistemi che rientrano nell'ambito di solito chiamano sistemi e servizi fuori ambito. Queste connessioni rimangono sicure perché la segmentazione impedisce a qualsiasi chiamante remoto (diverso da un titolare della carta) di avviare una connessione nel CDE direttamente o indirettamente. La Figura 3 mostra che l'unico percorso in entrata verso l'applicazione di pagamento proviene dall'utente.

Nella Figura 3, nessun servizio o applicazione fuori ambito fornisce dati di configurazione o di sicurezza all'applicazione di elaborazione dei pagamenti. I dati passano attraverso l'architettura nel seguente modo:

  1. L'applicazione principale inoltra l'utente all'applicazione di pagamento e utilizza un POST HTTP per trasmettere il CartID e uno strumento di convalida chiamato CartAuthKey. CartAuthKey è un hash di CartID e un secret precondiviso noto solo all'applicazione principale e di pagamento.
  2. L'applicazione di pagamento convalida l'utente eseguendo l'hashing di CartID insieme al secret e confrontando questo valore con il valore CartAuthKey.
  3. Una volta autenticati i dati utente, CartID viene utilizzato per leggere i contenuti del carrello dal relativo database. 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 archiviati nel servizio di tokenizzazione.
  5. Una volta elaborato il pagamento, il risultato viene inserito nel database dell'applicazione principale con un account di servizio di database di sola scrittura.

Considerazioni sull'ambito

Nelle linee guida per la segmentazione della rete e l'ambito PCI DSS, il PCI Security Standards Council (SSC) consiglia di presumere che tutto sia nell'ambito fino a quando non viene verificato diversamente. Questo consiglio SSC non significa che devi rendere l'ambito il più ampio possibile. Piuttosto, significa che il QSA valuta tutti i sistemi come se fossero attendibili, a meno che tu non possa dimostrare che un sistema non ha connettività o alcun impatto sulla sicurezza del CDE. Per soddisfare i requisiti di conformità normativa e mantenere al sicuro i tuoi asset IT, devi 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 i confini tra i sistemi in ambito e fuori ambito. La prima attività del QSA è confermare che l'ambito documentato incapsula ragionevolmente il CDE e i sistemi collegati. Nell'ambito della valutazione complessiva, il QSA verifica quindi che i sistemi al di fuori dell'ambito non possano influire negativamente su quelli inclusi.

Assicurati di comprendere eventuali circostanze speciali specifiche per il tuo ambiente, come le seguenti:

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

Rischi di definizione dell'ambito errata

Un ambito eccessivamente ampio può comportare valutazioni costose e un aumento dei rischi per la conformità. Per mantenere un ambito ristretto, considera attendibili il maggior numero possibile di sistemi e concedi l'accesso solo a un numero ristretto di utenti designati. Tramite una valutazione accurata e 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 contribuire a garantire che non possano influenzare i sistemi inclusi nell'ambito.

Se hai bisogno di un'infrastruttura di grandi dimensioni per soddisfare i requisiti PCI DSS, puoi includere sistemi estranei nell'ambito di valutazione. L'inclusione di sistemi estranei nell'ambito potrebbe comportare rischi per la capacità di garantire la conformità. Inoltre, può peggiorare la tua strategia di sicurezza complessiva ampliando la superficie di attacco del tuo ambiente di ambito attendibile.

Un principio fondamentale per la sicurezza di rete e lo standard PCI DSS è presumere che una parte o l'intera rete sia già stata compromessa. Questo principio è sancito nel modello di sicurezza Zero Trust di Google, che rifiuta la sicurezza perimetrale a favore di un modello in cui ogni sistema è responsabile della sicurezza se stessa. Il modello di sicurezza di Google è in linea con PCI DSS, che consiglia che il deployment di CDE e dei relativi sistemi connessi venga eseguito in un piccolo spazio affidabile, segmentato dall'ambiente IT più ampio e non mescolato con quest'ultimo.

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

Un ambiente ampio e nell'ambito di sistemi attendibili richiede un apparato di gestione di dimensioni simili per mantenere costanti il monitoraggio, la manutenzione, il controllo e l'inventario di questi sistemi. La complessità dell'architettura del sistema, dei processi di gestione dei cambiamenti e dei criteri di controllo dell'accesso può creare rischi per la sicurezza e la conformità. La difficoltà di gestire questi processi 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 Supporto della 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 è possibile creare un proprio servizio o applicazione che archivia, elabora o trasmette i dati dei titolari della carta.

Strategie per ridurre l'ambito

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

Non esiste una soluzione universale per l'ambito PCI. Potresti avere già attivato la segmentazione in una rete on-premise o una soluzione di elaborazione delle schede che può far sì che il design della tua infrastruttura abbia un aspetto leggermente diverso da quello descritto qui. Usa queste strategie come principi da applicare al tuo ambiente.

Stabilisci controlli per la gerarchia delle risorse

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

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

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

Esempio di gerarchia delle risorse che mostra come raggruppare le risorse PCI in modo che rientrino nell'ambito della valutazione.
Figura 4. Un esempio di gerarchia delle risorse per la conformità PCI.

Nella Figura 4, tutti i progetti in ambito PCI sono raggruppati in una singola cartella per essere isolati a livello di cartella. La cartella con ambito PCI contiene il CDE e un altro progetto con servizi condivisi. Quando implementi una gerarchia di risorse simile, le cartelle con ambito PCI formano la radice logica dell'ambito di conformità PCI. Se ti assicuri che solo gli utenti designati abbiano accesso a questa cartella e ai suoi 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 nell'ambito. Questo supporta i requisiti PCI DSS 7.2 e 7.3 (PDF) e altri ancora. Per assicurarti che le autorizzazioni per l'organizzazione principale e le cartelle siano impostate correttamente, scopri 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 il supplemento PCI DSS sulle linee guida per l'autenticazione a più fattori (PDF). Per applicare la conformità nella gerarchia delle risorse, assicurati di aver compreso come impostare i vincoli dei criteri dell'organizzazione. Questi vincoli supportano la conformità continua e possono aiutarti a proteggere gli ambienti attendibili dall'escalation dei privilegi.

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

Implementazione della segmentazione della rete

La segmentazione della rete è un importante modello di architettura che contribuisce a proteggere il CDE e i sistemi connessi, come descritto nella guida aggiuntiva alla segmentazione della rete (PDF) supplementare 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 al tuo CDE o ai suoi componenti collegati. Definisci solo le route necessarie per consentire la comunicazione tra componenti attendibili. Quando i sistemi non attendibili non dispongono di una route per inviare o ricevere pacchetti dai sistemi attendibili, i sistemi non attendibili sono fuori ambito e non possono influire sulla sicurezza dei componenti 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 route o subnet estranee che potrebbero abilitare l'accesso predefinito alle 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 in che modo la strategia di segmentazione della rete è strettamente correlata alla gerarchia delle risorse. Questo diagramma presuppone una gerarchia di risorse con una singola cartella per l'ambiente PCI nell'ambito e due progetti in quella cartella per il CDE e i servizi condivisi.

CDE mostrato in un VPC dedicato con una connessione di rete al progetto di 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 è un sistema connesso a e, di conseguenza, rientra nell'ambito del protocollo PCI. L'accesso al CDE è limitato a livello di rete dal bilanciatore del carico e dalle regole firewall o dai criteri del 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 il CDE si trovano all'interno di un perimetro di sicurezza dei Controlli di servizio VPC per garantire la protezione da errori di configurazione accidentali o compromissioni dei controlli dell'accesso IAM.

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

  • Gli spazi dei nomi offrono un ulteriore livello di isolamento del controllo dell'accesso dell'accesso in base al quale gli utenti possono avere accesso solo a determinati pod, servizi e deployment all'interno del cluster Kubernetes. Questa funzionalità è utile per fornire un accesso più granulare agli utenti designati.
  • I criteri di rete possono isolare pod e 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 ti consente di applicare gli standard di sicurezza dei pod ai pod in esecuzione sul tuo cluster GKE.

Ciascuno di questi livelli rappresenta una parte importante della strategia di sicurezza di difesa in profondità e contribuisce a restringere ulteriormente l'ambito, isolando e proteggendo ulteriormente i componenti attendibili dall'ambiente circostante. Se esegui il deployment del CDE interamente o in parte con Kubernetes, scopri nel dettaglio come eseguire il tuo ambiente conforme allo standard PCI su GKE.

Implementare la tokenizzazione

La tokenizzazione è il processo di occultamento irreversibile di un numero di conto bancario principale (PAN). Un PAN tokenizzato, o token, non può essere utilizzato per un PAN con metodi matematici. PCI SSC offre indicazioni sull'impatto dell'ambito della tokenizzazione nel Capitolo 3 del supplemento delle linee guida per la tokenizzazione (PDF). L'ambito PCI DSS è fortemente influenzato dall'insieme di componenti che memorizzano e trasmettono i dati dei titolari della carta. Se implementata correttamente, la tokenizzazione può aiutare a ridurre l'ambito di valutazione riducendo al minimo la presenza e la trasmissione dei numeri principali degli account.

La tokenizzazione è anche una forma di segmentazione per flusso di dati, perché separa i sistemi che memorizzano 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 rilevare le attività fraudolente potrebbero non avere bisogno dei PAN, ma 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. Se l'applicazione web interagisce solo con i sistemi che utilizzano token, l'applicazione web può essere potenzialmente rimossa dall'insieme dei sistemi connessi, riducendo l'ambito.

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

Mostra il flusso di dati CHD, PAN e tokenizzati in tutto il progetto CDE e nel progetto di servizi condivisi di un sistema di tokenizzazione.
Figura 6. Una tipica architettura per un sistema di tokenizzazione.

Nella figura 6, l'utente riceve un PAN e altri dati del titolare della carta, che vengono poi inviati immediatamente al servizio di tokenizzazione. Il servizio di tokenizzazione cripta il PAN, genera un token, quindi li archivia in un vault sicuro. Solo i servizi designati, come il servizio di transazione, possono accedere al caveau della rete e sono autorizzati a richiedere un PAN utilizzando un token generato. Il servizio di transazione utilizza il PAN solo per inviarlo all'elaboratore dei pagamenti. Né il PAN né altri dati del titolare della carta avvengono 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 perdita involontaria di dati PAN o altri dati dei titolari delle carte.

Nella figura 6, il sistema di tokenizzazione utilizza Hashicorp Vault, un archivio secret protetto, per gestire le mappature PAN a token. Solo gli utenti e i servizi autorizzati possono utilizzare il codice PAN da un token tramite una procedura di ricerca. Ai componenti autorizzati ad accedere al token vault può essere concesso un accesso limitato in modo che il componente possa utilizzare un PAN solo nell'arco di tempo specifico necessario per svolgere la sua funzione. Anche altri datastore possono essere appropriati, a seconda delle esigenze della tua attività. Per ulteriori informazioni sull'implementazione sicura della tokenizzazione nel tuo ambiente, consulta Tokenizzazione dei 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, nonché l'archiviazione dei record delle transazioni tokenizzati in Spanner.

Mostra il progetto di elaborazione delle transazioni in cui Pub/Sub riceve i dati tokenizzati prima di inviarli a Dataflow per l'elaborazione.
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, rientrato nell'ambito di PCI. Non ha un impatto sulla sicurezza, perché la compromissione di qualsiasi componente del progetto di elaborazione delle transazioni non può consentire a un utente malintenzionato di accedere a CHD. Il progetto webapp è fuori ambito perché non si connette al CDE e interagisce solo con dati sanitizzati.

I dati tokenizzati vengono inviati dal CDE a Pub/Sub. Prima che i dati tokenizzati vengano pubblicati per altri abbonati, Sensitive Data Protection verifica che non contenga CHD. I dati tokenizzati vengono elaborati da Dataflow e archiviati nel database di transazioni Spanner. Le transazioni possono essere associate a utenti specifici tramite token senza accedere ai PAN. Il database di transazioni Spanner può essere utilizzato anche per il reporting e l'analisi mediante strumenti di business intelligence (BI) come Looker.

Supporta la conformità continua

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

Per supportare la conformità con ciascuna delle 12 categorie di requisiti PCI DSS, è necessario monitorare costantemente l'implementazione di tale requisito. Devi dimostrare a te stesso e al tuo valutatore che qualsiasi componente nell'ambito rimarrà sicuro in futuro, molto tempo dopo il completamento della valutazione PCI DSS. Una supervisione corretta abbinata a un'azione di correzione rapida si chiama conformità continua. La conformità continua è un requisito dello standard 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 Controlli di servizio VPC e i log di Cloud Load Balancing. Puoi monitorare l'attività dei sistemi e degli utenti utilizzando Cloud Audit Logs. Il monitoraggio regolare di questi log consente di soddisfare il requisito PCI DSS 10.4 e di rispondere rapidamente a potenziali minacce alla sicurezza e intervenire di conseguenza. Per ulteriori informazioni, consulta il supplemento PCI DSS sul monitoraggio efficace dei log giornaliero (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 contribuire a identificare la perdita dei dati dei titolari della carta e verificare che il tuo sistema di tokenizzazione non venga utilizzato in modo improprio per utilizzare i PAN in modo fraudolento. Utilizzando Event Threat Detection, Security Command Center può aiutarti a rilevare in modo proattivo minacce e attività insolite sulla tua rete e nelle tue VM, indicando potenzialmente che un utente malintenzionato sta esplorando 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 relative a una serie di attacchi web comuni e può aiutarti a evitare lunghe revisioni manuali del codice specificate nel requisito 6.4. L'implementazione di WAF consente di mantenere la conformità continua riducendo al contempo i costi e i rischi continui per la conformità.

Passaggi successivi