Questa guida ha lo scopo di aiutarti a risolvere i problemi specifici di le applicazioni Google Kubernetes Engine (GKE) quando implementi le applicazioni le responsabilità Standard di sicurezza dei dati del settore delle carte di pagamento (PCI DSS) i tuoi requisiti.
Disclaimer: questa guida è solo a scopo informativo. Google non intende che le informazioni o i consigli in questa guida costituiscono una consulenza legale o di revisione contabile. Ogni cliente è responsabile valutare il proprio utilizzo dei servizi in modo appropriato per supportare i propri obblighi legali e di conformità.
Introduzione alla conformità PCI DSS e a GKE
Se gestisci i dati di carte di pagamento, devi proteggerli, indipendentemente dal fatto che siano memorizzati in un un database on-premise o nel cloud. Il PCI DSS è stato sviluppato per incoraggiare e migliorare la sicurezza dei dati dei titolari delle carte e facilitare l'ampia adozione di strumenti misure di sicurezza dei dati a livello globale. PCI DSS fornisce una base di dati tecnici e requisiti operativi per la protezione dei dati delle carte di credito. Si applica lo standard PCI DSS a tutte le persone giuridiche coinvolte nell'elaborazione delle carte di pagamento, tra cui commercianti, responsabili, acquirenti, emittenti e fornitori di servizi. PCI DSS si applica anche Tutte le altre persone giuridiche che memorizzano, elaborano o trasmettono dati dei titolari di carte di credito (CHD) o sensibili per l'autenticazione (SAD) o entrambe.
Le applicazioni containerizzate sono diventate popolari di recente tra molte applicazioni legacy per la migrazione di carichi di lavoro da un'architettura basata su macchina virtuale (VM) a un containerizzato. Google Kubernetes Engine è un ambiente gestito e pronto per la produzione per il deployment per applicazioni containerizzate. Offre le ultime innovazioni di Google per gli sviluppatori produttività, efficienza delle risorse, operazioni automatizzate e open source flessibilità per accelerare il time to market.
La conformità è una responsabilità condivisa nel cloud. Google Cloud, compreso GKE (sia la modalità operativa Autopilot che quella Standard), è conforme ai requisiti PCI DSS. Spieghiamo le nostre responsabilità Matrice di responsabilità condivisa.
Pubblico di destinazione
- I clienti che vogliono portare carichi di lavoro conformi allo standard PCI Google Cloud che implicano GKE.
- Sviluppatori, responsabili della sicurezza, conformità dirigenti, amministratori IT e altri dipendenti responsabili l'implementazione dei controlli e la conformità ai requisiti PCI DSS.
Prima di iniziare
Per i consigli che seguono, potresti dover utilizzare seguenti:
- 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 con GKE.
Ambito
Questa guida identifica i seguenti requisiti di PCI DSS che sono univoci i problemi per GKE e fornisce indicazioni per soddisfarli. È scritto su versione 4.0 dello standard. Questa guida non tratta tutti i requisiti di PCI DSS. Le informazioni fornite in questa guida possono aiutare le organizzazioni a perseguire la conformità PCI DSS, ma non si tratta di una consulenza esaustiva. Le organizzazioni possono ingaggiare un QSA (PCI Certified Security Assessor) per la convalida formale.
Terminologia
Questa sezione definisce i termini utilizzati in questa guida. Per ulteriori dettagli, consulta Glossario PCI DSS.
- CHD
dati del titolare della carta. Deve contenere almeno il numero di conto bancario principale completo (PAN). I dati del titolare della carta possono anche essere visualizzati sotto forma di codice PAN più completo 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. Le persone, i processi e la tecnologia che archiviare, elaborare o trasmettere dati del titolare della carta o dati di autenticazione sensibili.
- PAN
numero dell'account principale. Un elemento chiave dei dati del titolare obbligati a proteggere ai sensi dello PCI DSS. Il PAN è generalmente un numero di 16 cifre univoco di una carta di pagamento (credito e debito) e che identifica l'emittente e l'account del titolare della carta.
- PIN
Personal Identification Number. Una password numerica nota solo a l'utente e un sistema; utilizzata per autenticare l'utente nel sistema.
- QSA
qualificatore della sicurezza. Una persona che è certificata dal PCI Security degli standard di Google per l'esecuzione di controlli e analisi della conformità.
- SAD
dati di autenticazione sensibili. In conformità PCI, i dati utilizzati emittenti di carte di credito per autorizzare le transazioni. Simile ai dati del titolare della carta, PCI DSS richiede la protezione del SAD. Inoltre, il SAD non può essere conservato i commercianti e i loro elaboratori dei pagamenti. Il SAD include:
- "Traccia" dati provenienti da strisce magnetiche
- "Monitora dati equivalenti" generati da carte con chip e contactless
- I codici di convalida della sicurezza (ad esempio, il numero di 3-4 cifre stampato sul carte) utilizzate per le transazioni online e senza carta di credito.
- PIN e blocchi di PIN
- segmentazione
Nel contesto dello standard PCI DSS, la pratica di isolare il CDE dal resto della rete dell'entità. La segmentazione non è un modello PCI DSS requisito. Tuttavia, questo metodo è vivamente consigliato 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 grazie al consolidamento dei dati dei titolari della carta 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 memorizzano, elaborano o trasmettono dati dei titolari delle carte o dati sensibili dati di autenticazione. Nel contesto di GKE, il CDE comprende:
- Sistemi che forniscono servizi di sicurezza (ad esempio IAM).
- I sistemi che facilitano la segmentazione (ad esempio progetti, cartelle, firewall, VPC (Virtual Private Cloud) e subnet).
- Pod e cluster di applicazioni che archiviano, elaborano o trasmettono dati del titolare della carta. Senza un'adeguata segmentazione, l'intera superficie del cloud possono rientrare nell'ambito di PCI DSS.
Per essere considerato fuori ambito per PCI DSS, un componente di sistema deve essere correttamente isolati dal CDE in modo che anche se il componente del sistema fuori ambito fosse compromesso, non potrebbe influire sulla sicurezza del CDE.
Un prerequisito importante per ridurre l'ambito del CDE è la chiara le esigenze e i processi aziendali legati all'archiviazione, l'elaborazione e la trasmissione dei dati dei titolari. La limitazione dei dati del titolare della carta a il minor numero di posizioni possibile eliminando i dati inutili e il consolidamento dei dati necessari può richiedere la riprogettazione pratiche commerciali.
Puoi segmentare correttamente il tuo CDE in vari modi su in 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 lo strumento gerarchia delle risorse. Le risorse Google Cloud sono organizzate in modo gerarchico. La Organizzazione è il nodo radice della gerarchia di risorse Google Cloud. Cartelle e progetti che rientrano nella risorsa Organizzazione. Le cartelle possono contenere progetti e cartelle. Le cartelle vengono utilizzate per controllare l'accesso alle risorse nella gerarchia di cartelle autorizzazioni IAM a livello di cartella. Vengono utilizzate anche per raggruppare progetti simili. R è un confine di attendibilità per tutte le risorse e un punto di applicazione IAM.
Puoi raggruppare tutti i progetti nell'ambito PCI all'interno di una cartella per isolare a livello di cartella. Puoi anche utilizzare un progetto per tutte cluster e applicazioni PCI nell'ambito oppure potresti creare un cluster per ogni applicazione PCI in ambito e utilizzarli per organizzare dell'accesso a specifiche risorse Google Cloud. In ogni caso, ti consigliamo di conservare carichi di lavoro all'interno e all'esterno dell'ambito di diversi progetti.
Segmentazione della rete tramite reti e subnet VPC
Puoi utilizzare la modalità Virtual Private Cloud (VPC) e subnet per il provisioning della rete e per raggruppare per isolare le risorse correlate a CDE. Il VPC è un isolamento logico di di un cloud pubblico. Le reti VPC offrono scalabilità networking flessibile per le istanze di macchine virtuali (VM) Compute Engine per i servizi che sfruttano le istanze VM, tra cui GKE. Per ulteriori dettagli, consulta Panoramica di VPC e consulta i best practice e architetture di riferimento.
Segmentazione a livello di servizio mediante Controlli di servizio VPC e Google Cloud Armor
Mentre VPC e subnet forniscono segmentazione e creano un perimetro per isolare il tuo CDE, Controlli di servizio VPC aumenta il perimetro di sicurezza al livello 7. Puoi utilizzare i Controlli di servizio VPC per creare un perimetro intorno ai progetti CDE nell'ambito. I Controlli di servizio VPC offrono i seguenti controlli:
- Controllo in entrata. Sono consentiti solo identità e client autorizzati nel tuo perimetro di sicurezza.
- Controllo in uscita: Sono consentite solo destinazioni autorizzate per e client all'interno del tuo perimetro di sicurezza.
Puoi utilizzare la modalità Google Cloud Armor per creare elenchi di indirizzi IP per consentire o negare l'accesso ai tuoi Bilanciatore del carico HTTP(S) sul perimetro della rete Google Cloud. Esaminando gli indirizzi IP come il più vicino possibile all'utente e a traffico dannoso, contribuisci a prevenire traffico dannoso proveniente dal consumo di risorse o dall'ingresso nelle reti VPC.
Utilizza i Controlli di servizio VPC per definire un perimetro di servizio intorno all'ambito in modo programmatico a gestire i progetti. Questo perimetro regola i percorsi da VM a servizio e da servizio a servizio, nonché al traffico VPC in entrata e in uscita.
Crea e gestisci sistemi e reti sicuri
La creazione e la gestione di una rete sicura comprendono i requisiti 1 e 2 delle PCI-DSS
Requisito 1
Installa e gestisci una configurazione firewall per proteggere e il traffico in entrata e in uscita dal CDE.
I concetti di networking per container e GKE sono diversi da quelli per alle VM tradizionali. I pod possono raggiungersi a vicenda direttamente, senza NAT, anche nodi. Questo crea una topologia di rete semplice che potrebbe sorprenderti se abituati a gestire sistemi più complessi. Il primo passo nella sicurezza di rete GKE è imparare a usare questi concetti di networking.
Prima di esaminare i singoli requisiti nel Requisito 1, ti consigliamo di per rivedere i seguenti concetti di networking in relazione a GKE:
Regole firewall. Regole firewall vengono utilizzati per limitare il traffico ai nodi. I nodi GKE sono istanze le istanze di Compute Engine e utilizzano lo stesso firewall come gli altri casi. All'interno della tua rete, puoi usare i tag e applicare queste regole firewall a ciascuna istanza. Ogni pool di nodi riceve il proprio insieme di tag che puoi utilizzare nelle regole. Per impostazione predefinita, ogni istanza appartiene a un pool di nodi riceve un tag che identifica uno specifico di cui fa parte questo pool di nodi. Questo tag è utilizzato nel firewall che GKE crea automaticamente per te. Puoi aggiungere tag personalizzati in fase di creazione del cluster o del pool di nodi utilizzando Flag
--tagsin Google Cloud CLI.Criteri di rete. Criteri di rete di limitare le connessioni di rete tra i pod, cambio di rete e movimenti laterali all'interno dell'ammasso nel caso di un problema di sicurezza con un pod. Per utilizzare i criteri di rete, è necessario attivare durante la creazione del cluster GKE. Puoi abilitarla su un cluster esistente, ma causerà nodi al riavvio. Il comportamento predefinito è che tutte le comunicazioni pod-to-pod è sempre aperto. Pertanto, se desideri segmentare la tua rete, devi e applicare criteri di networking a livello di pod. In GKE puoi per definire un criterio di rete, API Network Policy di Kubernetes o utilizzando lo strumento
kubectl. Queste regole dei criteri di traffico a livello di pod determinare quali pod e servizi possono accedere l'uno all'altro all'interno in un cluster Kubernetes.Spazi dei nomi. Spazi dei nomi consente la segmentazione delle risorse all'interno del cluster Kubernetes. Kubernetes è dotato di uno spazio dei nomi predefinito, ma puoi creare più spazi dei nomi all'interno del cluster. Gli spazi dei nomi sono isolati logicamente e l'altro. Forniscono l'ambito per pod, servizi e deployment cluster, in modo che gli utenti che interagiscono con un singolo spazio dei nomi non vedano contenuti in un altro spazio dei nomi. Tuttavia, gli spazi dei nomi all'interno dello stesso cluster limitare la comunicazione tra spazi dei nomi; è qui che i criteri di rete entra in gioco. Per ulteriori informazioni sulla configurazione degli spazi dei nomi, consulta Best practice per gli spazi dei nomi post del blog.
Il seguente diagramma illustra i concetti precedenti in relazione a ciascuno altri componenti GKE come cluster, node 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 i gruppi, i ruoli e le responsabilità nella gestione componenti di rete.
Innanzitutto, come faresti con la maggior parte dei servizi su Google Cloud, configura IAM ruoli per configurare l'autorizzazione su GKE. Dopo aver configurato devi aggiungere i ruoli IAM, 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 di risorse in ogni cluster Kubernetes e consente un'autorizzazione granulare a livello dello spazio dei nomi. Con GKE, questi approcci all'autorizzazione di lavorare in parallelo, e le capacità di un utente rappresentano in modo efficace l'unione Ruoli IAM e RBAC assegnati:
- Utilizzare IAM per controllare gruppi, ruoli e responsabilità per la gestione logica dei componenti di rete in GKE.
- Usa Kubernetes RBAC per concedere autorizzazioni granulari norme della rete all'interno dei cluster Kubernetes, per controllare il traffico tra pod e prevenire modifiche non autorizzate o accidentali da parte di utenti non CDE.
- Giustifica tutti gli utenti e le autorizzazioni IAM e RBAC. In genere, quando le QSA verificano i controlli, cercano un'azienda per un esempio di IAM e RBAC.
Requisito 1.2
I controlli di sicurezza di rete (NSC) sono configurati e gestiti.
Innanzitutto, devi configurare regole firewall sulle istanze Compute Engine che eseguono i tuoi nodi GKE. Le regole firewall proteggono questi nodi del cluster.
Poi devi configurare norme della rete per limitare i flussi e proteggere i pod in un cluster. R criteri di rete è una specifica del modo in cui i gruppi di pod sono autorizzati a comunicare con altri endpoint di rete. Puoi usare la rete GKE dell'applicazione dei criteri per controllare la comunicazione tra i pod del cluster i servizi di machine learning. Per segmentare ulteriormente il cluster, crea più spazi dei nomi al suo interno. e sono logicamente isolati tra loro. Forniscono l'ambito di pod, servizi e deployment nel cluster, in modo che gli utenti interagiscano non vedrà i contenuti di un altro spazio dei nomi. Tuttavia, gli spazi dei nomi all'interno nello stesso cluster non limitano la comunicazione tra gli spazi dei nomi, questo è dove i criteri di rete. consentono la segmentazione delle risorse all'interno in un cluster Kubernetes. Per ulteriori informazioni sulla configurazione degli spazi dei nomi, consulta Best practice per gli spazi dei nomi post del blog.
Per impostazione predefinita, se non esistono criteri in uno spazio dei nomi, vengono inclusi tutti i criteri in entrata e in uscita il traffico sia consentito da e verso i pod in quello spazio dei nomi. Ad esempio, puoi creare un criterio di isolamento predefinito per uno spazio dei nomi creando un che seleziona tutti i pod, ma non consente il traffico in entrata verso quei pod.
Requisito 1.2.2
Tutte le modifiche alle connessioni di rete e alle le configurazioni NSC siano approvate e gestite in conformità con il processo di controllo delle modifiche definiti al requisito 6.5.1.
Per trattare le configurazioni di networking e l'infrastruttura come codice, devi stabilire un'integrazione e una distribuzione continue (CI/CD) nell'ambito dei tuoi processi di gestione e controllo dei cambiamenti.
Puoi utilizzare la modalità Cloud Deployment Manager o Terraform come parte della pipeline CI/CD per creare criteri di rete cluster. Con Deployment Manager o Terraform, puoi e Infrastructure as Code in grado di riprodurre copie coerenti nell'ambiente di produzione attuale o in altri ambienti. Quindi scrivere test delle unità e altri test per garantire che le modifiche alla rete funzionino previsto. È possibile gestire un processo di controllo delle modifiche che include un'approvazione tramite file di configurazione archiviati in un repository delle versioni.
Con Strumento di convalida di Terraform Config puoi definire i vincoli per applicare criteri di sicurezza e governance. Di aggiungendo lo strumento di convalida della configurazione alla pipeline CI/CD, puoi aggiungere un passaggio nel tuo flusso di lavoro. Questo passaggio convalida un piano Terraform e lo rifiuta in caso di violazioni disponibili.
Requisito 1.2.5
Tutti i servizi, i protocolli e le porte sono consentiti identificati, approvati e hanno un'attività definita necessaria.
Per controlli efficaci in entrata per i tuoi cluster GKE, puoi utilizzare reti autorizzate per limitare determinati intervalli IP che possono raggiungere dal piano di controllo. GKE utilizza sia Transport Layer Security (TLS) per fornire un accesso sicuro all'endpoint master del cluster tramite la rete internet pubblica. Questo accesso ti offre la flessibilità di amministrare cluster da qualsiasi luogo. Utilizzando le reti autorizzate, puoi limitare ulteriormente l'accesso a insiemi specifici di indirizzi IP.
Puoi utilizzare la modalità Google Cloud Armor creare liste di indirizzi IP bloccati, liste consentite e criteri di sicurezza per delle applicazioni in hosting su GKE. In un cluster GKE, il traffico in entrata viene gestito Bilanciamento del carico HTTP(S), che è un componente Cloud Load Balancing. In genere, il bilanciatore del carico HTTP(S) viene configurato tramite Controller in entrata GKE, che ottiene le informazioni di configurazione da un In entrata . Per ulteriori informazioni, vedi 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 comunicazioni private tra Cluster GKE all'interno delle tue reti VPC e ambienti ibridi on-premise i deployment utilizzando Controlli di servizio VPC e accesso privato Google.
Requisito 1.3.1
Il traffico in ingresso verso CDE è limitato come segue:
- Solo per il traffico necessario.
- Tutto il resto del traffico viene specificamente negato.
Valuta l'implementazione 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 rivolti al pubblico nel tuo CDE. In un cluster privato, i nodi dispongono solo di indirizzi IP RFC 1918 interni, il che garantisce che i loro carichi di lavoro e isolato dalla rete internet pubblica.
Requisito 1.4
Le connessioni di rete tra reti attendibili e non attendibili sono controllate.
Puoi soddisfare questo requisito utilizzando gli stessi metodi elencati per il Requisito 1.3.
Requisito 1.4.3
Le misure anti-spoofing vengono implementate rilevare e bloccare gli indirizzi IP di origine falsificati che entrano nella rete attendibile.
Implementi misure anti-spoofing utilizzando indirizzi IP alias su Pod e cluster GKE per rilevare e bloccare l'IP di origine contraffatto di indirizzi IP esterni alla rete. Un cluster che utilizza Intervalli IP alias è chiamato cluster nativo di VPC.
Requisito 1.4.5
La divulgazione degli indirizzi IP interni e delle informazioni di routing è limitata solo alle parti autorizzate.
Puoi utilizzare uno dei seguenti Agente di mascheramento IP di GKE per eseguire la Network Address Translation (NAT) per traduzioni di indirizzi IP many-to-one su un cluster. Il mascheramento maschera più indirizzi IP di origine dietro un singolo .
Requisito 2
Applica configurazioni sicure a tutti i componenti del sistema.
Il requisito 2 specifica come rafforzare la 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.
Assicurarsi che questi standard risolvano tutte le vulnerabilità di sicurezza note e che in linea con gli standard di protezione del sistema accettati dal settore. Origini di gli standard di protezione dei sistemi accettati dal settore possono includere, a titolo esemplificativo a:Requisito 2.2.4
Solo servizi, protocolli, daemon necessari e le funzioni sono abilitate e non è necessario viene rimossa o disattivata.
Requisito 2.2.5
- La giustificazione aziendale è documentata.
- Le funzionalità di sicurezza aggiuntive sono documentate implementate che riducono il rischio di usare daemon, protocolli o servizi non sicuri.
Requisito 2.2.6
I parametri di sicurezza del sistema sono configurati su evitare usi impropri.
Pre-deployment
Prima di spostare i container in GKE, ti consigliamo seguenti:
- Inizia con un container immagine di base gestita creato, mantenuto e controllato da una fonte attendibile. Valuta l'idea di creare un insieme di "beni noti" o "oro" le immagini di base utilizzabili dagli sviluppatori. Un'opzione più restrittiva è l'utilizzo di immagine senza distroless o un immagine di base dello scraping.
- Utilizza le funzionalità di Analisi degli artefatti per analizzare le immagini container alla ricerca di vulnerabilità.
- Stabilisci un criterio DevOps/SecOps interno per includere solo i criteri librerie e programmi binari attendibili nei container.
Al momento della configurazione
Durante la configurazione, è consigliabile:
- Utilizza il valore predefinito Container-Optimized OS come immagine del nodo per GKE. Container-Optimized OS è basato su Chromium OS ed è ottimizzato per sicurezza dei nodi.
- Attiva nodi con upgrade automatico per i cluster che eseguono le tue applicazioni. Questa funzionalità esegue l'upgrade del nodo alla versione Kubernetes in esecuzione il piano di controllo gestito, offrendo maggiore stabilità e sicurezza.
- Attiva nodi con riparazione automatica. Quando questa funzionalità è abilitata, GKE controlla periodicamente e utilizza lo stato di integrità del nodo per determinare se deve essere riparato. Se un nodo deve essere riparato, viene svuotato e ne viene creato uno nuovo. e aggiunti al cluster.
- Attiva Cloud Monitoring e Cloud Logging per avere visibilità su tutti gli eventi, inclusi gli eventi di sicurezza e l'integrità dei nodi . Crea Criteri di avviso di Cloud Monitoring per ricevere una notifica in caso di incidenti di sicurezza.
- Richiedi account di servizio con privilegi minimi per i nodi GKE
- Esamina e applica (se applicabile) la sezione GKE del
Benchmark CIS di Google Cloud
guida. L'audit logging di Kubernetes è già abilitato per impostazione predefinita e i log per
vengono scritte entrambe le richieste a
kubectle all'API GKE Cloud Audit Logs. - Configura 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 quali crittografia, troncamento, mascheramento e hashing sono componenti fondamentali di la protezione dei dati dei titolari. Se un intruso aggira altri controlli di sicurezza e ottiene l'accesso ai dati crittografati, senza le chiavi di crittografia appropriate, il i dati siano illeggibili e inutilizzabili per quella persona.
Potresti anche prendere in considerazione altri metodi per proteggere i dati archiviati potenziali opportunità di mitigazione del rischio. Ad esempio, i metodi per ridurre al minimo rischiano di non archiviare i dati dei titolari se non assolutamente necessario, il troncamento dati del titolare della carta se il PAN completo non è necessario e non invia PAN non protetti usando tecnologie di messaggistica per gli utenti finali, come email e messaggistica immediata.
Esempi di sistemi in cui il codice CHD potrebbe persistere nell'ambito dell'elaborazione dei pagamenti durante l'esecuzione su Google Cloud:
- Bucket Cloud Storage
- Istanze BigQuery
- Datastore
- Cloud SQL
Tieni presente che il CHD potrebbe essere inavvertitamente memorizzato in email o nel servizio clienti log delle comunicazioni. È prudente usare Protezione dei dati sensibili per filtrare questi stream di dati in modo da limitare l'ambiente che rientra nell'ambito ai sistemi di elaborazione dei pagamenti.
Tieni presente che su Google Cloud i dati criptati at-rest per impostazione predefinita, e criptati in transito per impostazione predefinita quando attraversa i confini fisici. 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 scoprire di più su la tokenizzazione, consulta Limitazione dell'ambito di conformità per gli ambienti PCI in Google Cloud
Puoi utilizzare lo API DLP per scansionare, individuare e segnalare i dati del titolare della carta. Sensitive Data Protection offre il supporto per la scansione e la classificazione dei dati PAN di 12-19 cifre Cloud Storage, BigQuery e Datastore. Dispone inoltre di un'API Streaming Content per abilitare il supporto di dati aggiuntivi carichi di lavoro personalizzati, origini dati e applicazioni. Puoi utilizzare anche l'API DLP per troncare (oscurare) o eseguire l'hashing i 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. Sebbene Cloud KMS non direttamente store secret come i dati del titolare della carta, possono essere usati per criptare tali dati.
I secret nel contesto di Kubernetes sono oggetti segreti che ti consentono di archiviare e gestire informazioni sensibili come password, token, e chiavi.
Per impostazione predefinita, Google Cloud cripta i contenuti archiviati inattivi dei clienti. GKE gestisce e gestisce questa crittografia predefinita per te senza qualsiasi altra azione da parte vostra. Crittografia dei secret a livello di applicazione fornisce un ulteriore livello di sicurezza per i dati sensibili come i secret. Utilizzando questa funzionalità, puoi fornire una chiave da gestire Cloud KMS, per criptare i dati a livello di applicazione. Questo meccanismo protegge da malintenzionati che accedere a una copia dell'istanza di archiviazione della configurazione Kubernetes in un cluster Kubernetes.
Requisito 4
Proteggi i dati dei titolari delle carte con una crittografia avanzata durante la trasmissione su piattaforme aperte e pubbliche reti.
I dati nell'ambito devono essere criptati durante la trasmissione su reti che facilmente accessibili da parte di utenti malintenzionati, ad esempio le reti pubbliche.
Istio è una mesh di servizi open source che si sovrappone in modo trasparente su in applicazioni distribuite. Istio gestisce in modo scalabile l'autenticazione, l'autorizzazione e la crittografia del traffico tra microservizi. È una piattaforma che include API che consentono l'integrazione in qualsiasi piattaforma di logging, telemetria o criterio di un sistema operativo completo. Il set di funzionalità di Istio consente di eseguire in modo efficiente un microservizio distribuito dell'architettura e offre un modo uniforme per proteggere, connettere e monitorare di microservizi.
Requisito 4.1
I processi e i meccanismi per proteggere i dati dei titolari 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, l'autenticazione e il monitoraggio tra servizi. Puoi utilizzarlo anche per comunicazione sicura tra servizi in un cluster, con autenticazione e autorizzazione basate su TLS reciproco. TLS reciproco (mTLS) è un handshake TLS eseguito due volte e che stabilisce lo stesso livello la fiducia in entrambe le direzioni (al contrario dell'attendibilità unidirezionale client-server).
Istio consente di eseguire il deployment dei certificati TLS su ciascuno dei pod GKE all'interno di un'applicazione. I servizi in esecuzione sul pod possono utilizzare mTLS per a identificare le identità peer. La comunicazione tra servizi è in tunnel tramite lato client e lato server Envoy proxy. Envoy utilizza SPIFFE ID per stabilire connessioni mTLS tra i servizi. Per informazioni su come eseguire il deployment Istio su GKE, consulta le Documentazione di GKE. Per informazioni sulle versioni TLS supportate, consulta la documentazione di Istio Informazioni sulla gestione del traffico. Utilizza TLS 1.2 e versioni successive.
Se la tua applicazione è esposta a internet, usa Bilanciamento del carico HTTP(S) di GKE con 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 il modo in cui il traffico viene instradato verso i tuoi un'applicazione. Inoltre, una risorsa Ingress può fornire un singolo indirizzo IP più servizi nel tuo cluster.
- Integrazione con i servizi di rete di Google Cloud. un oggetto Ingress poter configurare funzionalità di Google Cloud, 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 utilizzo di più certificati TLS per la terminazione delle richieste.
Quando crei un oggetto Ingress, Controller in entrata GKE crea un Bilanciatore del carico HTTP(S) di Cloud e lo configura in base alle informazioni nel traffico in entrata e ai suoi Servizi.
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 dello standard PCI DSS prevede l'utilizzo di software antivirus su tutti i sistemi comunemente colpiti da malware per proteggere i sistemi da sistemi minacce software dannose in continua evoluzione, e i container non fanno eccezione.
Requisito 5.2
Il software dannoso (malware) viene impedito o rilevato e gestito.
Devi implementare programmi di gestione delle vulnerabilità per le immagini container.
Consigliamo di eseguire queste operazioni:
- Controlla regolarmente e applica patch di sicurezza aggiornate ai container.
- Esegui regolarmente analisi delle vulnerabilità rispetto ad applicazioni containerizzate e programmi binari/librerie.
- Analizzare le immagini come parte della pipeline di build.
- Iscriviti a un servizio di intelligence sulle vulnerabilità di ricevere informazioni aggiornate sulle vulnerabilità e sull'ambiente e le librerie utilizzate nei container.
Google Cloud collabora con vari provider di soluzioni per la sicurezza dei container per migliorare la security posture dei clienti deployment di Google Cloud. Me consiglia di sfruttare soluzioni e tecnologie di sicurezza convalidate per aumentare una maggiore profondità di difesa nel tuo ambiente GKE. Per le ultime notizie Elenco dei partner per la sicurezza convalidati da Google Cloud, vedi Partner per la sicurezza.
Requisito 5.2.2
Le soluzioni antimalware implementate:
- Rileva tutti i tipi di malware noti.
- Rimuove, blocca o contiene tutti i tipi noti di malware.
Requisito 5.2.3
I componenti del sistema che non sono a rischio malware vengono valutati periodicamente per includere seguenti:
- Un elenco documentato di tutti i componenti di sistema non a rischio di malware.
- Individuazione e valutazione dell’evoluzione malware per quei componenti del sistema.
- Conferma se i componenti di sistema in questione continuano a non avere bisogno di protezione antimalware.
Esistono molte soluzioni per eseguire scansioni di malware, ma PCI DSS riconosce che non tutti i sistemi hanno le stesse probabilità di essere vulnerabili. È comune per i commercianti di dichiarare i server Linux, i mainframe e computer non "comunque colpiti da software dannoso" e quindi esente dalla versione 5.2.2. In questo caso, si applica la sezione 5.2.3, ed è necessario implementare un sistema per valutazioni periodiche delle minacce.
Tieni presente che queste regole si applicano sia ai nodi che ai pod all'interno di un cluster GKE.
Requisito 5.3
I meccanismi e i processi antimalware sono attivi, gestiti e monitorati.
I Requisiti 5.2, 5.3 e 11.5 richiedono scansioni antivirus e monitoraggio dell’integrità dei file (FIM) su qualsiasi host nell'ambito. Consigliamo di implementare una soluzione in cui tutti i nodi possono essere analizzati da un agente attendibile all'interno del cluster o dove ogni nodo ha scanner che riporta fino a un singolo endpoint di gestione.
Per ulteriori informazioni, vedi la panoramica sulla sicurezza di GKE, e la panoramica sulla sicurezza di Container-Optimized OS.
Una soluzione comune ai requisiti antivirus e FIM è il blocco il tuo container in modo che solo determinate cartelle consentite abbiano accesso in scrittura. Da fare questo, eseguire i container come utente non root e usano le autorizzazioni del file system per impedire l'accesso in scrittura a tutti tranne quelli funzionanti all'interno del file system del container. Non consentire l'escalation dei privilegi per evitare la circonvenzione delle regole del file system.
Requisito 6
Sviluppa e gestisci sistemi e software sicuri.
Il requisito 6 dello standard PCI DSS prevede che il software ciclo di sviluppo in cui la sicurezza è integrata in ogni fase del software sviluppo del prodotto.
Requisito 6.2
I software su misura e personalizzati vengono sviluppati in modo sicuro.
Requisito 6.2.1
Sviluppo di software su misura e personalizzati in modo sicuro, come segue:
- In base agli standard di settore e/o ai migliori per uno sviluppo sicuro.
- In conformità allo standard PCI DSS (ad esempio, autenticazione e logging sicuri).
- Integrazione della considerazione delle informazioni problemi di sicurezza in ogni fase del software ciclo di sviluppo del prodotto.
Puoi utilizzare la modalità Autorizzazione binaria per garantire che venga eseguito il deployment su GKE solo di container attendibili. Se vuoi attivare solo le immagini autorizzate da uno o più attestatori specifici, puoi configurare Autorizzazione binaria per applicare norme con regole che richiedono attestazioni in base ai risultati dell'analisi delle vulnerabilità. Puoi anche scrivere criteri che richiedono una o più parti fidate (chiamate "attaccatori") per approvare un'immagine prima di cui è possibile eseguire il deployment. Per una pipeline di deployment multifase in cui le immagini progrediscono dallo sviluppo ai test, fino ai cluster di produzione, puoi utilizzare gli attestatori garantire che tutti i processi richiesti siano stati completati prima del passaggio del software alla fase successiva.
Al momento del deployment, Autorizzazione binaria applica i criteri verificando che l'immagine container abbia superato tutti i vincoli richiesti, inclusi che tutti gli attestatori richiesti abbiano verificato che l'immagine è pronta per e deployment continuo. Se l'immagine viene accettata, il servizio ne consente il deployment. In caso contrario, il deployment viene bloccato e l'immagine non può essere sottoposta a deployment conforme.
Per ulteriori informazioni su Autorizzazione binaria, consulta Configura per GKE.
In caso di emergenza, puoi ignorare un criterio di Autorizzazione binaria utilizzando flusso di lavoro del deployment di emergenza. Tutti i casi di emergenza sono registrati in Audit log di Cloud.
GKE Sandbox riduce la necessità che il container interagisca direttamente con l'host, la superficie di attacco per la compromissione dell'host e limitando il movimento malintenzionati.
Requisito 6.3
Le vulnerabilità di sicurezza vengono identificate e gestite.
Requisito 6.3.1
Le vulnerabilità di sicurezza vengono gestiti nel seguente modo:
- Vengono identificate nuove vulnerabilità di sicurezza fonti riconosciute nel settore per la sicurezza informazioni sulle vulnerabilità, tra cui avvisi emergenza informatica internazionale e nazionale di risposta ai team (CERT).
- Alle vulnerabilità viene assegnato un ranking del rischio basato sulle best practice del settore e sulla considerazione il potenziale impatto.
- Le classifiche di rischio identificano, come minimo, tutte vulnerabilità considerate ad alto rischio o fondamentale per l'ambiente.
- Vulnerabilità per applicazioni personalizzate software di terze parti (ad esempio, sistemi e database) vengono trattati.
La sicurezza nel cloud è una responsabilità condivisa tra il cloud provider e il cliente.
In GKE, Google gestisce il piano di controllo, che include
le VM master, il server API e altri componenti in esecuzione su queste VM, nonché
come database etcd. Sono inclusi upgrade, patch, scalabilità e
riparazioni, il tutto supportato da un obiettivo del livello del servizio (SLO). Per i nodi operativo
come Container-Optimized OS, o Ubuntu, GKE
rende disponibili prontamente eventuali patch a queste immagini. Se disponi dell'upgrade automatico
abilitato, il deployment di queste patch
viene eseguito automaticamente. (Questo è lo strato di base
del tuo container, non è uguale al sistema operativo in esecuzione
containers.)
Per ulteriori informazioni sul modello di responsabilità condivisa di GKE, consulta Esplorazione della sicurezza dei container: il modello di responsabilità condivisa in GKE.
Google offre diversi servizi di sicurezza per aiutarti a integrare la sicurezza nel tuo pipeline CI/CD. Per identificare le vulnerabilità nelle immagini container, puoi utilizzare Analisi delle vulnerabilità di Google Artifact Analysis. Quando viene eseguito il push di un'immagine container Google Container Registry (GCR) l'analisi delle vulnerabilità analizza automaticamente le immagini per individuare di esposizioni note a CVE fonti. Alle vulnerabilità sono assegnati livelli di gravità (critico, elevato, medio, bassa e minima) in base a Punteggi CVSS.
Requisito 6.4
Le applicazioni web rivolte al pubblico sono protette dagli attacchi.
Web Security Scanner consente di eseguire scansioni di App Engine, Compute Engine e le applicazioni web GKE per le vulnerabilità comuni cross-site scripting (XSS) e configurazioni errate in risorse vulnerabili. Le scansioni possono essere eseguita on demand e programmata dal Console Google Cloud. Utilizzando le API Security Scanner, è possibile automatizzare la scansione come parte e la suite di test per la sicurezza nella pipeline di build delle applicazioni.
Implementa efficaci misure di controllo dell'accesso
L'implementazione di misure efficaci di controllo dell'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 definisce poiché garantiscono l'accesso alla minor quantità di dati e offrono il minor numero di dati 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 Controllo controllo dell'accesso basato su ruoli (RBAC) di Kubernetes possono lavorare insieme per fornire un controllo dell'accesso granulare ai tuoi completamente gestito di Google Cloud. IAM è utilizzato per gestire l'accesso e le autorizzazioni degli utenti risorse Google Cloud nel tuo progetto CDE. In GKE puoi usano IAM anche per gestire l'accesso e le azioni che utenti e che possono eseguire nei cluster, ad esempio creando ed eliminando cluster.
Kubernetes RBAC ti consente di configurare autorizzazioni che definiscono in che modo un determinato utente Google Cloud, account di servizio o gruppi di utenti (Google Gruppi) possono interagire con qualsiasi oggetto Kubernetes nel tuo cluster o in del tuo cluster. Esempi di autorizzazioni RBAC includono la modifica deployment o ConfigMap, eliminazione di pod o visualizzazione dei log da un pod. Concedi con autorizzazioni IAM limitate per utenti o servizi, Visualizzatore cluster Google Kubernetes Engine o ruoli personalizzati, quindi applica i RoleBinding RBAC di Kubernetes in base alle tue esigenze.
Cloud Identity Aware Proxy (IAP) possono essere integrati tramite Ingress per GKE al controllo accesso a livello di applicazione per i dipendenti o le persone che richiedono l'accesso al tuo PCI diverse applicazioni.
Inoltre, puoi utilizzare 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, tra cui con privilegi in base a:
- Classificazione e funzione del job.
- Privilegi minimi necessari per eseguire il job e le responsabilità aziendali.
Oltre a garantire che gli utenti e gli account di servizio rispettino il principio della con il privilegio minimo, lo dovrebbero fare anche i container. Una best practice per l'esecuzione di un container è eseguire il processo con un utente non root. Puoi eseguire questa operazione e applicarla in modo forzato esercitati utilizzando 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 è necessario assegnare un ID univoco a ogni persona che l'accesso ai sistemi PCI pertinenti per garantire che ogni individuo sia univoco responsabile delle proprie azioni.
Requisito 8.2
L'identificazione degli utenti e gli account correlati per utenti e amministratori sono gestiti rigorosamente durante l'intero ciclo di vita dell'account.
Requisito 8.2.1
A tutti gli utenti viene assegnato prima un ID univoco l'accesso ai componenti di sistema o ai dati dei titolari consentito.
Requisito 8.2.5
L'accesso per gli utenti terminati viene immediatamente revocati.
È possibile usare sia IAM sia Kubernetes RBAC per controllare l'accesso il tuo cluster GKE e in entrambi i casi puoi concedere le autorizzazioni un utente. Consigliamo agli utenti di ricollegarsi sistema di identità esistente, in modo da poter gestire gli account utente e i criteri da un'unica posizione.
Requisito 8.3
L'autenticazione avanzata per utenti e amministratori viene istituita e gestita.
Requisito 8.3.1
- Qualcosa che conosci, ad esempio una password o una passphrase.
- Qualcosa che possiedi, ad esempio un dispositivo token o una smart card.
- Qualcosa che sei, ad esempio un elemento biometrico.
I certificati sono associati all'identità dell'utente quando
fa l'autenticazione in kubectl.
Tutti i cluster GKE sono configurati per accettare l'utente Google Cloud
e le identità degli account di servizio, convalidando le credenziali e recuperando
all'indirizzo email associato all'identità dell'account dell'utente o dell'account di servizio. Di conseguenza,
le credenziali per questi account devono includere l'ambito OAuth userinfo.email
per poter eseguire l'autenticazione.
Requisito 9
Limita l'accesso fisico ai dati del titolare della carta.
Google sta responsabile dei controlli di sicurezza fisica in tutti i data center Google sottostanti. in Google Cloud.
Monitorare e testare regolarmente le reti
Il monitoraggio e il test regolari delle reti contempla i requisiti 10 e 11 delle PCI-DSS
Requisito 10
Registra e monitora 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.
I cluster Kubernetes Audit logging di Kubernetes abilitata per impostazione predefinita, che conserva un registro cronologico delle chiamate al server API di Kubernetes. Le voci degli audit log di Kubernetes sono utili indaga su richieste API sospette, per raccogliere statistiche o per creando avvisi di monitoraggio per le chiamate API indesiderate.
I cluster GKE integrano una configurazione predefinita Audit logging di GKE con Audit log di Cloud e Logging. Puoi visualizzare le voci degli audit log di Kubernetes nel tuo progetto Google Cloud.
Oltre alle voci scritte da Kubernetes, gli audit log del progetto scritte da GKE.
Per differenziare i carichi di lavoro CDE e non CDE, ti consigliamo di aggiungere etichette ai tuoi pod GKE che si penetrano in metriche e log emesse dai carichi di lavoro.
Requisito 10.2.2
- Identificazione utente
- Tipo di evento
- Data e ora
- Indicazione di successo o errore
- Origine dell'evento
- Identità o nome dei dati e del sistema interessati componente, risorsa o servizio (ad esempio, nome e protocollo)
Ogni voce di audit log in Logging è un oggetto di tipo
LogEntry
che contiene i seguenti campi:
- Un payload, di tipo
protoPayload. Il payload di ogni audit voce di log è un oggetto di tipoAuditLogPuoi trovare l'identità utente nel campoAuthenticationInfodiAuditLogoggetti. - L'evento specifico, che puoi trovare nel campo
methodNamediAuditLog. - Un timestamp.
- Lo stato dell'evento, che puoi trovare negli oggetti
responsedella sezione OggettoAuditLog. - La richiesta dell'operazione, che puoi trovare in
requesterequestMetadataoggetti nell'oggettoAuditLog. - Il servizio che verrà eseguito, che puoi trovare nella
AuditDataoggetto inserviceData.
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.
- Vulnerabilità critiche e ad alto rischio (in base i livelli di rischio di vulnerabilità dell'entità definiti Il requisito 6.3.1) sono stati risolti.
- Vengono eseguite nuove scansioni per confermare tutte le vulnerabilità critiche e ad alto rischio (come indicato sopra) sono stati risolti.
- Lo strumento di scansione è aggiornato con le ultime informazioni sulle vulnerabilità.
- Le scansioni vengono eseguite da personale qualificato e dell'indipendenza organizzativa del tester.
Artifact Analysis analisi delle vulnerabilità esegue i seguenti tipi di analisi delle vulnerabilità per le immagini Container Registry:
Scansione iniziale. Quando attivi per la prima volta l'API Artifact Analysis, scansiona le immagini in Container Registry ed estrae gestore di pacchetti, base di immagini ed e le occorrenze di vulnerabilità delle immagini.
Scansione incrementale. Nuove analisi di Artifact Analysis quando vengono caricate su Container Registry.
Analisi continua: man mano che Artifact Analysis riceve nuovi e ha aggiornato le informazioni sulle vulnerabilità da origini di vulnerabilità, esegue nuovamente dei container per mantenere l'elenco delle occorrenze di vulnerabilità le immagini già scansionate sono aggiornate.
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 nel perimetro CDE,
- Tutto il traffico viene monitorato nei punti critici della CDE,
- Il personale viene avvisato qualora sospetti compromissioni.
- Tutti i motori di rilevamento e prevenzione delle intrusioni, basi di riferimento e le firme vengono mantenute aggiornate.
Mirroring pacchetto Google Cloud può essere utilizzato con Cloud IDS per rilevare le intrusioni nella rete. Il mirroring pacchetto Google Cloud inoltra tutti del traffico di rete dalle VM di Compute Engine o dai cluster Google Cloud a un indirizzo designato. Cloud IDS può consumare questo il traffico sottoposto a mirroring per rilevare un'ampia gamma di minacce, inclusi i tentativi di exploit, scansioni delle porte, overflow del buffer, frammentazione del protocollo, comando e controllo (C2) traffico e malware.
Security Command Center offre una visibilità centralizzata sullo stato della i servizi e gli asset Google Cloud (incluso GKE) in tutto nell'intera organizzazione, il che rende più facile prevenire, rilevare e in modo proattivo. Utilizzando Security Command Center, puoi vedere quando minacce ad alto rischio come malware, cryptomining, accessi non autorizzati alle risorse Google Cloud, sono stati rilevati attacchi DDoS in uscita, scansione delle porte e attacchi di forza bruta SSH in base ai log di Cloud Logging.
Mantieni una politica di sicurezza delle informazioni
Un solido criterio di sicurezza definisce il tono della sicurezza e indica alle persone cosa che ci si aspettava da loro. In questo caso, "persone" si riferisce a tempo pieno e part-time dipendenti, collaboratori temporanei, contrattisti e consulenti che hanno accesso del tuo CDE.
Requisito 12
Supporta la sicurezza delle informazioni con i criteri e i programmi dell'organizzazione.
Per informazioni sul requisito 12, consulta Matrice di responsabilità condivisa PCI di Google Cloud.
esegui la pulizia
Se hai utilizzato risorse durante l'esecuzione di questo articolo, ad esempio se hai hanno avviato nuove VM o utilizzato gli script Terraform, puoi evitare i costi vengono addebitati al tuo account Google Cloud eliminando il progetto in cui hanno utilizzato tali risorse.
- 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ù su Conformità allo standard di sicurezza dei dati PCI.
- Prova la Starter kit Terraform.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.