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

Questo documento descrive le best practice per la progettazione di un ambiente cloud per la conformità al standard degli standard di sicurezza (PCI) per il settore delle carte di pagamento. Queste best practice sono utili per le organizzazioni che stanno eseguendo la migrazione o progettando sistemi nel cloud soggetti ai requisiti di conformità PCI.

Informazioni sull'ambito della valutazione DSI PCI

Se la tua organizzazione si occupa di commercio su Internet, devi supportare e mantenere la conformità PCI. La modalità di progettazione e gestione dell'ambiente cloud influisce sull'ambito dei sistemi per la valutazione degli standard di sicurezza dei dati PCI (DSS). La definizione degli ambiti ha implicazioni importanti per la sicurezza delle risorse IT e la tua capacità di supportare e mantenere la conformità PCI. Per garantire che il tuo ambiente PCI abbia l'ambito corretto, devi comprendere come i processi aziendali e le decisioni di progettazione influiscono sull'ambito.

Che cos'è l'ambito?

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

Definizione dell'ambito PCI DSS.

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

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

Secondo PCI DSS, i sistemi nell'ambito sono attendibili. I sistemi nell'ambito includono il CDE e qualsiasi sistema collegato alla, o che potrebbe avere un impatto, sulla sicurezza del tuo CDE.

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

Un sistema ha un impatto sulla sicurezza se, se compromesso, consente a un utente malintenzionato di accedere al CDE. Tutti i sistemi connessi e che influiscono sulla sicurezza sono sempre ambito di applicazione.

I sistemi fuori ambito sono non attendibili per definizione in PCI DSS e non hanno alcun valore per un utente malintenzionato che vuole ottenere l'accesso a CHD o dati di autenticazione sensibili (SAD). Un sistema non rientra nell'ambito se non può influire sulla sicurezza di un sistema in ambito, anche se il sistema esterno viene compromesso. Sebbene i sistemi esterni all'ambito non vengano valutati direttamente, il PCI qualificati Security Assessor (QSA) verifica che la definizione dell'ambito sia precisa e protegga CHD in base allo standard PCI DSS. Pertanto, i limiti dell'ambito sono strettamente protetti, monitorati in modo continuo e completo e documentati in modo chiaro.

Connessioni nel contesto PCI

Diversi requisiti del criterio PCI DSS fanno riferimento alle connessioni. Al momento della stesura di questo documento, PCI non definisce esplicitamente le connessioni. Puoi interpretare il significato delle connessioni in questo contesto comprendendo la struttura ad albero dell'ambito decisionale nella guida agli SSC PCI DSS per la definizione dell'ambito e la segmentazione della rete.

Ai fini della valutazione del tuo ambito PCI, una connessione è definita da quanto segue:

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

Quando documenti il tuo ambiente, è preferibile indicare chiaramente quale parte è autorizzata ad 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ò effettuare query su un server di database esterno nell'ambito senza che il server esterno rientri 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 è altrimenti segmentato 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:

Diagramma di flusso per determinare 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 per PCI DSS:

    • Sistemi che si trovano nel CDE per i quali uno dei seguenti è vero:
      • Un componente del sistema memorizza, elabora o trasmette CHD o SAD.
      • Un componente del sistema si trova sullo stesso segmento di rete, ad esempio nella stessa subnet o VLAN, dei sistemi che memorizzano, elaborano o trasmettono CHD.
    • Sistemi connessi a sistemi che incidono sulla sicurezza per i quali uno dei seguenti è vero:
      • Un componente del 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 di reti e sistemi esterni all'ambito.
      • Un componente di sistema si connette indirettamente alla 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 non rientrano nell'ambito dello standard 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 a nessun sistema del 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 di sistema connesso all'ambito o che incide sulla sicurezza, ove sono stati predisposti controlli per impedire al sistema esterno all'ambito di ottenere l'accesso al CDE utilizzando il componente del sistema nell'ambito.

In termini pratici, la definizione di ambito di sistema PCI DSS può indicare che l'archivio sessioni dell'applicazione web e il database di e-commerce potrebbero essere considerati fuori dall'ambito se la segmentazione è implementata e documentata correttamente. Il seguente diagramma mostra come funzionano le connessioni in lettura e scrittura tra i sistemi nell'ambito e nei sistemi fuori ambito:

Applicazioni nell'ambito che possono chiamare servizi e applicazioni esterni all'ambito.

Figura 3. Applicazioni che rientrano nell'ambito e sono in grado di chiamare servizi e applicazioni esterni all'ambito.

La Figura 3 mostra le seguenti connessioni:

  • Solo lettura:
    • Un'applicazione di elaborazione dei pagamenti in ambito legge un ID carrello dal database del carrello esterno e legge i dati da un DNS e un NTP.
  • Solo scrittura:
    • Un'applicazione di elaborazione dei pagamenti nell'ambito scrive in un database principale dell'applicazione esterno all'ambito e in Cloud Logging.
    • L'applicazione web principale esterna all'ambito scrive i 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 nel seguente modo:
      • L'utente legge e scrive in un'applicazione di elaborazione dei pagamenti nell'ambito. I metadati di questa 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 esterna all'ambito. I metadati di questa richiesta sono un ID sessione che non contiene CHD o SAD.
    • L'applicazione web principale fuori dall'ambito legge e scrive i dati in un database del carrello esterno all'ambito, nell'archivio sessioni e nel database principale dell'applicazione. Questi dati non includono CHD o SAD.
    • Un'applicazione di elaborazione dei pagamenti in ambito legge e scrive i dati in un servizio di tokenizzazione della carta nell'ambito e in un elaboratore di 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 pagamenti (applicazione di pagamento), che rientra nell'ambito. In questa architettura, è possibile avviare una connessione tra due entità solo nelle indicazioni descritte dall'elenco precedente. Le connessioni tra le entità possono essere di sola lettura, in lettura e scrittura o solo di scrittura dal punto di vista del chiamante. Qualsiasi direzione o direzione della richiesta che non sia esplicitamente descritta è bloccata dalla segmentazione. Ad esempio, l'applicazione di elaborazione pagamenti può leggere dal database del carrello e scrivere sul servizio di logging, il che comporta l'avvio di una connessione a tali entità.

I sistemi nell'ambito comunemente chiamano sistemi e servizi esterni all'ambito. Queste connessioni rimangono sicure perché la segmentazione impedisce a qualsiasi chiamante remoto (tranne che al titolare della carta) di avviare una connessione al CDE direttamente o indirettamente. La Figura 3 mostra che l'unico percorso in entrata verso l'applicazione di pagamento è dell'utente.

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

  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 alle applicazioni principali e di pagamento.
  2. L'applicazione di pagamento convalida l'utente eseguendo l'hashing di CartID insieme al secret e confrontando questo valore con CartAuthKey.
  3. Una volta autenticati 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 di database di sola scrittura.

Considerazioni sull'ambito

Nella Guida per la definizione dell'ambito e la segmentazione della rete PCI DSS, il PCI Security Standards Council (SSC) consiglia di supporre che tutto sia in ambito finché non sia verificato diversamente. Il consiglio relativo alle SSC non significa che dovresti ampliare il più possibile il tuo ambito. Piuttosto, significa che la QSA valuta tutti i sistemi come se fossero attendibili, a meno che tu non possa dimostrare che un sistema non ha connettività o un impatto sulla sicurezza sul tuo CDE. Per soddisfare i requisiti di conformità normativa e tenere al sicuro i tuoi asset IT, devi definire l'ambiente in linea con il principio di privilegio minimo considerando il minor numero possibile di sistemi.

Prima della valutazione, valuta il tuo ambiente per comprendere e documentare i confini tra i sistemi all'interno e all'esterno dell'ambito. La prima attività di QSA è verificare che l'ambito documentato incorpori ragionevolmente il CDE e i sistemi connessi. Nell'ambito della valutazione complessiva, il QSA verifica che i sistemi fuori ambito non possano influire negativamente su alcun sistema interno all'ambito.

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

Le best practice per la sicurezza di Google possono aiutarti a stabilire e dimostrare un confine chiaro e difensivo tra l'ambito dell'ambito e quello non attendibile che ti aiuterà nella valutazione. Quando gestisci l'accesso e la sicurezza seguendo il principio del privilegio minimo, aiuti a ridurre al minimo il numero di punti di esposizione per i dati dei titolari di carte, ridurre al minimo la superficie di attacco del CDE e, di conseguenza, ridurre la portata. Quando riduci la portata dei sistemi interessati, contribuisci a ridurre la complessità del sistema e semplificare la valutazione dei PCS DSS.

Rischi dell'ambito errato

Una portata troppo ampia può portare a costose valutazioni e aumentare i rischi di conformità. Per mantenere un ambito limitato, fidati il meno possibile dei sistemi e concedi l'accesso solo a pochi utenti designati. Mediante un'attenta valutazione e un'autovalutazione, potrai identificare i sistemi che non dovrebbero rientrare nell'ambito dei PCI DSS, verificare che siano conformi alle linee guida relative ai 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 garantire che non abbiano alcun impatto sui sistemi nell'ambito.

Se hai bisogno di un'infrastruttura di grandi dimensioni per soddisfare i requisiti degli standard PCI DSS, puoi causare l'inclusione di sistemi non pertinenti nell'ambito della valutazione. L'inclusione di sistemi non pertinenti nell'ambito di un approccio rappresenta un rischio per la tua conformità. Può anche ridurre la qualità della tua strategia di sicurezza ampliando la superficie di attacco dell'ambiente affidabile.

Uno dei principi fondamentali della sicurezza di rete e dello standard PCI DSS consiste nel presupporre che alcune o tutte le reti della tua rete siano già state compromesse. Questo principio è sancito nel modello di sicurezza Zero Trust di Google, che respinge la sicurezza solo in perimetro a favore di un modello in cui ogni sistema è responsabile della sicurezza. Il modello di sicurezza di Google è in linea con PCI DSS, che consiglia di eseguire il deployment del CDE e dei relativi sistemi connessi in uno spazio ridotto e affidabile, segmentato dal tuo ambiente IT più ampio e non interconnesso.

All'interno dell'ambiente PCI nell'ambito, non posizionare il tuo CDE in uno spazio ampio e attendibile con un ampio perimetro. Questo può creare un falso senso di sicurezza e compromettere una strategia di difesa in profondità. Se un utente malintenzionato viola la sicurezza del perimetro, può agire con facilità all'interno di una Intranet privata affidabile. Pensa a come restringere lo spazio attendibile in modo che contenga solo le esigenze necessarie per operare in modo sicuro ed evitare di fare affidamento esclusivamente sulla sicurezza del perimetro. Comprendere e seguire questi principi puoi progettare un ambiente cloud per proteggere i tuoi sistemi critici e ridurre il rischio di contaminazione da sistemi compromessi.

Un ambiente ampio e adatto ai diversi sistemi attendibili richiede un sistema di gestione simile che sia in grado di mantenere monitoraggio, manutenzione, controllo e inventario continui di questi sistemi. La complessità dell'architettura di sistema, i processi di gestione dei cambiamenti e i criteri di controllo degli accessi possono creare rischi per la sicurezza e la conformità. La difficoltà di gestione di questi processi di monitoraggio può portare a difficoltà nel soddisfare i requisiti PCI DSS10 e 11. È importante comprendere questi rischi e implementare strategie per limitare l'ambito del tuo ambiente valutato. Per ulteriori informazioni, consulta la sezione Supportare la conformità continua di 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 la tua applicazione per archiviare, elaborare o trasmettere i dati dei titolari di carte.

Strategie per ridurre l'ambito

In questa sezione vengono illustrate le seguenti strategie per ridurre l'ambito della valutazione: controlli della gerarchia delle risorse, segmentazione dei Controlli di servizio VPC e tokenizzazione. Invece di scegliere un approccio, conviene adottare tutte queste strategie per massimizzare la potenziale riduzione dell'ambito.

Non esiste una soluzione universale per l'ambito PCI. Potresti avere una segmentazione esistente in una rete on-premise o una soluzione di elaborazione delle schede che può far apparire il design dell'infrastruttura in modo leggermente diverso rispetto a quanto descritto qui. Utilizza queste strategie come principi applicabili al tuo ambiente personale.

Stabilisci controlli della gerarchia delle risorse

Le risorse Google Cloud sono strutturate in modo gerarchico:

  • La risorsa organizzazione è il nodo radice nella gerarchia delle risorse di Google Cloud. Le risorse dell'organizzazione contengono risorse relative a cartelle e progetti. I criteri di controllo dell'accesso Identity and Access Management (IAM) applicati alla risorsa organizzazione si applicano a tutta la gerarchia 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 comunemente utilizzate 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 di valutazione, segui le best practice per le aziende di Google per definire la gerarchia delle risorse. L'immagine seguente mostra una gerarchia di risorse di esempio per la conformità PCI:

Una gerarchia di risorse di esempio per la conformità PCI.

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

Nella figura 4, tutti i progetti che rientrano nell'ambito PCI sono raggruppati all'interno di una singola cartella per essere isolati 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 forma una radice logica dell'ambito della tua conformità PCI. Se consenti che solo gli utenti designati abbiano accesso a questa cartella e ai relativi progetti, puoi escludere altre cartelle, progetti e risorse dalla 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. Sono supportati i requisiti PCI DSS 7.1 e 7.2 e altri. Per assicurarti che le autorizzazioni per l'organizzazione principale e le cartelle siano impostate correttamente, consulta le implicazioni dell'ereditarietà dei criteri. Per supportare il requisito PCI DSS 8.3.1, assicurati di applicare l'autenticazione a più fattori (MFA) per gli utenti designati e consulta il componente aggiuntivo PCI DSS sulle indicazioni per l'autenticazione a più fattori. 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 dalla riassegnazione dei privilegi.

Come per tutte le operazioni di conformità PCI, sono necessari un logging e un monitoraggio adeguati del tuo ambiente e dei suoi componenti con ambito per definire un confine di ambito chiaro. La gerarchia delle risorse è indissolubilmente collegata alla gestione di identità e accessi ed è necessario registrare, controllare e monitorare in modo efficace le azioni degli utenti per imporre e mantenere la separazione.

Implementare la segmentazione delle reti

La segmentazione della rete è un importante modello di architettura per garantire la protezione di CDE e dei sistemi connessi, come descritto nella guida aggiuntiva alla segmentazione della rete per PCI SSC. Se implementata correttamente, la segmentazione della rete restringe l'ambito di valutazione rimuovendo le route di rete che i sistemi non attendibili potrebbero utilizzare per accedere al CDE o ai relativi componenti connessi. Definisci solo i route necessari per consentire la comunicazione tra componenti attendibili. Quando i sistemi non attendibili non hanno un percorso mediante il quale inviare o ricevere pacchetti da sistemi attendibili, i sistemi non attendibili sono fuori ambito e non possono influire sulla sicurezza dei componenti all'interno dell'ambito.

Per implementare la segmentazione della rete, posiziona il CDE in un virtual private cloud (VPC) dedicato con i controlli del servizio VPC abilitati. Crea questo VPC in modalità personalizzata per garantire che non vengano create subnet o route estranee che potrebbero consentire l'accesso predefinito alle reti attendibili. Implementa vincoli dei criteri dell'organizzazione per assicurarti che questo VPC non possa essere condiviso con altri progetti e possa essere collegato 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 tue risorse. Questo diagramma presuppone una gerarchia delle risorse con una singola cartella per l'ambiente PCI nell'ambito e due progetti in quella cartella per il CDE e i servizi condivisi.

Un esempio di gerarchia delle risorse che utilizza la segmentazione della rete.

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

Nella figura 5, il progetto dei servizi condivisi non fa parte del CDE, ma è un sistema connesso a e quindi rientra nell'ambito del PCI. L'accesso al CDE è limitato a livello di rete dal bilanciatore del carico e dalle regole firewall per proteggere queste reti e soddisfare i requisiti PCI DSS 1.1 e 1.2. Il sistema di tokenizzazione e il sistema di pagamento sono inseriti in subnet separate e la comunicazione è regolata da regole firewall tra ogni subnet per consentire solo le comunicazioni necessarie. Le funzioni di logging, monitoraggio e avvisi necessarie che soddisfano i requisiti PCI DSS 10.1, 10.2, 10.3, 10.6 e 10.7 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 evitare errori di configurazione accidentale o compromissione dei controlli di accesso IAM.

Se il deployment è eseguito su Google Kubernetes Engine (GKE), ecco alcuni ulteriori modi per segmentare il 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 di accesso, grazie al quale gli utenti possono accedere solo a determinati pod, servizi e deployment all'interno del cluster Kubernetes. È utile per fornire un accesso più granulare agli 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.
  • PodSecurityPolicies definisce un insieme di condizioni che i pod devono soddisfare per essere accettati dal cluster e forniscono un ulteriore livello di protezione nel cluster GKE.

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

Implementare la tokenizzazione

La tokenizzazione è il processo di oscuramento irreversibile di un numero di conto principale (PAN). Non è possibile utilizzare un PAN o token tokenizzato per un PAN con mezzi matematici. Lo standard PCI SSC offre indicazioni sull'impatto della definizione degli ambiti della tokenizzazione nel capitolo 3 dell'integrazione delle linee guida sulla tokenizzazione. L'ambito PCI DSS è influenzato in modo significativo 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 dell'account principali.

La tokenizzazione è anche una forma di segmentazione in base al 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 i token. Ad esempio, i sistemi che analizzano le attività dei consumatori per attività fraudolenta non hanno bisogno di PAN, ma possono invece eseguire queste analisi utilizzando dati tokenizzati. La tokenizzazione aggiunge anche un livello di separazione tra i sistemi che archiviano e trasmettono PAN e l'applicazione web di e-commerce. Quando la tua applicazione web interagisce solo con i sistemi che utilizzano token, l'applicazione web può potenzialmente essere rimossa dal set di sistemi connessi, riducendo così l'ambito.

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

Un'architettura tipica di un sistema di tokenizzazione.

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

Nella figura 6, l'utente riceve un codice PAN e altri dati, quindi vengono inviati immediatamente al servizio di tokenizzazione. Il servizio di tokenizzazione cripta il PAN, genera un token e quindi li archivia in un archivio protetto di token. Solo i servizi designati, come il servizio di liquidazione, possono accedere al caveau sulla rete e sono autorizzati a utilizzare un PAN utilizzando un token generato. Il servizio di transazione utilizza solo il PAN per inviarlo all'elaboratore dei pagamenti. Né il PAN né gli altri dati del titolare della carta si verificano al di fuori di questo flusso di dati strettamente controllato. Come parte di una strategia di difesa in profondità, l'architettura utilizza anche Cloud Data Loss Prevention (Cloud DLP) come ulteriore livello di difesa contro la fuga involontaria di PAN o altri dati dei titolari di carte.

Nella figura 6, il sistema di tokenizzazione utilizza Hashicorp Vault, un archivio segreto protetto, per gestire le mappature da PAN a token. Solo gli utenti e i servizi autorizzati possono utilizzare un PAN da un token utilizzando una procedura di ricerca. Ai componenti autorizzati ad accedere al Archivio token è possibile concedere un accesso limitato al tempo, in modo che il componente possa utilizzare un PAN solo durante l'intervallo di tempo specifico necessario per svolgere la sua funzione. Anche altri datastore possono essere appropriati, a seconda delle esigenze della tua azienda. Per ulteriori informazioni sull'implementazione sicura della tokenizzazione nel tuo ambiente, consulta Tokening dei dati sensibili dei titolari delle carte per PCI DSS.

Esempio di architettura

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

Un'architettura di esempio per l'elaborazione di transazioni con token.

Figura 7. Un'architettura di esempio per l'elaborazione di transazioni con token.

Nella figura 7, il progetto di elaborazione delle transazioni è un sistema connesso a e rientra nell'ambito del PCI. Non ha un impatto negativo 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 webapp è fuori ambito perché non si connette al CDE e interagisce solo con i dati purificati.

I dati tokenizzati vengono inviati dal CDE a Pub/Sub. Prima di pubblicare i dati tokenizzati per altri abbonati, Cloud DLP verifica che non contenga 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 Spanner può essere utilizzato anche per la generazione di report e l'analisi tramite strumenti di business intelligence (BI), come Looker.

Supportare la conformità continua

Sicurezza e conformità sono più di una semplice architettura e una buona progettazione. Un'architettura corretta può indicare che l'ambiente è progettato in modo sicuro in teoria. Hai anche bisogno di efficaci processi di controllo, logging, monitoraggio e correzione per garantire che l'ambiente rimanga sicuro in pratica.

Per supportare la conformità a ciascuna delle 12 categorie di requisiti per PCI DSS, devi monitorare costantemente l'implementazione di tale requisito. Devi dimostrare a te e al perito di valutazione che qualsiasi componente nell'ambito rimarrà sicuro in futuro, molto dopo il completamento della valutazione PCI DSS. La supervisione adeguata insieme all'azione di correzione rapida è chiamata conformità continua. La conformità continua è un requisito di PCI DSS che, 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 i log di 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 tuoi sistemi e utenti utilizzando gli audit log di Cloud. Il monitoraggio regolare di questi log ti consente di rispettare il requisito PCI DSS 10.6 e di rispondere rapidamente alle potenziali minacce alla sicurezza. Per ulteriori informazioni, consulta l'articolo Integrazione di PCI DSS sul monitoraggio quotidiano dei log efficace.

Security Command Center consente di comprendere la piattaforma di attacco per sicurezza e dati fornendo inventario, rilevamento, ricerca e gestione degli asset. Security Command Center può analizzare i risultati della scansione di Cloud DLP per identificare meglio i dati dei titolari di carte che sono stati divulgati e verificare che il sistema di tokenizzazione non venga utilizzato in modo improprio per utilizzare PAN in modo dannoso. Grazie a 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 utente malintenzionato potrebbe proibire il tuo sistema di identificarne le capacità difensive. Security Command Center consente inoltre di creare origini di sicurezza personalizzate specifiche per il tuo ambiente.

Puoi utilizzare Forseti Security per rilevare modifiche accidentali o dannose alla configurazione dell'ambiente. Puoi acquisire la cronologia di queste modifiche in Security Command Center per facilitare il controllo e la gestione delle modifiche. Ad esempio, Forseti Enforcer può contribuire a verificare l'integrità delle regole firewall, contribuendo a rafforzare la segmentazione della rete.

Google Cloud Armor può fornire maggiore protezione per le tue applicazioni web Google Cloud rivolte al pubblico e aiutarti a rispettare il requisito PCI DSS 6.6. Google Cloud Armor Web Application Firewall (WAF) valuta le richieste in entrata per una serie di attacchi web comuni e può aiutarti a evitare revisioni manuali del codice ad alta intensità di lavoro specificate nel requisito 6.6. La presenza di un WAF consente di mantenere la conformità continua riducendo i costi e i rischi di conformità in corso.

Passaggi successivi