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

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

Comprendere l'ambito della valutazione PCI DSS

Se la tua organizzazione svolge attività commerciali su internet, devi supportare e mantenere la conformità PCI. Il modo in cui progetti e gestisci il tuo ambiente cloud influisce sull'ambito dei tuoi sistemi per la valutazione degli standard di sicurezza dei dati PCI (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 assicurarti che il tuo ambiente PCI sia definito correttamente, devi capire in che modo i tuoi processi aziendali e le decisioni di progettazione influiscono sull'ambito.

Che cos'è l'ambito?

Tutti i sistemi che archiviano, 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 inclusi nell'ambito può causare una violazione dei dati e l'esposizione di dati della carta.

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

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

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 ai dati sanitari personali.

Un sistema è con impatto sulla sicurezza se, in caso di compromissione, può consentire a un malintenzionato di ottenere l'accesso all'ambiente CDE. Tutti i sistemi connessi e che influiscono sulla sicurezza sono sempre inclusi nell'ambito.

I sistemi fuori ambito sono non attendibili per definizione in PCI DSS e non hanno alcun valore per un malintenzionato che vuole ottenere l'accesso ai dati dei titolari di carte o ai dati di autenticazione sensibili (SAD). Un sistema è fuori ambito se non può avere un impatto sulla sicurezza di un sistema incluso nell'ambito, anche se il sistema fuori ambito è compromesso. Sebbene i sistemi non inclusi nell'ambito non vengano valutati direttamente, il Qualified Security Assessor (QSA) PCI verifica che l'ambito sia accurato e protegga i dati della carta secondo lo standard PCI DSS. È quindi importante che i limiti dell'ambito siano protetti in modo efficace, monitorati in modo continuo e approfondito e documentati in modo chiaro.

Connessioni nel contesto PCI

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

Ai fini della valutazione dell'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 a avviare una connessione. Un firewall configurato per consentire il traffico in una sola direzione può imporre una connessione unidirezionale. Ad esempio, un'applicazione di elaborazione dei pagamenti inclusa nell'ambito può eseguire query su un server di database non incluso nell'ambito senza che il server non incluso nell'ambito rientri 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 CDE.
• Il database non può avviare chiamate nel CDE direttamente o indirettamente.
• Il database non fornisce servizi di sicurezza al CDE.
• Il database non influisce sulla configurazione o sulla sicurezza dell'ambiente CDE.
• Il database supporta i requisiti PCI DSS.

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

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

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

  • Sistemi che si trovano nel CDE per i quali una delle seguenti condizioni è vera:
    • Un componente del sistema memorizza, elabora o trasmette dati sanitari protetti o dati sensibili.
    • Un componente di sistema si trova nello stesso segmento di rete, ad esempio nella stessa subnet o VLAN, dei sistemi che archiviano, elaborano o trasmettono i dati della carta.
  • Sistemi connessi o che influiscono sulla sicurezza per i quali una delle seguenti condizioni è vera:
    • Un componente del sistema si connette direttamente al CDE.
    • Un componente di sistema influisce sulla configurazione o sulla sicurezza del CDE.
    • Un componente di sistema segmenta i sistemi CDE da sistemi e reti non inclusi nell'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 di sistema possono essere considerati non attendibili e fuori dall'ambito di PCI DSS quando tutti i seguenti punti sono veri:

  • Un componente del sistema non memorizza, elabora o trasmette dati sanitari protetti o dati sensibili.
  • Un componente di sistema non si trova nello stesso segmento di rete, ad esempio nella stessa subnet o VLAN, dei sistemi che archiviano, elaborano o trasmettono dati della carta o dati sensibili.
  • Un componente di sistema non può connettersi a nessun sistema nel CDE.
  • Un componente di 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 o che influisce sulla sicurezza, in cui sono in vigore controlli per impedire al sistema fuori ambito di accedere all'ambiente CDE utilizzando il componente di sistema in ambito.

In termini pratici, la definizione di ambito del sistema PCI DSS può significare che l'archivio delle 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 inclusi nell'ambito e quelli esclusi:

La Figura 3 mostra le seguenti connessioni:

• Sola lettura:
  • Un'applicazione di elaborazione dei pagamenti inclusa nell'ambito legge legge un ID carrello da un database carrello non incluso nell'ambito e legge i dati da un DNS e un NTP.
• Solo scrittura:
  • Un'applicazione di elaborazione dei pagamenti inclusa nell'ambito scrive nel database principale di un'applicazione non inclusa nell'ambito e in Cloud Logging.
  • L'applicazione web principale non inclusa nell'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 inclusa 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 non inclusa nell'ambito. Questi metadati della richiesta sono un ID sessione che non contiene dati sanitari e dati pubblicitari sensibili.
  • L'applicazione web principale non inclusa nell'ambito legge e scrive dati in un database del carrello, un archivio delle sessioni e un database principale dell'applicazione non inclusi nell'ambito. Questi dati non includono CHD o SAD.
  • Un'applicazione di elaborazione dei pagamenti inclusa nell'ambito legge legge e scrive dati in un servizio di tokenizzazione delle carte incluso nell'ambito legge e in un'azienda di elaborazione dati delle carte di credito sul web pubblico. Questi dati includono CHD e SAD.

L'architettura nella Figura 3 descrive due applicazioni web distinte: l'applicazione web principale (applicazione principale), che non rientra nell'ambito 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 le entità possono essere di sola lettura, di lettura e scrittura o di sola scrittura dal punto di vista del chiamante. Qualsiasi percorso o direzione della richiesta non descritto esplicitamente viene bloccato dalla segmentazione. Ad esempio, l'applicazione di elaborazione dei pagamenti può leggere dal database del carrello e scrivere nel servizio di logging, il che comporta l'avvio di una connessione a queste entità.

I sistemi inclusi nell'ambito chiamano comunemente sistemi e servizi non inclusi nell'ambito. Queste connessioni rimangono sicure perché la segmentazione impedisce a qualsiasi chiamante remoto (diverso dal titolare della carta) di avviare una connessione al CDE direttamente o indirettamente. La figura 3 mostra che l'unico percorso di ingresso all'applicazione di pagamento è quello dell'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 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 un convalidatore 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 di CartID insieme al segreto e confrontando questo valore con CartAuthKey.
3. Una volta autenticati i dati utente, il CartID viene utilizzato per leggere i contenuti del carrello dal database del carrello. Tutti i dati del titolare della carta vengono inviati dall'utente direttamente all'applicazione di pagamento.
4. Se vengono utilizzati profili pagamenti, i dati del titolare della carta vengono memorizzati nel servizio di tokenizzazione.
5. 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

Nella Guida per la definizione dell'ambito e la segmentazione della rete PCI DSS, il PCI Security Standards Council (SSC) consiglia di presumere che tutto sia incluso nell'ambito fino a quando non viene verificato il contrario. Questo consiglio del Centro sicurezza Google non significa che devi rendere il tuo ambito il più ampio possibile. Significa invece 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 impatto sulla sicurezza sul tuo CDE. Per soddisfare i requisiti di conformità normativa e proteggere le tue risorse IT, devi definire l'ambito del tuo ambiente in linea con il principio del privilegio minimo, affidandoti al minor numero possibile di sistemi.

Prima della valutazione, valuta il tuo ambiente per comprendere e documentare il confine tra i sistemi inclusi e non inclusi nell'ambito. Il primo compito del QSA è confermare che l'ambito documentato comprenda 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 quelli inclusi.

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

• Se raccogli i dati dei titolari delle carte telefonicamente o tramite un sistema VOIP, valuta i problemi di definizione dell'ambito aggiuntivi descritti in Protezione dei dati delle carte di pagamento basati su telefono (PDF).
• Se il tuo fornitore di servizi richiede l'accesso al tuo CDE (PDF) per gestire un sistema POS, il sistema utilizzato dal tuo fornitore di servizi potrebbe essere considerato un sistema connesso. Ciò potrebbe richiedere ulteriori considerazioni relative all'ambito e alla due diligence.

Le best practice per la sicurezza di Google possono aiutarti a stabilire e dimostrare un limite chiaro e difendibile tra i sistemi inclusi nell'ambito e quelli non attendibili, il 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 delle carte, a ridurre al minimo la superficie di attacco del tuo CDE e, di conseguenza, a ridurre l'ambito. Quando riduci l'impronta dei sistemi inclusi nell'ambito, contribuisci a ridurre la complessità del sistema e a semplificare la valutazione PCI DSS.

Rischi di una definizione dell'ambito errata

Un ambito eccessivamente ampio può portare a valutazioni costose e a un aumento dei rischi di conformità. Per mantenere un ambito ristretto, considera attendibili il minor numero possibile di sistemi e concedi l'accesso solo a un numero selezionato di utenti designati. Grazie a una valutazione diligente e all'autovalutazione, puoi identificare i sistemi che non devono rientrare nell'ambito del 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 influire sui 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 della valutazione. Se includi sistemi estranei nel tuo ambito, ciò comporta rischi per la tua capacità di raggiungere la conformità. Può anche peggiorare il tuo livello di sicurezza complessivo ampliando la superficie di attacco del tuo ambiente attendibile incluso nell'ambito.

Un principio fondamentale della sicurezza di rete e del PCI DSS è presumere che una parte o tutta la rete sia già stata compromessa. Questo principio è sancito dal modello di sicurezza Zero Trust di Google, che rifiuta la sicurezza basata solo sul perimetro a favore di un modello in cui ogni sistema è responsabile della propria sicurezza. Il modello di sicurezza di Google è in linea con PCI DSS, che consiglia di implementare il CDE e i relativi sistemi connessi in uno spazio piccolo e affidabile segmentato dal tuo ambiente IT più ampio e non interconnesso.

All'interno dell'ambiente PCI incluso nell'ambito, non posizionare il CDE in uno spazio ampio e attendibile con un perimetro ampio. In questo modo, si può creare un falso senso di sicurezza e minare una strategia di difesa in profondità olistica. Se un utente malintenzionato viola la sicurezza perimetrale, può operare facilmente all'interno di una rete intranet privata e attendibile. Valuta i modi in cui puoi rafforzare lo spazio attendibile in modo che contenga solo ciò che serve per operare e proteggersi ed evita di fare affidamento esclusivamente sulla sicurezza perimetrale. Se comprendi e segui questi principi, puoi progettare il tuo ambiente cloud per proteggere i tuoi sistemi critici e ridurre il rischio di contaminazione da sistemi compromessi.

Un ambiente di sistemi attendibili di grandi dimensioni e inclusi nell'ambito richiede un apparato di gestione altrettanto grande per mantenere il monitoraggio continuo, la manutenzione, l'audit e l'inventario di questi sistemi. La complessità dell'architettura del sistema, dei processi di gestione delle modifiche e delle norme di controllo dell'accesso può creare rischi per la sicurezza e la conformità. La difficoltà nel mantenere 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 la sezione Supportare la conformità continua più avanti in questo documento.

ServiziGoogle Cloud nell'ambito della conformità PCI DSS

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

Strategie per ridurre l'ambito

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

Non esiste una soluzione universale per la definizione dell'ambito PCI. Potresti avere una segmentazione esistente in una rete on-premise o una soluzione di elaborazione delle carte che può far sì che la progettazione dell'infrastruttura appaia leggermente diversa da quella descritta qui. Utilizza queste strategie come principi da applicare al tuo ambiente.

Stabilisci i controlli della gerarchia delle risorse

Le risorseGoogle Cloud sono organizzate in modo gerarchico come segue:

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

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

Nella figura 4, tutti i progetti inclusi nell'ambito PCI sono raggruppati in una singola cartella per l'isolamento a livello di cartella. La cartella con ambito PCI contiene l'ambiente CDE e un altro progetto che contiene servizi condivisi. Quando implementi una gerarchia delle risorse simile, la cartella con ambito PCI forma una radice logica dell'ambito di conformità PCI. Se ti assicuri 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 necessità, ti assicuri che solo gli utenti designati abbiano accesso ai componenti inclusi nell'ambito. Ciò supporta i requisiti PCI DSS 7.2 e 7.3 (PDF) e altri. Per assicurarti che le autorizzazioni per l'organizzazione e le cartelle principali siano impostate correttamente, comprendi le implicazioni dell'ereditarietà dei criteri. Per supportare il requisito 8.4.1 di PCI DSS, assicurati di applicare l'autenticazione a più fattori (MFA) per gli utenti designati e consulta il supplemento PCI DSS sulle indicazioni per l'autenticazione a più fattori (PDF). Per garantire la conformità nella gerarchia delle risorse, assicurati di comprendere come impostare i vincoli delle policy dell'organizzazione. Questi vincoli supportano la conformità continua e possono contribuire a proteggere gli ambienti attendibili dall'escalation dei privilegi.

Come per tutta la conformità PCI, per stabilire un limite di ambito chiaro sono necessari la registrazione e il monitoraggio adeguati del tuo ambiente e dei suoi componenti inclusi nell'ambito. La gerarchia delle risorse è indissolubilmente legata alla gestione dell'identità e dell'accesso e un logging, un controllo e un monitoraggio efficaci delle azioni degli utenti sono necessari per applicare e mantenere la separazione.

Implementa la segmentazione della rete

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

Per implementare la segmentazione della rete, inserisci il tuo 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 attivare 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 che possa essere sottoposto a peering solo con altre reti attendibili.

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

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

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

• Gli spazi dei nomi offrono un ulteriore livello di isolamento del controllo dell'accesso dell'accesso, in base al quale agli utenti può essere concesso l'accesso solo a determinati pod, servizi e deployment all'interno del cluster Kubernetes. Ciò è 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 di rete all'interno del cluster.
• PodSecurity è un controller di ammissione Kubernetes che ti consente di applicare gli standard di sicurezza dei pod ai pod in esecuzione sul tuo cluster GKE.

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

Implementare la tokenizzazione

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

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

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

Nella figura 6, l'utente riceve un PAN e altri dati del titolare della carta, quindi i dati vengono inviati immediatamente al servizio di tokenizzazione. Il servizio di tokenizzazione cripta il PAN, genera un token e li memorizza entrambi in un vault di token sicuro. Solo i servizi designati, come il servizio di compensazione, possono accedere alla cassaforte sulla rete e sono autorizzati a utilizzare un PAN utilizzando un token generato. Il servizio di compensazione utilizza il PAN solo per inviarlo al responsabile del trattamento dei pagamenti. Il PAN e altri dati del titolare della carta non vengono mai visualizzati al di fuori di questo flusso di dati strettamente controllato. Nell'ambito di una strategia di difesa in profondità, l'architettura utilizza anche Sensitive Data Protection come ulteriore livello di difesa contro la divulgazione involontaria di PAN o altri dati del titolare della carta.

Nella Figura 6, il sistema di tokenizzazione utilizza Hashicorp Vault, un archivio dei secret protetto, per gestire le mappature PAN-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 token vault può essere concesso un accesso con limiti di tempo, in modo che il componente possa utilizzare un PAN solo durante il periodo di tempo specifico necessario per svolgere la sua funzione. Anche altri datastore possono essere adatti, a seconda dei requisiti 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 e l'archiviazione dei record delle transazioni tokenizzate in Spanner.

Nella Figura 7, il progetto di elaborazione delle transazioni è un sistema connected-to ed è incluso nell'ambito PCI. Non è rilevante per la sicurezza, perché la compromissione di qualsiasi componente nel progetto di elaborazione delle transazioni non può fornire a un malintenzionato l'accesso ai dati della carta. 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 dal CDE a Pub/Sub. Prima che i dati tokenizzati vengano pubblicati per altri abbonati, Sensitive Data Protection verifica che non contengano dati della carta. 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à non sono solo architettura corretta e buona ingegneria. Un'architettura corretta può dimostrare che il tuo ambiente è progettato in modo sicuro in teoria. Hai anche bisogno di processi efficaci di controllo, registrazione, monitoraggio e correzione per contribuire a garantire che il tuo ambiente rimanga sicuro in pratica.

Per supportare la conformità a ciascuna delle 12 categorie di requisiti PCI DSS, devi monitorare l'implementazione di ogni requisito su base continuativa. Devi dimostrare a te stesso e al tuo valutatore che qualsiasi componente incluso nell'ambito rimarrà sicuro in futuro, molto tempo dopo il completamento della valutazione PCI DSS. Una supervisione adeguata, unita a un'azione di correzione rapida, è chiamata conformità continua. La conformità continua è un requisito di 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 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 aiuta a rispettare il requisito 10.4 dello standard PCI DSS e ti consente di rispondere e correggere rapidamente le potenziali minacce alla sicurezza. Per maggiori informazioni, consulta il supplemento PCI DSS sul monitoraggio efficace dei log giornalieri (PDF).

Security Command Center consente di comprendere la superficie di attacco di dati e sicurezza fornendo servizi di individuazione, ricerca, gestione e inventario degli asset. Security Command Center può analizzare i risultati della scansione Sensitive Data Protection per identificare i dati dei titolari delle carte compromessi e verificare che il tuo sistema di tokenizzazione non venga utilizzato in modo improprio per riscattare i PAN in modo dannoso. 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, il che potrebbe indicare che un malintenzionato potrebbe sondare il tuo sistema per identificare le sue capacità difensive. Security Command Center ti consente anche di creare origini di sicurezza personalizzate specifiche per il tuo ambiente.

Google Cloud Armor può fornire una protezione aggiuntiva per le tue applicazioni web Google Cloud pubbliche e aiutarti a rispettare il requisito 6.4 del PCI DSS. Cloud Armor valuta le richieste in entrata per una serie di attacchi web comuni e può aiutarti a evitare le revisioni manuali del codice che richiedono molto lavoro specificate nel requisito 6.4. Un WAF ti aiuta a mantenere la conformità continua riducendo i costi e i rischi di conformità in corso.

Passaggi successivi

• Consulta le best practice per la gestione degli obblighi di conformità.
• Leggi Conformità agli standard di sicurezza dei dati PCI su Google Cloud.
• Guida del PCI Council per la definizione dell'ambito PCI DSS e la segmentazione della rete (PDF).
• Prova il progetto PCI su GKE.
• Proteggi i tuoi workload Kubernetes per PCI DSS.
• Tokenizzazione dei dati sensibili dei titolari di carte per PCI DSS.
• Esegui il deployment del progetto Terraform iniziale PCI.
• Esplora architetture, diagrammi e best practice di riferimento su Google Cloud. Consulta il nostro Cloud Architecture Center.