Conformità allo standard PCI Data Security

Last reviewed 2023-11-27 UTC

Questa guida ti aiuta a scoprire come implementare lo standard PCI DSS (Payment Card Industry Data Security Standard) per la tua attività su Google Cloud. La guida va oltre le linee guida del PCI SSC sul cloud computing (PDF) per fornire informazioni sullo standard, spiegare il tuo ruolo nella conformità basata su cloud e fornire le linee guida per progettare, implementare e configurare un'app di elaborazione dei pagamenti utilizzando PCI DSS. Il tutorial illustra anche i metodi per monitorare, registrare e convalidare l'app.

Questo documento fa riferimento ai requisiti PCI DSS 4.0, ove applicabili.

Il PCI Data Security Standard, creato dal PCI Security Standards Council, è uno standard di sicurezza delle informazioni per le attività che gestiscono i dati delle carte di pagamento (sia di credito che di debito). Il PCI Security Standards Council include tutte le principali società di carte di pagamento. Le attività che accettano carte Visa, MasterCard, Discover, American Express, JCB o UnionPay devono rispettare lo standard PCI DSS e possono essere multate o penalizzate se non lo fanno.

Il PCI DSS include classificazioni per diversi tipi di commercianti, dai commercianti che collect informazioni di pagamento di persona ai commercianti che esternalizza completamente l'elaborazione dei pagamenti. Questa guida riguarda i tipi di commercianti SAQ A, SAQ A-EP e SAQ D.

Obiettivi

  • Esamina l'architettura dell'app di elaborazione dei pagamenti.
  • Configura l'ambiente di elaborazione dei pagamenti.
  • Esegui il deployment e configura i server delle app.
  • Configura il logging e il monitoraggio.
  • Convalida l'ambiente di elaborazione dei pagamenti.

Definizioni

Questa guida utilizza molte frasi uniche. Ecco alcuni dei più comuni. Per maggiori informazioni, consulta il glossario PCI DSS.

CDE: acronimo di cardholder data environment (ambiente dati dei titolari della carta). Questo acronimo si riferisce a qualsiasi parte della tua app che detiene o trasferisce dati del titolare della carta, incluso il numero dell'account pagamenti o qualsiasi informazione che consenta l'identificazione personale relativa alla carta.

Controlli compensativi: soluzioni alternative che possono essere prese in considerazione se un'entità non è in grado di soddisfare un requisito esplicitamente indicato, a causa di vincoli aziendali tecnici o documentati legittimi. Le persone giuridiche devono mitigare sufficientemente il rischio associato al requisito quando implementano questi altri controlli. Per indicazioni sull'utilizzo dei controlli compensativi, consulta le appendici B e C "Controlli compensativi" in Requisiti e procedure di valutazione della sicurezza PCI DSS.

PAN: acronimo di numero di conto principale e indicato anche come numero di conto. Si tratta del numero univoco della carta di pagamento che identifica l'emittente e l'account del titolare della carta.

QSA: acronimo di Qualified Security Assessor. I QSA sono qualificati dal PCI Security Standards Council (SSC) per eseguire valutazioni PCI DSS on-site. I requisiti di qualifica per gli valutatori della sicurezza qualificati (QSA) forniscono dettagli sui requisiti per le aziende e i dipendenti QSA.

SAQ: acronimo di Self-Assessment Questionnaire, lo strumento di generazione di report utilizzato per documentare i risultati dell'autovalutazione della valutazione PCI DSS di una persona giuridica. Questo vale solo per le persone giuridiche idonee all'autovalutazione.

Ambito: i sistemi, le procedure e le persone da includere in una valutazione PCI DSS.

Tokenizzazione: un processo che sostituisce il numero PAN (Permanent Account Number) con un valore sostitutivo chiamato token. Il PAN viene quindi archiviato in una ricerca sicura. La detokenizzazione è il processo inverso della ricerca di un PAN tramite il token. Un token può essere un hash o un valore assegnato.

Contesto

PCI DSS fornisce un elenco di requisiti progettati per migliorare la sicurezza dei titolari di carte. Questi requisiti sono suddivisi in двенадцать parti principali numerate e molti sottoparti. Questo documento fa riferimento a questi numeri di parte per fornire un contesto, ma i riferimenti alle sezioni non sono un elenco esaustivo dei requisiti applicabili.

I requisiti di conformità PCI DSS variano a seconda di come la tua azienda gestisce le transazioni con carte di pagamento (tipo) e quante transazioni esegue ogni anno (livello).

Man mano che il numero di transazioni aumenta, il livello del commerciante PCI DSS aumenta e le linee guida per la conformità al PCI DSS diventano più severe. Al livello più alto del commerciante, il livello 1, il PCI DSS richiede un audit. I livelli variano in base al marchio della carta. Il livello 1 è definito da American Express come 2,5 milioni di transazioni annuali e da Visa, Mastercard e Discover come 6 milioni di transazioni annuali. Ogni brand di carte ha requisiti di livello aggiuntivi che non rientrano nell'ambito di questo documento. Assicurati che l'ambiente di elaborazione dei pagamenti sia sottoposto a verifica per supportare il tuo livello di commerciante.

Poiché Google Cloud è un fornitore di servizi conforme a PCI DSS 4.0 di livello 1, può supportare le tue esigenze di conformità a PCI DSS indipendentemente dal livello del commerciante della tua azienda. La sezione Impegno alla conformità illustra le aree coperte da Google per te.

L'altra variabile fondamentale è il tipo di SAQ. L'SAQ illustra i criteri che devi soddisfare per rispettare i PCI DSS se hai l'idoneità per l'autovalutazione. Il tipo di SAQ è determinato dall'architettura dell'app e dal modo preciso in cui gestisci i dati delle carte di pagamento. La maggior parte dei commercianti nel cloud è una delle seguenti:

Tipo di SAQ Descrizione
A Commercianti che hanno completamente esternalizzato l'elaborazione delle carte di pagamento a un sito di terze parti. I clienti escono dal tuo dominio (anche tramite un <iframe> modulo web), completano il pagamento e poi tornano alla tua app.

In altre parole, la tua azienda non può in alcun modo accedere ai dati delle carte dei clienti.
A-EP I commercianti che esternalizzano l'elaborazione dei pagamenti a un fornitore di terze parti, ma che possono accedere ai dati delle carte dei clienti in qualsiasi momento della procedura. I commercianti che possono accedere ai dati della carta includono elementi della pagina controllati dal commerciante, come JavaScript o CSS, incorporati nella pagina di pagamento di terze parti.

In altre parole, l'app di elaborazione dei pagamenti inoltra i dati della carta a un responsabile del trattamento lato client oppure il responsabile del trattamento esegue il rendering di tutti i contenuti ospitati da te.
D I commercianti che accettano pagamenti online e non sono idonei per il SAQ A o per il SAQ A-EP. Questo tipo include tutti i commercianti che chiamano un'API di un elaboratore dei pagamenti dai propri server, indipendentemente dalla tokenizzazione.

In altre parole, se non sei SAQ A o SAQ A-EP, sei SAQ D.

Il SAQ D distingue tra commercianti e fornitori di servizi. I fornitori di servizi non sono trattati in questo documento e tutti i riferimenti SAQ D si riferiscono ai commercianti come definiti nel PCI DSS.
Diagramma di Venn dei requisiti del SAQ. Il questionario SAQ A-EP è un superset del questionario SAQ A e il questionario SAQ D è un superset del questionario SAQ A-EP.
Figura 1. Diagramma di Venn dei requisiti del SAQ. Il SAQ A-EP è un superset del SAQ A e il SAQ D è un superset del SAQ A-EP.

Impegno per la conformità

Google utilizza una serie di tecnologie e procedure per proteggere le informazioni memorizzate sui suoi server. Google ha convalidato in modo indipendente i requisiti PCI DSS che si applicano alle Google Cloud tecnologie e all'infrastruttura Google Cloud gestite da Google. Puoi scaricare i report di conformità PCI DSS di Google da Gestione dei report di conformità. Sebbene Google offra ai commercianti un'ampia gamma di controlli sulle loro istanze di calcolo in esecuzione sull'infrastruttura di Google, non controlla la sicurezza del sistema operativo, dei pacchetti o delle app di cui i commercianti eseguono il deployment Google Cloud. È tua responsabilità rispettare i requisiti PCI DSS per i pacchetti del sistema operativo e le app di cui esegui il deployment, oltre ad altre personalizzazioni richieste dalla tua architettura.

Google Cloud rispetta i requisiti PCI DSS previsti per un fornitore di servizi di Livello 1 e tutti i requisiti applicabili per i fornitori di servizi. La Google Cloud matrice di responsabilità condivisa descrive gli obblighi di conformità del PCI DSS. La matrice di responsabilità può essere un riferimento utile per perseguire la conformità allo standard PCI DSS e condurre i tuoi audit PCI DSS.

Informazioni sui prodotti

Questa sezione contiene indicazioni per i servizi Google Cloud di uso comune nelle architetture utilizzate per gli ambienti PCI DSS.

App Engine

Utilizza le regole firewall di ingresso e i controlli del traffico in uscita di App Engine.

Cloud Run

Utilizza le impostazioni di ingresso di Cloud Run, Controlli di servizio VPC e controlli in uscita sui connettori VPC. Se necessario, configura un indirizzo IP in uscita statico.

Funzioni Cloud Run

Utilizza le impostazioni di rete in entrata e in uscita di Cloud Run Functions.

Cloud Logging

Registra le interazioni con Cloud Logging.

Cloud Monitoring

Monitora le interazioni con Cloud Monitoring.

Google Kubernetes Engine

Per informazioni sull'utilizzo di Google Kubernetes Engine per gli ambienti PCI DSS, consulta Conformità a PCI DSS su GKE.

Cloud Storage

Il requisito 3.5 prevede che un numero PAN (codice PAN) sia protetto ovunque sia archiviato. Sebbene Google offra automaticamente la crittografia a riposo, non esegue automaticamente gli hash unidirezionali, il troncamento o la tokenizzazione richiesti anche dalle norme.

Architetture di esempio

Questa sezione illustra gli approcci per l'implementazione di un ambiente conforme a SAQ A, SAQ A-EP e SAQ D.

Panoramica dell'architettura

Il SAQ A è l'architettura di elaborazione dei pagamenti più semplice. I pagamenti vengono elaborati da una terza parte e le app o le pagine dei commercianti non accedono ai dati della carta.

A livello generale, il flusso di elaborazione dei pagamenti è il seguente:

  1. Il cliente effettua le sue selezioni e procede al pagamento.

  2. L'app di pagamento reindirizza il cliente a un elaboratore di pagamenti di terze parti.

  3. Il cliente inserisce i dati della carta di pagamento in un modulo di pagamento di proprietà e gestito dall'elaboratore di terze parti.

  4. Il fornitore di servizi di terze parti che segue per noi l'elaborazione dei pagamenti controlla i dati della carta di pagamento e poi addebita o rifiuta la carta.

  5. Dopo aver elaborato la transazione, l'elaboratore dei pagamenti di terze parti indirizza nuovamente il cliente all'app del commerciante insieme ai dettagli della transazione.

  6. L'app commerciante invia una richiesta di verifica all'operatore di pagamento per confermare la transazione.

  7. L'operatore di pagamento risponde per verificare i dettagli della transazione.

Elaborazione delle informazioni tra il browser del cliente, il sito del commerciante, l&#39;elaboratore dei pagamenti e il gateway di pagamento.
Architettura di un SAQ: un ambiente di elaborazione dei pagamenti di terze parti.

L'architettura di elaborazione dei pagamenti SAQ A-EP è incentrata su un'app di elaborazione dei pagamenti che viene eseguita su istanze di macchine virtuali Compute Engine. Queste istanze si trovano in una rete privata sicura e utilizzano canali sicuri per comunicare con i servizi esterni alla rete.

A livello generale, il flusso di elaborazione dei pagamenti è il seguente:

  1. Il cliente inserisce i dati della carta di pagamento in un modulo di pagamento di proprietà e gestito dalla tua azienda.

  2. Quando il cliente invia le proprie informazioni, queste vengono trasmesse in modo sicuro a un elaboratore dei pagamenti di terze parti.

  3. Il fornitore di servizi di terze parti che segue per noi l'elaborazione dei pagamenti controlla i dati della carta di pagamento e poi addebita o rifiuta la carta.

  4. L'elaboratore dei pagamenti invia una risposta alla tua app di pagamento, che a sua volta passa un messaggio alla tua app principale.

Tutte queste interazioni vengono registrate e monitorate con Cloud Logging e Cloud Monitoring.

Architettura di un ambiente di elaborazione dei pagamenti A-EP SAQ
Architettura di un ambiente di elaborazione dei pagamenti A-EP SAQ.

L'architettura di elaborazione dei pagamenti SAQ D si basa su un'app di elaborazione dei pagamenti in esecuzione su istanze di macchine virtuali Compute Engine. Queste istanze si trovano in una rete privata sicura e utilizzano canali sicuri per comunicare con i servizi esterni alla rete.

A livello generale, il flusso di elaborazione dei pagamenti è il seguente:

  1. Il cliente inserisce i dati della carta di pagamento in un modulo di pagamento di proprietà e gestito dalla tua azienda.

  2. Quando il cliente invia le sue informazioni, la tua app di pagamento riceve le informazioni del modulo.

  3. L'app di pagamento convalida i dati di pagamento e li inoltra in modo sicuro a un fornitore di servizi di terze parti che segue per noi l'elaborazione dei pagamenti tramite un'API di backend.

  4. Il fornitore di servizi di terze parti che segue per noi l'elaborazione dei pagamenti controlla i dati della carta di pagamento e poi addebita o rifiuta la carta.

  5. L'elaboratore dei pagamenti invia una risposta alla tua app di pagamento, che a sua volta passa un messaggio alla tua app principale.

Tutte queste interazioni vengono registrate e monitorate con Logging e Monitoring.

Architettura di un ambiente di elaborazione dei pagamenti SAQ D
Architettura di un ambiente di elaborazione dei pagamenti SAQ D.

Flusso di elaborazione dei pagamenti rivolto al cliente

Questa sezione descrive il flusso di elaborazione dei pagamenti di terze parti dal punto di vista dei clienti che utilizzano la tua app.

Flusso rivolto ai clienti dell&#39;SAQ A: elaborazione dei pagamenti di terze parti
Flusso rivolto al cliente del SAQ Elaborazione dei pagamenti di terze parti.

Quando il cliente accede al tuo modulo di pagamento, l'app presenta un <iframe> ospitato dall'elaboratore dei pagamenti. La tua app non può accedere o monitorare i contenuti di <iframe> a causa di limitazioni alla condivisione di risorse cross-origin. Quando il cliente invia i dati della carta di pagamento, l'elaboratore dei pagamenti accetta o rifiuta la carta, quindi rimanda il cliente alla tua app. L'app controlla la risposta alla transazione dell'elaboratore dei pagamenti e agisce di conseguenza. L'app non ha accesso o gestito i dati della carta di pagamento.

Questa sezione descrive lo stesso flusso di elaborazione dei pagamenti interni descritto in precedenza, ma dal punto di vista dei clienti che utilizzano la tua app.

Flusso rivolto ai clienti per l&#39;elaborazione dei pagamenti di terze parti SAQ A-EP
Flusso rivolto al cliente per l'elaborazione dei pagamenti di terze parti SAQ A-EP.

Quando il cliente accede all'URL del modulo di pagamento, il sito presenta un modulo ospitato dalla tua app di pagamento. Quando il cliente invia i dati della sua carta di pagamento, il modulo viene inviato direttamente all'elaboratore dei pagamenti. L'elaboratore accetta o rifiuta la carta, quindi rimanda il cliente alla tua app. L'app controlla la risposta alla transazione dell'elaboratore dei pagamenti e agisce di conseguenza. Il cliente potrebbe non vedere l'elaboratore dei pagamenti di terze parti, ma la tua app non ha avuto accesso ai dati della carta di pagamento lato server.

Questa sezione descrive il flusso interno di elaborazione dei pagamenti dal punto di vista dei clienti che utilizzano la tua app.

Flusso rivolto ai clienti dell&#39;elaborazione dei pagamenti di terze parti SAQ D
Flusso rivolto al cliente dell'elaborazione dei pagamenti di terze parti SAQ D.

Quando il cliente accede all'URL del modulo di pagamento, viene indirizzato in modo sicuro al modulo tramite un bilanciatore del carico HTTPS. Quando il cliente invia i dati della sua carta di pagamento, la tua app di elaborazione dei pagamenti li invia in modo sicuro a un elaboratore dei pagamenti di terze parti. L'elaboratore dei pagamenti di terze parti accetta o rifiuta la carta, quindi restituisce una risposta alla tua app di elaborazione dei pagamenti.

Flusso interno di elaborazione dei pagamenti

Questa sezione descrive il flusso di elaborazione dei pagamenti dal punto di vista dei server che eseguono la tua app.

Flusso interno di SAQ A e SAQ A-EP
Flusso interno di SAQ A e SAQ A-EP.

L'app di elaborazione dei pagamenti riceve e analizza la risposta data dall'elaboratore dei pagamenti di terze parti, quindi invia alcuni o tutti i dati della risposta all'app principale. A questo punto, l'app di elaborazione dei pagamenti ha completato la transazione. L'app di base gestisce l'attività di invio di notifiche ai clienti.

Questa sezione descrive il flusso interno di elaborazione dei pagamenti dal punto di vista dei server su cui è in esecuzione la tua app.

Flusso interno SAQ D
Flusso interno SAQ D.

L'app di elaborazione dei pagamenti convalida i dati della carta di pagamento inviati dal cliente e li invia all'elaboratore dei pagamenti tramite un'API di backend. L'agente di elaborazione tenta l'addebito e risponde con i dettagli della transazione. L'app riceve ed elabora la risposta, quindi invia alcuni o tutti i dati della risposta all'app principale. A questo punto, l'app di elaborazione dei pagamenti ha completato la transazione. L'app di base gestisce l'attività di invio di notifiche al cliente e di consegna del prodotto.

Monitoraggio e registrazione del flusso di dati

Il flusso di monitoraggio e logging è progettato come segue:

Flusso di monitoraggio e logging
Flusso di monitoraggio e logging.

Configurazione dell'ambiente di elaborazione dei pagamenti

Questa sezione descrive come configurare l'ambiente di elaborazione dei pagamenti. La configurazione include quanto segue:

  • Creare un nuovo Google Cloud account per isolare l'ambiente di elaborazione dei pagamenti dall'ambiente di produzione.
  • Limitare l'accesso al tuo ambiente.
  • Configurazione delle risorse virtuali.
  • Progettazione dell'immagine di base di Linux che utilizzerai per configurare i server app.
  • Implementazione di una soluzione di gestione dei pacchetti sicura.

Configurare un nuovo account

Per semplificare la limitazione dell'accesso e il controllo della conformità, crea un ambiente di elaborazione dei pagamenti con qualità di produzione completamente isolato dall'ambiente di produzione standard e da eventuali ambienti di sviluppo e QA (requisito 6.5.3). Per garantire l'isolamento, crea e utilizza un Google Cloud account distinto da quello dell'ambiente di produzione principale. Gli utenti esperti di configurazione di Identity and Access Management (IAM) possono ottenere un isolamento equivalente utilizzando progetti separati per il lavoro in ambito.

Limitare l'accesso al tuo ambiente

Consenti l'accesso all'ambiente di elaborazione dei pagamenti solo alle persone che implementano il codice del sistema di pagamento o gestiscono le macchine del sistema di pagamento (sezione 7.2 e requisito 8.2.1). Questo è noto come principio del privilegio minimo. Utilizza i ruoli IAM per limitare l'accesso. Le best practice includono l'utilizzo dei ruoli, ove possibile, la concessione solo delle autorizzazioni necessarie per eseguire il lavoro previsto e la concessione del ruolo Proprietario solo alle entità che hanno legittimamente bisogno dell'accesso root completo ai tuoi servizi. Per ulteriori informazioni, consulta la guida alla sicurezza di IAM.

L'accesso automatico a qualsiasi servizio gestito deve basarsi su account di servizio. Gli account di servizio semplificano il ciclo di vita della gestione delle app offrendoti un modo per gestire l'autenticazione e l'autorizzazione delle app. Questi account ti offrono un modo flessibile, ma sicuro, per raggruppare istanze di macchine virtuali con app e funzioni simili che hanno un'identità comune. Puoi applicare il controllo di sicurezza e di accesso a livello di account di servizio tramite i ruoli IAM e le regole del firewall VPC.

Le regole IAM applicate alle cartelle vengono ereditate da tutti gli elementi contenuti al loro interno. Le autorizzazioni predefinite sono di tipo deny-all (Requisito 7.2.3) e ogni regola applicata aggiunge solo autorizzazioni.

Il requisito 8.3.6 fornisce alcune regole di base per le password utente. Il National Institute of Standards and Technology (NIST) definisce un insieme di regole più sicure per le password sicure nella sezione 5.1.1 di NIST SP800-63B. Google consiglia di seguire le linee guida per le identità digitali del NIST, se possibile.

La sezione 12.7 del SAQ D del PCI DSS richiede che le persone con accesso al tuo ambiente ambito superino un controllo dei precedenti, in conformità con le leggi locali, prima di poter accedere all'ambiente. Per ridurre il rischio di violazioni della conformità, valuta la possibilità di eseguire questi controlli di referenza e dei precedenti penali su ogni persona, indipendentemente dal tipo di conformità.

Protezione della rete

Per proteggere il traffico in entrata e in uscita verso e dalla rete della tua app di elaborazione dei pagamenti, devi creare quanto segue:

  • Policy Cloud Next Generation Firewall o regole firewall di Compute Engine
  • Un tunnel Cloud VPN
  • Un bilanciatore del carico delle applicazioni esterno

Per la creazione del VPC, ti consigliamo anche di utilizzare Cloud NAT per un ulteriore livello di sicurezza di rete. Esistono molte opzioni efficaci per proteggere le reti delle istanze Compute Engine e GKE.

Creazione di regole firewall

Utilizza le policy o le regole firewall di Cloud Next Generation Firewall per limitare il traffico in entrata a ciascuna delle tue istanze Compute Engine (requisiti 1.3 e 1.4). Consenti il traffico in entrata solo dalle seguenti tre origini:

  • HTTPS pubblico, in modo che i clienti possano raggiungere la tua pagina di pagamento.
  • La tua rete di app, in modo che l'app di elaborazione dei pagamenti possa ricevere risposte dal tuo gestore dei pagamenti di terze parti.
  • La rete interna dell'ufficio, in modo da poter accedere alle istanze per scopi di controllo e gestione.

Utilizza le regole firewall sulle singole istanze per limitare il traffico in uscita. Puoi implementare queste regole localmente con iptables o, più in generale, utilizzando le regole firewall VPC e i tag di rete. Consenti il traffico in uscita solo dal tuo modulo di pagamento all'elaboratore di pagamenti di terze parti. Questa connessione deve essere solo HTTPS. Per verificare il tuo lavoro, consulta la sezione relativa alla registrazione delle regole firewall più avanti in questo documento.

Cloud DNS offre zone DNS private in modo da poter assegnare nomi in modo sicuro agli host all'interno del tuo CDE senza la possibilità di far trapelare dati sensibili sulla topologia di rete al pubblico.

Limita il traffico come segue:

Origine Destinazione Porta Indicazioni e motivo
Bilanciatore del carico pubblico Modulo per i pagamenti di terze parti tcp:443 In entrata
Accesso pubblico all'app di elaborazione dei pagamenti
Modulo di pagamento di terze parti Elaboratore dei pagamenti di terze parti tcp:443 In uscita
Inoltro delle richieste AUTH al fornitore di servizi di pagamento
Elaboratore dei pagamenti di terze parti La tua app di elaborazione dei pagamenti tcp:5480 In entrata
Accetta le richieste AUTH dai sistemi di pagamento (non contiene dati del titolare della carta)
La rete dell'ufficio della tua azienda vpn-gateway tcp:8000 In entrata
Accesso all'ambiente di elaborazione dei pagamenti per accedere ai log e alle macchine di sviluppo

Inoltre, il seguente traffico avviene in modo sicuro nella rete interna della tua app di elaborazione dei pagamenti:

Origine Destinazione Porta Motivo
Modulo della scheda Proxy PCI tcp:5480 Scambio di dati della carta criptati per il token dello strumento di pagamento
Tutti gli host Server NTP di Google udp:123 Sincronizzazione dell'ora
Gateway VPN Tutti gli host tcp:22 Connessioni Secure Shell (SSH)

Creazione di un tunnel VPN sicuro

Puoi utilizzare Cloud VPN per stabilire un tunnel VPN sicuro tra il tuo ambiente on-premise e l'ambiente di elaborazione dei pagamenti (sezioni 2.2.7 e 4.2).

Creazione di un bilanciatore del carico delle applicazioni esterno

Puoi contribuire ad assicurare la sicurezza del traffico in entrata dei clienti creando un bilanciatore del carico delle applicazioni esterno (sezioni 2.2.7 e 4.2). Per creare un bilanciatore del carico delle applicazioni esterno, devi disporre di quanto segue:

  • Un sottodominio del tuo sito web utilizzato per il modulo di elaborazione dei pagamenti, ad esempio payments.your-domain-name.com.
  • Un certificato SSL valido e firmato che è stato registrato per il tuo sottodominio.

Verifica che il tuo dominio sia valido controllandone le impostazioni DNS nell'interfaccia di configurazione del dominio del tuo registrar web.

Creazione di un'immagine di base Linux

Lo standard PCI DSS contiene requisiti che descrivono come configurare le macchine che fanno parte di un'architettura di elaborazione dei pagamenti conforme. Puoi implementare questi requisiti in diversi modi, ma l'approccio più semplice è il seguente:

  1. Crea un elenco del software e delle librerie che devono essere installati su ogni server che rientra nell'ambito della tua app di elaborazione dei pagamenti. Per evitare di introdurre vulnerabilità non necessarie nel sistema (requisito 2.2.4), includi solo il minimo di software e librerie necessario per eseguire l'app. I candidati potrebbero includere Google Cloud CLI, runtime e librerie specifiche per il linguaggio o un server web.

  2. Crea un'istanza Compute Engine che utilizza una delle immagini del sistema operativo preconfigurate di Compute Engine.

  3. Installa le librerie e il software elencati in precedenza.

  4. Installa e configura ntp per mantenere sincronizzati gli orologi di sistema. La gestione degli orologi dei server con il Network Time Protocol garantisce l'integrità dei timestamp nei log (sezione 10.6).

  5. Assicurati che l'immagine segua le best practice per la creazione di un'immagine Compute Engine sicura (tutta la sezione 2.2).

  6. Dopo aver configurato l'immagine di base, crea un'immagine disco Compute Engine personalizzata dalla tua immagine. Questa immagine ti consente di utilizzare l'immagine di base Linux quando crei istanze di macchine virtuali.

Utilizzo di una gestione sicura dei pacchetti

La gestione dei pacchetti è un componente chiave di un ambiente di hosting rafforzato per la sicurezza. Ai sensi della sezione 2.2, devi implementare standard di hardening accettati dal settore. A meno che tu non utilizzi Container-Optimized OS di Google, è probabile che tu abbia installato un gestore dei pacchetti come RPM, Yum o Apt. La tua app potrebbe utilizzare il proprio gestore di pacchetti specifico per il linguaggio di programmazione, ad esempio NPM, PyPi o Composer, e scaricare le dipendenze alla prima esecuzione.

Se la tua app può recuperare gli aggiornamenti da internet, devi trattare le fonti di aggiornamento come un potenziale rischio per la sicurezza. Gli attacchi a monte o lato offerta, inclusi deliberatamente nei pacchetti ospitati pubblicamente, stanno diventando sempre più comuni. Immagina gli effetti dell'installazione di un aggiornamento di SSH contenente codice dannoso.

Puoi ridurre il rischio di attacchi lato offerta creando un elenco di destinatari sicuri per i tuoi pacchetti e verificando che corrispondano a quelli dell'elenco. Tieni un elenco di numeri di versione testati e approvati per ogni pacchetto che utilizzi. Registra il numero di versione insieme all'hash o alla firma. Assicurati che il gestore del pacchetto convalidi l'hash o la firma prima di installare o aggiornare un'app.

La maggior parte dei sistemi di gestione dei pacchetti consente l'hosting privato. Se possibile, avvia il tuo server di gestione dei pacchetti privato e ospita solo software testato e approvato. Blocca il gestore dei pacchetti in modo che non possa contattare altri server per gli aggiornamenti.

Idealmente, il processo di compilazione dell'app recupera e convalida tutti i pacchetti, quindi crea una revisione dell'immagine del disco personalizzata che include tutto ciò di cui il contenitore ha bisogno. In questo modo, i server vengono avviati e scalati senza ritardi dell'installatore e le probabilità di errori casuali al momento del lancio sono ridotte. Puoi anche rivedere qualsiasi versione precedente dell'app esattamente come era in produzione lanciandone l'immagine, il che può essere utile per la diagnostica e la forensistica.

Deployment e configurazione

Successivamente, configura il deployment e la configurazione delle istanze dall'immagine di base.

Eseguire il deployment dell'ambiente

Per soddisfare i requisiti PCI DSS, assicurati di eseguire ogni volta il deployment dell'app corretta, di eseguirlo in modo sicuro e di non installare altri pacchetti software durante il deployment. Per semplificare la procedura di deployment, valuta la possibilità di creare un deployment automatico per la tua app utilizzando Terraform. Terraform ti consente di descrivere l'intero ambiente di elaborazione dei pagamenti, incluse le regole firewall, i gateway, i bilanciatori del carico e le istanze nel codice.

In un deployment automatico, devi verificare l'integrità del software in fase di deployment, che si tratti di software di terze parti o di tua proprietà. Puoi verificare il tuo software eseguendo un hash automatico su ogni pacchetto durante l'installazione. Dopo aver verificato un hash, puoi utilizzare un framework di test automatico per eseguire test di sicurezza e altri test e per verificare che i test siano stati superati.

Infine, quando esegui il deployment delle istanze Compute Engine, progetta un piano di recupero nel caso in cui le istanze non funzionino. Se il periodo di tempo in cui è accettabile un tempo di riposo è sufficientemente lungo, potrebbe essere sufficiente un piano di recupero manuale. In caso contrario, devi progettare un piano di recupero automatico. Per indicazioni, consulta la guida alla pianificazione del ripristino di emergenza, la sezione Progettazione di sistemi solidi e la sezione Creazione di applicazioni web scalabili e resilienti.

configura il tuo ambiente

Dopo aver eseguito il deployment delle istanze, assicurati che siano configurate correttamente. Installa software e librerie aggiuntivi sopra ogni immagine di base dell'istanza, in base alle esigenze. Per evitare la complessità, il sovraccarico e il rischio complessivo della configurazione manuale, utilizza uno strumento di gestione della configurazione automatizzata come Skaffold, Chef, Puppet, Ansible o Salt.

Implementazione dell'audit logging immutabile

La registrazione genera automaticamente audit log per un'ampia gamma di attività in molti prodotti. A lungo termine, puoi archiviare in modo sicuro i log immutabili utilizzando i blocchi dei bucket di Cloud Storage (sezione 10.3). I blocchi dei bucket ti consentono di impostare un criterio per rendere tutti gli oggetti immutabili e non eliminabili per un periodo di tempo specificato, da secondi a anni.

Implementazione dei log di flusso Virtual Private Cloud

Il servizio Log di flusso VPC è progettato per registrare i flussi di rete inviati o ricevuti dalle istanze di macchine virtuali. Puoi utilizzare questi log per il monitoraggio della rete, l'analisi forense e l'analisi della sicurezza in tempo reale (sezione 10.2).

Installazione dell'agente Logging

Dopo aver configurato iptables sui server, ogni server registra ogni attività nell'archiviazione a blocchi del server. Consulta la pagina dei prezzi di Logging per informazioni dettagliate sull'assegnazione gratuita e sui prezzi del trasferimento dei dati. Per conservare questi log e generare avvisi in base ad attività sospette, trasmettili tramite streaming a Logging e monitoraggio installando l'agente di logging su ogni server (sezione 10.3).

Integrare un sistema di rilevamento delle intrusioni

Per contribuire a garantire la sicurezza del tuo ambiente di elaborazione dei pagamenti, descritto nella sezione 11.5, utilizza un IDS (Intrusion Detection System) per sapere quando malintenzionati tentano di attaccare il sistema. Esistono due modi per inserire un IDS in un ambiente di elaborazione dei pagamenti: inserire un IDS in ogni punto di contatto o installare un IDS su ogni server.

Per ridurre la complessità dell'architettura dell'ambiente e semplificare la conformità a 11.5, installa un IDS su ogni server. Dopo aver eseguito ricerche e scelto il software IDS da utilizzare, includi l'installazione dell'IDS nello script di installazione all'avvio per ogni server.

Cloud IDS (Cloud Intrusion Detection System), un servizio di rilevamento delle intrusioni, offre il rilevamento delle minacce come intrusioni, malware, spyware e attacchi command-and-control sulla tua rete. Cloud IDS offre una visibilità completa sul traffico di rete, incluso il traffico nord/sud e est/ovest, consentendoti di monitorare le comunicazioni da VM a VM per rilevare il movimento laterale. Puoi anche utilizzare Cloud IDS per semplificare la conformità al requisito 11.5.

I log IDS rientrano nell'ambito della conformità PCI DSS e devono essere inviati a logging e monitoraggio per la generazione di report, l'invio di avvisi e il controllo.

Implementazione di Security Command Center

Security Command Center aiuta i team di sicurezza a raccogliere dati, identificare le minacce e rispondere prima che causino danni o perdite all'azienda. Offre informazioni approfondite sul rischio per app e dati, in modo da poter mitigare rapidamente le minacce alle risorse cloud e valutare lo stato generale. Con Security Command Center, puoi visualizzare e monitorare un inventario dei tuoi asset cloud, effettuare la scansione dei sistemi di archiviazione per individuare dati sensibili, rilevare le vulnerabilità web comuni e controllare i diritti di accesso alle risorse critiche, il tutto da un'unica dashboard centralizzata. Può aiutarti a rispettare diversi requisiti, tra cui le sezioni 5 e 6.4.

Automatizzare il deployment dell'app

Crea il tuo strumento di gestione della configurazione per recuperare e lanciare in modo sicuro la versione più recente della tua app. L'app può essere recuperata da qualsiasi posizione, ad esempio da Cloud Storage, purché la posizione sia sicura.

Molti degli strumenti di gestione della configurazione menzionati in precedenza supportano i flussi di lavoro di integrazione e deployment continui (CI/CD), che possono essere utilizzati anche per eseguire la scansione automatica (sezione 11.3) e per garantire che il codice venga esaminato (requisito 6.2.3).

Acquisizione dei log di Configuration Manager

Quando configuri il gestore della configurazione, assicurati che registri tutti i dettagli di installazione. Dopo aver completato la procedura di configurazione, assicurati che i log vengano inviati a Logging e monitoraggio.

Logging e monitoraggio

Per garantire la conformità a PCI DSS ai sensi della sezione 10, assicurati che ogni passaggio eseguito nel tuo ambiente di elaborazione dei pagamenti sia monitorato e registrato. Ogni attività del server su ogni istanza deve essere registrata e ogni azione dell'utente deve essere esaminabile in un secondo momento.

Attivazione di Access Transparency

Grazie a Access Transparency, ora la funzionalità di logging offre log quasi in tempo reale quando Google Cloud gli amministratori accedono ai tuoi contenuti. Gli audit log di Cloud forniscono già visibilità sulle azioni dei tuoi amministratori. Tuttavia, questo audit trail in genere esclude le azioni intraprese dal team di assistenza o di ingegneria del tuo cloud provider. Ad esempio, prima del logging delle approvazioni dell'accesso, se aprissi un ticket con l'Assistenza Google che richiedeva l'accesso ai dati, il ticket non verrebbe monitorato negli audit log di Cloud. L'approvazione dell'accesso colma questa lacuna, acquisendo log quasi in tempo reale di accessi mirati manuali da parte del team di assistenza o tecnico.

Access Approval ti consente di approvare esplicitamente l'accesso ai tuoi dati o alle tue configurazioni su Google Cloud prima che questo accesso venga eseguito. Access Approval fornisce inoltre informazioni sugli accessi da parte del team di assistenza e tecnico di Google.

Attivazione del logging delle regole firewall

Il logging delle regole firewall ti consente di attivare il logging a livello di singola regola. Può registrare le connessioni TCP e UDP all'interno di un VPC per qualsiasi regola creata personalmente. Questi possono essere utili per controllare l'accesso alla rete o per avvisare preventivamente che la rete viene utilizzata in un modo non approvato.

Utilizzo dei Controlli di servizio VPC

Controlli di servizio VPC ti consente di definire un perimetro di sicurezza attorno Google Cloud a risorse come bucket Cloud Storage, istanze Bigtable e set di dati BigQuery per limitare i dati in una rete VPC e contribuire a mitigare i rischi di esfiltrazione di dati (requisiti 1.3.1 e 1.3.2). Con i Controlli di servizio VPC, puoi mantenere privati i tuoi dati sensibili, approfittando delle funzionalità di archiviazione ed elaborazione dati completamente gestite diGoogle Cloud.

Configurazione dei log di flusso VPC

I log di flusso VPC registrano i flussi di traffico di rete inviati o ricevuti dalle istanze VM. I log sono utili ai sensi del PCI DSS per il monitoraggio, l'audit, la forensitica e l'analisi della sicurezza in tempo reale. Per ogni subnet della rete VPC è possibile attivare o disattivare i log di flusso in modo indipendente. Puoi ridurre al minimo la quantità di dati dei log attivando solo i log flussi nel tuo CDE ambito. I log flussi, combinati con le regole firewall in uscita, ti consentono di limitare il traffico in uscita agli endpoint autorizzati in modo verificabile e difficile da aggirare (requisiti 1.2.1 e 1.3.4).

Il seguente diagramma mostra in che modo i log di flusso VPC registrano i flussi di traffico di rete inviati o ricevuti dalle istanze VM."

Ambiente dati dei titolari con i log di flusso VPC abilitati
Figura 2. CDE con i log di flusso VPC abilitati.

Se hai bisogno di dati più dettagliati di quelli forniti dai log flusso, ad esempio il logging delle singole richieste HTTP, puoi implementare controlli nell'app o nel proxy per le richieste in uscita. A tale scopo, utilizza il tuo server proxy inverso configurato per inoltrare i log di accesso a Logging. Per istruzioni su come configurare un server proxy Squid su Compute Engine, consulta Configurare un proxy di rete. Per evitare colli di bottiglia, configura almeno due server proxy ridondanti.

Registrazione dei dati di accesso interni

Oltre a registrare le minacce esterne, monitora e registra anche l'attività delle persone che hanno accesso amministrativo al tuo ambiente di elaborazione dei pagamenti (sezione 10.2). Per farlo, puoi registrare i comandi della shell. Diversi strumenti open source possono controllare i comandi shell e inviarli al logging. Le opzioni più diffuse per questa attività includono OSSEC o Tripwire.

Configurare gli avvisi di monitoraggio

Configura il monitoraggio in modo da inviare avvisi in caso di problemi nel tuo ambiente di elaborazione dei pagamenti (sezione 10.6). Assicurati che gli avvisi coprano eventi ambientali, di controllo e delle app interne. Basati sulla strategia di invio di avvisi in base ai potenziali rischi o vettori di attacco per ogni componente della tua app di elaborazione dei pagamenti. Ad esempio, attiva gli avvisi di monitoraggio se il tuo IDS rileva tentativi di intrusione, che siano riusciti o meno. Puoi anche utilizzare il logging delle regole firewall per attivare avvisi in risposta a tentativi di violazione di criteri di rete specifici.

Streaming dei log in BigQuery

Registrazione dei log di streaming sia in Cloud Storage sia in BigQuery
Figura 3. Registrazione dei log in streaming sia in Cloud Storage sia in BigQuery.

Se vuoi, puoi inoltrare i log di Logging a BigQuery per analizzarli in un secondo momento. Per maggiori dettagli, consulta Panoramica di routing e archiviazione: sink. Poiché BigQuery è ottimizzato per eseguire query su set di dati di grandi dimensioni, è uno strumento ideale per l'analisi dei log su larga scala. I log possono anche essere registrati direttamente in BigQuery per i log che richiedono un'analisi quasi in tempo reale (requisito 10.4.1).

Utilizzo di Sensitive Data Protection per la sanificazione dei dati

Esistono molti motivi per utilizzare parti dei dati contenuti nell'app in ambito che non rientrano nell'ambito, ad esempio per l'analisi o lo sviluppo. Concedi alle app l'accesso ai dati PCI solo dopo che sono stati sottoposti a sanificazione con Sensitive Data Protection (Requisito 6.5.1).

Sicurezza delle app

Per contribuire alla sicurezza della tua app, devi prima valutare l'interfaccia amministratore. Puoi anche utilizzare Cloud Key Management Service.

Valutazione dell'interfaccia di amministrazione

La maggior parte delle app di e-commerce ha una propria interfaccia di amministrazione non console, come un portale di fatturazione per l'assistenza clienti. Uno strumento di questo tipo deve avere controlli di accesso rigorosi, accesso individualizzato che utilizza l'autenticazione a più fattori (sezione 8.4) e deve essere dotato di registrazione di controllo (sezione 10.2).

Tutti i log che crei devono rispondere a queste domande: chi ha fatto cosa? Dove lo hanno fatto? Quando l'ha fatto? In base alla sezione 2.2.7, tutto l'accesso a uno strumento di questo tipo deve utilizzare una crittografia di trasporto efficace. Utilizza la protezione dei dati sensibili per filtrare le informazioni sensibili prima di visualizzarle in qualsiasi strumento di amministrazione.

Utilizzo di Cloud Key Management Service (Cloud KMS)

Cloud KMS è un servizio che consente di gestire le chiavi di crittografia. Può generare, utilizzare, ruotare ed eliminare chiavi di crittografia AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256 ed EC P384. Cloud KMS ti consente di rimuovere le password in chiaro memorizzate nel codice o nei file di configurazione, il che semplifica la conformità alle sezioni 2.2.2, 3.6, 3.7 e 8.2.

Convalida dell'ambiente

Dopo aver implementato l'ambiente, ma prima che il traffico di produzione scorra al suo interno, devi convalidarlo:

  • Se sei un commerciante di livello 1, il tuo ambiente deve essere convalidato da un Qualified Security Assessor (QSA). Un QSA è un'azienda o un privato approvato dal PCI Security Standards Council per convalidare gli ambienti PCI e rilasciare il marchio di approvazione.
  • Se sei un commerciante di livello 2 o inferiore, puoi convalidare il tuo ambiente compilando il questionario di autovalutazione.

Passaggi successivi