Dichiarazione di responsabilità condivisa per la sicurezza
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
L'esecuzione di carichi di lavoro business-critical su Cloud Build richiede che più parti si assumano responsabilità diverse. Il modello di responsabilità condivisa
descritto in questo documento chiarisce che Google Cloud è
responsabile della sicurezza del servizio Cloud Build stesso e
della sua infrastruttura sottostante, mentre tu, il cliente, sei responsabile della
sicurezza nell'utilizzo di Cloud Build, incluse le build specifiche,
le configurazioni, i dati e le immagini container che esegui utilizzando
Cloud Build.
Sebbene non sia un elenco esaustivo, questa pagina elenca le rispettive responsabilità di
Google Cloud e del cliente.
Responsabilità di Google Cloud
Protezione dell'infrastruttura sottostante, inclusi hardware, firmware, kernel, sistema operativo, archiviazione e rete.
È incluso quanto segue:
Protezione della sicurezza fisica dei data center, crittografia predefinita dei dati
inattivi e in transito e componenti di rete sicuri.
Fornire protezione di rete utilizzando i Controlli di servizio VPC.
Seguendo pratiche di sviluppo software sicure.
Gestione e protezione del service control plane di Cloud Build (API,
backend, pianificatori e così via), inclusi patching e hardening.
Fornire ambienti di build temporanei e isolati per ogni chiamata di build.
Limitazione dell'accesso amministrativo a Google Cloud alle risorse dei clienti per scopi di assistenza contrattuale, con Access Transparency e Approvazioni dell'accesso e registrazione di tutti questi accessi.
Produzione di provenienza SLSA autentica, se configurata per farlo.
Responsabilità del Cliente
Proteggere il codice sorgente dell'applicazione, i file di configurazione della build e tutte le
immagini container utilizzate nelle build.
Ciò include la valutazione dell'idoneità delle immagini per i tuoi standard di sicurezza, l'utilizzo delle versioni delle immagini supportate più recenti e il rispetto delle best practice per i componenti open source e la configurazione complessiva della build.
Per gli scenari che richiedono il massimo grado di sicurezza, valuta la possibilità di utilizzare
immagini personalizzate per l'esecuzione delle build.
Assicurati che i token di integrazione di terze parti (ad esempio quelli forniti per stabilire
un link al repository) siano protetti in modo appropriato.
Configurazione di IAM per tutti gli utenti, i gruppi e i service account
che interagiscono con Cloud Build, in conformità con il
principio del privilegio minimo.
Ti consigliamo di utilizzare service account dedicati e specificati dall'utente per le build
anziché quelli predefiniti.
Assicurati che gli script di build utilizzino in modo appropriato le credenziali di build, i token di integrazione di terze parti e i secret forniti che vengono resi disponibili per la build e proteggiti dall'esfiltrazione.
Attivazione e intervento in base all'analisi delle vulnerabilità per gli artefatti di build (ad esempio, utilizzando Artifact Analysis), generazione di dati di provenienza della build e implementazione di criteri di deployment (ad esempio, utilizzando Autorizzazione binaria) per garantire che vengano eseguito il deployment solo di immagini autorizzate e verificate.
Fornire a Google i dettagli ambientali quando richiesti per la risoluzione dei problemi.
Passaggi successivi
Scopri di più
sul modello di responsabilità condivisa di Google Cloud.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-08 UTC."],[],[],null,["# Statement of shared responsibility for security\n\nRunning business-critical workloads on Cloud Build requires that multiple\nparties assume different responsibilities. The shared responsibility model\ndescribed in this document clarifies that Google Cloud is\naccountable for the security of the Cloud Build service itself and\nits underlying infrastructure, while you, the customer, are responsible for\nsecurity in how Cloud Build is used, including your specific builds,\nconfigurations, data, and the container images you execute using\nCloud Build.\n\nWhile not an exhaustive list, this page lists the respective responsibilities of\nGoogle Cloud and the customer.\n\nGoogle Cloud Responsibilities\n-----------------------------\n\n- Protecting the underlying infrastructure, including hardware, firmware,\n kernel, operating system, storage, and network.\n\n This includes the following:\n - Protecting the physical security of data centers, default encryption of data at rest and in transit, and secure network components.\n - Providing network protection using VPC Service Controls.\n - Following secure software development practices.\n - Managing and securing the Cloud Build service control plane (API, backend, schedulers, etc.), including patching and hardening.\n - Providing ephemeral, isolated build environments for each build invocation.\n- Providing Google Cloud integrations for\n [Identity and Access Management](/iam) (IAM),\n [Cloud Audit Logs](/logging/docs/audit), [Cloud Key Management Service](/kms/docs), and others.\n\n- Restricting Google Cloud administrative access to\n customer resources for contractual support purposes, with\n [Access Transparency](/assured-workloads/access-transparency/docs) and\n [Access Approval](/assured-workloads/access-approval/docs/overview),\n and logging all such access.\n\n- Producing authentic [SLSA provenance](https://slsa.dev/), when configured to\n do so.\n\nThe Customer's Responsibilities\n-------------------------------\n\n- Securing your application source code, build configuration files, and all\n container images used in your builds.\n\n This includes evaluating image suitability for your security standards,\n leveraging the latest supported image versions, and following best practices\n for open source components and overall build configuration.\n\n For scenarios demanding the highest degree of security, consider bringing your\n own hardened images for running builds.\n- Ensuring any 3rd-party integration tokens (such as those provided to establish\n a repository link) are appropriately safeguarded.\n\n- Configuring IAM for all users, groups, and service accounts\n interacting with Cloud Build, in accordance with the\n [principle of least privilege](/iam/docs/using-iam-securely).\n\n We recommend you use dedicated, user-specified service accounts for builds\n instead of default ones.\n\n Ensure that your build scripts make appropriate use of the provided build\n credentials, 3P integration tokens, and secrets that are made available to the\n build, and guard against exfiltration.\n- Enabling and acting on vulnerability scanning for build artifacts (for\n example, using Artifact Analysis), generating build provenance data,\n and implementing deployment policies (for example, using Binary Authorization) to\n ensure only authorized and verified images are deployed.\n\n- Providing Google with environmental details when requested for troubleshooting\n purposes.\n\nWhat's next\n-----------\n\n- [Read more](/architecture/framework/security/shared-responsibility-shared-fate) about the Google Cloud shared responsibility model."]]
