IAM e il principio del least privilege

Google Cloud regola l’accesso con IAM, che lega un principal (utente, gruppo o service account) a un role su una resource tramite un policy binding. I role si dividono in tre famiglie. I basic role — Owner, Editor, Viewer — sono ampi ed ereditati da tutti i servizi del project: comodi ma troppo permissivi per un ambiente dati. I predefined role sono granulari e legati al singolo servizio, per esempio roles/bigquery.dataViewer (lettura di dataset e tabelle) o roles/bigquery.jobUser (esecuzione di query). I custom role compongono singole permission quando nessun predefined è adatto.

Il least privilege impone di concedere solo i permessi necessari: in pratica preferire sempre i predefined role ai basic role, assegnarli a gruppi anziché a singoli utenti, e applicarli al livello di resource più basso possibile (il singolo dataset o bucket, non l’intero project).

Access control in Cloud Storage

Un bucket Cloud Storage supporta due modelli. Con uniform bucket-level access l’accesso è gestito esclusivamente da IAM a livello di bucket: è la scelta raccomandata perché semplice, uniforme e verificabile. L’alternativa fine-grained aggiunge le ACL per-oggetto, utile solo quando servono permessi diversi su singoli file.

La distinzione pubblico/privato dipende da chi compare nella policy: assegnare un role (es. roles/storage.objectViewer) al principal allUsers rende gli oggetti leggibili da chiunque su Internet; senza quel binding il bucket resta privato. La feature Public Access Prevention blocca a monte qualsiasi esposizione pubblica.

Condividere i dati con Analytics Hub

Quando occorre condividere dataset BigQuery con altri team o organizzazioni senza copiare né spostare i dati, lo strumento è Analytics Hub. Un publisher crea un exchange e vi pubblica una listing che punta a un dataset; il subscriber vi si iscrive e ottiene un linked dataset di sola lettura nel proprio project, interrogabile come un normale dataset ma senza duplicazione. Questo evita export, pipeline di copia e costi di storage ridondanti, mantenendo un unico source of truth governato dal publisher. È la risposta corretta agli scenari di data sharing, in contrapposizione a soluzioni che copiano i dati.

Storage classes e regole di lifecycle

Cloud Storage offre quattro storage class scelte in base alla frequenza di accesso e alla retention: Standard per dati hot ad accesso frequente; Nearline per accessi circa mensili (minimum storage duration 30 giorni); Coldline per accessi circa trimestrali (90 giorni); Archive per dati raramente letti, tipicamente annuali (365 giorni). Scendendo di classe il costo di storage cala ma aumentano i costi di retrieval e la durata minima di conservazione fatturata.

Le regole di Object Lifecycle Management automatizzano azioni al verificarsi di condizioni: l’azione SetStorageClass declassa gli oggetti (es. da Standard a Nearline dopo 30 giorni), mentre l’azione Delete li rimuove dopo un’età definita, riducendo i costi senza intervento manuale. In BigQuery il meccanismo analogo è l’expiration: default table expiration a livello di dataset, table expiration sulla singola tabella e partition expiration, che eliminano automaticamente dati o partizioni scaduti.

Trappole tipiche d’esame

  • Un analista deve leggere le tabelle BigQuery → soluzione: assegnare il predefined roles/bigquery.dataViewer, non il basic role Editor o Owner; least privilege significa preferire i predefined ai basic.
  • Condividere dati con un’altra organizzazione senza copiarli → soluzione: Analytics Hub con listing e linked dataset di sola lettura, non un export su Cloud Storage né la duplicazione del dataset.
  • Dati acceduti circa una volta l’anno da conservare a lungo → soluzione: Archive storage class, non Coldline (trimestrale) né Nearline (mensile); la classe si sceglie sulla frequenza di accesso.
  • Ridurre i costi eliminando automaticamente oggetti vecchi → soluzione: una lifecycle rule con azione Delete su condizione di age, non uno script manuale ricorrente.
  • Semplificare e uniformare i permessi di un bucket → soluzione: abilitare uniform bucket-level access (solo IAM), evitando le ACL fine-grained per-oggetto.
  • Impedire che un bucket diventi pubblico → soluzione: Public Access Prevention più la rimozione di allUsers/allAuthenticatedUsers dalla policy, senza affidarsi alle sole ACL.