Questa guida ha lo scopo di aiutarti a risolvere i problemi specifici delle applicazioni Google Kubernetes Engine (GKE) quando implementi le responsabilità del cliente in merito ai requisiti dello standard Payment Card Industry Data Security Standard (PCI DSS).
Disclaimer: questa guida viene fornita solo a scopo informativo. Google non intende che le informazioni o i consigli in questa guida costituiscano una consulenza legale o di revisione. Ciascun cliente è responsabile di valutare in modo indipendente il proprio particolare utilizzo dei servizi, in modo da supportare i propri obblighi di legge e di conformità.
Introduzione alla conformità PCI DSS e 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 delle carte e facilitare l'ampia adozione di misure coerenti di sicurezza dei dati a livello globale. PCI DSS fornisce una base di requisiti tecnici e operativi progettati per proteggere i dati delle carte di credito. PCI DSS si applica a tutte le persone giuridiche coinvolte nell'elaborazione delle carte di pagamento, inclusi commercianti, responsabili, acquirenti, emittenti e fornitori di servizi. 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 diventati popolari di recente, con molti carichi di lavoro 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 che consente di eseguire il deployment di applicazioni containerizzate. Offre le più recenti innovazioni di Google in termini di produttività per sviluppatori, efficienza delle risorse, operazioni automatizzate e flessibilità dell'open source per accelerare il time to market.
La conformità è una responsabilità condivisa nel cloud. Google Cloud, incluso GKE (modalità operativa Autopilot e Standard), è conforme ai requisiti PCI DSS. Definisci le nostre responsabilità nella matrice di responsabilità condivisa.
Pubblico di destinazione
- Clienti che vogliono portare carichi di lavoro conformi allo standard PCI in Google Cloud che coinvolgono GKE.
- Sviluppatori, responsabili della sicurezza, addetti alla conformità, amministratori IT e altri dipendenti responsabili dell'implementazione di controlli e della conformità ai requisiti PCI DSS.
Prima di iniziare
Per i consigli che seguono, potresti dover utilizzare quanto segue:
- Risorse di organizzazione, cartella e progetto Google Cloud
- Identity and Access Management (IAM)
- Google Kubernetes Engine
- VPC di Google Cloud
- Google Cloud Armor
- API Cloud Data Loss Prevention (parte di Sensitive Data Protection)
- Identity-Aware Proxy (IAP)
- Security Command Center
Questa guida è rivolta a chi ha familiarità con i container e GKE.
Ambito
Questa guida identifica i seguenti requisiti di PCI DSS che sono preoccupazioni specifiche per GKE e fornisce indicazioni per soddisfarli. È scritto in base alla versione 4.0 dello standard. Questa guida non tratta tutti i requisiti di PCI DSS. Le informazioni fornite in questa guida potrebbero aiutare le aziende a perseguire la conformità allo standard PCI DSS, ma non si tratta di un consiglio esaustivo. Le organizzazioni possono affidarsi a un PCI qualificati Security Assessor (QSA) per una convalida formale.
Terminologia
In questa sezione vengono definiti i termini utilizzati nella guida. Per ulteriori dettagli, consulta il glossario PCI DSS.
- CHD
dati del titolare della carta. Come minimo, è composto dal numero PAN (principale dell'account) completo. I dati del titolare della carta possono essere visualizzati anche sotto forma di PAN completo più uno dei seguenti elementi:
- Nome del titolare della carta
- Data di scadenza e/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 di account principale. Un elemento chiave dei dati dei titolari della carta che hai l'obbligo di proteggere in base ai requisiti PCI DSS. Il PAN è in genere un numero di 16 cifre univoco di una carta di pagamento (di credito e di debito) e che identifica l'emittente e l'account del titolare.
- PIN
Personal Identification Number. Una password numerica nota solo all'utente e a un sistema; utilizzata per autenticare l'utente nel sistema.
- QISA
un valutatore della sicurezza qualificato. Persona certificata dal PCI Security Standards Council per eseguire controlli e analisi di conformità.
- TRISTE
dati di autenticazione sensibili. In conformità PCI, i dati utilizzati dagli emittente delle carte per autorizzare le transazioni. Analogamente ai dati dei titolari della carta, PCI DSS richiede la protezione di SAD. Inoltre, SAD non può essere trattenuta dai commercianti e dai loro elaboratori dei pagamenti. SAD include quanto segue:
- Dati "traccia" da strisce magnetiche
- "Traccia dati equivalenti" generati da chip e carte contactless
- Codici di convalida di sicurezza (ad esempio, il numero di 3-4 cifre stampato sulle carte) utilizzati per le transazioni online e senza carta.
- Blocchi di PIN e PIN
- segmentazione
Nel contesto dello standard PCI DSS, si tratta della 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ò aiutare a ridurre i seguenti problemi:
- Ambito e costo della valutazione PCI DSS
- Il costo e la difficoltà di implementazione e manutenzione dei controlli PCI DSS
- Il rischio per un'organizzazione (ridotto mediante il consolidamento dei dati dei titolari delle carte in un numero inferiore di sedi più controllate)
Segmentare l'ambiente dei dati del titolare della carta
L'ambiente dei dati del titolare della carta (CDE) comprende persone, processi e tecnologie che memorizzano, elaborano o trasmettono i dati del titolare della carta o i 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, VPC (Virtual Private Cloud) e subnet).
- Pod e cluster di applicazioni che archiviano, elaborano o trasmettono i dati dei titolari di carte. Senza una segmentazione adeguata, l'intero cloud può rientrare nell'ambito di PCI DSS.
Per essere considerato fuori dall'ambito di PCI DSS, un componente di sistema deve essere adeguatamente isolato dal CDE in modo che, anche se il componente di sistema fuori ambito sia stato compromesso, non possa influire 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 di carte. Limitare i dati dei titolari delle carte al minor numero di località possibile eliminando i dati superflui 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 metodi:
- Segmentazione logica utilizzando la gerarchia delle risorse
- Segmentazione della rete tramite VPC e subnet
- Segmentazione del livello di servizio tramite VPC
- Altre considerazioni per qualsiasi cluster nell'ambito
Segmentazione logica utilizzando la gerarchia delle risorse
Esistono diversi modi per isolare il CDE all'interno della struttura organizzativa utilizzando la gerarchia delle risorse di Google Cloud. Le risorse Google Cloud sono organizzate in modo gerarchico. La risorsa Organizzazione è il nodo radice nella gerarchia delle risorse di Google Cloud. Cartelle e progetti rientrano nella risorsa Organizzazione. Le cartelle possono contenere progetti e cartelle. Le cartelle vengono utilizzate per controllare l'accesso alle risorse nella gerarchia delle cartelle tramite le autorizzazioni IAM a livello di cartella. Vengono utilizzati anche per raggruppare progetti simili. Un progetto è un confine di attendibilità per tutte le tue risorse e un punto di applicazione IAM.
Puoi raggruppare tutti i progetti in ambito PCI all'interno di una cartella per isolarli a livello di cartella. Potresti anche utilizzare un progetto per tutti i cluster e le applicazioni PCI nell'ambito oppure puoi creare un progetto e un cluster per ogni applicazione PCI nell'ambito e utilizzarli per organizzare le tue risorse Google Cloud. In ogni caso, ti consigliamo di mantenere i carichi di lavoro in ambito e fuori ambito in progetti diversi.
Segmentazione della rete tramite reti e subnet VPC
Puoi utilizzare il Virtual Private Cloud (VPC) e le subnet per eseguire il provisioning della rete e per raggruppare e isolare le risorse relative a CDE. VPC è l'isolamento logico di una sezione di un cloud pubblico. Le reti VPC offrono networking scalabile e flessibile per le istanze di macchine virtuali (VM) Compute Engine e per i servizi che utilizzano le istanze VM, tra cui GKE. Per ulteriori dettagli, consulta la Panoramica di VPC e la pagina relativa alle architetture di riferimento e best practice.
Segmentazione del livello di servizio tramite Controlli di servizio VPC e Google Cloud Armor
Mentre il VPC e le subnet forniscono la segmentazione e creano un perimetro per isolare il CDE, Controlli di servizio VPC aumenta il perimetro di sicurezza al livello 7. Puoi usare Controlli di servizio VPC per creare un perimetro intorno ai progetti CDE in ambito. Controlli di servizio VPC offre i seguenti controlli:
- Controllo in entrata. Solo le identità e i client autorizzati sono consentiti nel perimetro di sicurezza.
- Controllo in uscita. Per le identità e i client sono consentite solo le destinazioni autorizzate all'interno del tuo perimetro di sicurezza.
Puoi utilizzare Google Cloud Armor per creare elenchi di indirizzi IP per consentire o negare l'accesso al 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, eviti che il traffico dannoso consumi risorse o entri nelle reti VPC.
Utilizza i Controlli di servizio VPC per definire un perimetro di servizio attorno ai progetti nell'ambito di applicazione. Questo perimetro regola i percorsi da VM a servizio e da servizio a servizio, nonché il traffico VPC in entrata e in uscita.
Crea e mantieni una rete e sistemi sicuri
La creazione e il mantenimento di una rete sicura soddisfa i requisiti 1 e 2 dello standard PCI DSS.
Requisito 1
Installare e mantenere una configurazione firewall per proteggere i dati e il traffico dei titolari delle carte in entrata e in uscita dal CDE.
I concetti di networking per container e GKE sono diversi da quelli per le VM tradizionali. I pod possono raggiungersi direttamente, senza NAT, anche tra nodi. In questo modo viene creata una topologia di rete semplice che potrebbe sorprendere se di solito gestisci sistemi più complessi. Il primo passo per la sicurezza di rete per GKE consiste nell'acquisire familiarità con questi concetti di networking.
Prima di approfondire 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. Viene eseguito il provisioning dei nodi GKE come istanze di Compute Engine e utilizzano gli stessi meccanismi firewall delle altre istanze. Puoi utilizzare i tag all'interno della rete per applicare queste regole firewall a ogni istanza. Ogni pool di nodi riceve il proprio insieme di tag che puoi utilizzare nelle regole. Per impostazione predefinita, ogni istanza appartenente a un pool di nodi riceve un tag che identifica uno specifico cluster GKE di cui fa parte questo pool di nodi. Questo tag viene utilizzato nelle regole firewall che GKE crea automaticamente. Puoi aggiungere tag personalizzati al momento della creazione del cluster o del pool di nodi utilizzando il flag
--tagsin Google Cloud CLI.Criteri di rete. I criteri di rete consentono di limitare le connessioni di rete tra i pod, il che può contribuire a limitare il Pivot della 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 la funzionalità in modo esplicito durante la creazione del cluster GKE. Puoi abilitarlo su un cluster esistente, ma causerà il riavvio dei nodi del cluster. Il comportamento predefinito è che tutte le comunicazioni pod-to-pod sono sempre aperte. Di conseguenza, 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 offre uno spazio dei nomi predefinito pronto all'uso, ma puoi creare più spazi dei nomi all'interno del cluster. Gli spazi dei nomi sono isolati logicamente l'uno dall'altro. 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. Tuttavia, gli spazi dei nomi all'interno dello stesso cluster non limitano la comunicazione tra gli spazi dei nomi; è qui che entrano in gioco i criteri di rete. Per ulteriori informazioni sulla configurazione degli spazi dei nomi, consulta il post del blog sulle best practice per gli spazi dei nomi.
Il seguente diagramma illustra i concetti precedenti in relazione tra loro e con altri componenti GKE come cluster, nodo e pod.
Requisito 1.1
I processi e i meccanismi per installare e mantenere i controlli di sicurezza di rete sono definiti e compresi.
Requisito 1.1.2
Descrivere i gruppi, i ruoli e le responsabilità per la gestione dei componenti di rete.
Innanzitutto, come per la maggior parte dei servizi su Google Cloud, devi configurare i ruoli IAM per configurare l'autorizzazione su GKE. Una volta impostati i ruoli IAM, devi aggiungere la configurazione del controllo dell'accesso basato sui ruoli di Kubernetes (RBAC) nell'ambito di una strategia di autorizzazione di Kubernetes.
In sostanza, tutta la configurazione IAM si applica a qualsiasi risorsa Google Cloud e a tutti i cluster all'interno di un progetto. La configurazione di Kubernetes RBAC si applica alle risorse di ogni cluster Kubernetes e consente un'autorizzazione granulare a livello dello spazio dei nomi. Con GKE, questi approcci all'autorizzazione funzionano in parallelo, con le capacità di un utente che rappresentano in modo efficace l'unione di ruoli IAM e RBAC assegnati:
- Usa 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 dai pod ai pod e per evitare modifiche non autorizzate o accidentali da parte di utenti non CDE.
- Essere in grado di giustificare per tutti gli utenti e le autorizzazioni IAM e RBAC. In genere, durante i test dei controlli, i QSA cercano una giustificazione aziendale per un campione di IAM e RBAC.
Requisito 1.2
I controlli di sicurezza di rete (NSC) vengono configurati e gestiti.
Innanzitutto, devi configurare le regole firewall sulle istanze di Compute Engine che eseguono i nodi GKE. Le regole firewall proteggono questi nodi cluster.
Il passaggio successivo consiste nella configurazione dei criteri di rete per limitare i flussi e proteggere i pod in un cluster. Un criterio di rete è una specifica del modo in cui i gruppi di pod possono 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 tuo 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, quindi gli utenti che interagiscono con uno spazio dei nomi non vedranno 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 i criteri 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 sulle 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 selezioni tutti i pod, ma non consenta il traffico in entrata verso questi pod.
Requisito 1.2.2
Tutte le modifiche alle connessioni di rete e alle configurazioni delle NSC vengono approvate e gestite in conformità al processo di controllo delle modifiche definito nel Requisito 6.5.1.
Per trattare le configurazioni di networking e l'infrastruttura come codice, devi definire una pipeline di integrazione continua e distribuzione continua (CI/CD) come parte dei processi di gestione e controllo dei cambiamenti.
Puoi utilizzare i modelli Cloud Deployment Manager o Terraform nell'ambito della pipeline CI/CD per creare criteri 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. Quindi puoi scrivere test delle unità e altri test per assicurarti che le modifiche di 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 lo strumento di convalida Terraform Config, puoi definire i vincoli per applicare i criteri di sicurezza e governance. Aggiungendo lo strumento di convalida di configurazione alla pipeline CI/CD, puoi aggiungere un passaggio a qualsiasi flusso di lavoro. Questo passaggio convalida un piano Terraform e lo rifiuta in caso di 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 del traffico in entrata efficaci per i tuoi cluster GKE, puoi utilizzare le reti autorizzate per limitare determinati intervalli IP che possono raggiungere il piano di controllo del cluster. GKE utilizza sia TLS (Transport Layer Security) sia l'autenticazione per fornire un accesso sicuro all'endpoint master del cluster dalla rete internet pubblica. Questo accesso ti offre la flessibilità di amministrare il cluster ovunque ti trovi. Utilizzando le reti autorizzate, puoi limitare ulteriormente l'accesso a insiemi specifici di indirizzi IP.
Puoi utilizzare Google Cloud Armor per creare liste bloccate di IP e liste consentite e criteri di sicurezza per le applicazioni ospitate da GKE. In un cluster GKE, il traffico in entrata è gestito dal bilanciamento del carico HTTP(S), un componente di Cloud Load Balancing. In genere, il bilanciatore del carico HTTP(S) viene configurato dal controller in entrata di GKE, che riceve le informazioni di configurazione da un oggetto Kubernetes in entrata. Per maggiori informazioni, consulta Come configurare i criteri di Google Cloud Armor con GKE.
Requisito 1.3
L'accesso di rete da e verso l'ambiente dei dati del titolare della carta è limitato.
Per mantenere privati i dati sensibili, puoi configurare le comunicazioni private tra i cluster GKE all'interno delle tue reti VPC e i deployment ibridi on-premise utilizzando Controlli di servizio VPC e accesso privato Google.
Requisito 1.3.1
Il traffico in entrata verso il CDE è limitato come segue:
- Solo per il traffico necessario.
- Tutto il resto del traffico viene rifiutato in modo specifico.
Valuta la possibilità di implementare la configurazione di Cloud NAT con GKE per limitare il traffico internet in entrata solo al cluster. Puoi configurare un cluster privato per i cluster non pubblici nel tuo CDE. In un cluster privato, i nodi hanno solo indirizzi IP RFC 1918 interni, il che garantisce che i 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 impedire agli indirizzi IP di origine falsificati di entrare nella rete attendibile.
Puoi implementare misure anti-spoofing utilizzando indirizzi IP alias su pod e cluster GKE per rilevare e bloccare l'ingresso nella rete di indirizzi IP di origine falsificati. Un cluster che utilizza intervalli IP alias è chiamato cluster nativo di VPC.
Requisito 1.4.5
La divulgazione di indirizzi IP interni e informazioni di routing è limitata solo alle parti autorizzate.
Puoi utilizzare un agente di mascheramento IP di GKE per eseguire Network Address Translation (NAT) per le traduzioni di indirizzi IP many-to-one su un cluster. Il mascheramento 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 i valori predefiniti e le credenziali fornite dal fornitore. La protezione del cluster è una responsabilità del cliente.
Requisito 2.2
I componenti del sistema sono configurati e gestiti in modo sicuro.
Assicurati che questi standard affrontino tutte le vulnerabilità di sicurezza note e siano coerenti con gli standard di protezione dei sistemi accettati dal settore. Le fonti di standard di protezione dei sistemi accettate dal settore possono includere, a titolo esemplificativo:Requisito 2.2.4
Vengono 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
- La giustificazione aziendale è documentata.
- Sono state documentate e implementate funzionalità di sicurezza aggiuntive che riducono il rischio di utilizzare servizi, protocolli o daemon non sicuri.
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 quanto segue:
- Inizia con un'immagine di base gestita del container creata, gestita e controllata da un'origine attendibile. Potresti creare un insieme di immagini di base "noto" o "dorate" che gli sviluppatori possono utilizzare. Un'opzione più restrittiva consiste nell'utilizzare un'immagine senza distro o un'immagine di base di scraping.
- Utilizza Artifact Analysis per analizzare le vulnerabilità delle immagini container.
- Stabilire un criterio DevOps/SecOps interno per includere nei container solo librerie e file binari approvati e attendibili.
Al momento della configurazione
Durante la configurazione, consigliamo di svolgere le seguenti operazioni:
- Utilizza il sistema operativo ottimizzato per i container come immagine del nodo per GKE. Container-Optimized OS è basato su Chromium OS ed è ottimizzato per la sicurezza dei nodi.
- Abilita i nodi con upgrade automatico per i cluster che eseguono le tue applicazioni. Questa funzionalità esegue automaticamente l'upgrade del nodo alla versione di Kubernetes in esecuzione sul piano di controllo gestito, migliorando stabilità e sicurezza.
- Abilita i nodi di riparazione automatica. Se questa funzionalità è abilitata, GKE controlla e utilizza periodicamente lo stato di integrità del nodo per determinare se è necessario riparare un nodo. I nodi da riparare vengono svuotati e ne viene creato uno nuovo e 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 notifiche in caso di incidente di sicurezza.
- Applica account di servizio con privilegi minimi per i nodi GKE
- Esamina e applica (se applicabile) la sezione GKE della guida al Benchmark CIS di Google Cloud. L'audit logging di Kubernetes è già abilitato per impostazione predefinita e i log per entrambe le richieste a
kubectle all'API GKE vengono scritti in Cloud Audit Logs. - Configura l'audit logging.
Proteggere i dati dell'account
La protezione dei dati dei titolari di carta comprende i requisiti 3 e 4 di PCI DSS.
Requisito 3
Proteggere i dati dell'account memorizzati.
Il Requisito 3 di PCI DSS stabilisce che le tecniche di protezione come la crittografia, il troncamento, il mascheramento e l'hashing sono componenti fondamentali per la protezione dei dati dei titolari di carta. Se un intruso aggira altri controlli di sicurezza e ottiene l'accesso a dati criptati, senza le chiavi di crittografia appropriate, i dati sono illeggibili e inutilizzabili per l'utente.
Potresti anche prendere in considerazione altri metodi di protezione dei dati archiviati come potenziali opportunità di mitigazione del rischio. Ad esempio, i metodi per ridurre al minimo il rischio includono non archiviare i dati dei titolari delle carte se non assolutamente necessario, troncarli se non è necessario l'intero PAN e non inviare PAN non protetti utilizzando tecnologie di messaggistica per gli utenti finali, come email e messaggistica immediata.
Esempi di sistemi in cui il CHD potrebbe persistere nell'ambito dei flussi di elaborazione dei pagamenti durante l'esecuzione su Google Cloud sono:
- Bucket Cloud Storage
- Istanze BigQuery
- Datastore
- Cloud SQL
Tieni presente che il valore CHD potrebbe essere inavvertitamente archiviato nei log di comunicazione di email o dell'assistenza clienti. È prudente utilizzare Sensitive Data Protection per filtrare questi stream di dati in modo da limitare l'ambiente interessato ai sistemi di elaborazione dei pagamenti.
Tieni presente che su Google Cloud i dati sono criptati at-rest per impostazione predefinita e criptati in transito per impostazione predefinita quando attraversano i confini fisici. Non è necessaria alcuna configurazione aggiuntiva per abilitare queste protezioni.
Requisito 3.5
Il numero di conto principale (PAN) è protetto ovunque sia memorizzato.
Un meccanismo per rendere illeggibili i dati PAN è la tokenizzazione. Per ulteriori informazioni, consulta la guida alle soluzioni sulla tokenizzazione dei dati sensibili dei titolari di carte per PCI DSS.
Puoi utilizzare l'API DLP per scansionare, individuare e segnalare i dati dei titolari della carta. Sensitive Data Protection offre un supporto nativo per la scansione e la classificazione di dati PAN di 12-19 cifre in Cloud Storage, BigQuery e Datastore. Dispone inoltre di un'API per i flussi di contenuti per consentire il supporto di ulteriori origini dati, carichi di lavoro personalizzati e applicazioni. Puoi utilizzare l'API DLP per troncare (oscurare) o sottoporre ad hashing i dati.
Requisito 3.6
Le chiavi di crittografia utilizzate per proteggere i dati degli account archiviati sono protette.
Cloud Key Management Service (KMS) è un sistema di archiviazione gestito per le chiavi di crittografia. Può generare, utilizzare, ruotare e distruggere le chiavi di crittografia. Anche se Cloud KMS non archivia direttamente i secret come i dati dei titolari della carta, può essere utilizzato per criptare questi dati.
I secret nel contesto di Kubernetes sono oggetti segreti di Kubernetes che consentono di archiviare e gestire informazioni sensibili come password, token e chiavi.
Per impostazione predefinita, Google Cloud cripta i contenuti dei clienti archiviati at-rest. GKE gestisce questa crittografia predefinita per conto tuo senza che tu debba fare altro. La crittografia dei secret a livello di applicazione fornisce un ulteriore livello di sicurezza per i dati sensibili come i secret. Con questa funzionalità puoi fornire una chiave che gestisci in Cloud KMS per criptare i dati a livello di applicazione. In questo modo puoi proteggere da 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 dei titolari delle carte con una crittografia efficace durante la trasmissione su reti pubbliche aperte.
I dati nell'ambito di applicazione devono essere criptati durante la trasmissione su reti facilmente accessibili da utenti malintenzionati, ad esempio le reti pubbliche.
Istio è un mesh di servizi open source che si basa in modo trasparente sulle applicazioni distribuite esistenti. Istio gestisce in modo scalabile l'autenticazione, l'autorizzazione e la crittografia del traffico tra microservizi. Si tratta di una piattaforma che include API che consentono l'integrazione in qualsiasi piattaforma di logging, telemetria o sistema di criteri. 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
I processi e i meccanismi per proteggere i dati dei titolari con una crittografia efficace durante la trasmissione su reti aperte e pubbliche sono definiti e documentati.
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 utilizzarlo anche per fornire comunicazioni sicure tra servizi in un cluster, con una solida autenticazione e autorizzazione basata sull'identità e basate su TLS reciproco. Il protocollo mTLS (mutual TLS) è un handshake TLS eseguito due volte, che stabilisce lo stesso livello di attendibilità in entrambe le direzioni (anziché l'attendibilità client-server unidirezionale).
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 usare mTLS per identificare in modo sicuro le identità peer. La comunicazione service-to-service è sottoposta a tunneling 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 il riferimento sulla gestione del traffico di Istio. Utilizza TLS 1.2 e versioni successive.
Se la tua applicazione è esposta a internet, utilizza il bilanciamento del carico HTTP(S) di GKE con il routing in entrata impostato per utilizzare 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 in che modo il traffico raggiunge i tuoi servizi e in che modo viene instradato alla tua applicazione. Inoltre, una risorsa Ingress può fornire un singolo indirizzo IP per più servizi nel cluster.
- Integrazione con i servizi di rete Google Cloud. Un oggetto Ingress può configurare le funzionalità di Google Cloud come i certificati SSL gestiti da Google (beta), Google Cloud Armor, Cloud CDN e Identity-Aware Proxy.
- Supporto per 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 in entrata di GKE crea un bilanciatore del carico HTTP(S) Cloud e lo configura in base alle informazioni contenute nella risorsa Ingress e ai servizi associati.
Mantieni un programma di gestione delle vulnerabilità
Il mantenimento di un programma di gestione delle vulnerabilità comprende i requisiti 5 e 6 dello standard PCI DSS.
Requisito 5
Proteggi tutti i sistemi e le reti da software dannosi.
Il requisito 5 di PCI DSS stabilisce che il software antivirus deve essere utilizzato su tutti i sistemi comunemente interessati da malware per proteggere i sistemi dalle minacce software dannose attuali e in continua evoluzione. Inoltre, i container non fanno eccezione.
Requisito 5.2
Il software dannoso (malware) viene impedito o rilevato e affrontato.
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 ai container.
- Esegui una normale analisi delle vulnerabilità su applicazioni containerizzate e binari/librerie.
- Scansiona le immagini come parte della pipeline di build.
- Abbonati a un servizio di intelligence delle vulnerabilità per ricevere informazioni aggiornate sulle vulnerabilità pertinenti all'ambiente e alle librerie utilizzate nei container.
Google Cloud collabora con vari provider di soluzioni per la sicurezza dei container per migliorare la strategia di sicurezza nei deployment Google Cloud dei clienti. 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 di sicurezza convalidati da Google Cloud, visita la pagina Partner per la sicurezza.
Requisito 5.2.2
Le soluzioni antimalware di cui è stato eseguito il deployment:
- Rileva tutti i tipi di malware noti.
- Rimuove, blocca o contiene tutti i tipi di malware noti.
Requisito 5.2.3
I componenti del sistema che non sono a rischio di malware vengono valutati periodicamente per includere quanto segue:
- Un elenco documentato di tutti i componenti del sistema non a rischio di malware.
- Identificazione e valutazione delle minacce malware in continua evoluzione per i componenti di sistema.
- Conferma se tali componenti di sistema continuano a non richiedere la protezione antimalware.
Sono disponibili molte soluzioni per eseguire le scansioni di malware, ma PCI DSS riconosce che non tutti i sistemi hanno le stesse probabilità di essere vulnerabili. È comune per i commercianti dichiarare i propri server Linux, mainframe e macchine simili come non "comunemente interessati da software dannoso" e quindi esenti dalla versione 5.2.2. In tal caso, si applica la versione 5.2.3 ed è necessario implementare un sistema per la valutazione periodica 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 antimalware sono attivi, mantenuti e monitorati.
I requisiti 5.2, 5.3 e 11.5 richiamano le scansioni antivirus e il monitoraggio dell'integrità dei file (FIM) su qualsiasi host nell'ambito di applicazione. Ti consigliamo di implementare una soluzione in cui tutti i nodi possano essere analizzati da un agente attendibile all'interno del cluster o in cui ogni nodo disponga di uno scanner che segnala fino a un singolo endpoint di gestione.
Per ulteriori informazioni, 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 determinate cartelle consentite abbiano accesso in scrittura. Per farlo, devi eseguire i container come utente non root e utilizzare 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. Non consentire l'escalation dei privilegi per evitare l'elusione delle regole del file system.
Requisito 6
Sviluppa e mantieni sistemi e software sicuri.
Il requisito 6 di PCI DSS prevede un solido ciclo di vita dello sviluppo del software in cui la sicurezza è integrata in ogni fase dello sviluppo del software.
Requisito 6.2
Software su misura e personalizzati vengono sviluppati in modo sicuro.
Requisito 6.2.1
Software su misura e personalizzati vengono sviluppati in modo sicuro, come segue:
- in base agli standard di settore e/o alle best practice per uno sviluppo sicuro.
- In conformità con gli standard PCI DSS (ad esempio, autenticazione e logging sicure).
- Integrazione della considerazione dei problemi di sicurezza delle informazioni durante ogni fase del ciclo di vita di sviluppo del software.
Puoi utilizzare Autorizzazione binaria per garantire che venga eseguito il deployment in GKE solo dei container attendibili. Se vuoi abilitare solo le immagini autorizzate da uno o più attestatori specifici, puoi configurare Autorizzazione binaria per applicare un criterio con regole che richiedono attestations in base ai risultati dell'analisi delle vulnerabilità. Puoi anche scrivere criteri che richiedono a una o più parti attendibili (chiamati "attestatori") di approvare un'immagine prima di poterne eseguire il deployment. Per una pipeline di deployment a più fasi in cui le immagini avanzano dallo sviluppo ai test fino ai cluster di 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 i criteri 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 viene approvata, il servizio ne consente il deployment. In caso contrario, il deployment viene bloccato e non è possibile eseguire il deployment dell'immagine 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 del deployment 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 gestite.
Requisito 6.3.1
Le vulnerabilità di sicurezza sono identificate e gestite come segue:
- Le nuove vulnerabilità di sicurezza vengono identificate utilizzando fonti riconosciute dal settore per le informazioni sulle vulnerabilità della sicurezza, compresi gli avvisi di team di risposta alle emergenze informatiche internazionali e nazionali (CERT).
- Alle vulnerabilità viene assegnato un ranking di rischio in base alle best practice del settore e alla considerazione del potenziale impatto.
- I ranking di rischio identificano, come minimo, tutte le vulnerabilità considerate ad alto rischio o critiche per l'ambiente.
- Sono trattate le vulnerabilità per software su misura e personalizzati e di terze parti (ad esempio sistemi operativi e database).
La sicurezza nel cloud è una responsabilità condivisa tra il cloud provider e il cliente.
In GKE, Google gestisce il piano di controllo, che include le VM master, il server API e altri componenti in esecuzione su queste VM, nonché il database etcd. Ciò include upgrade e patch, scalabilità e riparazioni, il tutto supportato da un obiettivo del livello di servizio (SLO). Per il sistema operativo dei nodi, come Container-Optimized OS o Ubuntu, GKE rende subito disponibili eventuali patch per queste immagini. Se hai abilitato l'upgrade automatico, il deployment di queste patch viene eseguito automaticamente. Questo è il livello di base del container, non è uguale al sistema operativo in esecuzione nei tuoi container.
Per maggiori informazioni sul modello di responsabilità condivisa di GKE, consulta Esplorazione della sicurezza dei container: il modello di responsabilità condivisa in GKE.
Google fornisce diversi servizi di sicurezza per integrare la sicurezza nella tua pipeline CI/CD. Per identificare le vulnerabilità nelle immagini container, puoi utilizzare l'analisi delle vulnerabilità di Google Artifact Analysis. Quando viene eseguito il push di un'immagine container in Google Container Registry (GCR), l'analisi delle vulnerabilità analizza automaticamente le immagini per individuare vulnerabilità ed esposizioni note da origini CVE note. Alle vulnerabilità vengono assegnati livelli di gravità (critico, elevato, medio, basso e minimo) in base ai punteggi CVSS.
Requisito 6.4
Le applicazioni web rivolte al pubblico sono protette dagli attacchi.
Web Security Scanner consente di scansionare le applicazioni web App Engine, Compute Engine e GKE rivolte al pubblico alla ricerca di vulnerabilità comuni che vanno da cross-site scripting, configurazioni errate a risorse vulnerabili. Le scansioni possono essere eseguite on demand e pianificate dalla console Google Cloud. Utilizzando le API Security Scanner, puoi automatizzare la scansione come parte della tua suite di test di sicurezza nella pipeline di build delle applicazioni.
Implementare solide misure di controllo dell'accesso
L'implementazione di misure efficaci di controllo dell'accesso'accesso comprende i requisiti 7, 8 e 9 dello standard PCI DSS.
Requisito 7
Limita l'accesso ai componenti di sistema e ai dati del titolare della carta in base alle esigenze aziendali.
Il requisito 7 è incentrato sui privilegi minimi o sulle informazioni necessarie. PCI DSS definisce queste regole come la concessione dell'accesso alla quantità minima di dati e il numero dei privilegi minimi necessari per eseguire un job.
Requisito 7.2
L'accesso a componenti e dati del sistema viene definito e assegnato in modo appropriato.
IAM e Controllo controllo dell'accesso basato su ruoli (RBAC) di Kubernetes interagiscono per fornire controllo dell'accesso granulare al tuo ambiente GKE. IAM consente di gestire l'accesso e le autorizzazioni degli utenti delle risorse Google Cloud nel progetto CDE. In GKE, puoi anche utilizzare IAM per gestire l'accesso e le azioni che utenti e account di servizio possono eseguire nei tuoi cluster, ad esempio la creazione e l'eliminazione dei cluster.
Kubernetes RBAC consente di configurare set di autorizzazioni granulari che definiscono il modo in cui un determinato utente di Google Cloud, account di servizio Google Cloud o gruppi di utenti (Google Gruppi) possono interagire con qualsiasi oggetto Kubernetes nel cluster o in uno spazio dei nomi specifico del cluster. Esempi di autorizzazioni RBAC includono la modifica di deployment o ConfigMap, l'eliminazione di pod o la visualizzazione dei log da un pod. Concedi a utenti o servizi autorizzazioni IAM limitate, ad esempio Visualizzatore cluster Google Kubernetes Engine o ruoli personalizzati, quindi applica le associazioni di ruoli Kubernetes RBAC in base alle tue esigenze.
Cloud Identity Aware Proxy (IAP) può essere integrato tramite Ingress per GKE per controllare l'accesso a livello di applicazione per i dipendenti o le persone che richiedono l'accesso alle applicazioni PCI.
Inoltre, puoi utilizzare i Criteri dell'organizzazione per limitare le API e i servizi disponibili all'interno di un progetto.
Requisito 7.2.2
L'accesso viene assegnato agli utenti, inclusi gli utenti con privilegi, in base a:
- Classificazione e funzione del lavoro.
- Almeno privilegi necessari per eseguire le responsabilità lavorative.
Oltre ad assicurare che gli utenti e gli account di servizio rispettino il principio del privilegio minimo, anche i container dovrebbero farlo. Una best practice per l'esecuzione di un container consiste nell'eseguire il processo con un utente non root. Puoi eseguire 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 le istruzioni per la migrazione da PodSecurityPolicy al controller di ammissione PodSecurity.
Requisito 8
Identifica gli utenti e autentica l'accesso ai componenti del sistema
Il requisito 8 specifica che è necessario assegnare un ID univoco a ogni persona che ha accesso ai sistemi PCI nell'ambito per garantire che ogni individuo sia responsabile delle proprie azioni in modo univoco.
Requisito 8.2
L'identificazione degli utenti e i relativi account per utenti e amministratori sono rigorosamente gestiti durante l'intero 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 terminati viene revocato immediatamente.
Sia IAM che Kubernetes RBAC possono essere utilizzati per controllare l'accesso al tuo cluster GKE e, in entrambi i casi, puoi concedere le autorizzazioni a un utente. Consigliamo agli utenti di ricollegarsi al sistema di identità esistente, in modo da poter gestire gli account utente e i criteri in un'unica posizione.
Requisito 8.3
L'autenticazione avanzata per utenti e amministratori viene stabilita e gestita.
Requisito 8.3.1
- Qualcosa che conosci, ad esempio una password o una passphrase.
- Qualcosa che possiedi, ad esempio un token o una smart card.
- Qualcosa che sei, ad esempio un elemento biometrico.
I certificati sono associati all'identità di un utente quando esegui l'autenticazione in kubectl.
Tutti i cluster GKE sono configurati per accettare le identità degli utenti e degli account di servizio Google Cloud, convalidando le credenziali e recuperando l'indirizzo email associato all'identità dell'account utente o di servizio. Di conseguenza,
le credenziali di questi account devono includere l'ambito OAuth userinfo.email
per poter eseguire correttamente l'autenticazione.
Requisito 9
Limitare l'accesso fisico ai dati del titolare della carta.
Google è responsabile dei controlli di sicurezza fisica in tutti i data center di Google sottostanti a Google Cloud.
Monitora e testa regolarmente le reti
Il monitoraggio e i test regolari delle reti soddisfano i requisiti 10 e 11 dello standard PCI DSS.
Requisito 10
Registra e monitora tutti gli accessi ai componenti di sistema e ai dati del titolare della carta.
Requisito 10.2
Gli audit log sono implementati per supportare il rilevamento di anomalie e attività sospette e l'analisi forense degli eventi.
Nei cluster Kubernetes è abilitato per impostazione predefinita l'audit logging di Kubernetes, che conserva un record cronologico delle chiamate effettuate al server API Kubernetes. Le voci degli audit log di Kubernetes sono utili per analizzare le richieste API sospette, raccogliere statistiche o creare avvisi di monitoraggio per chiamate API indesiderate.
I cluster GKE integrano una configurazione predefinita per l'audit logging di GKE con Audit log di Cloud e Logging. Puoi visualizzare le voci degli audit log di Kubernetes nel tuo progetto Google Cloud.
Oltre alle voci scritte da Kubernetes, gli audit log del progetto hanno voci scritte da GKE.
Per differenziare i carichi di lavoro CDE da quelli non CDE, ti consigliamo di aggiungere etichette ai pod GKE che verranno inserite nelle metriche e nei log emessi da questi carichi di lavoro.
Requisito 10.2.2
- Identificazione utente
- Tipo di evento
- Data e ora
- Indicazione di operazione riuscita
- Origine dell'evento
- Identità o nome dei dati, del componente, della risorsa o del servizio interessati (ad esempio nome e protocollo)
Ogni voce di audit log in Logging è un oggetto di tipo LogEntry che contiene i seguenti campi:
- Un payload, che è di tipo
protoPayload. Il payload di ogni voce dell'audit log è un oggetto di tipoAuditLog. Puoi trovare l'identità utente nel campoAuthenticationInfodiAuditLogoggetti. - L'evento specifico, che puoi trovare nel campo
methodNamediAuditLog. - Un timestamp.
- Lo stato dell'evento, che puoi trovare negli oggetti
responsenell'oggettoAuditLog. - La richiesta dell'operazione, che puoi trovare negli oggetti
requesterequestMetadatanell'oggettoAuditLog. - Il servizio che verrà eseguito, che puoi trovare nell'oggetto
AuditDatainserviceData.
Requisito 11
Verificare regolarmente la sicurezza dei sistemi e delle reti.
Requisito 11.3
Le vulnerabilità esterne e interne vengono regolarmente identificate, prioritizzate e gestite.
Requisito 11.3.1
- Almeno una volta ogni tre mesi.
- Le vulnerabilità critiche e ad alto rischio (in base ai ranking di rischio di vulnerabilità dell'entità definiti nel requisito 6.3.1) vengono risolte.
- Vengono eseguite nuove scansioni per confermare che tutte le vulnerabilità critiche e ad alto rischio (come indicato in precedenza) sono state risolte.
- Lo strumento di analisi è sempre aggiornato con le informazioni sulle vulnerabilità più recenti.
- Le scansioni vengono eseguite da personale qualificato ed esiste un'indipendenza dell'organizzazione dal tester.
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, analizza le tue immagini in Container Registry ed estrae gestore di pacchetti, base delle immagini e occorrenze di vulnerabilità per le immagini.
Scansione incrementale. Artifact Analysis analizza le nuove immagini quando vengono caricate su Container Registry.
Analisi continua: man mano che Artifact Analysis riceve informazioni sulle vulnerabilità nuove e aggiornate da origini di vulnerabilità, esegue nuovamente l'analisi dei container per mantenere aggiornato l'elenco delle occorrenze di vulnerabilità per le immagini già scansionate.
Requisito 11.5
Vengono rilevate intrusioni nella rete e le modifiche impreviste ai file.
Requisito 11.5.1
- Tutto il traffico è monitorato sul perimetro del CDDE.
- Tutto il traffico viene monitorato nei punti critici del CDDE.
- Il personale viene avvisato di sospetti compromissioni.
- Tutti i motori di rilevamento e prevenzione delle intrusioni, le basi e le firme sono sempre aggiornati.
Il Mirroring pacchetto di Google Cloud può essere utilizzato con Cloud IDS per rilevare le intrusioni di rete. Il Mirroring pacchetto di Google Cloud inoltra tutto il traffico di rete dalle VM di Compute Engine o dai cluster Google Cloud a un indirizzo designato. Cloud IDS può consumare questo traffico con mirroring per rilevare un'ampia gamma di minacce, tra cui tentativi di exploit, scansioni delle porte, overflow del buffer, frammentazione del protocollo, traffico di comando e controllo (C2) e malware.
Security Command Center ti offre una visibilità centralizzata sullo stato della sicurezza dei servizi Google Cloud (incluso GKE) e degli asset in tutta l'organizzazione, semplificando la prevenzione, il rilevamento e la risposta alle minacce. Utilizzando Security Command Center, puoi vedere quando vengono rilevate minacce ad alto rischio come malware, cryptomining, accessi non autorizzati alle risorse Google Cloud, attacchi DDoS in uscita, scansione delle porte e attacchi di forza bruta SSH in base ai log di Cloud Logging.
Mantieni un criterio di sicurezza delle informazioni
Un criterio di sicurezza efficace definisce il tono della sicurezza e informa le persone cosa ci si aspetta da loro. In questo caso, il termine "persone" si riferisce a dipendenti a tempo pieno e part-time, dipendenti temporanei, appaltatori e consulenti che hanno accesso al tuo CDE.
Requisito 12
Sostenere la sicurezza delle informazioni con criteri e programmi dell'organizzazione.
Per informazioni sul requisito 12, consulta la matrice di responsabilità condivisa PCI di Google Cloud.
esegui la pulizia
Se hai utilizzato risorse mentre seguivi questo articolo, ad esempio se hai avviato nuove VM o utilizzato gli script Terraform, puoi evitare che al tuo account Google Cloud vengano addebitati costi eliminando il progetto in cui hai utilizzato quelle risorse.
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Passaggi successivi
- Scopri di più sulla conformità allo standard di sicurezza dei dati PCI.
- Prova lo Starter Kit Terraform.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.