Raccomandazioni sulla sicurezza per le risorse di Google Cloud Platform (GCP)

Articolo
03/13/2024

Questo articolo elenca tutte le raccomandazioni che potrebbero essere visualizzate in Microsoft Defender per il cloud se si connette un account Google Cloud Platform (GCP) usando la pagina Impostazioni ambiente. Le raccomandazioni visualizzate nell'ambiente sono basate sulle risorse protette e sulla configurazione personalizzata.

Per informazioni sulle azioni che è possibile eseguire in risposta a queste raccomandazioni, vedere Correggere le raccomandazioni in Defender per il cloud.

Il punteggio di sicurezza si basa sul numero di raccomandazioni di sicurezza completate. Per decidere quali raccomandazioni risolvere prima, esaminare la gravità di ogni raccomandazione e il potenziale effetto sul punteggio di sicurezza.

Raccomandazioni per le risorse di calcolo GCP

Le macchine virtuali del motore di calcolo devono usare il sistema operativo ottimizzato per i contenitori

Descrizione: questa raccomandazione valuta la proprietà config di un pool di nodi per la coppia chiave-valore, 'imageType': 'COS'.

Gravità: Bassa

I problemi di configurazione EDR devono essere risolti nelle macchine virtuali GCP

Descrizione: per proteggere le macchine virtuali dalle minacce e dalle vulnerabilità più recenti, risolvere tutti i problemi di configurazione identificati con la soluzione DIR (Endpoint Detection and Response) installata.
Nota: attualmente questa raccomandazione si applica solo alle risorse con Microsoft Defender per endpoint (MDE) abilitata.

Gravità: alta

La soluzione EDR deve essere installata in GCP Macchine virtuali

Descrizione: per proteggere le macchine virtuali, installare una soluzione di rilevamento e risposta degli endpoint (EDR). Le richieste edR consentono di prevenire, rilevare, analizzare e rispondere alle minacce avanzate. Usare Microsoft Defender per server per distribuire Microsoft Defender per endpoint. Se la risorsa è classificata come "Non integra", non è installata una soluzione EDR supportata [collegamento Segnaposto - Altre informazioni]. Se è installata una soluzione EDR che non è individuabile da questa raccomandazione, è possibile esentarla.

Gravità: alta

Verificare che "Blocca chiavi SSH a livello di progetto" sia abilitato per le istanze di macchina virtuale

Descrizione: è consigliabile usare chiavi SSH specifiche dell'istanza anziché usare chiavi SSH comuni/condivise a livello di progetto per accedere alle istanze. Le chiavi SSH a livello di progetto vengono archiviate in Calcolo/Project-meta-data. Le chiavi SSH a livello di progetto possono essere usate per accedere a tutte le istanze all'interno del progetto. L'uso di chiavi SSH a livello di progetto semplifica la gestione delle chiavi SSH, ma, se compromessa, comporta il rischio di sicurezza che può influire su tutte le istanze all'interno del progetto. È consigliabile usare chiavi SSH specifiche dell'istanza che possono limitare la superficie di attacco se le chiavi SSH vengono compromesse.

Gravità: medio

Verificare che le istanze di calcolo vengano avviate con la macchina virtuale schermata abilitata

Descrizione: per difendersi dalle minacce avanzate e assicurarsi che il caricatore di avvio e il firmware nelle macchine virtuali siano firmati e non soddisfatti, è consigliabile avviare le istanze di calcolo con la macchina virtuale schermata abilitata. Le macchine virtuali schermate sono macchine virtuali (VM) in Google Cloud Platform con protezione avanzata da un set di controlli di sicurezza che consentono di difendersi dai rootkit e dai bootkit. La macchina virtuale schermata offre l'integrità verificabile delle istanze della macchina virtuale del motore di calcolo, pertanto è possibile assicurarsi che le istanze non siano state compromesse da malware o rootkit a livello di kernel o di avvio. L'integrità verificabile della macchina virtuale schermata viene ottenuta tramite l'uso di avvio protetto, un modulo VTPM (Virtual Trusted Platform Module) abilitato per l'avvio misurato e il monitoraggio dell'integrità. Le istanze della macchina virtuale schermata eseguono il firmware firmato e verificato usando l'autorità di certificazione di Google, assicurandosi che il firmware dell'istanza non sia modificato e stabilissi la radice di attendibilità per l'avvio protetto. Il monitoraggio dell'integrità consente di comprendere e prendere decisioni sullo stato delle istanze della macchina virtuale e la macchina virtuale schermata vTPM abilita l'avvio misurato eseguendo le misurazioni necessarie per creare una baseline di avvio valida nota, denominata baseline dei criteri di integrità. La baseline dei criteri di integrità viene usata per il confronto con le misurazioni degli avvio delle macchine virtuali successive per determinare se sono state apportate modifiche. L'avvio protetto garantisce che il sistema esegua solo il software autentico verificando la firma digitale di tutti i componenti di avvio e interrompendo il processo di avvio in caso di esito negativo della verifica della firma.

Gravità: alta

Assicurarsi che l'opzione 'Abilita connessione alle porte seriali' non sia abilitata per l'istanza di macchina virtuale

Descrizione: l'interazione con una porta seriale viene spesso definita console seriale, simile all'uso di una finestra del terminale, in tale input e output è interamente in modalità testo e non è disponibile alcuna interfaccia grafica o supporto del mouse. Se si abilita la console seriale interattiva in un'istanza, i client possono tentare di connettersi a tale istanza da qualsiasi indirizzo IP. Pertanto, il supporto interattivo della console seriale deve essere disabilitato. Un'istanza di macchina virtuale ha quattro porte seriali virtuali. L'interazione con una porta seriale è simile all'uso di una finestra del terminale, in tale input e output è interamente in modalità testo e non è disponibile alcuna interfaccia grafica o supporto del mouse. Il sistema operativo, il BIOS e altre entità a livello di sistema spesso scrivono l'output nelle porte seriali e possono accettare input, ad esempio comandi o risposte alle richieste. In genere, queste entità a livello di sistema usano la prima porta seriale (porta 1) e la porta seriale 1 viene spesso definita console seriale. La console seriale interattiva non supporta restrizioni di accesso basate su IP, ad esempio gli elenchi di indirizzi IP consentiti. Se si abilita la console seriale interattiva in un'istanza, i client possono tentare di connettersi a tale istanza da qualsiasi indirizzo IP. Ciò consente a chiunque di connettersi a tale istanza se conosce la chiave SSH corretta, il nome utente, l'ID progetto, la zona e il nome dell'istanza. Pertanto, il supporto interattivo della console seriale deve essere disabilitato.

Gravità: medio

Assicurarsi che il flag di database 'log_duration' per l'istanza di Cloud SQL PostgreSQL sia impostato su 'on'

Descrizione: l'abilitazione dell'impostazione log_hostname determina la registrazione della durata di ogni istruzione completata. Ciò non registra il testo della query e pertanto si comporta in modo diverso dal flag log_min_duration_statement. Questo parametro non può essere modificato dopo l'avvio della sessione. Il monitoraggio del tempo impiegato per eseguire le query può essere fondamentale per identificare qualsiasi query di spostamento delle risorse e valutare le prestazioni del server. È possibile eseguire ulteriori passaggi, ad esempio il bilanciamento del carico e l'uso di query ottimizzate, per garantire le prestazioni e la stabilità del server. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che il flag di database "log_executor_stats" per l'istanza di Cloud SQL PostgreSQL sia impostato su "off"

Descrizione: l'executor PostgreSQL è responsabile dell'esecuzione del piano consegnato da PostgreSQL Planner. L'executor elabora il piano in modo ricorsivo per estrarre il set di righe richiesto. Il flag "log_executor_stats" controlla l'inclusione delle statistiche sulle prestazioni dell'executor PostgreSQL nei log postgreSQL per ogni query. Il flag "log_executor_stats" consente un metodo di profilatura grezzo per la registrazione delle statistiche sulle prestazioni dell'executor PostgreSQL, che, anche se può essere utile per la risoluzione dei problemi, potrebbe aumentare significativamente la quantità di log e avere un sovraccarico delle prestazioni. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che il flag di database "log_min_error_statement" per l'istanza di Cloud SQL PostgreSQL sia impostato su "Errore" o più restrittivo

Descrizione: il flag "log_min_error_statement" definisce il livello di gravità minimo del messaggio considerato come istruzione di errore. I messaggi per le istruzioni di errore vengono registrati con l'istruzione SQL. I valori validi includono "DEBUG5", "DEBUG4", "DEBUG3", "DEBUG2", "DEBUG1", "INFO", "AVVISO", "AVVISO", "ERRORE", "LOG", "FATAL" e "PANIC". Ogni livello di gravità include i livelli successivi indicati in precedenza. Verificare che sia impostato un valore ERROR o stricter. Il controllo aiuta a risolvere i problemi operativi e consente anche l'analisi forense. Se "log_min_error_statement" non è impostato sul valore corretto, i messaggi potrebbero non essere classificati come messaggi di errore in modo appropriato. Considerando i messaggi di log generali come messaggi di errore, è difficile trovare gli errori effettivi e considerare solo livelli di gravità più rigidi perché i messaggi di errore potrebbero ignorare gli errori effettivi per registrare le istruzioni SQL. Il flag "log_min_error_statement" deve essere impostato su "ERROR" o più restrittivo. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che il flag di database "log_parser_stats" per l'istanza di Cloud SQL PostgreSQL sia impostato su "off"

Descrizione: PostgreSQL planner/optimizer è responsabile dell'analisi e della verifica della sintassi di ogni query ricevuta dal server. Se la sintassi è corretta, viene creato un "albero di analisi" in caso contrario viene generato un errore. Il flag "log_parser_stats" controlla l'inclusione delle statistiche sulle prestazioni del parser nei log postgreSQL per ogni query. Il flag "log_parser_stats" consente un metodo di profilatura grezzo per la registrazione delle statistiche sulle prestazioni del parser, che, anche se può essere utile per la risoluzione dei problemi, potrebbe aumentare significativamente la quantità di log e avere un sovraccarico delle prestazioni. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che il flag di database "log_planner_stats" per l'istanza di Cloud SQL PostgreSQL sia impostato su "off"

Descrizione: la stessa query SQL può essere eseguita in diversi modi e comunque produrre risultati diversi. PostgreSQL Planner/Optimizer è responsabile della creazione di un piano di esecuzione ottimale per ogni query. Il flag "log_planner_stats" controlla l'inclusione delle statistiche sulle prestazioni di PostgreSQL planner nei log postgreSQL per ogni query. Il flag "log_planner_stats" consente un metodo di profilatura grezzo per la registrazione delle statistiche sulle prestazioni di PostgreSQL Planner, che, anche se può essere utile per la risoluzione dei problemi, potrebbe aumentare notevolmente la quantità di log e avere un sovraccarico delle prestazioni. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che il flag di database "log_statement_stats" per l'istanza di Cloud SQL PostgreSQL sia impostato su "off"

Descrizione: il flag "log_statement_stats" controlla l'inclusione delle statistiche sulle prestazioni end-to-end di una query SQL nei log postgreSQL per ogni query. Non è possibile abilitare questa opzione con altre statistiche del modulo (log_parser_stats, log_planner_stats log_executor_stats). Il flag "log_statement_stats" consente un metodo di profilatura grezzo per la registrazione delle statistiche sulle prestazioni end-to-end di una query SQL. Ciò può essere utile per la risoluzione dei problemi, ma potrebbe aumentare notevolmente la quantità di log e avere un sovraccarico delle prestazioni. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che le istanze di calcolo non dispongano di indirizzi IP pubblici

Descrizione: le istanze di calcolo non devono essere configurate per avere indirizzi IP esterni. Per ridurre la superficie di attacco, le istanze di calcolo non devono avere indirizzi IP pubblici. Al contrario, le istanze devono essere configurate dietro i servizi di bilanciamento del carico, per ridurre al minimo l'esposizione dell'istanza a Internet. Le istanze create da GKE devono essere escluse perché alcune di esse hanno indirizzi IP esterni e non possono essere modificate modificando le impostazioni dell'istanza. Queste macchine virtuali hanno nomi che iniziano con gke- e sono etichettati goog-gke-node.

Gravità: alta

Assicurarsi che le istanze non siano configurate per l'uso dell'account del servizio predefinito

Descrizione: è consigliabile configurare l'istanza per non usare l'account del servizio motore di calcolo predefinito perché ha il ruolo Editor nel progetto. L'account del servizio Motore di calcolo predefinito ha il ruolo Editor nel progetto, che consente l'accesso in lettura e scrittura alla maggior parte dei Servizi cloud Google. Per difendersi dalle escalation dei privilegi se la macchina virtuale è compromessa e impedire a un utente malintenzionato di accedere a tutto il progetto, è consigliabile non usare l'account del servizio motore di calcolo predefinito. È invece necessario creare un nuovo account del servizio e assegnare solo le autorizzazioni necessarie per l'istanza. L'account del servizio motore di calcolo predefinito è denominato [PROJECT_NUMBER]- compute@developer.gserviceaccount.com. Le macchine virtuali create da GKE devono essere escluse. Queste macchine virtuali hanno nomi che iniziano con gke- e sono etichettati goog-gke-node.

Gravità: alta

Assicurarsi che le istanze non siano configurate per l'uso dell'account del servizio predefinito con accesso completo a tutte le API cloud

Descrizione: per supportare il principio dei privilegi minimi e impedire l'escalation dei privilegi potenziali, è consigliabile che le istanze non vengano assegnate all'account del servizio predefinito "Account del servizio predefinito del motore di calcolo" con ambito "Consenti l'accesso completo a tutte le API cloud". Oltre alla possibilità di creare, gestire e usare gli account del servizio personalizzati gestiti dall'utente, Google Compute Engine fornisce l'account di servizio predefinito "Account del servizio predefinito del motore di calcolo" per un'istanza per accedere ai servizi cloud necessari. Il ruolo "Project Editor" viene assegnato all'account del servizio predefinito del motore di calcolo, di conseguenza, questo account del servizio ha quasi tutte le funzionalità di tutti i servizi cloud ad eccezione della fatturazione. Tuttavia, quando "Account del servizio predefinito del motore di calcolo" assegnato a un'istanza può operare in tre ambiti.

Consenti accesso predefinito: consente solo l'accesso minimo necessario per eseguire un'istanza (privilegi minimi).
Consenti l'accesso completo a tutte le API cloud: consenti l'accesso completo a tutte le API/servizi cloud (troppo accesso).
Impostare l'accesso per ogni API: consente all'amministratore dell'istanza di scegliere solo le API necessarie per eseguire funzionalità aziendali specifiche previste dall'istanza Quando un'istanza viene configurata con "Account del servizio predefinito del motore di calcolo" con ambito "Consenti l'accesso completo a tutte le API cloud", in base ai ruoli IAM assegnati all'istanza, potrebbe consentire all'utente di eseguire operazioni cloud/chiamate API che l'utente non deve eseguire con successo l'escalation dei privilegi. Le macchine virtuali create da GKE devono essere escluse. Queste macchine virtuali hanno nomi che iniziano con "gke-" e sono etichettati come "goog-gke-node".

Gravità: medio

Assicurarsi che l'inoltro IP non sia abilitato nelle istanze

Descrizione: l'istanza del motore di calcolo non può inoltrare un pacchetto a meno che l'indirizzo IP di origine del pacchetto corrisponda all'indirizzo IP dell'istanza. Analogamente, GCP non recapita un pacchetto il cui indirizzo IP di destinazione è diverso dall'indirizzo IP dell'istanza che riceve il pacchetto. Tuttavia, entrambe le funzionalità sono necessarie se si vogliono usare le istanze per indirizzare i pacchetti. L'inoltro dei pacchetti di dati deve essere disabilitato per evitare la perdita di dati o la divulgazione di informazioni. L'istanza del motore di calcolo non può inoltrare un pacchetto a meno che l'indirizzo IP di origine del pacchetto corrisponda all'indirizzo IP dell'istanza. Analogamente, GCP non recapita un pacchetto il cui indirizzo IP di destinazione è diverso dall'indirizzo IP dell'istanza che riceve il pacchetto. Tuttavia, entrambe le funzionalità sono necessarie se si vogliono usare le istanze per indirizzare i pacchetti. Per abilitare questo controllo IP di origine e destinazione, disabilitare il campo canIpForward, che consente a un'istanza di inviare e ricevere pacchetti con indirizzi IP di destinazione o di origine non corrispondenti.

Gravità: medio

Assicurarsi che il flag di database "log_checkpoints" per l'istanza di Cloud SQL PostgreSQL sia impostato su "on"

Descrizione: assicurarsi che il flag di database log_checkpoints per l'istanza di Cloud SQL PostgreSQL sia impostato su Attivato. L'abilitazione di log_checkpoints fa sì che i checkpoint e i punti di riavvio vengano registrati nel log del server. Alcune statistiche sono incluse nei messaggi di log, tra cui il numero di buffer scritti e il tempo impiegato per scriverli. Questo parametro può essere impostato solo nel file postgresql.conf o nella riga di comando del server. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che il flag di database "log_lock_waits" per l'istanza di Cloud SQL PostgreSQL sia impostato su "on"

Descrizione: l'abilitazione del flag "log_lock_waits" per un'istanza di PostgreSQL crea un log per le attese di sessione che richiedono più tempo rispetto al tempo "deadlock_timeout" assegnato per acquisire un blocco. Il timeout del deadlock definisce il tempo di attesa di un blocco prima di verificare eventuali condizioni. L'esecuzione frequente in caso di timeout dei deadlock può essere un'indicazione di un problema sottostante. La registrazione di tali attese sui blocchi abilitando il flag log_lock_waits può essere usata per identificare prestazioni scarse a causa di ritardi di blocco o se un SQL appositamente creato sta tentando di starvendo le risorse mantenendo blocchi per quantità eccessive di tempo. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che il flag di database "log_min_duration_statement" per l'istanza di Cloud SQL PostgreSQL sia impostato su '-1'

Descrizione: il flag "log_min_duration_statement" definisce la quantità minima di tempo di esecuzione di un'istruzione in millisecondi in cui viene registrata la durata totale dell'istruzione. Assicurarsi che "log_min_duration_statement" sia disabilitato, ovvero sia impostato il valore -1. Le istruzioni SQL di registrazione possono includere informazioni riservate che non devono essere registrate nei log. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che il flag di database "log_min_messages" per l'istanza di Cloud SQL PostgreSQL sia impostato in modo appropriato

Descrizione: il flag "log_min_error_statement" definisce il livello di gravità minimo del messaggio considerato come istruzione di errore. I messaggi per le istruzioni di errore vengono registrati con l'istruzione SQL. I valori validi includono "DEBUG5", "DEBUG4", "DEBUG3", "DEBUG2", "DEBUG1", "INFO", "AVVISO", "AVVISO", "ERRORE", "LOG", "FATAL" e "PANIC". Ogni livello di gravità include i livelli successivi indicati in precedenza. Nota: per disattivare efficacemente le istruzioni di errore di registrazione, impostare questo parametro su PANIC. L'errore è considerato l'impostazione di procedura consigliata. Le modifiche devono essere apportate solo in conformità ai criteri di registrazione dell'organizzazione. Il controllo aiuta a risolvere i problemi operativi e consente anche l'analisi forense. Se "log_min_error_statement" non è impostato sul valore corretto, i messaggi potrebbero non essere classificati come messaggi di errore in modo appropriato. Considerando i messaggi di log generali come messaggi di errore, sarebbe difficile trovare errori effettivi, considerando solo i livelli di gravità più rigidi perché i messaggi di errore potrebbero ignorare gli errori effettivi per registrare le istruzioni SQL. Il flag "log_min_error_statement" deve essere impostato in base ai criteri di registrazione dell'organizzazione. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che il flag di database "log_temp_files" per l'istanza di Cloud SQL PostgreSQL sia impostato su "0"

Descrizione: PostgreSQL può creare un file temporaneo per azioni come l'ordinamento, l'hashing e i risultati di query temporanei quando queste operazioni superano "work_mem". Il flag "log_temp_files" controlla i nomi di registrazione e le dimensioni del file quando viene eliminato. La configurazione di "log_temp_files" su 0 comporta la registrazione di tutte le informazioni sui file temporanei, mentre i valori positivi registrano solo file le cui dimensioni sono maggiori o uguali al numero specificato di kilobyte. Il valore "-1" disabilita la registrazione temporanea delle informazioni sui file. Se tutti i file temporanei non vengono registrati, potrebbe essere più difficile identificare potenziali problemi di prestazioni che potrebbero essere dovuti a problemi di codifica di applicazioni non ottimali o tentativi intenzionali di fame delle risorse.

Gravità: Bassa

Verificare che i dischi delle macchine virtuali per le macchine virtuali critiche siano crittografati con la chiave di crittografia fornita dal cliente

Descrizione: le chiavi di crittografia fornite dal cliente (C edizione Standard K) sono una funzionalità di Google Cloud Archiviazione e Google Compute Engine. Se si forniscono chiavi di crittografia personalizzate, Google usa la chiave per proteggere le chiavi generate da Google usate per crittografare e decrittografare i dati. Per impostazione predefinita, Google Compute Engine crittografa tutti i dati inattivi. Il motore di calcolo gestisce e gestisce automaticamente questa crittografia senza azioni aggiuntive da parte dell'utente. Tuttavia, se si vuole controllare e gestire questa crittografia manualmente, è possibile fornire chiavi di crittografia personalizzate. Per impostazione predefinita, Google Compute Engine crittografa tutti i dati inattivi. Il motore di calcolo gestisce e gestisce automaticamente questa crittografia senza azioni aggiuntive da parte dell'utente. Tuttavia, se si vuole controllare e gestire questa crittografia manualmente, è possibile fornire chiavi di crittografia personalizzate. Se si forniscono chiavi di crittografia personalizzate, il motore di calcolo usa la chiave per proteggere le chiavi generate da Google usate per crittografare e decrittografare i dati. Solo gli utenti che possono fornire la chiave corretta possono usare le risorse protette da una chiave di crittografia fornita dal cliente. Google non archivia le chiavi nei server e non può accedere ai dati protetti a meno che non si fornisca la chiave. Ciò significa anche che, se si dimentica o si perde la chiave, non c'è modo per Google di recuperare la chiave o di recuperare i dati crittografati con la chiave persa. Almeno le macchine virtuali business critical devono avere dischi vm crittografati con C edizione Standard K.

Gravità: medio

Per i progetti GCP deve essere abilitato il provisioning automatico di Azure Arc

Descrizione: per una visibilità completa del contenuto di sicurezza di Microsoft Defender per i server, le istanze di macchine virtuali GCP devono essere connesse ad Azure Arc. Per assicurarsi che tutte le istanze di vm idonee ricevano automaticamente Azure Arc, abilitare il provisioning automatico da Defender per il cloud a livello di progetto GCP. Altre informazioni su Azure Arc e Microsoft Defender per server.

Gravità: alta

Le istanze di vm GCP devono essere connesse ad Azure Arc

Descrizione: Connessione il Macchine virtuali GCP ad Azure Arc per avere visibilità completa sul contenuto di sicurezza di Microsoft Defender per server. Altre informazioni su Azure Arc e su Microsoft Defender per server nell'ambiente cloud ibrido.

Gravità: alta

Per le istanze di vm GCP deve essere installato l'agente di configurazione del sistema operativo

Descrizione: per ricevere le funzionalità complete di Defender per server usando il provisioning automatico di Azure Arc, le macchine virtuali GCP devono avere l'agente di configurazione del sistema operativo abilitato.

Gravità: alta

La funzionalità di ripristino automatico del cluster GKE deve essere abilitata

Descrizione: questa raccomandazione valuta la proprietà di gestione di un pool di nodi per la coppia chiave-valore, 'key': 'autoRepair,' 'value': true.

Gravità: medio

La funzionalità di aggiornamento automatico del cluster GKE deve essere abilitata

Descrizione: questa raccomandazione valuta la proprietà di gestione di un pool di nodi per la coppia chiave-valore, 'key': 'autoUpgrade,' 'value': true.

Gravità: alta

È necessario abilitare il monitoraggio dei cluster GKE

Descrizione: questa raccomandazione valuta se la proprietà monitoringService di un cluster contiene il percorso Da usare Monitoraggio cloud per scrivere le metriche.

Gravità: medio

Raccomandazioni per i contenitori GCP

[Anteprima] Le immagini del contenitore nel registro GCP devono avere i risultati della vulnerabilità risolti

Descrizione: Defender per il cloud analizza le immagini del Registro di sistema per individuare vulnerabilità note (CVE) e fornisce risultati dettagliati per ogni immagine analizzata. L'analisi e la correzione delle vulnerabilità per le immagini dei contenitori nel registro consentono di mantenere una catena di approvvigionamento software sicura e affidabile, riduce il rischio di eventi imprevisti di sicurezza e garantisce la conformità agli standard del settore.

Gravità: alta

Tipo: Valutazione della vulnerabilità

[Anteprima] I contenitori in esecuzione in GCP devono avere i risultati della vulnerabilità risolti

Descrizione: Defender per il cloud crea un inventario di tutti i carichi di lavoro dei contenitori attualmente in esecuzione nei cluster Kubernetes e fornisce report sulle vulnerabilità per tali carichi di lavoro associando le immagini usate e i report sulle vulnerabilità creati per le immagini del Registro di sistema. L'analisi e la correzione delle vulnerabilità dei carichi di lavoro dei contenitori è fondamentale per garantire una catena di approvvigionamento software affidabile e sicura, ridurre il rischio di incidenti di sicurezza e garantire la conformità agli standard di settore.

Gravità: alta

Tipo: Valutazione della vulnerabilità

La configurazione avanzata di Defender per contenitori deve essere abilitata nei connettori GCP

Descrizione: Microsoft Defender per contenitori offre funzionalità di sicurezza Kubernetes native del cloud, tra cui protezione avanzata dell'ambiente, protezione del carico di lavoro e protezione in fase di esecuzione. Per assicurarsi che il provisioning della soluzione venga eseguito correttamente e che sia disponibile il set completo di funzionalità, abilitare tutte le impostazioni di configurazione avanzate.

Gravità: alta

I cluster GKE devono avere installato l'estensione di Microsoft Defender per Azure Arc

Descrizione: l'estensione del cluster di Microsoft Defender offre funzionalità di sicurezza per i cluster GKE. L'estensione raccoglie i dati da un cluster e dai relativi nodi per identificare le vulnerabilità e le minacce per la sicurezza. L'estensione funziona con Kubernetes abilitato per Azure Arc. Altre informazioni sulle funzionalità di sicurezza di Microsoft Defender per il cloud per gli ambienti in contenitori.

Gravità: alta

Nei cluster GKE deve essere installata l'estensione Criteri di Azure

Descrizione: Criteri di Azure'estensione per Kubernetes estende Gatekeeper v3, un webhook del controller di ammissione per Open Policy Agent (OPA), per applicare le imposizione e le misure di sicurezza su larga scala nei cluster in modo centralizzato e coerente. L'estensione funziona con Kubernetes abilitato per Azure Arc.

Gravità: alta

Microsoft Defender per contenitori deve essere abilitato nei connettori GCP

Descrizione: Microsoft Defender per contenitori offre funzionalità di sicurezza Kubernetes native del cloud, tra cui protezione avanzata dell'ambiente, protezione del carico di lavoro e protezione in fase di esecuzione. Abilitare il piano Contenitori nel connettore GCP per rafforzare la sicurezza dei cluster Kubernetes e correggere i problemi di sicurezza. Altre informazioni su Microsoft Defender per contenitori.

Gravità: alta

La funzionalità di ripristino automatico del cluster GKE deve essere abilitata

Descrizione: questa raccomandazione valuta la proprietà di gestione di un pool di nodi per la coppia chiave-valore, 'key': 'autoRepair,' 'value': true.

Gravità: medio

La funzionalità di aggiornamento automatico del cluster GKE deve essere abilitata

Descrizione: questa raccomandazione valuta la proprietà di gestione di un pool di nodi per la coppia chiave-valore, 'key': 'autoUpgrade,' 'value': true.

Gravità: alta

È necessario abilitare il monitoraggio dei cluster GKE

Descrizione: questa raccomandazione valuta se la proprietà monitoringService di un cluster contiene il percorso Da usare Monitoraggio cloud per scrivere le metriche.

Gravità: medio

La registrazione per i cluster GKE deve essere abilitata

Descrizione: questa raccomandazione valuta se la proprietà loggingService di un cluster contiene il percorso Da usare Registrazione cloud per scrivere i log.

Gravità: alta

Il dashboard Web GKE deve essere disabilitato

Descrizione: questa raccomandazione valuta il campo kubernetesDashboard della proprietà addonsConfig per la coppia chiave-valore, 'disabled': false.

Gravità: alta

L'autorizzazione legacy deve essere disabilitata nei cluster GKE

Descrizione: questa raccomandazione valuta la proprietà legacyAbac di un cluster per la coppia chiave-valore, 'enabled': true.

Gravità: alta

Le reti autorizzate del piano di controllo devono essere abilitate nei cluster GKE

Descrizione: questa raccomandazione valuta la proprietà masterAuthorizedNetworksConfig di un cluster per la coppia chiave-valore, 'enabled': false.

Gravità: alta

I cluster GKE devono avere intervalli IP alias abilitati

Descrizione: questa raccomandazione valuta se il campo useIPAliases di ipAllocationPolicy in un cluster è impostato su false.

Gravità: Bassa

I cluster GKE devono avere cluster privati abilitati

Descrizione: questa raccomandazione valuta se il campo enablePrivateNodes della proprietà privateClusterConfig è impostato su false.

Gravità: alta

I criteri di rete devono essere abilitati nei cluster GKE

Descrizione: questa raccomandazione valuta il campo networkPolicy della proprietà addonsConfig per la coppia chiave-valore, 'disabled': true.

Gravità: medio

Raccomandazioni sul piano dati

Tutte le raccomandazioni sulla sicurezza del piano dati Kubernetes sono supportate per GCP dopo aver abilitato Criteri di Azure per Kubernetes.

Raccomandazioni per i dati GCP

Verificare che il flag di database '3625 (flag di traccia)' per l'istanza di SQL Server cloud sia impostato su 'off'

Descrizione: è consigliabile impostare il flag di database "3625 (flag di traccia)" per l'istanza di SQL Server cloud su "off". I flag di traccia vengono spesso usati per diagnosticare i problemi di prestazioni o per eseguire il debug di stored procedure o sistemi computer complessi, ma possono anche essere consigliati da supporto tecnico Microsoft per risolvere i comportamenti che influiscono negativamente su un carico di lavoro specifico. Tutti i flag di traccia descritti e quelli consigliati dal supporto tecnico Microsoft sono completamente supportati in un ambiente di produzione se usati come indicato. "3625(log di traccia)" Limita la quantità di informazioni restituite agli utenti che non sono membri del ruolo predefinito del server sysadmin, mascherando i parametri di alcuni messaggi di errore usando "******". In questo modo è possibile impedire la divulgazione di informazioni riservate. Di conseguenza, è consigliabile disabilitare questo flag. Questa raccomandazione è applicabile alle istanze di database di SQL Server.

Gravità: medio

Verificare che il flag di database "external scripts enabled" per l'istanza di SQL Server cloud sia impostato su 'off'

Descrizione: è consigliabile impostare il flag di database "script esterni abilitati" per l'istanza di SQL Server cloud su off. "script esterni abilitati" consentono l'esecuzione di script con determinate estensioni del linguaggio remoto. Questa proprietà è DISATTIVATA per impostazione predefinita. Quando Advanced Analytics Services è installato, il programma di installazione può impostare facoltativamente questa proprietà su true. Poiché la funzionalità "Script esterni abilitati" consente l'esecuzione di script esterni a SQL, ad esempio i file che si trovano in una libreria R, che potrebbero influire negativamente sulla sicurezza del sistema, di conseguenza questo dovrebbe essere disabilitato. Questa raccomandazione è applicabile alle istanze di database di SQL Server.

Gravità: alta

Verificare che il flag di database "Accesso remoto" per l'istanza di SQL Server cloud sia impostato su "off"

Descrizione: è consigliabile impostare il flag di database "Accesso remoto" per l'istanza di SQL Server cloud su "off". L'opzione "Accesso remoto" controlla l'esecuzione di stored procedure da server locali o remoti in cui sono in esecuzione istanze di SQL Server. Il valore predefinito dell'opzione è 1. In questo modo si ottiene l'autorizzazione a eseguire stored procedure locali da server remoti o stored procedure remote dal server locale. Per impedire l'esecuzione di stored procedure locali da un server remoto o da stored procedure remote nel server locale, questa operazione deve essere disabilitata. L'opzione Accesso remoto controlla l'esecuzione di stored procedure locali su server remoti o stored procedure remote nel server locale. La funzionalità "Accesso remoto" può essere caricata in modo improprio per avviare un attacco Denial of Service (DoS) sui server remoti disattivando l'elaborazione delle query in una destinazione, di conseguenza questa operazione deve essere disabilitata. Questa raccomandazione è applicabile alle istanze di database di SQL Server.

Gravità: alta

Assicurarsi che il flag di database 'skip_show_database' per l'istanza di Cloud SQL Mysql sia impostato su 'on'

Descrizione: è consigliabile impostare il flag di database "skip_show_database" per l'istanza di Cloud SQL Mysql su "on". Il flag di database 'skip_show_database' impedisce agli utenti di usare l'istruzione SHOW DATABA edizione Standard S se non dispone del privilegio SHOW DATABA edizione Standard S. In questo modo è possibile migliorare la sicurezza in caso di problemi relativi alla possibilità di visualizzare i database appartenenti ad altri utenti. L'effetto dipende dal privilegio SHOW DATABA edizione Standard S: se il valore della variabile è ON, l'istruzione SHOW DATABA edizione Standard S è consentita solo agli utenti che dispongono del privilegio SHOW DATABA edizione Standard S e l'istruzione visualizza tutti i nomi di database. Se il valore è OFF, SHOW DATABA edizione Standard S è consentito a tutti gli utenti, ma visualizza i nomi solo dei database per i quali l'utente dispone di SHOW DATABA edizione Standard S o di altri privilegi. Questa raccomandazione è applicabile alle istanze del database Mysql.

Gravità: Bassa

Assicurarsi che sia specificata una chiave di crittografia gestita dal cliente (CMEK) predefinita per tutti i set di dati BigQuery

Descrizione: Per impostazione predefinita, BigQuery crittografa i dati come inattivi usando Envelope Encryption usando chiavi di crittografia gestite da Google. I dati vengono crittografati usando le chiavi di crittografia dei dati e le chiavi di crittografia dei dati stessi vengono ulteriormente crittografati usando le chiavi di crittografia delle chiavi. Questo è facile e non richiede alcun input aggiuntivo dall'utente. Tuttavia, se si vuole avere un maggiore controllo, le chiavi di crittografia gestite dal cliente (CMEK) possono essere usate come soluzione di gestione delle chiavi di crittografia per i set di dati BigQuery. Per impostazione predefinita, BigQuery crittografa i dati come inattivi usando Envelope Encryption usando chiavi di crittografia gestite da Google. Questo è facile e non richiede alcun input aggiuntivo dall'utente. Per un maggiore controllo sulla crittografia, le chiavi di crittografia gestite dal cliente (CMEK) possono essere usate come soluzione di gestione delle chiavi di crittografia per i set di dati BigQuery. L'impostazione di una chiave di crittografia gestita dal cliente (CMEK) predefinita per un set di dati garantisce che tutte le tabelle create in futuro useranno il cmek specificato se non viene specificato alcun altro. Nota: Google non archivia le chiavi nei server e non può accedere ai dati protetti a meno che non fornisca la chiave. Ciò significa anche che, se si dimentica o si perde la chiave, non c'è modo per Google di recuperare la chiave o di recuperare i dati crittografati con la chiave persa.

Gravità: medio

Assicurarsi che tutte le tabelle BigQuery siano crittografate con la chiave di crittografia gestita dal cliente (CMEK)

Descrizione: Per impostazione predefinita, BigQuery crittografa i dati come inattivi usando Envelope Encryption usando chiavi di crittografia gestite da Google. I dati vengono crittografati usando le chiavi di crittografia dei dati e le chiavi di crittografia dei dati stessi vengono ulteriormente crittografati usando le chiavi di crittografia delle chiavi. Questo è facile e non richiede alcun input aggiuntivo dall'utente. Tuttavia, se si vuole avere un maggiore controllo, le chiavi di crittografia gestite dal cliente (CMEK) possono essere usate come soluzione di gestione delle chiavi di crittografia per i set di dati BigQuery. Se si usa CMEK, cmek viene usato per crittografare le chiavi di crittografia dei dati anziché usare chiavi di crittografia gestite da Google. Per impostazione predefinita, BigQuery crittografa i dati come inattivi usando Envelope Encryption usando chiavi di crittografia gestite da Google. Questo è facile e non richiede alcun input aggiuntivo dall'utente. Per un maggiore controllo sulla crittografia, le chiavi di crittografia gestite dal cliente (CMEK) possono essere usate come soluzione di gestione delle chiavi di crittografia per le tabelle BigQuery. Cmek viene usato per crittografare le chiavi di crittografia dei dati anziché usare chiavi di crittografia gestite da Google. BigQuery archivia la tabella e l'associazione CMEK e la crittografia/decrittografia viene eseguita automaticamente. L'applicazione delle chiavi gestite dal cliente predefinite nei set di dati BigQuery garantisce che tutte le nuove tabelle create in futuro verranno crittografate tramite CMEK, ma le tabelle esistenti devono essere aggiornate per usare singolarmente CMEK. Nota: Google non archivia le chiavi nei server e non può accedere ai dati protetti a meno che non fornisca la chiave. Ciò significa anche che, se si dimentica o si perde la chiave, non c'è modo per Google di recuperare la chiave o di recuperare i dati crittografati con la chiave persa.

Gravità: medio

Assicurarsi che i set di dati BigQuery non siano accessibili in modo anonimo o pubblico

Descrizione: è consigliabile che i criteri IAM nei set di dati BigQuery non consentano l'accesso anonimo e/o pubblico. La concessione delle autorizzazioni a allUsers o allAuthenticatedUsers consente a chiunque di accedere al set di dati. Tale accesso potrebbe non essere utile se i dati sensibili vengono archiviati nel set di dati. Assicurarsi pertanto che l'accesso anonimo e/o pubblico a un set di dati non sia consentito.

Gravità: alta

Assicurarsi che le istanze del database SQL cloud siano configurate con backup automatizzati

Descrizione: è consigliabile impostare tutte le istanze del database SQL per abilitare i backup automatici. I backup consentono di ripristinare un'istanza di Cloud SQL per ripristinare i dati persi o recuperare da un problema con tale istanza. I backup automatizzati devono essere impostati per qualsiasi istanza che contiene dati che devono essere protetti da perdite o danni. Questa raccomandazione è applicabile alle istanze di SQL Server, PostgreSql, MySql di prima generazione e MySql di seconda generazione.

Gravità: alta

Assicurarsi che le istanze del database SQL cloud non siano aperte al mondo

Descrizione: il server di database deve accettare connessioni solo da reti attendibili/IP e limitare l'accesso dal mondo. Per ridurre al minimo la superficie di attacco in un'istanza del server di database, è necessario approvare solo indirizzi IP attendibili/noti e necessari per la connessione. Una rete autorizzata non deve avere indirizzi IP/reti configurati su "0.0.0.0/0", che consentirà l'accesso all'istanza da qualsiasi parte del mondo. Si noti che le reti autorizzate si applicano solo alle istanze con indirizzi IP pubblici.

Gravità: alta

Assicurarsi che le istanze del database SQL cloud non abbiano indirizzi IP pubblici

Descrizione: è consigliabile configurare l'istanza sql di seconda generazione per usare indirizzi IP privati anziché indirizzi IP pubblici. Per ridurre la superficie di attacco dell'organizzazione, i database SQL cloud non devono avere indirizzi IP pubblici. Gli indirizzi IP privati offrono una maggiore sicurezza di rete e una latenza inferiore per l'applicazione.

Gravità: alta

Assicurarsi che il bucket Archiviazione cloud non sia accessibile in modo anonimo o pubblico

Descrizione: è consigliabile che i criteri IAM nel bucket cloud Archiviazione non consentano l'accesso anonimo o pubblico. Consentire l'accesso anonimo o pubblico concede autorizzazioni a chiunque acceda al contenuto del bucket. Questo accesso potrebbe non essere desiderato se si archiviano dati sensibili. Di conseguenza, assicurarsi che l'accesso anonimo o pubblico a un bucket non sia consentito.

Gravità: alta

Assicurarsi che i bucket di Archiviazione cloud dispongano dell'accesso uniforme a livello di bucket abilitato

Descrizione: è consigliabile abilitare l'accesso uniforme a livello di bucket nei bucket di Archiviazione cloud. È consigliabile usare l'accesso uniforme a livello di bucket per unificare e semplificare la modalità di concessione dell'accesso alle risorse cloud Archiviazione. Cloud Archiviazione offre due sistemi per concedere agli utenti l'autorizzazione per accedere ai bucket e agli oggetti: Cloud Identity and Access Management (Cloud IAM) e elenchi di Controllo di accesso (ACL).
Questi sistemi agiscono in parallelo: per consentire a un utente di accedere a una risorsa cloud Archiviazione, solo uno dei sistemi deve concedere all'utente l'autorizzazione. Cloud IAM viene usato in Google Cloud e consente di concedere un'ampia gamma di autorizzazioni a livello di bucket e progetto. Gli ACL vengono usati solo da Cloud Archiviazione e dispongono di opzioni di autorizzazione limitate, ma consentono di concedere autorizzazioni per ogni oggetto.

Per supportare un sistema di autorizzazione uniforme, Cloud Archiviazione ha accesso uniforme a livello di bucket. L'uso di questa funzionalità disabilita gli elenchi di controllo di accesso per tutte le risorse cloud Archiviazione: l'accesso alle risorse cloud Archiviazione viene quindi concesso esclusivamente tramite Cloud IAM. L'abilitazione dell'accesso uniforme a livello di bucket garantisce che, se un bucket Archiviazione non è accessibile pubblicamente, nessun oggetto nel bucket è accessibile pubblicamente.

Gravità: medio

Assicurarsi che le istanze di calcolo dispongano di Confidential Computing abilitato

Descrizione: Google Cloud crittografa i dati inattivi e in transito, ma i dati dei clienti devono essere decrittografati per l'elaborazione. Confidential Computing è una tecnologia rivoluzionaria che crittografa i dati in uso durante l'elaborazione. Gli ambienti confidential computing mantengono i dati crittografati in memoria e altrove all'esterno dell'unità di elaborazione centrale (CPU). Le macchine virtuali riservate sfruttano la funzionalità Secure Encrypted Virtualization (edizione Standard V) delle CPU AMD EPYC. I dati dei clienti rimarranno crittografati mentre vengono usati, indicizzati, sottoposti a query o sottoposti a training. Le chiavi di crittografia vengono generate in hardware, per macchina virtuale e non esportabili. Grazie alle ottimizzazioni hardware predefinite di prestazioni e sicurezza, non c'è alcuna riduzione significativa delle prestazioni per i carichi di lavoro Confidential Computing. Confidential Computing consente al codice sensibile dei clienti e ad altri dati crittografati in memoria durante l'elaborazione. Google non ha accesso alle chiavi di crittografia. La macchina virtuale riservata può aiutare ad alleviare le preoccupazioni relative al rischio correlato alla dipendenza dall'infrastruttura Google o all'accesso dei partecipanti al programma Google Insider ai dati dei clienti in modo chiaro.

Gravità: alta

Assicurarsi che i criteri di conservazione nei bucket di log siano configurati usando il blocco bucket

Descrizione: l'abilitazione dei criteri di conservazione nei bucket di log proteggerà i log archiviati nei bucket di archiviazione cloud da sovrascrivere o eliminare accidentalmente. È consigliabile configurare i criteri di conservazione e configurare il blocco bucket in tutti i bucket di archiviazione usati come sink di log. I log possono essere esportati creando uno o più sink che includono un filtro di log e una destinazione. Poiché la registrazione di Stackdriver riceve nuove voci di log, vengono confrontate con ogni sink. Se una voce di log corrisponde al filtro di un sink, viene scritta una copia della voce di log nella destinazione. I sink possono essere configurati per esportare i log nei bucket di archiviazione. È consigliabile configurare un criterio di conservazione dei dati per questi bucket di archiviazione cloud e bloccare i criteri di conservazione dei dati; impedendo così la riduzione o la rimozione dei criteri in modo permanente. In questo modo, se il sistema viene mai compromesso da un utente malintenzionato o da un utente malintenzionato che vuole coprire le loro tracce, i log attività vengono sicuramente conservati per indagini forensi e di sicurezza.

Gravità: Bassa

Assicurarsi che l'istanza del database SQL cloud richieda tutte le connessioni in ingresso per l'uso di SSL

Descrizione: è consigliabile applicare tutte le connessioni in ingresso all'istanza del database SQL per l'uso di SSL. Connessioni al database SQL se sono state intrappolate correttamente (MITM); può rivelare dati sensibili, ad esempio credenziali, query di database, output di query e così via. Per motivi di sicurezza, è consigliabile usare sempre la crittografia SSL per la connessione all'istanza. Questa raccomandazione è applicabile alle istanze di Postgresql, MySql di prima generazione e MySql di seconda generazione.

Gravità: alta

Assicurarsi che il flag di database "autenticazione del database indipendente" per Cloud SQL nell'istanza di SQL Server sia impostato su "off"

Descrizione: è consigliabile impostare il flag di database "autenticazione del database indipendente" per Cloud SQL nell'istanza di SQL Server è impostato su "off". Un database indipendente include tutte le impostazioni del database e i metadati necessari per definire il database e non ha dipendenze di configurazione dall'istanza del motore di database in cui è installato il database. Gli utenti possono connettersi al database senza eseguire l'autenticazione di un account di accesso al livello del motore di database. L'isolamento del database dal motore di database consente di spostare in modo semplice il database in un'altra istanza di SQL Server. I database indipendenti sono soggetti ad alcune minacce univoche che devono essere comprese e contrastate dagli amministratori del motore di database SQL Server. La maggior parte delle minacce è correlata al processo di autenticazione U edizione Standard R WITH PASSWORD, che sposta il limite di autenticazione dal livello di motore di database al livello di database, pertanto è consigliabile disabilitare questo flag. Questa raccomandazione è applicabile alle istanze di database di SQL Server.

Gravità: medio

Assicurarsi che il flag di database 'cross db ownership chaining' per l'istanza di SQL Server cloud sia impostato su 'off'

Descrizione: è consigliabile impostare il flag di database "cross db ownership chaining" per l'istanza di SQL Server cloud su "off". Usare l'opzione "cross db ownership" per il concatenamento per configurare il concatenamento della proprietà tra database per un'istanza di Microsoft SQL Server. Questa opzione del server consente di controllare il concatenamento della proprietà tra database a livello di database o di consentire il concatenamento della proprietà tra database per tutti i database. L'abilitazione della "proprietà tra database" non è consigliata a meno che tutti i database ospitati dall'istanza di SQL Server non debbano partecipare al concatenamento della proprietà tra database e non si siano a conoscenza delle implicazioni di sicurezza di questa impostazione. Questa raccomandazione è applicabile alle istanze di database di SQL Server.

Gravità: medio

Assicurarsi che il flag di database "local_infile" per un'istanza di Cloud SQL Mysql sia impostato su "off"

Descrizione: è consigliabile impostare il flag di database local_infile per un'istanza di Cloud SQL MySQL su off. Il flag local_infile controlla la funzionalità LOCAL lato server per le istruzioni LOAD DATA. A seconda dell'impostazione local_infile, il server rifiuta o consente il caricamento dei dati locali da parte dei client che dispongono di LOCAL abilitato sul lato client. Per fare in modo esplicito che il server rifiuti le istruzioni LOAD DATA LOCAL (indipendentemente dal modo in cui i programmi client e le librerie vengono configurati in fase di compilazione o runtime), avviare mysqld con local_infile disabilitato. local_infile possono essere impostati anche in fase di esecuzione. A causa di problemi di sicurezza associati al flag di local_infile, è consigliabile disabilitarlo. Questa raccomandazione è applicabile alle istanze del database MySQL.

Gravità: medio

Assicurarsi che il filtro delle metriche del log e gli avvisi esistano per le modifiche delle autorizzazioni IAM Archiviazione cloud

Descrizione: è consigliabile stabilire un filtro delle metriche e un allarme per le modifiche di IAM del bucket Archiviazione cloud. Il monitoraggio delle modifiche apportate alle autorizzazioni del bucket di archiviazione cloud potrebbe ridurre il tempo necessario per rilevare e correggere le autorizzazioni per bucket e oggetti di archiviazione cloud sensibili all'interno del bucket.

Gravità: Bassa

Assicurarsi che il filtro e gli avvisi delle metriche del log esistano per le modifiche alla configurazione dell'istanza di SQL

Descrizione: è consigliabile stabilire un filtro e un allarme delle metriche per le modifiche alla configurazione dell'istanza di SQL. Il monitoraggio delle modifiche apportate alle modifiche alla configurazione dell'istanza DI SQL potrebbe ridurre il tempo necessario per rilevare e correggere le configurazioni errate eseguite nel server SQL. Di seguito sono riportate alcune delle opzioni configurabili che potrebbero influire sul comportamento di sicurezza di un'istanza di SQL:

Abilitare i backup automatici e la disponibilità elevata: la configurazione errata potrebbe influire negativamente sulla continuità aziendale, il ripristino di emergenza e la disponibilità elevata
Autorizzare le reti: la configurazione errata potrebbe aumentare l'esposizione alle reti non attendibili

Gravità: Bassa

Assicurarsi che siano presenti solo chiavi dell'account del servizio gestito da GCP per ogni account del servizio

Descrizione: gli account del servizio gestito dall'utente non devono avere chiavi gestite dall'utente. Chiunque abbia accesso alle chiavi potrà accedere alle risorse tramite l'account del servizio. Le chiavi gestite da GCP vengono usate dai servizi della piattaforma cloud, ad esempio motore di app e motore di calcolo. Non è possibile scaricare queste chiavi. Google manterrà le chiavi e le ruota automaticamente su base settimanale. Le chiavi gestite dall'utente vengono create, scaricabili e gestite dagli utenti. Scadono 10 anni dalla creazione. Per le chiavi gestite dall'utente, l'utente deve assumere la proprietà delle attività di gestione delle chiavi, tra cui:

Archiviazione chiavi
Distribuzione delle chiavi
Revoca delle chiavi
Rotazione delle chiavi
Protezione delle chiavi da utenti non autorizzati
Recupero chiave

Anche con le precauzioni del proprietario delle chiavi, le chiavi possono essere facilmente perse da problemi di sviluppo comuni, ad esempio il controllo delle chiavi nel codice sorgente o l'abbandono nella directory Download o l'abbandono accidentale nei blog o nei canali di supporto. È consigliabile impedire le chiavi dell'account del servizio gestito dall'utente.

Gravità: Bassa

Verificare che il flag di database "connessioni utente" per l'istanza di SQL Server cloud sia impostato in base alle esigenze

Descrizione: è consigliabile impostare il flag di database "connessioni utente" per l'istanza di SQL Server cloud in base al valore definito dall'organizzazione. L'opzione "connessioni utente" specifica il numero massimo di connessioni utente simultanee consentite in un'istanza di SQL Server. Il numero effettivo di connessioni utente consentite dipende anche dalla versione di SQL Server in uso e anche dai limiti dell'applicazione o delle applicazioni e dell'hardware. SQL Server consente un massimo di 32.767 connessioni utente. Poiché le connessioni utente sono un'opzione dinamica (configurazione automatica), SQL Server regola automaticamente il numero massimo di connessioni utente in base alle esigenze, fino al valore massimo consentito. Se, ad esempio, sono connessi solo 10 utenti, vengono allocati 10 oggetti connessione utente. Nella maggior parte dei casi, non è necessario modificare il valore per questa opzione. Il valore predefinito è 0, che indica che è consentito il numero massimo di connessioni utente (32.767). Questa raccomandazione è applicabile alle istanze di database di SQL Server.

Gravità: Bassa

Verificare che il flag di database "opzioni utente" per l'istanza di SQL Server cloud non sia configurato

Descrizione: è consigliabile non configurare il flag di database "opzioni utente" per l'istanza di SQL Server cloud. L'opzione "opzioni utente" specifica le impostazioni predefinite globali per tutti gli utenti. Viene creato un elenco di opzioni predefinite per l'elaborazione delle query, che rimane valido per tutta la durata della sessione di lavoro dell'utente. L'opzione opzioni utente consente di modificare i valori predefiniti delle opzioni edizione Standard T (se le impostazioni predefinite del server non sono appropriate). Un utente può ottenere la priorità su tali impostazioni predefinite utilizzando l'istruzione SET. È possibile configurare dinamicamente user options per i nuovi account di accesso. Dopo aver modificato l'impostazione delle opzioni utente, le nuove sessioni di accesso usano la nuova impostazione; le sessioni di accesso correnti non sono interessate. Questa raccomandazione è applicabile alle istanze di database di SQL Server.

Gravità: Bassa

La registrazione per i cluster GKE deve essere abilitata

Descrizione: questa raccomandazione valuta se la proprietà loggingService di un cluster contiene il percorso Da usare Registrazione cloud per scrivere i log.

Gravità: alta

Il controllo delle versioni degli oggetti deve essere abilitato nei bucket di archiviazione in cui sono configurati i sink

Descrizione: questa raccomandazione valuta se il campo abilitato nella proprietà di controllo delle versioni del bucket è impostato su true.

Gravità: alta

Le identità con provisioning eccessivo nei progetti devono essere analizzate per ridurre l'indice di scorrimento delle autorizzazioni (PCI)

Descrizione: le identità con provisioning eccessivo nei progetti devono essere analizzate per ridurre l'indice di tipo permission creep (PCI) e per proteggere l'infrastruttura. Ridurre pci rimuovendo le assegnazioni di autorizzazioni ad alto rischio inutilizzate. Pci elevato riflette il rischio associato alle identità con autorizzazioni che superano l'utilizzo normale o richiesto.

Gravità: medio

I progetti con chiavi crittografiche non devono avere utenti con autorizzazioni di proprietario

Descrizione: questa raccomandazione valuta i criteri di autorizzazione IAM nei metadati del progetto per i ruoli assegnati/proprietario delle entità.

Gravità: medio

Archiviazione bucket usati come sink di log non devono essere accessibili pubblicamente

Descrizione: questa raccomandazione valuta i criteri IAM di un bucket per le entità allUsers o allAuthenticatedUsers, che concedono l'accesso pubblico.

Gravità: alta

Raccomandazioni su GCP IdentityAndAccess

Le chiavi crittografiche non devono avere più di tre utenti

Descrizione: questa raccomandazione valuta i criteri IAM per gli anelli chiave, progetti e organizzazioni e recupera le entità con ruoli che consentono loro di crittografare, decrittografare o firmare i dati usando chiavi cloud Servizio di gestione delle chiavi: ruoli/proprietario, ruoli/cloudkms.cryptoKeyEncrypterDecrypter, ruoli/cloudkms.cryptoKeyEncrypter, ruoli/cloudkms.cryptoKeyDecrypter, ruoli/cloudkms.signer e ruoli/cloudkms.signerVerifier.

Gravità: medio

Verificare che le chiavi API non vengano create per un progetto

Descrizione: le chiavi non sono sicure perché possono essere visualizzate pubblicamente, ad esempio dall'interno di un browser o accessibili in un dispositivo in cui risiede la chiave. È consigliabile usare invece il flusso di autenticazione standard.

Di seguito sono riportati i rischi per la sicurezza coinvolti nell'uso delle chiavi API:

Le chiavi API sono stringhe crittografate semplici
Le chiavi API non identificano l'utente o l'applicazione che effettua la richiesta API
Le chiavi API sono in genere accessibili ai client, semplificando l'individuazione e il furto di una chiave API

Per evitare il rischio di sicurezza nell'uso delle chiavi API, è consigliabile usare invece il flusso di autenticazione standard.

Gravità: alta

Assicurarsi che le chiavi API siano limitate solo alle API necessarie per l'accesso all'applicazione

Descrizione: le chiavi API non sono sicure perché possono essere visualizzate pubblicamente, ad esempio dall'interno di un browser o accessibili in un dispositivo in cui risiede la chiave. È consigliabile limitare le chiavi API per usare (chiamare) solo le API richieste da un'applicazione.

Di seguito sono riportati i rischi per la sicurezza coinvolti nell'uso delle chiavi API:

Le chiavi API sono stringhe crittografate semplici
Le chiavi API non identificano l'utente o l'applicazione che effettua la richiesta API
Le chiavi API sono in genere accessibili ai client, semplificando l'individuazione e il furto di una chiave API

Alla luce di questi potenziali rischi, Google consiglia di usare il flusso di autenticazione standard anziché le chiavi API. Esistono tuttavia casi limitati in cui le chiavi API sono più appropriate. Ad esempio, se è presente un'applicazione per dispositivi mobili che deve usare l'API Google Cloud Translation, ma non ha bisogno di un server back-end, le chiavi API sono il modo più semplice per eseguire l'autenticazione a tale API.

Per ridurre le superfici di attacco fornendo privilegi minimi, le chiavi API possono essere limitate all'uso (chiamata) solo delle API richieste da un'applicazione.

Gravità: alta

Assicurarsi che le chiavi API siano limitate all'uso solo da host e app specificati

Descrizione: le chiavi senza restrizioni non sono sicure perché possono essere visualizzate pubblicamente, ad esempio dall'interno di un browser o accessibili in un dispositivo in cui risiede la chiave. È consigliabile limitare l'utilizzo delle chiavi API a host attendibili, referrer HTTP e app.

Di seguito sono riportati i rischi per la sicurezza coinvolti nell'uso delle chiavi API:

Le chiavi API sono stringhe crittografate semplici
Le chiavi API non identificano l'utente o l'applicazione che effettua la richiesta API
Le chiavi API sono in genere accessibili ai client, semplificando l'individuazione e il furto di una chiave API

Per ridurre i vettori di attacco, le chiavi API possono essere limitate solo a host attendibili, referrer HTTP e applicazioni.

Gravità: alta

Verificare che le chiavi API vengano ruotate ogni 90 giorni

Descrizione: è consigliabile ruotare le chiavi API ogni 90 giorni.

Di seguito sono elencati i rischi per la sicurezza coinvolti nell'uso delle chiavi API:

Le chiavi API sono stringhe crittografate semplici
Le chiavi API non identificano l'utente o l'applicazione che effettua la richiesta API
Le chiavi API sono in genere accessibili ai client, semplificando l'individuazione e il furto di una chiave API

A causa di questi potenziali rischi, Google consiglia di usare il flusso di autenticazione standard anziché le chiavi API. Esistono tuttavia casi limitati in cui le chiavi API sono più appropriate. Ad esempio, se è presente un'applicazione per dispositivi mobili che deve usare l'API Google Cloud Translation, ma non ha bisogno di un server back-end, le chiavi API sono il modo più semplice per eseguire l'autenticazione a tale API.

Una volta rubata una chiave, non ha scadenza, ovvero può essere usata per un periodo illimitato, a meno che il proprietario del progetto non revoca o rigenera la chiave. La rotazione delle chiavi API ridurrà la finestra di opportunità per l'uso di una chiave di accesso associata a un account compromesso o terminato.

Le chiavi API devono essere ruotate per garantire che non sia possibile accedere ai dati con una chiave precedente che potrebbe essere stata persa, interrotta o rubata.

Gravità: alta

Assicurarsi che Servizio di gestione delle chiavi chiavi di crittografia vengano ruotate entro un periodo di 90 giorni

Descrizione: Google Cloud Servizio di gestione delle chiavi archivia le chiavi crittografiche in una struttura gerarchica progettata per una gestione utile ed elegante del controllo di accesso. Il formato per la pianificazione della rotazione dipende dalla libreria client usata. Per lo strumento da riga di comando gcloud, il tempo di rotazione successivo deve essere in formato "ISO" o "RFC3339" e il periodo di rotazione deve essere nel formato "INTEGER[UNIT]", dove le unità possono essere uno dei secondi (s), minuti (m), ore (h) o giorni (d). Impostare un periodo di rotazione delle chiavi e l'ora di inizio. È possibile creare una chiave con un "periodo di rotazione" specificato, ovvero il tempo tra il momento in cui vengono generate automaticamente nuove versioni chiave. È anche possibile creare una chiave con un'ora di rotazione successiva specificata. Una chiave è un oggetto denominato che rappresenta una "chiave crittografica" usata per uno scopo specifico. Il materiale della chiave, i bit effettivi usati per la "crittografia", possono cambiare nel tempo man mano che vengono create nuove versioni delle chiavi. Una chiave viene usata per proteggere un "corpus di dati". Una raccolta di file potrebbe essere crittografata con la stessa chiave e le persone con autorizzazioni di "decrittografia" per tale chiave sarebbero in grado di decrittografare tali file. Pertanto, è necessario assicurarsi che il "periodo di rotazione" sia impostato su un orario specifico.

Gravità: medio

Verificare che esistano avvisi e filtri delle metriche dei log per le assegnazioni/modifiche della proprietà del progetto

Descrizione: per evitare assegnazioni di proprietà del progetto non necessarie a utenti/account di servizio e altri usi impropri di progetti e risorse, è necessario monitorare tutte le assegnazioni di "ruoli/proprietario". I membri (users/Service-Accounts) con un'assegnazione di ruolo al ruolo primitivo "roles/Owner" sono proprietari del progetto. Il proprietario del progetto dispone di tutti i privilegi per il progetto a cui appartiene il ruolo. Di seguito sono riepilogati:

Tutte le autorizzazioni del visualizzatore per tutti i servizi GCP all'interno del progetto
Autorizzazioni per le azioni che modificano lo stato di tutti i servizi GCP all'interno del progetto
Gestire ruoli e autorizzazioni per un progetto e tutte le risorse all'interno del progetto
Configurare la fatturazione per un progetto La concessione del ruolo proprietario a un membro (utente/account del servizio) consentirà a tale membro di modificare i criteri di Gestione identità e accesso (IAM). Concedere quindi il ruolo proprietario solo se il membro ha uno scopo legittimo per gestire i criteri IAM. Questo perché il criterio IAM del progetto contiene dati di controllo di accesso sensibili. Avere un set minimo di utenti autorizzati a gestire i criteri IAM semplifica il controllo che potrebbe essere necessario. La proprietà del progetto ha il massimo livello di privilegi per un progetto. Per evitare l'uso improprio delle risorse del progetto, è consigliabile monitorare e avvisare i destinatari interessati per le azioni di proprietà o modifica indicate in precedenza.
Invio di inviti di proprietà del progetto
Accettazione/rifiuto dell'invito di proprietà del progetto da parte dell'utente
Aggiunta role\Owner a un account utente/servizio
Rimozione di un account utente/servizio da role\Owner

Gravità: Bassa

Assicurarsi che oslogin sia abilitato per un progetto

Descrizione: l'abilitazione dell'accesso del sistema operativo associa i certificati SSH agli utenti IAM e facilita la gestione efficace dei certificati SSH. L'abilitazione di osLogin garantisce che le chiavi SSH usate per connettersi alle istanze vengano mappate agli utenti IAM. La revoca dell'accesso all'utente IAM revoca tutte le chiavi SSH associate a tale utente specifico. Facilita la gestione centralizzata e automatizzata della coppia di chiavi SSH, utile nella gestione di casi come la risposta alle coppie di chiavi SSH compromesse e/o alla revoca di utenti esterni/di terze parti/fornitori. Per scoprire quale istanza fa sì che il progetto non sia integro, vedere la raccomandazione "Assicurarsi che oslogin sia abilitato per tutte le istanze".

Gravità: medio

Assicurarsi che oslogin sia abilitato per tutte le istanze

Gravità: medio

Assicurarsi che la registrazione di controllo cloud sia configurata correttamente in tutti i servizi e tutti gli utenti di un progetto

Descrizione: è consigliabile configurare La registrazione di controllo cloud per tenere traccia di tutte le attività di amministrazione e l'accesso in lettura e scrittura ai dati utente.

La registrazione di controllo cloud gestisce due log di controllo per ogni progetto, cartella e organizzazione: Amministrazione l'attività e l'accesso ai dati.

Amministrazione i log attività contengono voci di log per le chiamate API o altre azioni amministrative che modificano la configurazione o i metadati delle risorse. Amministrazione i log di controllo attività sono abilitati per tutti i servizi e non possono essere configurati.
I log di controllo di Accesso ai dati registrano chiamate API che creano, modificano o leggono i dati forniti dall'utente. Questi sono disabilitati per impostazione predefinita e devono essere abilitati. Esistono tre tipi di informazioni sul log di controllo di accesso ai dati:

Amministrazione lettura: registra le operazioni che leggono i metadati o le informazioni di configurazione. Amministrazione i log di controllo attività registrano scritture di metadati e informazioni di configurazione che non possono essere disabilitate.
Dati letti: registra le operazioni che leggono i dati forniti dall'utente.
Scrittura dati: registra operazioni che scrivono dati forniti dall'utente.

È consigliabile configurare una configurazione di controllo predefinita efficace in modo che:

logtype è impostato su DATA_READ (per registrare il rilevamento delle attività dell'utente) e DATA_WRITES (per registrare modifiche/manomissioni ai dati utente).
la configurazione di controllo è abilitata per tutti i servizi supportati dalla funzionalità Log di controllo di accesso ai dati.
I log devono essere acquisiti per tutti gli utenti, ovvero non esistono utenti esenti nelle sezioni di configurazione del controllo. Ciò garantisce che l'override della configurazione di controllo non sia in contrasto con il requisito.

Gravità: medio

Assicurarsi che le chiavi di crittografia Servizio di gestione delle chiavi cloud non siano accessibili in modo anonimo o pubblico

Descrizione: è consigliabile che i criteri IAM in Cloud Servizio di gestione delle chiavi "cryptokeys" debbano limitare l'accesso anonimo e/o pubblico. La concessione delle autorizzazioni a "allUsers" o "allAuthenticatedUsers" consente a chiunque di accedere al set di dati. Tale accesso potrebbe non essere utile se i dati sensibili vengono archiviati nella posizione. In questo caso, assicurarsi che l'accesso anonimo e/o pubblico a un cloud Servizio di gestione delle chiavi "cryptokey" non sia consentito.

Gravità: alta

Descrizione: usare le credenziali di accesso aziendale anziché gli account personali, ad esempio gli account Gmail. È consigliabile usare account Google aziendali completamente gestiti per aumentare la visibilità, il controllo e il controllo dell'accesso alle risorse della piattaforma cloud. Gli account Gmail basati all'esterno dell'organizzazione dell'utente, ad esempio gli account personali, non devono essere usati per scopi aziendali.

Gravità: alta

Assicurarsi che agli utenti IAM non siano assegnati i ruoli Utente account del servizio o Creatore di token dell'account del servizio a livello di progetto

Descrizione: è consigliabile assegnare i ruoli "Account del servizio (iam.serviceAccountUser)" e "Service Account Token Creator (iam.serviceAccountTokenCreator)" a un utente per un account di servizio specifico anziché assegnare il ruolo a un utente a livello di progetto. Un account del servizio è un account Google speciale che appartiene a un'applicazione o a una macchina virtuale anziché a un singolo utente finale. Application/VM-Instance usa l'account del servizio per chiamare l'API Google del servizio in modo che gli utenti non siano direttamente coinvolti. Oltre a essere un'identità, un account del servizio è una risorsa con criteri IAM associati. Questi criteri determinano chi può usare l'account del servizio. Gli utenti con ruoli IAM per aggiornare le istanze del motore di calcolo e del motore di calcolo ,ad esempio Il motore di distribuzione del motore di app o l'istanza di calcolo Amministrazione, possono eseguire il codice come account del servizio usati per eseguire queste istanze e ottenere indirettamente l'accesso a tutte le risorse a cui gli account del servizio hanno accesso. Analogamente, l'accesso SSH a un'istanza del motore di calcolo può anche offrire la possibilità di eseguire codice come account di istanza/servizio. In base alle esigenze aziendali, potrebbero essere configurati più account del servizio gestiti dall'utente per un progetto. La concessione dei ruoli "iam.serviceAccountUser" o "iam.serviceAserviceAccountTokenCreatorccountUser" a un utente di un progetto consente all'utente di accedere a tutti gli account di servizio nel progetto, inclusi gli account del servizio che potrebbero essere creati in futuro. Ciò può comportare l'elevazione dei privilegi usando gli account del servizio e le corrispondenti "istanze del motore di calcolo". Per implementare le procedure consigliate per i "privilegi minimi", agli utenti IAM non devono essere assegnati i ruoli "Utente account del servizio" o "Autore token account del servizio" a livello di progetto. Questi ruoli devono invece essere assegnati a un utente per un account di servizio specifico, concedendo all'utente l'accesso all'account del servizio. L'utente "Account del servizio" consente a un utente di associare un account del servizio a un servizio di processo a esecuzione prolungata, mentre il ruolo "Autore token dell'account del servizio" consente a un utente di rappresentare direttamente (o asserire) l'identità di un account del servizio.

Gravità: medio

Descrizione: è consigliabile applicare il principio "Separazione dei compiti" durante l'assegnazione di Servizio di gestione delle chiavi ruoli correlati agli utenti. Il ruolo IAM predefinito o predefinito "Cloud Servizio di gestione delle chiavi Amministrazione" consente all'utente/identità di creare, eliminare e gestire gli account del servizio. Il ruolo IAM predefinito/predefinito "Cloud Servizio di gestione delle chiavi CryptoKey Encrypter/Decrypter" consente all'utente/identità (con privilegi adeguati per le risorse interessate) di crittografare e decrittografare i dati inattivi usando una o più chiavi di crittografia. Il ruolo IAM predefinito/predefinito Cloud Servizio di gestione delle chiavi CryptoKey Encrypter consente all'utente/identità (con privilegi adeguati per le risorse interessate) di crittografare i dati inattivi usando una o più chiavi di crittografia. Il ruolo IAM predefinito/predefinito "Cloud Servizio di gestione delle chiavi CryptoKey Decrypter" consente all'utente/identità (con privilegi adeguati per le risorse interessate) di decrittografare i dati inattivi usando una o più chiavi di crittografia. La separazione dei compiti è il concetto di garantire che un individuo non disponga di tutte le autorizzazioni necessarie per poter completare un'azione dannosa. In Cloud Servizio di gestione delle chiavi potrebbe trattarsi di un'azione come l'uso di una chiave per accedere e decrittografare i dati a cui un utente normalmente non deve avere accesso. La separazione dei compiti è un controllo aziendale usato in genere in organizzazioni di grandi dimensioni, progettato per evitare incidenti ed errori di sicurezza o privacy. È considerata una procedura consigliata. Nessun utente deve avere Cloud Servizio di gestione delle chiavi Amministrazione e uno dei "Cloud Servizio di gestione delle chiavi CryptoKey Encrypter/Decrypter", "Cloud Servizio di gestione delle chiavi CryptoKey Encrypter", "Cloud Servizio di gestione delle chiavi CryptoKey Encrypter", "Cloud Servizio di gestione delle chiavi CryptoKey Decrypter" ruoli assegnati contemporaneamente.

Gravità: alta

Descrizione: è consigliabile applicare il principio "Separazione dei compiti" durante l'assegnazione di ruoli correlati all'account del servizio agli utenti. Il ruolo IAM predefinito o predefinito "Amministratore account del servizio" consente all'utente/identità di creare, eliminare e gestire gli account del servizio. Il ruolo IAM predefinito o predefinito "Utente account del servizio" consente all'utente/identità (con privilegi adeguati per calcolo e motore di app) di assegnare account di servizio alle app/istanze di calcolo. La separazione dei compiti è il concetto di garantire che un individuo non disponga di tutte le autorizzazioni necessarie per poter completare un'azione dannosa. In Cloud IAM - Account del servizio potrebbe trattarsi di un'azione come l'uso di un account del servizio per accedere alle risorse a cui l'utente normalmente non deve avere accesso. La separazione dei compiti è un controllo aziendale usato in genere in organizzazioni di grandi dimensioni, progettato per evitare incidenti ed errori di sicurezza o privacy. È considerata una procedura consigliata. Nessun utente deve avere ruoli "Account del servizio Amministrazione" e "Utente account del servizio" assegnati contemporaneamente.

Gravità: medio

Assicurarsi che l'account del servizio non abbia privilegi di Amministrazione

Descrizione: un account del servizio è un account Google speciale che appartiene a un'applicazione o a una macchina virtuale, anziché a un singolo utente finale. L'applicazione usa l'account del servizio per chiamare l'API Google del servizio in modo che gli utenti non siano direttamente coinvolti. È consigliabile non usare l'accesso amministratore per ServiceAccount. Gli account di servizio rappresentano la sicurezza a livello di servizio delle risorse (applicazione o macchina virtuale) che possono essere determinate dai ruoli assegnati. La registrazione di ServiceAccount con diritti di Amministrazione consente l'accesso completo a un'applicazione assegnata o a una macchina virtuale. Un titolare dell'accesso ServiceAccount può eseguire azioni critiche, ad esempio eliminare, aggiornare le impostazioni e così via senza l'intervento dell'utente. Per questo motivo, è consigliabile che gli account del servizio non abbiano diritti di Amministrazione.

Gravità: medio

Assicurarsi che i sink siano configurati per tutte le voci di log

Descrizione: è consigliabile creare un sink che esportare copie di tutte le voci di log. Ciò consente di aggregare i log da più progetti ed esportarli in un siem (Security Information and Event Management). Le voci di log vengono mantenute nella registrazione di Stackdriver. Per aggregare i log, esportarli in un sistema SIEM. Per mantenerli più a lungo, è consigliabile configurare un sink di log. L'esportazione comporta la scrittura di un filtro che seleziona le voci di log da esportare e la scelta di una destinazione in Cloud Archiviazione, BigQuery o Cloud Pub/Sub. Il filtro e la destinazione vengono mantenuti in un oggetto denominato sink. Per assicurarsi che tutte le voci di log vengano esportate in sink, assicurarsi che non sia configurato alcun filtro per un sink. I sink possono essere creati in progetti, organizzazioni, cartelle e account di fatturazione.

Gravità: Bassa

Assicurarsi che il filtro e gli avvisi delle metriche del log esistano per le modifiche alla configurazione di controllo

Descrizione: i servizi Google Cloud Platform (GCP) scrivono voci del log di controllo nei log di accesso alle attività e ai dati di Amministrazione per rispondere alle domande di "chi ha fatto, dove e quando?" all'interno dei progetti GCP. Le informazioni sui record di registrazione controllo cloud includono l'identità del chiamante API, l'ora della chiamata API, l'indirizzo IP di origine del chiamante API, i parametri della richiesta e gli elementi di risposta restituiti dai servizi GCP. La registrazione di controllo cloud fornisce una cronologia delle chiamate API GCP per un account, incluse le chiamate API effettuate tramite la console, gli SDK, gli strumenti da riga di comando e altri servizi GCP. Amministrazione log di accesso alle attività e ai dati prodotti dalla registrazione di controllo cloud consentono l'analisi della sicurezza, il rilevamento delle modifiche delle risorse e il controllo della conformità. La configurazione del filtro delle metriche e degli avvisi per le modifiche alla configurazione del controllo garantisce che lo stato consigliato della configurazione di controllo venga mantenuto in modo che tutte le attività del progetto siano in grado di essere controllate in qualsiasi momento.

Gravità: Bassa

Assicurarsi che il filtro e gli avvisi delle metriche del log esistano per le modifiche al ruolo personalizzato

Descrizione: è consigliabile stabilire un filtro delle metriche e un allarme per le modifiche apportate alla creazione, all'eliminazione e all'aggiornamento dei ruoli di gestione delle identità e degli accessi . Google Cloud IAM fornisce ruoli predefiniti che consentono l'accesso granulare a risorse specifiche di Google Cloud Platform e impediscono l'accesso indesiderato ad altre risorse. Tuttavia, per soddisfare le esigenze specifiche dell'organizzazione, Cloud IAM offre anche la possibilità di creare ruoli personalizzati. I proprietari e gli amministratori del progetto con ruolo organizzazione Amministrazione istrator o ruolo IAM Amministrazione istrator possono creare ruoli personalizzati. Il monitoraggio delle attività di creazione, eliminazione e aggiornamento dei ruoli consente di identificare qualsiasi ruolo con privilegi elevati nelle prime fasi.

Gravità: Bassa

Verificare che le chiavi gestite dall'utente o esterne per gli account del servizio vengano ruotate ogni 90 giorni o meno

Descrizione: le chiavi dell'account di servizio sono costituite da un ID chiave (Private_key_Id) e una chiave privata, che vengono usati per firmare le richieste a livello di codice che gli utenti effettuano ai servizi cloud Google accessibili a tale account del servizio specifico. È consigliabile ruotare regolarmente tutte le chiavi dell'account del servizio. La rotazione delle chiavi dell'account del servizio ridurrà la finestra di opportunità per l'uso di una chiave di accesso associata a un account compromesso o terminato. Le chiavi dell'account del servizio devono essere ruotate per garantire che non sia possibile accedere ai dati con una chiave precedente che potrebbe essere stata persa, interrotta o rubata. Ogni account del servizio è associato a una coppia di chiavi gestita da Google Cloud Platform (GCP). Viene usato per l'autenticazione da servizio a servizio all'interno di GCP. Google ruota le chiavi ogni giorno. GCP offre la possibilità di creare una o più coppie di chiavi gestite dall'utente (dette anche coppie di chiavi esterne) da usare dall'esterno di GCP (ad esempio, per l'uso con le credenziali predefinite dell'applicazione). Quando viene creata una nuova coppia di chiavi, l'utente deve scaricare la chiave privata (che non viene mantenuta da Google).

Con le chiavi esterne, gli utenti sono responsabili della sicurezza della chiave privata e di altre operazioni di gestione, ad esempio la rotazione delle chiavi. Le chiavi esterne possono essere gestite dall'API IAM, dallo strumento da riga di comando gcloud o dalla pagina Account del servizio in Google Cloud Platform Console.

GCP facilita fino a 10 chiavi dell'account del servizio esterno per ogni account del servizio per facilitare la rotazione delle chiavi.

Gravità: medio

Il dashboard Web GKE deve essere disabilitato

Descrizione: questa raccomandazione valuta il campo kubernetesDashboard della proprietà addonsConfig per la coppia chiave-valore, 'disabled': false.

Gravità: alta

L'autorizzazione legacy deve essere disabilitata nei cluster GKE

Descrizione: questa raccomandazione valuta la proprietà legacyAbac di un cluster per la coppia chiave-valore, 'enabled': true.

Gravità: alta

Il ruolo IAM redis non deve essere assegnato a livello di organizzazione o cartella

Descrizione: questa raccomandazione valuta i criteri di autorizzazione IAM nei metadati delle risorse per i ruoli assegnati/redis.admin, roles/redis.editor, roles/redis.viewer a livello di organizzazione o cartella.

Gravità: alta

Gli account del servizio devono avere accesso limitato ai progetti in un cluster

Descrizione: questa raccomandazione valuta la proprietà config di un pool di nodi per verificare se non è specificato alcun account di servizio o se viene usato l'account del servizio predefinito.

Gravità: alta

Gli utenti devono avere accesso con privilegi minimi con ruoli IAM granulari

Descrizione: questa raccomandazione valuta i criteri IAM nei metadati delle risorse per qualsiasi entità assegnata ruoli/proprietario, ruoli/writer o ruoli/lettore.

Gravità: alta

Le identità con privilegi avanzati nell'ambiente GCP devono essere rimosse (anteprima)

Descrizione: un'identità con privilegi avanzati ha un potente set di autorizzazioni. Gli amministratori con privilegi avanzati sono identità umane o del carico di lavoro che hanno accesso a tutte le autorizzazioni e a tutte le risorse. Possono creare e modificare le impostazioni di configurazione in un servizio, aggiungere o rimuovere identità e accedere o persino eliminare i dati. Non monitorate, queste identità presentano un rischio significativo di uso improprio delle autorizzazioni in caso di violazione.

Gravità: alta

Le identità inutilizzate nell'ambiente GCP devono essere rimosse (anteprima)

Descrizione: è fondamentale identificare le identità inutilizzate in quanto rappresentano rischi significativi per la sicurezza. Queste identità spesso comportano procedure non valide, ad esempio autorizzazioni eccessive e chiavi non gestite che lasciano le organizzazioni aperte all'uso improprio o allo sfruttamento delle credenziali e aumenta la superficie di attacco della risorsa. Le identità inattive sono entità umane e non umane che non hanno eseguito alcuna azione su alcuna risorsa negli ultimi 90 giorni. Le chiavi dell'account del servizio possono diventare un rischio per la sicurezza se non vengono gestite attentamente.

Gravità: medio

Le identità con provisioning eccessivo di GCP devono avere solo le autorizzazioni necessarie (anteprima)

Descrizione: un'identità attiva con provisioning eccessivo è un'identità con accesso ai privilegi non usati. Le identità attive con provisioning eccessivo, soprattutto per gli account non umani che hanno azioni e responsabilità molto definite, possono aumentare il raggio di esplosione in caso di compromissione di un utente, di una chiave o di una risorsa. Il principio dei privilegi minimi indica che una risorsa deve avere accesso solo alle risorse esatte necessarie per funzionare. Questo principio è stato sviluppato per affrontare il rischio di identità compromesse concedendo a un utente malintenzionato l'accesso a un'ampia gamma di risorse.

Gravità: medio

Raccomandazioni sulla rete GCP

Gli host del cluster devono essere configurati in modo da usare solo indirizzi IP privati e interni per accedere alle API Google

Descrizione: questa raccomandazione valuta se la proprietà privateIpGoogleAccess di una sottorete è impostata su false.

Gravità: alta

Le istanze di calcolo devono usare un servizio di bilanciamento del carico configurato per l'uso di un proxy HTTPS di destinazione

Descrizione: questa raccomandazione valuta se la proprietà selfLink della risorsa targetHttpProxy corrisponde all'attributo di destinazione nella regola di inoltro e se la regola di inoltro contiene un campo loadBalancingScheme impostato su Esterno.

Gravità: medio

Le reti autorizzate del piano di controllo devono essere abilitate nei cluster GKE

Descrizione: questa raccomandazione valuta la proprietà masterAuthorizedNetworksConfig di un cluster per la coppia chiave-valore, 'enabled': false.

Gravità: alta

La regola di negazione in uscita deve essere impostata su un firewall per bloccare il traffico in uscita indesiderato

Descrizione: questa raccomandazione valuta se la proprietà destinationRanges nel firewall è impostata su 0.0.0.0/0 e la proprietà negata contiene la coppia chiave-valore, 'IPProtocol': 'all'.

Gravità: Bassa

Verificare che le regole del firewall per le istanze dietro il proxy IAP (Identity Aware Proxy) consentano solo il traffico proveniente da Google Cloud Loadbalancer (GCLB) Health Check and Proxy Addresses (GCLB)

Descrizione: l'accesso alle macchine virtuali deve essere limitato dalle regole del firewall che consentono solo il traffico IAP assicurando che siano consentite solo le connessioni proxy tramite IAP. Per garantire che anche il bilanciamento del carico funzioni correttamente, è consigliabile consentire i controlli di integrità. IAP garantisce che l'accesso alle macchine virtuali sia controllato tramite l'autenticazione delle richieste in ingresso. Tuttavia, se la macchina virtuale è ancora accessibile da indirizzi IP diversi dall'IAP, potrebbe comunque essere possibile inviare richieste non autenticate all'istanza. È necessario prestare attenzione per assicurarsi che i controlli di integrità di loadblancer non vengano bloccati perché il servizio di bilanciamento del carico non conosce correttamente l'integrità della macchina virtuale e il bilanciamento del carico correttamente.

Gravità: medio

Verificare che le reti legacy non esistano per un progetto

Descrizione: per impedire l'uso di reti legacy, un progetto non deve avere una rete legacy configurata. Le reti legacy hanno un singolo intervallo di prefissi IPv4 di rete e un singolo indirizzo IP del gateway per l'intera rete. La rete è globale nell'ambito e si estende su tutte le aree cloud. Non è possibile creare subnet in una rete legacy e non è possibile passare da reti legacy a reti subnet personalizzate o auto. Le reti legacy possono avere un impatto sui progetti di traffico di rete elevato e sono soggette a un singolo punto di contesa o errore.

Gravità: medio

Assicurarsi che il flag di database "log_hostname" per l'istanza di Cloud SQL PostgreSQL sia impostato in modo appropriato

Descrizione: PostgreSQL registra solo l'indirizzo IP degli host di connessione. Il flag "log_hostname" controlla la registrazione di "nomi host" oltre agli indirizzi IP registrati. Il successo delle prestazioni dipende dalla configurazione dell'ambiente e dalla configurazione della risoluzione dei nomi host. Questo parametro può essere impostato solo nel file "postgresql.conf" o nella riga di comando del server. La registrazione dei nomi host può comportare un sovraccarico sulle prestazioni del server in quanto per ogni istruzione registrata, la risoluzione DNS sarà necessaria per convertire l'indirizzo IP in nome host. A seconda dell'installazione, questo potrebbe non essere trascurabile. Inoltre, gli indirizzi IP registrati possono essere risolti nei nomi DNS in un secondo momento quando si esaminano i log esclusi i casi in cui vengono usati nomi host dinamici. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: Bassa

Assicurarsi che nessun servizio di bilanciamento del carico proxy HTTPS o SSL consenta i criteri SSL con pacchetti di crittografia deboli

Descrizione: i criteri SSL (Secure Sockets Layer) determinano quali client delle funzionalità tls (Transport Layer Security) delle porte possono usare durante la connessione ai servizi di bilanciamento del carico. Per evitare l'utilizzo di funzionalità non sicure, i criteri SSL devono usare (a) almeno TLS 1.2 con il profilo MODERN; o (b) il profilo CON RESTRIZIONI, perché richiede effettivamente ai client di usare TLS 1.2 indipendentemente dalla versione minima di TLS scelta; o (3) un profilo PERSONALIZZATO che non supporta alcuna delle funzionalità seguenti: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA

I servizi di bilanciamento del carico vengono usati per distribuire in modo efficiente il traffico tra più server. I servizi di bilanciamento del carico SSL e HTTPS sono servizi di bilanciamento del carico esterni, ovvero distribuiscono il traffico da Internet a una rete GCP. I clienti GCP possono configurare i criteri SSL del servizio di bilanciamento del carico con una versione minima di TLS (1.0, 1.1 o 1.2) che i client possono usare per stabilire una connessione, insieme a un profilo (compatibile, moderno, con restrizioni o personalizzato) che specifica pacchetti di crittografia consentiti. Per garantire la conformità agli utenti che usano protocolli obsoleti, i servizi di bilanciamento del carico GCP possono essere configurati per consentire pacchetti di crittografia non sicuri. Infatti, il criterio SSL predefinito GCP usa una versione minima tls 1.0 e un profilo compatibile, che consente la gamma più ampia di suite di crittografia non sicure. Di conseguenza, è facile per i clienti configurare un servizio di bilanciamento del carico senza nemmeno sapere che stanno consentendo suite di crittografia obsolete.

Gravità: medio

Assicurarsi che la registrazione DNS cloud sia abilitata per tutte le reti VPC

Descrizione: la registrazione DNS cloud registra le query dai server dei nomi all'interno del VPC a Stackdriver. Le query registrate possono provenire da macchine virtuali del motore di calcolo, contenitori GKE o altre risorse GCP di cui è stato effettuato il provisioning all'interno del VPC. Il monitoraggio della sicurezza e le analisi forensi non possono dipendere esclusivamente dagli indirizzi IP dai log dei flussi VPC, soprattutto quando si considera l'utilizzo di ip dinamico delle risorse cloud, il routing dell'host virtuale HTTP e altre tecnologie che possono nascondere il nome DNS usato da un client dall'indirizzo IP. Il monitoraggio dei log DNS cloud offre visibilità sui nomi DNS richiesti dai client all'interno del VPC. Questi log possono essere monitorati per i nomi di dominio anomali, valutati in base all'intelligence sulle minacce e Nota: per l'acquisizione completa del DNS, il firewall deve bloccare l'uscita UDP/53 (DNS) e TCP/443 (DNS su HTTPS) per impedire al client di usare il server dei nomi DNS esterno per la risoluzione.

Gravità: alta

Assicurarsi che DNS edizione Standard C sia abilitato per IL DNS cloud

Descrizione: Cloud Domain Name System (DNS) è un sistema di nomi di dominio veloce, affidabile e conveniente che supporta milioni di domini su Internet. Domain Name System Security Extensions (DNS edizione Standard C) in CLOUD DNS consente ai proprietari di dominio di eseguire semplici misure per proteggere i domini da attacchi DNS di hijacking e man-in-the-middle e altri attacchi. Domain Name System Security Extensions (DNS edizione Standard C) aggiunge sicurezza al protocollo DNS abilitando la convalida delle risposte DNS. Avere un DNS attendibile che converte un nome di dominio come www.example.com nell'indirizzo IP associato è un blocco predefinito sempre più importante delle applicazioni basate sul Web di oggi. Gli utenti malintenzionati possono dirottare questo processo di ricerca di dominio/IP e reindirizzare gli utenti a un sito dannoso tramite attacchi DNS di hijack e man-in-the-middle. DNS edizione Standard C consente di ridurre il rischio di attacchi di questo tipo tramite la firma crittografica dei record DNS. Di conseguenza, impedisce agli utenti malintenzionati di emettere risposte DNS false che potrebbero indirizzare i browser in modo non diretto a siti Web illeciti.

Gravità: medio

Assicurarsi che l'accesso RDP sia limitato da Internet

Descrizione: le regole del firewall GCP sono specifiche di una rete VPC. Ogni regola consente o nega il traffico quando vengono soddisfatte le relative condizioni. Le condizioni consentono agli utenti di specificare il tipo di traffico, ad esempio porte e protocolli, e l'origine o la destinazione del traffico, inclusi indirizzi IP, subnet e istanze. Le regole del firewall vengono definite a livello di rete VPC e sono specifiche della rete in cui sono definite. Le regole stesse non possono essere condivise tra reti. Le regole del firewall supportano solo il traffico IPv4. Quando si specifica un'origine per una regola di ingresso o una destinazione per una regola di uscita per indirizzo, è possibile usare un indirizzo IPv4 o un blocco IPv4 nella notazione CIDR. È possibile evitare il traffico generico (0.0.0.0/0) da Internet a un'istanza VPC o vm tramite RDP sulla porta 3389. Regole del firewall GCP all'interno di una rete VPC. Queste regole si applicano al traffico in uscita (in uscita) dalle istanze e dal traffico in ingresso alle istanze della rete. I flussi di traffico in uscita e in ingresso vengono controllati anche se il traffico rimane all'interno della rete , ad esempio la comunicazione tra istanze. Affinché un'istanza disponga dell'accesso a Internet in uscita, la rete deve avere una route del gateway Internet valida o una route personalizzata il cui indirizzo IP di destinazione è specificato. Questa route definisce semplicemente il percorso verso Internet, per evitare l'intervallo IP di destinazione più generale (0.0.0.0/0) specificato da Internet tramite RDP con la porta predefinita 3389. L'accesso generico da Internet a un intervallo IP specifico deve essere limitato.

Gravità: alta

Assicurarsi che RSASHA1 non venga usato per la chiave di firma della chiave nel DNS DNS cloud edizione Standard C

Descrizione: i numeri di algoritmo DNS edizione Standard C in questo Registro di sistema potrebbero essere usati nelle richieste RR del certificato. La firma della zona (DNS edizione Standard C) e i meccanismi di sicurezza delle transazioni (SIG(0) e TSIG usano determinati subset di questi algoritmi. L'algoritmo usato per la firma della chiave deve essere consigliato e deve essere sicuro. I numeri di algoritmo DNS (DOMAIN Name System Security Extensions) (DNS edizione Standard C) in questo Registro di sistema potrebbero essere usati nelle richieste RR del certificato. La firma della zona (DNS edizione Standard C) e i meccanismi di sicurezza delle transazioni (SIG(0) e TSIG usano determinati subset di questi algoritmi. L'algoritmo usato per la firma della chiave deve essere consigliato e deve essere sicuro. Quando si abilita DNS edizione Standard C per una zona gestita o si crea una zona gestita con DNS edizione Standard C, l'utente può selezionare gli algoritmi di firma DNS edizione Standard C e il tipo di negazione dell'esistenza. La modifica delle impostazioni DNS edizione Standard C è valida solo per una zona gestita se DNS edizione Standard C non è già abilitato. Se è necessario modificare le impostazioni per una zona gestita in cui è stata abilitata, disattivare DNS edizione Standard C e quindi riabilitarla con impostazioni diverse.

Gravità: medio

Assicurarsi che RSASHA1 non venga usato per la chiave di firma della zona nel DNS DNS cloud edizione Standard C

Descrizione: i numeri di algoritmo DNS edizione Standard C in questo Registro di sistema potrebbero essere usati nelle richieste RR del certificato. La firma della zona (DNS edizione Standard C) e i meccanismi di sicurezza delle transazioni (SIG(0) e TSIG usano determinati subset di questi algoritmi. L'algoritmo usato per la firma della chiave deve essere consigliato e deve essere sicuro. I numeri di algoritmo DNS edizione Standard C in questo Registro di sistema potrebbero essere usati nelle richieste RR del certificato. La firma della zona (DNS edizione Standard C) e i meccanismi di sicurezza delle transazioni (SIG(0) e TSIG usano determinati subset di questi algoritmi. L'algoritmo usato per la firma della chiave deve essere consigliato e deve essere sicuro. Quando si abilita DNS edizione Standard C per una zona gestita o si crea una zona gestita con DNS edizione Standard C, gli algoritmi di firma DNS edizione Standard C e il tipo di negazione dell'esistenza può essere selezionato. La modifica delle impostazioni DNS edizione Standard C è valida solo per una zona gestita se DNS edizione Standard C non è già abilitato. Se è necessario modificare le impostazioni per una zona gestita in cui è stata abilitata, disattivare DNS edizione Standard C e quindi riabilitarla con impostazioni diverse.

Gravità: medio

Assicurarsi che l'accesso SSH sia limitato da Internet

Descrizione: le regole del firewall GCP sono specifiche di una rete VPC. Ogni regola consente o nega il traffico quando vengono soddisfatte le relative condizioni. Le condizioni consentono all'utente di specificare il tipo di traffico, ad esempio porte e protocolli, e l'origine o la destinazione del traffico, inclusi indirizzi IP, subnet e istanze. Le regole del firewall vengono definite a livello di rete VPC e sono specifiche della rete in cui sono definite. Le regole stesse non possono essere condivise tra reti. Le regole del firewall supportano solo il traffico IPv4. Quando si specifica un'origine per una regola di ingresso o una destinazione per una regola di uscita per indirizzo, è possibile usare solo un indirizzo IPv4 o un blocco IPv4 nella notazione CIDR. È possibile evitare il traffico generico (0.0.0.0/0) da Internet a VPC o istanza di macchina virtuale tramite SSH sulla porta 22. Le regole del firewall GCP all'interno di una rete VPC si applicano al traffico in uscita (in uscita) dalle istanze e dal traffico in ingresso alle istanze della rete. I flussi di traffico in uscita e in ingresso vengono controllati anche se il traffico rimane all'interno della rete , ad esempio la comunicazione tra istanze. Affinché un'istanza disponga dell'accesso a Internet in uscita, la rete deve avere una route del gateway Internet valida o una route personalizzata il cui indirizzo IP di destinazione è specificato. Questa route definisce semplicemente il percorso verso Internet, per evitare l'intervallo IP di destinazione più generale (0.0.0.0/0) specificato da Internet tramite SSH con la porta predefinita '22'. L'accesso generico da Internet a un intervallo IP specifico deve essere limitato.

Gravità: alta

Verificare che la rete predefinita non esista in un progetto

Descrizione: per impedire l'uso della rete "predefinita", un progetto non deve avere una rete "predefinita". La rete predefinita ha una configurazione di rete preconfigurata e genera automaticamente le regole firewall non sicure seguenti:

default-allow-internal: consente connessioni in ingresso per tutti i protocolli e le porte tra le istanze della rete.
default-allow-ssh: consente le connessioni in ingresso sulla porta TCP 22(SSH) da qualsiasi origine a qualsiasi istanza della rete.
default-allow-rdp: consente connessioni in ingresso sulla porta TCP 3389(RDP) da qualsiasi origine a qualsiasi istanza della rete.
default-allow-icmp: consente il traffico ICMP in ingresso da qualsiasi origine a qualsiasi istanza della rete.

Queste regole del firewall create automaticamente non vengono registrate e non possono essere configurate per abilitare la registrazione delle regole del firewall. Inoltre, la rete predefinita è una rete in modalità automatica, il che significa che le subnet usano lo stesso intervallo predefinito di indirizzi IP e, di conseguenza, non è possibile usare cloud VPN o peering di rete VPC con la rete predefinita. In base ai requisiti di sicurezza e rete dell'organizzazione, l'organizzazione deve creare una nuova rete ed eliminare la rete predefinita.

Gravità: medio

Assicurarsi che il filtro delle metriche del log e gli avvisi esistano per le modifiche alla rete VPC

Descrizione: è consigliabile stabilire un filtro delle metriche e un allarme per le modifiche alla rete VPC (Virtual Private Cloud). È possibile avere più VPC all'interno di un progetto. Inoltre, è anche possibile creare una connessione peer tra due VPC, consentendo al traffico di rete di instradare tra reti virtuali. Il monitoraggio delle modifiche apportate a un VPC consentirà di garantire che il flusso del traffico VPC non venga influenzato.

Gravità: Bassa

Assicurarsi che il filtro e gli avvisi delle metriche del log esistano per le modifiche apportate alle regole del firewall di rete VPC

Descrizione: è consigliabile stabilire un filtro delle metriche e un allarme per le modifiche alle regole del firewall di rete del cloud privato virtuale (VPC). Il monitoraggio degli eventi delle regole Create o Update Firewall fornisce informazioni dettagliate sulle modifiche all'accesso alla rete e potrebbe ridurre il tempo necessario per rilevare attività sospette.

Gravità: Bassa

Assicurarsi che il filtro delle metriche del log e gli avvisi esistano per le modifiche alla route di rete VPC

Descrizione: è consigliabile stabilire un filtro delle metriche e un allarme per le modifiche alla route di rete del cloud privato virtuale (VPC). Le route GCP (Google Cloud Platform) definiscono i percorsi che il traffico di rete prende da un'istanza di macchina virtuale a un'altra destinazione. L'altra destinazione può trovarsi all'interno della rete VPC dell'organizzazione (ad esempio un'altra macchina virtuale) o all'esterno di essa. Ogni route è costituita da una destinazione e da un hop successivo. Il traffico il cui INDIRIZZO IP di destinazione si trova all'interno dell'intervallo di destinazione viene inviato all'hop successivo per il recapito. Il monitoraggio delle modifiche alle tabelle di route consente di garantire che tutto il traffico VPC passi attraverso un percorso previsto.

Gravità: Bassa

Assicurarsi che il flag di database "log_connections" per l'istanza di Cloud SQL PostgreSQL sia impostato su "on"

Descrizione: l'abilitazione dell'impostazione log_connections determina la registrazione di ogni tentativo di connessione al server, insieme al completamento dell'autenticazione client. Questo parametro non può essere modificato dopo l'avvio della sessione. PostgreSQL non registra le connessioni tentate per impostazione predefinita. L'abilitazione dell'impostazione log_connections creerà le voci di log per ogni connessione tentata, nonché il completamento dell'autenticazione client, che può essere utile per la risoluzione dei problemi e per determinare eventuali tentativi di connessione insoliti al server. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: medio

Assicurarsi che il flag di database "log_disconnections" per l'istanza di Cloud SQL PostgreSQL sia impostato su "on"

Descrizione: l'abilitazione dell'impostazione log_disconnections registra la fine di ogni sessione, inclusa la durata della sessione. PostgreSQL non registra i dettagli della sessione, ad esempio la durata e la fine della sessione per impostazione predefinita. L'abilitazione dell'impostazione log_disconnections creerà voci di log alla fine di ogni sessione, che può essere utile per la risoluzione dei problemi e determinare eventuali attività insolite in un periodo di tempo. Il log_disconnections e log_connections lavoro in mano e in genere, la coppia verrebbe abilitata/disabilitata insieme. Questa raccomandazione è applicabile alle istanze del database PostgreSQL.

Gravità: medio

Assicurarsi che i log dei flussi VPC siano abilitati per ogni subnet in una rete VPC

Descrizione: i log di flusso sono una funzionalità che consente agli utenti di acquisire informazioni sul traffico IP che passano da e verso le interfacce di rete nelle subnet VPC dell'organizzazione. Dopo aver creato un log di flusso, l'utente può visualizzare e recuperare i dati in Stackdriver Logging. È consigliabile abilitare i log dei flussi per ogni subnet VPC critica per l'azienda. Le reti VPC e le subnet forniscono partizioni di rete isolate e sicure logicamente in cui è possibile avviare le risorse GCP. Quando i log dei flussi sono abilitati per una subnet, le macchine virtuali all'interno di tale subnet avviano la creazione di report su tutti i flussi TCP (Transmission Control Protocol) e UDP (User Datagram Protocol). Ogni macchina virtuale esegue il flusso TCP e UDP che vede, in ingresso e in uscita, indipendentemente dal fatto che il flusso sia da o verso un'altra macchina virtuale, un host nel data center locale, un servizio Google o un host su Internet. Se due MACCHINE virtuali GCP comunicano e entrambe si trovano in subnet in cui sono abilitati i log dei flussi VPC, entrambe le macchine virtuali segnalano i flussi. I log di flusso supportano i casi d'uso seguenti: 1. Monitoraggio di rete. 2. Informazioni sull'utilizzo della rete e sull'ottimizzazione delle spese per il traffico di rete. 3. Rete forense. 4. I log dei flussi di analisi della sicurezza in tempo reale offrono visibilità sul traffico di rete per ogni macchina virtuale all'interno della subnet e possono essere usati per rilevare traffico anomalo o informazioni dettagliate durante i flussi di lavoro di sicurezza.

Gravità: Bassa

La registrazione delle regole del firewall deve essere abilitata

Descrizione: questa raccomandazione valuta la proprietà logConfig nei metadati del firewall per verificare se è vuota o contiene la coppia chiave-valore 'enable': false.

Gravità: medio

Il firewall non deve essere configurato per essere aperto all'accesso pubblico

Descrizione: questa raccomandazione valuta le proprietà sourceRanges e allowed per una delle due configurazioni seguenti:

La proprietà sourceRanges contiene 0.0.0.0/0 e la proprietà consentita contiene una combinazione di regole che includono qualsiasi protocollo o protocollo:port, ad eccezione del seguente: icmp tcp:22 tcp:443 tcp:3389 udp:3389 sctp:22

La proprietà sourceRanges contiene una combinazione di intervalli IP che includono qualsiasi indirizzo IP non privato e la proprietà consentita contiene una combinazione di regole che consentono tutte le porte TCP o tutte le porte UDP.

Gravità: alta

Il firewall non deve essere configurato per avere una porta CASSANDRA aperta che consente l'accesso generico

Descrizione: questa raccomandazione valuta la proprietà consentita nei metadati del firewall per i protocolli e le porte seguenti: TCP:7000-7001, 7199, 8888, 9042, 9160, 61620-61621.

Gravità: Bassa

Il firewall non deve essere configurato per avere una porta CISCO aperta edizione Standard CURE_WEBSM che consente l'accesso generico

Descrizione: questa raccomandazione valuta la proprietà consentita nei metadati del firewall per il protocollo e la porta seguenti: TCP:9090.

Gravità: Bassa

Il firewall non deve essere configurato per avere una porta aperta DIRECTORY_edizione Standard RVICES che consente l'accesso generico

Descrizione: questa raccomandazione valuta la proprietà consentita nei metadati del firewall per i protocolli e le porte seguenti: TCP:445 e UDP:445.

Gravità: Bassa

Il firewall non deve essere configurato per avere una porta DNS aperta che consente l'accesso generico

Descrizione: questa raccomandazione valuta la proprietà consentita nei metadati del firewall per i protocolli e le porte seguenti: TCP:53 e UDP:53.

Gravità: Bassa

Il firewall non deve essere configurato per avere una porta ELASTIC edizione Standard ARCH aperta che consente l'accesso generico

Descrizione: questa raccomandazione valuta la proprietà consentita nei metadati del firewall per i protocolli e le porte seguenti: TCP:9200, 9300.

Gravità: Bassa