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 monitorare, registrare e convalidare l'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 riguarda i tipi di commercianti SAQ A, SAQ A-EP e SAQ D.
Obiettivi
- Esaminare l'architettura delle app di elaborazione dei pagamenti.
- Configura l'ambiente di elaborazione dei pagamenti.
- Esegui il deployment e configura i server delle app.
- Configura il logging e il monitoraggio.
- Convalida l'ambiente di elaborazione dei pagamenti.
Definizioni
Questa guida utilizza molte frasi 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 della tua app che detiene o trasferisce dati del titolare della carta, incluso il numero dell'account pagamenti o qualsiasi informazione che consenta l'identificazione personale relativa alla carta.
Controlli compensativi: soluzioni alternative che possono essere prese in considerazione se un'entità non è in grado di soddisfare un requisito esplicitamente indicato, a causa di vincoli aziendali tecnici o documentati legittimi. Le persone giuridiche devono mitigare sufficientemente il rischio associato al requisito quando implementano questi altri controlli. Consulta "Controlli di compensazione" Nelle Appendici B e C dei Requisiti PCI DSS e Procedure di valutazione della sicurezza per indicazioni sull'uso dei controlli compensativi.
PAN: acronimo di numero di conto principale, noto anche come numero di conto. Si tratta del numero univoco della carta di pagamento che identifica l'emittente e l'account del titolare della carta.
QSA: acronimo di Qualified Security Assessor. I QSA sono qualificati dal PCI Security Standards Council (SSC) per eseguire valutazioni PCI DSS on-site. I requisiti di qualifica per gli valutatori della sicurezza qualificati (QSA) forniscono dettagli sui requisiti per le aziende e i dipendenti QSA.
SAQ: 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 persone giuridiche idonee per l'autovalutazione.
Ambito: i sistemi, le procedure e le persone da includere in un PCI DSS la valutazione.
Tokenizzazione: un processo che sostituisce il numero PAN (Permanent Account Number) con un valore sostitutivo chiamato token. Il PAN viene quindi memorizzato in una ricerca sicura. La detokenizzazione è il processo inverso della ricerca di un PAN tramite il token. Un token può essere un hash o un valore assegnato.
Sfondo
PCI DSS fornisce un elenco di requisiti destinato a migliorare la sicurezza dei titolari di carte. Questi requisiti si suddividono in dodici parti numerate principali e molte sottoparti. Questo documento fa riferimento a questi numeri di parte per fornire un contesto, ma i riferimenti alle sezioni non sono un elenco esaustivo dei requisiti applicabili.
I requisiti di conformità PCI DSS variano a seconda di come la tua azienda gestisce le transazioni con carte di pagamento (tipo) e quante transazioni esegue ogni anno (livello).
Con l'aumento del numero di transazioni, Livello commerciante PCI DSS aumenta e le linee guida di conformità PCI DSS diventano più rigide. Al livello più alto del commerciante, il livello 1, il PCI DSS richiede un audit. I livelli variano in base al marchio della carta. Il livello 1 è definito da American Express come 2,5 milioni di 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.
Poiché Google Cloud è un fornitore di servizi conforme a PCI DSS 4.0 di livello 1, può supportare le tue esigenze di conformità a PCI DSS indipendentemente dal livello del commerciante della tua azienda. La sezione Impegno alla conformità illustra le aree coperte da Google per te.
L'altra variabile fondamentale è il tipo di SAQ. I contorni del SAQ criteri da soddisfare per garantire la conformità allo standard PCI DSS in caso di idoneità all'autovalutazione. Il tipo di SAQ è determinato dall'architettura dell'app e dal modo preciso in cui gestisci i dati delle carte di pagamento. La maggior parte dei commercianti nel cloud è una delle seguenti:
| Tipo di SAQ | Descrizione |
|---|---|
| A | Commercianti che hanno completamente esternalizzato l'elaborazione delle carte di pagamento a un sito di terze parti. I clienti escono dal tuo dominio (anche tramite un
<iframe> modulo web), completano il pagamento e poi tornano alla tua
app.In altre parole, la tua azienda non può in alcun modo accedere ai dati delle carte dei clienti. |
| A-EP | 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 elaboratore lato client oppure l'elaboratore esegue il rendering di tutti i contenuti ospitati da te. |
| 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. Il SAQ D distingue 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 Gestore 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 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, 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 matrice di responsabilità condivisa di Google Cloud illustra gli obblighi di conformità del PCI DSS. La matrice di responsabilità può essere un riferimento utile per perseguire la conformità allo standard PCI DSS e condurre i tuoi audit PCI DSS.
Indicazioni relative ai prodotti
Questa sezione contiene indicazioni per i servizi Google Cloud di uso comune nelle architetture utilizzate per gli ambienti PCI DSS.
App Engine
Utilizza le regole firewall 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.
Funzioni Cloud Run
Utilizza le impostazioni di rete in entrata e in uscita delle funzioni Cloud Run.
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. Sebbene Google offra automaticamente la crittografia a riposo, non esegue automaticamente gli hash unidirezionali, il troncamento o la tokenizzazione richiesti anche dalle regole.
Architetture di esempio
Questa sezione illustra gli approcci per implementare un ambiente conforme a 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 sue selezioni e procede al pagamento.
L'app di pagamento reindirizza il cliente a un elaboratore di pagamenti di terze parti.
Il cliente inserisce i dati della carta di pagamento in un modulo di pagamento di proprietà e gestito dall'elaboratore di terze parti.
Il fornitore di servizi di terze parti che segue per noi l'elaborazione dei pagamenti controlla i dati della carta di pagamento e poi addebita o rifiuta la carta.
Dopo aver elaborato la transazione, l'elaboratore dei pagamenti di terze parti indirizza nuovamente il cliente all'app del commerciante insieme ai dettagli della transazione.
L'app commerciante invia una richiesta di verifica all'operatore di pagamento per confermare la transazione.
L'elaboratore dei pagamenti risponde per verificare i dettagli della transazione.
SAQ A-EP
L'architettura di elaborazione dei pagamenti SAQ A-EP è incentrata su un'app di elaborazione dei pagamenti che viene eseguita su istanze di macchine virtuali 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 la tua azienda possiede e gestisce.
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. 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 sicura e utilizzano canali sicuri per comunicare con i 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 un modulo di pagamento di proprietà e gestito dalla tua azienda.
Quando il cliente invia le sue informazioni, la tua app di pagamento riceve le informazioni del modulo.
L'app di pagamento convalida i dati di pagamento e in modo sicuro la passa a un elaboratore dei pagamenti di terze parti tramite un'API backend.
Il fornitore di servizi di terze parti che segue per noi l'elaborazione dei pagamenti controlla i dati della carta di pagamento e poi addebita o rifiuta la carta.
L'elaboratore dei pagamenti invia una risposta alla tua app di pagamento, che a sua volta passa un messaggio alla tua app principale.
Tutte queste interazioni vengono registrate e monitorate con Logging e Monitoraggio.
Flusso di elaborazione dei pagamenti rivolto al cliente
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. Il tuo
L'app non può accedere o monitorare i contenuti
<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 quindi 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 interni descritto in precedenza, ma dal punto di vista dei clienti che utilizzano la tua app.
Quando il cliente accede all'URL del tuo modulo di pagamento, il sito presenta un modulo ospitato dalla tua app per i pagamenti. Quando il cliente invia 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 alla tua app. L'app controlla la risposta alla transazione dell'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 interno di elaborazione dei pagamenti dal 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 i dati della sua carta di pagamento, la tua app di elaborazione dei pagamenti li invia in modo sicuro a un elaboratore dei pagamenti di terze parti. 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 & 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 data dall'elaboratore dei pagamenti di terze parti, quindi invia alcuni o tutti i dati della risposta all'app principale. A questo punto, l'app di elaborazione dei pagamenti ha completato la transazione. L'app di base gestisce l'invio di notifiche ai clienti.
SAQ D
Questa sezione descrive il flusso di elaborazione dei pagamenti interno dalla dai 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. L'agente tenta l'addebito e risponde con i dettagli della transazione. L'app riceve ed elabora la risposta, quindi invia alcuni o tutti i dati della risposta all'app principale. A questo punto, l'app di elaborazione dei pagamenti ha completato la transazione. L'app di base gestisce l'attività di notifica del cliente e di consegna del prodotto.
Monitoraggio e registrazione del flusso di dati
Il flusso di monitoraggio e logging è progettato come segue:
Configurazione dell'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.
- Limitare l'accesso al tuo ambiente.
- Configurazione delle risorse virtuali.
- Progettare l'immagine Linux di base che userai per configurare server delle app.
- Implementazione di una soluzione di gestione dei pacchetti sicura.
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 distinto da quello del tuo ambiente di produzione principale. Gli utenti esperti di configurazione di Identity and Access Management (IAM) possono ottenere un isolamento equivalente utilizzando progetti separati per il lavoro in ambito.
Limitazione dell'accesso all'ambiente
Consenti l'accesso all'ambiente di elaborazione dei pagamenti solo alle persone che implementano il codice del sistema di pagamento o gestiscono le macchine del sistema di pagamento (sezione 7.2 e requisito 8.2.1). Questo è noto come principio del privilegio minimo. Utilizza i ruoli IAM per limitare l'accesso. Le best practice includono l'utilizzo dei ruoli, ove possibile, la concessione solo delle autorizzazioni necessarie per eseguire il lavoro previsto e la concessione del ruolo Proprietario solo alle entità che hanno legittimamente bisogno dell'accesso root completo ai tuoi servizi. 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 offrendoti un modo 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 utente. 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 per l'identità digitale del NIST, se possibile.
La sezione 12.7 del SAQ D del PCI DSS richiede che le persone con accesso al tuo ambiente ambito superino un controllo dei precedenti, in conformità con le leggi locali, prima di poter accedere all'ambiente. Per ridurre il rischio di violazioni della conformità, valuta la possibilità di eseguire questi controlli di referenza e dei precedenti penali su ogni persona, indipendentemente dal tipo di conformità.
Protezione della rete
Per proteggere il traffico in entrata e in uscita 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 per proteggere le reti delle istanze Compute Engine e GKE.
Creazione di regole firewall
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 dalle seguenti tre origini:
- HTTPS pubblico, per consentire ai clienti di raggiungere la pagina di pagamento.
- La tua rete di app, in modo che l'app di elaborazione dei pagamenti possa ricevere risposte dal tuo fornitore di servizi di elaborazione 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 le regole firewall VPC e i tag di rete. Consenti il traffico in uscita solo dal modulo di pagamento all'elaboratore dei pagamenti di terze parti. Questa connessione deve essere solo HTTPS. Per testare il tuo lavoro, consulta la sezione sul logging delle regole firewall più avanti in questo documento.
Cloud DNS offre zone DNS private. 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 | Elaboratore dei pagamenti di terze parti | tcp:443. | In uscita Inoltro delle richieste AUTH al fornitore di servizi di pagamento |
| Elaboratore dei pagamenti di terze parti | La tua app di elaborazione dei pagamenti | tcp:5480 | In entrata Accetta le richieste AUTH dai sistemi di pagamento (non contiene dati del titolare della carta) |
| La rete dell'ufficio della tua azienda | vpn-gateway | tcp:8000 | In entrata Accesso all'ambiente di elaborazione dei pagamenti per accedere ai log e alle macchine di sviluppo |
Inoltre, il seguente traffico avviene in modo sicuro nella rete interna della tua app di elaborazione dei pagamenti:
| Origine | Destinazione | Porta | Motivo |
|---|---|---|---|
| Modulo 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 ad assicurare la sicurezza del traffico in entrata dei clienti creando un bilanciatore del carico delle applicazioni esterno (sezioni 2.2.7 e 4.2). Per creare un bilanciatore del carico delle applicazioni esterno, devi avere quanto segue:
- Un sottodominio del tuo sito web utilizzato per il modulo di elaborazione dei pagamenti, ad esempio
payments.your-domain-name.com. - Un certificato SSL valido e firmato che è stato registrato per il tuo sottodominio.
Assicurati che il tuo dominio sia valido osservando le impostazioni DNS nel tuo sito web del dominio del registrar.
Creazione di un'immagine di base Linux
Il PCI DSS contiene requisiti che descrivono come configurare macchine che nell'ambito di un'architettura di elaborazione dei pagamenti conforme. Puoi implementare questi in vari modi, ma l'approccio più semplice è il seguente:
Crea un elenco del software e delle librerie che devono essere installati su ogni server che rientra nell'ambito della tua app di elaborazione dei pagamenti. Per evitare di introdurre vulnerabilità non necessarie nel sistema (requisito 2.2.4), includi solo il minimo di software e librerie necessario per eseguire l'app. I candidati potrebbero includere Google Cloud CLI, runtime e librerie specifiche per il linguaggio o un server web.
Crea un'istanza Compute Engine che utilizza uno dei Google Compute Engine immagini preconfigurate del sistema operativo.
Installa le librerie e il software elencati in precedenza.
Installa e configura
ntpper mantenere sincronizzati gli orologi di sistema. La gestione degli orologi dei server con il Network Time Protocol garantisce l'integrità dei timestamp nei log (sezione 10.6).Assicurati che l'immagine segua le best practice per la creazione di un'immagine Compute Engine sicura (tutta 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 la tua immagine Linux di base quando di creare istanze di macchine virtuali.
Utilizzo della gestione sicura dei pacchetti
La gestione dei pacchetti è un componente chiave di un ambiente di hosting rafforzato per la sicurezza. Ai sensi della sezione 2.2, devi implementare soluzioni di protezione accettate dal settore standard. A meno che tu non utilizzi Container-Optimized OS di Google, è probabile che tu abbia installato un gestore dei pacchetti come RPM, Yum o Apt. La tua app potrebbe utilizzare il proprio gestore di pacchetti specifico per il linguaggio di programmazione, ad esempio NPM, PyPi o Composer, e scaricare le dipendenze alla prima esecuzione.
Se la tua app può recuperare gli aggiornamenti da internet, devi trattare le fonti di aggiornamento come un potenziale rischio per la sicurezza. Gli attacchi a monte o lato offerta, inclusi deliberatamente nei pacchetti ospitati pubblicamente, stanno diventando sempre più comuni. Immagina gli effetti dell'installazione di un aggiornamento di SSH contenente codice dannoso.
Puoi ridurre il rischio di attacchi lato offerta creando un 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 ospita solo software testato e approvato. Blocca il gestore dei pacchetti in modo che non possa contattare altri server per gli aggiornamenti.
Idealmente, il processo di compilazione dell'app recupera e convalida tutti i pacchetti, quindi crea una revisione dell'immagine del disco personalizzata che include tutto ciò di cui il contenitore ha bisogno. In questo modo, i server vengono avviati e scalati senza ritardi dell'installatore e le probabilità di errori casuali al momento del lancio sono ridotte. Puoi anche rivedere qualsiasi versione precedente dell'app esattamente come era in produzione lanciandone l'immagine, il che può essere utile per la diagnostica e la forensistica.
Deployment e configurazione
Imposta quindi il deployment e la configurazione delle istanze dalla tua base dell'immagine.
Eseguire il deployment dell'ambiente
Per soddisfare i requisiti PCI DSS, assicurati di eseguire ogni volta il deployment dell'app corretta, di eseguirlo in modo sicuro e di non installare altri pacchetti software durante il deployment. Per semplificare la procedura di deployment, valuta la possibilità di creare un deployment automatico per la tua app utilizzando Terraform. Terraform ti consente di descrivere l'intero ambiente di elaborazione dei pagamenti, incluse le regole firewall, i gateway, i bilanciatori del carico e le istanze nel codice.
In un deployment automatico, devi verificare l'integrità del software il deployment, di terze parti o personali. Puoi verificare il tuo software eseguendo un hash automatico su ogni pacchetto durante l'installazione. Dopo aver verificato un hash, puoi utilizzare un framework di test automatico per eseguire test di sicurezza e altri test e per verificare che i test siano stati superati.
Infine, quando esegui il deployment delle istanze Compute Engine, progetta un piano di recupero nel caso in cui le istanze non funzionino. Se il periodo di tempo per il tempo di riposo accettabile è sufficientemente lungo, potrebbe essere sufficiente un piano di recupero manuale. In caso contrario, devi progettare un piano di recupero automatico. 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 aver eseguito il deployment delle istanze, assicurati che siano configurate correttamente. Installa software e librerie aggiuntivi sopra ogni immagine di base dell'istanza, in base alle esigenze. Per evitare la complessità, 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
La registrazione genera automaticamente audit log per un'ampia gamma di attività in molti prodotti. A lungo termine, puoi archiviare in modo sicuro i log immutabili utilizzando i blocchi dei bucket di Cloud Storage (sezione 10.3). I blocchi dei bucket ti consentono di impostare 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. Puoi utilizzare questi log per il monitoraggio della rete, l'analisi forense e l'analisi della sicurezza in tempo reale (sezione 10.2).
Installazione dell'agente Logging
Dopo aver configurato iptables sui 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, trasmettili tramite streaming a Logging e monitoraggio installando l'agente di logging su ogni server (sezione 10.3).
Integrare un sistema di rilevamento delle intrusioni
Per contribuire a garantire la sicurezza del tuo ambiente di elaborazione dei pagamenti, descritto nella sezione 11.5, utilizza un IDS (Intrusion Detection System) per sapere quando malintenzionati tentano di attaccare il sistema. Esistono due modi per 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 IDS (Cloud Intrusion Detection System), un servizio di rilevamento delle intrusioni, offre il rilevamento delle minacce come intrusioni, malware, spyware e attacchi command-and-control sulla tua rete. Cloud IDS offre una visibilità completa sul traffico di rete, incluso il traffico nord/sud e est/ovest, consentendoti di monitorare le comunicazioni da VM a VM per rilevare il movimento laterale. Puoi 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 di sicurezza a raccogliere dati, identificare minacce e rispondere 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, puoi visualizzare e monitorare un inventario dei tuoi asset cloud, effettuare la scansione dei sistemi di archiviazione per individuare dati sensibili, rilevare le vulnerabilità web comuni e controllare i diritti di accesso alle risorse critiche, il tutto da un'unica dashboard centralizzata. Può 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, ad esempio Cloud Storage purché la posizione sia sicura.
Molti degli strumenti di gestione della configurazione menzionati in precedenza supportano i flussi di lavoro di integrazione e deployment continui (CI/CD), che possono essere utilizzati anche per eseguire la scansione automatica (sezione 11.3) e per garantire che il codice venga esaminato (requisito 6.2.3).
Acquisizione dei log di Configuration Manager
Quando configuri il gestore della configurazione, assicurati che registri tutti i dettagli di installazione. Dopo aver completato la procedura di configurazione, assicurati che i log vengano inviati a Logging e monitoraggio.
Logging e monitoraggio
Per garantire la conformità a PCI DSS ai sensi della sezione 10, assicurati che ogni passaggio eseguito nel tuo ambiente di elaborazione dei pagamenti sia monitorato e registrato. Ogni attività del server su ogni istanza deve essere registrata e ogni azione dell'utente deve essere esaminabile in un secondo momento.
Attivazione di Access Transparency
Grazie a Access Transparency, ora la funzionalità di logging offre log quasi in tempo reale quando gli amministratori di Google Cloud accedono ai tuoi contenuti. Log di Cloud Audit Logs già offrono visibilità sulle azioni dei tuoi amministratori. Tuttavia, questo audit trail in genere esclude le azioni intraprese dal team di assistenza o di ingegneria del tuo cloud provider. Ad esempio, prima del logging delle approvazioni dell'accesso, se aprissi un ticket con l'Assistenza Google che richiedeva l'accesso ai dati, il ticket non verrebbe monitorato negli audit log di Cloud. L'approvazione dell'accesso colma questa lacuna, acquisendo log quasi in tempo reale di accessi mirati manuali da parte del team di assistenza o tecnico.
Access Approval ti consente di approvare esplicitamente l'accesso ai tuoi dati o alle tue configurazioni su Google Cloud prima che venga eseguito l'accesso. Access Approval fornisce inoltre informazioni sugli accessi da parte del team di assistenza e tecnico di Google.
Attivazione del logging delle regole firewall
Logging delle regole firewall consente di abilitare il logging a livello di singola regola. Può registrare le connessioni TCP e UDP all'interno di un VPC per qualsiasi regola creata personalmente. 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 ti consente di definire un perimetro di sicurezza attorno alle risorse Google Cloud come i bucket Cloud Storage, le istanze Bigtable e i set di dati BigQuery per limitare i dati in una rete VPC e contribuire a mitigare i rischi di esfiltrazione dei dati (requisiti 1.3.1 e 1.3.2). Con i Controlli di servizio VPC, puoi mantenere privati i tuoi dati sensibili, avvalendoti delle funzionalità di archiviazione ed elaborazione dati completamente gestite di Google Cloud.
Configurazione dei log di flusso VPC
I log di flusso VPC registrano i flussi di traffico di rete inviati o ricevuti dalle istanze VM. I log sono 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 dei log attivando solo i log flussi nel tuo CDE ambito. I log flussi, combinati con le regole firewall in uscita, ti consentono di limitare il traffico in uscita agli endpoint autorizzati in modo verificabile e difficile da aggirare (requisiti 1.2.1 e 1.3.4).
Il seguente diagramma mostra in che modo i log di flusso VPC registrano i flussi di traffico di rete inviati o ricevuti dalle istanze VM.
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. A tale scopo, utilizza il tuo server proxy inverso configurato per inoltrare i log di accesso a Logging. Per istruzioni su come configurare un server proxy Squid su Compute Engine, consulta 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à delle persone che hanno accesso amministrativo al tuo ambiente di elaborazione dei pagamenti (sezione 10.2). Per farlo, puoi registrare i comandi della shell. Diversi strumenti open source possono controllare i comandi shell e inviarli al logging. 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 gli avvisi coprano eventi ambientali, di controllo e delle app interne. Basati sulla strategia di invio di avvisi in base ai potenziali rischi o vettori di attacco per ogni componente della tua app di elaborazione dei pagamenti. Ad esempio, attiva gli avvisi di monitoraggio se il tuo IDS rileva tentativi di intrusione, che siano riusciti o meno. Puoi anche utilizzare il logging delle regole firewall per attivare avvisi in risposta a tentativi di violazione criteri di rete.
Streaming dei log in BigQuery
Se vuoi, puoi inoltrare i log di Log in BigQuery per analizzarli in un secondo momento. Per maggiori dettagli, consulta la Panoramica di routing e archiviazione: sink. Poiché BigQuery è ottimizzato per eseguire query su set di dati di grandi dimensioni, è uno strumento ideale per l'analisi dei log su larga scala. I log possono anche essere registrati direttamente in BigQuery per i log che richiedono un'analisi quasi in tempo reale (requisito 10.4.1).
Utilizzo di Sensitive Data Protection per la sanificazione dei dati
Esistono molti motivi per utilizzare parti dei dati contenuti nell'app in ambito che non rientrano nell'ambito, ad esempio per l'analisi o lo sviluppo. Concedi alle app l'accesso ai dati PCI solo dopo che sono stati sottoposti a sanificazione con Sensitive Data Protection (Requisito 6.5.1).
Sicurezza delle app
Per 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 di amministrazione non console, come un portale di fatturazione per l'assistenza clienti. Uno strumento di questo tipo deve avere accesso controls; 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, tutto l'accesso a uno strumento di questo tipo deve utilizzare una crittografia di trasporto efficace. Utilizza la protezione dei dati sensibili per filtrare le informazioni sensibili prima di visualizzarle in qualsiasi strumento di amministrazione.
Utilizzo di Cloud Key Management Service (Cloud KMS)
Cloud KMS è un servizio che consente di gestire le chiavi di crittografia. Può generare, utilizzare, ruotare ed eliminare chiavi di crittografia AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256 ed EC P384. Cloud KMS 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 aver implementato l'ambiente, ma prima che il traffico di produzione scorra al suo interno, devi convalidarlo:
- Se sei un commerciante di livello 1, il tuo ambiente deve essere convalidato da un Qualified Security Assessor (QSA). Un QSA è un'azienda o un privato approvato dal PCI Security Standards Council per convalidare gli ambienti PCI e rilasciare il marchio di approvazione.
- Se sei un commerciante di livello 2 o di livello inferiore, puoi convalidare il tuo ambiente compilando il Questionario di autovalutazione.
Passaggi successivi
- Libreria di documenti PCI DSS
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.