Conformità agli standard di sicurezza dei dati PCI

Questa guida ti aiuta a imparare a implementare lo standard di sicurezza dei dati (PCI DSS) per la tua azienda su Google Cloud. La guida va oltre le linee guida per il cloud computing delle SSC PCI (PDF) per fornire informazioni di base sullo standard, spiegare il tuo ruolo nella conformità basata sul cloud e infine linee guida per progettare, sottoporre a deployment e configurare un'app di elaborazione pagamenti tramite PCI DSS. Il tutorial illustra anche i metodi per monitorare, registrare e convalidare la tua app.

Lo standard PCI Data Security Standard, creato dal PCI Security Standards Council, è uno standard di sicurezza delle informazioni per le aziende che gestiscono informazioni relative alle carte di pagamento (sia credito sia debito). Il PCI Security Standards Council include tutte le principali società che operano nel settore delle carte di pagamento. Le aziende che accettano Visa, MasterCard, Discover, American Express o JCB devono rispettare il PCI DSS e possono essere multate o penalizzate, a meno che non lo facciano.

PCI DSS include le classificazioni per diversi tipi di commerciante, dai commercianti che raccolgono di persona i dati di pagamento, ai commercianti che esternalizzano completamente l'elaborazione dei pagamenti. Questa guida illustra i tipi di commerciante SAQ A, SAQ A-EP e SAQ D.

Obiettivi

  • Rivedi l'architettura dell'app per l'elaborazione dei pagamenti.
  • Configura l'ambiente di elaborazione dei pagamenti.
  • Eseguire il deployment e configurare gli ad server.
  • Configurare il logging e il monitoraggio.
  • Convalida l'ambiente di elaborazione dei pagamenti.

Definizioni

Questa guida utilizza molte frasi univoche. Di seguito sono riportati alcuni tra quelli più comuni. Per ulteriori informazioni, consulta il glossario di PCI DSS.

CDE: acronimo di cardowner dataenvironment. Questo acronimo si riferisce a qualsiasi parte dell'app che contenga o trasferisca dati dei titolari della carta, compresi il numero di conto bancario o eventuali informazioni di identificazione personale relative alla carta.

Controlli di compensazione: soluzioni alternative a qualsiasi requisito che soddisfa l'intento e il rigore del requisito originale e che forniscono un livello di difesa simile. La definizione ufficiale afferma che i controlli di compensazione devono essere "superiori e oltre" ad altri requisiti PCI DSS e devono essere commisurati al rischio aggiuntivo imposto dal mancato rispetto del requisito originale.

PAN: acronimo di numero di conto principale e denominato anche numero di conto. È 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 certificati dal PCI Security Standards Council (SSC) per l'esecuzione di valutazioni PCI DSS in loco. Per i dettagli relativi ai requisiti per le aziende e i dipendenti QSA, consulta i requisiti di qualificazione per QSA.

SAQ: Acronimo di Self- Assessment Questionnaire, lo strumento di generazione di report utilizzato per documentare i risultati dell'autovalutazione a seguito della valutazione PCI DSS di un'entità.

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

Tokenizzazione: un processo che sostituisce il numero dell'account principale (PAN) con un valore surrogato chiamato token. Il PAN viene quindi memorizzato in una ricerca sicura. La deduplicazione è la procedura inversa per 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 di carte. Questi requisiti sono suddivisi in dodici parti principali e molte sottopartite. Il presente documento fa riferimento a questi numeri di parte per maggiore contesto, ma i riferimenti alle sezioni non costituiscono un elenco completo dei requisiti applicabili.

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

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

Poiché Google Cloud è un provider di servizi conforme allo standard PCI DSS 3.2.1, può supportare le tue esigenze di conformità PCI DSS indipendentemente dal livello di commerciante della tua azienda. La sezione Impegno per la conformità stabilisce quali aree sono coperte per te da Google.

L'altra variabile fondamentale è il tipo SAQ. La SAQ definisce i criteri che devi rispettare per rispettare lo standard PCI DSS. 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 è una delle seguenti:

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

In altre parole, la tua azienda non può toccare i dati della carta dei clienti in nessun modo.
EP Commercianti che esternalizzano l'elaborazione dei pagamenti a un fornitore di terze parti, ma possono accedere ai dati della carta dei clienti in qualsiasi momento del processo. 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 pagamenti inoltra i dati della carta a un responsabile sul lato client, oppure il processore esegue il rendering dei contenuti ospitati da te.
D I commercianti che accettano pagamenti online e non risultano idonei per SAQ A o SAQ A-EP. Questo tipo include i commercianti che chiamano un'API per l'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 distingue tra commercianti e fornitori di servizi. I fornitori di servizi non sono discussi in questo documento e tutti i riferimenti SAQ D si rivolgono ai commercianti come definito in PCI DSS.
Diagramma di Venn dei requisiti SAQ. SAQ A-EP è un soprainsieme di SAQ A-EP, mentre
SAQ D è un soprainsieme di SAQ A-EP.
Diagramma dei requisiti di SAQ di Ven. SAQ A-EP è un soprainsieme di SAQ A, mentre SAQ D è un soprainsieme di SAQ A-EP.

I commercianti possono essere qualsiasi combinazione di livello e tipo e i requisiti di conformità variano notevolmente, a seconda delle circostanze.

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 applicabili alle tecnologie e all'infrastruttura Google Cloud gestite da Google. Google offre ai commercianti un grande controllo sulle loro istanze di calcolo eseguite sull'infrastruttura Google, ma 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 i pacchetti del sistema operativo e le app di cui esegui il deployment, in aggiunta ad altre personalizzazioni richieste dalla tua architettura.

Google Cloud è conforme ai requisiti PCI DSS stabiliti per un fornitore di servizi di livello 1 e per tutti i requisiti applicabili del fornitore di servizi. La Matrice di responsabilità condivisa di Google Cloud delinea gli obblighi di conformità di PCI DSS. La matrice delle responsabilità può essere un riferimento utile mentre cerchi di rispettare la conformità allo standard PCI DSS e a svolgere i tuoi controlli relativi a PCI DSS.

Indicazioni sul prodotto

App Engine

Sono disponibili regole del firewall per il traffico in entrata in App Engine, ma al momento non sono disponibili regole per il traffico in uscita. In base ai requisiti 1.2.1 e 1.3.4, devi assicurarti che tutto il traffico in uscita sia autorizzato. I commercianti di tipo SAQ A-EP e SAQ D devono fornire controlli di compensazione o utilizzare un prodotto Google Cloud diverso. Compute Engine e GKE sono le alternative alternative.

Cloud Functions

Analogamente ad App Engine, Cloud Functions attualmente non supporta le regole firewall in uscita. I commercianti di tipo SAQ A-EP e SAQ D devono fornire controlli di compensazione o utilizzare un prodotto Google Cloud diverso. Compute Engine e GKE sono le alternative preferite.

Google Kubernetes Engine

Avvicinati ai nodi e ai pod in un cluster GKE allo stesso modo di qualsiasi server gestito dal commerciante. Implementa logging, strumentazione e patch a livello di nodo e pod. Non conservare i dati dei titolari di carte a livello di nodo; tuttavia, i nodi saranno comunque nell'ambito se contengono o potrebbero contenere pod all'interno dell'ambito.

Per limitare l'accesso al piano di controllo (master del cluster), utilizza le reti autorizzate per bloccare gli indirizzi IP non attendibili dall'esterno di Google Cloud. Queste regole CIDR sono compatibili con i cluster privati e agiscono come lista consentita (denominato anche lista consentita).

Implementa criteri di rete nel cluster GKE quando i tuoi progetti nell'ambito contengono tipi di pod diversi. I criteri di rete funzionano in modo simile ai firewall Virtual Private Cloud (VPC) che già conosci. Puoi consentire o negare il traffico in base a regole o etichette IP.

Il requisito 2.2.1 stabilisce che è possibile implementare una sola funzione principale per server. Questo requisito non vieta il caso di un singolo cluster GKE che ospita più di un tipo di pod. La funzione principale dei nodi GKE è gestire e gestire i container. Se progettati correttamente, anche i singoli pod possono rispettare questa regola della funzione principale in un unico cluster.

Cloud Storage

Il requisito 3.4 stabilisce che un PAN deve essere illeggibile ovunque venga archiviato. Anche se Google offre automaticamente la crittografia dei dati at-rest, non esegue automaticamente gli hash unidirezionali, 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

Domande frequenti

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

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

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

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

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

  4. L'elaboratore dei pagamenti di terze parti controlla i dati della carta di pagamento e addebita o rifiuta.

  5. Dopo aver elaborato la transazione, il processore di pagamento di terze parti rimanda il cliente all'app del commerciante insieme ai dettagli della transazione.

  6. L'app del commerciante invia una richiesta di verifica all'elaboratore dei pagamenti per confermare la transazione.

  7. L'elaboratore dei pagamenti risponde per verificare i dettagli della transazione.

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

SAQ EP

L'architettura di elaborazione dei pagamenti A-EP di SAQ è incentrata su un'applicazione di elaborazione dei pagamenti eseguita su istanze di macchine virtuali Compute Engine. Queste istanze si trovano in una rete privata sicura e utilizzano canali sicuri per comunicare con 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. L'elaboratore dei pagamenti di terze parti controlla i dati della carta di pagamento e addebita o rifiuta.

  4. L'elaboratore dei pagamenti invia una risposta alla tua app di pagamento, che trasmette il messaggio all'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 pagamenti SAQ A-EP

Domande frequenti D

L'architettura di elaborazione dei pagamenti DQ SAQ si basa su un'applicazione di elaborazione 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 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, la tua app di pagamento riceve le informazioni del modulo.

  3. L'app per i pagamenti convalida i dati di pagamento e li passa in modo sicuro a un elaboratore dei pagamenti di terze parti attraverso un'API di backend.

  4. L'elaboratore dei pagamenti di terze parti controlla i dati della carta di pagamento e addebita o rifiuta.

  5. L'elaboratore dei pagamenti invia una risposta alla tua app di pagamento, che trasmette il messaggio all'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 pagamenti SAQ D

Flusso di elaborazione dei pagamenti lato cliente

Domande frequenti

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

Flusso di lavoro del cliente di terze parti per l&#39;elaborazione dei pagamenti
Flusso di lavoro del cliente di SAQ: elaborazione di pagamento di terze parti

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

SAQ EP

In questa sezione viene descritto lo stesso flusso di elaborazione dei pagamenti interno descritto in precedenza, ma dal punto di vista dei clienti che utilizzano l'app.

Flusso di lavoro del cliente per l&#39;elaborazione dei pagamenti di terze parti tramite SAQ A-EP
Flusso di lavoro del cliente per l'elaborazione dei pagamenti di terze parti SAQ A-EP

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

Domande frequenti D

Questa sezione descrive il flusso di elaborazione dei pagamenti interni dal punto di vista dei clienti che utilizzano l'app.

Flusso di lavoro del cliente per l&#39;elaborazione dei pagamenti di terze parti da parte di SAQ D
Flusso di lavoro del cliente per l'elaborazione dei pagamenti di terze parti da parte di SAQ D

Quando il cliente accede all'URL per il 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 le 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 all'app di elaborazione pagamenti.

Flusso interno di elaborazione dei pagamenti

SAQ A &AMP; A-EP

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

Flusso interno SAQ A e SAQ A-EP
Flusso interno SAQ A e SAQ A-EP

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 della risposta all'app principale. A questo punto, l'app per l'elaborazione dei pagamenti viene completata con la transazione. L'app principale gestisce l'attività di notifica ai tuoi clienti.

Domande frequenti D

Questa sezione descrive il flusso di elaborazione dei pagamenti interno dal punto di vista dei server che eseguono l'app.

Flusso interno SAQ D
Flusso interno di 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. Il processore 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 viene terminata con la transazione. L'app principale gestisce l'attività di notifica del cliente e di consegna del prodotto.

Flusso di dati e monitoraggio

Il flusso di monitoraggio e logging è progettato come segue:

Flusso di monitoraggio e logging
Monitoraggio e logging del flusso

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 da quello di produzione.
  • Limitazione dell'accesso al tuo ambiente.
  • Configurazione delle risorse virtuali in corso.
  • La progettazione dell'immagine Linux di base che utilizzerai per configurare i server dell'app.
  • Implementare una soluzione di gestione dei pacchetti sicura.

Configurare un nuovo account

Per semplificare le limitazioni di accesso e il controllo della conformità, crea un ambiente di elaborazione dei pagamenti di qualità di produzione completamente isolato dal tuo ambiente di produzione standard e da qualsiasi ambiente di sviluppo/QA (requisito 6.4.1). Per garantire l'isolamento, crea e utilizza un account Google Cloud separato dall'account dell'ambiente di produzione principale. Gli utenti esperti nella configurazione di Identity and Access Management (IAM) possono ottenere un isolamento equivalente utilizzando progetti separati per il lavoro nell'ambito.

Limitazione dell'accesso al tuo ambiente

Consenti l'accesso all'ambiente di elaborazione dei pagamenti solo agli utenti che implementano il codice di sistema di pagamento o gestiscono le macchine del sistema di pagamento (sezione 7.1 e requisito 8.1.1). Questa pratica è nota come il principio di privilegio minimo. Utilizza i ruoli IAM per limitare l'accesso. Le best practice includono l'utilizzo di ruoli, ove possibile, la concessione solo delle autorizzazioni necessarie per eseguire il lavoro previsto e la concessione del ruolo Proprietario solo alle entità che legittimamente necessitano di un accesso root completo ai servizi. Per ulteriori informazioni, consulta la Guida alla sicurezza IAM.

L'accesso automatico a qualsiasi servizio gestito deve fare affidamento sugli account di servizio. Gli account di servizio semplificano il ciclo di vita di 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 della sicurezza e 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 che contengono. Le autorizzazioni predefinite sono "den-all" (requisito 7.2.3) e ogni regola applicata aggiunge solo le autorizzazioni.

Il requisito 8.2.3 fornisce alcune regole di base per le password degli utenti. Il National Institute of Standards and Technology (NIST) definisce un insieme di regole più sicure per le password protette nella sezione 5.1.1 del NIST SP800-63B. Google consiglia di seguire le linee guida NIST Digital Identity ogni volta che è possibile.

La sezione 12.7 di PCI DSS SAQ D richiede che le persone che hanno accesso al tuo ambiente nell'ambito di applicazione siano in grado di superare un controllo dei precedenti, in conformità con le leggi locali, prima che sia concesso loro di accedere all'ambiente. Per ridurre il rischio di violazione delle norme, ti consigliamo di eseguire questi controlli dei precedenti penali e i controlli sui riferimenti per ogni privato, indipendentemente dal tipo di conformità.

Protezione della rete

Per proteggere il traffico in entrata e in uscita dalla tua app dell'app di elaborazione pagamenti, devi creare quanto segue:

  • Regole firewall di Compute Engine
  • Un tunnel VPN (Virtual Private Network) di Compute Engine
  • Un bilanciatore del carico HTTPS di Compute Engine

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

Creazione di regole firewall

Utilizza le regole firewall per limitare il traffico in entrata a ciascuna delle tue istanze Compute Engine (requisiti 1.2.1 e 1.3.2). Consenti il traffico in entrata solo dalle seguenti tre sorgenti:

  • HTTPS pubblico, in modo che i clienti possano raggiungere la tua pagina di pagamento.
  • Rete di app, in modo che l'app di elaborazione pagamenti possa ricevere risposte dall'elaboratore dei pagamenti di terze parti.
  • La tua rete di uffici interna, 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 regole firewall o tag di rete VPC. Consenti il traffico in uscita solo dal modulo di pagamento all'elaboratore dei pagamenti di terze parti. Questa connessione deve essere solo HTTPS. Consulta la sezione relativa al logging delle regole firewall di seguito per testare il tuo lavoro.

Cloud DNS offre zone DNS private, per consentirti di denominare in modo sicuro gli host all'interno del tuo CDE, senza impedire la divulgazione di dati sensibili della topologia di rete al pubblico.

Limita il traffico come segue:

Origine Destinazione Porta Indicazioni stradali e motivo
Bilanciatore del carico pubblico Modulo per i pagamenti di terze parti tcp:443 In entrata
Accesso pubblico all'app di elaborazione pagamenti
Modulo di pagamento di terze parti Elaboratore pagamenti di terze parti tcp:443 In uscita
Inoltro di richieste AUTH al fornitore di servizi di pagamento
Elaboratore pagamenti di terze parti La tua app di elaborazione pagamenti tcp:5480 In entrata
Accettazione richieste AUTH da sistemi di pagamento (non contiene dati del titolare della carta)
La tua rete di uffici della tua azienda gateway vpn tcp:8000 In entrata
Accesso all'ambiente di elaborazione dei pagamenti per l'accesso a log e macchine di sviluppo

Inoltre, il seguente traffico si verifica in modo sicuro nella rete interna dell'app per l'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 organizzatori Server NTP di Google udp:123 Sincronizzazione temporale
Gateway VPN Tutti gli organizzatori TCP:22 Connessioni Secure Shell (SSH)

Creazione di un tunnel VPN sicuro

Compute Engine fornisce un servizio VPN che puoi utilizzare per stabilire un tunnel VPN sicuro tra il tuo ambiente on-premise e l'ambiente di elaborazione dei pagamenti (sezioni 2.3 e 4.1).

Creazione di un bilanciatore del carico HTTPS

Per garantire la sicurezza del traffico dei clienti in entrata, crea un bilanciatore del carico HTTP(S) di Compute Engine (sezioni 2.3 e 4.1). Per creare un bilanciatore del carico HTTPS, 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 sottodominio.

Per assicurarti che il tuo dominio sia valido, controlla le impostazioni DNS nell'interfaccia di configurazione del dominio del registrar web.

Creazione di un'immagine Linux di base

Lo standard PCI DSS contiene i 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 di software e librerie che devono essere installati su ogni server che rientra nell'ambito della tua app per l'elaborazione dei pagamenti. Per evitare di introdurre vulnerabilità non necessarie nel sistema (requisito 2.2.2), includi solo il numero minimo di software e librerie necessari per eseguire l'app. I candidati possono includere l'interfaccia a riga di comando di Google Cloud, i runtime e le librerie specifici del linguaggio o un server web.

  2. Crea un'istanza di 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 in modo da 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.4).

  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 personalizzata di Compute Engine dall'immagine. Questa immagine consente di utilizzare l'immagine di base di Linux quando crei istanze di macchine virtuali.

Usare la gestione sicura dei pacchetti

La gestione dei pacchetti è un componente chiave di un ambiente di hosting con protezione della sicurezza. Secondo la sezione 2.2, è necessario 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 come RPM, Yum o Apt. L'app potrebbe utilizzare un 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 gli aggiornamenti da Internet, devi considerare le origini degli aggiornamenti come un potenziale rischio per la sicurezza. Gli attacchi Supply-Side, o upstream, che sono malevolmente inclusi nei pacchetti ospitati pubblicamente, stanno diventando più comuni. Immagina di avere le conseguenze dell'installazione di un aggiornamento su SSH che contiene codice dannoso.

Puoi ridurre il rischio di attacchi lato fornitura creando un elenco di destinatari sicuri per i tuoi pacchetti e verificando che corrispondano all'elenco. Conserva un elenco di numeri di versione testati e approvati per ogni pacchetto che utilizzi. Registra il numero di versione insieme al relativo hash o 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 di gestione dei pacchetti privato e ospita solo il software testato e approvato. Blocca il gestore di pacchetti in modo che non possa contattare gli altri server per aggiornamenti.

Idealmente, il processo di compilazione della tua 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 si avviano e fanno lo scale up senza ritardi di installazione e la probabilità di errori casuali si riduce al momento del lancio. Puoi anche rivedere qualsiasi versione precedente dell'app esattamente come era in produzione semplicemente lanciando l'immagine, che può essere utile per la diagnostica e la diagnostica.

Deployment e configurazione

Quindi, configura 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'applicazione 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 automatizzato per la tua app utilizzando Cloud Deployment Manager.

Deployment Manager consente di descrivere l'intero ambiente di elaborazione dei pagamenti, inclusi regole del firewall, gateway, bilanciatori del carico e istanze. Deployment Manager può inoltre aiutarti a creare un audit trail che mostri come è stato creato ogni ambiente delle app e ti consente di creare versioni degli ambienti man mano che le migliori e le modifichi.

In un deployment automatico, devi verificare l'integrità del software di cui è stato eseguito il deployment, che sia di terze parti o di tua proprietà. Per verificare il software, esegui un hash automatico per ogni pacchetto man mano che viene installato. Dopo aver verificato un hash, puoi utilizzare un framework di test automatico per eseguire sicurezza e altri test, nonché per verificare che i test siano stati superati.

Infine, quando esegui il deployment delle istanze di Compute Engine, pianifica un piano di ripristino da utilizzare nel caso in cui le tue istanze non vadano a buon fine. Se il periodo di inattività accettabile è sufficientemente ampio, potrebbe essere sufficiente un piano di recupero manuale; in caso contrario, devi pianificarlo. Per indicazioni, consulta la guida alla pianificazione del ripristino di emergenza, la progettazione di sistemi solidi e la creazione di app web scalabili e resilienti.

Configurazione dell'ambiente

Dopo aver eseguito il deployment delle istanze, assicurati che siano configurate correttamente. Installa software e librerie aggiuntivi su ogni immagine di base dell'istanza, se necessario. Per evitare la complessità, l'overhead e il rischio complessivo di una configurazione manuale, utilizza uno strumento di gestione della configurazione automatica come Skaffold, Chef, Puppet, Ansible o Sale.

Gli attacchi alla catena di fornitura sulle origini upstream stanno diventando un fattore di maggiore preoccupazione, quindi oltre all'utilizzo di immagini Linux di base, potresti voler utilizzare uno strumento come l'API Grafeas per controllare il codice upstream.

Implementare la sicurezza di Forseti

Forseti Security è una raccolta di strumenti open source basati sulla community che ti aiutano a migliorare la sicurezza dei tuoi ambienti Google Cloud. La sua architettura modulare consente di abilitare singoli componenti, molti dei quali possono soddisfare requisiti specifici all'interno dello standard PCI DSS.

L'inventario crea uno snapshot dell'inventario delle tue risorse Google Cloud in modo da avere un record storico della tua architettura.

Scanner utilizza le informazioni raccolte da Forseti Inventory per confrontare regolarmente i criteri di accesso basati sul ruolo per le risorse Google Cloud. Lo scanner applica regole per controllare le risorse Google Cloud come la seguente:

  • Criteri di gestione di identità e accessi (IAM) per organizzazioni, cartelle e progetti
  • ACL bucket
  • ACL dei set di dati BigQuery
  • Reti autorizzate Cloud SQL

Con Scanner puoi specificare utenti, gruppi e domini consentiti, obbligatori o esclusi dalle risorse e puoi garantire che questi criteri di accesso rimangano coerenti. Se trova criteri di accesso che non corrispondono alle regole dello scanner, può salvare le informazioni su tali violazioni in Cloud SQL o in Cloud Storage. In questo modo ti proteggi da modifiche non sicure o accidentali.

Enforcer utilizza i criteri che crei per confrontare lo stato corrente del firewall di Compute Engine con uno stato specificato. Enforcer è uno strumento a riga di comando on demand che confronta i criteri in modalità batch con tutti i progetti gestiti o con i progetti selezionati. Se comprende le differenze nei criteri, utilizza le API Google Cloud per apportare modifiche e visualizzare l'output dei risultati.

Il modulo dei componenti aggiuntivi Spiega fornisce visibilità sui tuoi criteri IAM. Spiegazione può aiutarti a comprendere:

  • Chi ha accesso a quali risorse e come l'utente può interagire con la risorsa.
  • Perché un'entità ha l'autorizzazione su una risorsa o perché non dispone di un'autorizzazione e come correggerla.
  • Quali ruoli concedono un'autorizzazione e quali non sono sincronizzati con le modifiche recenti.

Dopo averla configurata, la funzionalità Notifiche email può inviare notifiche via email per l'inventario e lo scanner.

Implementazione degli audit log immutabili

Logging produce audit log automaticamente per una vasta gamma di attività in molti prodotti. Nel lungo termine, puoi archiviare in modo sicuro i log immutabili utilizzando i blocchi dei bucket Cloud Storage (sezione 10.5). I blocchi dei bucket consentono di impostare un criterio per rendere immutabili e non impostabili tutti gli oggetti per un periodo di tempo specificato da secondi all'anno. Se hai bisogno di accedere al programma di accesso in anteprima, contatta il tuo rappresentante di Google Cloud.

Implementazione dei log di flusso Virtual Private Cloud

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

Installazione dell'agente Logging

Dopo aver configurato iptables sui server, ogni server registra ogni attività nella memoria a blocchi del server. Controlla la pagina dei prezzi di Logging per i dettagli sull'allocazione gratuita e sui prezzi di Data Transfer. Per conservare questi log e generare avvisi basati su attività anomala, trasmetteli in streaming a Logging e Monitoring installando l'agente Logging su ciascun server (requisito 10.5.3).

Integrazione di un sistema di rilevamento delle intrusioni

Per garantire la sicurezza del tuo ambiente di elaborazione dei pagamenti, descritto nella sezione 11.4, utilizza un sistema di rilevamento delle intrusioni (IDS) in modo da sapere quando gli utenti 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 accesso o installare un IDS su ogni server.

Per ridurre la complessità dell'architettura dell'ambiente e per semplificare la conformità alla versione 11.5, installa un IDS su ogni server. Dopo aver cercato e scelto il software IDS da utilizzare, rendi l'installazione di IDS nello script di installazione di avvio per ogni server.

I log IDS rientrano nell'ambito della conformità PCI DSS e devono essere inviati a Logging e Monitoring per la generazione di report, avvisi e controllo.

Implementazione di Security Command Center

Security Command Center aiuta i team di sicurezza a raccogliere i dati, identificare le minacce e rispondere alle minacce prima che si verifichino danni o perdite per l'azienda. Offre insight approfonditi sul rischio legato alle app e ai dati, in modo da poter ridurre rapidamente le minacce alle tue risorse cloud e valutare lo stato complessivo delle risorse. Con Security Command Center puoi visualizzare e monitorare un inventario dei tuoi asset cloud, eseguire la scansione dei sistemi di archiviazione per i dati sensibili, rilevare le vulnerabilità web comuni e controllare i diritti di accesso alle tue risorse critiche, il tutto da un'unica dashboard centralizzata. Può aiutarti a rispettare diversi requisiti, incluse le sezioni 5 e 6.6.

Automazione del deployment delle 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 località, ad esempio Cloud Storage, purché la posizione sia sicura.

Molti degli strumenti di gestione della configurazione menzionati sopra supportano i flussi di lavoro di integrazione e deployment continui (CI/CD), che possono essere utilizzati anche per eseguire la scansione automatica (requisito 11.2.3) e per assicurare che il codice venga esaminato (requisito 6.3.2).

Acquisizione dei log di Configuration Manager

Quando imposti il gestore di configurazione, assicurati che registri tutti i dettagli dell'installazione. Dopo aver completato la procedura di configurazione, assicurati che trasmetta i log a Logging e Monitoring.

Logging e monitoraggio

Per garantire la conformità allo standard PCI DSS ai sensi della sezione 10, assicurati che ogni passaggio effettuato nell'ambiente di elaborazione dei pagamenti venga monitorato e registrato. Ogni attività del server su ogni istanza deve essere registrata e ogni azione dell'utente deve essere esaminata in un secondo momento.

Attivazione di Access Transparency

Tramite una funzionalità chiamata Access Transparency, Logging offre log quasi in tempo reale quando gli amministratori di Google Cloud accedono ai tuoi contenuti. Gli audit log di Cloud forniscono già visibilità sulle azioni dei tuoi amministratori. Tuttavia, in questo audit trail sono escluse di solito le azioni intraprese dal team di assistenza o di progettazione del cloud provider. Ad esempio, prima di registrare la trasparenza degli accessi, se avevi aperto un ticket con l'assistenza Google che richiedeva l'accesso ai dati non sarebbe stato monitorato negli audit log di Cloud. Access Transparency colma questa lacuna, acquisendo log in tempo quasi reale degli accessi manuali e mirati da parte del team di assistenza o tecnico.

Google ha rilasciato di recente Access Access. L'approvazione dell'accesso è nella fase di accesso in anteprima. Access Transparency fornisce insight sugli accessi da parte del team di assistenza e progettazione di Google, ma ti consente di approvare esplicitamente l'accesso ai tuoi dati o alle tue configurazioni su Google Cloud prima che si verifichi l'accesso. Per ulteriori dettagli e per richiedere l'accesso in anteprima, consulta la pagina collegata.

Attivazione del logging delle regole firewall

Il logging delle regole firewall consente di abilitare il logging a livello della singola regola. Può registrare le connessioni TCP e UDP all'interno di un VPC per qualsiasi regola che crei. Questi strumenti 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

I controlli di servizio VPC consentono di definire un perimetro di sicurezza attorno alle risorse Google Cloud come i bucket Cloud Storage, le istanze Cloud Bigtable e i set di dati BigQuery per limitare i dati in una rete VPC e mitigare i rischi di esfiltrazione di dati (requisiti 1.2.1 e 1.3.4). Con i Controlli di servizio VPC, puoi mantenere privati i tuoi dati sensibili e sfruttare le funzionalità di archiviazione ed elaborazione dati completamente gestite di Google Cloud.

Configurazione dei log di flusso VPC

Ambiente dei dati del titolare con log di flusso VPC abilitati
CDE con log di flusso VPC abilitati

I log di flusso VPC registrano i flussi di traffico di rete inviati o ricevuti dalle istanze VM. I log sono utili ai sensi dello standard PCI DSS per il monitoraggio, il controllo, le analisi forensi e l'analisi della sicurezza in tempo reale. Ogni log di rete VPC può essere abilitato o disabilitato in modo indipendente per i log di flusso. Puoi ridurre al minimo la quantità di dati di log solo attivando i log di flusso sul tuo CDE nell'ambito.

I log di flusso, combinati con le regole firewall in uscita, consentono di limitare il traffico in uscita agli endpoint autorizzati in modo verificabile e difficile da elusione (requisiti 1.2.1 e 1.3.4).

Se hai bisogno di dati più dettagliati rispetto a quelli forniti dai log di flusso, come le singole richieste di registrazione HTTP, puoi implementare controlli nell'app o richieste proxy in uscita. A tale scopo, utilizza il tuo server proxy inverso configurato per l'inoltro dei log di accesso a Logging. Per istruzioni sulla configurazione di un server proxy Squid su Compute Engine, consulta la sezione Configurare un proxy di rete. Per evitare colli di bottiglia, configura almeno due server proxy ridondanti.

Registrazione dei dati di accesso interno

Oltre a registrare le minacce esterne, monitora e registra anche le 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 della shell e inviarli al logging. Le opzioni più comuni per questa attività includono OSSEC o Tripwire.

Configurazione degli avvisi di monitoraggio

Configurare Monitoring per l'invio di avvisi in caso di problemi nell'ambiente di elaborazione dei pagamenti (sezione 10.6). Assicurati che gli avvisi riguardino eventi ambientali, di controllo e delle app interni. Basa la tua strategia di avviso sul potenziale rischio o sui vettori di attacco per ogni componente dell'app di elaborazione dei pagamenti. Ad esempio, attiva gli avvisi di Monitoring se il tuo IDS rileva tentativi di intrusione, 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.

Flusso dei log a BigQuery

Registrazione dei log di flusso in Cloud Storage e BigQuery
Logging dei log di flusso a Cloud Storage e BigQuery

Facoltativamente, puoi instradare i log di Logging a BigQuery per analizzarli in un secondo momento; per maggiori dettagli, vedi Panoramica su routing e archiviazione. Dato che BigQuery è ottimizzato per eseguire query su set di dati di grandi dimensioni, è uno strumento ideale per l'analisi di log su larga scala. Logging può anche accedere direttamente a BigQuery per i log che richiedono un'analisi quasi in tempo reale (requisito 10.6.1).

Utilizzo di Cloud Data Loss Prevention per sanificare i dati

Esistono molti motivi per utilizzare parti dei dati contenuti nell'app che rientra nell'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 purificati con la prevenzione della perdita di dati cloud (requisito 6.4.3).

Sicurezza delle app

Per proteggere la tua app, devi prima valutare l'interfaccia di amministrazione. Potresti anche voler usare 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 per l'assistenza clienti. Uno strumento di questo tipo deve avere controlli di accesso affidabili, deve avere accesso personalizzato che utilizza l'autenticazione a più fattori (sezione 8.3) e deve essere strumentato con l'audit logging (sezione 10.2).

I log che crei devono rispondere alle seguenti domande: Chi ha fatto cosa? Dove lo hanno fatto? Quando lo hanno fatto? Come descritto nella sezione 2.3, tutti gli accessi a questo strumento devono utilizzare una crittografia di trasporto efficace. Utilizza la Prevenzione della perdita di dati Cloud 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 di testo normale archiviate in codice o file di configurazione, che semplifica la conformità con i requisiti 3.5, 3.6, 6.3.1 e 8.2.

Convalidare l'ambiente

Dopo aver implementato l'ambiente, ma prima che possa entrare il traffico di produzione, devi prima convalidarlo:

  • Se sei un commerciante di livello 1, il tuo ambiente deve essere convalidato da un qualificatore di sicurezza qualificato (QSA). Una QSA è un'azienda o un privato approvato dal PCI Security Standards Council per convalidare gli ambienti PCI e dare il sigillo dell'approvazione.
  • Se sei un commerciante di livello 2 o inferiore, puoi convalidare il tuo ambiente compilando il Questionario di autovalutazione.

Passaggi successivi