Mitigazione di OWASP Top 10:2025 su Google Cloud

Questo documento identifica i servizi e le strategie di mitigazione che possono aiutarti a difenderti dagli attacchi a livello di applicazione descritti in OWASP Top 10:2025. Google Cloud Creato dalla Open Web Application Security (OWASP) Foundation, OWASP Top 10:2025 è un elenco dei 10 principali rischi per la sicurezza in un ciclo di vita di sviluppo del software (SDLC). Sebbene nessun servizio possa garantire una protezione completa contro questi rischi, l'applicazione di questi servizi quando hanno senso nella tua architettura può contribuire a una solida soluzione di sicurezza multilivello.

L'infrastruttura Google è progettata per aiutarti a creare, eseguire il deployment e gestire servizi con solidi controlli di sicurezza. La sicurezza fisica e operativa, la crittografia dei dati inattivi e in transito e molte altre protezioni dell'infrastruttura di base sono gestite da Google. Erediti questi vantaggi eseguendo il deployment delle tue applicazioni su Google Cloud, ma potresti dover adottare misure aggiuntive per proteggere la tua applicazione da attacchi specifici.

Matrice di conformità

I servizi Google Cloud elencati nella tabella seguente possono aiutarti a difenderti dai 10 principali rischi per la sicurezza identificati da OWASP Top 10:2025:

Categoria OWASP Top 10:2025 Controlli Google Cloud principali e di Wiz

A01: Controllo dell'accesso interrotto

Gestore contesto accesso, Agent Gateway, Agent Identity, Apigee, Google Cloud Armor, Firebase App Check, Firebase Security Rules, Cloud Next Generation Firewall (Cloud NGFW), Identity-Aware Proxy (IAP), Identity and Access Management (IAM), servizio policy dell'organizzazione, Controlli di servizio VPC, Wiz Cloud

A02: Errata configurazione della sicurezza

Gestore contesto accesso, Cloud Asset Inventory, Google Security Operations, policy dell'organizzazione, Security Command Center Premium, Controlli di servizio VPC, Wiz Cloud

A03: Errori nella catena di fornitura del software

Artifact Registry, Assured Open Source Software (Assured OSS), Binary Authorization, Cloud Build, Cloud Deploy, Cloud Workstations, CodeMender, Wiz Code

A04: Errori di crittografia

Apigee, Certificate Authority Service, Certificate Manager, Cloud Key Management Service, Cloud Load Balancing, Cloud Workstations, Confidential Computing, Organization Policy, Secret Manager, Sensitive Data Protection, Wiz Cloud

A05: Iniezione

Apigee, Cloud Armor, CodeMender, Firebase Security Rules, Cloud Next Generation Firewall (Cloud NGFW), Model Armor, Security Command Center Premium, VirusTotal, Wiz Code

A06: Progettazione non sicura

Apigee, CodeMender, Mandiant, Wiz Cloud

A07: Authentication Failures

Gestore contesto accesso, Identità agente, Apigee, Cloud Armor, Cloud Identity, Firebase App Check, Firebase Authentication, Google Cloud Fraud Defense, IAM (Privileged Access Manager, federazione delle identità per i workload e federazione delle identità della forza lavoro), IAP, Identity Platform, Security Command Center Premium, Secret Manager, Titan Security Keys, Wiz Code

A08: Errori di integrità del software o dei dati

Artifact Analysis, Assured OSS, Binary Authorization, Cloud Armor, Cloud Build, Cloud Deploy, Firebase App Check, Security Command Center Premium, VirusTotal, Wiz Defend

A09: Errori di logging e avvisi di sicurezza

Access Approval e Access Transparency, Apigee, Google SecOps, Cloud Logging, Cloud Monitoring, Sensitive Data Protection, Wiz Defend

R10: Gestione errata delle condizioni eccezionali

Cloud Armor, Cloud Load Balancing, Error Reporting, Model Armor

Google Cloud servizi

Le sezioni seguenti descrivono le best practice OWASP Top 10 per i servizi Google Cloud di base.

Access Approval e Access Transparency

Access Transparency e Access Approval consentono la verifica dell'accesso del cloud provider. Utilizzando Access Transparency, puoi registrare il motivo di ogni accesso effettuato dal personale Google. Access Approval ti consente di approvare o respingere le richieste di accesso da parte del personale di Google che fornisce assistenza al tuo servizio.

Si applica ad A09: Security Logging & Alerting Failures.

Consulta le seguenti best practice:

  • Automatizza la procedura di approvazione dell'accesso. A questo scopo, configura Access Approval per inviare i metadati delle richieste di approvazione dell'accesso in entrata a un argomento Pub/Sub. Crea una sottoscrizione Pub/Sub che esegua il push del payload JSON al tuo endpoint webhook personalizzato (ad esempio un servizio Cloud Run autenticato, funzioni Cloud Run o un gateway API aziendale) per l'elaborazione.
  • Considera i log di Access Transparency come telemetria di sicurezza critica. Crea metriche basate sui log e norme di avviso in Monitoring per segnalare al tuo centro operazioni di sicurezza (SecOps) se il personale Google accede a risorse sensibili senza un ticket di assistenza attivo e corrispondente.
  • Esporta direttamente i log di Access Transparency in Google SecOps o nel tuo SIEM aziendale centralizzato.
  • Crea una norma di conformità per controllare regolarmente i flussi di log e verificare che gli eventi di accesso di emergenza auto_approved siano correlati a un incidente documentato di gravità elevata.
  • Per il controllo crittografico, utilizza Key Access Justifications per forzare il sistema a richiedere in modo programmatico un'approvazione per la decrittografia delle chiavi.

Gestore contesto accesso

Gestore contesto accesso è il motore di accesso sensibile al contesto di Google Cloud. Gestore contesto accesso ti consente di definire livelli di accesso basati su attributi (come intervalli di indirizzi IP client, security posture del dispositivo e posizione geografica) per IAP, Controlli di servizio VPC e IAM.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A02: Errata configurazione della sicurezza
  • A07: Errori di autenticazione

Esamina le seguenti best practice per A01: Broken Access Control:

  • Crea livelli di sicurezza riutilizzabili e suddivisi in livelli per la policy di accesso della tua organizzazione. Crea livelli di accesso base per testare gli attributi standard. Per condizioni complesse e multifattoriali, implementa livelli di accesso personalizzati per valutare stati avanzati dei dispositivi e indicatori degli endpoint di terze parti.
  • Utilizza Verifica endpoint o Chrome Enterprise Core per applicare vincoli a livello di dispositivo, come la crittografia completa del disco, un blocco schermo attivo e una versione del sistema operativo approvata.
  • Per proteggere i repository di dati di alto valore con i Controlli di servizio VPC, aggiungi livelli di accesso alle regole in entrata dei Controlli di servizio VPC. Se una chiave dell'account di servizio viene compromessa, un malintenzionato non può utilizzare solo la chiave per eseguire query su BigQuery o Cloud Storage da un indirizzo IP pubblico non autorizzato o da una macchina non attendibile.
  • Per estendere la protezione Zero Trust alle applicazioni web e ai tunnel amministrativi delle VM, collega i livelli di accesso direttamente alle risorse protette da IAP.

Esamina le seguenti best practice per A02: Errata configurazione della sicurezza:

  • Implementa policy di accesso con ambito associate a cartelle specifiche per delegare la gestione delle policy locali a singoli team di progetto e isolare le modifiche dal resto dell'organizzazione.
  • Per evitare che le regole di ingresso orfane diventino backdoor silenziose, rivedi e rimuovi regolarmente gli intervalli IP ritirati, le subnet partner scadute e gli attributi del dispositivo obsoleti.

Consulta le seguenti best practice per A07: Errori di autenticazione:

  • Utilizza i binding di accesso utente per impostare durate massime della sessione rigorose. Configura il criterio di riautenticazione in modo che richieda SECURITY_KEY (FIDO2 o WebAuthn). Per applicare vincoli più rigidi agli ambienti ad alto rischio, configura scopedAccessSettings per ignorare le durate predefinite delle sessioni per le applicazioni sensibili.

Agent Gateway e Agent Identity

Agent Gateway e Agent Identity forniscono applicazione di criteri di rete dedicati, gestione del ciclo di vita delle identità e autenticazione crittografica per gli agenti di AI e i workflow agentici.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A07: Errori di autenticazione

Esamina le seguenti best practice per A01: Broken Access Control:

  • In ambienti con sistemi multi-agente, strumenti MCP esterni o pipeline autonome, utilizza Agent Gateway come punto di applicazione di rete e policy dedicato per contribuire a mitigare gli errori di controllo dell'accesso agentico.
  • Configura norme di autorizzazione granulare per le identità degli agenti per limitare l'accesso agli strumenti e il recupero dei dati solo alle risorse richieste per il flusso di lavoro specifico dell'agente.

Consulta le seguenti best practice per A07: Errori di autenticazione:

  • Per autenticare gli agenti autonomi e le integrazioni di strumenti senza incorporare password o chiavi API statiche, genera e assegna un'identità agente a ogni agente.
  • Configura l'identità dell'agente per emettere un certificato X.509 come credenziali dell'agente. Questi certificati contribuiscono a impedire il furto di token, in modo che se un token di accesso viene intercettato, non possa essere utilizzato da altri ambienti.

Apigee

Apigee fornisce meccanismi centralizzati a livello di gateway utilizzando proxy API per applicare standard crittografici, convalidare i payload firmati e criptare i dati delle applicazioni in transito e inattivi. Fungendo da gateway proxy inverso per il traffico API, Apigee esegue controlli di limite e struttura per convalidare i payload. Apigee fornisce criteri integrati di autenticazione API, OAuth e verifica del token web JSON (JWT) per stabilire limiti di identità rigorosi. Apigee include diversi modi per eseguire logging, monitoraggio, gestione degli errori e audit log.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A04: Errori crittografici
  • A05: Injection
  • A06: Progettazione non sicura
  • A07: Errori di autenticazione
  • A09: Security Logging & Alerting Failures

Esamina le seguenti best practice per A01: Broken Access Control:

  • Utilizza i proxy API per completare le seguenti operazioni:

    • Intercetta le richieste in cui un malintenzionato tenta di accedere ai record di un altro utente manipolando le variabili ID nel percorso della richiesta API.

    • Impedisci ai client standard di eseguire metodi amministrativi con limitazioni o operazioni con privilegi elevati.

  • Per il piano di gestione delle API, applica i controlli dell'accesso, l'autenticazione e l'archiviazione dei secret utilizzando mappe chiave-valore criptate, Secret Manager o secret Kubernetes (solo deployment ibridi).

  • Utilizza i token OAuth e JWT per verificare le firme. Mappa gli endpoint e le azioni sensibili in ambiti OAuth granulari con privilegi elevati (ad esempio delete:account o write:billing). Utilizza le norme OAuthV2 per convalidare questi ambiti nel punto di ingresso dell'API e restituire un codice di stato HTTP 403 Forbidden a qualsiasi client che non disponga delle autorizzazioni corrette.

  • Abilita Advanced API Security per analizzare il traffico alla ricerca di pattern comportamentali anomali e avviare azioni di sicurezza.

Consulta le seguenti best practice per A04: Failures crittografici:

  • Cripta i dati sensibili nella tua applicazione e applica una rigorosa convalida crittografica prima che il traffico raggiunga l'applicazione di backend. Configura il tuo ambiente Apigee con le chiavi di crittografia gestite dal cliente (CMEK) utilizzando Cloud KMS.
  • Utilizza TLS unidirezionale e bidirezionale per criptare le informazioni sensibili a livello di protocollo. Per le integrazioni aziendali da server a server o ad alto rischio, configura mutual TLS (mTLS) nel gateway in entrata Apigee.
  • Utilizza i criteri VerifyJWT e VerifyJWS per richiedere che i token in entrata abbiano una firma crittografica valida prima che la richiesta venga elaborata. Utilizza tecniche OAuth standard e valuta l'implementazione di HMAC, hashing del payload, convalida di stato o nonce e Proof Key for Code Exchange (PKCE) per proteggere crittograficamente ogni richiesta.
  • Maschera i dati sensibili in modo che vengano criptati e nascosti quando utilizzi lo strumento di debug di Apigee.

Consulta le seguenti best practice per A05: Injection:

Esamina le seguenti best practice per A06: Progettazione non sicura:

  • Convalida le richieste in entrata con il criterio OASValidation per i messaggi di richiesta o risposta in entrata rispetto alla specifica OpenAPI.
  • Mitiga i picchi di traffico e il sovraccarico del backend implementando il criterio SpikeArrest e il criterio Quota.
  • Utilizza le regole di gestione dei guasti per intercettare gli errori di backend (ad esempio un arresto anomalo del database) e riscriverli in risposte HTTP generiche.

Consulta le seguenti best practice per A07: Errori di autenticazione:

  • Implementa la convalida della chiave API per le API rivolte agli sviluppatori in modo che Apigee possa verificare se la chiave API di un'applicazione client è presente, valida e autorizzata ad accedere alla risorsa API richiesta.
  • Per contribuire a prevenire il furto di token di sessione e gli attacchi di replay, implementa la dimostrazione della prova di possesso (DPoP). DPoP associa i token alla chiave pubblica del mittente per ridurre il rischio di replay dei token.
  • Proteggi la generazione di token e gli endpoint di accesso da attacchi di forza bruta automatizzati combinando i limiti di frequenza di SpikeArrest con l'integrazione di reCAPTCHA Enterprise.

Consulta le seguenti best practice per A09: Errori di logging e avvisi di sicurezza:

  • Trasmetti in streaming in modo asincrono i metadati delle transazioni API strutturate a Logging o a SIEM di terze parti. Allega le tue MessageLogging norme a PostClientFlow, che viene eseguito dopo che la risposta è stata recapitata al client.
  • Centralizza i log di controllo della piattaforma per monitorare le modifiche apportate a proxy API, credenziali e ambienti di deployment. Per evitare che le modifiche non autorizzate ai proxy passino inosservate, integra Apigee con Cloud Audit Logs. Per saperne di più, consulta Audit logging di Apigee e Audit logging di Apigee API Management.
  • Configura gli avvisi di Advanced API Security in Monitoring per comunicare ai team SecOps campagne di scraping automatizzate, abusi delle credenziali e regressioni del punteggio di sicurezza.
  • Sanitizza le variabili fornite dall'utente nei modelli di messaggi di log racchiudendole nella funzione escapeJSON().
  • Se trasmetti in streaming i metadati dei log a un SIEM esterno, configura il criterio MessageLogging per utilizzare Syslog su TLS (porta TCP 6514) per criptare i dati in transito.

Artifact Registry e Artifact Analysis

Artifact Registry offre una singola posizione da cui la tua organizzazione può gestire le immagini container e i pacchetti di linguaggio. Artifact Analysis fornisce analisi delle vulnerabilità integrata, generazione della distinta materiali del software (SBOM) e archiviazione dei metadati per gli artefatti archiviati in Artifact Registry.

Si applica a quanto segue:

  • A03: Errori nella catena di fornitura del software
  • A08: Errori di integrità del software o dei dati

Consulta le seguenti best practice per A03: guasti alla catena di fornitura del software:

  • Ridurre la superficie di attacco e contribuire a impedire il deployment di immagini legacy vulnerabili configurando criteri di pulizia per eliminare le immagini candidate al rilascio senza versione, senza tag o obsolete dopo un periodo di conservazione predefinito.
  • Proteggiti dagli attacchi di confusione delle dipendenze configurando i repository virtuali con le priorità dei repository upstream che danno la priorità ai repository di artefatti interni rispetto ai registri pubblici.
  • Applica tag immagine immutabili o esegui il deployment rigorosamente in base al digest crittografico (sha256:...) per impedire attacchi di mutazione dei tag.

Consulta le seguenti best practice per A08: Errori di integrità di software o dati:

Assured OSS

Assured OSS ti consente di incorporare i pacchetti OSS che Google convalida e utilizza nei tuoi flussi di lavoro per sviluppatori.

Si applica a quanto segue:

  • A03: Errori nella catena di fornitura del software
  • A08: Errori di integrità del software o dei dati

Consulta le seguenti best practice per A03: guasti alla catena di fornitura del software:

  • Configura i repository remoti in modo che puntino a monte ad Assured OSS.
  • Verifica che le librerie open source nelle tue build contengano una firma Google valida e un record di provenienza della build SLSA verificabile. Configura i controlli di qualità in Cloud Build per verificare queste attestazioni prima di compilare i binari dell'applicazione.
  • Configura i gestori di pacchetti (come pip.conf, settings.xml o build.gradle) nelle immagini di base di Cloud Workstations in modo che puntino solo ai repository Assured OSS interni.
  • Utilizza i metadati generati da Assured OSS per determinare se una CVE appena divulgata in un pacchetto open source è sfruttabile nel tuo contesto di deployment specifico.

Consulta le seguenti best practice per A08: Errori di integrità di software o dati:

Autorizzazione binaria

Autorizzazione binaria verifica l'integrità dei container in modo che venga eseguito il deployment solo delle immagini container attendibili. Puoi creare criteri per consentire o negare le implementazioni in base alla presenza o all'assenza di attestazioni. L'autorizzazione binaria applica i criteri a livello di cluster, quindi puoi configurare criteri diversi per ambienti diversi.

Si applica a quanto segue:

  • A03: Errori nella catena di fornitura del software
  • A08: Errori di integrità del software o dei dati

Consulta le seguenti best practice per A03: guasti alla catena di fornitura del software:

  • Configura le pipeline di deployment in modo che facciano riferimento alle immagini container e le applichino in base al digest crittografico SHA-256 univoco e immutabile (ad esempio @sha256).
  • Esegui il deployment di Autorizzazione binaria - Convalida continua sui tuoi cluster GKE per monitorare i pod attivi rispetto alle norme della tua piattaforma e generare avvisi in Logging se i container in esecuzione non sono più conformi.

Consulta le seguenti best practice per A08: Errori di integrità di software o dati:

  • Applica la generazione automatica dell'attestazione nelle pipeline Cloud Build o GitHub Actions. Crea requisiti di attestazione progressivi in modo che le immagini superino i gate di convalida sequenziali man mano che si avvicinano alla produzione.
  • Per gli incidenti di produzione di gravità elevata, attiva i deployment di emergenza breakglass. Configura le policy di avviso di Monitoring sugli eventi dei log di controllo breakglass per inviare una notifica al tuo team SecOps quando si verifica un bypass dell'ammissione.

CA Service and Certificate Manager

Certificate Authority Service (CA Service) semplifica il deployment e la gestione delle autorità di certificazione (CA) private. Certificate Manager fornisce provisioning, rinnovo e gestione centralizzati dei certificati TLS per Cloud Load Balancing e Cloud CDN.

Si applica ad A04: Errori crittografici.

Consulta le seguenti best practice:

  • Utilizza CA Service per automatizzare l'emissione e la gestione del ciclo di vita dei certificati privati. Esegui il deployment di CA radice e intermedie supportate da Cloud HSM per proteggere le chiavi private e utilizza i modelli di certificato per applicare criteri crittografici (come lunghezze minime delle chiavi e utilizzi delle chiavi estese consentiti).
  • Attiva Cloud Audit Logs per monitorare gli eventi amministrativi ad alto rischio (ad esempio la revoca della CA, gli aggiornamenti delle norme o un improvviso picco di richieste di certificati). Instrada gli avvisi a Google SecOps per rilevare potenziali minacce interne o pipeline CI/CD compromesse.
  • Configura Certificate Manager in modo che utilizzi i certificati gestiti da Google abbinati alle autorizzazioni DNS. Certificate Manager convalida la proprietà del dominio, emette il certificato X.509 e gestisce i rinnovi 30 giorni prima della scadenza.
  • Collega le mappe dei certificati ai proxy HTTPS di destinazione per attivare la selezione dinamica dei certificati e la rotazione dei certificati senza richiedere riavvii del proxy o riconfigurazioni del bilanciatore del carico.
  • Per i microservizi interni o il bilanciamento del carico ibrido, configura le mappe dei certificati per emettere certificati privati direttamente da un pool di CA del servizio CA privato.
  • Configura le mappe di certificati in modo che corrispondano alle richieste SNI (Server Name Indication) in entrata a certificati specifici.

Cloud Asset Inventory

Cloud Asset Inventory ti consente di monitorare la tua infrastruttura su Google Cloud per l'infrastruttura IT orfana o non autorizzata.

Si applica ad A02: Errore di configurazione della sicurezza.

Consulta le seguenti best practice:

  • Configura le notifiche per avvisarti in caso di risorse in esecuzione impreviste, che potrebbero essere protette in modo improprio o utilizzare software obsoleti.
  • Utilizza IAM Policy Analyzer per rilevare controlli dell'accesso configurati in modo errato, ad esempio bucket di archiviazione pubblici con l'autorizzazione allUsers, ruoli del account di servizio con privilegi eccessivi o identità orfane.
  • Esporta snapshot degli asset in BigQuery per controllare le configurazioni dell'infrastruttura nel tempo e mantenere un record di conformità di base in ambienti multi-progetto.

Cloud Armor

Cloud Armor è un web application firewall (WAF) adattivo che puoi implementare all'edge della tua rete Google Cloud per proteggerti dagli attacchi DDoS e bloccare i payload di iniezione SQLi o XSS. Cloud Armor include regole WAF preconfigurate per difendersi dalle vulnerabilità OWASP Top 10, limitare la superficie di attacco degli endpoint di autenticazione e bloccare le credenziali compromesse.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A05: Injection
  • A07: Errori di autenticazione
  • A08: Errori di integrità del software o dei dati
  • A10: Gestione errata di condizioni eccezionali

Esamina le seguenti best practice per A01: Broken Access Control:

Consulta le seguenti best practice per A05: Injection:

Consulta le seguenti best practice per A07: Errori di autenticazione:

  • Limita l'accesso agli endpoint di autenticazione e amministrativi a indirizzi IP o paesi autorizzati.
  • Attiva evaluatePreconfiguredWaf per intercettare e bloccare le richieste progettate per sfruttare le vulnerabilità dello stato della sessione e l'hijacking della sessione.
  • Utilizza l'API securityPolicies.patchRule per bloccare qualsiasi richiesta in entrata che contenga un parametro compromesso nella stringa di query o nelle intestazioni all'edge della rete.

Consulta le seguenti best practice per A08: Errori di integrità di software o dati:

  • Limita gli endpoint che accettano oggetti serializzati ad alto rischio da fonti non attendibili a un insieme di indirizzi IP attendibili con una regola di negazione simile alla seguente:

    request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')

  • Implementa regole personalizzate per esaminare le parole chiave del corpo della richiesta per individuare pattern di esecuzione specifici della lingua e firme di deserializzazione non sicure.

Esamina le seguenti best practice per A10: Mishandling of Exceptional Conditions:

  • Attiva Google Cloud Armor Adaptive Protection nelle tue policy di sicurezza per stabilire una base di riferimento per i normali pattern di traffico, configurare avvisi per anomalie di livello 7 e generare regole WAF mirate con firme di attacco.
  • Configura le regole di limitazione di frequenza di Cloud Armor sugli endpoint critici (ad esempio, le API /login, /checkout o di ricerca). Le regole di limitazione della frequenza limitano le richieste in base all'intestazione HTTP o all'IP per client (ad esempio, limitando i client a 100 richieste al minuto) e restituiscono un codice di stato HTTP 429 Too Many Requests.
  • Imposta la regola predefinita con priorità più bassa nella policy di sicurezza di Cloud Armor su Deny (codice di stato: 403 o 404).

Cloud Build e Cloud Deploy

Cloud Build e Cloud Deploy forniscono una pipeline di integrazione continua e distribuzione continua (CI/CD) integrata e sicura su Google Cloud. Cloud Build crea artefatti con provenance SLSA verificabile e attestazioni crittografiche, mentre Cloud Deploy gestisce implementazioni progressive, approvazioni di destinazione e verifica automatica in GKE e Cloud Run.

Si applica a quanto segue:

  • A03: Errori nella catena di fornitura del software
  • A08: Errori di integrità del software o dei dati

Consulta le seguenti best practice per A03: guasti alla catena di fornitura del software:

  • Imposta requestedVerifyOption: VERIFIED nel file cloudbuild.yaml in modo da richiedere una provenienza verificabile.
  • Esegui il deployment di pool privati di Cloud Build in peering con la tua rete VPC privata per build aziendali sensibili.
  • Configura i trigger di build da eseguire con service account dedicati e gestiti dall'utente. Concedi a questi service account solo le autorizzazioni IAM consentite minime richieste (ad esempio Writer di Artifact Registry (roles/artifactregistry.writer) e Writer di log (roles/logging.logWriter)).
  • Richiedi approvazioni manuali sui trigger di Cloud Build che hanno come target ambienti di gestione temporanea o produzione.
  • Limita gli strumenti di build CI (come Cloud Build, GitHub Actions o GitLab) al ruolo Cloud Deploy Releaser (roles/clouddeploy.releaser) in modo che le pipeline di build possano creare solo release.
  • Per richiedere approvazioni manuali, configura il manifest della pipeline di distribuzione (delivery-pipeline.yaml) con requireApproval: true nelle destinazioni di staging e produzione.
  • Configura gli ambienti di esecuzione con service account specifici per la destinazione (ad esempio, un account di servizio con autorizzazioni limitate allo spazio dei nomi di staging e un account di servizio separato e sottoposto a audit per la produzione).
  • Esegui il deployment di hook personalizzati per eseguire asserzioni di sicurezza fuori banda durante il ciclo di vita dell'implementazione. Utilizza gli hook pre-deployment per verificare se i cluster di destinazione soddisfano le baseline di conformità e gli hook post-deployment per avviare scansioni automatiche delle vulnerabilità rispetto agli endpoint dei container attivi.

Consulta le seguenti best practice per A08: Errori di integrità di software o dati:

  • Integra Cloud Build con Cloud KMS e Artifact Analysis per creare e firmare attestazioni crittografiche al termine dei test delle unità e di analisi statica.
  • Utilizza i digest SHA-256 crittografici immutabili (ad esempio, golang@sha256:...) nei passaggi del builder in cloudbuild.yaml.
  • Archivia le configurazioni di build in repository con controllo delle versioni protetti da regole di protezione dei rami (ad esempio, l'obbligo di revisioni da parte di due persone per le richieste di pull). Limita le autorizzazioni di modifica dei trigger agli amministratori della piattaforma autorizzati che utilizzano service account gestiti dall'utente.
  • Promuovi manifest di deployment identici e pre-renderizzati e digest di immagini container immutabili nelle fasi di destinazione senza consentire alle pipeline CI di modificare i manifest tra lo staging e la produzione.
  • Definisci le attività di verifica del deployment automatizzate all'interno del manifest skaffold.yaml. Cloud Deploy esegue questi container di verifica dopo che i pod vengono implementati per eseguire controlli di integrità dinamici, test di integrazione e asserzioni del contratto API.
  • Utilizza le strategie di deployment canary. Se un test di verifica Skaffold non riesce o il monitoraggio rileva soglie di anomalie durante una fase canary, Cloud Deploy interrompe l'implementazione e ripristina il traffico all'ultima versione di release nota.
  • Configura i cluster GKE e Cloud Run per applicare le norme di Autorizzazione binaria. Quando Cloud Deploy applica i manifest, il controller di ammissione di destinazione verifica crittograficamente i digest delle immagini container e rifiuta gli artefatti non attendibili.

Cloud Identity e token di sicurezza Titan

Cloud Identity fornisce identità centralizzata, ciclo di vita delle credenziali e gestione dell'accesso in Google Cloude Google Workspace. I token di sicurezza Titan sono dispositivi di sicurezza basati su hardware e resistenti al phishing che utilizzano la crittografia a chiave pubblica basata sugli standard FIDO2 o WebAuthn.

Si applica ad A07: errori di autenticazione.

Consulta le seguenti best practice:

  • Per proteggerti dagli attacchi di phishing di tipo person-in-the-middle (PITM), configura la verifica in due passaggi (V2P) e imposta il metodo consentito su Solo token di sicurezza (FIDO2, WebAuthn o token di sicurezza Titan).
  • Configura il Single Sign-On (SSO) basato su SAML 2.0 o OIDC con il tuo provider di identità aziendale insieme al provisioning automatico.
  • Imposta il criterio durata sessione su una soglia massima bassa per forzare gli utenti a eseguire nuovamente l'autenticazione periodicamente.Google Cloud
  • Registra i token di sicurezza Titan come passkey per attivare l'autenticazione senza password, riducendo significativamente i rischi di attacchi di forza bruta e compromissione delle credenziali.
  • Imponi l'autenticazione a due fattori con i token di sicurezza Titan per le tue identità con privilegi (come proprietari di progetti, amministratori della fatturazione e team SecOps) applicando le norme relative ai token di sicurezza in Cloud Identity. Registra gli utenti ad alto rischio al programma di protezione avanzata.

Cloud KMS

Cloud KMS gestisce chiavi di crittografia simmetriche e asimmetriche per servizi Google Cloud compatibili e nelle tue applicazioni. Puoi generare, utilizzare, ruotare ed eliminare chiavi di crittografia per la crittografia simmetrica, la firma asimmetrica, la crittografia asimmetrica e la firma MAC.

Si applica ad A04: Errori crittografici.

Consulta le seguenti best practice:

  • Utilizza Cloud KMS Autokey per automatizzare il provisioning e l'assegnazione. Con Autokey, non devi eseguire il provisioning di portachiavi, chiavi e service account in anticipo. Vengono invece generate on demand durante la creazione delle risorse.
  • Utilizza le chiavi Cloud KMS per criptare i payload sensibili prima che vengano inviati ai bucket di archiviazione o ai database. Puoi utilizzare l'API Cloud KMS o le librerie client per utilizzare le chiavi Cloud KMS per la crittografia lato client.
  • Verifica l'integrità dei dati end-to-end con la convalida dei checksum durante il transito.
  • Per carichi di lavoro di conformità e normativi rigorosi, archivia ed esegui le operazioni crittografiche utilizzando Cloud HSM. Cloud HSM archivia le chiavi in moduli di sicurezza hardware convalidati secondo lo standard FIPS 140-3 di livello 3.
  • Configura pianificazioni di rotazione della chiave automatica in un periodo di tempo prestabilito (ad esempio, ogni 90 giorni).

Cloud Load Balancing

Cloud Load Balancing è un servizio gestito software-defined completamente distribuito che distribuisce il traffico utente su più istanze di backend e regioni.

Si applica a quanto segue:

  • A04: Errori crittografici
  • A10: Gestione errata di condizioni eccezionali

Consulta le seguenti best practice per A04: Failures crittografici:

Esamina le seguenti best practice per A10: Mishandling of Exceptional Conditions:

Google Cloud Observability (logging, monitoraggio e Error Reporting)

Google Cloud Observability fornisce la gestione dei log full-stack con Logging, metriche e avvisi con Monitoring e monitoraggio in tempo reale degli arresti anomali delle applicazioni con Error Reporting.

Si applica a quanto segue:

  • A09: Security Logging & Alerting Failures
  • A10: Gestione errata di condizioni eccezionali

Consulta le seguenti best practice per A09: Errori di logging e avvisi di sicurezza:

  • Abilita i log di accesso ai dati per i repository di dati di alto valore (come Cloud Storage, BigQuery e Spanner) che archiviano dati sensibili. I log di accesso ai dati ti consentono di controllare ogni evento di lettura, scrittura e query per i dati sensibili.
  • Applica Bucket Lock e le norme di conservazione per il bucket di logging personalizzato per impedire ad aggressori o amministratori non autorizzati di eliminare i log per coprire le proprie tracce.
  • Utilizza i sink aggregati per raccogliere e indirizzare le voci di log in un unico repository centrale per i tuoi team SecOps. Configura i sink aggregati di intercettazione per evitare di archiviare log ad alto volume come i log di accesso ai dati in più di una posizione.
  • Configura policy di avviso basate sui log per indicatori critici di compromissione, come errori IAM di tipo Autorizzazione negata, creazioni impreviste di chiavi API o modifiche improvvise alla configurazione del firewall.
  • Implementa criteri di avviso basati su log in Esplora log o Monitoring. Specifica filtri esatti che hanno come target eventi di gravità elevata, come modifiche non autorizzate alle policy IAM o revoche delle chiavi KMS, in modo che venga generata una notifica di incidente quando viene inserita una voce di log corrispondente.
  • Crea metriche di conteggio basate su log in Logging per convertire le voci di log corrispondenti in dati di serie temporali. Poi, crea un criterio di avviso basato su metriche in Monitoring che avvii un incidente quando la frequenza supera una soglia specifica (ad esempio, più di 50 tentativi di accesso non riusciti in cinque minuti).
  • Configura policy di avviso basate su log che monitorano le chiamate amministrative all'API Cloud Logging e inviano avvisi in caso di modifiche impreviste al sink di esportazione dei log o eliminazioni di bucket.
  • Configura i canali di notifica con modelli di documentazione chiari. Includi link diretti e profondi alla query di Esplora log, procedure operative standard (SOP) per l'ingegnere di turno e passaggi di correzione espliciti per contribuire a contenere rapidamente l'incidente.

Esamina le seguenti best practice per A10: Mishandling of Exceptional Conditions:

  • Integra gli SDK Error Reporting direttamente nel codice dell'applicazione o configura Logging per analizzare i formati JSON strutturati delle eccezioni.
  • Configura i canali di notifica di Error Reporting o i criteri di avviso di Monitoring per inviare una notifica ai tuoi team SecOps quando viene visualizzata una nuova classe di eccezioni.

Cloud NGFW

Cloud NGFW è un servizio firewall gestito che consente l'ispezione stateful e il controllo delle applicazioni di livello 7 per il traffico nord/sud ed est/ovest.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A05: Iniezione

Esamina le seguenti best practice per A01: Broken Access Control:

Consulta le seguenti best practice per A05: Injection:

  • Configura il servizio di rilevamento e prevenzione delle intrusioni con un gruppo di profili di sicurezza che nega le minacce che corrispondono a firme di exploit di SQL injection, OS command injection ed esecuzione di codice remoto.
  • Configura l'ispezione TLS di Cloud NGFW per decriptare il traffico HTTPS in entrata e in uscita, applica i controlli della firma di inserimento IPS al payload in testo non crittografato e cripta nuovamente la sessione prima della consegna al backend.
  • Applica regole firewall di uscita basate su FQDN ai database di backend e alle subnet di Compute. Limita le connessioni in uscita a domini esterni approvati e predefiniti per impedire alle applicazioni vulnerabili di creare shell reverse non autorizzate.
  • Attiva il logging delle regole firewall nei profili di prevenzione delle minacce e indirizza questi log in Google SecOps per correlare le firme di iniezione di rete bloccate con la telemetria a livello di host, identificando i workload di destinazione per l'applicazione di patch prioritaria.

Cloud Workstations

Cloud Workstations fornisce ambienti di sviluppo gestiti su Google Cloud con sicurezza e personalizzazioni integrate.

Si applica a quanto segue:

  • A03: Errori nella catena di fornitura del software
  • A04: Errori crittografici

Consulta le seguenti best practice per A03: guasti alla catena di fornitura del software:

  • Crea immagini container di base personalizzate archiviate in Artifact Registry che preinstallano strumenti di sicurezza, estensioni per sviluppatori attendibili e runtime di linguaggio approvati.
  • Esegui il deployment dei cluster di workstation con ingresso e uscita IP privati e all'interno di un perimetro dei Controlli di servizio VPC.
  • Configura Cloud Workstations per instradare il traffico di sessione tramite IAP. Richiedi agli sviluppatori di autenticarsi utilizzando le credenziali aziendali con l'autenticazione a più fattori (MFA) abilitata e applica ruoli con privilegi minimi (ad esempio, utente Cloud Workstations (roles/workstations.user)).
  • Configura le configurazioni della workstation con limiti di timeout bassi (ad esempio, arresto automatico dopo due ore di inattività). Quando una workstation viene riavviata, Cloud Workstations recupera l'ultima immagine container con patch di sicurezza, in modo che gli sviluppatori possano lavorare in un ambiente pulito.

Consulta le seguenti best practice per A04: Failures crittografici:

CodeMender

CodeMender è un agente di ingegneria AI autonomo e specializzato. CodeMender può correggere le vulnerabilità appena scoperte e riscrivere il codice legacy esistente per risolvere quelle esistenti. Puoi installare e configurare CodeMender in Gemini Enterprise Agent Platform.

Si applica a quanto segue:

  • A03: Errori nella catena di fornitura del software
  • A05: Iniezione
  • A06: Progettazione non sicura

Consulta le seguenti best practice per A03: guasti alla catena di fornitura del software:

Consulta le seguenti best practice per A05: Injection:

  • Esegui la generazione automatica di patch all'interno di sandbox locali isolate per riscrivere la logica vulnerabile (ad esempio la sanificazione degli input). Prima di creare le richieste pull, verifica che i test unitari vengano superati e che le prove di concetto non siano più sfruttabili.

Esamina le seguenti best practice per A06: Progettazione non sicura:

  • Rifattorizza la logica del codice architetturale legacy o non sicuro utilizzando il motore di patch iterativo di CodeMender, fornendo vincoli di codifica espliciti per applicare pattern di progettazione sicuri nei moduli dell'applicazione.
  • Esegui una revisione human-in-the-loop per le richieste pull e le differenze generate da CodeMender per verificare che le modifiche proposte siano in linea con le tue linee guida per la programmazione sicura.

Confidential Computing

Confidential Computing aiuta a proteggere i dati in uso mantenendoli criptati in memoria durante l'elaborazione. Utilizzando Trusted Execution Environment (TEE) basati su hardware, Confidential Computing contribuisce a garantire che i tuoi dati sensibili e le chiavi crittografiche non siano accessibili all'hypervisor, al sistema operativo host o agli amministratori dell'infrastruttura.

Si applica ad A04: Errori crittografici.

Consulta le seguenti best practice:

  • Utilizza Confidential VM o Confidential GKE Nodes per carichi di lavoro altamente sensibili (come PII, registri finanziari o pesi di modelli di AI proprietari).
  • Quando più organizzazioni devono mettere in comune dati sensibili per l'analisi o l'addestramento dell'AI (senza esporsi reciprocamente i dati non elaborati), utilizza Confidential Space per applicare l'attestazione crittografica e l'isolamento dei dati.

Firebase (Firebase Authentication, Firebase App Check e Regole di sicurezza Firebase)

Firebase fornisce controlli di sicurezza incentrati sugli sviluppatori per identità, attestazione del client e accesso al database. Firebase Authentication gestisce l'identità e la gestione delle sessioni degli utenti, App Check convalida l'integrità dell'app client e le regole di sicurezza di Firebase applicano il controllo dell'accesso basato sugli attributi e la convalida dello schema per Firestore e Cloud Storage.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A05: Injection
  • A07: Errori di autenticazione
  • A08: Errori di integrità del software o dei dati

Esamina le seguenti best practice per A01: Broken Access Control:

  • L'ambito legge e scrive nell'ID dell'utente autenticato nelle regole di sicurezza di Firebase. Non utilizzare mai regole predefinite permissive come allow read, write: if true;.
  • Per i ruoli amministrativi, utilizza gli SDK Firebase Admin per impostare rivendicazioni personalizzate sui token ID degli utenti e convalidale nelle regole di sicurezza anziché consentire le scritture del profilo lato client.
  • Applica App Check nelle regole di sicurezza di Firebase per bloccare l'accesso client non autenticato o falsificato a livello di database.

Consulta le seguenti best practice per A05: Injection:

  • Applica la convalida del payload strutturale nelle regole di sicurezza controllando i tipi di campi dei documenti in entrata, le lunghezze delle stringhe e le dimensioni degli oggetti per rifiutare i payload di scrittura malformati o dannosi prima dell'inserimento nel database.

Consulta le seguenti best practice per A07: Errori di autenticazione:

  • Esegui l'upgrade a Firebase Authentication con Identity Platform per attivare le protezioni aziendali come l'MFA con TOTP e le funzioni di blocco.
  • Verifica i token ID Firebase sul backend utilizzando l'SDK Firebase Admin prima di concedere l'accesso ai dati sensibili dell'applicazione.
  • Utilizza il provider di debug per generare token di debug temporanei e con ambito per i tuoi sviluppatori e le pipeline CI/CD negli ambienti di gestione temporanea.

Consulta le seguenti best practice per A08: Errori di integrità di software o dati:

  • Imponi ai fornitori di attestazione basata su hardware di verificare l'integrità del client. Configura App Check per utilizzare Android Play Integrity e Apple App Attest.
  • Esegui il deployment del middleware di verifica del token App Check sui backend API Cloud Run e API Kubernetes Engine per rifiutare le richieste provenienti da chiavi API sottoposte a scraping, script automatizzati o ambienti emulati.

Fraud Defense

Fraud Defense è una piattaforma unificata per la difesa da frodi e abusi, inclusa la protezione di bot, account e transazioni per il web. reCAPTCHA, un'offerta che fa parte di Fraud Defense, filtra i bot e altre forme di automazione e traffico collettivo valutando il livello di rischio dei tentativi di accesso.

Si applica ad A07: errori di autenticazione.

Consulta le seguenti best practice:

  • Integra reCAPTCHA con il tuo WAF esistente, ad esempio Google Cloud Armor, per emettere verifiche automatiche o bloccare il traffico dei bot ad alto rischio prima che le richieste raggiungano gli endpoint di autenticazione.
  • Proteggi gli account negli endpoint di accesso, reimpostazione della password e rinnovo della sessione. Ottieni punteggi di rischio di takeover dell'account (ATO) in base alla velocità di accesso degli utenti e alle impronte dei dispositivi.
  • Difenditi dalle frodi tariffarie SMS nei moduli di registrazione e autenticazione a due fattori valutando i profili di rischio dei numeri di telefono prima di inviare messaggi SMS in uscita.
  • Per ridurre i falsi positivi e addestrare modelli di valutazione del rischio specifici per il sito, annota e invia regolarmente il feedback sulle transazioni.
  • Controlla le password durante i flussi di accesso e creazione di account per rilevare se le credenziali inviate vengono visualizzate in database di violazione dei dati di terze parti sul web.

Google SecOps

Google Security Operations è una piattaforma di operazioni di sicurezza che combina l'analisi della telemetria di sicurezza (SIEM), l'orchestrazione, l'automazione e la risposta della sicurezza (SOAR) e la threat intelligence di prima linea di Mandiant in un'unica piattaforma.

Si applica a quanto segue:

  • A02: Errata configurazione della sicurezza
  • A09: Security Logging & Alerting Failures

Esamina le seguenti best practice per A02: Errata configurazione della sicurezza:

  • Importa i risultati di Security Command Center in Google SecOps per combinare i risultati di configurazione errata statica (ad esempio PUBLIC_BUCKET_ACL o CMEK_DISABLED) con la telemetria di rete e firewall in tempo reale.
  • Crea playbook di risposta SOAR automatizzati per eseguire azioni di contenimento.
  • Utilizza Gemini per accelerare la valutazione della priorità degli errori di configurazione e per ricevere riepiloghi sintetici degli asset configurati in modo errato, dei ruoli IAM collegati e indicazioni dettagliate per la correzione.

Consulta le seguenti best practice per A09: Errori di logging e avvisi di sicurezza:

  • Normalizza la telemetria dei log in base al modello di modello dei dati (UDM) per consentire la ricerca e la correlazione multicloud rapide e standardizzate senza l'overhead dell'analisi dei log non elaborati.
  • Scrivi regole di rilevamento YARA-L 2.0 per monitorare le modifiche alla configurazione ad alto rischio, come la disattivazione di OS Login, l'eliminazione dei sink Logging o le modifiche ai perimetri dei Controlli di servizio VPC.
  • Utilizza i rilevamenti curati di Applied Threat Intelligence per valutare i dati degli eventi rispetto ai dati di Mandiant Threat Intelligence.
  • Utilizza Gemini in Google SecOps per generare regole di rilevamento YARA-L a partire da descrizioni in linguaggio naturale e riassumere cronologie di incidenti complesse e multistadio in riepiloghi esecutivi degli incidenti.

Identity-Aware Proxy

IAP crea un livello di autorizzazione centrale per le applicazioni a cui si accede tramite HTTPS e connessioni TCP amministrative. IAP verifica l'identità e il contesto dell'utente prima di concedere l'accesso a Cloud Run, App Engine, Compute Engine, GKE e risorse on-premise.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A07: Errori di autenticazione

Esamina le seguenti best practice per A01: Broken Access Control:

  • Applica controlli dell'accesso granulari ad applicazioni web, VM, API e applicazioni Google Workspace in base all'identità dell'utente, all'iscrizione al gruppo e al contesto della richiesta. Google Cloud
  • Esegui l'integrazione con Agent Gateway per applicare i controlli dell'accesso per le identità degli agenti.
  • Utilizza l'inoltro TCP di IAP per stabilire tunnel HTTPS criptati alle tue istanze di backend e rimuovere gli endpoint SSH (porta 22) e RDP (porta 3389) esposti a internet.

Consulta le seguenti best practice per A07: Errori di autenticazione:

  • Autentica gli utenti che accedono a interfacce amministrative e applicazioni web tramite IAP utilizzando le identità di cui è stato eseguito il provisioning in IAM o Cloud Identity.
  • Verifica l'asserzione JWT firmata all'interno dell'intestazione x-goog-iap-jwt-assertion a livello di applicazione. Convalida la firma rispetto alle chiavi pubbliche di Google e verifica che l'attestazione del pubblico (aud) corrisponda all'ID del tuo servizio di backend.
  • Per impedire agli autori di attacchi di bypassare l'autenticazione IAP, configura le impostazioni di traffico in entrata di Cloud Run per consentire solo il traffico interno e di Cloud Load Balancing, bloccando l'accesso pubblico diretto agli URL dei container di backend. Per le VM o i nodi GKE, configura le regole firewall VPC per accettare solo il traffico in entrata proveniente dagli intervalli IP del bilanciatore del carico.

Identity and Access Management

Identity and Access Management (IAM) ti consente di gestire l'accesso granulare a servizi e risorse in Google Cloud. IAM include funzionalità come le seguenti:

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A07: Errori di autenticazione

Esamina le seguenti best practice per A01: Broken Access Control:

  • Utilizza ruoli predefiniti o personalizzati (non ruoli di base) per limitare le autorizzazioni a esigenze specifiche di risorse o utenti.
  • Limita le autorizzazioni per concedere i ruoli Utente account di servizio (roles/iam.serviceAccountUser) e Creatore token account di servizio (roles/iam.serviceAccountTokenCreator).
  • Utilizza IAM Recommender per analizzare i log di utilizzo attivo della tua organizzazione e rimuovere gli account con privilegi eccessivi.
  • Scrivi condizioni IAM nei binding dei ruoli per aggiungere l'autorizzazione sensibile al contesto e limitare l'accesso in base a data, ora del giorno o indirizzo IP di origine.
  • Implementa le policy sul confine di accesso dell'entità (PAB) per definire le organizzazioni, le cartelle o i progetti a cui un insieme di entità può accedere. Se un malintenzionato ruba una sessione attiva o a un account di servizio vengono concessi accidentalmente ruoli IAM ampi, PAB blocca l'accesso se la risorsa specificata si trova al di fuori del limite designato dell'identità.
  • Collega criteri di negazione IAM a livello di organizzazione o cartella per bloccare le autorizzazioni ad alto rischio (come iam.serviceAccountKeys.create o resourcemanager.projects.delete).
  • Quando configuri le regole di negazione IAM, dichiara un gruppo di sicurezza breakglass dedicato nell'elenco exceptionPrincipals. Utilizza i tag delle risorse nelle condizioni di negazione (ad esempio resource.matchTag('env', 'prod')) in modo che le azioni distruttive vengano bloccate sulle risorse di produzione, consentendo al contempo agli sviluppatori la flessibilità operativa nei progetti sandbox di sviluppo.

Consulta le seguenti best practice per A07: Authentication Failures che si applicano a Privileged Access Manager:

  • Converti i ruoli amministrativi critici (come Proprietario (roles/owner), Amministratore organizzazione (roles/resourcemanager.organizationAdmin) e Amministratore sicurezza (roles/iam.securityAdmin)) da associazioni IAM statiche in diritti di Privileged Access Manager. Configura questi diritti in modo che richiedano una giustificazione operativa prima che venga concesso l'accesso con privilegi elevati.
  • Per gli ambienti di produzione, configura i criteri di assegnazione dei diritti di Privileged Access Manager con approvatori obbligatori, ad esempio un gruppo SecOps centrale o i responsabili del team.
  • Configura la durata massima dei diritti di Privileged Access Manager sulla finestra operativa realistica più breve (ad esempio, due ore per la manutenzione standard, 30 minuti per le azioni di breakglass). Quando il timer scade, Google Cloud rimuove l'associazione temporanea del ruolo IAM.
  • Gestisci l'infrastruttura Terraform utilizzando risorse IAM non autorevoli (ad esempio google_project_iam_member o google_folder_iam_member anziché google_project_iam_policy o google_project_iam_binding). Questa pratica evita di sovrascrivere le pipeline Terraform o di desincronizzare i binding dei ruoli temporanei di Privileged Access Manager mentre un amministratore sta risolvendo attivamente un incidente.
  • Abilita Cloud Audit Logs in Privileged Access Manager per registrare le azioni sui diritti e gli eventi di scadenza. Importa questi log in Google SecOps per ricevere avvisi su pattern di elevazione sospetti, ad esempio più richieste di elevazione fuori orario o richieste ripetute da geolocalizzazioni impreviste.

Esamina le seguenti best practice per A07: Authentication Failures (Errori di autenticazione) che si applicano a Federazione delle identità per la forza lavoro:

  • Esegui il deployment di pool di identità della forza lavoro utilizzando SAML 2.0 o OpenID Connect (OIDC) per federare i provider di identità esterni conGoogle Cloud.
  • Configura la durata della sessione nel pool di identità per la forza lavoro per limitare la durata dei token utente federati.
  • Applica le condizioni degli attributi ai provider di identità per la forza lavoro per ridurre la falsificazione dei token IdP multi-tenant o l'impersonificazione tra organizzazioni.
  • Mappa le appartenenze a gruppi esterni per assegnare ruoli IAM a insiemi di entità di gruppi federati (ad esempio, principalSet://iam.googleapis.com/.../attribute.group/security-engineers).

Esamina le seguenti best practice per A07: Authentication Failures (Errori di autenticazione) che si applicano alla federazione delle identità per i workload:

  • Crea pool di identità del workload e provider per i carichi di lavoro esterni. Utilizza token OIDC di breve durata, scambiandoli dinamicamente utilizzando Security Token Service per token di accesso temporanei che scadono in pochi minuti.
  • Applica condizioni degli attributi ai provider di identità dei workload in modo che le piattaforme multitenant esterne non possano autenticarsi nel tuo pool da repository o account non autorizzati.
  • Associa i ruoli IAM direttamente a set di entità specifici filtrati in base agli attributi mappati personalizzati.
  • Quando configuri l'accesso ai workload, concedi i ruoli IAM direttamente all'identificatore principalSet:// federato sulla risorsa di destinazione.
  • Per applicare la federazione delle identità per i workload, imposta il vincolo constraints/iam.disableServiceAccountKeyCreation sulla tua organizzazione.

Identity Platform

Identity Platform è la piattaforma di gestione di identità e accessi cliente (GIAC) per i clienti di Google Cloud . Identity Platform fornisce l'autenticazione con supporto multiprotocollo utilizzando SDK e API. Identity Platform supporta l'autenticazione aMFAi, l'integrazione con servizi di autenticazione di terze parti e il monitoraggio dell'attività controllabile.

Si applica ad A07: errori di autenticazione.

Consulta le seguenti best practice:

  • Abilita l'MFA per tutta la base utenti. Dai la priorità ai metodi resistenti al phishing, come TOTP (app di autenticazione) o WebAuthn (biometria e token di sicurezza).
  • Esegui il deployment di funzioni di blocco Cloud Run utilizzando i trigger beforeCreate e beforeSignIn per eseguire codice di sicurezza personalizzato prima che un utente venga salvato o venga emesso un token. Questa pratica ti consente di bloccare i domini email temporanei, limitare gli indirizzi IP o richiedere la verifica dell'email.
  • Esegui l'integrazione con reCAPTCHA Enterprise per valutare le richieste di accesso, registrazione e reimpostazione della password per il traffico di bot, i tentativi di credential stuffing e gli abusi automatizzati.
  • Configura norme per le password per imporre lunghezze minime dei caratteri, richiedere complessità specifiche dei caratteri (come numeri e simboli) e bloccare sequenze prevedibili.
  • Se utilizzi l'autenticazione MFA basata sul telefono, configura le regioni SMS e attiva reCAPTCHA SMS defense per limitare i messaggi di verifica ai codici paese in cui risiedono gli utenti target.

Soluzioni Mandiant AI Security Consulting

Soluzioni di Mandiant AI Security Consulting possono valutare le architetture software, i processi aziendali e i deployment cloud proposti nelle prime fasi del ciclo di vita dello sviluppo. Applicando l'intelligence sulle minacce in prima linea alla progettazione del sistema, i consulenti Mandiant aiutano a esporre difetti logici nascosti, limiti di attendibilità mancanti e rischi architetturali prima che venga scritta una sola riga di codice.

Si applica ad A06: Progettazione non sicura.

Consulta le seguenti best practice:

  • Coinvolgi i consulenti Mandiant prima dell'inizio dello sviluppo per completare i workshop sull'architettura e implementare i controlli di sicurezza fin dall'inizio.
  • Collabora con esperti di modellazione delle minacce per mappare i diagrammi di flusso dei dati della tua applicazione. Definisci dove i dati sensibili superano i limiti di attendibilità per identificare dove devono essere applicati controlli rigorosi di autenticazione, crittografia e convalida.
  • Utilizza framework di modellazione delle minacce strutturati (ad esempio STRIDE) durante i workshop sull'architettura. I consulenti di Mandiant possono aiutarti a dare la priorità ai difetti di progettazione rilevati in base alla loro sfruttabilità nel mondo reale e all'impatto sull'attività.
  • Stabilisci baseline di governance dell'AI sicure per i workflow agentici e le implementazioni di LLM, definendo limiti di attendibilità chiari tra agenti AI, server MCP e origini dati di backend aziendali.

Model Armor

Model Armor è progettato per filtrare prompt, risposte e chiamate agli strumenti MCP degli LLM. Model Armor ispeziona i payload dell'AI generativa per rilevare e bloccare prompt injection, tentativi di jailbreak, URL dannosi, contenuti tossici e fughe di dati sensibili.

Si applica a quanto segue:

  • A05: Injection
  • A10: Gestione errata di condizioni eccezionali

Consulta le seguenti best practice per A05: Injection:

  • Esegui il deployment delle norme Model Armor inline a livello di gateway API utilizzando l'integrazione di Apigee o Agent Gateway per filtrare i prompt in entrata e le risposte del modello in uscita prima che il traffico raggiunga i motori di inferenza o i runtime degli strumenti.
  • Configura le impostazioni di base a livello di organizzazione o cartella per creare misure di protezione di base obbligatorie che i singoli team di progetto non possono ignorare.
  • Crea template Model Armor personalizzati con soglie di confidenza ottimizzate (ad esempio, LOW_AND_ABOVE o MEDIUM_AND_ABOVE) per l'injection di prompt e il rilevamento di jailbreak su endpoint pubblici.
  • Attiva il rilevamento di URL dannosi e la scansione di PDF e file nel modello Model Armor per controllare gli URL incorporati rispetto ai database di threat intelligence di Google. Elimina i prompt che contengono malware o vettori di phishing prima dell'esecuzione.
  • Abilita Sensitive Data Protection nel modello Model Armor per ispezionare il traffico di uscita del modello. Configura l'anonimizzazione o la mascheratura automatica per sostituire i dati sensibili rilevati con segnaposto prima che la risposta esca dal perimetro.

Esamina le seguenti best practice per A10: Mishandling of Exceptional Conditions:

  • Configura il codice dell'applicazione per intercettare i verdetti MATCH_FOUND e restituire una risposta generica, in modo che il sistema non esegua il prompt o non esponga le tracce delle eccezioni non elaborate per impostazione predefinita.
  • Implementa un'architettura fail-closed (fail-secure) nel codice dell'applicazione per rifiutare i prompt di AI generativa in entrata se le chiamate all'API Model Armor riscontrano timeout di rete, limiti di frequenza o errori HTTP 5xx non gestiti.

policy dell'organizzazione

La policy dell'organizzazione offre un controllo centralizzato e programmatico sulle risorse Google Cloud della tua organizzazione.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A02: Errata configurazione della sicurezza
  • A04: Errori crittografici

Esamina le seguenti best practice per A01: Broken Access Control:

  • Applica constraints/storage.publicAccessPrevention per eseguire l'override dei criteri IAM o degli ACL a livello di bucket che tentano di concedere l'accesso a allUsers o allAuthenticatedUsers.
  • Applica constraints/iam.allowedPolicyMemberDomains per limitare i binding dei criteri IAM rigorosamente agli ID cliente Google Workspace o Cloud Identity verificati.
  • Applica constraints/iam.disableServiceAccountKeyCreation nelle cartelle di produzione per impedire agli utenti di scaricare le chiavi degli account di servizio, costringendo i team di ingegneria ad adottare alternative di breve durata come la federazione delle identità per i workload.
  • Applica constraints/iam.automaticIamGrantsForDefaultServiceAccounts in modo che Google Cloud non conceda automaticamente il ruolo Editor (roles/editor) permissivo ai service account predefiniti.
  • Per i requisiti non coperti dai vincoli predefiniti, implementa vincoli personalizzati per applicare configurazioni delle risorse granulari. Valuta la possibilità di limitare la creazione di VM solo alle famiglie di macchine approvate, limitando le dimensioni del provisioning dei disco permanente o imponendo configurazioni specifiche dei tag firewall di rete.

Esamina le seguenti best practice per A02: Errata configurazione della sicurezza:

Consulta le seguenti best practice per A04: Failures crittografici:

  • Per imporre CMEK, applica constraints/gcp.restrictNonCmekServices a livello di organizzazione o cartella di primo livello, imposta il tipo di policy su Deny ed elenca i servizi Google Cloud supportati. Prima di applicare il vincolo, verifica che l'agente di servizio per ogni servizio di destinazione esista e che gli sia stato concesso il ruolo Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) sui keyring pertinenti.
  • Applica constraints/gcp.restrictCmekCryptoKeyProjects per limitare la selezione delle chiavi a progetti Cloud KMS dedicati.

Secret Manager

Secret Manager consente alle applicazioni e alle pipeline di accedere ai valori dei secret denominati in base alle autorizzazioni concesse con IAM. Se abilitate, le interazioni con Secret Manager creano una traccia di audit che puoi utilizzare per soddisfare le esigenze di conformità e scienza digitale forense.

Si applica a quanto segue:

  • A04: Errori crittografici
  • A07: Errori di autenticazione

Consulta le seguenti best practice per A04: Failures crittografici:

Consulta le seguenti best practice per A07: Errori di autenticazione:

  • Rimuovi i valori sensibili, come le chiavi API, dal codice sorgente, dai file .env e dalle configurazioni di build dei container e archivia le credenziali in Secret Manager. Recupera i valori decriptati in fase di runtime utilizzando le librerie client, i driver CSI Secret Store di GKE o i binding dei secret di Cloud Run.Google Cloud
  • Applica le associazioni di policy IAM direttamente a singoli secret specifici, concedendo ai microservizi il ruolo Accessore secret Secret Manager (roles/secretmanager.secretAccessor) solo per i secret specifici di cui hanno bisogno.
  • Configura le pianificazioni della rotazione automatica in Secret Manager. Quando inizia un intervallo di rotazione, Secret Manager pubblica una notifica SECRET_ROTATE in un argomento Pub/Sub designato. Configura un servizio Cloud Run Functions o Cloud Run per leggere la notifica, generare un nuovo valore secret, aggiungere la nuova versione a Secret Manager ed eliminare la versione ritirata.
  • Abilita Cloud Audit Logs su Secret Manager per monitorare gli eventi di creazione, eliminazione e accesso al payload delle versioni dei secret. Instrada questi log a Google SecOps per ricevere avvisi in caso di eventi di accesso sospetti, ad esempio un account di servizio compromesso che accede a secret al di fuori dell'orario di lavoro standard o che tenta di leggere risorse secret non approvate.

Security Command Center Premium

Security Command Center Premium ti consente di trovare e risolvere errori di configurazione della sicurezza e minacce di runtime attive, inclusi errori di identificazione e autenticazione, nel tuo ambiente Google Cloud e nelle tue applicazioni web. Il servizio Web Security Scanner può monitorare le vulnerabilità delle applicazioni, incluse quelle XML external entity (XXE), con scansioni progettate per coprire i controlli OWASP Top 10.

Si applica a quanto segue:

  • A02: Errata configurazione della sicurezza
  • A05: Iniezione
  • A07: Errori di autenticazione
  • A08: Errori di integrità del software o dei dati

Esamina le seguenti best practice per A02: Errata configurazione della sicurezza:

  • Applica framework integrati (come i benchmark CIS o NIST) utilizzando Compliance Manager per valutare le tue configurazioni cloud rispetto ai framework di sicurezza normativi e ai benchmark di settore.
  • Attiva Cloud Infrastructure Entitlement Management per gestire le identità che hanno accesso alle risorse nelle tue implementazioni cloud e mitigare le potenziali vulnerabilità derivanti da configurazioni errate.
  • Esamina e correggi i risultati di Web Security Scanner per correggere le intestazioni di sicurezza della risposta HTTP configurate in modo errato, le intestazioni di origine CORS non valide e la pubblicazione di contenuti misti.

Consulta le seguenti best practice per A05: Injection:

Consulta le seguenti best practice per A07: Errori di autenticazione:

Consulta le seguenti best practice per A08: Errori di integrità di software o dati:

  • Configura Web Security Scanner per analizzare gli endpoint web alla ricerca di bug di esecuzione basati su firme e generare un risultato STRUTS_INSECURE_DESERIALIZATION di gravità elevata se un'applicazione esegue una versione vulnerabile di Apache Struts.
  • Correggi il risultato STRUTS_INSECURE_DESERIALIZATION eseguendo l'upgrade della versione della libreria del framework vulnerabile o implementando Assured OSS per recuperare una sostituzione verificata da Google.

Sensitive Data Protection

Sensitive Data Protection ti consente di eseguire la scansione di eventuali dati potenzialmente sensibili archiviati in bucket, database, prompt di AI generativa o payload di applicazioni di streaming per contribuire a prevenire la divulgazione involontaria di informazioni. Se vengono identificati dati non consentiti, Sensitive Data Protection può contrassegnarli o oscurarli.

Si applica a quanto segue:

  • A04: Errori crittografici
  • A09: Security Logging & Alerting Failures

Consulta le seguenti best practice per A04: Failures crittografici:

  • Abilita il rilevamento dei dati sensibili per analizzare continuamente le risorse di archiviazione e database, generare profili di dati e segnalare metriche per i report di controllo.
  • Utilizza la crittografia con protezione del formato, l'hashing crittografico o la tokenizzazione basata su chiave per anonimizzare i dati sensibili.
  • Esegui il deployment di modelli di deidentificazione riutilizzabili e gestiti centralmente per applicare criteri di ispezione e mascheramento crittografico coerenti nei team di sviluppo.
  • Analizza i payload dei prompt per contribuire a impedire che dati aziendali sensibili o PII vengano divulgati nelle pipeline di addestramento dell'AI generativa.

Consulta le seguenti best practice per A09: Errori di logging e avvisi di sicurezza:

  • Configura il sink di Logging in modo che invii i log dell'applicazione a un argomento Pub/Sub. Collega un abbonato Cloud Run che utilizza l'API Sensitive Data Protection per analizzare e de-identificare il payload del log prima di scrivere i log puliti nel bucket Logging finale.
  • Utilizza i filtri di esclusione nei sink di logging per indirizzare solo i log non strutturati ad alto rischio (ad esempio errori di applicazione non elaborati, payload di registrazione utente e log delle transazioni) tramite la pipeline di sanificazione.

VirusTotal

L'API VirusTotal è una piattaforma di intelligence sulle minacce e scansione dei file che analizza file, URL, domini e indirizzi IP sospetti per rilevare malware, trojan e payload dannosi. L'integrazione dell'API VirusTotal nelle pipeline di importazione dei file consente di eseguire la scansione dei caricamenti non attendibili prima che i file vengano elaborati dai sistemi applicativi.

Si applica a quanto segue:

  • A08: Errori di integrità del software o dei dati
  • A05: Injection

Consulta le seguenti best practice per A08: Errori di integrità di software o dati:

  • Esegui il deployment di regole di corrispondenza delle firme YARA-X personalizzate per analizzare le strutture dei file in entrata alla ricerca di pattern binari e testuali dannosi noti, consentendo il rilevamento di varianti di malware mutate.

Consulta le seguenti best practice per A05: Injection:

  • Utilizza il modulo di scansione privata di VirusTotal per eseguire la scansione degli upload sensibili in isolamento e non condividere i file caricati con terze parti.
  • Implementa la limitazione della frequenza delle API e la gestione delle eccezioni nel codice di importazione per rilevare i codici di stato HTTP 429 Too Many Requests.

Controlli di servizio VPC

I Controlli di servizio VPC ti consentono di creare perimetri attorno alle tue risorse Google Cloud per impedire l'esfiltrazione di dati e mitigare gli attacchi di falsificazione delle richieste lato server (SSRF). I Controlli di servizio VPC negano le chiamate API che attraversano i confini del perimetro, a meno che non siano esplicitamente consentite dalle regole in entrata e in uscita.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A02: Errata configurazione della sicurezza

Esamina le seguenti best practice per A01: Broken Access Control:

  • Includi i servizi critici (come Cloud Storage, BigQuery, Spanner e Agent Platform) in un perimetro di servizio per limitare l'accesso alle API alle reti VPC autorizzate e alle identità attendibili.
  • Configura le regole del perimetro di uscita sulle risorse serverless per bloccare l'esfiltrazione di dati non autorizzata causata da chiamate API in uscita a destinazioni esterne non perimetrali.
  • Limita l'accesso API tra perimetri e organizzazioni utilizzando regole di ingresso e uscita esplicite che specificano origini progetto, API di destinazione e identità del chiamante approvate.

Esamina le seguenti best practice per A02: Errata configurazione della sicurezza:

  • Raggruppa i progetti in perimetri dedicati organizzati in base al livello di sicurezza dell'ambiente (ad esempio, un perimetro di produzione). Utilizza i servizi accessibili da VPC per limitare le API di Google interne che possono essere richiamate all'interno del perimetro.
  • Instrada le richieste API in uscita dai workload serverless attraverso la rete VPC. Configura i servizi Cloud Run e le funzioni Cloud Run in modo che utilizzino il traffico in uscita VPC diretto o un connettore di accesso VPC serverless con l'ingresso impostato rigorosamente su solo interno.
  • Collega i livelli di accesso di Gestore contesto accesso alle regole di ingresso del perimetro che valutano una combinazione di subnet IP aziendali, rivendicazioni di identità autenticate e indicatori di integrità del dispositivo di verifica degli endpoint.
  • Mantieni una procedura amministrativa di breakglass pre-approvata per la risposta agli incidenti di emergenza e configura avvisi di monitoraggio per eventuali eventi di violazione del perimetro imprevisti.

Servizi Wiz

Le sezioni seguenti descrivono le best practice OWASP Top 10 per i servizi Wiz che si integrano conGoogle Cloud.

Wiz Code

Wiz Code estende la sicurezza del cloud ai workflow degli sviluppatori e alle pipeline CI/CD. Wiz Code correla la telemetria da codice a cloud, esegue la scansione di Infrastructure as Code (IaC), analizza le dipendenze (SCA), rileva le credenziali esposte ed esegue test di sicurezza delle applicazioni statici (SAST).

Si applica a quanto segue:

  • A03: Errori nella catena di fornitura del software
  • A05: Injection
  • A07: Errori di autenticazione

Consulta le seguenti best practice per A03: guasti alla catena di fornitura del software:

  • Integra la CLI Wiz nelle pipeline CI/CD per impedire l'unione delle richieste pull se introducono CVE critiche, segreti esposti o errori di configurazione IaC gravi nei rami protetti.
  • Genera ed esporta una SBOM per ogni build per mantenere la visibilità continua della supply chain in Wiz Cloud.
  • Esegui il deployment delle estensioni IDE di Wiz Code per fornire feedback in tempo reale agli sviluppatori, rilevando pacchetti vulnerabili, chiavi API hardcoded ed errori di sintassi prima del commit del codice.
  • Integra Wiz Code con CodeMender nelle pipeline CI/CD per generare, testare e inviare richieste di pull quando vengono rilevate dipendenze di terze parti vulnerabili.

Consulta le seguenti best practice per A05: Injection:

  • Impedisci l'unione delle richieste pull se lo scanner SAST rileva input utente non attendibili che confluiscono in query di database o comandi del sistema operativo senza un'adeguata sanificazione.
  • Integra il plug-in Wiz Code negli IDE per sviluppatori per fornire avvisi in tempo reale se gli sviluppatori digitano query SQL o pattern di esecuzione di comandi non sicuri e concatenati.
  • Quando Wiz Code segnala un difetto di iniezione, invia le tracce del flusso di dati a CodeMender per creare una patch di correzione verificata.

Consulta le seguenti best practice per A07: Errori di autenticazione:

  • Implementa la scansione automatica dei segreti negli IDE per sviluppatori, negli hook pre-commit locali e nelle pipeline CI/CD per rilevare le credenziali esposte.
  • Per ridurre il rischio di furto delle credenziali, sostituisci le credenziali statiche di lunga durata con token dinamici di breve durata e accesso basato sull'identità (ad esempio la federazione delle identità per i carichi di lavoro o l'autenticazione basata su OIDC).
  • Implementa un playbook di risposta agli incidenti automatizzato per rimuovere i secret rilevati da codice, variabili di ambiente e log di build.

Wiz Cloud

Wiz Cloud analizza gli ambienti multi-cloud per identificare errori di configurazione della sicurezza, esposizioni di dati sensibili e rischi per l'identità. Utilizzando il Wiz Security Graph, Wiz Cloud correla i fattori di rischio nei vari livelli dell'infrastruttura per evidenziare i percorsi di attacco critici.

Si applica a quanto segue:

  • A01: Controllo dell'accesso interrotto
  • A02: Errata configurazione della sicurezza
  • A04: Errori crittografici
  • A06: Progettazione non sicura

Esamina le seguenti best practice per A01: Broken Access Control:

  • Trace e contrassegna percorsi di escalation dei privilegi complessi e multi-hop nei ruoli e nelle norme IAM per identificare dove gli autori degli attacchi potrebbero spostarsi lateralmente o elevare i privilegi.
  • Mappa le autorizzazioni di accesso attive tra account utente, account di servizio e agenti AI ai datastore critici e revoca i diritti con privilegi eccessivi.
  • Integra i risultati dei diritti di identità con le piattaforme di orchestrazione per sostituire i binding dei ruoli amministrativi permanenti con l'accesso just-in-time (JIT).
  • Monitora e visualizza lo spostamento dei dati per rilevare quando le PII di produzione vengono copiate o sincronizzate in ambienti di staging o di sviluppo non sicuri.

Esamina le seguenti best practice per A02: Errata configurazione della sicurezza:

  • Valuta e dai la priorità al rischio di configurazione cloud correlando le configurazioni errate con più fattori di attacco utilizzando Wiz Security Graph.
  • Applica framework di conformità integrati (come OWASP Top 10, CIS Benchmarks e NIST) per misurare le configurazioni cloud rispetto agli standard di settore.
  • Integra lo scanner Wiz CLI nelle pipeline CI/CD per rivedere le build o correggere le configurazioni errate di IaC prima del deployment.

Consulta le seguenti best practice per A04: Failures crittografici:

  • Dai la priorità alla correzione di database e bucket di archiviazione che contengono credenziali in testo normale, chiavi non sottoposte ad hashing o dati sensibili archiviati senza crittografia.
  • Esegui l'individuazione dei dati Wiz Cloud nelle directory di addestramento dell'AI, nei database vettoriali e nelle pipeline RAG per verificare che i dati proprietari e le PII vengano oscurati prima dell'importazione del modello LLM.
  • Esegui la scansione degli ambienti per identificare gli asset di dati non gestiti ed eliminare i dati ridondanti per ridurre al minimo la superficie di attacco.

Esamina le seguenti best practice per A06: Progettazione non sicura:

  • Chiedi a Wiz Red Agent di analizzare le interfacce architetturali logiche e simulare i percorsi di attacco per trovare difetti di progettazione non sicuri prima dell'implementazione della produzione.
  • Trasferisci il contesto della catena di attacco convalidato da Wiz Red Agent a CodeMender per identificare le cause principali e generare richieste di pull architetturali testate.

Wiz Defend

Wiz Defend fornisce rilevamento e risposta al cloud (CDR), protezione runtime dei workload e sicurezza di ammissione di Kubernetes. Wiz Defend monitora l'attività del control plane, rileva anomalie di runtime, applica i criteri di ammissione dei container e attiva il contenimento automatico.

Si applica a quanto segue:

  • A08: Errori di integrità del software o dei dati
  • A09: Security Logging & Alerting Failures

Consulta le seguenti best practice per A08: Errori di integrità di software o dati:

  • Configura le regole di ammissione di Wiz Defend per ispezionare e rifiutare i manifest di deployment Kubernetes che tentano di eseguire container con privilegi di root, richiedono spazi dei nomi di rete host o abilitano privileged: true.
  • Configura i webhook di ammissione di sicurezza critici con failurePolicy: Fail (fail-closed) in produzione per bloccare i container non attendibili se il webhook non è raggiungibile.

Consulta le seguenti best practice per A09: Errori di logging e avvisi di sicurezza:

  • Esporta i Google Cloud log di controllo utilizzando un sink di log in un argomento Pub/Sub in modo che Wiz Defend possa importare e analizzare le attività del control plane e gli eventi dei carichi di lavoro.
  • Esegui il deployment di Wiz Runtime Sensor sui cluster GKE e sulle VM Compute Engine di alto valore per rilevare minacce di runtime, exploit in memoria e compromissioni attive.
  • Automatizza i playbook di contenimento per disattivare immediatamente i service account IAM compromessi o isolare i workload compromessi.
  • Utilizza Wiz Blue Agent per esaminare i rilevamenti in fase di runtime, correlando la telemetria dei processi in tempo reale e il contesto dell'identità per determinare le cause principali e gli asset interessati.

Mantenere la conformità con OWASP Top 10:2025

Wiz include un framework di conformità OWASP Top 10 2025 che ti consente di valutare e monitorare la tua postura. Il framework di conformità OWASP Top 10 2025 mappa le policy Wiz integrate alle categorie di rischio OWASP pertinenti e crea risultati se un controllo non è conforme. Puoi monitorare il tuo punteggio di conformità nel tempo. Se necessario, puoi personalizzare il framework di conformità OWASP Top 10 2025 per soddisfare i requisiti della tua attività.

Passaggi successivi

Consulta il catalogo delle best practice per la sicurezza per ulteriori best practice.