Åtkomstkontrollmodell i Azure Data Lake Storage
Data Lake Storage stöder följande auktoriseringsmekanismer:
- Auktorisering av delad nyckel
- Auktorisering för signatur för delad åtkomst (SAS)
- Rollbaserad åtkomstkontroll (Azure RBAC)
- Attributbaserad åtkomstkontroll (Azure ABAC)
- Åtkomstkontrollistor (ACL)
Sas-auktorisering för delad nyckel, konto-SAS och tjänsten ger åtkomst till en användare (eller ett program) utan att kräva att de har en identitet i Microsoft Entra-ID. Med dessa former av autentisering har Azure RBAC, Azure ABAC och ACL:er ingen effekt. ACL:er kan tillämpas på användardelegerade SAS-token eftersom dessa token skyddas med Microsoft Entra-autentiseringsuppgifter. Se Delad nyckel och SAS-auktorisering.
Både RBAC och ACL kräver att användaren (eller programmet) har en identitet i Microsoft Entra ID. Med Azure RBAC kan du ge "grovkornig" åtkomst till lagringskontodata, till exempel läs- eller skrivåtkomst till alla data i ett lagringskonto. Med Azure ABAC kan du förfina RBAC-rolltilldelningar genom att lägga till villkor. Du kan till exempel bevilja läs- eller skrivåtkomst till alla dataobjekt i ett lagringskonto som har en specifik tagg. Med ACL:er kan du bevilja "finkornig" åtkomst, till exempel skrivåtkomst till en specifik katalog eller fil.
Den här artikeln fokuserar på Azure RBAC, ABAC och ACL:er och hur systemet utvärderar dem tillsammans för att fatta auktoriseringsbeslut för lagringskontoresurser.
Rollbaserad åtkomstkontroll (Azure RBAC)
Azure RBAC använder rolltilldelningar för att tillämpa uppsättningar med behörigheter på säkerhetsobjekt. Ett säkerhetsobjekt är ett objekt som representerar en användare, grupp, tjänstens huvudnamn eller hanterade identitet som definieras i Microsoft Entra-ID. En behörighetsuppsättning kan ge ett säkerhetsobjekt en "grov kornig" åtkomstnivå, till exempel läs- eller skrivåtkomst till alla data i ett lagringskonto eller alla data i en container.
Följande roller tillåter ett säkerhetsobjekt att komma åt data i ett lagringskonto.
| Roll | beskrivning |
|---|---|
| Storage Blob Data-ägare | Fullständig åtkomst till Blob Storage-containrar och data. Med den här åtkomsten kan säkerhetsobjektet ange ett objekt för ägaren och ändra ACL:erna för alla objekt. |
| Storage Blob datadeltagare | Läsa, skriva och ta bort åtkomst till Blob Storage-containrar och blobar. Den här åtkomsten tillåter inte att säkerhetsobjektet anger ägarskapet för ett objekt, men det kan ändra ACL för objekt som ägs av säkerhetsobjektet. |
| Storage Blob Data-läsare | Läsa och lista bloblagringscontainrar och blobar. |
Roller som Ägare, Deltagare, Läsare och Lagringskontodeltagare tillåter ett säkerhetsobjekt att hantera ett lagringskonto, men ger inte åtkomst till data i det kontot. Dessa roller (exklusive Läsare) kan dock få åtkomst till lagringsnycklarna, som kan användas i olika klientverktyg för att komma åt data.
Attributbaserad åtkomstkontroll (Azure ABAC)
Azure ABAC bygger på Azure RBAC genom att lägga till rolltilldelningsvillkor baserat på attribut i samband med specifika åtgärder. Ett rolltilldelningsvillkor är ytterligare en kontroll som du kan lägga till i rolltilldelningen för att ge mer förfinad åtkomstkontroll. Du kan inte uttryckligen neka åtkomst till specifika resurser med hjälp av villkor.
Mer information om hur du använder Azure ABAC för att styra åtkomsten till Azure Storage finns i Auktorisera åtkomst till Azure Blob Storage med hjälp av villkor för Rolltilldelning i Azure.
Åtkomstkontrollistor (ACL)
ACL:er ger dig möjlighet att använda "finare kornnivå" för åtkomst till kataloger och filer. En ACL är en behörighetskonstruktion som innehåller en serie ACL-poster. Varje ACL-post associerar säkerhetsobjektet med en åtkomstnivå. Mer information finns i Åtkomstkontrollistor (ACL: er) i Azure Data Lake Storage.
Så här utvärderas behörigheter
Under säkerhetshuvudnamnsbaserad auktorisering utvärderas behörigheter enligt följande diagram.
- Azure avgör om det finns en rolltilldelning för huvudkontot.
- Om det finns en rolltilldelning utvärderas villkor för rolltilldelning (2).
- Annars utvärderas ACL:erna (4) härnäst.
- Azure avgör om det finns några villkor för ABAC-rolltilldelning.
- Om det inte finns några villkor beviljas åtkomst.
- Om det finns villkor utvärderas de för att se om de matchar begäran (3).
- Azure avgör om alla ABAC-rolltilldelningsvillkor matchar attributen för begäran.
- Om alla matchar beviljas åtkomst.
- Om minst en av dem inte matchar utvärderas ACL:erna (4) härnäst.
- Om åtkomst inte uttryckligen har beviljats efter utvärdering av rolltilldelningar och villkor utvärderas ACL:erna.
- Om ACL:erna tillåter den begärda åtkomstnivån beviljas åtkomst.
- Om inte nekas åtkomst.
Viktigt!
På grund av hur åtkomstbehörigheter utvärderas av systemet kan du inte använda en ACL för att begränsa åtkomst som redan har beviljats av en rolltilldelning och dess villkor. Det beror på att systemet utvärderar Azure-rolltilldelningar och villkor först, och om tilldelningen ger tillräcklig åtkomstbehörighet ignoreras ACL:er.
Följande diagram visar behörighetsflödet för tre vanliga åtgärder: lista kataloginnehåll, läsa en fil och skriva en fil.
Behörighetstabell: Kombinera Azure RBAC, ABAC och ACL:er
I följande tabell visas hur du kombinerar Azure-roller, villkor och ACL-poster så att ett säkerhetsobjekt kan utföra de åtgärder som anges i kolumnen Åtgärd . Den här tabellen visar en kolumn som representerar varje nivå i en fiktiv kataloghierarki. Det finns en kolumn för rotkatalogen för containern (/), en underkatalog med namnet Oregon, en underkatalog till Oregon-katalogen med namnet Portland och en textfil i Portland-katalogen med namnet Data.txt. I dessa kolumner visas korta formulärrepresentationer av den ACL-post som krävs för att bevilja behörigheter. N/A (ej tillämpligt) visas i kolumnen om en ACL-post inte krävs för att utföra åtgärden.
| Åtgärd | Tilldelad Azure-roll (med eller utan villkor) | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Läs Data.txt | Ägare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas |
| Storage blobb data-deltagare | Saknas | Saknas | Saknas | Saknas | |
| Läsare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas | |
| Ingen | --X |
--X |
--X |
R-- |
|
| Lägg till i Data.txt | Ägare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas |
| Storage blobb data-deltagare | Saknas | Saknas | Saknas | Saknas | |
| Läsare av lagringsblobdata | --X |
--X |
--X |
-W- |
|
| Ingen | --X |
--X |
--X |
RW- |
|
| Ta bort Data.txt | Ägare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas |
| Storage blobb data-deltagare | Saknas | Saknas | Saknas | Saknas | |
| Läsare av lagringsblobdata | --X |
--X |
-WX |
Ej tillämpligt | |
| Ingen | --X |
--X |
-WX |
Ej tillämpligt | |
| Skapa/uppdatera Data.txt | Ägare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas |
| Storage blobb data-deltagare | Saknas | Saknas | Saknas | Saknas | |
| Läsare av lagringsblobdata | --X |
--X |
-WX |
Ej tillämpligt | |
| Ingen | --X |
--X |
-WX |
Ej tillämpligt | |
| Lista/ | Ägare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas |
| Storage blobb data-deltagare | Saknas | Saknas | Saknas | Saknas | |
| Läsare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas | |
| Ingen | R-X |
Saknas | Saknas | Saknas | |
| Lista /Oregon/ | Ägare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas |
| Storage blobb data-deltagare | Saknas | Saknas | Saknas | Saknas | |
| Läsare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas | |
| Ingen | --X |
R-X |
Saknas | Saknas | |
| Lista /Oregon/Portland/ | Ägare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas |
| Storage blobb data-deltagare | Saknas | Saknas | Saknas | Saknas | |
| Läsare av lagringsblobdata | Saknas | Saknas | Saknas | Saknas | |
| Ingen | --X |
--X |
R-X |
Inte tillgänglig |
Kommentar
Om du vill visa innehållet i en container i Azure Storage Explorer måste säkerhetsobjekt logga in på Storage Explorer med hjälp av Microsoft Entra-ID och (minst) ha läsbehörighet (R--) till rotmappen (\) för en container. Den här behörighetsnivån ger dem möjlighet att lista innehållet i rotmappen. Om du inte vill att innehållet i rotmappen ska visas kan du tilldela dem rollen Läsare . Med den rollen kan de lista containrarna i kontot, men inte containerinnehållet. Du kan sedan bevilja åtkomst till specifika kataloger och filer med hjälp av ACL:er.
Säkerhetsgrupper
Använd alltid Microsoft Entra-säkerhetsgrupper som det tilldelade huvudkontot i en ACL-post. Motstå möjligheten att tilldela enskilda användare eller tjänstens huvudnamn direkt. Med denna struktur kan du lägga till och ta bort användare eller tjänstens huvudnamn utan att behöva tillämpa ACL:er på en hel katalogstruktur igen. I stället kan du bara lägga till eller ta bort användare och tjänstens huvudnamn från lämplig Microsoft Entra-säkerhetsgrupp.
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 (ADF) 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, och olika Databricks-kluster analyserar loggar från den mappen.
Om du vill aktivera dessa aktiviteter kan du skapa en LogsWriter grupp och en LogsReader grupp. Sedan kan du tilldela behörigheter på följande sätt:
LogsWriterLägg till gruppen i ACL:en för katalogen /LogData medrwxbehörigheter.LogsReaderLägg till gruppen i ACL:en för katalogen /LogData medr-xbehörigheter.- Lägg till tjänstens huvudnamnsobjekt eller hanterad tjänstidentitet (MSI) för ADF i
LogsWritersgruppen. - Lägg till användare i serviceteknikteamet i
LogsWritergruppen. - Lägg till objektet för tjänstens huvudnamn eller MSI för Databricks i
LogsReadergruppen.
Om en användare i serviceteknikteamet lämnar företaget kan du bara ta bort dem från LogsWriter gruppen. Om du inte lade till den 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 katalogen /LogData . Du måste också ta bort posten från alla underkataloger och filer i hela kataloghierarkin i katalogen /LogData .
Information om hur du skapar en grupp och lägger till medlemmar finns i Skapa en grundläggande grupp och lägg till medlemmar med hjälp av Microsoft Entra-ID.
Viktigt!
Azure Data Lake Storage Gen2 är beroende av Microsoft Entra-ID för att hantera säkerhetsgrupper. Microsoft Entra ID rekommenderar att du begränsar gruppmedlemskap för ett visst säkerhetsobjekt till mindre än 200. Den här rekommendationen beror på en begränsning av JSON-webbtoken (JWT) som tillhandahåller information om säkerhetsobjektets gruppmedlemskap i Microsoft Entra-program. Om du överskrider den här gränsen kan det leda till oväntade prestandaproblem med Data Lake Storage Gen2. Mer information finns i Konfigurera gruppanspråk för program med hjälp av Microsoft Entra-ID.
Begränsningar för Azure-rolltilldelningar och ACL-poster
Genom att använda grupper är det mindre troligt att du överskrider det maximala antalet rolltilldelningar per prenumeration och det maximala antalet ACL-poster per fil eller katalog. I följande tabell beskrivs dessa gränser.
| Mekanism | Omfattning | Gränser | Behörighetsnivå som stöds |
|---|---|---|---|
| Azure RBAC | Lagringskonton, containrar. Azure-rolltilldelningar mellan resurser på prenumerations- eller resursgruppsnivå. |
4000 Azure-rolltilldelningar i en prenumeration | Azure-roller (inbyggda eller anpassade) |
| ACL | Katalog, fil | 32 ACL-poster (i praktiken 28 ACL-poster) per fil och per katalog. Åtkomst- och standard-ACL:er har varsin gräns på 32 ACL. | ACL-behörighet |
Sas-auktorisering (Signatur för delad nyckel och signatur för delad åtkomst)
Azure Data Lake Storage stöder även metoder för delad nyckel och SAS för autentisering.
När det gäller delad nyckel får anroparen effektivt "superanvändare"-åtkomst, vilket innebär fullständig åtkomst till alla åtgärder på alla resurser, inklusive data, inställning av ägare och ändrade ACL:er. ACL:er gäller inte för användare som använder auktorisering av delad nyckel eftersom ingen identitet är associerad med anroparen och därför kan behörighetsbaserad behörighetsbaserad auktorisering för säkerhetsobjekt inte utföras. Detsamma gäller för SAS-token (signatur för delad åtkomst), förutom när en användardelegering av SAS-token används. I så fall utför Azure Storage en POSIX ACL-kontroll mot objekt-ID:t innan åtgärden godkänns så länge den valfria parametern suoid används. Mer information finns i Skapa en SAS för användardelegering.
Nästa steg
Mer information om åtkomstkontrollistor finns i Åtkomstkontrollistor (ACL: er) i Azure Data Lake Storage.