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, storage buckets, 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 è all'interno di un'altra organizzazione, è necessario contattare il supporto GCP per spostarlo fuori dall'organizzazione prima. Per maggiori informazioni consulta questo.
Politiche dell'Organizzazione
Permettono di centralizzare il controllo sulle risorse cloud della tua organizzazione:
Centralizzare il controllo per configurare restrizioni su come possono essere utilizzate le risorse della tua organizzazione.
Definire e stabilire guardrails per i tuoi team di sviluppo per rimanere entro i limiti di conformità.
Aiutare 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, cartella(e) o progetto(i). I discendenti del nodo della gerarchia delle risorse mirato 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. Configura 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 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 granulare delle risorse della tua organizzazione. Per maggiori informazioni, consulta l' elenco di tutti i vincoli del servizio di politica dell'organizzazione.
Politiche dell'Organizzazione Predefinite
Ruoli IAM
Questi sono come le 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 ruoli di accesso X ai principali Y, 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 principale è chiedere a ogni risorsa a chi sta dando permessi, e un utente potrebbe non avere i permessi per ottenere permessi da tutte le risorse.
Ci sono tre tipi di ruoli in IAM:
Ruoli di base/primari, 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 vederli tutti 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 verificare 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 SAs a causa di alcuni permessi che contengono. Inoltre, nota che i permessi avranno effetto solo se sono assegnati al servizio rilevante.
Oppure verifica 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, questo viene fatto in Google Workspace. Sebbene tu possa sincronizzare un diverso provider di identità in Google Workspace.
Puoi accedere agli utenti e ai gruppi di Workspaces in https://admin.google.com.
MFA può essere forzata agli utenti di Workspaces, tuttavia, un attaccante potrebbe utilizzare un token per accedere a GCP via cli che non sarà protetto da MFA (sarà protetto da MFA solo quando l'utente effettua il login per generarlo: gcloud auth login).
Gruppi
Quando viene creata un'organizzazione, è fortemente consigliato creare diversi gruppi. Se gestisci uno di essi potresti aver compromesso tutta 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 risorse di Google Cloud. In alternativa, poiché questa funzione è altamente privilegiata, considera l'uso di 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. |
| Configurare account 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 le politiche di vincolo dell'organizzazione. Consulta la guida alle fondamenta della sicurezza di Google Cloud per maggiori informazioni sulla pianificazione della tua infrastruttura di sicurezza Google Cloud. |
| Creare o gestire pipeline end-to-end che supportano l'integrazione continua e la consegna, il monitoraggio e la fornitura di sistemi. |
| |
| |
| |
| Monitorare la spesa sui progetti. I membri tipici fanno parte del team finanziario. |
| Rivedere le informazioni sulle risorse in tutta l'organizzazione Google Cloud. |
| Rivedere la sicurezza del cloud. |
| Rivedere le configurazioni di rete. |
| Visualizzare i log di audit. |
| Amministrare il Security Command Center. |
| Gestire i segreti in Secret Manager. |
Politica delle Password Predefinita
Imporre password forti
Tra 8 e 100 caratteri
Nessun riutilizzo
Nessuna scadenza
Se le persone accedono a Workspace tramite un provider di terze parti, questi requisiti non si applicano.
Account di servizio
Questi sono i principali che le risorse possono avere allegati e accedere 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 violato è 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 assegnato automaticamente 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).
Molti 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 collegare alle risorse custom service accounts, che appariranno così:
Access scopes
Gli access scope sono allegati ai token OAuth generati per accedere agli endpoint API di GCP. Limitano i permessi del token OAuth. Ciò significa che se un token appartiene a un Proprietario di una risorsa ma non ha nel token scope l'accesso a quella risorsa, il token non può essere utilizzato per (ab)usare quei privilegi.
Google in realtà raccomanda che gli access scope non siano utilizzati e di fare affidamento totalmente su IAM. Il portale di gestione web in realtà impone questo, ma gli access scope possono ancora essere applicati alle istanze utilizzando account di servizio personalizzati programmaticamente.
Puoi vedere quali scope sono assegnati interrogando:
I precedenti scopes sono quelli generati di default usando gcloud per accedere ai dati. Questo perché quando usi gcloud crei prima un token OAuth e poi lo usi per contattare gli endpoint.
Lo scope più importante tra questi potenzialmente è cloud-platform, che fondamentalmente significa che è possibile accedere a qualsiasi servizio in GCP.
Puoi trovare un elenco di tutti i possibili scopes qui.
Se hai le credenziali del browser gcloud, è possibile ottenere un token con altri scopes, facendo qualcosa del genere:
Terraform IAM Policies, Bindings and Memberships
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 principal l'accesso a una risorsa:
Memberships: Si impostano principals come membri di ruoli senza restrizioni sul ruolo o sui principals. È possibile mettere un utente come membro di un ruolo e poi mettere un gruppo come membro dello stesso ruolo e anche impostare quei principals (utente e gruppo) come membri di altri ruoli.
Bindings: Diversi principals possono essere associati a un ruolo. Quei principals possono ancora essere associati o essere membri di altri ruoli. Tuttavia, se un principal che non è associato al ruolo è impostato come membro di un ruolo associato, la prossima volta che l'associazione viene applicata, l'appartenenza scomparirà.
Policies: Una policy è autoritativa, indica ruoli e principals e quindi, quei principals non possono avere più ruoli e quei ruoli non possono avere più principals a meno che quella policy non venga modificata (nemmeno in altre policies, bindings o memberships). Pertanto, quando un ruolo o un principal è specificato in una policy tutti i suoi privilegi sono limitati da quella policy. Ovviamente, questo può essere bypassato nel caso in cui al principal venga data l'opzione di modificare la policy o i permessi di escalation dei privilegi (come creare un nuovo principal e associargli un nuovo ruolo).
Riferimenti
Last updated
