Due sistemi di autorizzazione che coesistono

Su Azure Data Lake Storage Gen2 l’accesso ai dati è governato da due meccanismi distinti che lavorano insieme: Azure RBAC e le ACL POSIX. Capirne la differenza di granularità e l’ordine di valutazione è centrale nel DP-203, perché lo scenario tipico chiede quale meccanismo usare per un requisito specifico.

  • Azure RBAC assegna ruoli a livello di subscription, resource group, storage account o container (filesystem). È a grana grossa: un ruolo dato sul container vale per tutto il suo contenuto.
  • Le ACL POSIX operano a grana fine sul singolo file o cartella, con permessi Read/Write/Execute per owning user, owning group e other. Sono l’unico modo per dare, ad esempio, accesso in scrittura a /raw/finance ma sola lettura a /raw/hr all’interno dello stesso container.

Ordine di valutazione e il superuser

Il punto d’esame più frequente è l’ordine: Azure valuta prima l’RBAC, poi le ACL. Se il security principal possiede un ruolo RBAC con la data action richiesta a livello di account o container, l’accesso è concesso e le ACL non vengono nemmeno controllate. Solo quando l’RBAC non concede il permesso si passa alla valutazione delle ACL sul percorso richiesto (dove serve il permesso Execute su tutte le cartelle intermedie per attraversare l’albero).

Il ruolo Storage Blob Data Owner è un superuser: bypassa completamente le ACL e ha accesso pieno a qualsiasi file, oltre a poter modificare owner e ACL stesse. Anche l’account key e le SAS firmate con account key garantiscono accesso superuser. Per questo, in scenari di least privilege, non si assegna Data Owner agli account di servizio se basta un ruolo più ristretto.

I ruoli data-plane che contano

  • Storage Blob Data Reader — lettura e list dei blob. Assegnato a chi consuma i dati senza scriverli.
  • Storage Blob Data Contributor — lettura, scrittura ed eliminazione. È il ruolo standard per pipeline di ingestion/transform.
  • Storage Blob Data Owner — come Contributor più gestione ACL e comportamento superuser.

Attenzione a non confondere i ruoli control-plane (Owner, Contributor sullo storage account) che gestiscono la risorsa ma non concedono accesso ai dati: senza un ruolo Storage Blob Data* o senza ACL, un Contributor sull’account non legge i blob (a meno di usare l’account key).

Identità per l’accesso da ADF e Databricks

Per l’accesso da servizi come Azure Data Factory e Azure Databricks si evita di usare account key o SAS statiche a favore di identità gestite:

  • Managed identity (system-assigned o user-assigned): in ADF si usa la managed identity della factory come metodo di autenticazione del linked service verso ADLS, assegnandole Storage Blob Data Contributor sul container. In Databricks si usa un Access Connector con managed identity, referenziato da una storage credential in Unity Catalog.
  • Service principal: un’app registrata in Microsoft Entra ID con OAuth 2.0, utile per scenari cross-tenant o pipeline esterne, a cui si assegna il ruolo o le ACL necessarie.

Poiché queste identità appaiono nelle ACL tramite il loro object ID (non il nome), è prassi assegnarle a un Entra security group e mettere il gruppo nelle ACL: aggiungere o rimuovere un servizio diventa una modifica di membership, senza toccare le ACL sui file.

La trappola della propagazione delle ACL

Le ACL non si applicano retroattivamente. Le default ACL impostate su una cartella valgono solo per i nuovi file e sottocartelle creati dopo. Se modifichi le ACL di una directory che contiene già dati, i file esistenti mantengono le vecchie ACL: devi applicarle ricorsivamente (es. via az storage fs access set-recursive o PowerShell) per aggiornare tutto l’albero già presente.

Trappole tipiche d’esame

  • Serve accesso in scrittura a una singola cartella dentro un container → usa ACL POSIX sul percorso; l’RBAC sul container sarebbe troppo ampio.
  • Un principal ha Storage Blob Data Owner ma le ACL negano l’accesso a un file → l’accesso è comunque concesso: Data Owner è superuser e bypassa le ACL.
  • Hai impostato una default ACL ma i file già caricati restano inaccessibili → le default ACL non sono retroattive; applica le ACL in modalità recursive ai file esistenti.
  • ADF deve leggere da ADLS senza chiavi in chiaro → abilita la managed identity della data factory e assegnale Storage Blob Data Reader/Contributor (o ACL), non una SAS statica.
  • Un utente con ruolo Contributor sullo storage account non riesce a leggere i blob → il Contributor control-plane non dà accesso ai dati; serve un ruolo Storage Blob Data* o un’ACL.