Controlli di base sicuri per le aziende

Utilizza il vincolo booleano automaticIamGrantsForDefaultServiceAccounts per disattivare le concessioni automatiche dei ruoli quando i servizi creano automaticamente service account predefiniti con ruoli eccessivamente permissivi. Cloud de Confiance by S3NS

Per impostazione predefinita, alcuni sistemi concedono autorizzazioni eccessivamente ampie agli account automatici, il che rappresenta un potenziale rischio per la sicurezza. Ad esempio, se non applichi questo vincolo e crei un account di servizio predefinito, a quest'account di servizio viene concesso automaticamente il ruolo Editor (roles/editor) nel tuo progetto. Se un malintenzionato compromette una sola parte del sistema, potrebbe ottenere il controllo dell'intero progetto. Questo vincolo disattiva le autorizzazioni automatiche di alto livello, imponendo un approccio più sicuro e deliberato in cui vengono concesse solo le autorizzazioni minime necessarie.

Utilizza il vincolo booleano iam.disableServiceAccountKeyCreation per disattivare la creazione di chiavi esterne del account di servizio. Questo vincolo consente di controllare l'utilizzo di credenziali a lungo termine non gestite per i service account. Quando questo vincolo è impostato, non puoi creare credenziali gestite dall'utente per i service account nei progetti interessati dal vincolo.

Utilizza il vincolo booleano iam.disableServiceAccountKeyUpload per disabilitare il caricamento di chiavi pubbliche esterne nei service account. Quando questo vincolo è impostato, gli utenti non possono caricare chiavi pubbliche nei service account dei progetti interessati dal vincolo.

Google consiglia i token di sicurezza Titan per la verifica in due passaggi (V2P) per gli account super amministratore. Tuttavia, per i casi d'uso in cui ciò non è possibile, consigliamo di utilizzare un altro token di sicurezza come alternativa.

Applica la verifica in due passaggi (2SV) per un'unità organizzativa (UO) specifica o per l'intera organizzazione. Ti consigliamo di creare un'unità organizzativa per i super amministratori e di applicare la verifica in due passaggi a questa unità organizzativa.

Non avere un singolo super amministratore o amministratore dell'organizzazione. Crea uno o più (fino a 20) account amministratore di backup. Un singolo super amministratore o Amministratore organizzazione può causare scenari di blocco. Questa situazione comporta anche un rischio maggiore, in quanto una persona può apportare modifiche alla piattaforma, potenzialmente senza supervisione.

Utilizza Privileged Access Manager per gestire l'accesso con privilegi. Per tutti gli altri accessi, utilizza i gruppi di accesso, lascia che le appartenenze ai gruppi scadano automaticamente e implementa un flusso di lavoro di approvazione per le appartenenze ai gruppi.

L'utilizzo del modello di privilegio minimo ti consente di fornire l'accesso solo quando necessario, per le risorse necessarie. L'utilizzo di ruoli predefiniti semplifica l'uso e riduce la proliferazione causata dai ruoli personalizzati, in modo da non doverti preoccupare della gestione del ciclo di vita dei ruoli.

Decidi l'origine attendibile per il provisioning delle identità utente gestite. I pattern includono la creazione di identità utente in Cloud Identity, la sincronizzazione delle identità da un provider di identità esistente o l'utilizzo della federazione delle identità per la forza lavoro.

Applica password efficaci e univoche per tutti gli account utente. Valuta la possibilità di utilizzare un gestore delle password. Le credenziali deboli o assenti sono un pattern comune che gli utenti malintenzionati possono sfruttare facilmente.

Utilizza i ruoli Identity and Access Management (IAM) basati sulle funzioni lavorative per assegnare autorizzazioni agli utenti. Le funzioni lavorative sono ruoli predefiniti che consentono agli amministratori di fornire un insieme di autorizzazioni limitate a una funzione lavorativa, migliorando così la produttività e riducendo le richieste di autorizzazioni. Per allinearti meglio ai requisiti della tua organizzazione, puoi creare ruoli personalizzati in base a ruoli predefiniti.

Imposta criteri a livello di organizzazione per impedire l'aggiunta di membri esterni a Google Gruppi.

Per impostazione predefinita, gli account utente esterni possono essere aggiunti ai gruppi in Cloud Identity. Ti consigliamo di configurare le impostazioni di condivisione in modo che i proprietari dei gruppi non possano aggiungere membri esterni.

Tieni presente che questa limitazione non si applica all'account super amministratore o ad altri amministratori delegati con autorizzazioni di amministratore di Google Gruppi. Poiché la federazione dal tuo provider di identità viene eseguita con privilegi di amministratore, le impostazioni di condivisione del gruppo non si applicano a questa sincronizzazione del gruppo. Ti consigliamo di esaminare i controlli nel provider di identità e nel meccanismo di sincronizzazione per assicurarti che i membri non di dominio non vengano aggiunti ai gruppi o di applicare restrizioni ai gruppi.

Imposta la durata della sessione per i servizi Cloud de Confiance by S3NS in modo che scada almeno una volta al giorno. Lasciare un account connesso per un periodo di tempo prolungato è un rischio per la sicurezza. L'applicazione di una durata massima della sessione termina automaticamente la sessione dopo un determinato periodo di tempo, forzando un nuovo accesso sicuro.

Questa pratica riduce la possibilità che un utente malintenzionato utilizzi una password rubata e garantisce che l'accesso venga verificato regolarmente.

Per i nuovi clienti, viene applicata automaticamente una durata della sessione predefinita di 16 ore. I clienti che hanno creato la propria organizzazione Cloud de Confiance by S3NS prima del 2023 potrebbero avere un'impostazione predefinita che non richiede mai la riautenticazione. Rivedi questa impostazione per assicurarti di avere un criterio di riautenticazione con una durata della sessione compresa tra 1 e 24 ore. La policy di riautenticazione invalida il token di aggiornamento e costringe l'utente a eseguire regolarmente la riautenticazione di gcloud CLI con la propria password o il proprio token di sicurezza.

La durata della sessione per i servizi Cloud de Confiance by S3NS è un'impostazione distinta dalla durata della sessione per i servizi Google, che controlla le sessioni web per l'accesso ai servizi Google Workspace, ma non controlla la riautenticazione per Cloud de Confiance by S3NS. Se utilizzi i servizi Google Workspace, imposta la durata della sessione per entrambi.

Non consentire account consumer non gestiti. Consolida tutti gli account consumer non gestiti e valuta una soluzione per impedire la creazione di ulteriori account consumer non gestiti con il tuo dominio.

Gli account consumer non gestiti non sono regolati dai processi di gestione di utenti che entrano, si spostano o escono dall'organizzazione (JML), quindi introducono il rischio che un dipendente abbia ancora accesso alle tue risorse dopo aver lasciato il lavoro. Questi account vengono trattati anche come esterni per quanto riguarda i controlli come la condivisione con limitazioni del dominio.

Assicurati che gli account super amministratore siano separati dagli account utente quotidiani. Gli account super amministratore devono essere account dedicati utilizzati solo per apportare modifiche critiche. Per una maggiore sicurezza, attiva l'approvazione da più parti per le azioni amministrative. L'attivazione dell'approvazione da più parti significa che le azioni sensibili vengono approvate da due amministratori, il che impedisce agli autori degli attacchi di compromettere un account amministratore e bloccare altri utenti amministratore.

Attiva l'autenticazione a più fattori (MFA), nota anche come verifica in due passaggi (V2P), per tutti gli utenti di Account Google e Cloud Identity, non solo per i super amministratori. L'MFA per i super amministratori è abilitata per impostazione predefinita. L'MFA aggiunge un ulteriore livello di difesa perché le password da sole spesso non sono una misura di sicurezza sufficientemente efficace.

Rimuovi i ruoli Autore progetto e Creatore account di fatturazione a livello di dominio concessi per impostazione predefinita a tutti i membri di una nuova organizzazione.

Le nuove organizzazioni concedono i ruoli Autore progetto e Creatore account di fatturazione a tutte le identità utente gestite nel dominio. Sebbene questi ruoli siano utili per iniziare, questa configurazione non è pensata per gli ambienti di produzione. La proliferazione degli account di fatturazione comporta un aumento dei costi amministrativi e ha conseguenze tecniche quando i servizi vengono suddivisi in più account di fatturazione. Consentire la creazione di progetti in formato libero può portare a progetti che non rispettano le convenzioni di governance.

Rimuovi questi ruoli e crea una procedura di creazione dei progetti per richiedere nuovi progetti e associarli alla fatturazione.

Se devi utilizzare le chiavi del account di servizio, ruotale almeno una volta ogni 90 giorni.

Un intervallo di rotazione limita il periodo di tempo in cui un malintenzionato può accedere al sistema. Senza un intervallo di rotazione, l'aggressore ha accesso per sempre. Se possibile, valuta la possibilità di utilizzare la federazione delle identità per i workload anziché le chiavi dei account di servizio.

Utilizza la federazione delle identità per i workload per consentire ai sistemi CI/CD e ai carichi di lavoro in esecuzione su altri cloud di autenticarsi su Cloud de Confiance by S3NS. La federazione delle identità per i workload consente ai workload eseguiti al di fuori di Cloud de Confiance di autenticarsi senza richiedere una chiave del account di servizio. Evitando le chiavi dei account di servizio e altre credenziali di lunga durata, la federazione delle identità per i workload può aiutarti a ridurre il rischio di perdita delle credenziali.

Per impostazione predefinita, il recupero autonomo dell'account super amministratore è disattivato per i nuovi clienti. Tuttavia, i clienti esistenti potrebbero aver attivato questa impostazione. La disattivazione di questa impostazione contribuisce a ridurre il rischio che uno smartphone compromesso, un'email compromessa o un attacco di ingegneria sociale consentano a un malintenzionato di ottenere privilegi di super amministratore sul tuo ambiente.

Pianifica una procedura interna per consentire a un super amministratore di contattare un altro super amministratore della tua organizzazione se ha perso l'accesso al proprio account e assicurati che tutti i super amministratori conoscano la procedura di recupero assistito dall'assistenza.

Per disattivare la funzionalità, vai alle impostazioni di recupero dell'account nella Console di amministrazione Google.

Imposta il timeout della sessione inattiva su 15 minuti per i casi d'uso sensibili. Le sessioni inattive potrebbero essere utilizzate dai malintenzionati per il furto di credenziali.

Se possibile, fornisci token di sicurezza fisici a super amministratori o amministratori dell'organizzazione come secondo fattore. Gli account super amministratore sono gli obiettivi di maggior valore per gli attacchi sofisticati. I token di sicurezza hardware offrono un elevato livello di protezione perché sono resistenti al phishing. I token di sicurezza hardware sono la difesa più efficace possibile contro il takeover dell'account per gli amministratori più importanti e si basano sulle norme MFA standard.

Se utilizzi un provider di identità esterno, configura la verifica post-SSO.

Attiva un ulteriore livello di controllo in base all'analisi del rischio associato all'accesso effettuata da Google. Dopo aver applicato questa impostazione, gli utenti potrebbero dover sostenere ulteriori verifiche dell'accesso basate sul rischio al momento dell'accesso se Google rileva che l'accesso di un utente è sospetto.

Abilita le policy sul confine di accesso dell'entità (PAB) per limitare l'accesso dell'entità e contribuire a proteggere da phishing ed esfiltrazione di dati. Attiva una policy PAB per l'organizzazione per evitare attacchi di phishing esterni. I PAB migliorano la sicurezza riducendo l'entità di un attacco con un'identità compromessa e contribuiscono anche a prevenire attacchi di phishing esterni e altri attacchi di esfiltrazione.

I tag forniscono un modo per creare annotazioni per le risorse e, in alcuni casi, consentire o negare in modo condizionale i criteri a seconda che una risorsa abbia un tag specifico. Utilizza i tag e l'applicazione condizionale dei criteri per avere un controllo granulare in tutta la gerarchia delle risorse.

Utilizza Audit log di Cloud per monitorare le attività ad alto rischio, ad esempio gli account a cui vengono concessi ruoli ad alto rischio come Amministratore dell'organizzazione e Super amministratore. Configura gli avvisi per questo tipo di attività.

Per evitare di concedere un accesso eccessivo a Cloud de Confiance by S3NS, blocca l'accesso a Cloud Shell per gli account utente gestiti Cloud Identity.

Con l'accesso sensibile al contesto, puoi creare criteri di sicurezza per controllo dell'accesso granulare alle applicazioni in base ad attributi come l'identità dell'utente, la località, lo stato della sicurezza del dispositivo e l'indirizzo IP. Ti consigliamo di utilizzare l'accesso sensibile al contesto per limitare l'accesso alla console Cloud de Confiance (https://console.cloud.google.com/) e alla Console di amministrazione Google (https://admin.cloud.google.com).

Cloud de Confiance supporta più versioni del protocollo TLS. Per soddisfare i requisiti di conformità, ti consigliamo di rifiutare le richieste di handshake dai client che utilizzano versioni TLS precedenti.

Per configurare questo controllo, utilizza il vincolo della policy dell'organizzazione Limita versioni TLS (gcp.restrictTLSVersion). Puoi applicare questo vincolo a organizzazioni, cartelle o progetti nella gerarchia delle risorse. Il vincolo Limita versioni TLS utilizza una lista nera, che nega i valori espliciti e consente tutti gli altri. Si verifica un errore se provi a utilizzare una lista consentita.

A causa del comportamento della valutazione della gerarchia delle policy dell'organizzazione, la limitazione della versione TLS si applica al nodo risorsa specificato e a tutte le relative cartelle e progetti (elementi secondari). Ad esempio, se neghi TLS versione 1.0 per un'organizzazione, viene negata anche per tutti i suoi discendenti.

Puoi ignorare la limitazione della versione TLS ereditata aggiornando la policy dell'organizzazione su una risorsa secondaria. Ad esempio, se la policy dell'organizzazione nega TLS 1.0 a livello di organizzazione, puoi rimuovere la limitazione per una cartella secondaria impostando una policy dell'organizzazione separata per quella cartella. Se la cartella ha elementi secondari, il criterio della cartella verrà applicato anche a ogni risorsa secondaria a causa dell'ereditarietà dei criteri.

Per limitare ulteriormente la versione TLS solo a TLS 1.3, puoi impostare questo criterio in modo che limiti anche la versione TLS 1.2. Devi implementare questo controllo sulle applicazioni che ospiti all'interno di Cloud de Confiance by S3NS. Ad esempio, a livello di organizzazione, imposta:

["TLS_VERSION_1","TLS_VERSION_1.1","TLS_VERSION_1.2"]

Assicurati che nel tuo ambiente Cloud de Confiance by S3NS siano consentite solo le identità della tua organizzazione. Utilizza il vincolo di policy dell'organizzazione Condivisione con limitazioni del dominio (iam.allowedPolicyMemberDomains) o iam.managed.allowedPolicyMembers per definire uno o più ID cliente di Cloud Identity o Google Workspace le cui entità possono essere aggiunte ai criteri Identity and Access Management (IAM).

Questi vincoli aiutano a impedire ai dipendenti di concedere l'accesso ad account esterni al di fuori del controllo della tua organizzazione che non rispettano i criteri di sicurezza per l'autenticazione a più fattori (MFA) o la gestione delle password. Questo controllo è fondamentale per impedire l'accesso non autorizzato, garantendo che possano essere utilizzate solo identità aziendali attendibili e gestite.

Il vincolo gcp.restrictServiceUsage garantisce che solo i servizi approvati Cloud de Confiance by S3NS vengano utilizzati nei luoghi giusti. Ad esempio, una cartella di produzione o molto sensibile ha un piccolo elenco di Cloud de Confiance servizi approvati per l'archiviazione dei dati. Una cartella sandbox potrebbe avere un elenco più ampio di servizi e controlli di sicurezza dei dati di accompagnamento per contribuire a prevenire l'esfiltrazione di dati. Il valore è specifico per i tuoi sistemi e corrisponde all'elenco approvato di servizi e dipendenze per cartelle e progetti specifici.

Questo vincolo consente alla tua organizzazione di creare una lista consentita di servizi approvati, il che aiuta a impedire ai dipendenti di utilizzare servizi non verificati.

Il vincolo di limitazione della località delle risorse (gcp.resourceLocations) garantisce che per l'archiviazione dei dati vengano utilizzate solo le regioni Cloud de Confiance by S3NS approvate. Il valore è specifico per i tuoi sistemi e corrisponde all'elenco approvato di regioni per la residenza dei dati della tua organizzazione.

Questo vincolo consente alla tua organizzazione di imporre che le risorse e i dati vengano creati e salvati solo in regioni geografiche specifiche approvate.

Il vincolo booleano compute.skipDefaultNetworkCreation ignora la creazione della rete predefinita e delle risorse correlate durante la creazione dei progetti Cloud de Confiance by S3NS .

La rete predefinita è una rete Virtual Private Cloud (VPC) in modalità automatica con regole firewall IPv4 precompilate per consentire i percorsi di comunicazione interni. In genere, questa configurazione non è una postura di sicurezza consigliata per gli ambienti di produzione.

Le estensioni DNSSEC (Domain Name System Security Extensions) sono una funzionalità del DNS (Domain Name System) che autentica le risposte alle ricerche dei nomi di dominio. Non fornisce protezioni della privacy per queste ricerche, ma impedisce ai malintenzionati di manipolare o compromettere le risposte alle richieste DNS.

In Cloud DNS, abilita DNSSEC nei seguenti punti:

• Zona DNS
• Dominio di primo livello (TLD)
• Risoluzione DNS

Abilita l'accesso privato Google su tutte le subnet.

Abilita l'accesso privato ai servizi per creare una rete privata tra i servizi Cloud de Confiance by S3NS come le reti legacy di Google Cloud VMware Engine e i produttori di servizi come Cloud SQL. L'accesso privato ai servizi consente di evitare di esporre inutilmente le connessioni di rete dei workload a internet.

Disattiva la creazione di subnet esterne IPv6, a meno che non sia specificamente richiesta. Per ridurre la superficie di attacco, valuta la possibilità di disattivare IPv6 su sistemi e reti in cui non è gestito o richiesto attivamente. Molte organizzazioni dispongono di controlli di sicurezza e monitoraggio maturi per IPv4, ma i loro strumenti e criteri potrebbero non estendersi completamente a IPv6, il che può creare un punto cieco significativo per le minacce. L'esecuzione di una rete dual-stack introduce anche una complessità operativa, che richiede configurazioni ed competenze specifiche per la gestione e la risoluzione dei problemi in modo efficace. Pertanto, se non hai un chiaro motivo aziendale per utilizzare IPv6, la disattivazione può semplificare l'ambiente e garantire che tutto il traffico venga filtrato in modo coerente attraverso la tua postura di sicurezza IPv4 consolidata.

Limita l'accesso a fonti esterne perché, per impostazione predefinita, è consentito tutto l'accesso in uscita. Imposta regole firewall specifiche per i pattern di traffico previsti che devono uscire.

Per impostazione predefinita, spesso i sistemi sono autorizzati a effettuare connessioni in uscita a internet, il che può essere considerato un rischio per la sicurezza. Un criterio di negazione predefinita blocca il traffico in uscita e richiede la creazione di regole specifiche solo per le destinazioni note e necessarie.

Ove possibile, limita l'accesso in entrata solo a risorse e intervalli di risorse specifici. Se Identity-Aware Proxy (IAP) è configurato, imposta le regole firewall SSH e Remote Desktop Protocol (RDP) in entrata sugli intervalli IP IAP come origini.

Le regole firewall SSH e RDP permissive consentono attacchi di tipo brute force. Utilizza invece Cloud de Confiance by S3NS proxy Identity-Aware (come IAP) per SSH e RDP.

Attiva i Controlli di servizio VPC come livello di protezione aggiuntivo per evitare la potenziale perdita di dati.

I Controlli di servizio VPC possono contribuire a impedire l'esfiltrazione di dati creando perimetri di isolamento attorno alle risorse cloud, ai dati sensibili e alle reti.

Il perimetro di servizio limita l'utilità delle credenziali compromesse perché blocca le richieste ai servizi limitati provenienti da endpoint controllati da malintenzionati che si trovano al di fuori del tuo ambiente.

Per le applicazioni esposte dietro Cloud Load Balancing, utilizza le policy predefinite di Google Cloud Armor o configura le tue policy per aggiungere la protezione di rete di livello 3-7 per applicazioni o servizi esposti esternamente. Le policy di sicurezza di Cloud Armor contribuiscono a proteggere la tua applicazione fornendo filtri di livello 7. Queste policy esaminano anche le richieste in entrata per attacchi web comuni o altri attributi di livello 7 per bloccare potenzialmente il traffico prima che raggiunga i servizi di backend o i bucket di backend con bilanciamento del carico. Ogni policy di sicurezza è costituita da un insieme di regole che includono attributi dal livello 3 al livello 7.

Per ogni perimetro di servizio, conferma nella console Cloud de Confiance che il tipo di perimetro sia impostato su normale.

Per ogni perimetro di servizio, utilizza Gestore contesto accesso per verificare che il perimetro protegga l'API.

Il vincolo booleano compute.setNewProjectDefaultToZonalDNSOnly consente di impostare l'impostazione del DNS interno per i nuovi progetti in modo che utilizzino solo il DNS di zona. Utilizza il DNS di zona perché offre una maggiore affidabilità rispetto alle singole zone, in quanto isola gli errori nella registrazione DNS .

Se utilizzi Cloud Identity, condividi gli audit log di Cloud Identity con Cloud de Confiance by S3NS.

I log di controllo dell'attività amministrativa di Google Workspace o Cloud Identity vengono normalmente gestiti e visualizzati nella Console di amministrazione Google, separatamente dai log nel tuo ambiente Cloud de Confiance . Questi log contengono informazioni pertinenti per il tuo Cloud de Confiance ambiente, ad esempio gli eventi di accesso degli utenti.

Ti consigliamo di condividere gli audit log di Cloud Identity con il tuo ambiente Cloud de Confiance per gestire centralmente i log di tutte le origini.

I serviziCloud de Confiance scrivono voci di audit log per rispondere alla domanda "Chi ha fatto cosa, dove e quando?" con le risorse Cloud de Confiance .

Abilita l'audit logging a livello di organizzazione. Puoi configurare la registrazione utilizzando la pipeline che utilizzi per configurare l'organizzazione Cloud de Confiance .

I log di flusso VPC registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM, incluse quelle utilizzate come nodi Google Kubernetes Engine (GKE). Il campione è in genere pari al 50% o meno dei flussi di rete VPC.

Quando abiliti i log di flusso VPC, abiliti la registrazione per tutte le VM in una subnet. Tuttavia, puoi ridurre la quantità di informazioni scritte nel logging.

Abilita i log di flusso VPC per ogni subnet VPC. Puoi configurare la registrazione utilizzando una pipeline che utilizzi per creare un progetto.

Per impostazione predefinita, le regole firewall non scrivono automaticamente i log.Il logging delle regole firewall consente di controllare, verificare e analizzare gli effetti delle regole firewall. Ad esempio, puoi determinare se una regola firewall progettata per negare il traffico funziona come previsto. Il logging è utile anche se vuoi determinare quante connessioni sono interessate da una determinata regola firewall.

Attiva la registrazione per ogni regola firewall. Puoi configurare la registrazione utilizzando una pipeline che utilizzi per creare un firewall.

Per impostazione predefinita, Cloud de Confiance abilita e non consente a nessuno di disattivare l'audit delle attività di amministrazione chiave per gli account con privilegi.

Gli audit log per le attività di amministrazione contengono voci di log per le chiamate API o altre azioni che modificano la configurazione o i metadati delle risorse. Ad esempio, questi log registrano quando gli utenti creano istanze VM o modificano le autorizzazioni IAM.

Gli audit log per le attività di amministrazione contengono voci di log per la creazione, la modifica e l'eliminazione dei vincoli dei criteri dell'organizzazione a livello di organizzazione, cartella e progetto.

Gli audit log per le attività di amministrazione vengono sempre scritti; non puoi configurarli, escluderli o disabilitarli. Anche se disattivi l'API Cloud Logging, gli audit log delle attività di amministrazione vengono comunque generati.

Consigliamo alla tua organizzazione di configurare norme e procedure per monitorare questi avvisi e generare azioni o avvisi in base alle norme di accesso aziendali per il monitoraggio delle attività dell'amministratore.

Iscriviti alle notifiche del bollettino sulla sicurezza per i servizi Cloud de Confiance by S3NS per ricevere avvisi su vulnerabilità e misure di mitigazione.

Quando sono disponibili bollettini sulla sicurezza pertinenti per il tuo Cloud de Confiance by S3NS servizio (ad esempio GKE), il servizio può pubblicare notifiche relative a questi eventi come messaggi negli argomenti Pub/Sub che configuri. Puoi ricevere queste notifiche in una sottoscrizione Pub/Sub, integrarle con servizi di terze parti e filtrare in base ai tipi di notifiche che vuoi ricevere.

Configura i contatti fondamentali per assicurarti che un alias di gruppo o una mailing list monitorati ricevano notifiche importanti.

L'utilizzo di un indirizzo email di gruppo monitorato contribuisce a garantire che questi avvisi urgenti vengano inviati a un team attivo in grado di rispondere rapidamente.

Utilizza la funzionalità di anomalie di fatturazione in Fatturazione Cloud per monitorare eventuali picchi o deviazioni nella spesa prevista.

Un aumento improvviso e inaspettato di una fattura del cloud è un indicatore principale di una compromissione della sicurezza. A volte, i picchi di fatturazione imprevisti sono causati da malintenzionati che hanno ottenuto l'accesso e utilizzano le risorse per attività non autorizzate.

L'attivazione del rilevamento di anomalie di fatturazione fornisce un sistema di avviso preventivo essenziale per poter segnalare automaticamente questa attività sospetta.

Crea un sink di log per esportare i log per la tua soluzione di monitoraggio della sicurezza e imposta il periodo di conservazione in modo che soddisfi i tuoi requisiti.

I periodi di conservazione dei log predefiniti spesso non sono sufficientemente lunghi per soddisfare i requisiti di 1-7 anni previsti dalle normative di conformità come PCI o HIPAA.

La creazione di un sink di log per esportare i log in una posizione di archiviazione a lungo termine è essenziale per soddisfare determinati obblighi legali e normativi. I sink di log ti consentono anche di inviare i log a un sistema di monitoraggio della sicurezza centralizzato per il rilevamento avanzato delle minacce.

Per monitorare chi ha avuto accesso ai dati nel tuo ambiente Cloud de Confiance by S3NS , attiva gli audit log di accesso ai dati. Questi log registrano le chiamate API che leggono, creano o modificano i dati utente, nonché le chiamate API che leggono le configurazioni delle risorse.

Ti consigliamo vivamente di attivare gli audit log di accesso ai dati per i modelli di AI generativa e i dati sensibili per assicurarti di poter controllare chi ha letto le informazioni. Per utilizzare gli audit log degli accessi ai dati, devi configurare una logica di rilevamento personalizzata per attività specifiche, come gli accessi dei super amministratori.

Il volume degli audit log di accesso ai dati può essere elevato. L'abilitazione dei log di accesso ai dati potrebbe comportare l'addebito di costi aggiuntivi per l'utilizzo dei log nel tuo progetto Cloud de Confiance .

Evita sorprese nella fattura creando budget di fatturazione Cloud per monitorare tutti i tuoi Cloud de Confiance by S3NS addebiti in un unico posto. Dopo aver stabilito un importo del budget, imposta regole di soglia di avviso per il budget in base al progetto per attivare le notifiche email. Queste notifiche ti aiutano a monitorare la spesa rispetto al budget. Puoi anche utilizzare i budget di fatturazione Cloud per automatizzare le risposte al controllo dei costi.

I log standard mostrano le azioni intraprese dagli utenti della tua organizzazione, mentre i log di Access Transparency mostrano le azioni intraprese dal personale di assistenza Google quando accede all'account. Questo accesso in genere avviene solo in risposta a una richiesta di assistenza. I log di Access Transparency forniscono un audit trail completo e verificabile di tutti gli accessi, essenziale per soddisfare i rigorosi requisiti di conformità e governance dei dati.

Puoi attivare Access Transparency a livello di organizzazione.

Per un'ulteriore analisi della fatturazione, puoi esportare i dati di fatturazione Cloud de Confiance by S3NS in BigQuery o in un file JSON. Ad esempio, puoi esportare automaticamente dati dettagliati, come utilizzo, stime di costi e prezzi, durante la giornata in un set di dati BigQuery da te specificato. Potrai quindi accedere ai tuoi dati di fatturazione Cloud da BigQuery per un'analisi dettagliata o utilizzare uno strumento come Data Studio per visualizzare i dati.

Tutti i dati in Cloud de Confiance sono criptati at-rest per impostazione predefinita utilizzando algoritmi approvati dal NIST.

Assicurati che Cloud Key Management Service (Cloud KMS) utilizzi solo algoritmi approvati dal NIST per archiviare le chiavi sensibili nell'ambiente. Questo controllo garantisce l'utilizzo sicuro delle chiavi solo con algoritmi e sicurezza approvati dal NIST. Il campo CryptoKeyVersionAlgorithm è un elenco consentito fornito.

Rimuovi gli algoritmi che non rispettano le norme della tua organizzazione.

Imposta lo scopo delle chiavi Cloud KMS su ENCRYPT_DECRYPT in modo che le chiavi vengano utilizzate solo per criptare e decriptare i dati. Questo controllo blocca altre funzioni, come la firma, e garantisce che le chiavi vengano utilizzate solo per lo scopo previsto. Se utilizzi chiavi per altre funzioni, convalida questi casi d'uso e valuta la possibilità di creare chiavi aggiuntive.

Il livello di protezione indica il modo in cui vengono eseguite le operazioni crittografiche. Dopo aver creato una chiave di crittografia gestita dal cliente (CMEK), non puoi modificare il livello di protezione. I livelli di protezione supportati sono i seguenti:

• SOFTWARE: le operazioni di crittografia vengono eseguite nel software.
• HSM:le operazioni di crittografia vengono eseguite in un modulo di sicurezza hardware (HSM).
• EXTERNAL:le operazioni di crittografia vengono eseguite utilizzando una chiave archiviata in un gestore di chiavi esterno connesso a Cloud de Confiance tramite internet. Limitato alla crittografia simmetrica e alla firma asimmetrica.
• EXTERNAL_VPC::le operazioni di crittografia vengono eseguite utilizzando una chiave archiviata in un gestore di chiavi esterno connesso a Cloud de Confiance tramite una rete Virtual Private Cloud (VPC). Limitato alla crittografia simmetrica e alla firma asimmetrica.

Assicurati che il periodo di rotazione delle chiavi Cloud KMS sia impostato su 90 giorni. Una best practice generale è ruotare le chiavi di sicurezza a intervalli regolari. Questo controllo applica rotazione della chiave delle chiavi create con i servizi HSM.

Quando crei questo periodo di rotazione, crea anche criteri e procedure appropriati per gestire in modo sicuro la creazione, l'eliminazione e la modifica del materiale di generazione delle chiavi, in modo da proteggere le tue informazioni e garantire la disponibilità. Assicurati che questo periodo rispetti le norme aziendali per rotazione della chiave.

Crea una strategia di gestione della crittografia utilizzando Cloud Key Management Service (Cloud KMS) con Autokey, Cloud External Key Manager (Cloud EKM) o entrambi. Questa strategia consente alla tua organizzazione di utilizzare e gestire le proprie chiavi di crittografia per soddisfare i tuoi requisiti specifici. L'utilizzo delle tue chiavi di crittografia offre un controllo granulare e verificabile sull'accesso ai dati, inclusa la possibilità di bloccare immediatamente l'accesso ai dati disattivando la chiave.

Utilizza il vincolo della policy dell'organizzazione Limita i progetti che possono fornire CryptoKey KMS per CMEK (gcp.restrictCmekCryptoKeyProjects) per definire i progetti che possono archiviare le chiavi di crittografia gestite dal cliente (CMEK). Questo vincolo ti consente di centralizzare la governance e la gestione delle chiavi di crittografia. Quando una chiave selezionata non soddisfa questo vincolo, la creazione della risorsa non va a buon fine.

Per modificare questo vincolo, gli amministratori devono disporre del ruolo IAM Organization Policy Administrator (roles/orgpolicy.policyAdmin).

Se vuoi aggiungere un secondo livello di protezione, ad esempio Bring Your Own Key, modifica questo vincolo in modo che rappresenti i nomi delle chiavi CMEK abilitate.

Specifiche del prodotto:

• In Gemini Enterprise Agent Platform, archivi le chiavi nel progetto PROGETTI CHIAVE.

Se hai bisogno di un maggiore controllo sulle operazioni con le chiavi rispetto a quanto consentito dalle Google Cloud-powered encryption keys chiavi di crittografiabasate su Google Clouddi proprietà di Google e gestite da Google, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK). Queste chiavi vengono create e gestite utilizzando Cloud KMS. Memorizza le chiavi come chiavi software, in un cluster HSM o in un sistema di gestione delle chiavi esterno.

Le velocità di crittografia e decrittografia di Cloud KMS sono soggette a quote.

Specifiche di Cloud Storage

In Cloud Storage, utilizza le chiavi CMEK su singoli oggetti o configura i bucket Cloud Storage in modo che utilizzino una chiave CMEK per impostazione predefinita su tutti i nuovi oggetti aggiunti a un bucket. Quando utilizzi una CMEK, un oggetto viene criptato con la chiave da Cloud Storage al momento dell'archiviazione in un bucket e viene decriptato automaticamente da Cloud Storage quando viene fornito ai richiedenti.

Quando utilizzi le chiavi CMEK con Cloud Storage, si applicano le seguenti limitazioni:

• Non puoi criptare un oggetto con una CMEK aggiornando i metadati dell'oggetto. Includi la chiave come parte della riscrittura dell'oggetto.
• Cloud Storage utilizza il comando di aggiornamento degli oggetti per impostare le chiavi di crittografia sugli oggetti, ma il comando riscrive l'oggetto nell'ambito della richiesta.
• Devi creare il keyring Cloud KMS nella stessa posizione dei dati che intendi criptare. Ad esempio, se il bucket si trova in us-east1, qualsiasi portachiavi utilizzato per criptare gli oggetti in quel bucket deve essere creato anche in us-east1.
• Per la maggior parte delle doppie regioni, devi creare il keyring Cloud KMS nella multiregione associata. Ad esempio, se il bucket si trova nella coppia us-east1, us-west1, qualsiasi portachiavi utilizzato per criptare gli oggetti in quel bucket deve essere creato nella multiregione Stati Uniti.
• Per le doppie regioni predefinite asia1, eur4 e nam4, devi creare il keyring nella stessa doppia regione predefinita.
• Il checksum CRC32C e l'hash MD5 degli oggetti criptati con chiavi CMEK non vengono restituiti quando vengono elencati oggetti con l'API JSON.
• L'utilizzo di strumenti come Cloud Storage per eseguire ulteriori richieste di metadati GET su ogni oggetto di crittografia per recuperare le informazioni CRC32C e MD5 può rendere l'elenco molto più breve. Cloud Storage non può utilizzare la parte di decriptazione delle chiavi asimmetriche archiviate in Cloud KMS per decriptare automaticamente gli oggetti pertinenti nello stesso modo in cui lo fanno le CMEK.