Questo documento descrive le best practice per progettare l'ambiente cloud della Payment Card Industry (PCI) Security Standards Council conformità. Queste best practice sono utili per le organizzazioni che eseguono la migrazione o progettano sistemi nel cloud soggetti ai requisiti di conformità PCI. Questo documento fa riferimento ai requisiti PCI DSS 4.0, ove applicabili.
Comprensione dell'ambito della valutazione PCI DSS
Se la tua organizzazione si occupa di commercio su internet, devi supportare e mantenere la conformità PCI. Il modo in cui progetti e gestisci il tuo ambiente cloud influisce sull'ambito dei tuoi sistemi per la valutazione del PCI Data Security Standard (DSS). La definizione dell'ambito ha importanti implicazioni per la sicurezza dell'IT asset e la capacità di supportare e mantenere la conformità PCI. Per garantire che l'ambiente PCI sia limitato in modo corretto, è necessario capire come i processi aziendali e le decisioni di progettazione influiscono sull'ambito di applicazione.
Che cos'è l'ambito?
Tutti i sistemi che archiviano, elaborano o trasmettono i dati dei titolari di carte (CHD) rientrano nell'ambito della valutazione PCI DSS. La sicurezza è importante per l'intero cloud dell'ambiente circostante, ma la compromissione dei sistemi interessati può causare una violazione dei dati di esposizione di CHD.
Nella Figura 1, l'ambiente dei dati del titolare della carta (CDE), i sistemi connessi e che i sistemi che influiscono sulla sicurezza rientrano nei confini dell'ambito della valutazione, i sistemi non attendibili e fuori ambito non rientrano nel limite dell'ambito della valutazione.
Secondo lo standard PCI DSS, i sistemi inclusi nell'ambito sono attendibili. I sistemi inclusi nell'ambito includono la tua CDE e qualsiasi sistema connesso o che potrebbe influire sulla sicurezza della tua CDE.
Un sistema è collegato se si trova sulla stessa rete, condivide database o archiviazione di file o ha accesso o connettività a qualsiasi sistema o processo che si trova all'interno del CDE, ma non ha accesso diretto al CHD.
Un sistema ha impatto sulla sicurezza se, in caso di compromissione, può consentire a un malintenzionato di accedere al CDE. Tutti i sistemi connessi e che hanno un impatto sulla sicurezza sono sempre in ambito.
I sistemi non inclusi nell'ambito sono non attendibili per definizione nei PCI DSS e non hanno alcun valore per un malintenzionato che vuole ottenere l'accesso a CHD o a dati di autenticazione sensibili (SAD). Un sistema è fuori ambito se non può influire sulla sicurezza un sistema incluso nell'ambito, anche se quest'ultimo viene compromesso. Mentre sistemi fuori ambito non vengono valutati direttamente, Qualificatore della sicurezza PCI (QSA) verifica che la definizione dell'ambito sia accurata e protegge il CHD secondo lo standard PCI DSS. È quindi importante che i confini dell'ambito siano fortemente protetti, monitorati continuamente e in modo approfondito e documentati chiaramente.
Connessioni nel contesto PCI
Diversi requisiti PCI DSS fanno riferimento alle connessioni, ma il PCI DSS non le definisce esplicitamente. Per interpretare il significato delle connessioni in questo contesto, la struttura decisionale dell'ambito Linee 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 dalla seguenti:
- 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 la parte autorizzata a avviare una connessione. Un firewall configurato per consentire solo il traffico in una direzione può applicare una connessione unidirezionale. Ad esempio, un'applicazione di elaborazione dei pagamenti in ambito può eseguire query su un server di database fuori ambito senza che il server fuori ambito entri nell'ambito se si verificano tutte le condizioni seguenti:
- La connessione e il database fuori ambito non archiviano, elaborano o trasmettono CHD o SAD.
- Il database si trova su una rete separata o è comunque separato dal CDE.
- Il database non può avviare chiamate al CDE direttamente o indirettamente.
- Il database non fornisce servizi di sicurezza al CDE.
- Il database non influisce sulla configurazione o sulla sicurezza del CDE.
- Il database supporta i requisiti PCI DSS.
Il seguente diagramma mostra i fattori che determinano l'ambito del sistema:
Nella Figura 2, l'ambito del sistema è determinato come segue:
Componenti di sistema che rientrano nell'ambito di PCI DSS:
- Sistemi che si trovano nel CDE per i quali è vera una di queste condizioni:
- Un componente di sistema memorizza, elabora o trasmette CHD o SAD.
- Un componente di sistema si trova nello stesso segmento di rete, ad esempio nella stessa subnet o VLAN, dei sistemi che archiviano, elaborano o trasmettono i dati sanitari sensibili.
- Sistemi collegati o che influiscono sulla sicurezza per i quali è vera una di queste condizioni:
- Un componente del sistema si connette direttamente a CDE.
- Un componente di sistema influisce sulla configurazione o sulla sicurezza del CDE.
- Un componente di sistema separa i sistemi CDE da reti e sistemi non coperti.
- Un componente di sistema si connette indirettamente al CDE.
- Un componente di sistema fornisce servizi di sicurezza al CDE.
- Un componente di sistema supporta i requisiti PCI DSS.
- Sistemi che si trovano nel CDE per i quali è vera una di queste condizioni:
I componenti di sistema possono essere considerati non attendibili e non rientrano nell'ambito di PCI DSS quando tutte le seguenti condizioni sono vere:
- Un componente di sistema non memorizza, elabora o trasmette CHD o SAD.
- Un componente di sistema non è lo stesso segmento di rete, ad esempio nel sulla stessa subnet o VLAN, ossia dei sistemi che archiviano, elaborano o trasmettono CHD o TRISTE.
- Un componente di sistema non può connettersi ad alcun sistema nel CDE.
- Un componente di sistema non soddisfa nessun criterio per sistemi che influiscono sulla sicurezza.
I sistemi fuori ambito possono includere sistemi che si connettono a un componente del sistema che incide sulla sicurezza, in cui sono in atto dei controlli per prevenire al sistema fuori ambito di ottenere l'accesso al CDE utilizzando componente di sistema.
In termini pratici, la definizione di ambito di sistema del PCI DSS può significare che il database di e-commerce e l'area di archiviazione delle sessioni dell'applicazione web potrebbero essere considerati al di fuori dell'ambito se la segmentazione è implementata e documentata correttamente. Il seguente diagramma mostra il funzionamento delle connessioni di lettura e scrittura tra i sistemi inclusi nel campo di applicazione e quelli non inclusi:
La figura 3 mostra le seguenti connessioni:
- Sola lettura:
- Un'applicazione di elaborazione dei pagamenti in ambito legge un ID carrello da un database di carrelli fuori ambito e legge i dati da DNS e NTP.
- Solo scrittura:
- Un'applicazione di elaborazione dei pagamenti all'interno dell'ambito scrive in una posizione che non rientra nell'ambito dell'applicazione nel database principale dell'applicazione e in Cloud Logging.
- L'applicazione web principale fuori ambito scrive i dati in un servizio di registrazione. Questi dati non includono le malattie coronariche o la sindrome di Alzheimer.
- Lettura e scrittura:
- Un utente sul web pubblico legge e scrive i metadati delle richieste come segue:
- L'utente legge e scrive su un'elaborazione dei pagamenti nell'ambito un'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 non inclusa nell'ambito. Questi metadati di richiesta sono un ID sessione che non contiene CHD o TRISTE.
- L'applicazione web principale fuori ambito legge e scrive dati in un database del carrello, in un archivio sessioni e nel database principale dell'applicazione fuori ambito. Questi dati non includono CHD o SAD.
- Un'applicazione di elaborazione dei pagamenti in ambito legge e scrive i dati in un servizio di tokenizzazione delle carte in ambito e in un elaboratore di carte di credito sul web pubblico. Questi dati includono le malattie coronariche e la depressione stagionale.
- Un utente sul web pubblico legge e scrive i metadati delle richieste come segue:
L'architettura in figura 3 descrive due applicazioni web distinte: l'applicazione web principale (applicazione principale), che non rientra nell'ambito del PCI, e l'applicazione di elaborazione dei pagamenti (applicazione di pagamento), che rientra nell'ambito. Nella questa architettura, una connessione può essere avviata tra due entità solo in le istruzioni nell'elenco precedente. Le connessioni tra entità possono essere di sola lettura, di lettura e scrittura o di sola scrittura dal punto di vista dell'utente chiamante. Qualsiasi percorso o direzione della richiesta non descritto esplicitamente viene bloccato dalla segmentazione. Ad esempio, l'applicazione di elaborazione dei pagamenti può leggere dal database del carrello e scrivere nel servizio di registrazione, il che comporta l'avvio di una connessione a queste entità.
I sistemi che rientrano nell'ambito richiamano comunemente sistemi e servizi fuori dall'ambito. Queste collegamenti rimangono sicuri perché la segmentazione impedisce a qualsiasi chiamante remoto (diverso da un titolare della carta) di avviare una connessione al CDE direttamente o indirettamente. La Figura 3 mostra che l'unico percorso di accesso all'applicazione di pagamento proviene dall'utente.
Nella Figura 3, nessun servizio o applicazione fuori ambito fornisce alcuna configurazione o dati di sicurezza all'applicazione di elaborazione dei pagamenti. I dati passano attraverso dell'architettura come segue:
- L'applicazione principale inoltra l'utente all'applicazione di pagamento e utilizza un
POSTHTTP per trasmettere ilCartIDe un validatore chiamatoCartAuthKey.CartAuthKeyè un hash diCartIDe una secret pre-condivisa nota solo alle applicazioni principali e di pagamento. - L'applicazione di pagamento convalida l'utente sottoponendo ad hashing il
CartIDinsieme al segreto e confrontando il valore con ilCartAuthKey. - Dopo l'autenticazione dei dati utente,
CartIDviene 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. - Se vengono utilizzati profili pagamenti, i dati del titolare della carta vengono memorizzati nel servizio di tokenizzazione.
- Dopo l'elaborazione del pagamento, il risultato viene inserito nel database dell'applicazione principale con un account servizio database di sola scrittura.
Considerazioni sull'ambito
Nella guida "Guidance for PCI DSS scopeting and network segmentare", il team Standards Council (SSC) consiglia di dare per scontato che tutto rientri nell'ambito fino alla verifica altrimenti. Questo consiglio del Centro assistenza sui prodotti non significa che devi ampliare l'ambito il più possibile. Significa piuttosto che il QSA valuta tutti i sistemi come se fossero attendibili, a meno che tu non possa dimostrare che un sistema non ha connettività con il tuo CDE o non ha impatto sulla sicurezza. Per soddisfare la conformità normativa requisiti e mantenere al sicuro le risorse IT, è necessario definire l'ambito in linea con principio del privilegio minimo confidando in un numero ridotto di sistemi il più possibile.
Prima della valutazione, valuta il tuo ambiente per comprendere e documentare il confine tra i sistemi inclusi e non inclusi nell'ambito. Il primo compito dell'QSA è verificare che l'ambito documentato inglobi ragionevolmente il CDE e i sistemi collegati. Nell'ambito della valutazione complessiva, il QSA verifica i sistemi fuori ambito non possono influire negativamente su alcun sistema all'interno dell'ambito.
Assicurati di comprendere le circostanze particolari specifiche di il tuo ambiente, ad esempio:
- Se raccogli i dati dei titolari della carta per telefono o tramite un sistema VoIP, considerare gli altri problemi di definizione dell'ambito descritti in Protezione dei dati delle carte di pagamento tramite telefono (PDF).
- Se il tuo fornitore di servizi richiede l'accesso al tuo file CDE (PDF) per gestire un sistema point of sale, allora il sistema che il tuo il fornitore di servizi di telefonia mobile può essere considerato un sistema connesso a internet. Ciò potrebbe richiedere ulteriori considerazioni di ambito e due diligence.
Le best practice di sicurezza di Google possono aiutarti a stabilire e dimostrare un confine chiaro e difendibile tra i sistemi inclusi nell'ambito e quelli non attendibili, che ti aiuteranno nella valutazione. Quando gestisci l'accesso e la sicurezza l'applicazione del principio del privilegio minimo, si contribuisce a ridurre al minimo il numero di punti di esposizione per i dati del titolare della carta, la superficie di attacco del tuo CDE e di conseguenza riduci l'ambito. Quando a ridurre l'ingombro dei sistemi nell'ambito, si contribuisce a ridurre la complessità del sistema e la valutazione PCI DSS.
Rischi di errata definizione dell'ambito
Un ambito eccessivamente ampio può comportare valutazioni costose e maggiori rischi di conformità. Per limitare l'ambito, affidati al minor numero di sistemi possibile e concedi solo a pochi utenti selezionati. Attraverso valutazioni e autovalutazioni scrupolose, puoi identificare i sistemi che non rientrano nell'ambito del PCI DSS, verificare che soddisfino le linee guida per i sistemi non inclusi nell'ambito e ridurre di conseguenza l'ambito. Questo processo di eliminazione è il modo più sicuro per scoprire quali sistemi non sono attendibili e contribuiscono ad assicurare che non possano all'interno dell'ambito di applicazioni.
Se hai bisogno di un'infrastruttura di grandi dimensioni per soddisfare i requisiti PCI DSS, è possibile che nell'ambito della valutazione vengano inclusi sistemi estranei. Se includi sistemi estranei nell'ambito, rischi di non riuscire a garantire la conformità. Inoltre, può peggiorare la tua security posture generale l’ampliamento della superficie di attacco dell’ambiente di applicazione affidabile.
Un principio fondamentale della sicurezza di rete e dei PCI DSS è presupporre che parte o tutta la rete sia già stata compromessa. Questo principio è sancito di Google modello di sicurezza Zero Trust, che respinge la sicurezza solo perimetrale in favore di un modello in cui ogni sistema responsabile della sua sicurezza. Il modello di sicurezza di Google è in linea con il PCI DSS, che consiglia di implementare il CDE e i relativi sistemi collegati in un piccolo spazio attendibile separato dall'ambiente IT più ampio e non mescolati con esso.
All'interno del tuo ambiente PCI ambito, non posizionare il tuo CDE in uno spazio grande e attendibile con un perimetro ampio. Ciò può creare un falso senso di sicurezza e minare una strategia olistica di difesa in profondità. Se un utente malintenzionato viola la sicurezza del perimetro, può operare facilmente all'interno di un'intranet privata attendibile. Valuta i modi in cui puoi rafforzare lo spazio attendibile in modo che contenga solo ciò che è necessario per il suo funzionamento e la sua protezione ed evita di fare affidamento esclusivamente sulla sicurezza perimetrale. Comprendendo e seguendo questi principi, puoi progettare il tuo ambiente cloud per proteggere i tuoi sistemi critici e ridurre il rischio di contaminazione da sistemi compromessi.
Un ambiente di sistemi attendibili di grandi dimensioni e ambito richiede un apparato di gestione altrettanto grande per mantenere il monitoraggio, la manutenzione, il controllo e l'inventario continui di questi sistemi. La complessità dell'architettura di sistema, delle procedure di gestione del cambiamento e dei criteri di controllo dell'accesso può creare rischi per la sicurezza e la conformità. La difficoltà nel mantenere questi processi di monitoraggio può alle 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.
Servizi Google Cloud che rientrano nell'ambito di PCI DSS
Prima di iniziare a ridurre l'ambito del tuo ambiente PCI, comprendi quali servizi Google Cloud rientrano nell'ambito di PCI DSS. Questi servizi forniscono l'infrastruttura su cui puoi creare un tuo servizio o un'applicazione che archivi, elabori o trasmetta i dati dei titolari di carte.
Strategie per ridurre l'ambito
Questa sezione illustra le seguenti strategie per ridurre l'ambito della valutazione: controlli della gerarchia delle risorse, Controlli di servizio VPC segmentazione e tokenizzazione. Anziché scegliere un approccio, valuta la possibilità di impiegare tutte queste strategie per massimizzare la potenziale riduzione dell'ambito.
Non esiste una soluzione universale per la definizione dell'ambito PCI. Potresti avere account segmentazione in una rete on-premise o una soluzione per l'elaborazione delle carte che possono far sì che la progettazione della tua infrastruttura abbia un aspetto descritti qui. Utilizza queste strategie come principi da applicare ai tuoi un ambiente completamente nuovo.
Stabilisci controlli della gerarchia delle risorse
Le risorse Google Cloud sono organizzate in modo gerarchico come segue:
- La Organizzazione è il nodo radice della gerarchia di risorse Google Cloud. Le risorse dell'organizzazione contengono risorse di cartelle e progetti. Identity and Access Management (IAM) si applicano i criteri di controllo dell'accesso applicati alla risorsa Organizzazione della 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 spesso utilizzate per raggruppare progetti simili.
- I progetti rappresentano un confine di attendibilità per tutte le tue risorse e sono un punto di applicazione di IAM.
Per ridurre l'ambito della valutazione, segui le best practice di Google per: definire la gerarchia delle risorse. L'immagine seguente mostra un esempio di gerarchia delle risorse per la conformità PCI:
Nella figura 4, tutti i progetti che rientrano nell'ambito PCI sono raggruppati in un per isolare a livello di cartella. La cartella con ambito PCI contiene il CDE e un altro progetto che contiene servizi condivisi. Quando implementi un modello simile gerarchia delle risorse, la cartella con ambito PCI costituisce una radice logica del nell'ambito della conformità. Assicurati che solo gli utenti designati abbiano accesso a questa cartella e ai relativi progetti, in modo da escludere altre cartelle, progetti e risorse nella gerarchia dall'ambito della valutazione.
Quando concedi agli utenti l'accesso solo alle cartelle e ai progetti di cui hanno bisogno, assicuri che solo gli utenti designati abbiano accesso ai componenti inclusi nell'ambito. Questo supporta Requisiti PCI DSS 7.2 e 7.3 (PDF). e altri. Per assicurarti che le autorizzazioni per l'organizzazione principale e siano impostate correttamente, tieni presente implicazioni dell'ereditarietà dei criteri. Per supportare il Requisito 8.4.1 del PCI DSS, assicurati di applicare l'autenticazione a più fattori (MFA) per gli utenti designati e consulta il supplemento del PCI DSS sulle indicazioni per l'autenticazione a più fattori (PDF). Per applicare la conformità nella gerarchia delle risorse, assicurati di comprendere come impostare i vincoli dei criteri dell'organizzazione. Questi vincoli supportano la conformità continua e possono contribuire a proteggere i tuoi ambienti attendibili dall'escalation dei privilegi.
Come per tutta la conformità PCI, un adeguato logging e monitoraggio dell’ambiente e i relativi componenti di ambito sono necessari per stabilire un confine chiaro dell'ambito. La gerarchia delle risorse è indissolubilmente legata alla gestione dell'identità e dell'accesso e sono necessari registrazioni, controlli e monitoraggio efficaci delle azioni degli utenti per applicare e mantenere la separazione.
Implementazione della segmentazione della rete
La segmentazione della rete è un importante modello di architettura che contribuisce a proteggere CDE e sistemi connessi, come descritto nella documentazione supplementare PCI SSC guida alla segmentazione della rete (PDF). Se implementata correttamente, la segmentazione della rete restringe l'ambito della valutazione rimuovendo i percorsi di rete che i sistemi non attendibili potrebbero utilizzare per accedere al tuo CDE o ai suoi componenti connessi. Definisci solo le route necessarie per consentire la comunicazione tra i componenti attendibili. Se i sistemi non sono attendibili non hanno una route per inviare o ricevere pacchetti dai sistemi attendibili, sistemi non attendibili non rientrano nell'ambito e non possono influire sulla sicurezza del tuo all'interno dell'ambito.
Per implementare la segmentazione della rete, posiziona il tuo CDE in una Virtual Private Cloud (VPC) con Controlli di servizio VPC in un bucket in cui è abilitato il controllo delle versioni. 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 può essere connesso in peering solo con altre reti attendibili.
Il seguente diagramma mostra la correlazione tra la tua strategia di segmentazione della rete molto vicino alla gerarchia delle risorse. Questo diagramma presuppone una gerarchia delle risorse con una singola cartella per l'ambiente PCI ambito e due progetti in quella cartella per il CDE e i servizi condivisi.
Nella figura 5, il progetto di servizi condivisi non fa parte del CDE, ma è un sistema collegato e pertanto rientra nell'ambito di PCI. L'accesso al CDE è limitato a livello di rete dal bilanciatore del carico e dalle regole firewall o dai criteri firewall per proteggere queste reti e soddisfare i requisiti PCI DSS 1.2 e 1.3. Il sistema di tokenizzazione e il sistema di pagamento sono posizionati in subnet separate e la loro comunicazione è regolata da regole firewall tra ogni subnet per consentire solo le comunicazioni necessarie. Il logging, il monitoraggio e gli avvisi necessari funzioni che soddisfano Requisiti PCI DSS 10.2, 10.4 e 10.5 in un progetto separato. I servizi condivisi e la CDE si trovano all'interno di un perimetro di sicurezza dei Controlli di servizio VPC per proteggersi da configurazioni errate accidentali o compromissione dei controlli di accesso IAM.
Se il deployment è attivo Google Kubernetes Engine (GKE) Di seguito sono riportati altri modi per segmentare il tuo CDE e proteggere il titolare della carta Dati provenienti da sistemi non attendibili:
- Spazi dei nomi offrono un ulteriore livello di isolamento controllo dell'accesso tramite il quale gli utenti possono solo a determinati pod, servizi e deployment in un cluster Kubernetes. Questo è utile per fornire un accesso più granulare agli utenti designati.
- I criteri di rete possono isolare i pod e i servizi tra loro per limitare i flussi di dati e possono fornire un ulteriore livello di segmentazione della rete all'interno del cluster.
- PodSecurity è un controller di ammissione Kubernetes che ti consente di applicare gli standard di sicurezza dei pod ai pod in esecuzione su GKE. in un cluster Kubernetes.
Ciascuno di questi livelli costituisce una parte importante della tua strategia di sicurezza difensiva e ti aiuta a restringere l'ambito isolando e proteggendo ulteriormente i componenti attendibili dall'ambiente circostante. Se esegui il deployment di tutto o di parte del tuo CDE con Kubernetes, scopri di più su come eseguire il tuo ambiente conforme a PCI su GKE.
Implementare la tokenizzazione
La tokenizzazione è il processo di oscuramento irreversibile di un numero di conto bancario principale (PAN). Un PAN tokenizzato o token non può essere utilizzato per un PAN tramite metodi matematici. Il PCI SSC offre indicazioni sull'impatto dell'ambito della tokenizzazione nel Capitolo 3 del supplemento alle linee guida sulla tokenizzazione (PDF). L'ambito PCI DSS è fortemente influenzato dalla serie di componenti che archiviano e trasmettere i dati del titolare della carta. Se implementata correttamente, la tokenizzazione può contribuire a ridurre l'ambito della valutazione riducendo al minimo l'occorrenza e la trasmissione dei numeri di conto principali.
La tokenizzazione è anche una forma di segmentazione per flusso di dati, poiché separa sistemi che memorizzano e trasmettono i dati dei titolari delle carte da quelli che possono effettuare le operazioni usando solo token. Ad esempio, i sistemi che analizzano i dati l'attività fraudolenta potrebbe non aver bisogno di PAN, ma può eseguire queste analisi mediante 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, il web potrebbe essere potenzialmente rimossa dall'insieme di sistemi connessi, riducendo così l'ambito.
Il seguente diagramma mostra come vengono gestiti i dati CHD, PAN e tokenizzati in un tipico sistema di tokenizzazione:
Nella figura 6, un PAN e altri dati del titolare della carta vengono ricevuti dall'utente, quindi vengono inviati immediatamente al servizio di tokenizzazione. La tokenizzazione cripta il PAN, genera un token e quindi li archivia entrambi in un l'archiviazione protetta dei token. Solo i servizi designati, come il servizio di liquidazione, possono accedere alla cassaforte sulla rete e avere l'autorizzazione a richiedere un PAN utilizzando un il token generato. Il servizio di liquidazione utilizza il PAN solo per inviarlo al elaboratore dei pagamenti. Né il PAN né altri dati del titolare della carta vengono mai visualizzati al di fuori di questo flusso di dati strettamente controllato. Nell'ambito di un sistema di difesa in profondità l'architettura usa anche Protezione dei dati sensibili come ulteriore livello di difesa contro la fuoriuscita involontaria di PAN o altri dati del titolare della carta.
Nella Figura 6, il sistema di tokenizzazione utilizza vault di hashicorp un archivio protetto di segreti, per gestire le mappature PAN-to-token. Solo gli utenti e i servizi autorizzati possono utilizzare un token per riscattare un PAN tramite una procedura di ricerca. È possibile fornire i componenti autorizzati ad accedere all'archivio dei token accesso a tempo limitato in modo che il componente possa utilizzare solo un PAN durante di un intervallo di tempo specifico di cui ha bisogno per svolgere la sua funzione. Anche altri datastore possono essere appropriati, a seconda dei requisiti della tua attività.
Architettura di esempio
Il seguente diagramma mostra un'architettura di esempio per l'elaborazione delle transazioni tokenizzate utilizzando Pub/Sub e Dataflow, nonché per l'archiviazione dei record delle transazioni tokenizzate in Spanner.
Nella figura 7, il progetto di elaborazione delle transazioni è un sistema collegato ed rientra nell'ambito del PCI. Non ha un impatto sulla sicurezza, perché la compromissione di qualsiasi del progetto di elaborazione delle transazioni non può fornire a un utente malintenzionato l'accesso a CHD. Il progetto dell'app web non rientra nell'ambito perché non si connette CDE e interagisce solo con dati sanitizzati.
I dati tokenizzati vengono inviati da CDE a Pub/Sub. Prima che i dati tokenizzati vengano pubblicati per altri abbonati, la funzionalità Protezione dei dati sensibili verifica che non contengano CHD. I dati tokenizzati vengono elaborati da Dataflow e archiviati nel database delle transazioni Spanner. Le transazioni possono essere associate a utenti specifici tramite token senza che accede ai PAN. Il database delle transazioni di Spanner può essere usato anche per il reporting e l'analisi utilizzando strumenti di business intelligence (BI) come Looker.
Supporto della conformità continua
Sicurezza e conformità sono più che un'architettura corretta e una buona progettazione. Un'architettura corretta può indicare che il tuo ambiente è progettato in modo sicuro in dell'IA. Hai anche bisogno di controlli, logging, monitoraggio e correzione efficaci per garantire la sicurezza dell'ambiente in pratica.
Per supportare la conformità con ciascuna delle 12 categorie di requisiti PCI DSS, è necessario devi monitorare costantemente l'implementazione di questo requisito. Tu Deve dimostrare a te stesso e al responsabile della valutazione che qualsiasi componente incluso nell'ambito rimarrà invariato sicura in futuro, molto tempo dopo il completamento della valutazione PCI DSS. La supervisione corretta abbinata a un'azione di correzione rapida è chiamata conformità continua. La conformità continua è un requisito del PCI DSS e, se implementata correttamente, può contribuire a massimizzare l'effetto delle altre strategie di riduzione dell'ambito.
Google Cloud ti consente di registrare tutto ciò che accade nella tua rete utilizzando il Logging delle regole firewall, i log di flusso VPC, i log di VPC Service Controls e i log di Cloud Load Balancing. Puoi monitorare l'attività dei tuoi sistemi e utenti utilizzando: Audit log di Cloud. Il monitoraggio regolare di questi log ti consente di rispettare le Requisito PCI DSS 10.4 e consente di rispondere rapidamente a potenziali minacce alla sicurezza e di porre rimedio. Per ulteriori informazioni, consulta Integratore PCI DSS sul monitoraggio giornaliero efficace dei log (PDF).
Security Command Center ti consente di comprendere la tua superficie di attacco per dati e sicurezza fornendo servizi di individuazione, ricerca, gestione e inventario degli asset. Security Command Center può analizzare Protezione dei dati sensibili analizzare i risultati per identificare i dati del titolare della carta divulgati e verificare che il sistema di tokenizzazione non sia utilizzato in modo improprio per riscattare in modo fraudolento i PAN. Utilizzo Event Threat Detection, Security Command Center può aiutarti a rilevare in modo proattivo le minacce e le attività insolite sulla tua rete e nelle tue VM, il che potrebbe indicare che un utente malintenzionato sondare il sistema per identificarne le capacità difensive. Security Command Center ti consente anche creare origini di sicurezza personalizzate specifiche per il tuo ambiente.
Google Cloud Armor può fornire una protezione aggiuntiva per le tue applicazioni web Google Cloud rivolte al pubblico e aiutarti a rispettare il requisito 6.4 del PCI DSS. Google Cloud Armor valuta le richieste in entrata per una serie di attacchi web comuni consentono di evitare revisioni manuali del codice che richiedono molto lavoro, specificate nel requisito 6.4. L'implementazione di un WAF ti consente di mantenere la conformità in modo continuo, riducendo al contempo i costi e i rischi della conformità.
Passaggi successivi
- Consulta le best practice per la gestione degli obblighi di conformità.
- Letto Conformità allo standard di sicurezza dei dati PCI su Google Cloud.
- Linee guida del PCI Council per l'ambito e la segmentazione della rete PCI DSS (PDF).
- Prova il blueprint PCI su GKE.
- Proteggi i carichi di lavoro Kubernetes per PCI DSS.
- Esegui il deployment Progetto Terraform PCI Starter.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.