GCP - Basic Information
Gerarchia delle risorse
Google Cloud utilizza una Gerarchia delle risorse che è simile, concettualmente, a quella di un filesystem tradizionale. Questo fornisce un flusso di lavoro logico genitore/figlio con punti di attacco specifici per politiche e permessi.
A un livello alto, appare così:
Una macchina virtuale (chiamata Compute Instance) è una risorsa. Una risorsa risiede in un progetto, probabilmente insieme ad altre Compute Instances, bucket di archiviazione, ecc.
Migrazione dei Progetti
È possibile migrare un progetto senza alcuna organizzazione a un'organizzazione con i permessi roles/resourcemanager.projectCreator e roles/resourcemanager.projectMover. Se il progetto si trova all'interno di un'altra organizzazione, è necessario contattare il supporto GCP per spostarlo fuori dall'organizzazione prima. Per ulteriori informazioni, consulta questo.
Politiche dell'Organizzazione
Consentono di centralizzare il controllo sulle risorse cloud della tua organizzazione:
Centralizza il controllo per configurare restrizioni su come possono essere utilizzate le risorse della tua organizzazione.
Definisci e stabilisci guardrail per i tuoi team di sviluppo per rimanere all'interno dei confini di conformità.
Aiuta i proprietari dei progetti e i loro team a muoversi rapidamente senza preoccuparsi di violare la conformità.
Queste politiche possono essere create per influenzare l'intera organizzazione, la cartella o il progetto. I discendenti del nodo della gerarchia delle risorse mirate ereditano la politica dell'organizzazione.
Per definire una politica dell'organizzazione, scegli un vincolo, che è un particolare tipo di restrizione contro un servizio Google Cloud o un gruppo di servizi Google Cloud. Configuri quel vincolo con le restrizioni desiderate.
Casi d'uso comuni
Limitare la condivisione delle risorse in base al dominio.
Limitare l'uso degli account di servizio di Identity and Access Management.
Limitare la posizione fisica delle risorse appena create.
Disabilitare la creazione di account di servizio.
Ci sono molti altri vincoli che ti danno un controllo dettagliato sulle risorse della tua organizzazione. Per maggiori informazioni, consulta la lista di tutti i vincoli del Servizio di Politica dell'Organizzazione.
Politiche di Organizzazione Predefinite
Ruoli IAM
Questi sono simili alle politiche IAM in AWS poiché ogni ruolo contiene un insieme di permessi.
Tuttavia, a differenza di AWS, non esiste un repository centralizzato di ruoli. Invece, le risorse danno X ruoli di accesso a Y principi, e l'unico modo per scoprire chi ha accesso a una risorsa è utilizzare il metodo get-iam-policy su quella risorsa.
Questo potrebbe essere un problema perché significa che l'unico modo per scoprire quali permessi ha un principio è chiedere a ogni risorsa a chi sta dando permessi, e un utente potrebbe non avere permessi per ottenere permessi da tutte le risorse.
Ci sono tre tipi di ruoli in IAM:
Ruoli di base/primitive, che includono i ruoli di Proprietario, Editor e Visualizzatore che esistevano prima dell'introduzione di IAM.
Ruoli predefiniti, che forniscono accesso granulare per un servizio specifico e sono gestiti da Google Cloud. Ci sono molti ruoli predefiniti, puoi vedere tutti loro con i privilegi che hanno qui.
Ruoli personalizzati, che forniscono accesso granulare secondo un elenco di permessi specificato dall'utente.
Ci sono migliaia di permessi in GCP. Per controllare se un ruolo ha un permesso, puoi cercare il permesso qui e vedere quali ruoli lo hanno.
Puoi anche cercare qui i ruoli predefiniti offerti da ciascun prodotto. Nota che alcuni ruoli non possono essere assegnati agli utenti e solo agli SA a causa di alcuni permessi che contengono. Inoltre, nota che i permessi avranno effetto solo se sono assegnati al servizio pertinente.
Oppure controlla se un ruolo personalizzato può utilizzare un permesso specifico qui.
GCP - IAM, Principals & Org Policies EnumUtenti
Nella console GCP non c'è alcuna gestione di Utenti o Gruppi, che viene effettuata in Google Workspace. Anche se potresti sincronizzare un diverso fornitore di identità in Google Workspace.
Puoi accedere agli utenti e gruppi di Workspaces in https://admin.google.com.
MFA può essere forzata per gli utenti di Workspaces, tuttavia, un attaccante potrebbe utilizzare un token per accedere a GCP tramite cli che non sarà protetto da MFA (sarà protetto da MFA solo quando l'utente accede per generarlo: gcloud auth login).
Gruppi
Quando viene creata un'organizzazione, è fortemente consigliato creare diversi gruppi. Se gestisci uno di essi, potresti aver compromesso tutto o una parte importante dell'organizzazione:
Gruppo | Funzione |
| Amministrare qualsiasi risorsa che appartiene all'organizzazione. Assegna questo ruolo con parsimonia; gli amministratori dell'organizzazione hanno accesso a tutte le tue risorse Google Cloud. In alternativa, poiché questa funzione è altamente privilegiata, considera di utilizzare account individuali invece di creare un gruppo. |
| Creare reti, subnet, regole firewall e dispositivi di rete come Cloud Router, Cloud VPN e bilanciatori di carico cloud. |
| Impostare conti di fatturazione e monitorare il loro utilizzo. |
| Progettare, codificare e testare applicazioni. |
| Stabilire e gestire politiche di sicurezza per l'intera organizzazione, inclusa la gestione degli accessi e politiche di vincolo dell'organizzazione. Consulta la guida alle fondamenta di sicurezza di Google Cloud per ulteriori informazioni sulla pianificazione della tua infrastruttura di sicurezza Google Cloud. |
| Creare o gestire pipeline end-to-end che supportano integrazione e distribuzione continue, monitoraggio e provisioning di sistemi. |
| |
| |
| |
| Monitorare la spesa sui progetti. I membri tipici fanno parte del team finanziario. |
| Esaminare le informazioni sulle risorse nell'organizzazione Google Cloud. |
| Esaminare la sicurezza del cloud. |
| Esaminare le configurazioni di rete. |
| Visualizzare i log di audit. |
| Amministrare il Security Command Center. |
| Gestire i segreti in Secret Manager. |
Politica di Password Predefinita
Forzare password forti
Tra 8 e 100 caratteri
Nessun riutilizzo
Nessuna scadenza
Se le persone accedono a Workspace tramite un fornitore di terze parti, questi requisiti non vengono applicati.
Account di servizio
Questi sono i principi che le risorse possono avere allegate e accesso per interagire facilmente con GCP. Ad esempio, è possibile accedere al token di autenticazione di un Account di Servizio allegato a una VM nei metadati.
È possibile incontrare alcuni conflitti quando si utilizzano sia IAM che ambiti di accesso. Ad esempio, il tuo account di servizio potrebbe avere il ruolo IAM di compute.instanceAdmin, ma l'istanza che hai compromesso è stata limitata con la limitazione dell'ambito di https://www.googleapis.com/auth/compute.readonly. Questo ti impedirebbe di apportare modifiche utilizzando il token OAuth che è automaticamente assegnato alla tua istanza.
È simile ai ruoli IAM di AWS. Ma a differenza di AWS, qualsiasi account di servizio può essere allegato a qualsiasi servizio (non è necessario consentirlo tramite una politica).
Diversi degli account di servizio che troverai sono in realtà generati automaticamente da GCP quando inizi a utilizzare un servizio, come:
Tuttavia, è anche possibile creare e allegare a risorse account di servizio personalizzati, che appariranno in questo modo:
Chiavi e Token
Ci sono 2 modi principali per accedere a GCP come account di servizio:
Via token OAuth: Questi sono token che otterrai da luoghi come gli endpoint dei metadati o rubando richieste http e sono limitati dagli ambiti di accesso.
Chiavi: Queste sono coppie di chiavi pubbliche e private che ti permetteranno di firmare richieste come account di servizio e persino generare token OAuth per eseguire azioni come account di servizio. Queste chiavi sono pericolose perché sono più complicate da limitare e controllare, ecco perché GCP raccomanda di non generarle.
Nota che ogni volta che viene creato un SA, GCP genera una chiave per l'account di servizio a cui l'utente non può accedere (e non sarà elencata nell'applicazione web). Secondo questo thread, questa chiave è utilizzata internamente da GCP per dare accesso agli endpoint dei metadati per generare i token OAuth accessibili.
Ambiti di accesso
Gli ambiti di accesso sono allegati ai token OAuth generati per accedere agli endpoint API di GCP. Essi limitano i permessi del token OAuth. Questo significa che se un token appartiene a un Proprietario di una risorsa ma non ha nell'ambito del token l'accesso a quella risorsa, il token non può essere utilizzato per (ab)usare quei privilegi.
Google in realtà raccomanda che gli ambiti di accesso non vengano utilizzati e di fare totalmente affidamento su IAM. Il portale di gestione web in realtà applica questa regola, ma gli ambiti di accesso possono ancora essere applicati alle istanze utilizzando account di servizio personalizzati programmaticamente.
Puoi vedere quali ambiti sono assegnati eseguendo una query:
Le scopes precedenti sono quelle generate per default utilizzando gcloud per accedere ai dati. Questo perché quando usi gcloud crei prima un token OAuth e poi lo usi per contattare gli endpoint.
La scope più importante di quelle potenzialmente è cloud-platform, che fondamentalmente significa che è possibile accedere a qualsiasi servizio in GCP.
Puoi trovare un elenco di tutte le possibili scopes qui.
Se hai le credenziali del browser gcloud, è possibile ottenere un token con altre scopes, facendo qualcosa come:
Politiche IAM di Terraform, Binding e Membri
Come definito da terraform in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, utilizzando terraform con GCP ci sono diversi modi per concedere a un principale accesso a una risorsa:
Membri: Imposti i principali come membri di ruoli senza restrizioni sul ruolo o sui principali. Puoi mettere un utente come membro di un ruolo e poi mettere un gruppo come membro dello stesso ruolo e anche impostare quei principali (utente e gruppo) come membri di altri ruoli.
Binding: Diversi principali possono essere legati a un ruolo. Quei principali possono ancora essere legati o essere membri di altri ruoli. Tuttavia, se un principale che non è legato al ruolo è impostato come membro di un ruolo legato, la prossima volta che il binding viene applicato, la membership scomparirà.
Politiche: Una politica è autoritativa, indica ruoli e principali e poi, quei principali non possono avere più ruoli e quei ruoli non possono avere più principali a meno che quella politica non venga modificata (neanche in altre politiche, binding o membership). Pertanto, quando un ruolo o un principale è specificato nella politica, tutti i suoi privilegi sono limitati da quella politica. Ovviamente, questo può essere aggirato nel caso in cui al principale venga data l'opzione di modificare la politica o i permessi di escalation dei privilegi (come creare un nuovo principale e legarlo a un nuovo ruolo).
Riferimenti
Last updated
