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. Le informazioni o i suggerimenti in questa guida non devono essere considerati da Google come consulenza legale o di audit. Ogni cliente è responsabile di valutare in modo indipendente il proprio utilizzo specifico dei servizi in modo da adempiere ai propri obblighi legali e di conformità.
Introduzione alla conformità PCI DSS e a GKE
Se gestisci i dati di carte di pagamento, devi proteggerli, sia che si trovino in un database on-premise o nel cloud. PCI DSS è stato sviluppato per incoraggiare e migliorare la sicurezza dei dati dei titolari delle carte e facilitare l'ampia adozione di misure di sicurezza dei dati coerenti a livello globale. Lo standard PCI DSS fornisce una serie di requisiti tecnici e operativi di base 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. PCI DSS si applica anche a tutte le altre entità che archiviano, elaborano o trasmettono i dati dei titolari di carte di credito (CHD) e i dati di autenticazione sensibili (SAD) o entrambi.
Le applicazioni containerizzate sono diventate popolari di recente grazie alla migrazione di molti carichi di lavoro legacy da un'architettura basata su macchina virtuale (VM) a una containerizzata. Google Kubernetes Engine è un ambiente gestito e pronto per la produzione per il deployment di applicazioni containerizzate. Offre le ultime innovazioni di Google in termini di produttività degli 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 (sia la modalità operativa Autopilot che quella Standard), è conforme ai requisiti PCI DSS. Descriviamo le nostre responsabilità nella nostra Matrice di responsabilità condivisa.
Pubblico di destinazione
- Clienti che vogliono portare carichi di lavoro conformi allo standard PCI su Google Cloud che coinvolgono GKE.
- Sviluppatori, responsabili della sicurezza, funzionari della conformità, amministratori IT e altri dipendenti responsabili dell'implementazione dei controlli e della conformità ai requisiti PCI DSS.
Prima di iniziare
Per i consigli che seguono, potenzialmente devi utilizzare quanto segue:
- Risorse per l'organizzazione, le cartelle e i 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 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 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 il glossario PCI DSS.
- CHD
dati del titolare della carta. Deve contenere almeno il numero PAN (principale) di conto bancario. I dati del titolare della carta possono anche essere visualizzati sotto forma di PAN completo più uno qualsiasi 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 dei titolari di carte di credito. Persone, processi e tecnologie che memorizzano, elaborano o trasmettono dati di titolari di carte o dati di autenticazione sensibili.
- PAN
numero dell'account principale. Un dato fondamentale del titolare della carta che hai l'obbligo di proteggere ai sensi dello standard PCI DSS. Il PAN è in genere un numero di 16 cifre univoco per una carta di pagamento (credito e debito) e che identifica l'emittente e il conto del titolare della carta.
- PIN
Personal Identification Number. Una password numerica nota solo all'utente e al sistema, utilizzata per autenticare l'utente nel sistema.
- QSA
qualificatore della sicurezza. certificato dal PCI Security Standard Council per eseguire controlli e analisi di conformità.
- TRISTE
dati di autenticazione sensibili. In conformità PCI, i dati vengono usati dagli emittente delle carte per autorizzare le transazioni. Analogamente ai dati dei titolari, lo PCI DSS richiede la protezione del SAD. Inoltre, il SAD non può essere trattenuto dai commercianti e dai loro elaboratori dei pagamenti. Il SAD include:
- Dati "traccia" da strisce magnetiche
- "Monitora dati equivalenti" generati da carte con chip e contactless
- Codici di convalida di sicurezza (ad es. il numero di 3-4 cifre stampato sulle carte) utilizzati per le transazioni online e senza carta.
- 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, consigliamo vivamente di utilizzare questo metodo per 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 in meno località 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 archiviano, elaborano o trasmettono dati dei titolari di carte o dati di autenticazione sensibili. Nel contesto di GKE, il CDE comprende anche quanto segue:
- Sistemi che forniscono servizi di sicurezza (ad esempio IAM).
- Sistemi che facilitano la segmentazione (ad esempio progetti, cartelle, firewall, VPC) e subnet.
- Pod e cluster di applicazioni che archiviano, elaborano o trasmettono i dati dei titolari di carte. Senza un'adeguata segmentazione, l'intera impronta cloud può rientrare nell'ambito di PCI DSS.
Per essere considerato fuori ambito per PCI DSS, un componente del sistema deve essere adeguatamente isolato dal CDE in modo che, anche se il componente del sistema fuori ambito venisse compromesso, non potrebbe influire sulla sicurezza del CDE.
Un prerequisito importante per ridurre l'ambito della CDE è una chiara comprensione delle esigenze e dei processi aziendali relativi all'archiviazione, all'elaborazione e alla trasmissione dei dati dei titolari di carte. La limitazione dei dati dei titolari delle carte al minor numero di sedi possibile eliminando i dati non necessari e il consolidamento di quelli necessari potrebbe richiedere la riprogettazione di pratiche commerciali consolidate.
Puoi segmentare correttamente il tuo CDE in vari 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 mediante 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 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 attraverso le autorizzazioni IAM a livello di cartella. Vengono utilizzate anche per raggruppare progetti simili. Un progetto è un confine di attendibilità per tutte le risorse e un punto di applicazione IAM.
Potresti raggruppare tutti i progetti nell'ambito PCI in una cartella per isolare a livello di cartella. Potresti anche utilizzare un progetto per tutti i cluster e le applicazioni PCI nell'ambito oppure 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 un Virtual Private Cloud (VPC) e le subnet per eseguire il provisioning della rete e raggruppare e isolare le risorse relative a CDE. Un VPC è un isolamento logico di una sezione di un cloud pubblico. Le reti VPC forniscono un networking scalabile e flessibile per le istanze di macchine virtuali (VM) Compute Engine e per i servizi che sfruttano le istanze VM, tra cui GKE. Per maggiori dettagli, consulta la panoramica di VPC e fai riferimento alle best practice e alle architetture di riferimento.
Segmentazione a livello di servizio mediante Controlli di servizio VPC e Google Cloud Armor
Mentre il VPC e le subnet forniscono segmentazione e creano un perimetro per isolare il CDE, Controlli di servizio VPC aggrava il perimetro di sicurezza al livello 7. Puoi usare Controlli di servizio VPC per creare un perimetro attorno ai progetti CDE in ambito. I Controlli di servizio VPC offrono i seguenti controlli:
- Controllo in entrata. Nel perimetro di sicurezza sono consentiti solo client e identità autorizzati.
- Controllo in uscita: Per le identità e i client all'interno del tuo 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 il più vicini possibile all'utente e al traffico dannoso, puoi evitare che il traffico dannoso consumi risorse o entri nelle reti VPC.
Utilizza Controlli di servizio VPC per definire un perimetro di servizio attorno ai progetti nell'ambito. 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 gestisci sistemi e reti sicuri
La creazione e la gestione di una rete sicura include i requisiti 1 e 2 di PCI DSS.
Requisito 1
Installa e gestisci una configurazione firewall per proteggere i dati e il traffico dei titolari di carte in entrata e in uscita dalla piattaforma CDE.
I concetti di networking per container e GKE sono diversi da quelli per le VM tradizionali. I pod possono raggiungersi l'un l'altro direttamente, senza NAT, anche tra i nodi. Questo crea una topologia di rete semplice che potrebbe sorprendere se si è abituati a gestire sistemi più complessi. Il primo passo per la sicurezza di rete per GKE è acquisire familiarità con questi concetti di networking.
Prima di esaminare i singoli requisiti del Requisito 1, ti consigliamo di rivedere i seguenti concetti di networking in relazione a GKE:
Regole firewall. Le regole firewall vengono utilizzate per limitare il traffico ai nodi. Il provisioning dei nodi GKE viene eseguito come istanze di Compute Engine e utilizza gli stessi meccanismi firewall delle altre istanze. All'interno della rete, puoi usare i tag per applicare queste regole firewall a ogni istanza. Ogni pool di nodi riceve il proprio set di tag che puoi utilizzare nelle regole. Per impostazione predefinita, ogni istanza appartenente a un pool di nodi riceve un tag che identifica uno specifico cluster GKE di cui fa parte questo pool di nodi. Questo tag viene utilizzato nelle regole firewall che GKE crea automaticamente per te. Puoi aggiungere tag personalizzati durante la creazione del cluster o del pool di nodi utilizzando il 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 cambio di rotazione della rete e il movimento laterale all'interno del cluster in caso di problemi di sicurezza con un pod. Per usare 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 prevede che tutte le comunicazioni tra pod siano sempre aperte. Pertanto, per segmentare la rete, devi applicare criteri di networking 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 stabiliscono 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. 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 ne vedano il contenuto in un altro. Tuttavia, gli spazi dei nomi all'interno dello stesso cluster non limitano la comunicazione tra loro; è qui che entrano in gioco i criteri di rete. Per ulteriori informazioni sulla configurazione degli spazi dei nomi, vedi il post del blog sulle best practice per gli spazi dei nomi.
Il seguente diagramma illustra i concetti precedenti in relazione tra loro e agli altri componenti GKE, come cluster, nodo e pod.
Requisito 1.1
I processi e i meccanismi per l'installazione e il mantenimento dei controlli di sicurezza della rete sono definiti e compresi.
Requisito 1.1.2
descrivere gruppi, ruoli e responsabilità nella gestione dei componenti di rete.
Innanzitutto, come faresti con la maggior parte dei servizi su Google Cloud, devi configurare i ruoli IAM per configurare l'autorizzazione su GKE. Una volta configurati i ruoli IAM, devi aggiungere la configurazione del controllo degli accessi basato su ruoli di Kubernetes (RBAC) nell'ambito di una strategia di autorizzazione Kubernetes.
In pratica, 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 alle risorse in ogni cluster Kubernetes e consente un'autorizzazione granulare a livello dello spazio dei nomi. Con GKE, questi approcci all'autorizzazione funzionano in parallelo, e le capacità di un utente rappresentano effettivamente l'unione dei 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 tra pod e per impedire modifiche non autorizzate o accidentali da parte di utenti non CDE.
- Giustifica tutti gli utenti e le autorizzazioni IAM e RBAC. In genere, quando testano i controlli delle domande frequenti, cercano una giustificazione aziendale per un campione di IAM e RBAC.
Requisito 1.2
I controlli di sicurezza di rete (NSC) sono configurati e gestiti.
Innanzitutto, configura le regole firewall sulle istanze Compute Engine che eseguono i tuoi nodi GKE. Le regole firewall proteggono questi nodi del cluster.
Successivamente, configurerai i 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. e sono logicamente isolati tra loro. Forniscono l'ambito per pod, servizi e deployment nel cluster, in modo che gli utenti che interagiscono con uno spazio dei nomi non vedano i contenuti in un altro spazio dei nomi. Tuttavia, gli spazi dei nomi all'interno dello stesso cluster non limitano la comunicazione tra gli spazi dei nomi; è qui che entrano in gioco 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, vedi 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 verso e dai 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 consente 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à con il processo di controllo delle modifiche definito nel requisito 6.5.1.
Per gestire le configurazioni di networking e l'infrastruttura come codice, devi stabilire una pipeline di integrazione e distribuzione continua (CI/CD) come parte dei processi di gestione dei cambiamenti e controllo dei cambiamenti.
Puoi utilizzare i modelli Cloud Deployment Manager o Terraform come parte 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. Dopodiché puoi scrivere test delle unità e altri test per assicurarti che le modifiche alla rete funzionino come previsto. Un processo di controllo delle modifiche che include un'approvazione può essere gestito tramite file di configurazione archiviati in un repository di versioni.
Con lo strumento di convalida di Terraform Config puoi definire i vincoli per applicare i criteri di sicurezza e governance. Aggiungendo lo strumento di convalida della configurazione alla pipeline CI/CD, puoi aggiungere un passaggio a qualsiasi flusso di lavoro. Questo passaggio convalida un piano Terraform e lo rifiuta se vengono rilevate violazioni.
Requisito 1.2.5
Tutti i servizi, i protocolli e le porte consentiti sono identificati, approvati e hanno esigenze aziendali definite.
Per controlli 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 Transport Layer Security (TLS) 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 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 liste di indirizzi IP bloccati, liste consentite e criteri di sicurezza per le applicazioni ospitate su GKE. In un cluster GKE, il traffico in entrata viene gestito dal bilanciamento del carico HTTP(S), che è un componente di Cloud Load Balancing. In genere, il bilanciatore del carico HTTP(S) viene configurato dal controller in entrata GKE, che riceve le informazioni di configurazione da un oggetto Ingress Kubernetes. Per ulteriori informazioni, consulta Come configurare i criteri di Google Cloud Armor con GKE.
Requisito 1.3
L'accesso di rete da e verso l'ambiente 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 i controlli di servizio VPC e l'accesso privato Google.
Requisito 1.3.1
Il traffico in ingresso verso CDE è limitato come segue:
- Solo per il 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 nella tua CDE. In un cluster privato, i nodi hanno solo indirizzi IP interni RFC 1918, il che garantisce che i relativi 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 che gli indirizzi IP di origine falsificati entrino 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 degli indirizzi IP interni e delle informazioni di routing è limitata solo alle parti autorizzate.
Puoi utilizzare un agente di mascheramento IP di GKE per eseguire la Network Address Translation (NAT) per tradurre indirizzi IP many-to-one in 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. Il rafforzamento del cluster è una 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 protezione del sistema accettati dal settore. Le origini degli standard di protezione dei sistemi accettati 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 in GKE, ti consigliamo di seguire questi suggerimenti:
- Inizia con un'immagine di base gestita del container che viene creata, gestita e sottoposta a vulnerabilità verificata da un'origine attendibile. Prendi in considerazione la possibilità di creare un insieme di immagini di base note o dorate che gli sviluppatori possono utilizzare. Un'opzione più restrittiva è l'utilizzo di un'immagine senza distrografia o un'immagine di base di 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 programmi binari approvati e attendibili.
Al momento della configurazione
Durante la configurazione, è consigliabile:
- Utilizza il sistema operativo predefinito Container-Optimized OS come immagine 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 nel piano di controllo gestito, offrendo maggiore stabilità e sicurezza.
- Abilita i nodi con riparazione automatica. Quando questa funzionalità è abilitata, GKE controlla periodicamente e utilizza lo stato di integrità del nodo per determinare se un nodo deve essere riparato. Se un nodo deve essere riparato, viene svuotato e viene creato e aggiunto un nuovo nodo al cluster.
- Attiva Cloud Monitoring e Cloud Logging per 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 se si verifica un incidente di sicurezza.
- Applica account di servizio con privilegi minimi per i nodi GKE
- Esamina e applica (ove applicabile) la sezione GKE della guida Google Cloud CIS Benchmark. Gli audit log di Kubernetes sono già abilitati per impostazione predefinita e i log per entrambe le richieste a
kubectle all'API GKE vengono scritti in Cloud Audit Logs. - Configura il logging di controllo.
Proteggere i dati dell'account
La protezione dei dati dei titolari di carte comprende i requisiti 3 e 4 dello standard PCI DSS.
Requisito 3
Proteggere i dati dell'account memorizzati.
Il requisito 3 dello standard PCI DSS stabilisce che le tecniche di protezione come crittografia, troncamento, mascheramento e hashing sono componenti fondamentali della protezione dei dati dei titolari delle carte. Se un intruso aggira altri controlli di sicurezza e ottiene l'accesso ai dati criptati senza le chiavi di crittografia appropriate, i dati risultano illeggibili e inutilizzabili per quella persona.
Potresti anche considerare altri metodi per proteggere i dati archiviati come potenziali opportunità di mitigazione del rischio. Ad esempio, i metodi per ridurre al minimo i rischi includono il divieto di archiviare i dati dei titolari della carta, a meno che non sia assolutamente necessario, il troncamento dei dati dei titolari se non è necessario il PAN completo e il divieto di inviare PAN non protetti utilizzando tecnologie di messaggistica per gli utenti finali, come email e messaggistica immediata.
Ecco alcuni esempi di sistemi in cui la CHD potrebbe persistere nei flussi di elaborazione dei pagamenti quando sono in esecuzione su Google Cloud:
- Bucket Cloud Storage
- Istanze BigQuery
- Datastore
- Cloud SQL
Tieni presente che CHD potrebbe essere inavvertitamente memorizzato nei log delle comunicazioni dell'email o dell'assistenza clienti. È prudente utilizzare la protezione dei dati Sensitive Data Protection 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 vengono criptati at-rest per impostazione predefinita e criptati in transito per impostazione predefinita quando attraversano i confini fisici. Per attivare queste protezioni non è necessaria alcuna configurazione aggiuntiva.
Requisito 3.5
Il numero di conto bancario principale (PAN) è protetto ovunque sia memorizzato.
Un meccanismo per rendere illeggibili i dati PAN è la tokenizzazione. Per ulteriori informazioni, consulta la guida alla soluzione relativa alla 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 supporto nativo per la scansione e la classificazione dei dati PAN a 12-19 cifre in Cloud Storage, BigQuery e Datastore. Dispone inoltre di un'API Streaming Content per abilitare il supporto di ulteriori origini dati, carichi di lavoro personalizzati e applicazioni. Puoi utilizzare l'API DLP anche per tagliare (oscurare) o eseguire l'hashing dei dati.
Requisito 3.6
Le chiavi crittografiche utilizzate per proteggere i dati dell'account memorizzati sono protette.
Cloud Key Management Service (KMS) è un sistema di archiviazione gestito per le chiavi di crittografia. Può generare, usare, ruotare ed eliminare le chiavi di crittografia. Cloud KMS non memorizza direttamente i secret, come i dati dei titolari di carte, ma può essere utilizzato per criptare questi dati.
Nel contesto di Kubernetes, i secret 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 archiviati inattivi dei clienti. GKE gestisce questa crittografia predefinita per te senza che tu debba fare altro. La crittografia dei secret a livello di applicazione fornisce un livello di sicurezza aggiuntivo per i dati sensibili come i secret. Utilizzando questa funzionalità, puoi fornire una chiave che gestisci in Cloud KMS per criptare i dati a livello di applicazione. In questo modo protegge i malintenzionati che accedono a una copia dell'istanza di archiviazione della configurazione Kubernetes del tuo cluster.
Requisito 4
Proteggi i dati dei titolari delle carte con una crittografia avanzata durante la trasmissione su reti pubbliche aperte.
I dati nell'ambito devono essere criptati durante la trasmissione su reti a cui possono accedere facilmente utenti malintenzionati, ad esempio le reti pubbliche.
Istio è un mesh di servizi open source che si sovrappone in modo trasparente alle applicazioni esistenti distribuite. Istio gestisce in modo scalabile l'autenticazione, l'autorizzazione e la crittografia del traffico tra i microservizi. È 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 distribuiti e offre un modo uniforme per proteggere, connettere e monitorare i microservizi.
Requisito 4.1
I processi e i meccanismi per proteggere i dati dei titolari di carte con una forte crittografia 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 tra servizi e monitoraggio. Puoi utilizzarlo anche per fornire comunicazioni sicure tra servizi in un cluster, con autenticazione e autorizzazione efficaci basate sull'identità e sul protocollo TLS reciproco. Il TLS reciproco (mTLS) è un handshake TLS eseguito due volte, che stabilisce lo stesso livello di attendibilità in entrambe le direzioni (al contrario dell'attendibilità client-server unidirezionale).
Istio consente di eseguire il deployment di certificati TLS su 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 viene trasferita tramite i proxy Envoy lato client e lato server. Envoy utilizza gli ID SPIFFE per stabilire le 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 l'applicazione è esposta a internet, utilizza il bilanciamento del carico HTTP(S) di GKE con il routing in entrata impostato per l'utilizzo di HTTP(S). Il bilanciamento del carico HTTP(S), configurato da un oggetto Ingress, include le seguenti funzionalità:
- Configurazione flessibile per i servizi. Un oggetto Ingress definisce il modo in cui il traffico raggiunge i tuoi servizi e come il traffico viene instradato alla tua applicazione. Inoltre, una risorsa Ingress può fornire un singolo indirizzo IP per più servizi nel tuo cluster.
- Integrazione con i servizi di rete di Google Cloud. Un oggetto Ingress può configurare funzionalità di Google Cloud come 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'uso di più certificati TLS per la terminazione delle richieste.
Quando crei un oggetto Ingress, il controller in entrata GKE crea un bilanciatore del carico HTTP(S) Cloud e lo configura in base alle informazioni nel traffico in entrata e nei servizi associati.
Mantenere 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 del PCI DSS prevede che il software antivirus debba essere utilizzato su tutti i sistemi comunemente interessati da malware per proteggere i sistemi da minacce software dannose attuali e in evoluzione. 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 regolarmente e applica patch di sicurezza aggiornate ai container.
- Esegui regolarmente analisi delle vulnerabilità su applicazioni containerizzate e programmi binari/librerie.
- Analizzare le immagini come parte della pipeline di build.
- Abbonati a un servizio di intelligence sulle vulnerabilità per ricevere informazioni aggiornate sulle vulnerabilità pertinenti per l'ambiente e le librerie utilizzate nei container.
Google Cloud collabora con vari provider di soluzioni di sicurezza per i container per migliorare la security posture nei deployment Google Cloud dei clienti. Consigliamo di sfruttare soluzioni e tecnologie di sicurezza convalidate per aumentare la profondità della difesa nell'ambiente GKE. Per l'elenco più recente dei partner di sicurezza convalidati da Google Cloud, vedi Partner per la sicurezza.
Requisito 5.2.2
Le soluzioni antimalware implementate:
- Rileva tutti i tipi di malware noti.
- Rimuove, blocca o contiene tutti i tipi di malware noti.
Requisito 5.2.3
Tutti 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 di sistema non a rischio di malware.
- identificazione e valutazione delle minacce malware in evoluzione per i componenti del sistema.
- Conferma se tali componenti del sistema continuano a non richiedere protezione antimalware.
Le soluzioni disponibili per eseguire le scansioni di malware sono molte, ma lo standard PCI DSS riconosce che non tutti i sistemi hanno le stesse probabilità di essere vulnerabili. Capita spesso ai commercianti di dichiarare i propri server Linux, mainframe e macchine simili come non "comunque colpiti da software dannoso" ed esenti dalla versione 5.2.2. In questo caso, si applica la sezione 5.2.3, ed è necessario implementare un sistema per le 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 la scansione antivirus e il monitoraggio dell'integrità dei file (FIM) su qualsiasi host nell'ambito. 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 dispone di uno scanner che riporta 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 consiste nel bloccare il container in modo che solo determinate cartelle consentite abbiano accesso in scrittura. Per farlo, esegui i container come utente non root e utilizza le autorizzazioni del file system per impedire l'accesso in scrittura a tutte le directory tranne quelle di lavoro all'interno del file system del container. Non consentire l'escalation dei privilegi per evitare l'elusione delle regole del file system.
Requisito 6
Sviluppa e gestisci sistemi e software sicuri.
Il requisito 6 di PCI DSS prevede che l'utente stabilisca un ciclo di vita solido di sviluppo del software in cui la sicurezza sia integrata in ogni fase dello sviluppo del software.
Requisito 6.2
I software su misura e personalizzati vengono sviluppati in modo sicuro.
Requisito 6.2.1
Il software su misura e personalizzato viene sviluppato in modo sicuro, come segue:
- In base agli standard di settore e/o alle best practice per uno sviluppo sicuro.
- In conformità con PCI DSS (ad esempio, autenticazione e logging sicure).
- Incorporare la considerazione dei problemi di sicurezza delle informazioni in ogni fase del ciclo di vita dello sviluppo del software.
Puoi utilizzare Autorizzazione binaria per assicurarti che venga eseguito il deployment su GKE solo di 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 l'approvazione di un'immagine da parte di una o più parti affidabili (chiamate "attendi") prima di eseguirne il deployment. Per una pipeline di deployment in più fasi in cui le immagini avanzano dallo sviluppo al 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 il criterio verificando che l'immagine container abbia superato tutti i vincoli richiesti, tra cui che tutti gli attestatori richiesti abbiano verificato che l'immagine è pronta per il deployment. Se l'immagine viene accettata, il servizio ne consente il deployment. In caso contrario, il deployment viene bloccato e l'immagine non può essere sottoposta a deployment finché non diventa conforme.
Per saperne di più su Autorizzazione binaria, consulta Configurare GKE.
In caso di emergenza, puoi ignorare 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 di utenti malintenzionati.
Requisito 6.3
Le vulnerabilità di sicurezza vengono identificate e gestite.
Requisito 6.3.1
Le vulnerabilità di sicurezza vengono identificate e gestite come segue:
- Le nuove vulnerabilità di sicurezza vengono identificate utilizzando fonti riconosciute nel settore per le informazioni sulle vulnerabilità di sicurezza, compresi gli avvisi provenienti dai team di risposta alle emergenze informatiche internazionali e nazionali (CERT).
- Alle vulnerabilità viene assegnato un ranking del rischio basato sulle best practice del settore e sulla considerazione del potenziale impatto.
- Le classificazioni del rischio identificano, come minimo, tutte le vulnerabilità considerate ad alto rischio o critiche per l'ambiente.
- Sono trattate le vulnerabilità del software personalizzato 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 immediatamente disponibili eventuali patch per queste immagini. Se hai abilitato gli upgrade automatici, 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 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 nella tua 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 a Google Container Registry (GCR), l'analisi delle vulnerabilità scansiona automaticamente le immagini alla ricerca di vulnerabilità note ed esposizioni 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 analizzare 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 per la sicurezza nella pipeline di build delle applicazioni.
Implementa efficaci misure di controllo dell'accesso
L'implementazione di misure efficaci di controllo dell'accesso'accesso include i requisiti 7, 8 e 9 dello standard 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 li definisce come la concessione dell'accesso a una quantità minima di dati e la concessione del minor numero di privilegi necessari per eseguire un job.
Requisito 7.2
L'accesso ai dati e ai componenti del sistema è definito e assegnato in modo appropriato.
IAM e il controllo controllo dell'accesso basato su ruoli (RBAC) di Kubernetes collaborano per fornire controllo dell'accesso granulare al tuo ambiente GKE. IAM viene utilizzato per gestire l'accesso e le autorizzazioni degli utenti delle risorse Google Cloud nel progetto CDE. In GKE, puoi utilizzare IAM anche per gestire l'accesso e le azioni che gli utenti e gli account di servizio possono eseguire nei cluster, come la creazione e l'eliminazione dei cluster.
Kubernetes RBAC ti consente di configurare set granulari di autorizzazioni che definiscono il modo in cui un determinato utente Google Cloud, account di servizio Google Cloud o gruppo di utenti (Google Gruppi) possono interagire con qualsiasi oggetto Kubernetes nel tuo cluster o in uno spazio dei nomi specifico del tuo cluster. Esempi di autorizzazioni RBAC includono la modifica dei deployment o delle mappe di configurazione, l'eliminazione di pod o la visualizzazione dei log da un pod. Puoi concedere agli utenti o ai servizi autorizzazioni IAM limitate, ad esempio Visualizzatore cluster Google Kubernetes Engine o ruoli personalizzati, quindi applicare le associazioni di ruoli RBAC di Kubernetes a seconda dei casi.
Cloud Identity Aware Proxy (IAP) può essere integrato tramite Ingress per GKE al fine di controllare l'accesso a livello di applicazione per i dipendenti o le persone che richiedono l'accesso alle tue 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 job.
- Privilegi minimi necessari per svolgere le responsabilità lavorative.
Oltre a garantire che gli utenti e gli account di servizio aderiscano al principio del privilegio minimo, anche i container devono farlo. Una best practice per l'esecuzione di un container è quella di 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 istruzioni per eseguire 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 ogni persona che ha accesso ai sistemi PCI nell'ambito deve essere assegnato un ID univoco, per garantire che ogni individuo sia responsabile delle proprie azioni in modo univoco.
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 un ID univoco prima che sia consentito l'accesso ai componenti di sistema o ai dati dei titolari 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 autorizzazioni a un utente. Consigliamo agli utenti di ricollegarsi al tuo sistema di identità esistente, in modo che tu possa gestire gli account utente e i criteri in 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 dispositivo token o una smart card.
- Qualcosa che sei, ad esempio un elemento biometrico.
I certificati vengono associati all'identità dell'utente quando vengono autenticati in kubectl.
Tutti i cluster GKE sono configurati per accettare le identità degli account utente e di servizio di 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 l'autenticazione.
Requisito 9
Limita l'accesso fisico ai dati del titolare della carta.
Google è responsabile dei controlli di sicurezza fisica in tutti i data center Google sottostanti a Google Cloud.
Monitorare e testare regolarmente le reti
Il monitoraggio e il test regolari delle reti include i requisiti 10 e 11 di PCI DSS.
Requisito 10
Registra e monitora tutti gli accessi ai componenti del 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 è abilitato l'audit logging di Kubernetes per impostazione predefinita, 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, per raccogliere statistiche o per creare avvisi di monitoraggio per le chiamate API indesiderate.
I cluster GKE integrano una configurazione predefinita per l'audit logging 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 contengono voci scritte da GKE.
Per differenziare i carichi di lavoro CDE e non CDE, ti consigliamo di aggiungere ai tuoi pod GKE delle etichette che si fonderanno 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 successo o errore
- Origine dell'evento
- Identità o nome di dati, componenti di sistema, risorse o servizi 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, di tipo
protoPayload. Il payload di ogni voce di audit log è un oggetto di tipoAuditLog. Puoi trovare l'identità utente nel campoAuthenticationInfodegli oggettiAuditLog. - 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
Testare regolarmente la sicurezza di sistemi e reti.
Requisito 11.3
Le vulnerabilità esterne e interne vengono regolarmente identificate, assegnate per priorità e gestite.
Requisito 11.3.1
- Almeno una volta ogni tre mesi.
- Le vulnerabilità critiche e ad alto rischio (in base ai livelli 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 sopra) sono state risolte.
- Lo strumento di scansione si tiene aggiornato con le ultime informazioni sulle vulnerabilità.
- Le scansioni vengono eseguite da personale qualificato e con indipendenza organizzativa del 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, l'API esegue la scansione delle immagini in Container Registry ed estrae il gestore di pacchetti, le basi delle immagini e le occorrenze di vulnerabilità per le immagini.
Scansione incrementale. Artifact Analysis esegue la scansione delle nuove immagini quando vengono caricate in Container Registry.
Analisi continua: man mano che Artifact Analysis riceve informazioni nuove e aggiornate sulle vulnerabilità da origini di vulnerabilità, esegue nuovamente l'analisi dei container per mantenere aggiornato l'elenco delle occorrenze di vulnerabilità delle immagini già analizzate.
Requisito 11.5
Vengono rilevate intrusioni di rete e modifiche impreviste ai file e viene data risposta.
Requisito 11.5.1
- Tutto il traffico viene monitorato all'interno del perimetro del CDE.
- Tutto il traffico viene monitorato in punti critici della CDE.
- Il personale viene avvisato di presunte compromissioni.
- Tutti i motori di rilevamento e prevenzione delle intrusioni, le basi di riferimento e le firme vengono sempre aggiornati.
Il Mirroring dei pacchetti di Google Cloud può essere utilizzato con Cloud IDS per rilevare le intrusioni nella 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 sottoposto a mirroring per rilevare un'ampia gamma di minacce, tra cui tentativi di exploit, analisi 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 e degli asset Google Cloud (incluso GKE) nell'intera organizzazione, semplificando la prevenzione, il rilevamento e la risposta alle minacce. Utilizzando Security Command Center, puoi vedere quando sono state rilevate minacce ad alto rischio come malware, cryptomining, accesso non autorizzato alle risorse Google Cloud, attacchi DDoS in uscita, scansione delle porte e attacchi di forza bruta SSH in base ai tuoi log di Cloud Logging.
Mantieni una politica di sicurezza delle informazioni
Un criterio di sicurezza efficace definisce il tono della sicurezza e informa le persone di ciò che si aspetta da loro. In questo caso, con "persone" si intendono dipendenti a tempo pieno e part-time, dipendenti temporanei, contrattisti 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 la Matrice di responsabilità condivisa PCI di Google Cloud.
esegui la pulizia
Se hai utilizzato risorse durante l'esecuzione di questo articolo, ad esempio se hai avviato nuove VM o utilizzato gli script Terraform, puoi evitare di incorrere in addebiti sul tuo account Google Cloud eliminando il progetto in cui hai utilizzato queste 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.