Share via

Åtkomstkontroll och datasjökonfigurationer i Azure Data Lake Storage Gen2

  • Artikel

Den här artikeln hjälper dig att utvärdera och förstå mekanismerna för åtkomstkontroll i Azure Data Lake Storage Gen2. Dessa mekanismer omfattar rollbaserad åtkomstkontroll i Azure (RBAC) och åtkomstkontrollistor (ACL). Du får lära dig:

  • Så här utvärderar du åtkomst mellan Azure RBAC och ACL:er
  • Så här konfigurerar du åtkomstkontroll med hjälp av en eller båda dessa mekanismer
  • Så här tillämpar du mekanismerna för åtkomstkontroll på implementeringsmönster för datasjöar

Du behöver grundläggande kunskaper om lagringscontainrar, säkerhetsgrupper, Azure RBAC och ACL:er. För att rama in diskussionen refererar vi till en allmän datasjöstruktur med råa, berikade och kuraterade zoner.

Du kan använda det här dokumentet med dataåtkomsthantering.

Använda de inbyggda Azure RBAC-rollerna

Azure Storage har två åtkomstlager: tjänsthantering och data. Du kan komma åt prenumerationer och lagringskonton via tjänsthanteringsskiktet. Få åtkomst till containrar, blobar och andra dataresurser via datalagret. Om du till exempel vill ha en lista över lagringskonton från Azure skickar du en begäran till hanteringsslutpunkten. Om du vill ha en lista över filsystem, mappar eller filer i ett lagringskonto skickar du en begäran till en tjänstslutpunkt.

Roller kan innehålla behörigheter för hantering eller datalageråtkomst. Rollen Läsare ger skrivskyddad åtkomst till hanteringslagerresurser men inte läsåtkomst till data.

Roller som Ägare, Deltagare, Läsare och Lagringskontodeltagare tillåter ett säkerhetsobjekt att hantera ett lagringskonto. Men de ger inte åtkomst till data i det kontot. Endast roller som uttryckligen definierats för dataåtkomst tillåter ett säkerhetsobjekt att komma åt data. Dessa roller, förutom Läsare, får åtkomst till lagringsnycklarna för att komma åt data.

Inbyggda hanteringsroller

Följande är de inbyggda hanteringsrollerna.

  • Ägare: Hantera allt, inklusive åtkomst till resurser. Den här rollen ger nyckelåtkomst.
  • Deltagare: Hantera allt, förutom åtkomst till resurser. Den här rollen ger nyckelåtkomst.
  • Deltagare i lagringskonto: Fullständig hantering av lagringskonton. Den här rollen ger nyckelåtkomst.
  • Läsare: Läs- och listresurser. Den här rollen ger inte nyckelåtkomst.

Inbyggda dataroller

Följande är de inbyggda datarollerna.

Lagringsblobdataägaren är en superanvändarroll som beviljas fullständig åtkomst till alla muterande åtgärder. Dessa åtgärder omfattar att ange ägaren till en katalog eller fil och ACL:er för kataloger och filer som de inte är ägare till. Superanvändaråtkomst är det enda auktoriserade sättet att ändra ägaren till en resurs.

Kommentar

Azure RBAC-tilldelningar kan ta upp till fem minuter att sprida och börja gälla.

Hur åtkomst utvärderas

Under säkerhetshuvudnamnsbaserad auktorisering utvärderar systemet behörigheter i följande ordning. Mer information finns i följande diagram.

  • Azure RBAC utvärderas först och prioriteras framför alla ACL-tilldelningar.
  • Om åtgärden är fullständigt auktoriserad baserat på RBAC utvärderas inte ACL:er alls.
  • Om åtgärden inte är helt auktoriserad utvärderas ACL:er.

Mer information finns i Så här utvärderas behörigheter.

Kommentar

Den här behörighetsmodellen gäller endast för Azure Data Lake Storage. Det gäller inte för generell användning eller bloblagring utan hierarkiskt namnområde aktiverat. Den här beskrivningen exkluderar metoder för delad nyckel och SAS-autentisering. Det utesluter också scenarier där säkerhetsobjektet tilldelas den inbyggda rollen Storage Blob Data Owner, som ger superanvändare åtkomst. Ställ in allowSharedKeyAccess på false så att åtkomsten granskas av identiteten.

Diagram of a flow chart that shows how access is evaluated.

Mer information om vilka ACL-baserade behörigheter som krävs för en viss åtgärd finns i Åtkomstkontrollistor i Azure Data Lake Storage Gen2.

Kommentar

  • Åtkomstkontrollistor gäller endast för säkerhetsobjekt i samma klientorganisation, inklusive gästanvändare.
  • Alla användare med behörighet att ansluta till ett kluster kan skapa Azure Databricks-monteringspunkter. Konfigurera monteringspunkten med autentiseringsuppgifter för tjänstens huvudnamn eller genomströmningsalternativet Microsoft Entra. Vid tidpunkten för skapandet utvärderas inte behörigheter. Behörigheter utvärderas när en åtgärd använder monteringspunkten. Alla användare som kan ansluta till ett kluster kan försöka använda monteringspunkten.
  • När en användare skapar en tabelldefinition i Azure Databricks eller Azure Synapse Analytics måste de ha läsbehörighet till underliggande data.

Konfigurera åtkomst till Azure Data Lake Storage

Konfigurera åtkomstkontroll i Azure Data Lake Storage med hjälp av Azure RBAC, ACL:er eller en kombination av båda.

Konfigurera endast åtkomst med Hjälp av Azure RBAC

Om åtkomstkontroll på containernivå räcker erbjuder Azure RBAC-tilldelningar en enkel hanteringsmetod för att skydda data. Vi rekommenderar att du använder åtkomstkontrollistor för ett stort antal begränsade datatillgångar eller där du behöver detaljerad åtkomstkontroll.

Konfigurera endast åtkomst med hjälp av ACL:er

Följande är åtkomstkontrollistor för konfigurationsrekommendationer för analys i molnskala.

Tilldela åtkomstkontrollposter till en säkerhetsgrupp i stället för en enskild användare eller tjänstens huvudnamn. Mer information finns i Använda säkerhetsgrupper jämfört med enskilda användare.

När du lägger till eller tar bort användare från gruppen behöver du inte göra uppdateringar av Data Lake Storage. Att använda grupper minskar också risken för att överskrida de 32 åtkomstkontrollposterna per fil- eller mapp-ACL. Efter de fyra standardposterna finns det bara 28 återstående poster för behörighetstilldelningar.

Även när du använder grupper kan du ha många åtkomstkontrollposter på de översta nivåerna i katalogträdet. Den här situationen inträffar när detaljerade behörigheter för olika grupper krävs.

Diagram that shows several security groups requiring access to three data products.

Konfigurera åtkomst med hjälp av både Azure RBAC- och åtkomstkontrollistor

Behörigheterna Storage Blob Data Contributor och Storage Blob Data Reader ger åtkomst till data och inte lagringskontot. Du kan bevilja åtkomst på lagringskontonivå eller containernivå. Om Storage Blob Data Contributor har tilldelats kan ACL:er inte användas för att hantera åtkomst. Där Storage Blob Data Reader har tilldelats kan du bevilja utökade skrivbehörigheter med hjälp av ACL:er. Mer information finns i Hur åtkomst utvärderas.

Den här metoden gynnar scenarier där de flesta användare behöver läsåtkomst men bara ett fåtal användare behöver skrivåtkomst. Datasjözonerna kan vara olika lagringskonton och datatillgångar kan vara olika containrar. Datasjözonerna kan representeras av containrar och datatillgångar som representeras av mappar.

Gruppmetoder för kapslad åtkomstkontrollista

Det finns två metoder för kapslade ACL-grupper.

Alternativ 1: Den överordnade körningsgruppen

Innan du skapar filer och mappar börjar du med en överordnad grupp. Tilldela behörigheterna för gruppkörning till både standard- och åtkomst-ACL:er på containernivå. Lägg sedan till de grupper som kräver dataåtkomst till den överordnade gruppen.

Varning

Vi rekommenderar att du inte använder det här mönstret där du har rekursiva borttagningar och i stället använder alternativ 2: Den andra posten i åtkomstkontrollistan.

Den här tekniken kallas kapslingsgrupper. Medlemsgruppen ärver behörigheterna för den överordnade gruppen, vilket ger globala körningsbehörigheter till alla medlemsgrupper. Medlemsgruppen behöver inte körningsbehörigheter eftersom dessa behörigheter ärvs. Mer kapsling kan ge större flexibilitet och flexibilitet. Lägg till säkerhetsgrupper som representerar team eller automatiserade jobb i dataåtkomstläsar- och skrivargrupper.

Diagram that shows nested groups where global run includes data assets for readers and writers and includes analysis team and engineering jobs.

Alternativ 2: Den andra posten i åtkomstkontrollistan

Den rekommenderade metoden är att använda den andra ACL-posten i containern eller roten. Ange standardvärden och åtkomst-ACL:er enligt följande skärm. Den här metoden säkerställer att varje del av sökvägen från rot till lägsta nivå har körningsbehörigheter.

Screen capture that shows the manage access dialog box with other highlighted and access and default selected.

Den här körningsbehörigheten sprids nedåt till eventuella tillagda underordnade mappar. Behörigheten sprids till djupet där den avsedda åtkomstgruppen behöver behörighet att läsa och köra. Nivån är i den lägsta delen av kedjan, som du ser på följande skärm. Den här metoden ger gruppåtkomst för att läsa data. Metoden fungerar på samma sätt för skrivåtkomst.

Screen capture that shows the manage access dialog box with businessgrp 1 highlighted and access and default selected.

Följande användningar är de rekommenderade säkerhetsmönstren för var och en av datasjözonerna:

  • Rådata bör endast tillåta åtkomst till data med hjälp av säkerhetshuvudnamn (SPN).
  • Utökad bör endast tillåta åtkomst till data med hjälp av säkerhetshuvudnamn (SPN).
  • Kuraterad bör tillåta åtkomst med både säkerhetshuvudnamn (SPN) och användarhuvudnamn (UPN).

Exempelscenario för att använda Microsoft Entra-säkerhetsgrupper

Det finns många olika sätt att konfigurera grupper. Anta till exempel att du har en katalog med namnet /LogData som innehåller loggdata som genereras av servern. Azure Data Factory matar in data i den mappen. Specifika användare från tjänstutvecklingsteamet laddar upp loggar och hanterar andra användare av den här mappen. Azure Databricks-analys- och data science-arbetsytekluster kan analysera loggar från den mappen.

Om du vill aktivera dessa aktiviteter skapar du en LogsWriter grupp och en LogsReader grupp. Tilldela följande behörigheter:

  • LogsWriter Lägg till gruppen i ACL:en för /LogData katalogen med rwx behörigheter.
  • LogsReader Lägg till gruppen i ACL:en för /LogData katalogen med r-x behörigheter.
  • Lägg till objektet för tjänstens huvudnamn eller den hanterade tjänstidentiteten (MSI) för Data Factory i LogsWriters gruppen.
  • Lägg till användare i serviceteknikteamet i LogsWriter gruppen.
  • Azure Databricks har konfigurerats för Microsoft Entra-genomströmning till Azure Data Lake Store.

Om en användare i tjänstutvecklingsteamet överförs till ett annat team tar du bara bort användaren från LogsWriter gruppen.

Om du inte lade till användaren i en grupp, utan i stället lade till en dedikerad ACL-post för den användaren, måste du ta bort den ACL-posten från /LogData katalogen. Du måste också ta bort posten från alla underkataloger och filer i hela kataloghierarkin i /LogData katalogen.

Åtkomstkontroll för Azure Synapse Analytics-data

För att distribuera en Azure Synapse-arbetsyta krävs ett Azure Data Lake Storage Gen2-konto. Azure Synapse Analytics använder det primära lagringskontot för flera integreringsscenarier och lagrar data i en container. Containern innehåller Apache Spark-tabeller och programloggar under en mapp med namnet /synapse/{workspaceName}. Arbetsytan använder också en container för att hantera bibliotek som du installerar.

Under distributionen av arbetsytan via Azure-portalen anger du ett befintligt lagringskonto eller skapar ett nytt. Det angivna lagringskontot är arbetsytans primära lagringskonto. Distributionsprocessen ger arbetsytans identitet åtkomst till det angivna Data Lake Storage Gen2-kontot med hjälp av rollen Storage Blob Data Contributor .

Om du distribuerar arbetsytan utanför Azure-portalen lägger du manuellt till Azure Synapse Analytics-arbetsytans identitet i rollen Storage Blob Data Contributor . Vi rekommenderar att du tilldelar rollen Storage Blob Data-deltagare på containernivå för att följa principen om minsta behörighet.

När du kör pipelines, arbetsflöden och notebook-filer via jobb använder de behörighetskontexten för arbetsytans identitet. Om något av jobben läser eller skriver till arbetsytans primära lagring använder arbetsytans identitet de läs-/skrivbehörigheter som beviljats via lagringsbloggens datadeltagare.

När användare loggar in på arbetsytan för att köra skript eller för utveckling tillåter användarens kontextbehörigheter läs- och skrivåtkomst på den primära lagringen.

Detaljerad dataåtkomstkontroll i Azure Synapse Analytics med hjälp av åtkomstkontrollistor

När du konfigurerar åtkomstkontroll för Data Lake kräver vissa organisationer detaljerad åtkomst på nivå. De kan ha känsliga data som inte kan ses av vissa grupper i organisationen. Azure RBAC tillåter endast läsning eller skrivning på lagringskonto- och containernivå. Med ACL:er kan du konfigurera detaljerad åtkomstkontroll på mapp- och filnivå för att tillåta läsning/skrivning på en delmängd data för specifika grupper.

Att tänka på när du använder Spark-tabeller

När du använder Apache Spark-tabeller i Spark-poolen skapas en lagermapp. Mappen finns i roten för containern i arbetsytans primära lagring:

synapse/workspaces/{workspaceName}/warehouse

Om du planerar att skapa Apache Spark-tabeller i Azure Synapse Spark-poolen beviljar du skrivbehörighet för lagermappen för gruppen som kör kommandot som skapar Spark-tabellen. Om kommandot körs via ett utlöst jobb i en pipeline beviljar du skrivbehörighet till arbetsytans MSI.

Det här exemplet skapar en Spark-tabell:

df.write.saveAsTable("table01")

Mer information finns i Konfigurera åtkomstkontroll för synapse-arbetsytan.

Sammanfattning av Azure Data Lake-åtkomst

Ingen enskild metod för att hantera datasjöåtkomst passar alla. En stor fördel med en datasjö är att ge friktionsfri åtkomst till data. I praktiken vill olika organisationer ha olika styrningsnivåer och kontroll över sina data. Vissa organisationer har ett centraliserat team för att hantera åtkomst- och etableringsgrupper under rigorösa interna kontroller. Andra organisationer är mer flexibla och har decentraliserad kontroll. Välj den metod som uppfyller din styrningsnivå. Ditt val bör inte leda till onödiga fördröjningar eller friktion när det gäller att få åtkomst till data.

Nästa steg