Ti consigliamo di definire vincoli dei criteri che impongano configurazioni delle risorse accettabili e impediscano configurazioni rischiose. Il blueprint utilizza una combinazione di vincoli dei criteri dell'organizzazione e convalida dell'infrastruttura come codice (IaC) nella pipeline. Questi controlli impediscono la creazione di risorse che non rispettano le linee guida dei tuoi criteri. L'applicazione di questi controlli all'inizio della progettazione e della creazione dei carichi di lavoro ti aiuta a evitare di dover eseguire in un secondo momento attività di correzione.
Vincoli dei criteri dell'organizzazione
Il servizio Criteri dell'organizzazione applica vincoli per garantire che determinate configurazioni delle risorse non possano essere create nella tua organizzazione Google Cloud, nemmeno da un utente con un ruolo IAM sufficientemente privilegiato.
Il blueprint applica i criteri al nodo dell'organizzazione in modo che questi controlli vengano ereditati da tutte le cartelle e da tutti i progetti all'interno dell'organizzazione. Questo insieme di criteri è progettato per impedire determinate configurazioni ad alto rischio, come l'esposizione di una VM alla rete internet pubblica o la concessione dell'accesso pubblico ai bucket di archiviazione, a meno che non consenta deliberatamente un'eccezione al criterio.
La tabella seguente illustra i limiti dei criteri dell'organizzazione implementati nel blueprint:
| Vincolo dei criteri dell'organizzazione | Descrizione |
|---|---|
| La virtualizzazione nidificata sulle VM di Compute Engine può aggirare il monitoraggio e altri strumenti di sicurezza per le VM se non è configurata correttamente. Questo vincolo impedisce la creazione di virtualizzazione nidificata. |
| I ruoli IAM come |
| Le subnet IPv6 esterne possono essere esposte ad accessi internet non autorizzati se sono configurate in modo errato. Questo vincolo impedisce la creazione di subnet IPv6 esterne. |
| Il comportamento predefinito di impostazione delle chiavi SSH nei metadati può consentire l'accesso remoto non autorizzato alle VM se le chiavi sono esposte. Questo vincolo impone l'utilizzo di OS Login anziché di chiavi SSH basate su metadati. |
|
L'inoltro del protocollo VM per gli indirizzi IP esterni può comportare un traffico in uscita su internet non autorizzato se l'inoltro non è configurato correttamente. Questo vincolo consente di inoltrare il protocollo VM solo per gli indirizzi interni. |
|
L'eliminazione di un progetto host VPC condiviso può causare interruzioni in tutti i progetti di servizio che utilizzano risorse di rete. Questo vincolo impedisce l'eliminazione accidentale o dannosa dei progetti host con VPC condiviso impedendo la rimozione del blocco su questi progetti. |
|
Un'impostazione precedente per il DNS interno globale (a livello di progetto) non è consigliata perché riduce la disponibilità del servizio. Questo vincolo impedisce l'utilizzo dell'impostazione precedente. |
| In ogni nuovo progetto che attiva l'API Compute Engine vengono create una rete VPC predefinita e regole firewall VPC predefinite eccessivamente permissive. Questo vincolo ignora la creazione della rete predefinita e delle regole firewall VPC predefinite. |
| Per impostazione predefinita, viene creata una VM con un indirizzo IPv4 esterno che può comportare l'accesso non autorizzato a internet. Questo vincolo configura una lista consentita vuota di indirizzi IP esterni che la VM può utilizzare e nega tutti gli altri. |
|
Per impostazione predefinita, Contatti necessari può essere configurato per inviare notifiche sul tuo dominio a qualsiasi altro dominio. Questo vincolo impone che solo gli indirizzi email dei domini approvati possano essere impostati come destinatari per i Contatti necessari. |
| Per impostazione predefinita, i criteri di autorizzazione possono essere concessi a qualsiasi Account Google, inclusi gli account non gestiti e quelli appartenenti a organizzazioni esterne. Questo vincolo garantisce che i criteri di autorizzazione nella tua organizzazione possano essere concessi solo agli account gestiti del tuo dominio. Se vuoi, puoi consentire domini aggiuntivi. |
|
Per impostazione predefinita, ai service account predefiniti vengono concessi automaticamente ruoli eccessivamente permissivi. Questo vincolo impedisce le concessioni automatiche dei ruoli IAM agli account di servizio predefiniti. |
|
Le chiavi dei service account sono credenziali permanenti ad alto rischio e, nella maggior parte dei casi, è possibile utilizzare un'alternativa più sicura alle account di servizio account. Questo vincolo impedisce la creazione di chiavi dell'account di servizio. |
|
Il caricamento del materiale delle chiavi dell'account di servizio può aumentare il rischio se il materiale delle chiavi viene esposto. Questo vincolo impedisce il caricamento delle chiavi degli account di servizio. |
|
Le istanze Cloud SQL possono essere esposte all'accesso non autenticato a internet se sono configurate per utilizzare reti autorizzate senza un proxy di autenticazione Cloud SQL. Questa norma impedisce la configurazione delle reti autorizzate per l'accesso al database e forza l'utilizzo del proxy di autenticazione Cloud SQL. |
| Le istanze Cloud SQL possono essere esposte all'accesso a internet non autenticato se vengono create con indirizzi IP pubblici. Questo vincolo impedisce l'utilizzo di indirizzi IP pubblici nelle istanze Cloud SQL. |
| Per impostazione predefinita, è possibile accedere agli oggetti in Cloud Storage tramite gli elenchi di controllo dell'accesso (ACL) legacy anziché tramite IAM, il che può comportare controlli dell'accesso incoerenti ed esposizione accidentale in caso di configurazione errata. L'accesso ACL precedente non è
interessato dal vincolo |
|
I bucket Cloud Storage possono essere esposti all'accesso a internet non autenticato se sono configurati in modo errato. Questo vincolo impedisce gli ACL e le autorizzazioni IAM che consentono di accedere a |
Queste norme sono un punto di partenza consigliato per la maggior parte dei clienti e per la maggior parte degli scenari, ma potrebbe essere necessario modificare i vincoli delle norme dell'organizzazione per supportare determinati tipi di carichi di lavoro. Ad esempio, un carico di lavoro che utilizza un
bucket Cloud Storage come backend per Cloud CDN per ospitare
risorse pubbliche è bloccato da storage.publicAccessPrevention o un'app Cloud Run rivolta al pubblico che non richiede autenticazione è bloccata da iam.allowedPolicyMemberDomains. In questi casi, modifica il criterio dell'organizzazione a livello di cartella o progetto per consentire un'eccezione specifica.
Puoi anche aggiungere condizionalmente vincoli ai criteri dell'organizzazione
definendo un tag che concede un'eccezione o l'applicazione dei criteri, quindi
applicandolo ai progetti e alle cartelle.
Per vincoli aggiuntivi, consulta i vincoli disponibili e i vincoli personalizzati.
Convalida pre-deployment dell'infrastruttura come codice
Il blueprint utilizza un approccio GitOps per gestire l'infrastruttura, il che significa che tutte le modifiche dell'infrastruttura vengono implementate tramite l'infrastruttura come codice (IaC) con controllo della versione e possono essere convalidate prima del deployment.
I criteri applicati nel blueprint definiscono le configurazioni delle risorse accettabili che possono essere implementate dalla pipeline. Se il codice inviato al tuo repository GitHub non supera i controlli dei criteri, non viene dispiegato nessuna risorsa.
Per informazioni su come vengono utilizzate le pipeline e su come vengono applicati i controlli tramite l'automazione CI/CD, consulta la metodologia di deployment.
Passaggi successivi
- Leggi la sezione sulla metodologia di implementazione (documento successivo di questa serie)