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 viene fornita unicamente a scopo informativo. Le informazioni e i consigli forniti da Google in questa guida non devono essere interpretati come una consulenza legale o di revisione. Ogni cliente è tenuto a valutare autonomamente il modo in cui usa i servizi in modo da adempiere ai propri obblighi di conformità e legali.
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 linea di base di requisiti tecnici e operativi progettati per proteggere i 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 di recente molto diffuse, con molti workload legacy che eseguono la migrazione da un'architettura basata su macchine virtuali (VM) a una containerizzata. Google Kubernetes Engine è un ambiente gestito e pronto per la produzione dedicato al deployment di applicazioni containerizzate. Offre le più recenti innovazioni 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 le modalità di funzionamento Autopilot che Standard), rispetta i requisiti PCI DSS. Descriviamo le nostre responsabilità nella nostra matrice delle responsabilità condivise.
Pubblico di destinazione
- Clienti che vogliono portare carichi di lavoro conformi allo standard PCI su Google Cloud 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 quanto segue:
- Risorse di organizzazioni, cartelle e progetti Google Cloud
- Identity and Access Management (IAM)
- Google Kubernetes Engine
- VPC di Google Cloud
- Google Cloud Armor
- L'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 contenitori e GKE.
Ambito
Questa guida identifica i seguenti requisiti del PCI DSS che rappresentano problemi unici per GKE e fornisce indicazioni per soddisfarli. È scritto in base alla versione 4.0 dello standard. Questa guida non copre tutti i requisiti del PCI DSS. Le informazioni fornite in questa guida potrebbero aiutare le organizzazioni a perseguire la conformità al PCI DSS, ma non costituiscono un consiglio esaustivo. Le organizzazioni possono rivolgersi a un QSA (Qualified Security Assessor) PCI 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 essere costituito almeno dal numero di conto 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 servizio
- Dati di autenticazione sensibili (SAD)
- CDE
ambiente dei dati del titolare della carta. Le persone, i processi e la tecnologia che archiviano, elaborano o trasmettono i dati del titolare della carta o i dati di autenticazione sensibili.
- PAN
Numero di conto principale. Un elemento chiave dei dati del titolare della carta che hai obbligatoriamente bisogno 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 all'utente e a un sistema; utilizzata per autenticare l'utente nel sistema.
- QSA
valutatore della sicurezza qualificato. Una persona certificata dal PCI Security Standards Council per eseguire controlli e analisi di conformità.
- SAD
Dati di autenticazione sensibili. In conformità con PCI, i dati utilizzati dagli emittenti delle carte per autorizzare le transazioni. Analogamente ai dati del titolare della carta, PCI DSS richiede la protezione dei dati sensibili. 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
- Codici di verifica di sicurezza (ad esempio il numero di 3-4 cifre stampato sulle carte) utilizzati per le transazioni online e con carta non presente.
- PIN e blocchi di PIN
- segmentazione
Nel contesto del PCI DSS, la pratica di isolare il CDE dal resto della rete dell'entità. La segmentazione non è un requisito del 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)
Segmenta l'ambiente dei dati dei titolari delle carte
L'ambiente dei dati dei titolari di carte (CDE) comprende persone, processi e tecnologie che archiviano, elaborano o trasmettono dati dei titolari di carte o dati di autenticazione sensibili. Nel contesto di GKE, 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 dall'ambito del PCI DSS, un componente di sistema deve essere adeguatamente isolato dal CDE in modo che, anche se il componente di sistema fuori dall'ambito fosse compromesso, non possa influire sulla sicurezza del CDE.
Un prerequisito importante per ridurre l'ambito del CDE è una chiara comprensione delle esigenze e delle procedure aziendali relative allo stoccaggio, all'elaborazione e alla trasmissione dei dati del titolare della carta. 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 i tuoi dati CDE in diversi modi su Google Cloud. Questa sezione illustra i seguenti metodi:
- Segmentazione logica mediante la gerarchia delle risorse
- Segmentazione della rete mediante VPC e subnet
- Segmentazione a livello di servizio mediante VPC
- Altre considerazioni per qualsiasi cluster ambito
Segmentazione logica utilizzando la gerarchia delle risorse
Esistono diversi modi per isolare il CDE all'interno della struttura organizzativa utilizzando la gerarchia delle risorse di Google Cloud. Le risorse diGoogle 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 utilizzati anche per raggruppare progetti simili. Un progetto è un confine di attendibilità per tutte le tue risorse e un punto di applicazione di IAM.
Potresti raggruppare tutti i progetti che rientrano nell'ambito PCI all'interno di una cartella per isolarli 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 tue risorseGoogle Cloud . In ogni caso, ti consigliamo di mantenere i workload in ambito e fuori ambito in progetti diversi.
Segmentazione di rete utilizzando reti e subnet VPC
Puoi utilizzare un Virtual Private Cloud (VPC) e sottoreti per eseguire il provisioning della rete e raggruppare e isolare le risorse relative ai CDE. La 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) di Compute Engine e 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. Solo le identità e i client autorizzati sono consentiti nel 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 Google Cloud rete. Esaminando gli indirizzi IP il più possibile vicini all'utente e al traffico dannoso, contribuisci a impedire al traffico dannoso di consumare risorse o di entrare nelle tue reti VPC.
Utilizza i Controlli di servizio VPC per definire un perimetro di servizio attorno ai progetti in ambito. Questo perimetro regola i percorsi da VM a servizio e da servizio a servizio, nonché il traffico in entrata e in uscita 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 connettersi direttamente tra loro, senza NAT, anche tra i nodi. Viene creata una topologia di rete semplice che potrebbe sorprenderti se hai abituato 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 esaminare 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 viene utilizzato nelle regole del firewall che GKE crea automaticamente per te. Puoi aggiungere tag personalizzati al momento della creazione del cluster o del pool di nodi utilizzando il flag
--tags
in Google Cloud CLI.Norme della 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 tutta la comunicazione tra pod sia sempre aperta. Pertanto, se vuoi segmentare la tua rete, devi applicare i criteri di rete 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 determinano quali pod e servizi possono accedere uno all'altro all'interno del cluster.Spazi dei nomi. Gli spazi dei nomi consentono la segmentazione delle risorse all'interno del cluster Kubernetes. Kubernetes viene fornito con uno spazio dei nomi predefinito, ma puoi creare più spazi dei nomi all'interno del cluster. Gli spazi dei nomi sono isolati logicamente tra loro. Forniscono l'ambito per pod, servizi ed esecuzioni 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. 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 Google Cloud risorsa e a tutti i cluster all'interno di un progetto. La configurazione RBAC di Kubernetes si applica alle risorse di ogni cluster Kubernetes e consente l'autorizzazione granulare a livello di spazio dei nomi. Con GKE, questi approcci all'autorizzazione lavorano in parallelo, con le funzionalità di un utente che rappresentano in modo efficace un'unione dei ruoli IAM e RBAC assegnati:
- Utilizza IAM per controllare gruppi, ruoli e responsabilità per la gestione logica dei componenti di rete in GKE.
- Utilizza Kubernetes RBAC per concedere autorizzazioni granulari ai criteri di rete all'interno dei cluster Kubernetes, per controllare il traffico da pod a pod e per impedire modifiche non autorizzate o accidentali da parte di utenti non CDE.
- Devi essere in grado di giustificare tutte le autorizzazioni e gli utenti IAM e RBAC. In genere, quando i QSA eseguono test di controllo, 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 del firewall proteggono questi nodi del cluster.
Successivamente, configura i criteri di 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 utilizzare l'applicazione dei criteri di rete di GKE per controllare la comunicazione tra i pod e i servizi del cluster. Per segmentare ulteriormente il cluster, crea più spazi dei nomi al suo interno. Gli spazi dei nomi sono isolati logicamente tra loro. Forniscono l'ambito per 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 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 tuo cluster Kubernetes. Per ulteriori informazioni sulla configurazione degli spazi dei nomi, consulta il post del blog Best practice per gli spazi dei nomi.
Per impostazione predefinita, se 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 trattare la configurazione e l'infrastruttura come codice che può riprodurre copie coerenti dell'ambiente di produzione attuale o di 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 aggiungi Config Validator alla tua 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 una necessità aziendale definita.
Per controlli di ingresso rigorosi per i tuoi cluster GKE, puoi utilizzare le reti autorizzate per limitare determinati intervalli IP che possono raggiungere il piano di controllo del tuo cluster. 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 indirizzi IP consentiti e non consentiti e criteri di sicurezza per le applicazioni ospitate su GKE. In un cluster GKE, il traffico in entrata viene gestito dal bilanciamento del carico HTTP(S), un componente del bilanciamento del carico Cloud. 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 saperne di più, consulta 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 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 entrata verso il CDE è limitato nel seguente modo:
- Solo al traffico necessario.
- Tutto il resto del traffico viene rifiutato specificamente.
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 per rilevare e bloccare gli indirizzi IP di origine contraffatti che tentano di accedere alla 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 di VPC.
Requisito 1.4.5
La divulgazione di indirizzi IP interni e informazioni di routing è limitata 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 di 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
Vengono attivati solo i servizi, i protocolli, i demoni e le funzioni necessari e tutte le funzionalità non necessarie vengono rimosse o disattivate.
Requisito 2.2.5
- La motivazione commerciale è documentata.
- Sono documentate e implementate funzionalità di sicurezza aggiuntive che riducono il rischio di utilizzare servizi, protocolli o demoni 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 la possibilità di creare un insieme di immagini di base "known good" o "golden" che i tuoi sviluppatori possano utilizzare. Un'opzione più restrittiva è utilizzare un'immagine senza disturbi o un'immagine di base da zero.
- 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, ti consigliamo quanto segue:
- Utilizza il sistema operativo ottimizzato per i container predefinito come immagine del nodo per GKE. Container-Optimized OS è basato su Chromium OS ed è ottimizzato per la sicurezza dei nodi.
- Abilita l'upgrade automatico dei nodi per i cluster che eseguono le tue applicazioni. Questa funzionalità consente di eseguire automaticamente l'upgrade del nodo alla versione di Kubernetes in esecuzione nel piano di controllo gestito, garantendo una maggiore stabilità e sicurezza.
- Attiva i nodi con riparazione automatica. Quando questa funzionalità è abilitata, GKE controlla e utilizza periodicamente lo stato di integrità del nodo per determinare se un nodo 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.
- Applica account di servizio con privilegi minimi per i nodi GKE
- Esamina e applica (se applicabile) la sezione GKE nella guida del Google Cloud CIS Benchmark. L'audit logging di Kubernetes è già abilitato per impostazione predefinita e i log per entrambe le richieste a
kubectl
e all'API GKE vengono scritti in Cloud Audit Logs. - Configura l'audit logging.
Proteggere i dati dell'account
La protezione dei dati dei titolari di carte comprende i requisiti 3 e 4 di PCI DSS.
Requisito 3
Proteggere i dati dell'account memorizzati.
Il requisito 3 del PCI DSS stabilisce che tecniche di protezione come la crittografia, il troncamento, il mascheramento e l'hashing sono componenti fondamentali della protezione dei dati dei titolari delle carte. 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 come potenziali opportunità di mitigazione dei rischi. Ad esempio, i metodi per ridurre al minimo il rischio includono la mancata memorizzazione dei dati del titolare della carta, a meno che non sia assolutamente necessario, il troncamento dei dati del titolare della carta se non è necessario il PAN completo e la mancata invio di PAN non protetti utilizzando tecnologie di messaggistica per gli utenti finali, come email e messaggistica istantanea.
Ecco alcuni esempi di sistemi in cui i problemi relativi ai dati mancanti potrebbero persistere nell'ambito dei flussi di elaborazione dei pagamenti quando vengono eseguiti su Google Cloud :
- Bucket Cloud Storage
- Istanze BigQuery
- Datastore
- Cloud SQL
Tieni presente che i dati sanitari sensibili potrebbero essere archiviati inavvertitamente nei log delle comunicazioni email o con l'assistenza clienti. È consigliabile utilizzare Sensitive Data Protection per filtrare questi stream di dati in modo da limitare l'ambiente in ambito ai sistemi di elaborazione dei pagamenti.
Tieni presente che su Google Cloudi dati sono criptati quando sono inattivi per impostazione predefinita e criptati in transito per impostazione predefinita quando attraversano confini fisici. Non è necessaria alcuna configurazione aggiuntiva per attivare queste protezioni.
Requisito 3.5
Il codice PAN (numero di conto bancario permanente) è protetto ovunque sia archiviato.
Un meccanismo per rendere il PAN illeggibile è la tokenizzazione. Per scoprire di più sulla tokenizzazione, consulta Limitazione dell'ambito di conformità per gli ambienti PCI in Google Cloud.
Puoi utilizzare l'API DLP per eseguire la scansione, rilevare e segnalare i dati del titolare della carta. Sensitive Data Protection offre supporto nativo per la scansione e la classificazione dei dati PAN di 12-19 cifre in Cloud Storage, BigQuery e Datastore. Dispone inoltre di un'API di streaming di contenuti che garantisce il supporto per ulteriori origini di dati, carichi di lavoro personalizzati 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. Anche se Cloud KMS non memorizza direttamente i secret come i dati del titolare della carta, può essere utilizzato per criptarli.
I secret nel contesto di Kubernetes sono oggetti secret Kubernetes che ti consentono di archiviare e gestire informazioni sensibili, come password, token e chiavi.
Per impostazione predefinita, Google Cloud cripta i contenuti inattivi dei clienti archiviati. GKE gestisce questa crittografia predefinita per conto tuo senza che tu debba fare altro. La crittografia dei secret a livello di applicazione offre un ulteriore livello di sicurezza per i dati sensibili come i secret. Utilizzando questa funzionalità, puoi fornire una chiave che gestisci in Cloud KMS, per criptare i dati a livello di applicazione. In questo modo, gli utenti malintenzionati che accedono a una copia dell'istanza di archiviazione della configurazione di Kubernetes del tuo cluster non possono accedere ai dati.
Requisito 4
Proteggi i dati del titolare della carta con crittografia avanzata durante la trasmissione su reti aperte e pubbliche.
I dati inclusi nell'ambito devono essere criptati durante la trasmissione su reti a cui è facile accedere da parte di persone malintenzionate, ad esempio reti pubbliche.
Istio è un mesh di servizi open source che si sovrappone in modo trasparente alle applicazioni distribuite esistenti. Istio gestisce in modo scalabile l'autenticazione, l'autorizzazione e la crittografia del traffico tra i microservizi. È una piattaforma che include API che ti consentono di eseguire l'integrazione in qualsiasi piattaforma di logging, di telemetria o di sistema di criteri. L'insieme di funzionalità di Istio ti consente di eseguire in modo efficiente un'architettura di microservizi distribuita e fornisce un modo uniforme per proteggere, connettere e monitorare i microservizi.
Requisito 4.1
I processi e i meccanismi per proteggere i dati dei titolari 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 autenticazione e autorizzazione basate su identità solide basate su TLS reciproco. Il 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 nel pod possono utilizzare mTLS per identificare con sicurezza le loro identità peer. La comunicazione tra servizi viene eseguita tramite un tunnel tra proxy Envoy sul lato client e sul lato server. Envoy utilizza gli ID SPIFFE per stabilire connessioni mTLS tra i servizi. Per informazioni su come eseguire il deployment di Istio su GKE, consulta la documentazione di GKE. Per informazioni sulle versioni TLS supportate, consulta la documentazione di riferimento sulla gestione del traffico di Istio. Utilizza TLS versione 1.2 e successive.
Se la tua applicazione è esposta a internet, utilizza il bilanciamento del carico HTTP(S) di GKE con il routing di ingresso 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 come il traffico raggiunge i tuoi servizi e come viene indirizzato alla tua applicazione. Inoltre, un Ingress può fornire un unico indirizzo IP per più servizi nel cluster.
- Integrazione con i Google Cloud servizi di rete. Un oggetto Ingress può configurare Google Cloud funzionalità 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, il controller Ingress di GKE crea un bilanciatore del carico HTTP(S) cloud e lo configura in base alle informazioni in Ingress e nei servizi associati.
Gestire un programma di gestione delle vulnerabilità
La gestione di un programma di gestione delle vulnerabilità include i requisiti 5 e 6 del PCI DSS.
Requisito 5
Proteggi 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 proteggerli dalle minacce di software dannoso attuali e in evoluzione e i contenitori 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 tue immagini container.
Ti consigliamo di procedere nel seguente modo:
- 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.
- Abbonati a un servizio di intelligence sulle vulnerabilità per ricevere informazioni aggiornate sulle vulnerabilità pertinenti all'ambiente e alle librerie utilizzate nei container.
Google Cloud collabora con vari fornitori di soluzioni di sicurezza dei contenitori per migliorare la security posture all'interno dei deployment Google Cloud dei clienti. Ti consigliamo di sfruttare soluzioni e tecnologie di sicurezza validate per aumentare la profondità della difesa nel tuo ambiente GKE. Per l'elenco più recente dei partner per la sicurezza convalidati daGoogle Cloud, consulta Partner per la sicurezza.
Requisito 5.2.2
Le soluzioni antimalware di cui è stato eseguito il deployment:
- Rileva tutti i tipi di malware noti.
- Rimuove, blocca o contiene tutti i tipi di malware noti.
Requisito 5.2.3
Tutti i componenti di sistema non a rischio di malware vengono valutati periodicamente, tra cui:
- Un elenco documentato di tutti i componenti di sistema non esposti al 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 disponibili per eseguire scansioni di malware, ma il PCI DSS riconosce che non tutti i sistemi hanno la stessa probabilità di essere vulnerabili. È comune per i commercianti dichiarare che i loro server Linux, mainframe e macchine simili non sono "comunemente interessati da software dannoso " e quindi esenti dall'articolo 5.2.2. In questo caso, si applica la sezione 5.2.3 e devi 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 anti-malware 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 possono essere sottoposti a scansione da un agente attendibile all'interno del cluster o in cui ogni nodo dispone di uno scanner che genera report 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 sia ai requisiti di antivirus che a quelli FIM è bloccare il contenitore in modo che solo cartelle consentite specifiche 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, ad eccezione di quelle di lavoro, all'interno del file system del contenitore. Disattiva l'escalation dei privilegi per evitare il aggiramento delle regole del file system.
Requisito 6
Sviluppare e gestire sistemi e software sicuri.
Il requisito 6 del PCI DSS prevede che tu stabilisca un ciclo di vita di sviluppo del software solido in cui la sicurezza sia integrata in ogni fase dello sviluppo.
Requisito 6.2
Il software personalizzato e su misura viene sviluppato in modo sicuro.
Requisito 6.2.1
Il software personalizzato e su misura viene sviluppato 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 Autorizzazione binaria per contribuire ad assicurare che in GKE vengano eseguiti il deployment solo di container attendibili. Se vuoi attivare solo le immagini autorizzate da uno o più attestatori specifici, puoi configurare l'autorizzazione binaria per applicare un criterio con regole che richiedono attestazioni in base ai risultati della scansione delle vulnerabilità. Puoi anche scrivere criteri che richiedono l'approvazione di una o più parti attendibili (chiamate "attestatori") prima che un'immagine possa essere implementata. Per una pipeline di deployment multistadio in cui le immagini passano da cluster di sviluppo a cluster di test e di produzione, puoi utilizzare gli attestatori per assicurarti che tutte le procedure richieste siano state completate prima che il software passi alla fase successiva.
Al momento del deployment, Autorizzazione binaria applica i tuoi criteri controllando che l'immagine del contenitore abbia superato tutti i vincoli richiesti, incluso il fatto che tutti gli attestatori richiesti abbiano verificato che l'immagine sia pronta per il deployment. Se l'immagine supera il test, il servizio ne consente il deployment. In caso contrario, il deployment viene bloccato e l'immagine non può essere implementata finché non è conforme.
Per ulteriori informazioni su Autorizzazione binaria, consulta Configurazione per GKE.
In caso di emergenza, puoi bypassare un criterio di autorizzazione binaria utilizzando il flusso di lavoro di emergenza. Tutti i casi di emergenza sono registrati 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 identificate e gestite come segue:
- 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.
- Sono coperte le vulnerabilità per software personalizzati e di terze parti (ad esempio sistemi operativi e database).
La sicurezza nel cloud è una responsabilità condivisa tra il cloud provider e il cliente.
In GKE, Google gestisce il piano di controllo, che include le VM master, il server API e altri componenti in esecuzione su queste VM, nonché il database etcd
. Sono inclusi gli upgrade e le patch, la scalabilità e le riparazioni, il tutto supportato da un obiettivo del livello di servizio (SLO). Per il sistema operativo dei nodi, ad esempio Container-Optimized OS o Ubuntu, GKE rende disponibili tempestivamente eventuali patch per queste immagini. Se hai attivato l'upgrade automatico, queste patch vengono implementate 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 fornisce diversi servizi di sicurezza per aiutarti a integrare la sicurezza nella tua pipeline CI/CD. Per identificare le vulnerabilità nelle immagini container, puoi utilizzare 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 la scansione delle applicazioni web di App Engine, Compute Engine e GKE rivolte al pubblico alla ricerca di vulnerabilità comuni, che vanno dal cross-site scripting alle configurazioni errate fino alle risorse vulnerabili. Le scansioni possono essere eseguite su richiesta e pianificate dalla console Google Cloud. Utilizzando le API di Security Scanner, puoi automatizzare la scansione nell'ambito del tuo set di test di sicurezza nella pipeline di compilazione dell'applicazione.
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 si concentra sul privilegio minimo o sul principio del bisogno di sapere. Il PCI DSS li definisce come l'accesso al minor numero di dati e la concessione del minor numero di privilegi necessari per eseguire un'attività.
Requisito 7.2
L'accesso ai componenti e ai dati di sistema è definito e assegnato in modo appropriato.
IAM e il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes lavorano insieme per fornire controllo dell'accesso granulare al tuo ambiente GKE. IAM viene utilizzato per gestire l'accesso degli utenti e le autorizzazioni delle Google Cloud risorse nel 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 insiemi granulari di autorizzazioni che definiscono in che modo un determinato utente, account di servizio o gruppo di utenti (gruppi Google) può interagire con qualsiasi oggetto Kubernetes nel tuo cluster o in uno spazio dei nomi specifico del tuo cluster. Google Cloud Google Cloud 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 di ruoli RBAC di Kubernetes come appropriato.
Cloud Identity-Aware Proxy (IAP) può essere integrato tramite l'ingress per GKE per controllare l'accesso a livello di applicazione per i dipendenti o le persone che richiedono accesso alle tue applicazioni PCI.
Inoltre, puoi utilizzare 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 quelli con privilegi, in base a:
- Classificazione e funzione del job.
- I privilegi minimi necessari per svolgere le responsabilità lavorative.
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 l'ex controller di ammissione PodSecurityPolicy rimosso nella versione 1.25 di Kubernetes. 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 il ciclo di vita di un 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 del titolare della carta.
Requisito 8.2.5
L'accesso degli utenti con contratto risolto viene revocato immediatamente.
Sia IAM che Kubernetes RBAC possono essere utilizzati per controllare l'accesso al tuo cluster GKE e in entrambi i casi puoi concedere le autorizzazioni a un utente. Ti consigliamo di collegare gli utenti al tuo sistema di identità esistente, in modo da poter gestire gli account utente e i criteri in un'unica posizione.
Requisito 8.3
L'autenticazione avanzata per utenti e amministratori è stabilita e gestita.
Requisito 8.3.1
- Qualcosa che conosci, ad esempio una password o una passphrase.
- Qualcosa che possiedi, ad esempio un token o una smart card.
- Qualcosa che 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 Google Cloud le identità degli account di servizio e utente convalidando le credenziali e recuperando l'indirizzo email associato all'identità dell'account di servizio o utente. 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 su tutti i data center Google alla base diGoogle Cloud.
Monitora e testa regolarmente le reti
Il monitoraggio e il test regolari delle reti comprendono i requisiti 10 e 11 del 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 vengono implementati per supportare il rilevamento di anomalie e attività sospette e 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 per esaminare richieste API sospette, raccogliere statistiche o creare avvisi di monitoraggio per chiamate API indesiderate.
I cluster GKE integrano una configurazione predefinita per il logging di controllo di GKE con Cloud Audit Logs e Logging. Puoi visualizzare le voci dei log di controllo di Kubernetes nel tuo Google Cloud progetto.
Oltre alle voci scritte da Kubernetes, gli audit log del progetto contengono voci scritte da GKE.
Per distinguere i carichi di lavoro CDE e non CDE, ti consigliamo di aggiungere etichette ai pod GKE che verranno incorporate 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 esito positivo o negativo
- Origine dell'evento
- Identità o nome dei dati, del componente di sistema, della risorsa o del servizio interessati (ad esempio nome e protocollo)
Ogni voce di log di controllo in Logging è un oggetto di tipo
LogEntry
che contiene i seguenti campi:
- Un payload di tipo
protoPayload
. Il payload di ogni voce di log di controllo è un oggetto di tipoAuditLog
. Puoi trovare l'identità utente nel campoAuthenticationInfo
degli oggettiAuditLog
. - L'evento specifico, che puoi trovare nel campo
methodName
diAuditLog
. - Un timestamp.
- Lo stato dell'evento, che puoi trovare negli oggetti
response
nell'oggettoAuditLog
. - La richiesta di operazione, che puoi trovare negli oggetti
request
erequestMetadata
nell'oggettoAuditLog
. - Il servizio che verrà eseguito, che puoi trovare nell'oggetto
AuditData
inserviceData
.
Requisito 11
Testa 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.
- Le vulnerabilità critiche e ad alto rischio (in base al ranking del rischio di vulnerabilità dell'entità definito nel Requisito 6.3.1) sono state risolte.
- 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 viene mantenuto aggiornato con le informazioni più recenti 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, questa esegue la scansione delle immagini in Container Registry ed estrae il gestore pacchetti, la base dell'immagine e le occorrenze di vulnerabilità per le immagini.
Scansione incrementale. Artifact Analysis analizza le nuove immagini quando vengono caricate in Container Registry.
Analisi continua: man mano che Artifact Analysis riceve informazioni nuove e aggiornate sulle vulnerabilità dalle relative origini, 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 del CDE.
- Il personale viene avvisato in caso di compromissioni sospette.
- Tutti i motori di rilevamento e prevenzione delle intrusioni, le linee di base e le firme vengono tenute aggiornate.
Google Cloud Il mirroring dei pacchetti può essere utilizzato con Cloud IDS per rilevare le intrusioni nella rete. Google Cloud Il mirroring dei pacchetti inoltra tutto il traffico di rete dalle VM o dai cluster Google Cloud Compute Engine a un indirizzo designato. Cloud IDS può utilizzare questo traffico sottoposto a mirroring per rilevare un'ampia gamma di minacce, tra cui tentativi di exploit, scansione delle porte, overflow del buffer, frammentazione del protocollo, traffico di comando e controllo (C2) e malware.
Security Command Center ti offre visibilità centralizzata sullo stato di sicurezza dei Google Cloud servizi (incluso GKE) e delle risorse dell'intera organizzazione, il che semplifica la prevenzione, il rilevamento e la risposta alle minacce. Utilizzando Security Command Center, puoi vedere quando sono state rilevate minacce ad alto rischio come malware, cryptomining, accessi non autorizzati alle risorse, attacchi DDoS in uscita, scansione delle porte e attacchi brute-force contro SSH in base ai log di Cloud Logging. Google Cloud
Mantenere una norma di sicurezza delle informazioni
Un criterio di sicurezza efficace stabilisce il tono della sicurezza e comunica alle persone cosa è previsto. In questo caso, per "persone" si intendono dipendenti a tempo pieno e part-time, dipendenti temporanei, appaltatori e consulenti che hanno accesso al tuo CDE.
Requisito 12
Supporta la sicurezza delle informazioni con norme e programmi dell'organizzazione.
Per informazioni sul requisito 12, consulta la Google Cloud matrice di responsabilità condivisa PCI.
Pulizia
Se hai utilizzato risorse durante la lettura di questo articolo, ad esempio se hai avviato nuove VM o hai utilizzato gli script Terraform, puoi evitare di pagare costi sul tuo Google Cloud account eliminando il progetto in cui hai utilizzato queste 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ù sulla conformità allo standard PCI Data Security.
- Prova il starter kit Terraform.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.