Questa guida ti aiuta a imparare come implementare lo standard Payment Card Industry Data Security Standard (PCI DSS) per la tua attività su Google Cloud. La guida va oltre le linee guida sul cloud computing dei PCI SSC (PDF) per fornire informazioni di base sullo standard, spiegare il tuo ruolo nella conformità basata su cloud e quindi fornire le linee guida per progettare, eseguire il deployment e configurare un'app di elaborazione dei pagamenti utilizzando PCI DSS. Il tutorial illustra anche i metodi per monitorare, eseguire il logging e convalidare l'app.
Questo documento fa riferimento ai requisiti PCI DSS 4.0, ove applicabili.
Lo standard PCI Data Security Standard, creato dal PCI Security Standards Council, è uno standard di sicurezza delle informazioni per le aziende che gestiscono informazioni con 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 Visa, MasterCard, Discover, American Express, JCB o UnionPay devono rispettare gli standard PCI DSS e, in caso contrario, possono essere multate o penalizzate.
PCI DSS include classificazioni per diversi tipi di commercianti, da commercianti che raccoglino i dati di pagamento di persona a commercianti che esternalizzano 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 per l'elaborazione dei pagamenti.
- Configura l'ambiente di elaborazione dei pagamenti.
- Esegui il deployment e la configurazione dei server delle app.
- Configura il logging e il monitoraggio.
- Convalida l'ambiente di elaborazione dei pagamenti.
Definizioni
Questa guida utilizza molte frasi uniche. Di seguito sono riportati alcuni dei più comuni. Per ulteriori informazioni, consulta il glossario PCI DSS.
CDE: acronimo di ambiente dati del titolare della carta. Questo acronimo si riferisce a qualsiasi parte della tua app che conserva o trasferisce i dati del titolare della carta, incluso il numero dell'account pagamenti o qualsiasi informazione che consenta l'identificazione personale relativa alla carta.
Controlli di retribuzione: soluzioni alternative che possono essere prese in considerazione se un'entità non può soddisfare un requisito esplicitamente indicato, a causa di vincoli aziendali legittimi o tecnici. Le persone giuridiche devono mitigare in modo sufficiente il rischio associato al requisito quando implementano questi altri controlli. Consulta le appendici B e C della sezione "Controlli di compensazione" in Requisiti PCI DSS e procedure di valutazione della sicurezza per informazioni sull'uso dei controlli di compensazione.
PAN: acronimo di numero di conto bancario principale, noto anche come numero di account. È il numero univoco della carta di pagamento che identifica l'emittente e l'account del titolare.
QSA: acronimo di Qualified Security Assessor. I QSA sono qualificati dal PCI Security Standards Council (SSC) per eseguire valutazioni in loco PCI DSS. I requisiti di qualificazione per i qualificati sulla sicurezza Assessor (QSA) forniscono i dettagli sui requisiti per le società 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 un'entità. Questo vale solo per le persone giuridiche idonee per l'autovalutazione.
Ambito: i sistemi, le procedure e le persone da includere in una valutazione PCI DSS.
Tokenizzazione: un processo che sostituisce il numero di account principale (PAN) con un valore surrogato chiamato token. Il codice PAN viene quindi memorizzato in una ricerca sicura. La de-tokenizzazione è il processo inverso con la ricerca di un PAN tramite il relativo 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 delle carte. Questi requisiti sono suddivisi in dodici parti principali numerate e molte sottoparti. Questo documento fa riferimento a questi numeri di parti per aggiungere 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 (tipo) delle carte di pagamento e il numero di transazioni eseguite ogni anno (a livello).
Con l'aumento del numero di transazioni, il livello di commerciante PCI DSS aumenta e le linee guida di conformità PCI DSS diventano più severe. Al livello più alto del commerciante, il Livello 1, PCI DSS richiede un controllo. I livelli variano in base al brand della carta. Il livello 1 è definito da American Express come 2, 5 milioni di transazioni annue, mentre da Visa, Mastercard e Discover come 6 milioni di transazioni annuali. Per ciascun brand della carta sono previsti ulteriori requisiti di livello che esulano dall'ambito di questo documento. Assicurati che il tuo ambiente di elaborazione dei pagamenti sia sottoposto a controlli per supportare il tuo livello commerciante.
Poiché Google Cloud è un fornitore di servizi conforme allo standard PCI DSS 4.0 di livello 1, è in grado di supportare le tue esigenze di conformità PCI DSS indipendentemente dal livello commerciante della tua azienda. La sezione Impegno per la conformità illustra le aree coperte da Google per te.
L'altra variabile fondamentale è il tipo di query SAQ. La SAQ delinea i criteri che devi soddisfare per rispettare gli standard PCI DSS in caso di idoneità all'autovalutazione. Il tipo di query SAQ è determinato dall'architettura dell'app e dal modo esatto in cui gestisci i dati delle carte di pagamento. La maggior parte dei commercianti nel cloud sono una delle seguenti:
| Tipo di SAQ | Descrizione |
|---|---|
| A | Commercianti che hanno affidato in outsourcing l'elaborazione delle carte di pagamento a un sito di terze parti. I clienti abbandonano il tuo dominio (anche tramite un modulo web <iframe>), completano il pagamento e quindi tornano alla tua app.In altre parole, la tua azienda non può toccare i dati delle carte dei clienti in alcun modo. |
| A-EP | 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 delle carte includono elementi di 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 elaboratore sul lato client oppure il processore esegue il rendering di qualsiasi contenuto ospitato da te. |
| D | Commercianti che accettano pagamenti online e non sono idonei per i SAQ A o
SAQ A-EP. Questo tipo include tutti i commercianti che chiamano un'API elaboratore dei pagamenti dai propri server, indipendentemente dalla tokenizzazione. In altre parole, se non sei un SAQ A o un SAQ A-EP, sei SAQ D. SAQ D fa differenza tra commercianti e fornitori di servizi. I fornitori di servizi non sono descritti in questo documento e tutti i riferimenti SAQ D si rivolgono ai commercianti come definiti nello standard PCI DSS. |
Impegno per la conformità
Google utilizza una serie di tecnologie e processi per proteggere le informazioni archiviate sui propri server. Google ha convalidato in modo indipendente i requisiti PCI DSS che si applicano alle 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 notevole controllo sulle istanze di calcolo eseguite nell'infrastruttura di Google, Google non controlla la sicurezza del sistema operativo, dei pacchetti o delle app di cui i commercianti eseguono il deployment su Google Cloud. È tua responsabilità rispettare i requisiti PCI DSS per i pacchetti di sistemi operativi e le app di cui esegui il deployment, oltre ad altre personalizzazioni richieste dalla tua architettura.
Google Cloud segue i requisiti PCI DSS stabiliti per un fornitore di servizi di livello 1 e tutti i requisiti applicabili per i fornitori di servizi. La matrice di responsabilità condivisa di Google Cloud delinea gli obblighi di conformità dello standard PCI DSS. La matrice della responsabilità può essere un riferimento utile per perseguire la conformità PCI DSS ed eseguire i propri controlli PCI DSS.
Indicazioni sui prodotti
Questa sezione contiene indicazioni per i servizi Google Cloud di uso comune nelle architetture impiegate per ambienti PCI DSS.
App Engine
Utilizza le regole firewall in entrata e i controlli del traffico in uscita di App Engine.
Cloud Run
Utilizza le impostazioni in entrata, i Controlli di servizio VPC e i controlli in uscita sui connettori VPC di Cloud Run. Se necessario, configura un indirizzo IP in uscita statico.
Cloud Functions
Utilizza le impostazioni di rete in entrata e in uscita di Cloud Functions.
Cloud Logging
Registra le interazioni con Cloud Logging.
Cloud Monitoring
Monitorare le interazioni con Cloud Monitoring.
Google Kubernetes Engine
Per informazioni sull'utilizzo di Google Kubernetes Engine per gli ambienti PCI DSS, consulta Conformità PCI DSS su GKE.
Cloud Storage
Il requisito 3.5 stabilisce che un numero di conto principale (PAN) è protetto ovunque sia archiviato. Sebbene Google offra automaticamente la crittografia at-rest, non esegue automaticamente gli hash unidirezionale, il troncamento o la tokenizzazione richiesti anche dalle regole.
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
SAQ A
SAQ A è l'architettura di elaborazione dei pagamenti di base. I pagamenti vengono elaborati da una terza parte e le app o le pagine dei commercianti non accedono ai dati delle carte.
In linea generale, il flusso di elaborazione dei pagamenti è il seguente:
Il cliente effettua le selezioni e procede al pagamento.
L'app di pagamento reindirizza il cliente a un elaboratore dei pagamenti di terze parti.
Il cliente inserisce i dati della carta di pagamento in un modulo di pagamento di proprietà e gestito dal elaboratore di terze parti.
L'elaboratore dei pagamenti di terze parti controlla le informazioni della carta di pagamento, quindi addebita o rifiuta la carta.
Dopo l'elaborazione della transazione, l'elaboratore dei pagamenti di terze parti rimanda il cliente all'app del commerciante insieme ai dettagli della transazione.
L'app del commerciante invia una richiesta di verifica all'elaboratore dei pagamenti per confermare la transazione.
L'elaboratore dei pagamenti risponde per verificare i dettagli della transazione.
SAQ A-EP
L'architettura di elaborazione dei pagamenti SAQ A-EP è incentrata su un'app di elaborazione dei pagamenti in esecuzione su istanze di macchine virtuali Compute Engine. Queste istanze si trovano in una rete privata protetta e utilizzano canali sicuri per comunicare con servizi esterni alla rete.
In linea generale, il flusso di elaborazione dei pagamenti è il seguente:
Il cliente inserisce i dati della carta di pagamento in un modulo di pagamento di proprietà e di gestione della tua azienda.
Quando il cliente invia le proprie informazioni, queste vengono trasmesse in modo sicuro a un elaboratore dei pagamenti di terze parti.
L'elaboratore dei pagamenti di terze parti controlla le informazioni della carta di pagamento, quindi addebita o rifiuta la carta.
L'elaboratore dei pagamenti invia una risposta all'app di pagamento, che quindi passa un messaggio all'app principale.
Tutte queste interazioni vengono registrate e monitorate con Cloud Logging e Cloud Monitoring.
SAQ D
L'architettura di elaborazione dei pagamenti SAQ D è incentrata su un'app di elaborazione dei pagamenti in esecuzione su istanze di macchine virtuali Compute Engine. Queste istanze si trovano in una rete privata protetta e utilizzano canali sicuri per comunicare con servizi esterni alla rete.
In linea generale, il flusso di elaborazione dei pagamenti è il seguente:
Il cliente inserisce i dati della carta di pagamento in un modulo di pagamento di proprietà e di gestione della tua azienda.
Quando il cliente invia i dati, l'app per pagamenti riceve questi dati.
L'app per i pagamenti convalida i dati di pagamento e li trasmette in modo sicuro a un elaboratore dei pagamenti di terze parti tramite un'API di backend.
L'elaboratore dei pagamenti di terze parti controlla le informazioni della carta di pagamento, quindi addebita o rifiuta la carta.
L'elaboratore dei pagamenti invia una risposta all'app di pagamento, che quindi passa un messaggio all'app principale.
Tutte queste interazioni vengono registrate e monitorate con Logging e Monitoring.
Flusso rivolto al cliente di elaborazione dei pagamenti
SAQ A
Questa sezione descrive il flusso di elaborazione dei pagamenti di terze parti dal punto di vista dei clienti che utilizzano la tua app.
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 delle
limitazioni della condivisione delle risorse tra origini.
Quando il cliente invia le informazioni della carta di pagamento, l'elaboratore dei pagamenti accetta o rifiuta la carta, quindi reindirizza il cliente alla tua app. L'app quindi controlla la risposta alla transazione dell'elaboratore dei pagamenti e agisce di conseguenza. L'app non ha eseguito l'accesso o
gestito alcun dato della carta di pagamento.
SAQ A-EP
Questa sezione descrive lo stesso flusso di elaborazione dei pagamenti interno descritto in precedenza, ma dal punto di vista dei clienti che utilizzano la tua app.
Quando il cliente accede all'URL del tuo modulo di pagamento, il sito presenta un modulo ospitato dalla tua app per i pagamenti. Quando il cliente invia i dati della carta di pagamento, il modulo viene inviato direttamente all'elaboratore dei pagamenti. Il processore accetta o rifiuta la carta, quindi rimanda il cliente alla tua app. L'app quindi 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 accesso alle informazioni della carta di pagamento sul lato server.
SAQ D
Questa sezione descrive il flusso di elaborazione dei pagamenti interno dal punto di vista dei clienti che utilizzano la tua app.
Quando il cliente accede all'URL del tuo modulo di pagamento, viene indirizzato in modo sicuro al modulo tramite un bilanciatore del carico HTTPS. Quando il cliente invia i dati della carta di pagamento, l'app di elaborazione dei pagamenti invia tali informazioni in modo sicuro a un elaboratore dei pagamenti di terze parti. L'elaboratore dei pagamenti di terze parti accetta o rifiuta la carta, poi restituisce una risposta all'app di elaborazione dei pagamenti.
Flusso interno di elaborazione dei pagamenti
SAQ A e A-EP
Questa sezione descrive il flusso di elaborazione dei pagamenti dal punto di vista dei server che eseguono la tua app.
L'app di elaborazione dei pagamenti riceve e analizza la risposta restituita dall'elaboratore dei pagamenti di terze parti, quindi invia alcuni o tutti i dati di risposta all'app principale. A questo punto, l'app di elaborazione dei pagamenti ha terminato la transazione. L'app principale gestisce l'attività di notifica ai clienti.
SAQ D
Questa sezione descrive il flusso di elaborazione dei pagamenti interno dal punto di vista dei server che eseguono la tua app.
L'app di elaborazione dei pagamenti convalida le informazioni della carta di pagamento inviate dal cliente, quindi le invia all'elaboratore dei pagamenti tramite un'API di backend. Il processore tenta di effettuare 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 terminato la transazione. L'app principale gestisce l'attività di notifica al cliente e di consegna del prodotto.
Monitoraggio e logging del flusso di dati
Il flusso di monitoraggio e logging è progettato come segue:
Configurazione dell'ambiente di elaborazione dei pagamenti
In questa sezione viene descritto come configurare l'ambiente di elaborazione dei pagamenti. La configurazione include quanto segue:
- Creazione di un nuovo account Google Cloud per isolare l'ambiente di elaborazione dei pagamenti dall'ambiente di produzione.
- Limitazione dell'accesso al tuo ambiente.
- Configurazione delle risorse virtuali in corso.
- Progettare l'immagine Linux di base che utilizzerai per configurare i server delle app.
- Implementazione di una soluzione sicura per la gestione dei pacchetti.
Creazione di un nuovo account
Per semplificare le limitazioni di accesso e il controllo della conformità, crea un ambiente di elaborazione dei pagamenti con qualità di produzione completamente isolato dal tuo ambiente di produzione standard e da qualsiasi ambiente di sviluppo e QA (requisito 6.5.3). Per garantire l'isolamento, crea e utilizza un account Google Cloud separato dall'account dell'ambiente di produzione principale. Gli utenti esperti con la configurazione IAM (Identity and Access Management) possono realizzare un isolamento equivalente utilizzando progetti separati per il lavoro all'interno dell'ambito.
Limitazione dell'accesso all'ambiente
Consenti l'accesso all'ambiente di elaborazione dei pagamenti solo ai privati che eseguono il deployment del codice del tuo sistema di pagamento o che gestiscono le macchine del tuo sistema di pagamento (sezione 7.2 e requisito 8.2.1). Questo è noto come il principio del privilegio minimo. Utilizza i ruoli IAM per limitare l'accesso. Le best practice includono l'utilizzo dei ruoli laddove 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 servizi. Per ulteriori informazioni, consulta la guida alla sicurezza IAM.
L'accesso automatico a qualsiasi servizio gestito dovrebbe dipendere dagli account di servizio. Gli account di servizio semplificano il ciclo di vita della gestione delle app offrendoti la possibilità di gestire l'autenticazione e l'autorizzazione delle app. Questi account offrono un modo flessibile e sicuro per raggruppare le istanze di macchine virtuali con app e funzioni simili che hanno un'identità comune. Puoi applicare la sicurezza e controllo dell'accesso a livello di account di servizio tramite i ruoli IAM e le regole firewall VPC.
Le regole IAM applicate alle cartelle vengono ereditate da tutti gli elementi contenuti in quella cartella. Le autorizzazioni predefinite sono negazione tutto (requisito 7.2.3) e ogni regola applicata aggiunge solo autorizzazioni.
Il requisito 8.3.6 fornisce alcune regole di base per le password degli utenti. Il National In Institute of Standards and Technology (NIST) definisce un insieme più sicuro di regole per le password sicure nella sezione 5.1.1 del NIST SP800-63B. Google consiglia di seguire le linee guida sull'identità digitale del NIST, ove possibile.
PCI DSS SAQ D sezione 12.7 richiede che i singoli utenti con accesso all'ambiente in ambito superino un controllo dei precedenti, in conformità con le leggi locali, prima di concedere l'accesso all'ambiente. Per ridurre il rischio di violazioni della conformità, valuta la possibilità di eseguire questi controlli dei precedenti penali e di riferimento per ogni persona, indipendentemente dal tipo di conformità.
Protezione della rete
Per proteggere il traffico in entrata e in uscita da e verso la rete dell'app di elaborazione dei pagamenti, devi creare quanto segue:
- Criteri firewall di Cloud Next Generation o regole firewall di Compute Engine
- un tunnel Cloud VPN
- Un bilanciatore del carico delle applicazioni esterno
Per creare il tuo VPC, ti consigliamo anche Cloud NAT per un ulteriore livello di sicurezza di rete. Sono disponibili molte opzioni efficaci per proteggere le reti di istanze di Compute Engine e GKE.
Creazione delle regole firewall
Utilizza i criteri del firewall Cloud Next Generation o le regole firewall VPC 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 sorgenti:
- HTTPS pubblico, per consentire ai clienti di raggiungere la tua pagina di pagamento.
- La rete dell'app, in modo che l'app di elaborazione dei pagamenti possa ricevere risposte dall'elaboratore dei pagamenti di terze parti.
- La rete della tua sede interna, in modo da poter accedere alle istanze per scopi di controllo e gestione.
Utilizza le regole firewall su singole istanze per limitare il traffico in uscita. Puoi implementare queste regole in locale con iptables o, più in generale, utilizzando le regole firewall VPC e i tag di rete. Consenti il traffico in uscita solo dal modulo di pagamento all'elaboratore dei pagamenti di terze parti. Questa connessione deve essere solo HTTPS. Per testare il tuo lavoro, consulta la sezione sul logging delle regole firewall più avanti in questo documento.
Cloud DNS offre zone DNS private per consentirti di assegnare un nome in modo sicuro agli host all'interno del CDE senza la possibilità di diffondere al pubblico dati sensibili della topologia di rete.
Limita il traffico nel seguente modo:
| Origine | Destinazione | Porta | Direzione e motivo |
|---|---|---|---|
| Bilanciatore del carico pubblico | Modulo di pagamento di terze parti | TCP:443 | In entrata Accesso pubblico all'app di elaborazione dei pagamenti |
| Forma di pagamento di terze parti | Elaboratore dei pagamenti di terze parti | TCP:443 | In uscita Inoltro di richieste di AUTH al fornitore di servizi di pagamento |
| Elaboratore dei pagamenti di terze parti | L'app per l'elaborazione dei pagamenti | tcp:5480 | In entrata Accettazione di richieste di AUTH da 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 l'accesso ai log e alle macchine di sviluppo |
Inoltre, il seguente traffico avviene in modo sicuro nella rete interna dell'app di elaborazione dei pagamenti:
| Origine | Destinazione | Porta | Motivo |
|---|---|---|---|
| Modulo carta | Proxy PCI | tcp:5480 | Scambio di dati della carta criptati per il token dello strumento di pagamento |
| Tutti gli host | Server Google NTP | 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 a garantire la sicurezza del traffico dei clienti in entrata creando un Application Load Balancer esterno (sezioni 2.2.7 e 4.2). Per creare un bilanciatore del carico delle applicazioni esterno, devi:
- 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.
Assicurati che il dominio sia valido esaminando le impostazioni DNS nell'interfaccia di configurazione del dominio del registrar web.
Creazione di un'immagine Linux di base
PCI DSS contiene requisiti che descrivono come configurare 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:
Crea un elenco del software e delle librerie che devono essere installati su ogni server 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 necessari per eseguire l'app. I candidati potrebbero includere Google Cloud CLI, runtime e librerie specifici per lingua o un server web.
Crea un'istanza Compute Engine che utilizza una delle immagini del sistema operativo preconfigurate di Compute Engine.
Installa le librerie e il software che hai elencato in precedenza.
Installa e configura
ntpper mantenere sincronizzati gli orologi di sistema. La gestione degli orologi dei server con il protocollo Network Time Protocol garantisce l'integrità dei timestamp nei log (sezione 10.6).Assicurati che l'immagine segua le best practice per la creazione di un'immagine Compute Engine sicura (tutte la sezione 2.2).
Dopo aver configurato l'immagine di base, crea un'immagine disco di Compute Engine personalizzata dall'immagine. che ti consente di usare l'immagine Linux di base quando crei istanze di macchine virtuali.
Utilizzo della gestione sicura dei pacchetti
La gestione dei pacchetti è un componente fondamentale di un ambiente di hosting con protezione avanzata. Come indicato nella sezione 2.2, è necessario implementare gli standard di protezione accettati dal settore. A meno che non utilizzi Container-Optimized OS di Google, è probabile che tu abbia installato un gestore di pacchetti, come RPM, Yum o Apt. L'app potrebbe utilizzare il proprio gestore di pacchetti specifico del 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 considerare le origini degli aggiornamenti come un potenziale rischio per la sicurezza. Gli attacchi Supply-Side o upstream inclusi in modo malizioso nei pacchetti ospitati pubblicamente stanno diventando più comuni. Immagina gli effetti dell'installazione di un aggiornamento a SSH che contiene codice dannoso.
Puoi ridurre il rischio di attacchi lato fornitura creando un elenco di destinatari sicuri per i tuoi pacchi e verificando che corrispondano all'elenco. Tieni un elenco dei 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 di pacchetti 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 privato di gestione dei pacchetti e solo il software testato e approvato dall'host. Blocca il gestore di pacchetti in modo che non contatti altri server per ricevere aggiornamenti.
Idealmente, il processo di compilazione dell'app recupera e convalida tutti i pacchetti, poi crea una revisione dell'immagine disco personalizzata che include tutto ciò di cui il container ha bisogno. In questo modo, i server vengono avviati e scalati senza ritardi nel programma di installazione e riduce la probabilità di errori casuali al momento dell'avvio. Puoi anche rivedere qualsiasi versione precedente dell'app esattamente com'era in produzione avviando la relativa immagine, che può essere utile per la diagnostica e l'analisi forense.
Deployment e configurazione
Quindi, imposta il deployment e la configurazione delle istanze dall'immagine di base.
Deployment dell'ambiente
Per soddisfare i requisiti PCI DSS, assicurati di eseguire ogni volta il deployment dell'app corretta, di eseguire il deployment dell'app in modo sicuro e di non installare altri pacchetti software durante il deployment. Per semplificare il processo di deployment, puoi creare un deployment automatico per la tua app utilizzando Terraform. Terraform consente di descrivere l'intero ambiente di elaborazione dei pagamenti, inclusi i relativi firewall, gateway, bilanciatori del carico e istanze nel codice.
In un deployment automatico, devi verificare l'integrità del software di cui viene eseguito il deployment, sia che sia di terze parti o che sia tuo. Puoi verificare il software eseguendo un hash automatico su ogni pacchetto quando questo viene installato. Dopo la verifica dell'hash, puoi utilizzare un framework di test automatizzato per eseguire test di sicurezza e di altro tipo, nonché verificare che i test siano stati superati.
Infine, quando esegui il deployment delle istanze di Compute Engine, progetta un piano di ripristino in caso di errore delle istanze. Se la finestra di tempo di inattività accettabile è sufficientemente ampia, potrebbe essere sufficiente un piano di ripristino manuale. In caso contrario, devi progettare un piano di ripristino automatico. Per ulteriori indicazioni, consulta la Guida alla pianificazione del ripristino di emergenza, Progettazione di sistemi solidi e Creazione di app web scalabili e resilienti.
configura il tuo ambiente
Dopo il deployment delle istanze, assicurati che siano configurate correttamente. Installa software e librerie aggiuntivi sopra ogni immagine di base delle istanze in base alle tue esigenze. Per evitare la complessità, l'overhead e il rischio complessivo della configurazione manuale, utilizza uno strumento di gestione automatica della configurazione come Skaffold, Chef, Puppet, Ansible o Salt.
Implementazione dell'audit logging immutabile
Logging produce automaticamente audit log per un'ampia gamma di attività su 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 consentono di impostare un criterio per rendere tutti gli oggetti immutabili e non eliminabili per un periodo di tempo specificato, da secondi ad 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. È possibile utilizzare questi registri per il monitoraggio della rete, l'analisi forense e l'analisi della sicurezza in tempo reale (sezione 10.2).
Installazione dell'agente Logging
Dopo che hai configurato iptables sui tuoi server, ogni server registra ogni attività nell'archiviazione a blocchi del server. Consulta la pagina dei prezzi di Logging per i dettagli sui prezzi dell'allocazione gratuita e del trasferimento di dati. Per conservare questi log e generare avvisi basati sulle attività sospette, trasmettili in flussi su Logging e Monitoring installando l'agente Logging su ciascun server (sezione 10.3).
Integrazione di un sistema di rilevamento delle intrusioni
Per garantire la sicurezza dell'ambiente di elaborazione dei pagamenti, come descritto nella sezione 11.5, utilizza un sistema di rilevamento delle intrusioni (IDS), in modo da sapere quando i malintenzionati tentano di attaccare il sistema. Esistono due modi per inserire un IDS in un ambiente di elaborazione dei pagamenti: posizionare un IDS in ogni punto di ingresso o installare un IDS su ogni server.
Per ridurre la complessità dell'architettura dell'ambiente e per semplificare la conformità con la versione 11.5, installa un IDS su ogni server. Dopo aver effettuato una ricerca e scelto il software IDS da utilizzare, rendi l'installazione IDS parte dello script di installazione all'avvio per ogni server.
Cloud Intrusion Detection System (Cloud IDS), un servizio di rilevamento delle intrusioni, fornisce il rilevamento delle minacce per intrusioni, malware, spyware e attacchi command-and-control sulla tua rete. Cloud IDS offre visibilità completa sul traffico di rete, compreso il traffico da nord-sud e est-ovest, consentendo di monitorare la comunicazione da VM a VM per rilevare i movimenti laterali. 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 Monitoring per reporting, avvisi e controllo.
Implementazione di Security Command Center
Security Command Center aiuta i team di sicurezza a raccogliere dati, identificare le minacce e rispondere alle minacce prima che causino danni o perdite all'azienda. Offre insight approfonditi sui rischi correlati ad app e dati, in modo da poter mitigare rapidamente le minacce alle risorse cloud e valutare l'integrità complessiva. Con Security Command Center puoi visualizzare e monitorare un inventario dei tuoi asset cloud, scansionare i sistemi di archiviazione alla ricerca di dati sensibili, rilevare le vulnerabilità web comuni e rivedere i diritti di accesso alle risorse critiche, il tutto da un'unica dashboard centralizzata. Può aiutarti a soddisfare diversi requisiti, tra cui le sezioni 5 e 6.4.
Automatizzare il deployment delle app
Crea lo strumento di gestione delle configurazioni per recuperare e avviare in modo sicuro la versione più recente dell'app. L'app può essere recuperata da qualsiasi posizione, ad esempio Cloud Storage, purché questa posizione sia sicura.
Molti degli strumenti di gestione della configurazione menzionati in precedenza supportano 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 rivisto (requisito 6.2.3).
Acquisizione dei log di Configuration Manager
Quando imposti il gestore di configurazione, assicurati che registri tutti i dettagli di installazione. Dopo aver completato il processo di configurazione, assicurati che carichi i log in Logging e Monitoring.
Logging e monitoraggio
Per garantire la conformità PCI DSS alla sezione 10, verifica che ogni passaggio eseguito nell'ambiente di elaborazione dei pagamenti sia monitorato e registrato. Ogni attività del server in ogni istanza deve essere registrata e ogni azione dell'utente deve poter essere esaminata in un secondo momento.
Attivazione di Access Transparency
Grazie a Access Transparency, Logging offre ora log quasi in tempo reale quando gli amministratori di Google Cloud accedono ai tuoi contenuti. I log di Cloud Audit Logs forniscono già visibilità sulle azioni dei tuoi amministratori. Tuttavia, questo audit trail in genere esclude le azioni intraprese dal team di assistenza o di progettazione del provider cloud. Ad esempio, prima del logging di Access Approval, se avevi aperto un ticket con l'Assistenza Google che richiedeva l'accesso ai dati, l'evento non sarebbe stato monitorato in Cloud Audit Logs. Access Approval colma questa lacuna, acquisendo log quasi in tempo reale degli accessi manuali mirati da parte del team di assistenza o tecnico.
Access Approval consente di approvare esplicitamente l'accesso ai tuoi dati o alle tue configurazioni su Google Cloud prima che venga eseguito. Access Approval fornisce anche informazioni sugli accessi da parte del team tecnico e dell'Assistenza Google.
Abilitazione del logging delle regole firewall in corso...
Il logging delle regole firewall consente di abilitare il logging a livello di singola regola. Può registrare connessioni TCP e UDP all'interno di un VPC per qualsiasi regola creata da te. Possono essere utili per verificare l'accesso alla rete o per comunicare in anticipo che la rete viene utilizzata in un modo non approvato.
Utilizzo dei Controlli di servizio VPC
Controlli di servizio VPC consente di definire un perimetro di sicurezza intorno alle risorse Google Cloud 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 Controlli di servizio VPC puoi mantenere privati i tuoi dati sensibili, sfruttando le capacità di archiviazione ed elaborazione dei dati completamente gestite di Google 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 in PCI DSS per il monitoraggio, il controllo, l'analisi forense e l'analisi della sicurezza in tempo reale. Per ogni subnet di rete VPC puoi abilitare o disabilitare i log di flusso in modo indipendente. Puoi ridurre al minimo la quantità di dati di log attivando solo i log di flusso sul CDE nell'ambito. I log di flusso, combinati con le regole firewall in uscita, consentono di limitare il traffico in uscita verso gli endpoint autorizzati in modo controllabile e difficile da eludere (requisiti 1.2.1 e 1.3.4).
Il seguente diagramma mostra in che modo Log di flusso VPC registrano i flussi di traffico di rete inviati o ricevuti dalle istanze VM.
Se hai bisogno di dati più dettagliati di quelli forniti dai log di flusso, ad esempio il logging delle singole richieste HTTP, puoi implementare i controlli nella tua app o nelle richieste in uscita proxy. Per farlo, utilizza il tuo server proxy inverso configurato per inoltrare i log degli accessi a Logging. Per istruzioni sulla configurazione di un server proxy Squid su Compute Engine, vedi Configurare un proxy di rete. Per evitare colli di bottiglia, configura almeno due server proxy ridondanti.
Logging dei dati di accesso interno
Oltre a registrare le minacce esterne, monitora e registra anche l'attività dei soggetti che hanno accesso amministrativo all'ambiente di elaborazione dei pagamenti dell'utente (sezione 10.2). Per farlo, puoi registrare i comandi della shell. Diversi strumenti open source possono controllare i comandi della shell e inviarli al logging. Le opzioni più comuni per questa attività includono OSSEC o Tripwire.
Configurazione degli avvisi di monitoraggio
Configura Monitoring per inviare avvisi in caso di problemi nell'ambiente di elaborazione dei pagamenti (sezione 10.6). Assicurati che gli avvisi coprano gli eventi relativi all'ambiente, al controllo e alle app interni. Basa la tua strategia di avviso sui potenziali vettori di rischio o attacco per ogni componente dell'app di elaborazione dei pagamenti. Ad esempio, attiva avvisi di Monitoring se il tuo IDS rileva tentativi di intrusione, sia riusciti che non riusciti. Puoi anche utilizzare il logging delle regole firewall per attivare avvisi in risposta ai tentativi di violazione di criteri di rete specifici.
Streaming dei log in BigQuery
Facoltativamente, puoi instradare i log di Logging a BigQuery per analizzarli in un secondo momento. Per i dettagli, consulta Panoramica del routing e dell'archiviazione: sink. Poiché è ottimizzato per eseguire query su grandi set di dati, BigQuery è lo strumento ideale per l'analisi dei log su larga scala. Logging può anche accedere direttamente a BigQuery per i log che richiedono un'analisi quasi in tempo reale (requisito 10.4.1).
Usare Sensitive Data Protection per eliminare i dati
Esistono molti motivi per utilizzare parti dei dati contenuti nella tua app inclusa nell'ambito che non rientrano nell'ambito, ad esempio per l'analisi o lo sviluppo. Concedi alle app l'accesso a dati PCI solo dopo che sono stati sottoposti a sanitizzazione con Sensitive Data Protection (requisito 6.5.1).
Sicurezza delle app
Per contribuire a proteggere la tua app, devi prima valutare l'interfaccia di amministrazione. Potresti anche voler 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, ad esempio un portale di fatturazione dell'assistenza clienti. Uno strumento di questo tipo deve disporre di controlli dell'accesso affidabili, avere accesso individuale che utilizzi l'autenticazione a più fattori (sezione 8.4) e deve essere instrumentato con audit logging (sezione 10.2).
Ogni log creato dovrebbe rispondere a queste domande: chi ha fatto cosa? Dove l'hanno fatto? Quando l'hanno fatto? In base alla sezione 2.2.7, tutti gli accessi a uno strumento di questo tipo devono utilizzare una crittografia di trasporto efficace. Utilizza Sensitive Data Protection 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 consente di rimuovere le password in testo normale archiviate in file di codice o di configurazione, semplificando la conformità con le sezioni 2.2.2, 3.6, 3.7 e 8.2.
Convalida dell'ambiente
Dopo l'implementazione dell'ambiente, ma prima che qualsiasi traffico di produzione vi passi dentro, devi convalidare l'ambiente:
- 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 sigillo di approvazione.
- Se sei un commerciante di livello 2 o un livello inferiore, puoi convalidare il tuo ambiente compilando il questionario di autovalutazione.
Passaggi successivi
- Libreria di documenti PCI DSS
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.