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 Payment Card Industry Data Security Standard (PCI DSS).
Disclaimer: questa guida è solo a scopo informativo. Google non intende che le informazioni o i consigli in questa guida costituiscono una consulenza legale o di revisione contabile. Ogni cliente è responsabile valutare il proprio uso dei servizi in modo appropriato per supportare i propri obblighi legali e di conformità.
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. PCI DSS fornisce una base di dati tecnici e requisiti operativi per la protezione dei dati delle carte di credito. Lo standard PCI DSS si applica a tutte le persone giuridiche coinvolte nell'elaborazione delle carte di pagamento, inclusi commercianti, elaboratori, acquirenti, emittenti e fornitori di servizi. Lo standard PCI DSS si applica anche a tutte le altre persone giuridiche 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 tra molte applicazioni legacy per la migrazione di carichi di lavoro da un'architettura basata su macchina virtuale (VM) a un containerizzato. Google Kubernetes Engine è un ambiente gestito e pronto per la produzione per il deployment per applicazioni containerizzate. Offre le più recenti innovazioni disponibili sul mercato apportando significativi vantaggi 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 (sia in modalità operativa Autopilot che Standard), è conforme ai requisiti PCI DSS. Spieghiamo le nostre responsabilità Matrice di responsabilità condivisa.
Pubblico di destinazione
- Clienti che vogliono portare su Google Cloud carichi di lavoro conformi allo standard PCI che coinvolgono GKE.
- Sviluppatori, addetti alla sicurezza, responsabili della conformità, amministratori IT e altri dipendenti incaricati di implementare i controlli e garantire la conformità ai requisiti PCI DSS.
Prima di iniziare
Per i consigli che seguono, potresti dover utilizzare seguenti:
- Risorse di organizzazioni, cartelle e progetti Google Cloud
- Identity and Access Management (IAM)
- Google Kubernetes Engine
- VPC 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 con GKE.
Ambito
Questa guida identifica i seguenti requisiti di PCI DSS che sono univoci dei problemi per GKE e fornisce indicazioni per soddisfarli. È scritto su versione 4.0 dello standard. Questa guida non tratta tutti i requisiti di PCI DSS. Le informazioni fornite in questa guida possono aiutare le organizzazioni a perseguire la conformità PCI DSS, ma non si tratta di una consulenza esaustiva. Le organizzazioni possono ingaggiare un QSA (PCI Certified Security Assessor) per la convalida formale.
Terminologia
Questa sezione definisce i termini utilizzati in questa guida. Per ulteriori dettagli, consulta Glossario PCI DSS.
- CHD
Dati del titolare della carta. Deve contenere almeno il numero di conto bancario principale completo (PAN). I dati del titolare della carta potrebbero essere visualizzati anche sotto forma del PAN completo più uno dei seguenti elementi:
- Nome del titolare della carta
- Data di scadenza e/o codice del servizio
- Dati sensibili di autenticazione (SAD)
- CDE
ambiente dei dati del titolare della carta. Le persone, i processi e la tecnologia che archiviare, elaborare o trasmettere dati del titolare della carta o dati di autenticazione sensibili.
- PAN
Numero di conto principale. Un elemento chiave dei dati del titolare della carta che hai l'obbligo di proteggere ai sensi di PCI DSS. In genere, il PAN è un numero di 16 cifre univoco per una carta di pagamento (di credito e di debito) che identifica l'emittente e l'account del titolare della carta.
- PIN
numero di identificazione personale. Una password numerica nota solo a l'utente e un sistema; utilizzata per autenticare l'utente nel sistema.
- QSA
qualificatore della sicurezza. Una persona certificata dal PCI Security Standards Council per eseguire controlli e analisi di conformità.
- TRISTE
Dati di autenticazione sensibili. In conformità con PCI, i dati utilizzati dagli emittenti delle carte per autorizzare le transazioni. Simile ai dati del titolare della carta, PCI DSS richiede la protezione del SAD. Inoltre, i dati SAD non possono essere conservati dai commercianti e dai loro elaboratori dei pagamenti. La SAD include quanto segue:
- Dati "Traccia" dalle strisce magnetiche
- "Dati equivalenti dei dati traccianti" generati da carte con chip e contactless
- I codici di convalida della sicurezza (ad esempio, il numero di 3-4 cifre stampato sul carte) utilizzate per le transazioni online e senza carta di credito.
- PIN e blocchi di PIN
- segmentazione
Nel contesto dello standard 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 dal consolidamento dei dati dei titolari delle carte in meno posizioni più controllate)
Segmentare l'ambiente dei dati del titolare della carta
L'ambiente dei dati dei titolari delle carte (CDE) comprende persone, processi e Tecnologie che memorizzano, elaborano o trasmettono dati dei titolari delle carte o dati sensibili dati di autenticazione. Nel contesto di GKE, la CDE include anche quanto segue:
- 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 i dati dei titolari di carte. Senza una segmentazione adeguata, l'intera impronta cloud può rientrare nell'ambito di PCI DSS.
Per essere considerato fuori ambito per PCI DSS, un componente di sistema deve essere adeguatamente isolated dal CDE in modo che, anche se il componente di sistema fuori ambito fosse compromesso, non possa influire sulla sicurezza del CDE.
Un prerequisito importante per ridurre l'ambito del CDE è la chiara le esigenze e i processi aziendali legati all'archiviazione, l'elaborazione e la trasmissione dei dati dei titolari. Limitare i dati del titolare della carta a un numero minimo di località eliminando i dati non necessari e consolidando quelli necessari potrebbe richiedere la riprogettazione di pratiche aziendali consolidate.
Puoi segmentare correttamente il tuo CDE in diversi modi su Google Cloud. Questa sezione illustra i seguenti aspetti:
- Segmentazione logica mediante la gerarchia delle risorse
- Segmentazione della rete tramite VPC e subnet
- Segmentazione del livello di servizio tramite VPC
- Altre considerazioni per qualsiasi cluster in ambito
Segmentazione logica utilizzando la gerarchia delle risorse
Esistono diversi modi per isolare il CDE all'interno della struttura organizzativa utilizzando lo strumento gerarchia delle risorse. Le risorse Google Cloud sono organizzate in modo gerarchico. La risorsa Organizzazione è il nodo radice della gerarchia delle risorse Google Cloud. Le cartelle e i 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 utilizzate anche per raggruppare progetti simili. R è un confine di attendibilità per tutte le risorse e un punto di applicazione IAM.
Puoi raggruppare tutti i progetti nell'ambito PCI all'interno di una cartella per isolare a livello di cartella. Puoi anche utilizzare un progetto per tutti i cluster e le applicazioni PCI in ambito oppure creare un progetto e un cluster per ogni applicazione PCI in ambito e utilizzarli per organizzare le risorse Google Cloud. In ogni caso, ti consigliamo di conservare carichi di lavoro all'interno e all'esterno dell'ambito di diversi progetti.
Segmentazione di rete utilizzando reti e subnet VPC
Puoi utilizzare la modalità Virtual Private Cloud (VPC) e subnet per il provisioning della rete e per raggruppare per isolare le risorse correlate a CDE. La VPC è un isolamento logico di una sezione di un cloud pubblico. Le reti VPC offrono scalabilità networking flessibile per le istanze di macchine virtuali (VM) Compute Engine per i servizi che sfruttano le istanze VM, tra cui GKE. Per maggiori dettagli, consulta la panoramica delle VPC e le best practice e le architetture di riferimento.
Segmentazione a livello di servizio utilizzando i Controlli di servizio VPC e Google Cloud Armor
Sebbene la VPC e le sottoreti forniscano la segmentazione e creino un perimetro per isolare il CDE, i Controlli di servizio VPC aumentano il perimetro di sicurezza a livello 7. Puoi utilizzare i Controlli di servizio VPC per creare un perimetro attorno ai progetti CDE coperti. Controlli di servizio VPC ti offre i seguenti controlli:
- Controllo Ingress. Sono consentiti solo identità e client autorizzati nel tuo perimetro di sicurezza.
- Controllo in uscita. Per le identità e i client all'interno del perimetro di sicurezza sono consentite solo destinazioni autorizzate.
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 come il più vicino possibile all'utente e a traffico dannoso, contribuisci a prevenire traffico dannoso proveniente dal consumo di risorse o dall'ingresso nelle reti VPC.
Utilizza i Controlli di servizio VPC per definire un perimetro di servizio intorno all'ambito in modo programmatico a gestire i progetti. Questo perimetro regola i percorsi da VM a servizio e da servizio a servizio, nonché il traffico in entrata e in uscita del VPC.
Creare e gestire una rete e sistemi sicuri
La creazione e la gestione di una rete sicura comprende i requisiti 1 e 2 del PCI DSS.
Requisito 1
Installa e gestisci una configurazione del firewall per proteggere i dati e il traffico dei titolari della carta all'interno e all'esterno del CDE.
I concetti di networking per i container e GKE sono diversi da quelli per le VM tradizionali. I pod possono raggiungersi a vicenda direttamente, senza NAT, anche nodi. Viene creata una topologia di rete semplice che potrebbe sorprenderti se sei abituato a gestire sistemi più complessi. Il primo passo nella sicurezza di rete GKE è imparare a usare questi concetti di networking.
Prima di esaminare i singoli requisiti nel Requisito 1, ti consigliamo di di rivedere i seguenti concetti di networking in relazione a GKE:
Regole firewall. Le regole firewall vengono utilizzate per limitare il traffico verso i nodi. I nodi GKE vengono provisionati come istanze Compute Engine e utilizzano gli stessi meccanismi di firewall delle altre istanze. All'interno della tua rete, puoi utilizzare i tag per applicare queste regole firewall a ogni istanza. Ogni pool di nodi riceve un 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 un cluster GKE specifico di cui fa parte questo pool di nodi. Questo tag è utilizzato nel firewall che GKE crea automaticamente per te. Puoi aggiungere tag personalizzati in fase di creazione del cluster o del pool di nodi utilizzando Flag
--tagsin Google Cloud CLI.Criteri di rete. I criteri di rete ti consentono di limitare le connessioni di rete tra i pod, il che può contribuire a limitare il pivoting di rete e il movimento laterale all'interno del cluster in caso di un problema di sicurezza con un pod. Per utilizzare i criteri di rete, devi attivare esplicitamente la funzionalità durante la creazione del cluster GKE. Puoi attivarla su un cluster esistente, ma i nodi del cluster verranno riavviati. Il comportamento predefinito è che tutte le comunicazioni pod-to-pod è sempre aperto. Pertanto, se desideri segmentare la tua rete, devi e applicare criteri di networking a livello di pod. In GKE, puoi definire un criterio di rete utilizzando l'API Network Policy di Kubernetes o lo strumento
kubectl. Queste regole dei criteri di traffico a livello di pod determinare quali pod e servizi possono accedere l'uno all'altro all'interno in un cluster Kubernetes.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 cluster, in modo che gli utenti che interagiscono con un singolo spazio dei nomi non vedano 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. 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, nodi e pod.
Requisito 1.1
I processi e i meccanismi per l'installazione e la gestione dei controlli di sicurezza di rete sono definiti e compresi.
Requisito 1.1.2
Descrivere gruppi, ruoli e responsabilità per la gestione delle componenti di rete.
Innanzitutto, come per 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 (RBAC) di Kubernetes nell'ambito di una strategia di autorizzazione 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 RBAC di Kubernetes si applica di risorse in ogni cluster Kubernetes e consente un'autorizzazione granulare a livello dello spazio dei nomi. Con GKE, questi approcci all'autorizzazione di lavorare in parallelo, e le capacità di un utente rappresentano in modo efficace l'unione Ruoli IAM e RBAC assegnati:
- Utilizza IAM per controllare gruppi, ruoli e responsabilità per la gestione logica dei componenti di rete in GKE.
- Usa Kubernetes RBAC per concedere autorizzazioni granulari norme della rete all'interno dei cluster Kubernetes, per controllare il traffico tra pod e prevenire modifiche non autorizzate o accidentali da parte di utenti non CDE.
- Devi essere in grado di giustificare tutte le autorizzazioni e tutti gli utenti IAM e RBAC. In genere, quando le QSA verificano i controlli, cercano un'azienda per un esempio di IAM e RBAC.
Requisito 1.2
I controlli di sicurezza di rete (NSC) sono configurati e gestiti.
Innanzitutto, devi configurare regole firewall sulle istanze Compute Engine che eseguono i tuoi nodi GKE. Le regole firewall proteggono questi nodi del cluster.
Poi devi configurare norme della rete per limitare i flussi e proteggere i pod in un cluster. Un criterio di rete è una specifica delle modalità consentite per la comunicazione dei gruppi di pod tra loro e con altri endpoint di rete. Puoi usare la rete GKE dell'applicazione dei criteri per controllare la comunicazione tra i pod del cluster i servizi di machine learning. Per segmentare ulteriormente il cluster, crea più spazi dei nomi al suo interno. e sono logicamente isolati tra loro. Forniscono l'ambito per i pod, i servizi e i deployment nel cluster, pertanto 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 nello stesso cluster non limitano la comunicazione tra gli spazi dei nomi, questo è dove i criteri di rete. consentono la segmentazione delle risorse all'interno in un cluster Kubernetes. Per ulteriori informazioni sulla configurazione degli spazi dei nomi, consulta Best practice per gli spazi dei nomi post del blog.
Per impostazione predefinita, se in uno spazio dei nomi non esistono criteri, tutto il traffico in entrata e in uscita è consentito verso e dai pod nello 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 alcun traffico in entrata per questi pod.
Requisito 1.2.2
Tutte le modifiche alle connessioni di rete e alle configurazioni degli NSC vengono 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 e distribuzione continua (CI/CD) nell'ambito delle procedure di gestione e controllo delle modifiche.
Puoi utilizzare i modelli di Cloud Deployment Manager o Terraform all'interno della pipeline CI/CD per creare criteri di rete nei tuoi cluster. Con Deployment Manager o Terraform, puoi e Infrastructure as Code in grado di riprodurre copie coerenti nell'ambiente di produzione attuale o in altri ambienti. In seguito, potrai scrivere test di 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 delle versioni.
Con Terraform Config Validator, puoi definire vincoli per applicare criteri di sicurezza e governance. Se aggiunti Config Validator 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 disponibili.
Requisito 1.2.5
Tutti i servizi, i protocolli e le porte consentiti sono identificati, approvati e hanno una necessità aziendale definita.
Per controlli efficaci in entrata per i tuoi cluster GKE, puoi utilizzare reti autorizzate per limitare determinati intervalli IP che possono raggiungere dal piano di controllo. GKE utilizza sia Transport Layer Security (TLS) sia l'autenticazione per fornire accesso sicuro all'endpoint del master del cluster dall'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 Google Cloud Armor per creare elenchi di 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 Bilanciamento del carico HTTP(S), che è un componente Cloud Load Balancing. In genere, il bilanciatore del carico HTTP(S) viene configurato dal controller di ingress GKE, che recupera le informazioni di configurazione da un oggetto Kubernetes Ingress. Per ulteriori informazioni, vedi come configurare i criteri di Google Cloud Armor con GKE.
Requisito 1.3
L'accesso alla rete verso e dall'ambiente dei dati dei titolari delle carte è limitato.
Per mantenere privati i dati sensibili, puoi configurare comunicazioni private tra Cluster GKE all'interno delle tue reti VPC e ambienti ibridi on-premise i deployment utilizzando Controlli di servizio VPC e accesso privato Google.
Requisito 1.3.1
Il traffico in ingresso verso CDE è limitato come segue:
- Solo al traffico necessario.
- Tutto il resto del traffico viene specificamente negato.
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 conformi alla RFC 1918 e questo assicura 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
Le misure anti-spoofing vengono implementate rilevare e bloccare gli indirizzi IP di origine falsificati che entrano nella rete attendibile.
Implementi 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 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 di indirizzi IP molti-a-uno in 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 i valori predefiniti e le credenziali fornite dal fornitore. L'hardening del cluster è responsabilità del cliente.
Requisito 2.2
I componenti di sistema sono configurati e gestiti in modo sicuro.
Assicurati che questi standard risolvano tutte le vulnerabilità di sicurezza note e siano coerenti con gli standard di hardening del sistema accettati dal settore. Le fonti degli standard di hardening del sistema accettati dall'industria possono includere, a titolo esemplificativo:Requisito 2.2.4
Solo servizi, protocolli, daemon necessari e le funzioni sono abilitate e non è necessario viene rimossa o disattivata.
Requisito 2.2.5
- La motivazione commerciale è documentata.
- Le funzionalità di sicurezza aggiuntive sono documentate implementate che riducono il rischio di usare daemon, protocolli o servizi non sicuri.
Requisito 2.2.6
I parametri di sicurezza del sistema sono configurati per impedire l'uso improprio.
Pre-deployment
Prima di spostare i contenitori su GKE, ti consigliamo di procedere come segue:
- Inizia con un'immagine di base gestita per i container che viene creata, mantenuta e controllata per le vulnerabilità da una fonte attendibile. Valuta l'idea di creare un insieme di "beni noti" o "oro" le immagini di base utilizzabili dagli sviluppatori. Un'opzione più restrittiva è l'utilizzo di immagine senza distroless o un immagine di base dello scraping.
- Utilizza Artifact Analysis per analizzare le immagini container alla ricerca di vulnerabilità.
- Stabilisci un criterio DevOps/SecOps interno per includere nei container solo librerie e binari approvati e attendibili.
Durante la configurazione
Durante la configurazione, è consigliabile:
- Utilizza il valore predefinito Container-Optimized OS come immagine del nodo per GKE. Container-Optimized OS è basato su Chromium OS ed è ottimizzato per la sicurezza dei nodi.
- Attiva 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 nel control plane gestito, garantendo una maggiore stabilità e sicurezza.
- Attiva i nodi con riparazione automatica. Quando questa funzionalità è abilitata, GKE controlla periodicamente e utilizza lo stato di integrità del nodo per determinare se deve essere riparato. Se un nodo richiede la riparazione, viene prosciugato e viene creato un nuovo nodo che viene aggiunto al cluster.
- Attiva Cloud Monitoring e Cloud Logging per avere visibilità su tutti gli eventi, inclusi gli eventi di sicurezza e lo stato di salute dei nodi. Crea criteri di avviso di monitoraggio cloud per ricevere una notifica in caso di incidente di sicurezza.
- Richiedi account di servizio 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
vengono scritte entrambe le richieste a
kubectle all'API GKE 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 quali crittografia, troncamento, mascheramento e hashing sono componenti fondamentali di la protezione dei dati dei titolari. Se un malintenzionato 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 per proteggere i dati archiviati le potenziali opportunità di mitigazione del rischio. Ad esempio, i metodi per ridurre al minimo rischiano di non archiviare i dati dei titolari se non assolutamente necessario, il troncamento dati del titolare della carta se il PAN completo non è necessario e non invia PAN non protetti usando tecnologie di messaggistica per gli utenti finali, come email e messaggistica immediata.
Ecco alcuni esempi di sistemi in cui i dati sensibili potrebbero persistere come parte dei flussi di elaborazione dei pagamenti quando vengono eseguiti su Google Cloud:
- Bucket Cloud Storage
- Istanze BigQuery
- Datastore
- Cloud SQL
Tieni presente che il CHD potrebbe essere inavvertitamente memorizzato in email o nel servizio clienti log delle comunicazioni. È prudente usare Protezione dei dati sensibili per filtrare questi stream di dati in modo da limitare l'ambiente che rientra nell'ambito ai sistemi di elaborazione dei pagamenti.
Tieni presente che su Google Cloud i dati criptati at-rest per impostazione predefinita, e criptati in transito per impostazione predefinita quando attraversa i confini fisici. Non è necessaria alcuna configurazione aggiuntiva per attivare queste protezioni.
Requisito 3.5
Il numero di conto bancario principale (PAN) è protetto ovunque sia memorizzato.
Un meccanismo per rendere il PAN illeggibile è la tokenizzazione. Per scoprire di più su la tokenizzazione, consulta Limitazione dell'ambito di conformità per gli ambienti PCI in Google Cloud
Puoi utilizzare lo API DLP per scansionare, individuare e segnalare i dati del titolare della carta. Sensitive Data Protection offre il supporto per la scansione e la classificazione dei dati PAN di 12-19 cifre Cloud Storage, BigQuery e Datastore. Dispone inoltre di un'API Streaming Content per abilitare il supporto di dati aggiuntivi carichi di lavoro personalizzati, origini dati e applicazioni. Puoi anche 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 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 direttamente store secret come i dati del titolare della carta, possono essere usati per criptare tali dati.
I secret nel contesto di Kubernetes sono oggetti segreti che ti consentono di archiviare e gestire informazioni sensibili come password, token, e chiavi.
Per impostazione predefinita, Google Cloud cripta i contenuti archiviati inattivi dei clienti. GKE gestisce questa crittografia predefinita per conto tuo senza che tu debba fare altro. Crittografia dei secret a livello di applicazione fornisce 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. Questo meccanismo protegge da malintenzionati che accedere a una copia dell'istanza di archiviazione della configurazione Kubernetes del tuo in un cluster Kubernetes.
Requisito 4
Proteggi i dati del titolare della carta con crittografia avanzata durante la trasmissione su reti aperte e pubbliche.
I dati nell'ambito devono essere criptati durante la trasmissione su reti che facilmente accessibili da parte di utenti malintenzionati, 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 microservizi. È una piattaforma che include API che consentono l'integrazione in qualsiasi piattaforma di logging, telemetria o criterio di un sistema operativo completo. Il set di funzionalità di Istio consente di eseguire in modo efficiente un microservizio distribuito dell'architettura e offre un modo uniforme per proteggere, connettere e monitorare di microservizi.
Requisito 4.1
I processi e i meccanismi per proteggere i dati dei titolari delle carte con crittografia avanzata durante la trasmissione su reti pubbliche aperte sono definiti e documentati.
Puoi utilizzare Istio per creare una rete di servizi di cui è stato eseguito il deployment, con bilanciamento del carico, autenticazione di servizio in servizio e monitoraggio. Puoi anche utilizzarlo per fornire comunicazioni sicure tra servizi in un cluster, con un'autenticazione e un'autorizzazione basate su identità solide basate su TLS reciproco. Il protocollo TLS reciproco (mTLS) è un handshake TLS eseguito due volte, che stabilisce lo stesso livello di attendibilità in entrambe le direzioni (a differenza dell'attendibilità client-server unidirezionale).
Istio ti consente di eseguire il deployment di certificati TLS in ogni pod GKE all'interno di un'applicazione. I servizi in esecuzione sul pod possono utilizzare mTLS per a identificare le identità peer. La comunicazione tra servizi è in tunnel tramite lato client e lato server Envoy proxy. 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 documentazione di 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 di ingresso 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 il modo in cui il traffico raggiunge i tuoi servizi e il modo in cui il traffico viene instradato verso i tuoi un'applicazione. Inoltre, una risorsa Ingress può fornire un singolo indirizzo IP più servizi nel tuo cluster.
- Integrazione con i servizi di rete Google Cloud. Un oggetto Ingress può configurare funzionalità di Google Cloud come i certificati SSL gestiti da Google (beta), Google 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 il termine della richiesta.
Quando crei un oggetto Ingress, Controller in entrata GKE crea un Bilanciatore del carico HTTP(S) di Cloud e lo configura in base alle informazioni nel traffico in entrata e ai suoi Servizi.
Gestire un programma di gestione delle vulnerabilità
Il mantenimento di un programma di gestione delle vulnerabilità include i requisiti 5 e 6 dello standard PCI DSS.
Requisito 5
Proteggere tutti i sistemi e le reti da software dannosi.
Il requisito 5 dello standard PCI DSS prevede l'utilizzo di software antivirus su tutti i sistemi comunemente colpiti da malware per proteggere i sistemi da sistemi minacce software dannose in continua evoluzione, e i container non fanno eccezione.
Requisito 5.2
Il software dannoso (malware) viene impedito o rilevato e gestito.
Devi implementare programmi di gestione delle vulnerabilità per le immagini container.
Consigliamo di eseguire queste operazioni:
- Controlla e applica regolarmente patch di sicurezza aggiornate ai contenitori.
- Esegui regolarmente analisi delle vulnerabilità contro applicazioni containerizzate e binari/librerie.
- Esegui la scansione delle immagini nell'ambito della pipeline di compilazione.
- Iscriviti a un servizio di intelligence sulle vulnerabilità di ricevere informazioni aggiornate sulle vulnerabilità e sull'ambiente e le librerie utilizzate nei container.
Google Cloud collabora con vari provider di soluzioni per la sicurezza dei container per migliorare la security posture dei clienti deployment di Google Cloud. Me consiglia di sfruttare soluzioni e tecnologie di sicurezza convalidate per aumentare una maggiore profondità di difesa nel tuo ambiente GKE. Per le ultime notizie Elenco dei partner per la sicurezza convalidati da Google Cloud, vedi 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 noti di malware.
Requisito 5.2.3
I componenti del sistema che non sono a rischio malware vengono valutati periodicamente per includere seguenti:
- Un elenco documentato di tutti i componenti di sistema non a rischio di malware.
- Identificazione e valutazione delle minacce malware in evoluzione per questi componenti di sistema.
- Conferma se questi componenti di sistema continuano a non richiedere protezione antimalware.
Esistono molte soluzioni per eseguire scansioni di malware, ma PCI DSS riconosce che non tutti i sistemi hanno le stesse probabilità di essere vulnerabili. È comune per i commercianti di dichiarare i server Linux, i mainframe e computer non "comunque colpiti da software dannoso" e quindi esente dalla versione 5.2.2. In questo caso, si applica la sezione 5.2.3, ed è necessario 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 antimalware sono attivi, gestiti e monitorati.
I requisiti 5.2, 5.3 e 11.5 richiedono scansioni antivirus e monitoraggio dell'integrità dei file (FIM) su qualsiasi host ambito. Ti consigliamo di implementare una soluzione in cui tutti i nodi possano essere sottoposti a scansione da un agente attendibile all'interno del cluster o in cui ogni nodo abbia uno scanner che genera report fino a un singolo endpoint di gestione.
Per ulteriori informazioni, vedi la panoramica sulla sicurezza di GKE, e la panoramica sulla sicurezza di Container-Optimized OS.
Una soluzione comune ai requisiti antivirus e FIM è il blocco il tuo container in modo che solo determinate cartelle consentite abbiano accesso in scrittura. Da fare questo, eseguire i container come utente non root e usano le autorizzazioni del file system per impedire l'accesso in scrittura a tutti tranne quelli funzionanti all'interno del file system del container. Non consentire l'escalation dei privilegi per evitare la circonvenzione delle regole del file system.
Requisito 6
Sviluppa e gestisci sistemi e software sicuri.
Il requisito 6 dello standard PCI DSS prevede che il software ciclo di sviluppo in cui la sicurezza è integrata in ogni fase del software sviluppo del prodotto.
Requisito 6.2
I software su misura e personalizzati vengono sviluppati in modo sicuro.
Requisito 6.2.1
Sviluppo di software su misura e personalizzati in modo sicuro, come segue:
- In base agli standard e/o alle best practice del settore per lo sviluppo sicuro.
- In conformità con PCI DSS (ad esempio, autenticazione e registrazione sicure).
- Tenere conto dei problemi di sicurezza delle informazioni durante ogni fase del ciclo di vita di sviluppo del software.
Puoi utilizzare la modalità Autorizzazione binaria per garantire che venga eseguito il deployment su GKE solo di container attendibili. Se vuoi attivare solo le immagini autorizzate da uno o più attestatori specifici, puoi configurare Autorizzazione binaria per applicare norme con regole che richiedono attestazioni in base ai risultati dell'analisi delle vulnerabilità. Puoi anche scrivere criteri che richiedono l'approvazione di una o più terze parti attendibili (chiamate "attestatori") prima che un'immagine possa essere implementata. Per una pipeline di deployment multifase in cui le immagini progrediscono dallo sviluppo ai test, fino ai cluster di produzione, puoi utilizzare gli attestatori garantire che tutti i processi richiesti siano stati completati prima del passaggio del software alla fase successiva.
Al momento del deployment, Autorizzazione binaria applica i criteri verificando che l'immagine container abbia superato tutti i vincoli richiesti, inclusi che tutti gli attestatori richiesti abbiano verificato che l'immagine è pronta per e deployment continuo. Se l'immagine viene accettata, il servizio ne consente il deployment. In caso contrario, il deployment è bloccato e l'immagine non può essere sottoposta a deployment conforme.
Per ulteriori informazioni su Autorizzazione binaria, consulta Configura 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 negli audit log di Cloud.
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 agenti malintenzionati.
Requisito 6.3
Le vulnerabilità di sicurezza vengono identificate e risolte.
Requisito 6.3.1
Le vulnerabilità di sicurezza vengono gestiti nel seguente modo:
- Le nuove vulnerabilità di sicurezza vengono identificate utilizzando fonti riconosciute nel settore per le informazioni sulle vulnerabilità di sicurezza, inclusi gli avvisi dei CERT (Computer Emergency Response Team) internazionali e nazionali.
- Alle vulnerabilità viene assegnata una classificazione del rischio in base alle best practice del settore e al potenziale impatto.
- Le classificazioni dei rischi identificano, come minimo, tutte le vulnerabilità considerate ad alto rischio o critiche per l'ambiente.
- Vulnerabilità per applicazioni personalizzate software di terze parti (ad esempio, sistemi e database) vengono trattati.
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. Sono inclusi upgrade, patch, scalabilità e
riparazioni, il tutto supportato da un obiettivo del livello del servizio (SLO). Per il sistema operativo dei nodi, ad esempio Container-Optimized OS o Ubuntu, GKE rende disponibili tempestivamente eventuali patch per queste immagini. Se disponi dell'upgrade automatico
abilitato, il deployment di queste patch
viene eseguito automaticamente. Si tratta del livello di base del tuo container, non è lo stesso del sistema operativo in esecuzione nei container.
Per ulteriori informazioni sul modello di responsabilità condivisa di GKE, consulta Esplorazione della sicurezza dei container: il modello di responsabilità condivisa in GKE.
Google offre diversi servizi di sicurezza per aiutarti a integrare la sicurezza nel tuo pipeline CI/CD. Per identificare le vulnerabilità nelle immagini container, puoi utilizzare l'analisi delle vulnerabilità di Google Artifact Analysis. Quando un'immagine container viene inviata mediante push a Google Container Registry (GCR), l'analisi delle vulnerabilità esegue automaticamente la scansione delle 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 eseguire scansioni di App Engine, Compute Engine e le applicazioni web GKE per le vulnerabilità comuni cross-site scripting (XSS) e configurazioni errate in risorse vulnerabili. Le scansioni possono essere eseguite su richiesta e pianificate dalla console Google Cloud. Utilizzando le API Security Scanner, è possibile automatizzare la scansione come parte e la suite di test per la sicurezza nella pipeline di build delle applicazioni.
Implementare misure di controllo dell'accesso efficaci
L'implementazione di misure di controllo dell'accesso efficaci include i requisiti 7, 8 e 9 del PCI DSS.
Requisito 7
Limita l'accesso ai componenti di sistema e ai dati dei titolari delle carte in base alle esigenze aziendali.
Il requisito 7 è incentrato sul privilegio minimo o deve conoscere. PCI DSS definisce poiché consentono di concedere l'accesso alla quantità minore di dati e forniscono il minor numero di necessari per eseguire un job.
Requisito 7.2
L'accesso ai componenti e ai dati di sistema è definito e assegnato in modo appropriato.
IAM e Controllo controllo dell'accesso basato su ruoli (RBAC) di Kubernetes possono lavorare insieme per fornire un controllo dell'accesso granulare ai tuoi completamente gestito di Google Cloud. IAM è utilizzato per gestire l'accesso e le autorizzazioni degli utenti risorse Google Cloud nel tuo progetto CDE. In GKE puoi anche utilizzare IAM per gestire l'accesso e le azioni che gli utenti e gli account di servizio possono eseguire nei tuoi cluster, ad esempio la creazione ed eliminazione dei cluster.
Kubernetes RBAC ti consente di configurare autorizzazioni che definiscono in che modo un determinato utente Google Cloud, account di servizio o gruppi di utenti (Google Gruppi) possono interagire con qualsiasi oggetto Kubernetes nel tuo cluster o in del tuo cluster. Alcuni esempi di autorizzazioni RBAC sono la modifica di deployment o configmap, l'eliminazione di pod o la visualizzazione di log da un pod. Concedi agli utenti o ai servizi autorizzazioni IAM limitate, ad esempio Visualizzatore cluster Google Kubernetes Engine o ruoli personalizzati, quindi applica le assegnazioni dei ruoli RBAC di Kubernetes come appropriato.
Cloud Identity Aware Proxy (IAP) possono essere integrati tramite Ingress per GKE al controllo accesso a livello di applicazione per i dipendenti o le persone che richiedono l'accesso al tuo PCI diverse applicazioni.
Inoltre, puoi utilizzare i criteri dell'organizzazione per limitare le API e i servizi disponibili in un progetto.
Requisito 7.2.2
L'accesso viene assegnato agli utenti, tra cui con privilegi in base a:
- Classificazione e funzione del job.
- Privilegi minimi necessari per eseguire il job e le responsabilità aziendali.
Oltre ad assicurarti che gli utenti e gli account di servizio rispettino il principio del privilegio minimo, lo devono fare anche i contenitori. Una best practice per l'esecuzione di un contenitore è eseguire il processo con un utente non root. Puoi 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
Identifica gli utenti e autentica l'accesso ai componenti di sistema
Il requisito 8 specifica che a ogni persona che ha accesso ai sistemi PCI 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 sono gestiti rigorosamente durante l'intero ciclo di vita dell'account.
Requisito 8.2.1
A tutti gli utenti viene assegnato prima un ID univoco l'accesso ai componenti di sistema o ai dati dei titolari consentito.
Requisito 8.2.5
L'accesso degli utenti con il contratto risolto viene revocato immediatamente.
È possibile usare sia IAM sia Kubernetes RBAC per controllare l'accesso il tuo cluster GKE e in entrambi i casi puoi concedere le autorizzazioni un utente. Consigliamo agli utenti di ricollegarsi sistema di identità esistente, in modo da poter gestire gli account utente e i criteri da un'unica posizione.
Requisito 8.3
L'autenticazione avanzata per utenti e amministratori viene istituita 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 ti caratterizza, ad esempio un elemento biometrico.
I certificati sono associati all'identità di un utente quando
esegue l'autenticazione in kubectl.
Tutti i cluster GKE sono configurati per accettare l'utente Google Cloud
e le identità degli account di servizio, convalidando le credenziali e recuperando
all'indirizzo email associato all'identità dell'account dell'utente o dell'account di servizio. Di conseguenza,
le credenziali di questi account devono includere l'ambito OAuth userinfo.email
per poter eseguire l'autenticazione.
Requisito 9
Limita l'accesso fisico ai dati del titolare della carta.
Google sta responsabile dei controlli di sicurezza fisica su tutti i data center Google sottostanti. in Google Cloud.
Monitorare e testare regolarmente le reti
Il monitoraggio e il test regolari delle reti contempla i requisiti 10 e 11 delle PCI-DSS
Requisito 10
Registra e monitora tutto l'accesso ai componenti di sistema e ai dati dei titolari della carta.
Requisito 10.2
Gli audit log sono implementati per supportare il rilevamento di anomalie e attività sospette, nonché l’analisi forense degli eventi.
Nei cluster Kubernetes è attivo per impostazione predefinita il logging di controllo di Kubernetes, che mantiene un record cronologico delle chiamate effettuate al server dell'API Kubernetes. Le voci degli audit log di Kubernetes sono utili indaga su richieste API sospette, per raccogliere statistiche o per creando avvisi di monitoraggio per le 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 degli audit log di Kubernetes nel tuo progetto Google Cloud.
Oltre alle voci scritte da Kubernetes, gli audit log del progetto scritte da GKE.
Per differenziare i carichi di lavoro CDE e non CDE, ti consigliamo di aggiungere etichette ai tuoi pod GKE che si penetrano in metriche e log emesse dai carichi di lavoro.
Requisito 10.2.2
- Identificazione utente
- Tipo di evento
- Data e ora
- Indicazione di successo o errore
- Origine dell'evento
- Identità o nome dei dati e del sistema interessati componente, risorsa o servizio (ad esempio, nome e protocollo)
Ogni voce del 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 del log di controllo è 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
responsenella OggettoAuditLog. - La richiesta dell'operazione, che puoi trovare in
requesterequestMetadataoggetti nell'oggettoAuditLog. - Il servizio che verrà eseguito, che puoi trovare nell'oggetto
AuditDatainserviceData.
Requisito 11
Testare regolarmente la sicurezza di sistemi e reti.
Requisito 11.3
Le vulnerabilità esterne e interne vengono regolarmente identificate, assegnate una priorità e risolte.
Requisito 11.3.1
- Almeno una volta ogni tre mesi.
- Vulnerabilità critiche e ad alto rischio (in base i livelli di rischio di vulnerabilità dell'entità definiti Il requisito 6.3.1) sono stati risolti.
- Vengono eseguiti nuovi controlli per confermare che tutte le vulnerabilità critiche e ad alto rischio (come indicato sopra) sono state risolte.
- Lo strumento di scansione è aggiornato con le ultime informazioni sulle vulnerabilità.
- Le scansioni vengono eseguite da personale qualificato e il tester gode di indipendenza organizzativa.
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, scansiona le immagini in Container Registry ed estrae gestore di pacchetti, base di immagini ed le occorrenze di vulnerabilità delle 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 origini delle vulnerabilità, esegue di nuovo l'analisi dei container per mantenere aggiornato l'elenco delle occorrenze di vulnerabilità per le immagini già sottoposte a scansione.
Requisito 11.5
Le intrusioni nella rete e le modifiche impreviste ai file vengono rilevate e gestite.
Requisito 11.5.1
- Tutto il traffico viene monitorato al perimetro del centro dati.
- Tutto il traffico viene monitorato nei punti critici della CDE,
- Il personale viene avvisato qualora sospetti compromissioni.
- Tutti i motori di rilevamento e prevenzione delle intrusioni, basi di riferimento e le firme vengono mantenute aggiornate.
Mirroring pacchetto Google Cloud può essere utilizzato con Cloud IDS per rilevare le intrusioni nella rete. Il mirroring dei pacchetti di Google Cloud inoltra tutto il traffico di rete dalle VM Compute Engine o dai cluster Google Cloud a un indirizzo designato. Cloud IDS può consumare questo il traffico sottoposto a mirroring per rilevare un'ampia gamma di minacce, inclusi i tentativi di exploit, scansioni delle porte, overflow del buffer, frammentazione del protocollo, comando e controllo (C2) traffico e malware.
Security Command Center offre una visibilità centralizzata sullo stato della i servizi e gli asset Google Cloud (incluso GKE) in tutto nell'intera organizzazione, il che rende più facile prevenire, rilevare e in modo proattivo. 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 un criterio di sicurezza delle informazioni
Un criterio di sicurezza efficace stabilisce il tono della sicurezza e comunica alle persone cosa è previsto. In questo caso, "persone" si riferisce a dipendenti a tempo pieno e part-time, dipendenti temporanei, appaltatori e consulenti che hanno accesso al tuo CDE.
Requisito 12
Supporta la sicurezza delle informazioni con i criteri e i programmi dell'organizzazione.
Per informazioni sul requisito 12, consulta Matrice di responsabilità condivisa PCI di Google Cloud.
Pulizia
Se hai utilizzato risorse durante l'esecuzione di questo articolo, ad esempio se hai hanno avviato nuove VM o utilizzato gli script Terraform, puoi evitare i costi vengono addebitati al tuo account Google Cloud eliminando il progetto in cui hanno utilizzato tali risorse.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Passaggi successivi
- Scopri di più su Conformità allo standard di sicurezza dei dati PCI.
- Prova il starter kit Terraform.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.