Questa guida ti aiuta a imparare a implementare le Standard di sicurezza dei dati del settore delle carte di pagamento (PCI DSS) per la tua attività su Google Cloud. La guida va oltre Linee guida per il cloud computing PCI SSC (PDF) per fornire background sullo standard, spiegare il tuo ruolo nella conformità basata su cloud e ti forniremo le linee guida per progettare, eseguire il deployment di elaborazione dei pagamenti tramite PCI DSS. Il tutorial illustra anche i metodi per il monitoraggio, il logging e la convalida dell'app.
Ove applicabile, questo documento fa riferimento ai requisiti PCI DSS 4.0.
Lo standard di sicurezza dei dati PCI, creato dal PCI Security Standards Council è uno standard di sicurezza delle informazioni per le aziende che gestiscono carte di pagamento (credito e debito) informazioni. Il PCI Security Standards Council include tutti i principali pagamenti emittente della carta. Attività che accettano Visa, MasterCard, Discover, American Express, JCB o UnionPay devono essere conformi allo standard PCI DSS e possono essere multati o penalizzati in caso contrario.
PCI DSS include le classificazioni per diversi tipi di commercianti, da commercianti che raccogliere di persona dati di pagamento presso i commercianti che esternalizzano il pagamento completamente l'elaborazione. Questa guida tratta le SAQ A SAQ A-EP e SAQ D i tipi di commerciante.
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 per saperne di più, consulta 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 conserva o trasferisce i dati del titolare della carta, inclusi il numero dell'account pagamenti o qualsiasi informazione che consenta l'identificazione personale relativa a la 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. Consulta "Controlli di compensazione" Le appendici B e C 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) e indicato anche come conto numero. È il numero univoco della carta di pagamento che identifica l'emittente e il conto del titolare della carta.
QSA: acronimo di Qualified Security Assessor. Le QSA sono qualificate PCI Security Standards Council (SSC) per l’esecuzione di valutazioni PCI DSS in loco. La Requisiti di idoneità per un esperto di sicurezza qualificato fornisce dettagli sui requisiti per le aziende e i dipendenti di QSA.
SAQ: l'acronimo di Self-Assessment Questionnaire, lo strumento di generazione dei report utilizzati 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 un PCI DSS la valutazione.
Tokenizzazione: una procedura 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 offre elenco dei requisiti progettato per migliorare la sicurezza del titolare della carta. Questi requisiti si suddividono in dodici parti numerate principali e molte sottoparti. Questo documento fa riferimento a questi i numeri di parte per aggiungere contesto, ma i riferimenti alla sezione non sono esaustivi dei requisiti applicabili.
I requisiti di conformità PCI DSS variano a seconda di come l'azienda gestisce transazioni con carta di pagamento (tipo) e numero di transazioni eseguite ogni anno (livello).
Con l'aumento del numero di transazioni, Livello commerciante PCI DSS aumenta e le linee guida di conformità PCI DSS diventano più rigide. Al massimo a livello commerciante, Livello 1, PCI DSS richiede una verifica. I livelli variano in base a la marca della carta. Il livello 1 è definito da American Express come 2,5 milioni di sterline annuali e da Visa, Mastercard e Discover come 6 milioni di entrate annuali transazioni. Per ogni brand di carta sono previsti requisiti di livello aggiuntivi che vanno oltre l'ambito di applicazione del presente documento. Verifica che il tuo ambiente di elaborazione dei pagamenti viene controllato per supportare il tuo livello di commerciante.
Perché Google Cloud è un servizio conforme allo standard PCI DSS 4.0 di Livello 1 può supportare le tue esigenze di conformità PCI DSS, indipendentemente il livello commerciante dell'azienda. La Impegno per la conformità indica le aree coperte da Google.
L'altra variabile fondamentale è il tipo di SAQ. I contorni del SAQ criteri da soddisfare per garantire la conformità allo standard PCI DSS in caso di idoneità all'autovalutazione. Il tuo tipo di SAQ è determinato dall'architettura dell'app e dal modo preciso in cui gestisci dati della carta di pagamento. La maggior parte dei commercianti nel cloud sono uno dei seguenti:
| Tipo di SAQ | Descrizione |
|---|---|
| A | I commercianti che hanno affidato completamente l'elaborazione delle carte di pagamento a un
sito di terze parti. I clienti lasciano il tuo dominio (anche tramite una
modulo web <iframe>), completa il pagamento e torna al tuo
app.In altre parole, la tua azienda non può accedere ai dati delle carte dei clienti in molti modi diversi. |
| A-EP | Commercianti che esternalizzano l'elaborazione dei pagamenti a un fornitore di terze parti, ma
che possono accedere ai dati della carta del cliente in qualsiasi momento del processo. 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 un processore sul lato client oppure esegue il rendering di eventuali contenuti ospitati da parte tua. |
| D | Commercianti che accettano pagamenti online e non sono idonei per la SAQ A o
SAQ A-EP. Questo tipo include tutti i commercianti che chiamano un elaboratore dei pagamenti
dei server, a prescindere 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 ai commercianti dell'indirizzo come definito nello standard PCI DSS. |
Impegno per la conformità
Google utilizza una serie di tecnologie e processi per proteggere le informazioni che viene archiviata sui server di Google. PCI DSS convalidato in modo indipendente da Google Requisiti applicabili alle tecnologie e all'infrastruttura di Google Cloud gestiti da Google. Puoi scaricare i report di conformità PCI DSS di Google da Gestione dei report di conformità. Sebbene Google offra ai commercianti un'enorme quantità le istanze di calcolo eseguite sull'infrastruttura di Google, non controlla la sicurezza del sistema operativo, dei pacchetti o delle app che i commercianti eseguono il deployment su Google Cloud. È tua responsabilità rispettare 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 Livello 1 Il Fornitore di servizi e tutti i requisiti applicabili per i fornitori di servizi. La Google Cloud Matrice di responsabilità condivisa delinea gli obblighi di conformità dello standard PCI DSS. La matrice della responsabilità può un riferimento utile per perseguire la conformità PCI DSS e condurre la propria Verifiche 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 controlli del traffico in uscita.
Cloud Run
Utilizza le impostazioni del traffico in entrata di Cloud Run, i Controlli di servizio VPC e 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. Google offre automaticamente la crittografia at-rest, ma non eseguire gli hash unidirezionali, il troncamento o la tokenizzazione che le regole che ti servono.
Architetture di esempio
Questa sezione illustra gli approcci per implementare un ambiente che è conforme alle normative 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 sono elaborati da una terza parte e i dati delle carte non sono accessibili al commerciante app o pagine.
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 pagamento di terze parti di fatturazione.
Il cliente inserisce i dati della carta di pagamento in una forma di pagamento che il responsabile di terze parti possiede e gestisce.
L'elaboratore dei pagamenti di terze parti controlla i dati della carta di pagamento. e poi 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 dettagli della transazione.
L'app del commerciante invia una richiesta di verifica al pagamento di fatturazione 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 una di elaborazione dei pagamenti in esecuzione su macchine virtuali Compute Engine di Compute Engine. Queste istanze si trovano in una rete privata protetta Utilizzare canali sicuri per comunicare con servizi al di fuori del in ogni 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 che l'azienda possiede e gestisce.
Quando il cliente invia i propri dati, i dati del modulo vengono vengono passate 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. e poi addebita o rifiuta la carta.
L'elaboratore dei pagamenti invia una risposta all'app per i pagamenti, che poi 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 di elaborazione dei pagamenti in esecuzione su macchine virtuali Compute Engine 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 che l'azienda possiede e gestisce.
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 in modo sicuro e lo passa 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. e poi addebita o rifiuta la carta.
L'elaboratore dei pagamenti invia una risposta all'app per i pagamenti, che poi passa un messaggio all'app principale.
Tutte queste interazioni vengono registrate e monitorate con Logging e Monitoraggio.
Flusso di elaborazione dei pagamenti rivolto ai clienti
SAQ A
Questa sezione descrive il flusso di elaborazione dei pagamenti di terze parti dalla punto di vista dei clienti che utilizzano la tua app.
Quando il cliente accede al modulo di pagamento, l'app presenta una
<iframe> ospitato dall'elaboratore dei pagamenti. Il tuo
L'app non può accedere o monitorare i contenuti dei
<iframe> a causa di
limitazioni per la condivisione delle risorse tra origini.
Quando il cliente invia i dati della carta di pagamento, il pagamento
responsabile accetta o rifiuta la carta, quindi rimanda il cliente al tuo
dell'app. L'app controlla poi la risposta della transazione dal
elaboratore dei pagamenti e agisce di conseguenza. L'app non ha eseguito l'accesso o
gestire i dati delle carte di pagamento.
SAQ A-EP
Questa sezione descrive lo stesso flusso di elaborazione dei pagamenti interno di descritto in precedenza, ma dal punto di vista 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 la propria dati della carta di pagamento, il modulo viene inoltrato direttamente all'elaboratore dei pagamenti. L'elaboratore accetta o rifiuta la carta, quindi rimanda il cliente a la tua app. L'app controlla poi la risposta della transazione da l'elaboratore dei pagamenti e agisce di conseguenza. Il cliente potrebbe non vedere elaboratore dei pagamenti di terze parti, ma la tua app non ha eseguito l'accesso ad alcuno i dati della carta di pagamento sul lato server.
SAQ D
Questa sezione descrive il flusso di elaborazione dei pagamenti interno dalla punto di vista dei clienti che utilizzano la tua app.
Quando il cliente accede all'URL della tua forma di pagamento, accede in sicurezza indirizzato al modulo tramite un bilanciatore del carico HTTPS. Quando il cliente invia le informazioni della sua carta di pagamento, la tua app di elaborazione dei pagamenti invia le informazioni a un elaboratore dei pagamenti di terze parti. La terza parte l'elaboratore dei pagamenti accetta o rifiuta la carta, quindi restituisce una risposta a l'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 ai server che eseguono la tua app.
L'app di elaborazione dei pagamenti riceve e analizza la risposta restituiti dall'elaboratore dei pagamenti di terze parti, quindi invia alcuni o tutti i i dati di risposta all'app principale. A questo punto, di elaborazione pagamenti termina con la transazione. Il nucleo l'app gestisce l'attività di informare i clienti.
SAQ D
Questa sezione descrive il flusso di elaborazione dei pagamenti interno dalla 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 poi li invia all'elaboratore dei pagamenti mediante un'API backend. Il processore prova a effettuare la ricarica e risponde con i dettagli della transazione. La tua app riceve ed elabora la risposta e invia alcuni o tutti i dati di risposta all'app principale. Alle ore a questo punto, la tua app di elaborazione dei pagamenti transazione. L'app principale gestisce l'attività di notifica al cliente e alla 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. Configurazione include:
- Crea un nuovo account Google Cloud per isolare 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 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'istanza di elaborazione dei pagamenti, di qualità per la produzione, completamente isolato dell'ambiente di produzione standard e di qualsiasi ambiente di sviluppo e QA (requisito 6.5.3). Per garantire l'isolamento, crea e utilizza un account Google Cloud che separato da l'account dell'ambiente di produzione principale. Utenti che hanno esperienza con Identity and Access Management (IAM) può realizzare 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 tuo il codice del sistema di pagamento o gestire le macchine del sistema di pagamento (sezione 7.2 e requisito 8.2.1). Questo è noto come principio del privilegio minimo. Utilizza IAM ruoli per limitare l'accesso. Le best practice includono l'utilizzo dei ruoli, ove possibile, concedendo solo le autorizzazioni necessarie per eseguire il lavoro previsto e solo concedendo il ruolo Proprietario alle entità che hanno legittimamente bisogno dell'accesso root completo i tuoi servizi. Consulta le Guida alla sicurezza IAM per ulteriori informazioni.
L'accesso automatico a qualsiasi servizio gestito deve dipendere account di servizio. Gli account di servizio semplificano il ciclo di vita della gestione delle app fornendoti per gestire l'autenticazione e l'autorizzazione delle app. Questi account offrono un modo flessibile e sicuro per raggruppare istanze di macchine virtuali con strumenti app e funzioni che hanno un'identità comune. Puoi applicare criteri di sicurezza il controllo dell'accesso a livello di account di servizio tramite i ruoli IAM le regole firewall VPC.
Le regole IAM che applichi alle cartelle vengono ereditate da tutti gli elementi contenuti in quella cartella. Per impostazione predefinita, le autorizzazioni sono negate-all (requisito 7.2.3), e ogni regola applicata aggiunge solo autorizzazioni.
Il requisito 8.3.6 fornisce alcune regole di base per le password degli utenti. Il National Il Institute of Standards and Technology (NIST) definisce un insieme più sicuro di regole per le password sicure in sezione 5.1.1 del NIST SP800-63B. Google consiglia di seguire le linee guida sull'identità digitale NIST ogni volta che possibile.
La sezione 12.7 del PCI DSS SAQ D richiede che gli utenti abbiano accesso all'ambito ambiente per superare un controllo dei precedenti, in conformità con le leggi locali, prima a cui viene concesso l'accesso all'ambiente. Per ridurre il rischio di conformità violazioni delle norme, ti consigliamo di eseguire questi controlli dei precedenti penali controlla ogni singolo individuo, indipendentemente dal tipo di conformità.
Protezione della rete
Per proteggere il traffico in entrata e in uscita da e verso i sistemi 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, ti consigliamo anche Cloud NAT per aggiungere un ulteriore livello di sicurezza di rete. Esistono molte opzioni efficaci disponibili per le reti protette di Compute Engine delle istanze GKE.
Creazione delle regole firewall in corso...
Utilizza le funzionalità di Criteri o regole firewall VPC di Cloud Next Generation Firewall per limitare il traffico in entrata a ogni istanza di Compute Engine. (requisiti 1.3 e 1.4). Consenti il traffico in entrata solo dai seguenti canali tre fonti:
- 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 ricevere risposte dall'elaboratore dei pagamenti di terze parti.
- La rete aziendale interna, per poter accedere alle istanze per finalità 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 tag di rete. Consenti al pagamento di terze parti solo il traffico in uscita dal modulo di pagamento di fatturazione. 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 tuo CDE senza il potenziale la divulgazione di dati sensibili relativi alla topologia di rete.
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 Accetta richieste AUTH dai sistemi di pagamento (non contiene alcun 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 ai log e di sviluppo |
Inoltre, il seguente traffico avviene in modo sicuro nel tuo 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 la tua rete on-premise 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 una Bilanciatore del carico delle applicazioni esterno (sezioni 2.2.7 e 4.2). Per creare un bilanciatore del carico delle applicazioni esterno, è necessario seguenti:
- Un sottodominio del tuo sito web utilizzato per l'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 nel tuo sito web del dominio del registrar.
Creazione di un'immagine Linux di base
Il PCI DSS contiene requisiti che descrivono come configurare macchine che facenti parte di un'architettura di elaborazione dei pagamenti conforme. Puoi implementare questi in vari modi, ma l'approccio più semplice è il seguente:
Crea un elenco delle librerie e dei software che devono essere installati a ogni server nell'ambito della tua app di elaborazione dei pagamenti. A evitare di introdurre vulnerabilità non necessarie nel sistema (requisito 2.2.4), comprendono solo il minimo di software e librerie che devi eseguire l'app. I candidati possono includere Google Cloud CLI runtime e librerie specifici dei linguaggi o di un server web.
Crea un'istanza Compute Engine che utilizza uno dei Google Compute Engine immagini preconfigurate del sistema operativo.
Installa le librerie e il software elencato in precedenza.
Installa e configura
ntpper mantenere sincronizzati gli orologi di sistema. Gestione ai tempi del server con il Network Time Protocol, assicura l'integrità i timestamp nei log (sezione 10.6).Assicurati che l'immagine segua le best practice per la creazione di un'immagine Compute Engine sicura (vedi la sezione 2.2).
Dopo aver configurato l'immagine di base, crea un'immagine disco Compute Engine personalizzata dall'immagine. Questa immagine ti consente di usare l'immagine Linux di base quando di creare istanze di macchine virtuali.
Utilizzo della gestione sicura dei pacchetti
La gestione dei pacchetti è un componente fondamentale di un servizio di hosting rafforzato dalla sicurezza completamente gestito di Google Cloud. Ai sensi della sezione 2.2, devi implementare soluzioni di protezione accettate dal settore standard. A meno che non utilizzi Container-Optimized OS di Google probabilmente hai installato un gestore di pacchetti come RPM, Yum o Apt. Il tuo potrebbe utilizzare il proprio gestore di pacchetti specifico per 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 trattare gli aggiornamenti delle risorse come potenziale rischio per la sicurezza. Attacchi Supply-Side o upstream che sono inclusi malevoli in 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 offerta creando un destinatario sicuro dei tuoi pacchi e verificando che corrispondano all'elenco. Tieni un elenco di numeri di versione testati e approvati per ogni pacchetto utilizzato. Registra il numero di versione insieme all'hash o alla firma. Assicurati che il gestore di pacchetti convalida 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 solo l'host testato e approvato software. 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ò che di cui ha bisogno il container. In questo modo, i server vengono avviati e scalati senza dell'installatore. Inoltre, la probabilità di errori casuali in fase di lancio è ridotta. Puoi anche rivedere qualsiasi versione precedente dell'app esattamente com'era in produzione lanciando la sua immagine, che può essere utile diagnostica e analisi forense.
Deployment e configurazione
Imposta quindi il deployment e la configurazione delle istanze dalla tua base dell'immagine.
Deployment dell'ambiente
Per soddisfare i requisiti PCI DSS, assicurati di eseguire il deployment di eseguire il deployment dell'app in modo sicuro e non stai installando altri pacchetti software durante il deployment. A semplificare il processo di deployment, valuta la possibilità di creare un deployment la tua app utilizzando Terraform. Con Terraform puoi descrivere tutto di elaborazione dei pagamenti, incluse le regole firewall, i gateway, bilanciatori e istanze nel codice.
In un deployment automatico, devi verificare l'integrità del software il deployment, che provenga da una terza parte o dal tuo. Puoi verificare il tuo software eseguendo un hash automatico su ogni pacchetto come pacchetto. è già installato. Dopo la verifica di un hash, potrai utilizzare una funzione framework di test per eseguire test di sicurezza e di altro tipo e per verificare che i test sono superate.
Infine, quando esegui il deployment di istanze di Compute Engine, progetta un ripristino in caso di errore delle istanze. Se la tua finestra è il tempo di inattività è abbastanza elevato, potrebbe essere sufficiente un piano di ripristino manuale. In caso contrario, devi progettare un piano di ripristino automatizzato. Consulta le Guida alla pianificazione del ripristino di emergenza, Progettazione di sistemi solidi, e Creazione di app web scalabili e resilienti per assistenza.
configura il tuo ambiente
Dopo il deployment delle istanze, assicurati che siano configurate in modo corretto. Installa software e librerie aggiuntivi su ogni istanza dell'immagine di base in base alle esigenze. Per evitare la complessità, l'overhead e il rischio complessivo configurazione manuale, utilizzare uno strumento di gestione automatica della configurazione come Skaffold Chef, Burattini Ansible, o Salt.
Implementazione di audit logging immutabile
Logging produce log di controllo automaticamente per un'ampia gamma di attività in molti prodotti. A lungo termine, puoi archiviare in modo sicuro i log immutabili utilizzando Blocchi dei bucket di Cloud Storage (sezione 10.3). I blocchi dei bucket ti consentono di impostare per rendere tutti gli oggetti immutabili e non eliminabili per un determinato periodo di tempo da te specificati, dai secondi agli anni.
Implementazione dei log di flusso Virtual Private Cloud
La Log di flusso VPC è progettato per registrare i flussi di rete inviati o ricevuti di Compute Engine. È 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à in l'archiviazione a blocchi del server. Consulta le Logging pagina dei prezzi per informazioni dettagliate sull'allocazione gratuita e sui prezzi di Data Transfer. Per conservare questi log e generare avvisi in base ad attività sospette, invia un flusso di dati a Logging e Monitoring installando l'agente Logging su ciascun server (sezione 10.3).
Integrazione di un sistema di rilevamento delle intrusioni
Per contribuire a garantire la sicurezza dell'ambiente di elaborazione dei pagamenti, descritto in sezione 11.5, utilizza un sistema di rilevamento delle intrusioni (IDS), per sapere quando i malintenzionati tentano di attaccare il sistema. Esistono due modi per posizionare un IDS in un ambiente di elaborazione dei pagamenti: inserire un IDS in o installare un IDS su ciascun server.
Per ridurre la complessità dell'architettura del tuo ambiente e semplificare conformità alla versione 11.5, installare un IDS su ciascun server. Dopo aver studiato scegliere il software IDS da utilizzare, rendere l'installazione IDS parte per ciascun server.
Cloud Intrusion Detection System (Cloud IDS), un un servizio di rilevamento delle intrusioni, offre il rilevamento delle minacce per intrusioni, malware, spyware e attacchi command-and-control sulla tua rete. Cloud IDS fornisce visibilità completa sul traffico di rete, compreso il traffico da nord-sud e est-ovest, che ti permette di monitorare le comunicazioni da VM a VM per rilevare movimenti laterali. Puoi usano Cloud IDS anche per semplificare la conformità al requisito 11.5.
I log IDS rientrano nell'ambito della conformità PCI DSS e devono essere inviati Logging e Monitoring per il reporting, avvisi e controllo.
Implementazione di Security Command Center
Security Command Center aiuta i team della sicurezza a raccogliere dati, identificare le minacce e alle minacce prima che causino danni o perdite all'azienda. Offre approfondimenti al rischio di app e dati, in modo da poter mitigare rapidamente delle risorse cloud e valutano l'integrità generale. Con Security Command Center, visualizzare e monitorare un inventario dei tuoi asset cloud, analizzare i sistemi di archiviazione sensibili, rilevare le vulnerabilità web più comuni ed esaminare i diritti di accesso le risorse critiche, il tutto da un'unica dashboard centralizzata. Può essere utile si rispettano 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 l'ultima versione dell'app. La tua app può essere recuperata da qualsiasi posizione, come Cloud Storage purché la posizione sia sicura.
Molti degli strumenti di gestione della configurazione citati in precedenza supportano flussi di lavoro di integrazione e deployment (CI/CD), che possono essere usati anche per eseguire scansione automatizzata (sezione 11.3) e assicurare che il codice venga rivisto (requisito 6.2.3).
Acquisizione dei log di Configuration Manager
Quando imposti Gestore configurazione, assicurati che registri tutti i dettagli dell'installazione. Dopo aver completato il processo di configurazione, assicurati che invia i log a Logging e Monitoring.
Logging e monitoraggio
Per garantire la conformità allo standard PCI DSS nella sezione 10, verificare che ogni operazione eseguita nel l'ambiente di elaborazione dei pagamenti viene monitorato e registrato. Ogni server deve essere registrata l'attività su ogni istanza e ogni azione dell'utente deve essere in grado di in un secondo momento.
Attivazione di Access Transparency
Tramite Access Transparency, Logging ora offre log quasi in tempo reale Gli amministratori di Google Cloud accedono ai tuoi contenuti. Log di Cloud Audit Logs già offrono visibilità sulle azioni dei tuoi amministratori. Tuttavia, questo controllo in genere esclude le azioni intraprese dall'assistenza del provider cloud del nostro team tecnico. Ad esempio, prima del logging di Access Approval, se hai aperto un ticket con l'Assistenza Google che richiedeva l'accesso ai dati, tracciate in Cloud Audit Logs. Access Approval chiude gap, registrando log quasi in tempo reale degli accessi manuali mirati da parte dei due servizi o progettazione.
Access Approval ti consente di approvare esplicitamente l'accesso ai tuoi dati o alle tue configurazioni su Google Cloud prima che venga eseguito l'accesso. Access Approval offre inoltre insight agli accessi da parte dell'Assistenza Google e del team Engineering.
Abilitazione del logging delle regole firewall in corso...
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 per te. Può essere utile per controllare l'accesso alla rete o per fornire avviso 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 a Google Cloud come bucket Cloud Storage, 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 mentre sfruttare le capacità di archiviazione ed elaborazione dati completamente gestite in Google Cloud.
Configurazione dei log di flusso VPC
Log di flusso VPC registrare i flussi di traffico di rete inviati o ricevuti dalle istanze VM. I log sono utile in conformità allo standard PCI DSS per il monitoraggio, l'auditing, le indagini forensi e la sicurezza in tempo reale e analisi. Ogni subnet di rete VPC può avere log di flusso abilitati disattivato in modo indipendente. Puoi ridurre al minimo la quantità di dati di log abilitando solo Log di flusso sul CDE in ambito. I log di flusso, combinati con le regole firewall in uscita, consentono di limitare il traffico in uscita il traffico 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 singoli il logging delle richieste HTTP, puoi implementare i controlli nell'app richieste proxy in uscita. Puoi farlo seguendo il tuo rovescio: server proxy configurato per inoltrare i log di accesso a Logging. Per istruzioni su come configurare un server proxy Squid su Compute Engine, consulta la sezione Configurazione di 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 persone che hanno accesso amministrativo alla tua elaborazione dei pagamenti dell'ambiente di lavoro (sezione 10.2). Per farlo, puoi registrare i comandi della shell. Diversi aperti gli strumenti di origine possono controllare i comandi shell e inviarli al logging. Scelte popolari per questa attività includi OSSEC o Tripwire.
Configurazione degli avvisi di monitoraggio
Configurare Monitoring per inviare avvisi in caso di problemi nell'ambiente di elaborazione dei pagamenti (sezione 10.6). Assicurati che che riguardano gli eventi ambientali, di controllo e interni delle app. Basa la tua strategia di avviso sui potenziali vettori d'attacco o di rischio per ogni componente l'app di elaborazione dei pagamenti. Ad esempio, trigger Il monitoraggio ti avvisa se il tuo IDS rileva tentativi di intrusione, indipendentemente dall'esito positivo o negativo. Puoi anche utilizzare il logging delle regole firewall per attivare avvisi in risposta a tentativi di violazione criteri di rete.
Streaming dei log in BigQuery
Facoltativamente, puoi eseguire il routing dei log di Logging BigQuery per analizzarli in seguito; vedi Panoramica su routing e archiviazione: sink per maggiori dettagli. Poiché BigQuery è ottimizzato per eseguire query è uno strumento ideale per l'analisi dei log su larga scala. Il logging può anche accedi direttamente a BigQuery per i log che richiedono un'analisi quasi in tempo reale (requisito 10.4.1).
Utilizzo di Sensitive Data Protection per la sanificazione dei dati
Esistono molti motivi per utilizzare parti dei dati contenuti nell'ambito per app che non rientrano nel relativo ambito, ad esempio per l'analisi o sviluppo del prodotto. Concedi alle app l'accesso ai dati PCI solo dopo che sono stati sanificati con Protezione dei dati sensibili (requisito 6.5.1).
Sicurezza delle app
Per proteggere la tua app, devi prima valutare l'interfaccia amministratore. Tu potrebbe voler utilizzare anche Cloud Key Management Service.
Valutazione dell'interfaccia di amministrazione
La maggior parte delle app di e-commerce ha una propria interfaccia amministratore come il portale di fatturazione dell'assistenza clienti. Uno strumento di questo tipo deve avere accesso i controlli; Deve avere un accesso personalizzato che usa autenticazione (sezione 8.4); e deve essere dotata di audit logging (sezione 10.2).
I log creati dovrebbero rispondere a queste domande: chi ha fatto cosa? Dove sono farlo? Quando l'hanno fatto? In base alla sezione 2.2.7, ogni accesso a tale strumento deve una crittografia di trasporto efficace. Usa Sensitive Data Protection per filtrare 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, usare, ruotare e distruggere AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256 ed EC P384 chiavi di crittografia. Cloud KMS consente di rimuovere il testo non crittografato memorizzate in file di codice o di configurazione, il che semplifica la conformità sezioni 2.2.2, 3.6, 3.7 e 8.2.
Convalida dell'ambiente
Dopo l'implementazione dell'ambiente, ma prima del flusso di traffico di produzione l'ambiente deve essere 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 conferire 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. Dai un'occhiata al nostro Centro architetture cloud.