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 stanno eseguendo la migrazione o la progettazione di sistemi nel cloud soggetti alla conformità PCI. i tuoi requisiti. Ove applicabile, questo documento fa riferimento ai requisiti PCI DSS 4.0.
Comprensione dell'ambito della valutazione PCI DSS
Se la tua organizzazione opera in commercio su internet, devi sostenere e mantenere la conformità PCI. Il modo in cui progetti e gestisci il tuo cloud influisce sull'ambito dei sistemi per i tuoi Standard di sicurezza dei dati PCI (DSS) la valutazione. 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?
Rientrano nell'ambito di applicazione tutti i sistemi che memorizzano, elaborano o trasmettono i dati dei titolari delle carte per la 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: del tuo CDE e di qualsiasi sistema che sia collegato alla sicurezza o che potrebbe influire del tuo CDE.
Un sistema è connesso a se utilizza la stessa rete e se condivide database o file spazio di archiviazione, oppure avere accesso o connettività a qualsiasi sistema o processo che che risiede all'interno del CDE, ma non ha accesso diretto a quest'ultimo.
Un sistema ha un impatto sulla sicurezza se può, se compromesso, consentire a un utente malintenzionato di per ottenere l'accesso al CDE. Tutti i sistemi connessi e che hanno un impatto sulla sicurezza sono sempre in ambito.
I sistemi fuori ambito sono attendibili per definizione in PCI DSS e hanno zero a un aggressore che vuole accedere a CHD o all'autenticazione sensibile dati (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. Per questo è importante che i confini degli ambiti siano fortemente protetti, monitorato in modo continuo e approfondito e chiaramente documentato.
Connessioni nel contesto PCI
Diversi requisiti PCI DSS fanno riferimento alle connessioni, ma i requisiti PCI DSS non definisce esplicitamente le connessioni. 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 l'ambiente, è meglio indicare chiaramente a quale soggetto si tratta autorizzato ad avviare una connessione. Un firewall configurato per consentire solo il traffico in una direzione può applicare una connessione unidirezionale. Ad esempio, un un'applicazione di elaborazione dei pagamenti nell'ambito può indirizzare query fuori dall'ambito server di database senza che il server fuori ambito entri nell'ambito se tutte le sono vere:
- La connessione e il database fuori ambito non memorizzano, elaborano o trasmettono CHD o TRISTE.
- Il database si trova su una rete separata o è segmentato in altro modo CDE,
- Il database non può avviare chiamate direttamente o indirettamente a CDE.
- Il database non fornisce servizi di sicurezza al CDE.
- Il database non influisce sulla configurazione o sulla sicurezza del CDE.
- Il database supporta i requisiti PCI DSS.
Il seguente diagramma mostra i fattori che determinano l'ambito del sistema:
Nella Figura 2, l'ambito del sistema è determinato come segue:
Componenti di sistema che rientrano nell'ambito di PCI DSS:
- Sistemi che si trovano nella CDE per i quali è vera una delle seguenti condizioni:
- .
- Un componente del sistema archivia, elabora o trasmette CHD o SAD.
- Un componente di sistema si trova sullo stesso segmento di rete, ad esempio nella sulla stessa subnet o VLAN dei sistemi che archiviano, elaborano o trasmettono CHD.
- Sistemi connessi o sistemi che hanno un impatto sulla sicurezza per i quali
una delle seguenti condizioni è vera:
- .
- Un componente del sistema si connette direttamente a CDE.
- Un componente del sistema influisce sulla configurazione o sulla sicurezza del CDE.
- Un componente del sistema separa i sistemi CDE dai sistemi fuori ambito e reti.
- 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.
- Sistemi che si trovano nella CDE per i quali è vera una delle seguenti 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 PCI DSS di ambito del sistema può significare che il datastore e il database di e-commerce dell'applicazione web possono essere considerati fuori ambito se la segmentazione è implementata e documentata correttamente. La il seguente diagramma mostra come funzionano le connessioni di lettura e scrittura tra l'ambito e sistemi fuori ambito:
La figura 3 mostra le seguenti connessioni:
- Sola lettura:
- Un'applicazione di elaborazione dei pagamenti nell'ambito legge un ID carrello da un un database del carrello fuori ambito e legge i dati da un DNS e da una 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 dati in un servizio di logging. Questi dati non includono CHD o SAD.
- Lettura e scrittura:
- Un utente sul web pubblico legge e scrive i metadati delle richieste come segue:
- L'utente legge e scrive su un'elaborazione dei pagamenti nell'ambito un'applicazione. Questi metadati di richiesta sono l'ID carrello e l'ID carrello di autenticazione contenenti CHD e SAD.
- L'utente legge e scrive nell'applicazione web principale fuori 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 fuori ambito, archivio sessioni e principale applicazione per configurare un database. Questi dati non includono CHD o SAD.
- Un'applicazione di elaborazione dei pagamenti nell'ambito legge e scrive i dati in un nell'ambito del servizio di tokenizzazione delle carte e a un elaboratore della carta di credito sul web pubblico. Questi dati includono CHD e SAD.
- Un utente sul web pubblico legge e scrive i metadati delle richieste come segue:
L'architettura nella figura 3 descrive due applicazioni web discrete: applicazione web (applicazione principale), che non rientra nell'ambito di PCI e un'applicazione di elaborazione dei pagamenti (applicazione di pagamento), che rientra nell'ambito della procedura. Nel questa architettura, una connessione può essere avviata tra due entità solo in le istruzioni nell'elenco precedente. Le connessioni tra le entità essere di sola lettura, lettura e scrittura o di sola scrittura dal punto di vista del chiamante. Qualsiasi un percorso o una direzione della richiesta non descritti in modo esplicito è bloccato la segmentazione dei clienti. Ad esempio, l'applicazione di elaborazione dei pagamenti può leggere il database del carrello e scrivere sul servizio di logging, il che comporta l'avvio di connessione con queste entità.
I sistemi che rientrano nell'ambito richiamano comunemente sistemi e servizi fuori dall'ambito. Questi restano sicure perché la segmentazione impedisce a qualsiasi chiamante remoto (altro rispetto a un titolare della carta) di avviare una connessione direttamente con il CDE indirettamente. La figura 3 mostra che l'unico percorso in entrata per il pagamento che l'applicazione sia dell'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 trasmettereCartIDe uno strumento di convalida chiamatoCartAuthKey.CartAuthKeyè un hash diCartIDe un elemento precondiviso noto solo alle applicazioni principali e di pagamento. - L'applicazione di pagamento convalida l'utente eseguendo l'hashing del
CartIDinsieme con il secret e lo confrontiamo conCartAuthKey. - Una volta autenticati i dati utente,
CartIDviene utilizzato per leggere il carrello i contenuti del 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 nella di tokenizzazione.
- Una volta elaborato il pagamento, il risultato viene inserito nella dell'applicazione con un account di servizio del database di sola scrittura.
Considerazioni sull'ambito
Nel documento "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 SSC non implica che amplia il tuo ambito. Piuttosto, significa che il QSA valuta tutti sistemi come se fossero attendibili, a meno che tu non mostri che un sistema non ha la connettività o l'impatto sulla sicurezza sul tuo CDE. 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 confine tra i sistemi all'interno e all'esterno dell'ambito. La prima attività del QSA è per confermare che l'ambito documentato includa ragionevolmente il CDE e sistemi connessi. 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 eventuali circostanze particolari specifiche per 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. Questo potrebbe richiedono ulteriori considerazioni sull'ambito e sulla due diligence.
Best practice per la sicurezza di Google può aiutarti a stabilire e dimostrare un confine chiaro e difendibile tra i sistemi nell'ambito e i sistemi non attendibili, che aiuterà 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 troppo ampio può portare a valutazioni costose e a una maggiore conformità i rischi. Per limitare l'ambito, affidati al minor numero di sistemi possibile e concedi solo a pochi utenti selezionati. Attraverso una valutazione accurata e di autovalutazione, puoi identificare sistemi che non dovrebbero rientrare nell'ambito del PCI DSS, verificare che rispettino le linee guida per i sistemi fuori ambito e ridurre l'ambito di competenza di conseguenza. 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 di PCI DSS, è possibile che nell'ambito della valutazione vengano inclusi sistemi estranei. Quando se includi nel tuo ambito sistemi estranei, ciò comporta rischi per la tua capacità di 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 dello standard PCI DSS è il presupposto che alcune o tutte della rete è già stato compromesso. 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 PCI DSS, che consiglia il deployment di CDE e dei suoi sistemi connessi in uno spazio piccolo e affidabile, segmentato dal più ampio ambiente IT e non mescolato con questo.
All'interno del tuo ambiente PCI in ambito, non collocare il tuo CDE in un ambiente PCI di grandi dimensioni spazio con un ampio perimetro. Ciò può creare un falso senso di sicurezza e minare una strategia olistica di difesa in profondità. Se un utente malintenzionato viola le norme per la sicurezza perimetrale, possono operare con facilità all'interno di un ambiente intranet. Valuta dei modi per restringere lo spazio attendibile in modo che contenga ciò di cui ha bisogno per operare e proteggersi ed evitare di fare affidamento esclusivamente su della sicurezza perimetrale. Comprendere e seguire questi principi consente di progetta il tuo ambiente cloud per contribuire a proteggere i sistemi critici e ridurre rischio di contaminazione da sistemi compromessi.
Un ambiente ampio e compreso in sistemi attendibili richiede un'infrastruttura per mantenere il monitoraggio, la manutenzione, l'auditing continuo e l'inventario di questi sistemi. La complessità dell'architettura di sistema, processi di gestione dei cambiamenti e criteri di controllo dell'accesso possono creare i rischi di 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 il nell'ambito dell'ambiente valutato. Per ulteriori informazioni, vedi Supporto della conformità continua più avanti in questo documento.
Servizi Google Cloud nell'ambito di PCI DSS
Prima di iniziare a ridurre l'ambito del tuo ambiente PCI, comprendi quali servizi Google Cloud rientrano nell'ambito di PCI DSS. Questi servizi forniscono l'infrastruttura su cui è possibile creare il proprio servizio o un'applicazione che archivia, elabora o trasmette i dati del titolare della carta.
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 solo approccio, considera che utilizzano tutte queste strategie per massimizzare il potenziale e la riduzione dei costi.
Non esiste una soluzione universale per la definizione dell'ambito PCI. Potresti avere 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 progetto. 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.
- Cartelle possono contenere progetti e altre cartelle e controllare l'accesso usando autorizzazioni IAM a livello di cartella. Le cartelle sono comunemente utilizzata per raggruppare progetti simili.
- Progetti sono un confine di attendibilità per tutte le risorse punto di applicazione delle norme.
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 file 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à. Garantendo che solo gli utenti designati abbiano accesso a questo cartella e i relativi progetti, puoi escludere altre cartelle, progetti e risorse della gerarchia dall'ambito del test.
Quando concedi agli utenti l'accesso solo alle cartelle e ai progetti di cui hanno bisogno in un in base alle necessità, ti assicuri che solo gli utenti designati abbiano accesso ai tuoi all'interno dell'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 l'assistenza Requisito PCI DSS 8.4.1 assicurati di Applicare l'autenticazione a più fattori (MFA) per gli utenti designati e verifica Integratore PCI DSS sulle linee guida per l'autenticazione a più fattori (PDF). Per applicare la conformità nella gerarchia delle risorse, assicurati di capire come impostare Vincoli dei criteri dell'organizzazione. Questi vincoli supportano la conformità continua e possono aiutare a proteggere i tuoi in ambienti attendibili da 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 la gerarchia delle risorse è indissolubilmente collegata alla gestione di identità e accessi, ed efficaci Registrazione, controllo e monitoraggio delle azioni degli utenti è necessario 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 le route di rete che i sistemi non attendibili potrebbero utilizzare per accedere a CDE dei suoi componenti collegati. Definisci solo percorsi 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 con il controllo delle versioni attivo. 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 un'unica cartella per l'ambiente PCI in ambito e due progetti in per il CDE e i servizi condivisi.
Nella Figura 5, il progetto di servizi condivisi non fa parte del CDE, ma è una connesso a un sistema, pertanto rientra nell'ambito del PCI. Accesso a CDE è limitato a livello di rete dal bilanciatore del carico, regole firewall o criteri firewall per proteggere queste reti e rispettare Requisiti PCI DSS 1.2 e 1.3. Il sistema di tokenizzazione e quello di pagamento sono collocati in subnet separate e e le loro comunicazioni sono regolate da regole firewall tra ciascuna 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 il CDE si trovano all'interno di un Perimetro di sicurezza dei Controlli di servizio VPC per evitare errori di configurazione o compromissioni accidentali delle Controlli dell'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. Ciò è utile per fornire un accesso più granulare gli utenti designati.
- Criteri di rete possono isolare i pod e i servizi l'uno dall'altro per limitare i flussi di dati, può fornire un ulteriore livello di segmentazione della rete all'interno del tuo 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.
Ognuno di questi livelli costituisce una parte importante della protezione in profondità della sicurezza postura e restringi l'ambito isolando ulteriormente e proteggendo componenti attendibili dell'ambiente circostante. Se esegui il deployment di tutti gli strumenti parte del tuo CDE con Kubernetes, scopri più nel dettaglio come eseguire il tuo ambiente conforme allo standard PCI su GKE.
Implementa la tokenizzazione
La tokenizzazione è il processo di oscuramento irreversibile di un numero di conto bancario principale (PAN). Non è possibile utilizzare un PAN tokenizzato o un token per un PAN tramite mezzi matematici. Le SSC PCI offrono indicazioni sull'impatto della definizione dell'ambito delle la tokenizzazione nel Capitolo 3 della Supplemento alle linee guida per la 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ò aiutare ridurre l'ambito della valutazione riducendo al minimo l'occorrenza e la trasmissione di numeri di conto bancario 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 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, l'utente riceve un PAN e altri dati del titolare della carta e poi i dati vengono immediatamente inviati 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. Non vengono mai raccolti il PAN né altri dati del titolare della carta 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 PAN da un token mediante una ricerca e il processo di sviluppo. È 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. Altri datastore possono essere anche in base alle esigenze della tua attività.
Architettura di esempio
Il seguente diagramma illustra un'architettura di esempio per l'elaborazione le transazioni tokenizzate Pub/Sub e Dataflow e l'archiviazione dei record delle transazioni tokenizzati Spanner.
Nella Figura 7, il progetto di elaborazione delle transazioni è un sistema collegato a e 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 del i dati tokenizzati vengono pubblicati per altri abbonati, Sensitive Data Protection verifica che non contenga CHD. I dati tokenizzati vengono elaborati Dataflow e archiviati nella transazione Spanner per configurare un database. 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. Corretto in combinazione con un'azione di correzione rapida è detta continua conformità. La conformità continua è un requisito dello standard PCI DSS e quando se implementata correttamente, può aiutare a massimizzare l'effetto di un altro ambito strategie di riduzione.
Google Cloud ti consente di registrare tutto ciò che accade nella tua rete utilizzando Logging delle regole firewall, Log di flusso VPC, log dei Controlli di servizio VPC, e 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 Requisito PCI DSS 10.4 e consente di rispondere rapidamente a potenziali minacce alla sicurezza e di risolverle. Per ulteriori informazioni, consulta Integratore PCI DSS sul monitoraggio giornaliero efficace dei log (PDF).
Security Command Center consente di comprendere la superficie di attacco di dati e sicurezza fornendo inventario, scoperta, ricerca e gestione. 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 venga 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 ulteriore protezione per il tuo ambiente web Google Cloud le applicazioni e la conformità al Requisito PCI DSS 6.4. 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. La presenza di un WAF ti aiuta a mantenere la conformità continua 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 la definizione dell'ambito PCI DSS e la segmentazione della rete (PDF).
- Prova la Progetto 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.