Conformità PCI DSS su GKE

Questa guida ha lo scopo di aiutarti a risolvere i problemi specifici delle applicazioni Google Kubernetes Engine (GKE) quando implementi le responsabilità del cliente per i requisiti dello standard PCI DSS (Payment Card Industry Data Security Standard).

Disclaimer: questa guida viene fornita unicamente a scopo informativo. Le informazioni e i consigli forniti da Google in questa guida non devono essere interpretati come una consulenza legale o di revisione. Ogni cliente è tenuto a valutare autonomamente come fare uso dei servizi in modo da adempiere ai propri obblighi di conformità legale.

Introduzione alla conformità PCI DSS e a GKE

Se gestisci i dati delle carte di pagamento, devi proteggerli, indipendentemente dal fatto che si trovino in un database on-premise o nel cloud. Il PCI DSS è stato sviluppato per incoraggiare e migliorare la sicurezza dei dati dei titolari di carte e facilitare l'ampia adozione di misure di sicurezza dei dati coerenti a livello globale. Il PCI DSS fornisce una base di requisiti tecnici e operativi progettati per proteggere i dati delle carte di credito. Il PCI DSS si applica a tutte le entità coinvolte nell'elaborazione delle carte di pagamento, inclusi commercianti, responsabili del trattamento, acquirenti, emittenti e fornitori di servizi. Il PCI DSS si applica anche a tutte le altre entità che archiviano, elaborano o trasmettono dati dei titolari di carte (CHD) o dati di autenticazione sensibili (SAD) o entrambi.

Le applicazioni containerizzate sono diventate popolari di recente, con molti workload legacy che migrano da un'architettura basata su macchine virtuali (VM) a una containerizzata. Google Kubernetes Engine è un ambiente gestito e pronto per la produzione dedicato al deployment di applicazioni containerizzate. Offre le più recenti innovazioni di Google in termini di produttività degli sviluppatori, efficienza delle risorse, automazione delle operazioni e flessibilità dell'open source per accelerare il time to market.

La conformità è una responsabilità condivisa nel cloud. Google Cloud, incluso GKE (modalità operative Autopilot e Standard), è conforme ai requisiti PCI DSS. Descriviamo le nostre responsabilità nella nostra matrice di responsabilità condivisa.

Pubblico di destinazione

• Clienti che vogliono portare carichi di lavoro conformi a PCI su Google Cloud che coinvolgono GKE.
• Sviluppatori, responsabili della sicurezza, responsabili della conformità, amministratori IT e altri dipendenti che sono responsabili dell'implementazione dei controlli e della conformità ai requisiti PCI DSS.

Prima di iniziare

Per i consigli che seguono, potresti dover utilizzare quanto segue:

• Google Cloud Risorse di organizzazione, cartella e progetto
• Identity and Access Management (IAM)
• Google Kubernetes Engine
• Google Cloud VPC
• Google Cloud Armor
• L'API Cloud Data Loss Prevention (parte di Sensitive Data Protection)
• Identity-Aware Proxy (IAP)
• Security Command Center

Questa guida è destinata a chi ha familiarità con i container e GKE.

Ambito

Questa guida identifica i seguenti requisiti di PCI DSS che sono preoccupazioni uniche per GKE e fornisce indicazioni per soddisfarli. È scritto in base alla versione 4.0 dello standard. Questa guida non copre tutti i requisiti dello standard PCI DSS. Le informazioni fornite in questa guida possono aiutare le organizzazioni a ottenere la conformità PCI DSS, ma non costituiscono una consulenza completa. Le organizzazioni possono coinvolgere un Qualified Security Assessor (QSA) PCI per la convalida formale.

Obiettivi PCI DSS	Requisiti PCI DSS
Segmentare l'ambiente dei dati dei titolari delle carte	A volte chiamato requisito 0. Sebbene non sia obbligatorio per la conformità al PCI, consigliamo questo requisito per mantenere limitato l'ambito del PCI.
Creare e gestire una rete e sistemi sicuri	1. Installare e gestire i controlli di sicurezza della rete Requisito 1.1 Requisito 1.1.2 Requisito 1.2 Requisito 1.2.2 Requisito 1.2.5 Requisito 1.3 Requisito 1.3.1 Requisito 1.4 Requisito 1.4.3 Requisito 1.4.5 2. Applica configurazioni sicure a tutti i componenti di sistema Requisito 2.2 Requisito 2.2.4 Requisito 2.2.5 Requisito 2.2.6
Proteggere i dati dell'account	3. Proteggere i dati dell'account memorizzati Requisito 3.5 Requisito 3.6 4. Proteggi i dati del titolare della carta con una crittografia efficace durante la trasmissione su reti aperte e pubbliche Requisito 4.1
Mantenere un programma di gestione delle vulnerabilità	5. Proteggi tutti i sistemi e le reti da software dannosi Requisito 5.2 Requisito 5.2.3 Requisito 5.3 6. Sviluppare e gestire sistemi e software sicuri Requisito 6.2 Requisito 6.2.1 Requisito 6.3 Requisito 6.3.1 Requisito 6.4
Implementare misure di controllo dell'accesso efficaci	7. Limita l'accesso ai componenti di sistema e ai dati dei titolari delle carte in base alla necessità di conoscere l'attività Requisito 7.2 Requisito 7.2.2 8. Identificare e autenticare l'accesso ai componenti di sistema Requisito 8.2 Requisito 8.2.1 Requisito 8.2.5 Requisito 8.3 Requisito 8.3.1 9. Limitare l'accesso fisico ai dati del titolare della carta
Monitorare e testare regolarmente le reti	10. Registra e monitora tutti gli accessi ai componenti di sistema e ai dati dei titolari delle carte Requisito 10.2 Requisito 10.2.2 11. Testa regolarmente la sicurezza di sistemi e reti Requisito 11.3 Requisito 11.3.1 Requisito 11.5 Requisito 11.5.1
Mantenere una policy di sicurezza delle informazioni	12. Supportare la sicurezza delle informazioni con norme e programmi organizzativi

Terminologia

Questa sezione definisce i termini utilizzati in questa guida. Per maggiori dettagli, consulta il glossario PCI DSS.

CHD

dati del titolare della carta. Come minimo, è costituito dal numero di conto principale completo (PAN). I dati del titolare della carta potrebbero essere visualizzati anche sotto forma di PAN completo più uno dei seguenti elementi:

• Nome del titolare della carta
• Data di scadenza o codice di servizio
• Dati di autenticazione sensibili (SAD)

CDE

ambiente dei dati del titolare della carta. Le persone, i processi e la tecnologia che archiviano, elaborano o trasmettono i dati del titolare della carta o i dati di autenticazione sensibili.

PAN

numero del conto principale. Un elemento chiave dei dati del titolare della carta che sei obbligato a proteggere ai sensi del PCI DSS. Il PAN è in genere un numero di 16 cifre univoco per una carta di pagamento (di credito e di debito) che identifica l'emittente e il conto del titolare della carta.

PIN

numero di identificazione personale. Una password numerica nota solo all'utente e a un sistema; utilizzata per autenticare l'utente nel sistema.

QSA

revisore della sicurezza qualificato. Una persona certificata dal PCI Security Standards Council per eseguire audit e analisi di conformità.

SAD

dati di autenticazione sensibili. Conformità PCI, dati utilizzati dagli emittenti delle carte per autorizzare le transazioni. Analogamente ai dati dei titolari di carte, PCI DSS richiede la protezione dei SAD. Inoltre, i dati strutturati dell'indirizzo non possono essere conservati da commercianti e dai loro elaboratori dei pagamenti. Il SAD include quanto segue:

• Dati "Traccia" delle bande magnetiche
• "Traccia dati equivalenti" generati da carte con chip e contactless
• Codici di convalida della sicurezza (ad esempio, il numero di 3-4 cifre stampato sulle carte) utilizzati per le transazioni online e senza carta.
• PIN e blocchi PIN

segmentazione

Nel contesto di PCI DSS, la pratica di isolare il CDE dal resto della rete dell'entità. La segmentazione non è un requisito PCI DSS. Tuttavia, è vivamente consigliato come metodo che può contribuire a ridurre quanto segue:

• L'ambito e il costo della valutazione PCI DSS
• Il costo e la difficoltà di implementare e mantenere i controlli PCI DSS
• Il rischio per un'organizzazione (ridotto consolidando i dati dei titolari delle carte in un numero inferiore di posizioni più controllate)

Segmentare l'ambiente dei dati dei titolari delle carte

L'ambiente dei dati dei titolari di carte (CDE) comprende persone, processi e tecnologie che archiviano, elaborano o trasmettono dati dei titolari di carte o dati di autenticazione sensibili. Nel contesto di GKE, il CDE comprende anche:

• Sistemi che forniscono servizi di sicurezza (ad esempio IAM).
• Sistemi che facilitano la segmentazione (ad esempio progetti, cartelle, firewall, virtual private cloud (VPC) e subnet).
• Pod e cluster di applicazioni che archiviano, elaborano o trasmettono dati dei titolari di carte. Senza una segmentazione adeguata, l'intera impronta cloud può rientrare nell'ambito di PCI DSS.

Per essere considerato fuori dall'ambito del PCI DSS, un componente di sistema deve essere adeguatamente isolato dal CDE in modo che, anche se il componente di sistema fuori dall'ambito fosse compromesso, non influirebbe sulla sicurezza del CDE.

Un prerequisito importante per ridurre l'ambito del CDE è una chiara comprensione delle esigenze e dei processi aziendali relativi all'archiviazione, all'elaborazione e alla trasmissione dei dati dei titolari delle carte. Limitare i dati del titolare della carta al minor numero possibile di località eliminando i dati non necessari e consolidando quelli necessari potrebbe richiedere la riprogettazione di pratiche commerciali consolidate.

Puoi segmentare correttamente il tuo CDE in diversi modi su Google Cloud. Questa sezione illustra i seguenti mezzi:

• Segmentazione logica utilizzando la gerarchia delle risorse
• Segmentazione di rete utilizzando VPC e subnet
• Segmentazione a livello di servizio mediante VPC
• Altre considerazioni per qualsiasi cluster incluso nell'ambito

Segmentazione logica utilizzando la gerarchia delle risorse

Esistono diversi modi per isolare il tuo CDE all'interno della struttura organizzativa utilizzando la gerarchia delle risorse di Google Cloud. Le risorseGoogle Cloud sono organizzate in modo gerarchico. La risorsa Organizzazione è il nodo radice della gerarchia delle risorse Google Cloud . Cartelle e progetti rientrano nella risorsa Organizzazione. Le cartelle possono contenere progetti e altre cartelle. Le cartelle vengono utilizzate per controllare l'accesso alle risorse nella gerarchia di cartelle tramite le autorizzazioni IAM a livello di cartella. Vengono anche utilizzati per raggruppare progetti simili. Un progetto è un limite di trust per tutte le tue risorse e un punto di applicazione IAM.

Potresti raggruppare tutti i progetti inclusi nell'ambito PCI in una cartella per isolarli a livello di cartella. Puoi anche utilizzare un progetto per tutti i cluster e le applicazioni PCI inclusi nell'ambito oppure creare un progetto e un cluster per ogni applicazione PCI inclusa nell'ambito e utilizzarli per organizzare le risorseGoogle Cloud . In ogni caso, ti consigliamo di mantenere i workload inclusi e non inclusi nell'ambito in progetti diversi.

Segmentazione della rete utilizzando reti e subnet VPC

Puoi utilizzare Virtual Private Cloud (VPC) e le subnet per eseguire il provisioning della rete e per raggruppare e isolare le risorse correlate a CDE. Il VPC è un isolamento logico di una sezione di un cloud pubblico. Le reti VPC forniscono un networking scalabile e flessibile per le tue istanze di macchine virtuali (VM) di Compute Engine e per i servizi che utilizzano istanze VM, incluso GKE. Per maggiori dettagli, consulta la panoramica di VPC e fai riferimento alle best practice e alle architetture di riferimento.

Segmentazione a livello di servizio utilizzando i Controlli di servizio VPC e Cloud Armor

Mentre VPC e le subnet forniscono la segmentazione e creano un perimetro per isolare il tuo CDE, i Controlli di servizio VPC aumentano il perimetro di sicurezza al livello 7. Puoi utilizzare i Controlli di servizio VPC per creare un perimetro intorno ai progetti CDE inclusi nell'ambito. I Controlli di servizio VPC ti offrono i seguenti controlli:

• Controllo Ingress. Solo le identità e i client autorizzati possono accedere al tuo perimetro di sicurezza.
• Controllo in uscita. Solo le destinazioni autorizzate sono consentite per identità e client all'interno del perimetro di sicurezza.

Puoi utilizzare Cloud Armor per creare elenchi di indirizzi IP per consentire o negare l'accesso al tuo bilanciatore del carico HTTP(S) sul perimetro della rete Google Cloud . Esaminando gli indirizzi IP il più vicino possibile all'utente e al traffico dannoso, contribuisci a impedire che il traffico dannoso consumi risorse o entri nelle tue reti VPC.

Utilizza i Controlli di servizio VPC per definire un perimetro di servizio attorno ai progetti in ambito. Questo perimetro regola i percorsi da VM a servizio e da servizio a servizio, nonché il traffico in entrata e in uscita VPC.

Creare e gestire una rete e sistemi sicuri

La creazione e la manutenzione di una rete sicura comprendono i requisiti 1 e 2 di PCI DSS.

Requisito 1

Installare e gestire una configurazione firewall per proteggere i dati dei titolari delle carte e il traffico in entrata e in uscita dal CDE.

I concetti di networking per i container e GKE sono diversi da quelli per le VM tradizionali. I pod possono raggiungersi direttamente, senza NAT, anche tra nodi. In questo modo si crea una topologia di rete semplice che potrebbe sorprenderti se sei abituato a gestire sistemi più complessi. Il primo passo per la sicurezza di rete per GKE è informarsi su questi concetti di networking.

Prima di esaminare i singoli requisiti del requisito 1, ti consigliamo di rivedere i seguenti concetti di networking in relazione a GKE:

• Regole firewall. Le regole firewall vengono utilizzate per limitare il traffico ai nodi. I nodi GKE vengono sottoposti al provisioning come istanze Compute Engine e utilizzano gli stessi meccanismi firewall delle altre istanze. All'interno della rete, puoi utilizzare i tag per applicare queste regole firewall a ogni istanza. Ogni pool di nodi riceve il proprio set di tag che puoi utilizzare nelle regole. Per impostazione predefinita, ogni istanza appartenente a un pool di nodi riceve un tag che identifica un cluster GKE specifico di cui fa parte questo pool di nodi. Questo tag viene utilizzato nelle regole firewall che GKE crea automaticamente per te. Puoi aggiungere tag personalizzati al momento della creazione del cluster o del pool di nodi utilizzando il flag --tags in Google Cloud CLI.

• Norme di rete. Le policy di rete consentono di limitare le connessioni di rete tra i pod, il che può contribuire a limitare il pivot di rete e lo spostamento laterale all'interno del cluster in caso di un problema di sicurezza con un pod. Per utilizzare i criteri di rete, devi abilitare esplicitamente la funzionalità durante la creazione del cluster GKE. Puoi abilitarlo su un cluster esistente, ma i nodi del cluster verranno riavviati. Il comportamento predefinito è che tutta la comunicazione pod-to-pod sia sempre aperta. Pertanto, se vuoi segmentare la rete, devi applicare criteri di rete a livello di pod. In GKE, puoi definire un criterio di rete utilizzando l'API Kubernetes Network Policy o lo strumento kubectl. Queste regole dei criteri di traffico a livello di pod determinano quali pod e servizi possono accedere l'uno all'altro all'interno del cluster.

• Spazi dei nomi. Gli spazi dei nomi consentono la segmentazione delle risorse all'interno del cluster Kubernetes. Kubernetes viene fornito con uno spazio dei nomi predefinito, ma puoi creare più spazi dei nomi all'interno del cluster. Gli spazi dei nomi sono isolati logicamente tra loro. Forniscono l'ambito per pod, servizi e deployment nel cluster, in modo che gli utenti che interagiscono con uno spazio dei nomi non vedano i contenuti in un altro spazio dei nomi. Tuttavia, gli spazi dei nomi all'interno dello stesso cluster non limitano la comunicazione tra gli spazi dei nomi; è qui che entrano in gioco le norme di rete. Per ulteriori informazioni sulla configurazione degli spazi dei nomi, consulta il post del blog Best practice per gli spazi dei nomi.

Il seguente diagramma illustra i concetti precedenti in relazione tra loro e ad altri componenti di GKE come cluster, nodo e pod.

Requisito 1.1

I processi e i meccanismi per l'installazione e la manutenzione dei controlli di sicurezza di rete sono definiti e compresi.

Requisito 1.1.2

Descrivi gruppi, ruoli e responsabilità per la gestione dei componenti di rete.

Innanzitutto, come faresti con la maggior parte dei servizi su Google Cloud, devi configurare i ruoli IAM per impostare l'autorizzazione su GKE. Dopo aver configurato i ruoli IAM, devi aggiungere la configurazione del controllo dell'accesso basato sui ruoli di Kubernetes (RBAC) nell'ambito di una strategia di autorizzazione Kubernetes.

In sostanza, tutta la configurazione IAM si applica a tutte le risorse Google Cloud e a tutti i cluster all'interno di un progetto. La configurazione RBAC di Kubernetes si applica alle risorse di ogni cluster Kubernetes e consente un'autorizzazione granulare a livello di spazio dei nomi. Con GKE, questi approcci all'autorizzazione funzionano in parallelo e le funzionalità di un utente rappresentano effettivamente un'unione dei ruoli IAM e RBAC assegnati:

• Utilizza IAM per controllare gruppi, ruoli e responsabilità per la gestione logica dei componenti di rete in GKE.
• Utilizza Kubernetes RBAC per concedere autorizzazioni granulari ai criteri di rete all'interno dei cluster Kubernetes, per controllare il traffico da pod a pod e per impedire modifiche non autorizzate o accidentali da parte di utenti non CDE.
• Essere in grado di giustificare tutti gli utenti e le autorizzazioni IAM e RBAC. In genere, quando i QSA testano i controlli, cercano una giustificazione aziendale per un campione di IAM e RBAC.

Requisito 1.2

I controlli di sicurezza di rete (NSC) sono configurati e gestiti.

Per prima cosa, configura le regole firewall sulle istanze Compute Engine che eseguono i nodi GKE. Le regole firewall proteggono questi nodi del cluster.

Successivamente, configurerai le policy di rete per limitare i flussi e proteggere i pod in un cluster. Un criterio di rete è una specifica di come i gruppi di pod sono autorizzati a comunicare tra loro e con altri endpoint di rete. Puoi utilizzare l'applicazione dei criteri di rete di GKE per controllare la comunicazione tra i pod e i servizi del cluster. Per segmentare ulteriormente il cluster, crea più spazi dei nomi al suo interno. Gli spazi dei nomi sono isolati logicamente tra loro. Forniscono l'ambito per pod, servizi e deployment nel cluster, in modo che gli utenti che interagiscono con uno spazio dei nomi non vedano i contenuti di un altro spazio dei nomi. Tuttavia, gli spazi dei nomi all'interno dello stesso cluster non limitano la comunicazione tra gli spazi dei nomi. È qui che entrano in gioco le policy di rete. Gli spazi dei nomi consentono la segmentazione delle risorse all'interno del cluster Kubernetes. Per ulteriori informazioni sulla configurazione degli spazi dei nomi, consulta il post del blog Best practice per gli spazi dei nomi.

Per impostazione predefinita, se non esistono criteri in uno spazio dei nomi, tutto il traffico in entrata e in uscita è consentito da e verso i pod in quello spazio dei nomi. Ad esempio, puoi creare un criterio di isolamento predefinito per uno spazio dei nomi creando un criterio di rete che seleziona tutti i pod, ma non consente alcun traffico in entrata verso questi pod.

Requisito 1.2.2

Tutte le modifiche alle connessioni di rete e alle configurazioni dei sistemi di controllo della rete sono approvate e gestite in conformità con la procedura di controllo delle modifiche definita nel requisito 6.5.1.

Per trattare le configurazioni di rete e l'infrastruttura come codice, devi stabilire una pipeline di integrazione continua e distribuzione continua (CI/CD) nell'ambito dei processi di gestione e controllo delle modifiche.

Puoi utilizzare i modelli Cloud Deployment Manager o Terraform come parte della pipeline CI/CD per creare policy di rete sui tuoi cluster. Con Deployment Manager o Terraform, puoi trattare la configurazione e l'infrastruttura come codice in grado di riprodurre copie coerenti dell'ambiente di produzione attuale o di altri ambienti. A questo punto puoi scrivere test delle unità e altri test per assicurarti che le modifiche alla rete funzionino come previsto. Un processo di controllo delle modifiche che include un'approvazione può essere gestito tramite file di configurazione archiviati in un repository di versioni.

Con Terraform Config Validator, puoi definire vincoli per applicare le norme di sicurezza e governance. Se aggiungi Config Validator alla pipeline CI/CD, puoi aggiungere un passaggio a qualsiasi workflow. Questo passaggio convalida un piano Terraform e lo rifiuta se vengono rilevate violazioni.

Requisito 1.2.5

Tutti i servizi, i protocolli e le porte consentiti sono identificati, approvati e hanno un'esigenza aziendale definita.

Per controlli in entrata efficaci per i tuoi cluster GKE, puoi utilizzare le reti autorizzate per limitare determinati intervalli IP che possono raggiungere il control plane del tuo cluster. GKE utilizza sia Transport Layer Security (TLS) sia l'autenticazione per fornire un accesso sicuro all'endpoint del control plane del cluster da internet pubblico. Questo accesso ti offre la flessibilità di amministrare il tuo cluster da qualsiasi luogo. Utilizzando le reti autorizzate, puoi limitare ulteriormente l'accesso a insiemi specifici di indirizzi IP.

Puoi utilizzare Cloud Armor per creare elenchi di indirizzi IP consentiti e non consentiti e criteri di sicurezza per le applicazioni ospitate su GKE. In un cluster GKE, il traffico in entrata viene gestito dal bilanciamento del carico HTTP(S), che è un componente di Cloud Load Balancing. In genere, il bilanciatore del carico HTTP(S) viene configurato dal controller Ingress di GKE, che riceve le informazioni di configurazione da un oggetto Ingress di Kubernetes. Per maggiori informazioni, consulta come configurare le policy Cloud Armor con GKE.

Requisito 1.3

L'accesso alla rete da e verso l'ambiente dei dati dei titolari delle carte è limitato.

Per mantenere privati i dati sensibili, puoi configurare le comunicazioni private tra i cluster GKE all'interno delle reti VPC e i deployment ibridi on-premise utilizzando i controlli di servizio VPC e l'accesso privato Google.

Requisito 1.3.1

Valuta la possibilità di implementare la configurazione di Cloud NAT con GKE per limitare il traffico internet in entrata solo a quel cluster. Puoi configurare un cluster privato per i cluster non pubblici nel tuo CDE. In un cluster privato, i nodi hanno solo indirizzi IP interni RFC 1918, il che garantisce che i loro carichi di lavoro siano isolati dalla rete internet pubblica.

Requisito 1.4

Le connessioni di rete tra reti attendibili e non attendibili sono controllate.

Puoi soddisfare questo requisito utilizzando gli stessi metodi elencati per il requisito 1.3.

Requisito 1.4.3

Vengono implementate misure anti-spoofing per rilevare e bloccare gli indirizzi IP di origine falsificati dall'accesso alla rete attendibile.

Implementi misure anti-spoofing utilizzando indirizzi IP alias su pod e cluster GKE per rilevare e bloccare gli indirizzi IP di origine falsificati dall'accesso alla rete. Un cluster che utilizza intervalli IP alias è chiamato cluster nativo di VPC.

Requisito 1.4.5

La divulgazione degli indirizzi IP interni e delle informazioni di routing è limitata solo alle parti autorizzate.

Puoi utilizzare un agente di mascheramento IP GKE per eseguire la Network Address Translation (NAT) per le traduzioni molti-a-uno degli indirizzi IP su un cluster. Il masquerading maschera più indirizzi IP di origine dietro un singolo indirizzo.

Requisito 2

Applica configurazioni sicure a tutti i componenti del sistema.

Il requisito 2 specifica come rafforzare i parametri di sicurezza rimuovendo le credenziali predefinite e fornite dal fornitore. Rafforzare la sicurezza del cluster è responsabilità del cliente.

Requisito 2.2

Requisito 2.2.4

Sono abilitati solo i servizi, i protocolli, i daemon e le funzioni necessari e tutte le funzionalità non necessarie vengono rimosse o disattivate.

Requisito 2.2.5

Requisito 2.2.6

I parametri di sicurezza del sistema sono configurati per prevenire l'uso improprio.

Pre-deployment

Prima di spostare i container su GKE, ti consigliamo di:

• Inizia con un'immagine di base gestita creata, gestita e controllata per le vulnerabilità da una fonte attendibile. Valuta la possibilità di creare un insieme di immagini di base "note buone" o "golden" che i tuoi sviluppatori possono utilizzare. Un'opzione più restrittiva è utilizzare un'immagine distroless o un'immagine di base scratch.
• Utilizza Artifact Analysis per analizzare le immagini container alla ricerca di vulnerabilità.
• Stabilisci una policy DevOps/SecOps interna per includere nei container solo librerie e binari approvati e attendibili.

Durante la configurazione

Durante la configurazione, ti consigliamo quanto segue:

• Utilizza il sistema operativo ottimizzato per i container predefinito come immagine del nodo per GKE. Container-Optimized OS è basato su Chromium OS ed è ottimizzato per la sicurezza dei nodi.
• Abilita l'upgrade automatico dei nodi per i cluster che eseguono le tue applicazioni. Questa funzionalità esegue automaticamente l'upgrade del nodo alla versione di Kubernetes in esecuzione nel control plane gestito, offrendo maggiore stabilità e sicurezza.
• Attiva la riparazione automatica dei nodi. Quando questa funzionalità è abilitata, GKE controlla periodicamente e utilizza lo stato di integrità del nodo per determinare se un nodo deve essere riparato. Se un nodo richiede una riparazione, viene svuotato e viene creato un nuovo nodo che viene aggiunto al cluster.
• Attiva Cloud Monitoring e Cloud Logging per la visibilità di tutti gli eventi, inclusi gli eventi di sicurezza e lo stato di integrità dei nodi. Crea criteri di avviso di Cloud Monitoring per ricevere una notifica in caso di incidente di sicurezza.
• Applica service account con privilegi minimi per i nodi GKE
• Esamina e applica (se applicabile) la sezione GKE nella guida Google Cloud CIS Benchmark. L'audit logging di Kubernetes è già abilitato per impostazione predefinita e i log per sia le richieste a kubectl sia l'API GKE vengono scritti in Cloud Audit Logs.
• Configura l'audit logging.

Proteggere i dati dell'account

La protezione dei dati dei titolari di carte comprende i requisiti 3 e 4 di PCI DSS.

Requisito 3

Proteggere i dati dell'account memorizzati.

Il requisito 3 dello standard PCI DSS stabilisce che le tecniche di protezione come crittografia, troncamento, mascheramento e hashing sono componenti fondamentali della protezione dei dati dei titolari delle carte. Se un intruso aggira altri controlli di sicurezza e ottiene l'accesso ai dati criptati, senza le chiavi di crittografia appropriate, i dati sono illeggibili e inutilizzabili per quella persona.

Potresti anche prendere in considerazione altri metodi di protezione dei dati archiviati come potenziali opportunità di mitigazione dei rischi. Ad esempio, i metodi per ridurre al minimo il rischio includono la mancata memorizzazione dei dati del titolare della carta, a meno che non sia assolutamente necessario, il troncamento dei dati del titolare della carta se il PAN completo non è necessario e il mancato invio di PAN non protetti utilizzando tecnologie di messaggistica per gli utenti finali, come email e messaggistica istantanea.

Esempi di sistemi in cui i dati della carta potrebbero essere conservati nell'ambito dei flussi di elaborazione dei pagamenti quando vengono eseguiti su Google Cloud sono:

• Bucket Cloud Storage
• Istanze BigQuery
• Datastore
• Cloud SQL

Tieni presente che i dati sanitari protetti potrebbero essere inavvertitamente archiviati nei log di comunicazione via email o dell'assistenza clienti. È prudente utilizzare Sensitive Data Protection per filtrare questi flussi di dati in modo da limitare l'ambiente in ambito ai sistemi di elaborazione dei pagamenti.

Tieni presente che su Google Cloudi dati sono criptati quando sono inattivi per impostazione predefinita e criptati in transito per impostazione predefinita quando attraversano confini fisici. Per attivare queste protezioni non è necessaria alcuna configurazione aggiuntiva.

Requisito 3.5

Il numero di conto principale (PAN) è protetto ovunque venga memorizzato.

Un meccanismo per rendere illeggibili i dati PAN è la tokenizzazione. Per ulteriori informazioni, consulta la guida alla soluzione sulla tokenizzazione dei dati sensibili dei titolari di carte per PCI DSS.

Puoi utilizzare l'API DLP per analizzare, rilevare e segnalare i dati del titolare della carta. Sensitive Data Protection offre supporto integrato per la scansione e la classificazione dei dati PAN di 12-19 cifre in Cloud Storage, BigQuery e Datastore. Dispone inoltre di un'API per lo streaming di contenuti che garantisce il supporto per ulteriori origini dati, carichi di lavoro personalizzati e applicazioni. Puoi anche utilizzare l'API DLPP per troncare (oscurare) o eseguire l'hashing dei dati.

Requisito 3.6

Le chiavi di crittografia utilizzate per proteggere i dati dell'account archiviati sono protette.

Cloud Key Management Service (KMS) è un sistema di archiviazione gestito per le chiavi di crittografia. Può generare, utilizzare, ruotare ed eliminare le chiavi di crittografia. Sebbene Cloud KMS non memorizzi direttamente i secret come i dati del titolare della carta, può essere utilizzato per criptare questi dati.

I secret nel contesto di Kubernetes sono oggetti secret di Kubernetes che ti consentono di archiviare e gestire informazioni sensibili, come password, token e chiavi.

Per impostazione predefinita, Google Cloud cripta i contenuti inattivi dei clienti. GKE gestisce questa crittografia predefinita per conto tuo senza che tu debba fare altro. La crittografia dei secret a livello di applicazione offre un ulteriore livello di sicurezza per i dati sensibili come i secret. Utilizzando questa funzionalità, puoi fornire una chiave che gestisci in Cloud KMS, per criptare i dati a livello di applicazione. In questo modo, ti proteggi dagli utenti malintenzionati che ottengono l'accesso a una copia dell'istanza di archiviazione della configurazione di Kubernetes del tuo cluster.

Requisito 4

Proteggi i dati del titolare della carta con una crittografia efficace durante la trasmissione su reti aperte e pubbliche.

I dati inclusi nell'ambito devono essere criptati durante la trasmissione su reti facilmente accessibili a persone malintenzionate, ad esempio le reti pubbliche.

Istio è un mesh di servizi open source che si sovrappone in modo trasparente alle applicazioni distribuite esistenti. Istio gestisce in modo scalabile l'autenticazione, l'autorizzazione e la crittografia del traffico tra i microservizi. È una piattaforma che include API che ti consentono di integrarti con qualsiasi piattaforma di logging, telemetria o sistema di policy. Il set di funzionalità di Istio consente di eseguire in modo efficiente un'architettura di microservizi distribuita e fornisce un modo uniforme per proteggere, connettere e monitorare i microservizi.

Requisito 4.1

Sono definiti e documentati processi e meccanismi per proteggere i dati del titolare della carta con una crittografia efficace durante la trasmissione su reti pubbliche aperte.

Puoi utilizzare Istio per creare una rete di servizi di cui è stato eseguito il deployment, con bilanciamento del carico, autenticazione da servizio a servizio e monitoraggio. Puoi anche utilizzarlo per fornire una comunicazione sicura tra servizi in un cluster, con autenticazione e autorizzazione basate sull'identità e su TLS reciproca. TLS reciproco (mTLS) è un handshake TLS eseguito due volte, che stabilisce lo stesso livello di attendibilità in entrambe le direzioni (anziché l'attendibilità unidirezionale client-server).

Istio consente di eseguire il deployment dei certificati TLS in ciascuno dei pod GKE all'interno di un'applicazione. I servizi in esecuzione sul pod possono utilizzare mTLS per identificare con certezza le identità peer. La comunicazione da servizio a servizio viene incapsulata tramite i proxy Envoy lato client e lato server. Envoy utilizza gli ID SPIFFE per stabilire connessioni mTLS tra i servizi. Per informazioni su come eseguire il deployment di Istio su GKE, consulta la documentazione di GKE. Per informazioni sulle versioni TLS supportate, consulta la guida di riferimento per la gestione del traffico di Istio. Utilizza TLS versione 1.2 e successive.

Se la tua applicazione è esposta a internet, utilizza il bilanciamento del carico HTTP(S) di GKE con il routing Ingress impostato per l'utilizzo di HTTP(S). Il bilanciamento del carico HTTP(S), configurato da un oggetto Ingress, include le seguenti funzionalità:

• Configurazione flessibile per i servizi. Un oggetto Ingress definisce il modo in cui il traffico raggiunge i tuoi servizi e come viene instradato alla tua applicazione. Inoltre, una risorsa Ingress può fornire un singolo indirizzo IP per più servizi nel cluster.
• Integrazione con i Google Cloud servizi di rete. Un oggetto Ingress può configurare Google Cloud funzionalità come certificati SSL gestiti da Google (beta), Cloud Armor, Cloud CDN e Identity-Aware Proxy.
• Supporto di più certificati TLS. Un oggetto Ingress può specificare l'utilizzo di più certificati TLS per la terminazione delle richieste.

Quando crei un oggetto Ingress, il controller Ingress di GKE crea un bilanciatore del carico HTTP(S) di Cloud e lo configura in base alle informazioni di Ingress e dei servizi associati.

Gestire un programma di gestione delle vulnerabilità

Il mantenimento di un programma di gestione delle vulnerabilità comprende i requisiti 5 e 6 di PCI DSS.

Requisito 5

Proteggi tutti i sistemi e le reti da software dannosi.

Il requisito 5 del PCI DSS stabilisce che il software antivirus deve essere utilizzato su tutti i sistemi comunemente interessati da malware per proteggerli dalle minacce di software dannoso attuali e in evoluzione e i container non fanno eccezione.

Requisito 5.2

Il software dannoso (malware) viene impedito o rilevato e risolto.

Devi implementare programmi di gestione delle vulnerabilità per le tue immagini container.

Consigliamo di eseguire queste operazioni:

• Controlla e applica regolarmente le patch di sicurezza aggiornate sui container.
• Esegui regolarmente l'analisi delle vulnerabilità su applicazioni containerizzate e binari/librerie.
• Esegui la scansione delle immagini nell'ambito della pipeline di build.
• Abbonati a un servizio di intelligence sulle vulnerabilità per ricevere informazioni aggiornate sulle vulnerabilità pertinenti all'ambiente e alle librerie utilizzate nei container.

Google Cloud collabora con vari fornitori di soluzioni di sicurezza dei container per migliorare la security posture all'interno delle implementazioni dei clienti. Google Cloud Ti consigliamo di sfruttare soluzioni e tecnologie di sicurezza convalidate per aumentare la profondità della difesa nel tuo ambiente GKE. Per l'elenco più recente dei partner per la sicurezza con convalidaGoogle Cloud, consulta la pagina Partner per la sicurezza.

Requisito 5.2.2

Requisito 5.2.3

Esistono molte soluzioni disponibili per eseguire scansioni di malware, ma PCI DSS riconosce che non tutti i sistemi sono ugualmente vulnerabili. È comune che i commercianti dichiarino i propri server Linux, mainframe e macchine simili come non "comunemente interessati da software dannoso" e quindi esenti dal punto 5.2.2. In questo caso, si applica la sezione 5.2.3 e devi implementare un sistema per valutazioni periodiche delle minacce.

Tieni presente che queste regole si applicano sia ai nodi che ai pod all'interno di un cluster GKE.

Requisito 5.3

I meccanismi e i processi anti-malware sono attivi, gestiti e monitorati.

I requisiti 5.2, 5.3 e 11.5 prevedono scansioni antivirus e monitoraggio dell'integrità dei file (FIM) su qualsiasi host incluso nell'ambito. Ti consigliamo di implementare una soluzione in cui tutti i nodi possono essere analizzati da un agente attendibile all'interno del cluster o in cui ogni nodo dispone di uno scanner che invia report a un singolo endpoint di gestione.

Per saperne di più, consulta la panoramica della sicurezza per GKE e la panoramica della sicurezza per Container-Optimized OS.

Una soluzione comune ai requisiti antivirus e FIM è bloccare il container in modo che solo cartelle specifiche consentite abbiano accesso in scrittura. Per farlo, esegui i container come utente non root e utilizza le autorizzazioni del file system per impedire l'accesso in scrittura a tutte le directory tranne quelle di lavoro all'interno del file system del container. Disallow privilege escalation per evitare l'elusione delle regole del file system.

Requisito 6

Sviluppare e gestire sistemi e software sicuri.

Il requisito 6 di PCI DSS prevede che tu stabilisca un ciclo di vita di sviluppo del software solido in cui la sicurezza sia integrata in ogni fase dello sviluppo del software.

Requisito 6.2

Il software personalizzato e su misura viene sviluppato in modo sicuro.

Requisito 6.2.1

Puoi utilizzare Autorizzazione binaria per contribuire a garantire che solo i container attendibili vengano sottoposti a deployment su GKE. Se vuoi attivare solo le immagini autorizzate da uno o più attestatori specifici, puoi configurare Autorizzazione binaria per applicare un criterio con regole che richiedono attestazioni basate sui risultati della scansione delle vulnerabilità. Puoi anche scrivere criteri che richiedono l'approvazione di una o più parti attendibili (chiamate "attestatori") prima che un'immagine possa essere implementata. Per una pipeline di deployment in più fasi in cui le immagini passano dai cluster di sviluppo a quelli di test e produzione, puoi utilizzare gli attestatori per assicurarti che tutti i processi richiesti siano stati completati prima che il software passi alla fase successiva.

Al momento del deployment, Autorizzazione binaria applica il criterio verificando che l'immagine container abbia superato tutti i vincoli richiesti, incluso che tutti gli attestatori richiesti abbiano verificato che l'immagine è pronta per il deployment. Se l'immagine supera il test, il servizio ne consente il deployment. In caso contrario, il deployment viene bloccato e l'immagine non può essere eseguita finché non è conforme.

Per maggiori informazioni su Autorizzazione binaria, consulta Configurazione per GKE.

In caso di emergenza, puoi bypassare un criterio di autorizzazione binaria utilizzando il flusso di lavoro di emergenza. Tutti i casi di emergenza sono registrati in Cloud Audit Logs.

GKE Sandbox riduce la necessità che il container interagisca direttamente con l'host, riducendo la superficie di attacco per la compromissione dell'host e limitando il movimento degli utenti malintenzionati.

Requisito 6.3

Le vulnerabilità di sicurezza vengono identificate e risolte.

Requisito 6.3.1

La sicurezza nel cloud è una responsabilità condivisa tra il cloud provider e il cliente.

In GKE, Google gestisce il control plane, che include le VM principali, il server API e altri componenti in esecuzione su queste VM, nonché il database etcd. Sono inclusi upgrade e applicazione di patch, scalabilità e riparazioni, il tutto supportato da un obiettivo del livello di servizio (SLO). Per il sistema operativo dei nodi, ad esempio Container-Optimized OS o Ubuntu, GKE rende immediatamente disponibili le patch per queste immagini. Se hai attivato l'upgrade automatico, queste patch vengono implementate automaticamente. Si tratta del livello di base del container, che non è lo stesso del sistema operativo in esecuzione nei container.

Per saperne di più sul modello di responsabilità condivisa di GKE, consulta Esplorare la sicurezza dei container: il modello di responsabilità condivisa in GKE.

Google fornisce diversi servizi di sicurezza per aiutarti a integrare la sicurezza nella tua pipeline CI/CD. Per identificare le vulnerabilità nelle immagini container, puoi utilizzare Google Artifact Analysis Vulnerability Scanning. Quando un'immagine container viene inviata a Google Container Registry (GCR), l'analisi delle vulnerabilità analizza automaticamente le immagini per individuare vulnerabilità ed esposizioni note provenienti da fonti CVE note. Alle vulnerabilità vengono assegnati livelli di gravità (critica, alta, media, bassa e minima) in base ai punteggi CVSS.

Requisito 6.4

Le applicazioni web rivolte al pubblico sono protette dagli attacchi.

Web Security Scanner consente di analizzare le applicazioni web di App Engine, Compute Engine e GKE esposte pubblicamente per rilevare vulnerabilità comuni che vanno dal cross-site scripting e dagli errori di configurazione alle risorse vulnerabili. Le scansioni possono essere eseguite on demand e pianificate dalla consoleGoogle Cloud . Utilizzando le API Security Scanner, puoi automatizzare la scansione nell'ambito della suite di test di sicurezza nella pipeline di build dell'applicazione.

Implementare misure di controllo dell'accesso rigorose

L'implementazione di misure di controllo dell'accesso dell'accesso rigorose comprende i requisiti 7, 8 e 9 di PCI DSS.

Requisito 7

Limita l'accesso ai componenti del sistema e ai dati del titolare della carta in base alla necessità di conoscerli per l'attività.

Il requisito 7 si concentra sul privilegio minimo o sulla necessità di sapere. Il PCI DSS definisce questi come la concessione dell'accesso alla quantità minima di dati e la fornitura del minor numero di privilegi necessari per svolgere un lavoro.

Requisito 7.2

L'accesso ai componenti e ai dati del sistema è definito e assegnato in modo appropriato.

IAM e il controllo dell'controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes funzionano insieme per fornire controllo dell'accesso dell'accesso granulare al tuo ambiente GKE. IAM viene utilizzato per gestire l'accesso e le autorizzazioni degli utenti Google Cloud alle risorse nel progetto CDE. In GKE, puoi utilizzare IAM anche per gestire l'accesso e le azioni che utenti e service account possono eseguire nei tuoi cluster, ad esempio creare ed eliminare cluster.

Kubernetes RBAC consente di configurare set granulari di autorizzazioni che definiscono in che modo un determinato Google Cloud utente, Google Cloudservice account o gruppo di utenti (Google Gruppi) può interagire con qualsiasi oggetto Kubernetes nel cluster o in uno spazio dei nomi specifico del cluster. Alcuni esempi di autorizzazioni RBAC includono la modifica di deployment o configmap, l'eliminazione di pod o la visualizzazione dei log di un pod. Concedi agli utenti o ai servizi autorizzazioni IAM limitate, ad esempio Visualizzatore cluster Google Kubernetes Engine o ruoli personalizzati, poi applica le RoleBinding RBAC di Kubernetes in modo appropriato.

Cloud Identity Aware Proxy (IAP) può essere integrato tramite l'ingresso per GKE per controllare l'accesso a livello di applicazione per i dipendenti o le persone che richiedono l'accesso alle tue applicazioni PCI.

Inoltre, puoi utilizzare le policy dell'organizzazione per limitare le API e i servizi disponibili in un progetto.

Requisito 7.2.2

Oltre ad assicurarsi che utenti e service account rispettino il principio del privilegio minimo, anche i container devono farlo. Una best practice quando esegui un container è eseguire il processo con un utente non root. Puoi implementare e applicare questa pratica utilizzando il controller di ammissione PodSecurity.

PodSecurity è un controller di ammissione Kubernetes che ti consente di applicare gli standard di sicurezza dei pod ai pod in esecuzione sui tuoi cluster GKE. Gli standard di sicurezza dei pod sono criteri di sicurezza predefiniti che coprono le esigenze di alto livello della sicurezza dei pod in Kubernetes. Questi criteri variano da altamente permissivi ad altamente restrittivi. PodSecurity sostituisce il precedente controller di ammissione PodSecurityPolicy, rimosso in Kubernetes v1.25. Sono disponibili istruzioni per la migrazione da PodSecurityPolicy al controller di ammissione PodSecurity.

Requisito 8

Identificare gli utenti e autenticare l'accesso ai componenti del sistema

Il requisito 8 specifica che a ogni persona che ha accesso ai sistemi PCI inclusi nell'ambito deve essere assegnato un ID univoco per garantire che ogni individuo sia responsabile in modo univoco delle proprie azioni.

Requisito 8.2

L'identificazione degli utenti e gli account correlati per utenti e amministratori vengono gestiti rigorosamente durante il ciclo di vita di un account.

Requisito 8.2.1

A tutti gli utenti viene assegnato un ID univoco prima di consentire l'accesso ai componenti di sistema o ai dati del titolare della carta.

Requisito 8.2.5

L'accesso per gli utenti licenziati viene revocato immediatamente.

Sia IAM che Kubernetes RBAC possono essere utilizzati per controllare l'accesso al cluster GKE e in entrambi i casi puoi concedere le autorizzazioni a un utente. Consigliamo agli utenti di collegarsi al tuo sistema di identità esistente, in modo da poter gestire account utente e criteri in un'unica posizione.

Requisito 8.3

L'autenticazione avanzata per utenti e amministratori è stabilita e gestita.

Requisito 8.3.1

I certificati sono vincolati all'identità di un utente quando esegue l'autenticazione su kubectl. Tutti i cluster GKE sono configurati per accettare le identità di utenti e account di servizio con la convalida delle credenziali e il recupero dell'indirizzo email associato all'identità dell'utente o del account di servizio account. Google Cloud Di conseguenza, le credenziali per questi account devono includere l'ambito OAuth userinfo.email per eseguire l'autenticazione.

Requisito 9

Limitare l'accesso fisico ai dati del titolare della carta.

Google è responsabile dei controlli di sicurezza fisica di tutti i data center Google sottostanti Google Cloud.

Monitorare e testare regolarmente le reti

Il monitoraggio e il test regolari delle reti comprendono i requisiti 10 e 11 di PCI DSS.

Requisito 10

Registra e monitora tutti gli accessi ai componenti di sistema e ai dati dei titolari delle carte.

Requisito 10.2

I log di controllo vengono implementati per supportare il rilevamento di anomalie e attività sospette e l'analisi forense degli eventi.

I cluster Kubernetes hanno il logging di controllo di Kubernetes attivato per impostazione predefinita, che mantiene un record cronologico delle chiamate effettuate al server dell'API Kubernetes. Le voci degli audit log di Kubernetes sono utili per esaminare richieste API sospette, per raccogliere statistiche o per creare avvisi di monitoraggio per chiamate API indesiderate.

I cluster GKE integrano una configurazione predefinita per il logging di controllo di GKE con Cloud Audit Logs e Logging. Puoi visualizzare le voci di audit log di Kubernetes nel tuo progetto Google Cloud .

Oltre alle voci scritte da Kubernetes, gli audit log del tuo progetto contengono voci scritte da GKE.

Per distinguere i carichi di lavoro CDE e non CDE, ti consigliamo di aggiungere etichette ai pod GKE che verranno propagate nelle metriche e nei log emessi da questi carichi di lavoro.

Requisito 10.2.2

Ogni voce di log di controllo in Logging è un oggetto di tipo LogEntry che contiene i seguenti campi:

• Un payload, di tipo protoPayload. Il payload di ogni voce di logg di controllo è un oggetto di tipo AuditLog. Puoi trovare l'identità utente nel campo AuthenticationInfo degli oggetti AuditLog.
• L'evento specifico, che puoi trovare nel campo methodName di AuditLog.
• Un timestamp.
• Lo stato dell'evento, che puoi trovare negli oggetti response dell'oggetto AuditLog.
• La richiesta di operazione, che puoi trovare negli oggetti request e requestMetadata dell'oggetto AuditLog.
• Il servizio che verrà eseguito, che puoi trovare nell'oggetto AuditData in serviceData.

Requisito 11

Testa regolarmente la sicurezza di sistemi e reti.

Requisito 11.3

Le vulnerabilità esterne e interne vengono regolarmente identificate, classificate in ordine di priorità e risolte.

Requisito 11.3.1

L'analisi delle vulnerabilità di Artifact Analysis esegue i seguenti tipi di analisi delle vulnerabilità per le immagini in Container Registry:

• Scansione iniziale. Quando attivi per la prima volta l'API Artifact Analysis, esegue la scansione delle immagini in Container Registry ed estrae il gestore di pacchetti, la base dell'immagine e le occorrenze di vulnerabilità per le immagini.

• Scansione incrementale. Artifact Analysis analizza le nuove immagini quando vengono caricate in Container Registry.

• Analisi continua: man mano che Artifact Analysis riceve informazioni nuove e aggiornate sulle vulnerabilità dalle fonti, esegue nuovamente l'analisi dei container per mantenere aggiornato l'elenco delle occorrenze di vulnerabilità per le immagini già analizzate.

Requisito 11.5

Vengono rilevate e gestite intrusioni nella rete e modifiche impreviste ai file.

Requisito 11.5.1

Google Cloud Packet Mirroring può essere utilizzato con Cloud IDS per rilevare le intrusioni nella rete. Google Cloud Packet Mirroring inoltra tutto il traffico di rete dalle VM di Compute Engine o dai cluster Google Cloud a un indirizzo designato. Cloud IDS può utilizzare questo traffico di mirroring per rilevare un'ampia gamma di minacce, tra cui tentativi di exploit, scansioni delle porte, overflow del buffer, frammentazione del protocollo, traffico command and control (C2) e malware.

Security Command Center ti offre una visibilità centralizzata sullo stato di sicurezza dei serviziGoogle Cloud (incluso GKE) e degli asset in tutta l'organizzazione, il che semplifica la prevenzione, il rilevamento e la risposta alle minacce. Utilizzando Security Command Center, puoi vedere quando sono state rilevate minacce ad alto rischio come malware, cryptomining, accessi non autorizzati alle risorse Google Cloud , attacchi DDoS in uscita, scansione delle porte e attacchi brute-force contro SSH in base ai log di Cloud Logging.

Mantenere una policy di sicurezza delle informazioni

Una solida policy di sicurezza definisce il tono della sicurezza e informa le persone su cosa ci si aspetta da loro. In questo caso, per "persone" si intendono dipendenti a tempo pieno e part-time, dipendenti temporanei, appaltatori e consulenti che hanno accesso al tuo CDE.

Requisito 12

Supportare la sicurezza delle informazioni con norme e programmi organizzativi.

Per informazioni sul requisito 12, consulta la Google Cloud matrice di responsabilità condivisa PCI.

Pulizia

Se hai utilizzato risorse durante la lettura di questo articolo, ad esempio se hai avviato nuove VM o utilizzato gli script Terraform, puoi evitare addebiti sul tuo account Google Cloud eliminando il progetto in cui hai utilizzato queste risorse.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi

• Scopri di più sulla conformità allo standard PCI DSS (Payment Card Industry Data Security Standard).
• Prova il Terraform Starter Kit.
• Esplora architetture, diagrammi e best practice di riferimento su Google Cloud. Consulta il nostro Cloud Architecture Center.