Questa guida ti aiuta a scoprire come implementare lo standard Payment Card Industry Data Security Standard (PCI DSS) per la tua attività su Google Cloud. Questa guida va oltre le linee guida per il cloud computing PCI SSC (PDF) per fornire informazioni 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, registrare e convalidare l'app.
Ove applicabile, questo documento fa riferimento ai requisiti PCI DSS 4.0.
Lo standard PCI Data Security, creato dal PCI Security Standards Council, è uno standard di sicurezza delle informazioni per le aziende che gestiscono i dati delle carte di pagamento (sia di credito che di debito). Il PCI Security Standards Council comprende tutte le principali società di carte di pagamento. Le attività che accettano Visa, MasterCard, Discover, American Express, JCB o UnionPay sono tenute a rispettare lo standard PCI DSS e, in caso contrario, possono essere multe o penalizzate.
PCI DSS include le classificazioni per diversi tipi di commercianti, da commercianti che raccogliono di persona i dati di pagamento a commercianti che esternalizzano completamente l'elaborazione dei pagamenti. Questa guida illustra i tipi di commercianti SAQ A, SAQ A-EP e SAQ D.
Obiettivi
- Esaminare l'architettura delle app di elaborazione dei pagamenti.
- Imposta 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 univoche. Ecco alcune delle più comuni. Per ulteriori informazioni, consulta il glossario PCI DSS.
CDE: l'acronimo di cardholder dataenvironment (ambiente dati per titolari di carte). Questo acronimo si riferisce a qualsiasi parte dell'app che contenga o trasferisce i dati del titolare della carta, incluso il numero di conto 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 può soddisfare un requisito in modo esplicito come dichiarato a causa di vincoli aziendali legittimi o documentati. Le persone giuridiche devono mitigare sufficientemente il rischio associato al requisito quando implementano questi altri controlli. Consultare le appendici B e C dei controlli "compensativi" in Requisiti PCI DSS e procedure di valutazione della sicurezza per indicazioni sull'uso dei controlli compensativi.
PAN: acronimo di primary account number (numero di conto bancario principale). È il 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 l'esecuzione di valutazioni PCI DSS in loco. Il documento Requisiti di idoneità per i responsabili della sicurezza qualificati (QSA) fornisce dettagli sui requisiti per le aziende e i dipendenti di QSA.
SAQ: l'acronimo di Self-Assessment Questionnaire, lo strumento di reporting utilizzato per documentare i risultati dell'autovalutazione della valutazione PCI DSS di un'entità. Questo vale solo per le entità 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 conto bancario principale (PAN) con un valore surrogato chiamato token. Il PAN viene quindi memorizzato in una ricerca sicura. La de-tokenizzazione è il processo inverso di ricerca di un PAN per 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 numerate principali e molte sottoparti. Questo documento fa riferimento a questi numeri di parte per aggiungere contesto, ma i riferimenti alla sezione non sono un elenco esaustivo dei requisiti applicabili.
I requisiti di conformità PCI DSS variano a seconda del modo in cui la tua azienda gestisce le transazioni con carta di pagamento (tipo) e dal numero di transazioni eseguite ogni anno (a livello).
Man mano che il numero di transazioni aumenta, il tuo livello commerciante PCI DSS aumenta e le linee guida di conformità PCI DSS diventano più rigide. Al livello 1 del commerciante (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 annuali, mentre da Visa, Mastercard e Discover 6 milioni di transazioni annuali. Ogni brand della carta ha requisiti di livello aggiuntivi che esulano dall'ambito di applicazione del presente documento. Assicurati che l'ambiente di elaborazione dei pagamenti sia controllato per supportare il tuo livello commerciante.
Poiché Google Cloud è un provider di servizi conforme allo standard PCI DSS 4.0 di livello 1, può supportare le tue esigenze di conformità PCI DSS indipendentemente dal livello commerciante della tua azienda. La sezione Impegno a conformità illustra le aree coperte da Google.
L'altra variabile fondamentale è il tipo di SAQ. Il SAQ delinea i criteri da seguire per rispettare lo standard PCI DSS in caso di idoneità per l'autovalutazione. Il tipo di SAQ è determinato dall'architettura dell'app e dal modo preciso in cui gestisci i dati della carta di pagamento. La maggior parte dei commercianti nel cloud sono uno dei seguenti:
| Tipo di SAQ | Descrizione |
|---|---|
| A | Commercianti che hanno completamente affidato l'elaborazione delle carte di pagamento a un sito di terze parti. I clienti lasciano il tuo dominio (anche tramite un modulo web di <iframe>), completano il pagamento e poi tornano alla tua app.In altre parole, la tua azienda non può in alcun modo modificare i dati della carta del cliente. |
| 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 del processo. I commercianti
che possono accedere ai dati delle carte includono elementi delle pagine controllate 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 sul lato client oppure quest'ultimo esegue il rendering dei contenuti che ospiti. |
| D | Commercianti che accettano pagamenti online e non sono idonei per SAQ A o
SAQ A-EP. Questo tipo include tutti i commercianti che chiamano un'API di elaborazione dei pagamenti dai propri server, indipendentemente dalla tokenizzazione. In altre parole, se non sei SAQ A o SAQ A-EP, sei SAQ D. SAQ D fa distinzione tra commercianti e fornitori di servizi. In questo documento non vengono trattati i fornitori di servizi e tutti i riferimenti SAQ D indirizzino i commercianti come definito 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 di 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 loro istanze di calcolo eseguite sull'infrastruttura di Google, non controlla la sicurezza per il sistema operativo, i pacchetti o le app di cui i commercianti eseguono il deployment su Google Cloud. È tua responsabilità rispettare i requisiti PCI DSS per le app e i pacchetti del sistema operativo 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 illustra gli obblighi di conformità dello standard PCI DSS. La matrice di responsabilità può essere un riferimento utile per perseguire la conformità PCI DSS ed eseguire i tuoi controlli PCI DSS.
Indicazioni relative ai prodotti
Questa sezione contiene indicazioni per i servizi Google Cloud di uso comune nelle architetture usate per ambienti PCI DSS.
App Engine
Utilizza le regole firewall in entrata di App Engine e i controlli del traffico in uscita.
Cloud Run
Utilizza le impostazioni di traffico in entrata di Cloud Run, i Controlli di servizio VPC e i controlli in uscita sui connettori VPC. 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 ambienti PCI DSS, consulta Conformità PCI DSS su GKE.
Cloud Storage
Il requisito 3.5 prevede che il numero di conto bancario principale (PAN) sia protetto ovunque sia archiviato. Anche se Google offre automaticamente la crittografia at-rest, non esegue automaticamente gli hash unidirezionali, il troncamento o la tokenizzazione richiesti dalle regole.
Architetture di esempio
Questa sezione illustra gli approcci per implementare un ambiente conforme agli standard SAQ A, SAQ A-EP e SAQ D.
Panoramica dell'architettura
SAQ A
L'SAQ A è l'architettura di base per l'elaborazione dei pagamenti. I pagamenti vengono elaborati da una terza parte e le app o le pagine dei commercianti non possono accedere ai dati delle carte.
A livello 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 una forma di pagamento di proprietà e gestita dal responsabile del trattamento di terze parti.
L'elaboratore dei pagamenti di terze parti controlla i dati 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 di SAQ A-EP è incentrata su un'app di elaborazione dei pagamenti in esecuzione su istanze di macchine virtuali di Compute Engine. Queste istanze si trovano in una rete privata protetta e utilizzano canali sicuri per comunicare con servizi esterni alla rete.
A livello generale, il flusso di elaborazione dei pagamenti è il seguente:
Il cliente inserisce i dati della carta di pagamento in una forma di pagamento di proprietà e gestita dall'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 i dati della carta di pagamento, quindi addebita o rifiuta la carta.
L'elaboratore dei pagamenti invia una risposta all'app di pagamento, che trasmette 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 di Compute Engine. Queste istanze si trovano in una rete privata protetta e utilizzano canali sicuri per comunicare con servizi esterni alla rete.
A livello generale, il flusso di elaborazione dei pagamenti è il seguente:
Il cliente inserisce i dati della carta di pagamento in una forma di pagamento di proprietà e gestita dall'azienda.
Quando il cliente invia le proprie informazioni, la tua app per pagamenti riceve le informazioni del modulo.
L'app di pagamento convalida i dati di pagamento e li trasmette in modo sicuro a un elaboratore dei pagamenti di terze parti tramite un'API backend.
L'elaboratore dei pagamenti di terze parti controlla i dati della carta di pagamento, quindi addebita o rifiuta la carta.
L'elaboratore dei pagamenti invia una risposta all'app di pagamento, che trasmette un messaggio all'app principale.
Tutte queste interazioni vengono registrate e monitorate con Logging e Monitoring.
Flusso di elaborazione dei pagamenti rivolto ai clienti
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. L'app non può accedere o monitorare i contenuti di <iframe> a causa delle limitazioni per la condivisione delle risorse tra origini.
Quando il cliente invia i dati della sua carta di pagamento, l'elaboratore dei pagamenti accetta o rifiuta la carta, quindi rimanda il cliente alla tua app. L'app controlla la risposta della transazione dell'elaboratore dei pagamenti e agisce di conseguenza. L'app non ha eseguito l'accesso o
gestito i dati della carta di pagamento.
SAQ A-EP
Questa sezione descrive lo stesso flusso di elaborazione interno dei pagamenti descritto in precedenza, ma dal punto di vista dei clienti che utilizzano la tua app.
Quando il cliente accede all'URL della tua forma 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 della 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 sul lato server.
SAQ D
Questa sezione descrive il flusso di elaborazione interna dei pagamenti dal punto di vista dei clienti che utilizzano la tua app.
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 carta di pagamento, la tua app di elaborazione dei pagamenti invia in sicurezza le informazioni 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
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, la transazione termina con l'app di elaborazione dei pagamenti. L'app principale gestisce l'attività di informare i clienti.
SAQ D
Questa sezione descrive il flusso di elaborazione interna dei pagamenti dal punto di vista dei server che eseguono la tua app.
L'app di elaborazione dei pagamenti convalida i dati della carta di pagamento inviati dal cliente e quindi li invia all'elaboratore dei pagamenti tramite un'API backend. Il processore prova a eseguire l'addebito e risponde con i dettagli della transazione. L'app riceve ed elabora la risposta, quindi invia alcuni o tutti i dati di risposta all'app principale. A questo punto, la transazione termina con l'app di elaborazione dei pagamenti. L'app principale gestisce l'attività di notifica al cliente e consegna del prodotto.
Flusso di dati di monitoraggio e logging
Il flusso di monitoraggio e logging è progettato come segue:
Configurare l'ambiente di elaborazione dei pagamenti
Questa sezione descrive 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.
- Accesso limitato al tuo ambiente.
- Configurazione delle risorse virtuali.
- Progettare l'immagine Linux di base che userai per configurare i server delle app.
- Implementazione di una soluzione sicura per la gestione dei pacchetti.
Configurare un nuovo account
Per semplificare la limitazione dell'accesso e il controllo di conformità, crea un ambiente di elaborazione dei pagamenti di qualità per la 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 principale dell'ambiente di produzione. Gli utenti che hanno esperienza con la configurazione di Identity and Access Management (IAM) possono ottenere un isolamento equivalente utilizzando progetti separati per il lavoro nell'ambito.
Limitazione dell'accesso all'ambiente
Consenti l'accesso all'ambiente di elaborazione dei pagamenti solo alle persone che implementano il codice del tuo 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 IAM.
L'accesso automatico a qualsiasi servizio gestito deve dipendere dagli account di servizio. Gli account di servizio semplificano il ciclo di vita della gestione delle app, fornendoti un modo per 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 in modo forzato sicurezza e controllo dell'accesso a livello di account di servizio tramite ruoli IAM e regole firewall VPC.
Le regole IAM che applichi alle cartelle vengono ereditate da tutti gli elementi contenuti in quella cartella. Le autorizzazioni predefinite sono "Nega tutte" (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 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, quando possibile.
La sezione 12.7 del PCI DSS SAQ D richiede che le persone con accesso all'ambiente nell'ambito di applicazione superino un controllo dei precedenti, in conformità con le leggi locali, prima di ottenere l'accesso all'ambiente. Per ridurre il rischio di violazioni della conformità, ti consigliamo di eseguire questi controlli dei precedenti penali e dei controlli di riferimento su ogni privato, indipendentemente dal tipo di conformità.
Protezione della rete
Per proteggere il traffico in entrata e in uscita da e verso la rete di app di elaborazione dei pagamenti, devi creare quanto segue:
- Criteri firewall di nuova generazione Cloud o regole firewall di Compute Engine
- un tunnel Cloud VPN
- Un bilanciatore del carico delle applicazioni esterno
Per creare il tuo VPC, consigliamo inoltre di Cloud NAT per un ulteriore livello di sicurezza di rete. Sono disponibili molte opzioni efficaci per proteggere le reti delle istanze di Compute Engine e GKE.
Creazione delle regole firewall in corso...
Utilizza i criteri del firewall di 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 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 tua rete aziendale interna, in modo che tu possa 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 modulo pagamenti 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 in modo da poter assegnare un nome sicuro agli host all'interno del CDE senza la potenziale divulgazione di dati sensibili della topologia di rete al pubblico.
Limita il traffico come segue:
| Origine | Destinazione | Porta | Direzione 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 |
| Forma di pagamento di terze parti | Responsabile dell'elaborazione dei pagamenti di terze parti | tcp:443. | In uscita Inoltro delle richieste AUTH al fornitore di servizi di pagamento |
| Responsabile dell'elaborazione dei pagamenti di terze parti | La tua app di elaborazione dei pagamenti | tcp:5480. | In entrata Accettazione di richieste AUTH dai sistemi di pagamento (non contiene i dati del titolare della carta) |
| La rete di uffici dell'azienda | vpn-gateway | tcp:8000 | In entrata Accesso all'ambiente di elaborazione dei pagamenti per l'accesso a log e 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 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 l'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 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:
- 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 firmato che è stato registrato per il sottodominio.
Assicurati che il tuo dominio sia valido osservando le impostazioni DNS nell'interfaccia di configurazione del dominio del registrar web.
Creazione di un'immagine Linux di base
Il 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 ciascun 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 la quantità minima di software e librerie necessarie per eseguire l'app. I candidati potrebbero includere Google Cloud CLI, runtime e librerie specifici per linguaggio 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 elencato in precedenza.
Installa e configura
ntpper mantenere sincronizzati gli orologi di sistema. La gestione degli orologi del server con il 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 (tutti nella sezione 2.2).
Dopo aver configurato l'immagine di base, crea un'immagine disco di Compute Engine personalizzata dalla tua immagine. Questa immagine 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 protetto dalla sicurezza. In base alla sezione 2.2, devi implementare gli standard di protezione accettati dal settore. A meno che non utilizzi Container-Optimized OS di Google, probabilmente hai installato un gestore di pacchetti, ad esempio RPM, Yum o Apt. La tua app potrebbe utilizzare il proprio gestore di pacchetti specifico per il linguaggio di programmazione, come NPM, PyPi o Composer, e scaricare le dipendenze alla prima esecuzione.
Se la tua app può recuperare aggiornamenti da internet, devi considerare le fonti di aggiornamento come un potenziale rischio per la sicurezza. Gli attacchi Supply-Side (o upstream) inclusi maliziosamente 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 Supply-Side creando un elenco di destinatari sicuri per i tuoi pacchetti e verificando che corrispondano all'elenco. Conserva un elenco dei numeri delle versioni testate e approvate per ogni pacchetto che utilizzi. Annota 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 utilizza solo il software testato e approvato dall'host. Blocca il gestore di pacchetti in modo che non possa contattare gli altri server per gli aggiornamenti.
Idealmente, il processo di compilazione dell'app recupera e convalida tutti i pacchetti, quindi 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 del programma di installazione e la possibilità che si verifichino errori casuali al momento del lancio. Puoi anche rivedere qualsiasi versione precedente dell'app esattamente come era in produzione avviando la relativa immagine, che può essere utile per la diagnostica e l'analisi forense.
Deployment e configurazione
Imposta quindi 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, valuta la possibilità di creare un deployment automatico per la tua app utilizzando Terraform. Terraform consente di descrivere l'intero ambiente di elaborazione dei pagamenti, inclusi regole 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, che sia di terze parti o proprietario. Puoi verificare il tuo software eseguendo un hash automatico su ogni pacchetto durante l'installazione del pacchetto. Dopo aver verificato un hash, puoi utilizzare un framework di test automatico per eseguire test di sicurezza e altri test, nonché per verificare che i test siano stati superati.
Infine, quando esegui il deployment delle istanze Compute Engine, progetta un piano di ripristino in caso di errore. Se il periodo di inattività accettabile è sufficiente, un piano di ripristino manuale potrebbe essere sufficiente. In caso contrario, devi progettare un piano di ripristino automatico. Per indicazioni, consulta la Guida alla pianificazione del ripristino di emergenza, la Progettazione di sistemi robusti e la 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 su ogni immagine base dell'istanza, se necessario. Per evitare la complessità, l'overhead e il rischio complessivo della configurazione manuale, utilizza uno strumento di gestione delle configurazioni automatiche come Skaffold, Chef, Puppet, Ansible o Salt.
Implementazione di audit logging immutabile
Logging produce 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 consentono di impostare un criterio per rendere tutti gli oggetti immutabili e non eliminabili per il 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 aver configurato iptables sui tuoi server, ciascun 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 su attività sospette, inviali in modalità flusso a 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 del tuo ambiente di elaborazione dei pagamenti, 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 del tuo ambiente e semplificare la conformità alla versione 11.5, installa un IDS su ciascun server. Dopo aver esaminato e scelto il software IDS da utilizzare, rendi l'installazione IDS parte dello script di installazione dell'avvio per ciascun 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 piena visibilità sul traffico di rete, compreso quello nord-sud e est-ovest, consentendo di monitorare le comunicazioni 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 il reporting, gli 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 alle minacce prima che causino danni o perdite all'azienda. Offre insight approfonditi sui rischi relativi ad app e dati in modo da poter mitigare rapidamente le minacce alle risorse cloud e valutare lo stato di salute generale. Con Security Command Center, puoi visualizzare e monitorare un inventario dei tuoi asset cloud, eseguire la scansione dei sistemi di archiviazione per rilevare dati sensibili, rilevare vulnerabilità web comuni e rivedere i diritti di accesso alle risorse critiche, il tutto da un'unica dashboard centralizzata. Può aiutarti a rispettare diversi requisiti, incluse 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 località, ad esempio Cloud Storage, purché sia sicura.
Molti degli strumenti di gestione della configurazione citati in precedenza supportano flussi di lavoro di integrazione e deployment continui (CI/CD), che possono essere utilizzati anche per eseguire la scansione automatizzata (sezione 11.3) e per garantire che il codice venga rivisto (requisito 6.2.3).
Acquisizione dei log di Configuration Manager
Quando imposti Gestore della configurazione, assicurati che registri tutti i dettagli di installazione. Dopo aver completato il processo di configurazione, assicurati che invii i log a Logging e Monitoring.
Logging e monitoraggio
Per garantire la conformità allo standard PCI DSS di cui alla sezione 10, assicurati che ogni fase dell'ambiente di elaborazione dei pagamenti sia monitorata e registrata. Ogni attività del server su ogni istanza deve essere registrata e ogni azione dell'utente deve poter essere esaminata in un secondo momento.
Attivazione di Access Transparency
Tramite Access Transparency, Logging ora offre log quasi in tempo reale quando gli amministratori di Google Cloud accedono ai tuoi contenuti. I log di Cloud Audit Logs offrono già visibilità sulle azioni dei tuoi amministratori. Tuttavia, questo audit trail in genere esclude le azioni intraprese dal team di assistenza o dal team tecnico del tuo provider cloud. Ad esempio, prima del logging di Access Approval, se avevi aperto con l'Assistenza Google un ticket che richiedeva l'accesso ai dati, 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 dati o alle configurazioni su Google Cloud prima che venga eseguito. Access Approval offre inoltre informazioni sugli accessi da parte dell'Assistenza Google e del team Engineering.
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 che crei autonomamente. Queste possono essere utili per controllare l'accesso alla rete o per avvisare preventivamente che la rete viene utilizzata in modo non approvato.
Utilizzo dei Controlli di servizio VPC
Controlli di servizio VPC consente di definire un perimetro di sicurezza attorno 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 i Controlli di servizio VPC puoi mantenere privati i tuoi dati sensibili, sfruttando le funzionalità di archiviazione ed elaborazione dati completamente gestite di Google Cloud.
Configurazione dei log di flusso VPC
Log di flusso VPC registra i flussi di traffico di rete inviati o ricevuti dalle istanze VM. I log sono utili nello standard PCI DSS per il monitoraggio, l'auditing, le indagini forensi e l'analisi della sicurezza in tempo reale. Per ogni subnet di rete VPC è possibile abilitare o disabilitare i log di flusso in modo indipendente. Puoi ridurre al minimo la quantità di dati di log abilitando i log di flusso solo nell'ambito CDE. I log di flusso, combinati con le regole firewall in uscita, consentono di limitare il traffico in uscita verso gli endpoint autorizzati in un modo verificabile e difficile da eludere (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.
Se hai bisogno di dati più dettagliati rispetto a quelli forniti dai log di flusso, ad esempio il logging di singole richieste HTTP, puoi implementare dei controlli nella tua app o nelle richieste in uscita tramite proxy. A tale scopo, utilizza il tuo server proxy inverso configurato per inoltrare i log di accesso a Logging. Per istruzioni sulla configurazione di un server proxy Squid su Compute Engine, consulta 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à delle persone che hanno accesso in qualità di amministratore 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ù utilizzate per questa attività includono OSSEC o Tripwire.
Configurazione degli avvisi di monitoraggio
Configurare Monitoring per l'invio di 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. Basa la tua strategia di avviso sui potenziali vettori di rischio o attacco per ogni componente della tua app di elaborazione dei pagamenti. Ad esempio, attiva gli avvisi di Monitoring se il tuo IDS rileva tentativi di intrusione, riusciti o non,. Puoi anche utilizzare il logging delle regole firewall per attivare avvisi in risposta ai tentativi di violare criteri di rete specifici.
Streaming dei log in BigQuery
Facoltativamente, puoi eseguire il routing dei log di Logging a BigQuery per analizzarli in un secondo momento. Per i dettagli, consulta Panoramica su routing e archiviazione: sink. Poiché è ottimizzato per eseguire query su set di dati di grandi dimensioni, è lo strumento ideale per l'analisi dei log su larga scala. Logging può anche registrare direttamente in BigQuery 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 sanificati con Sensitive Data Protection (requisito 6.5.1).
Sicurezza delle app
Per proteggere la tua app, devi prima valutare l'interfaccia amministratore. Ti consigliamo anche di utilizzare Cloud Key Management Service.
Valutazione dell'interfaccia di amministrazione
La maggior parte delle app di e-commerce ha una propria interfaccia amministratore non console, ad esempio un portale di fatturazione dell'assistenza clienti. Uno strumento di questo tipo deve disporre di controlli di accesso solidi, avere un accesso personalizzato che utilizzi l'autenticazione a più fattori (sezione 8.4) e essere dotato di audit logging (sezione 10.2).
I log creati dovrebbero rispondere a queste domande: chi ha fatto cosa? Dove l'hanno fatto? Quando l'hanno fatto? Secondo la sezione 2.2.7, tutti gli accessi a questo strumento devono usare 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 nel codice o nei file 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 vi passi il traffico di produzione, è necessario che l'ambiente venga convalidato:
- 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 ottenere il sigillo di approvazione.
- Se sei un commerciante di livello 2 o di 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.