Az Azure Data Lake Storage Gen2 hozzáférés-vezérlési listái (ACL-ek)

Az Azure Data Lake Storage Gen2 olyan hozzáférés-vezérlési modellt implementál, amely támogatja az Azure szerepköralapú hozzáférés-vezérlést (Azure RBAC) és a POSIX-szerű hozzáférés-vezérlési listákat (ACL-eket). Ez a cikk a Data Lake Storage Gen2 hozzáférés-vezérlési listáit ismerteti. Az Azure RBAC és az ACL-ek együttes beépítéséről, valamint arról, hogy a rendszer hogyan értékeli ki őket engedélyezési döntések meghozatalához, tekintse meg az Azure Data Lake Storage Gen2 hozzáférés-vezérlési modelljét.

Tudnivalók az ACL-ekről

A biztonsági tagokat hozzárendelheti a fájlok és könyvtárak hozzáférési szintjéhez. Minden társítás bejegyzésként van rögzítve egy hozzáférés-vezérlési listában (ACL). A tárfiók minden fájlja és könyvtára rendelkezik hozzáférés-vezérlési listával. Amikor egy biztonsági tag műveletet kísérel meg egy fájlon vagy könyvtáron, az ACL ellenőrzi, hogy az adott biztonsági tag (felhasználó, csoport, szolgáltatásnév vagy felügyelt identitás) rendelkezik-e a megfelelő jogosultsági szinttel a művelet végrehajtásához.

Feljegyzés

Az ACL-ek csak az ugyanazon bérlőben lévő biztonsági tagokra vonatkoznak, és nem vonatkoznak a megosztott kulcsú vagy sas-jogkivonat-hitelesítést használó felhasználókra. Ennek az az oka, hogy nincs identitás társítva a hívóhoz, ezért a rendszerbiztonsági tagok engedélyalapú engedélyezése nem hajtható végre.

ACL-ek beállítása

A fájl- és könyvtárszintű engedélyek beállításához lásd a következő cikkek bármelyikét:

Környezet	Cikk
Azure Storage Explorer	Az Azure Storage Explorer használatával kezelheti az ACL-eket az Azure Data Lake Storage Gen2-ben
Azure Portal	Az Azure Portal használatával kezelheti az ACL-eket az Azure Data Lake Storage Gen2-ben
.NET	A .NET használata az ACL-ek kezeléséhez az Azure Data Lake Storage Gen2-ben
Java	Az ACL-ek kezelése a Java használatával az Azure Data Lake Storage Gen2-ben
Python	A Python használata az ACL-ek kezeléséhez az Azure Data Lake Storage Gen2-ben
JavaScript (Node.js)	A JavaScript SDK használata a Node.js-ben az ACL-ek kezeléséhez az Azure Data Lake Storage Gen2-ben
PowerShell	Az ACL-ek kezelése a PowerShell használatával az Azure Data Lake Storage Gen2-ben
Azure CLI	Az Azure CLI használata az ACL-ek kezeléséhez az Azure Data Lake Storage Gen2-ben
REST API	Elérési út – Frissítés

Fontos

Ha a biztonsági egyszerű szolgáltatásnév , fontos, hogy a szolgáltatásnév objektumazonosítóját használja, és ne a kapcsolódó alkalmazásregisztráció objektumazonosítóját. A szolgáltatásnév objektumazonosítójának lekéréséhez nyissa meg az Azure CLI-t, majd használja a következő parancsot: az ad sp show --id <Your App ID> --query objectId. Mindenképpen cserélje le a <Your App ID> helyőrzőt az alkalmazásregisztráció alkalmazásazonosítójára. A szolgáltatásnév nevesített felhasználóként lesz kezelve. Ezt az azonosítót ugyanúgy fogja hozzáadni az ACL-hez, mint bármely nevesített felhasználó. A nevesített felhasználókról a cikk későbbi részében olvashat.

ACL-ek típusai

Kétféle hozzáférés-vezérlési lista létezik: hozzáférési ACL-ek és alapértelmezett ACL-ek.

Az access ACL-ek szabályozzák az objektumokhoz való hozzáférést. A fájlok és könyvtárak egyaránt rendelkeznek hozzáférési ACL-ekkel.

Az alapértelmezett ACL-ek olyan címtárhoz társított ACL-sablonok, amelyek meghatározzák az adott könyvtárban létrehozott gyermekelemek hozzáférési ACL-jeit. A fájlok nem rendelkeznek alapértelmezett ACL-sel.

A hozzáférési ACL-ek és az alapértelmezett ACL-ek is ugyanazzal a struktúrával rendelkeznek.

Feljegyzés

Az alapértelmezett ACL megváltoztatása egy szülői elemen nem befolyásolja a már létező gyermekelemek hozzáférési ACL-jét vagy alapértelmezett ACL-jét.

Jogosultsági szintek

A tárolóban lévő könyvtárakra és fájlokra vonatkozó engedélyek olvasási, írási és végrehajtási engedélyek, és az alábbi táblázatban látható módon használhatók fájlokon és könyvtárakon:

	Fájl	Címtár
Olvasás (R)	Olvashatja a fájl tartalmát	Olvasást és végrehajtást igényel a címtár tartalmának listázásához
Írás (W)	Írhatja a fájlt vagy hozzáfűzhet a fájlhoz	Gyermekelemek könyvtárban való létrehozásához írásra és végrehajtásra van szükség
Végrehajtás (X)	Nem jelent semmit a Data Lake Storage Gen2 környezetében	Könyvtár gyermekelemeinek bejárásához szükséges

Feljegyzés

Ha csak ACL-ek használatával ad engedélyeket (azure RBAC nélkül), akkor ahhoz, hogy egy biztonsági tag olvasási vagy írási hozzáférést biztosítson egy fájlhoz, végrehajtási engedélyeket kell adnia a biztonsági tagnak a tároló gyökérmappájára és a fájlhoz vezető mappák hierarchiájának minden mappájára.

Az engedélyek rövid alakjai

RWX az Olvasás + Írás + Végrehajtás engedélyt jelöli. Egy tömörebb, numerikus formátum is létezik, amelyben Olvasás=4, Írás=2 és Végrehajtás=1, és az összegük jelöli az engedélyeket. Az alábbiakban néhány példa látható.

Numerikus alak	Rövid alak	Mit jelent
7	RWX	Olvasás + Írás + Végrehajtás
5	R-X	Olvasás + Végrehajtás
4	R--	Olvasás
0	---	Nincs engedély

Engedélyek öröklése

A Data Lake Storage Gen2 által használt POSIX-stílusú modellben az elemhez tartozó jogosultságok magán az elemen tárolódnak. Más szóval egy elem nem örökölhet engedélyeket a szülőelemektől, ha az engedélyek a gyermekelem létrehozása után lettek beállítva. A jogosultságok csak akkor öröklődnek, ha a szülői elemek alapértelmezett jogosultságai a gyermek elemek létrehozása előtt lettek beállítva.

Az ACL engedélyekhez kapcsolódó gyakori helyzetek

Az alábbi táblázat azokat az ACL-bejegyzéseket mutatja be, amelyek szükségesek ahhoz, hogy egy biztonsági tag végrehajthassa a Művelet oszlopban felsorolt műveleteket.

Ez a táblázat egy olyan oszlopot jelenít meg, amely egy fiktív címtárhierarchia minden szintjét képviseli. Van egy oszlop a tároló gyökérkönyvtárához (/), egy Oregon nevű alkönyvtárhoz, egy Portland nevű Oregon könyvtár alkönyvtárához, valamint egy szövegfájlhoz a Portland könyvtárban Data.txt.

Fontos

Ez a táblázat feltételezi, hogy csak azure-beli szerepkör-hozzárendelések nélküli ACL-eket használ. Az Azure RBAC-t az ACL-ekkel kombináló hasonló táblázat megtekintéséhez tekintse meg az Engedélyek táblát: Az Azure RBAC, az ABAC és az ACL kombinálása.

Művelet	/	Oregon/	Portland/	Data.txt
Olvasási Data.txt	--X	--X	--X	R--
Hozzáfűzés a Data.txt	--X	--X	--X	RW-
Data.txt törlése	--X	--X	-WX	---
Törlés /Oregon/	-WX	RWX	RWX	RWX
Törlés /Oregon/Portland/	--X	-WX	RWX	RWX
Data.txt létrehozása	--X	--X	-WX	---
Lista/	R-X	---	---	---
Lista /Oregon/	--X	R-X	---	---
Lista /Oregon/Portland/	--X	--X	R-X	---

Fájlok és könyvtárak törlése

Ahogy az előző táblázatban is látható, a fájl írási engedélyei nem szükségesek a törléshez mindaddig, amíg az előző két feltétel teljesül. Ha azonban törölni szeretne egy könyvtárat és annak teljes tartalmát, a szülőkönyvtárnak írási és végrehajtási engedélyekkel kell rendelkeznie. A törölni kívánt könyvtárhoz és azon belül minden könyvtárhoz olvasási és írási és végrehajtási engedélyek szükségesek.

Feljegyzés

A "/" gyökérkönyvtár soha nem törölhető.

Felhasználók és identitások

Minden fájl és könyvtár különböző engedélyekkel rendelkezik ezekhez az identitásokhoz:

• A tulajdonos felhasználó
• A tulajdonoscsoport
• Nevesített felhasználók
• Nevesített csoportok
• Névvel ellátott szolgáltatásnevek
• Elnevezett felügyelt identitások
• Minden egyéb felhasználó

A felhasználók és csoportok identitásai a Microsoft Entra-identitások. Ha tehát másként nem jelezzük, a Data Lake Storage Gen2 környezetében egy felhasználó hivatkozhat Egy Microsoft Entra-felhasználóra, szolgáltatásnévre, felügyelt identitásra vagy biztonsági csoportra.

A felügyelő

A felügyelők a legtöbb jogosultságot az összes felhasználó. A felügyelő:

• RWX-engedéllyel (olvasás, írás és végrehajtás) rendelkezik az összes fájlhoz és mappához.

• Bármely fájl vagy mappa engedélyeit megváltoztathatja.

• Bármely fájl vagy mappa tulajdonosát vagy tulajdonoscsoportját megváltoztathatja.

Ha egy tárolót, fájlt vagy könyvtárat megosztott kulcs, fiók SAS vagy szolgáltatás SAS használatával hoz létre, akkor a tulajdonos és a tulajdonoscsoport a következőre $superuservan állítva: .

A tulajdonos felhasználó

Automatikusan az elem tulajdonosa lesz az a felhasználó, aki létrehozta az elemet. A tulajdonos felhasználó:

• Megváltoztathatja a tulajdonában lévő fájl engedélyeit.
• megváltoztathatja a tulajdonában lévő fájl tulajdonos csoportját, ha a tulajdonos felhasználó szintén tagja ennek a csoportnak.

Feljegyzés

A tulajdonos felhasználó nem módosíthatja egy fájl vagy könyvtár tulajdonos felhasználóját. Csak a felügyelők módosíthatják egy fájl vagy könyvtár tulajdonos felhasználóját.

A tulajdonoscsoport

A POSIX ACL-ben minden felhasználó egy elsődleges csoporthoz van társítva. Az "Alice" felhasználó például a "pénzügyi" csoporthoz tartozhat. Alice több csoporthoz is tartozhat, de egy csoport mindig elsődleges csoportként van kijelölve. A POSIX-ban, amikor Alice létrehoz egy fájlt, a fájl tulajdonoscsoportja az elsődleges csoportjára van állítva, amely ebben az esetben a "pénzügy". A tulajdonoscsoport egyébként ugyanúgy viselkedik, mint más felhasználók/csoportok hozzárendelt engedélyei.

A tulajdonoscsoport hozzárendelése új fájlhoz vagy könyvtárhoz

• 1. eset: A gyökérkönyvtár /. Ez a könyvtár egy Data Lake Storage Gen2-tároló létrehozásakor jön létre. Ebben az esetben a tulajdonoscsoport a tárolót létrehozó felhasználóra van állítva, ha az OAuth használatával történt. Ha a tároló megosztott kulccsal, fiók SAS-sel vagy service SAS-sel jön létre, akkor a tulajdonos és a tulajdonoscsoport a következőre $superuservan állítva: .
• 2. eset (minden más eset): Új elem létrehozásakor a tulajdonoscsoport ki lesz másolva a szülőkönyvtárból.

A tulajdonoscsoport módosítása

A tulajdonoscsoportot megváltoztathatja:

• Bármely felügyelő.
• a tulajdonos, ha szintén tagja ennek a csoportnak.

Feljegyzés

A tulajdonoscsoport nem tudja módosítani egy fájl vagy könyvtár ACL-jeit. Bár a tulajdonoscsoport a legfelső szintű címtár esetében a fiókot létrehozó felhasználóra van állítva, a fenti 1 . eset esetében egyetlen felhasználói fiók nem érvényes a tulajdonoscsoporton keresztüli engedélyek megadására. Az engedélyt hozzárendelheti egy érvényes felhasználócsoporthoz, ha van ilyen.

Hogyan történik az engedélyek értékelése?

Az identitások kiértékelése a következő sorrendben történik:

1. Superuser felhasználó
2. Tulajdonos felhasználó
3. Elnevezett felhasználó, szolgáltatásnév vagy felügyelt identitás
4. Tulajdonoscsoport vagy elnevezett csoport
5. Minden egyéb felhasználó

Ha ezen identitások közül több is vonatkozik egy biztonsági tagra, akkor az első identitáshoz társított jogosultsági szint meg lesz adva. Ha például egy biztonsági tag a tulajdonos felhasználó és egy elnevezett felhasználó is, akkor a tulajdonos felhasználóhoz társított jogosultsági szint érvényes.

A névvel ellátott csoportok együtt tekinthetők meg. Ha egy biztonsági tag egynél több nevesített csoport tagja, akkor a rendszer kiértékeli az egyes csoportokat, amíg meg nem adja a kívánt engedélyt. Ha egyik nevesített csoport sem adja meg a kívánt engedélyt, akkor a rendszer továbbhalad, hogy kiértékelje a kérést az összes többi felhasználóhoz társított engedély alapján.

Az alábbi pszeudokód a tárfiókok hozzáférés-ellenőrzési algoritmusát jelöli. Ez az algoritmus az identitások kiértékelésének sorrendjét jeleníti meg.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

A maszk

Ahogy az a Hozzáférés-ellenőrzési algoritmusban látható, a maszk korlátozza az elnevezett felhasználók, a tulajdonoscsoport és a névvel ellátott csoportok hozzáférését.

Egy új Data Lake Storage Gen2-tároló esetében a gyökérkönyvtár ("/") hozzáférési ACL-jének maszkja alapértelmezés szerint 750 a címtárak esetében, a fájlok esetében pedig 640 . Az alábbi táblázat az engedélyszintek szimbolikus jelölését mutatja be.

Entitás	Címtárak	Fájlok
Tulajdonos felhasználó	rwx	rw-
Tulajdonoscsoport	r-x	r--
Egyéb	---	---

A fájlok nem kapják meg az X bitet, mivel nem releváns a csak tárolórendszerbeli fájlok számára.

A maszk hívásonként adható meg. Ez lehetővé teszi, hogy a különböző fogyasztó rendszerek, például a fürtök különböző hatékony maszkokkal rendelkezzenek a fájlműveleteikhez. Ha egy maszk egy adott kérelemben van megadva, az teljesen felülírja az alapértelmezett maszkot.

Ragadós bit

A ragadós bit a POSIX-tároló fejlettebb funkciója. A Data Lake Storage Gen2 környezetében nem valószínű, hogy a ragadós bitre lesz szükség. Összefoglalva, ha a ragadós bit engedélyezve van egy könyvtárban, a gyermekelemet csak a gyermekelem tulajdonos felhasználója, a könyvtár tulajdonosa vagy a Superuser ($superuser) törölheti vagy nevezheti át.

A ragadós bit nem jelenik meg az Azure Portalon.

Alapértelmezett engedélyek az új fájlokhoz és könyvtárakhoz

Amikor egy meglévő könyvtár alatt új fájl vagy könyvtár jön létre, a szülő könyvtár alapértelmezett ACL-je határozza meg:

• A gyermekkönyvtár alapértelmezett ACL-je és hozzáférési ACL-je.
• Egy gyermekfájl hozzáférési ACL-je (a fájloknak nincs alapértelmezett ACL-je).

umask

Alapértelmezett ACL létrehozásakor a rendszer az umaskot alkalmazza a hozzáférési ACL-hez az alapértelmezett ACL kezdeti engedélyeinek meghatározásához. Ha egy alapértelmezett ACL van definiálva a szülőkönyvtárban, a rendszer ténylegesen figyelmen kívül hagyja az umaszkot, és ehelyett a szülőkönyvtár alapértelmezett ACL-ével definiálja ezeket a kezdeti értékeket.

Az umask egy 9 bites érték a szülőkönyvtárakban, amely egy RWX-értéket tartalmaz a felhasználó, a tulajdonoscsoport és egyéb tulajdonlására.

Az umask for Azure Data Lake Storage Gen2 állandó értéke 007. Ez az érték a következőre fordítható:

umask összetevő	Numerikus alak	Rövid alak	Értelmezés
umask.owning_user	0	---	Tulajdonos felhasználó esetén másolja a szülő hozzáférési ACL-jét a gyermek alapértelmezett ACL-ére
umask.owning_group	0	---	Tulajdonoscsoport esetén másolja a szülő hozzáférési ACL-jét a gyermek alapértelmezett ACL-ére
umask.other	7	RWX	Más esetben távolítsa el a gyermek hozzáférési ACL-jének összes engedélyét

GYIK

Engedélyeznem kell az ACL támogatását?

Szám Az ACL-eken keresztüli hozzáférés-vezérlés engedélyezve van egy tárfiókhoz, amíg a hierarchikus névtér (HNS) funkció be van kapcsolva.

Ha a HNS ki van kapcsolva, az Azure RBAC engedélyezési szabályai továbbra is érvényesek.

Mi a legjobb módszer az ACL-ek alkalmazására?

Mindig a Microsoft Entra biztonsági csoportokat használja hozzárendelt tagként egy ACL-bejegyzésben. Ellen kell állnia annak a lehetőségnek, hogy közvetlenül rendeljen hozzá egyéni felhasználókat vagy szolgáltatásneveket. A struktúra használatával anélkül adhat hozzá és távolíthat el felhasználókat vagy szolgáltatásneveket, hogy újra kellene alkalmaznia az ACL-eket a teljes címtárstruktúrában. Ehelyett egyszerűen hozzáadhat vagy eltávolíthat felhasználókat és szolgáltatásneveket a megfelelő Microsoft Entra biztonsági csoportból.

A csoportok beállításának számos különböző módja van. Tegyük fel például, hogy rendelkezik egy /LogData nevű könyvtárral, amely a kiszolgáló által létrehozott naplóadatokat tárolja. Az Azure Data Factory (ADF) betölti az adatokat ebbe a mappába. A szolgáltatásmérnöki csapat egyes felhasználói feltöltik a naplókat, és kezelik a mappa többi felhasználóját, a különböző Databricks-fürtök pedig az adott mappából származó naplókat elemzik.

A tevékenységek engedélyezéséhez létrehozhat egy LogsWriter csoportot és egy LogsReader csoportot. Ezután a következőképpen rendelhet hozzá engedélyeket:

• Adja hozzá a LogsWriter csoportot a /LogData könyvtár ACL-éhez engedélyekkelrwx.
• Adja hozzá a LogsReader csoportot a /LogData könyvtár ACL-éhez engedélyekkelr-x.
• Adja hozzá az ADF szolgáltatásnév-objektumát vagy felügyeltszolgáltatás-identitását (MSI) a LogsWriters csoporthoz.
• Felhasználók hozzáadása a szolgáltatásmérnöki csapathoz.LogsWriter
• Adja hozzá a Databricks szolgáltatásnév-objektumát vagy MSI-ját a LogsReader csoporthoz.

Ha a szolgáltatásmérnöki csapat egy felhasználója elhagyja a vállalatot, egyszerűen eltávolíthatja őket a LogsWriter csoportból. Ha nem adta hozzá a felhasználót egy csoporthoz, hanem egy dedikált ACL-bejegyzést adott hozzá a felhasználóhoz, el kell távolítania az ACL-bejegyzést a /LogData könyvtárból. A bejegyzést a /LogData könyvtár teljes könyvtárhierarchiájában lévő összes alkönyvtárból és fájlból el kell távolítania.

Csoport létrehozásához és tagok hozzáadásához lásd : Alapszintű csoport létrehozása és tagok hozzáadása a Microsoft Entra-azonosítóval.

Fontos

Az Azure Data Lake Storage Gen2 a Microsoft Entra azonosítójától függ a biztonsági csoportok kezeléséhez. A Microsoft Entra ID azt javasolja, hogy egy adott biztonsági tag csoporttagsága 200-nál kevesebbre legyen korlátozva. Ez a javaslat a JSON webes jogkivonatok (JWT) korlátozásának köszönhető, amelyek a Microsoft Entra-alkalmazásokban biztosítják a biztonsági tagok csoporttagsági adatait. A korlát túllépése a Data Lake Storage Gen2 váratlan teljesítményproblémáihoz vezethet. További információ: Csoportjogcímek konfigurálása alkalmazásokhoz a Microsoft Entra ID használatával.

Hogyan történik az Azure RBAC- és ACL-engedélyek kiértékelése?

Ha szeretné megtudni, hogy a rendszer hogyan értékeli ki együtt az Azure RBAC-ket és az ACL-eket a tárfiók-erőforrások engedélyezési döntéseinek meghozatalához, tekintse meg az engedélyek kiértékelésének módját.

Mik az Azure-szerepkör-hozzárendelések és az ACL-bejegyzések korlátai?

Az alábbi táblázat összefoglalja azokat a korlátokat, amelyeket figyelembe kell venni az Azure RBAC használata során a "durva szemcsés" engedélyek (tárfiókokra vagy tárolókra vonatkozó engedélyek) kezeléséhez, valamint ACL-ek használatával a "részletes" engedélyek (fájlokra és könyvtárakra vonatkozó engedélyek) kezeléséhez. Biztonsági csoportok használata ACL hozzárendelésekhez. A csoportok használatával kisebb a valószínűsége, hogy túllépi az előfizetésenkénti szerepkör-kijelölések maximális számát és a fájlonként vagy könyvtáranként engedélyezett ACL-bejegyzések maximális számát.

Mechanizmus	Hatókör	Korlátok	Támogatott engedélyszint
Azure RBAC-vel	Tárfiókok, tárolók. Erőforrásközi Azure-szerepkör-hozzárendelések előfizetés vagy erőforráscsoport szintjén.	4000 Azure-szerepkör-hozzárendelés egy előfizetésben	Azure-szerepkörök (beépített vagy egyéni)
ACL	Könyvtár, fájl	Fájlonként és könyvtáronként 32 ACL-bejegyzés (gyakorlatilag 28 ACL-bejegyzés). A hozzáférési és az alapértelmezett ACL-ekre külön 32 ACL-bejegyzéses korlát vonatkozik.	ACL-engedély

Támogatja a Data Lake Storage Gen2 az Azure RBAC öröklését?

Az Azure-szerepkör-hozzárendelések öröklődnek. A hozzárendelések az előfizetés, az erőforráscsoport és a tárfiók erőforrásaitól a tárolóerőforrásig haladnak.

Támogatja a Data Lake Storage Gen2 az ACL-ek öröklését?

Az alapértelmezett ACL-ek segítségével beállíthatja a szülőkönyvtárban létrehozott új gyermek alkönyvtárak és fájlok ACL-jeit. A meglévő gyermekelemek ACL-jeinek frissítéséhez rekurzív módon kell hozzáadnia, frissítenie vagy eltávolítania az ACL-eket a kívánt címtárhierarchiához. Útmutatásért tekintse meg a cikk ACL-ek beállítását ismertető szakaszát.

Mely engedélyek szükségesek a címtárak és azok tartalmának rekurzív törléséhez?

• A hívó "szuperfelhasználói" engedélyekkel rendelkezik,

Vagy

• A szülőkönyvtárnak írási és végrehajtási engedélyekkel kell rendelkeznie.
• A törölni kívánt könyvtárhoz és azon belül minden könyvtárhoz olvasási és írási és végrehajtási engedélyek szükségesek.

Feljegyzés

A könyvtárakban lévő fájlok törléséhez nincs szükség írási engedélyekre. A "/" gyökérkönyvtár sem törölhető.

Ki a fájl vagy könyvtár tulajdonosa?

A fájl vagy könyvtár létrehozója lesz a tulajdonos. A gyökérkönyvtár esetében ez a tárolót létrehozó felhasználó identitása.

Melyik csoport van beállítva egy fájl vagy könyvtár tulajdonoscsoportjaként a létrehozáskor?

A tulajdonoscsoportot a rendszer annak a szülőkönyvtárnak a tulajdonoscsoportjából másolja, amely alatt az új fájl vagy könyvtár létrejön.

Egy fájl tulajdonosa vagyok, de nem rendelkezem a szükséges RWX-engedélyekkel. Mi a teendő?

A tulajdonos módosíthatja a fájlhoz tartozó engedélyeket, így bármilyen szükséges RWX-engedélyt megadhat saját magának.

Miért látom néha a GRAFIKUS TARTOMÁNYVEZÉRLŐ-ket az ACL-ben?

A GUID akkor jelenik meg, ha a bejegyzés egy felhasználót jelöl, és a felhasználó már nem létezik a Microsoft Entrában. Ez általában akkor fordul elő, ha a felhasználó elhagyta a vállalatot, vagy ha a fiókját törölték a Microsoft Entra-azonosítóból. Emellett a szolgáltatásnevek és biztonsági csoportok nem rendelkeznek egyszerű felhasználónévvel (UPN) az azonosításukhoz, ezért azokat az OID attribútum (guid) képviseli. Az ACL-ek törléséhez törölje manuálisan ezeket a GUID-bejegyzéseket.

Hogyan állítom be az ACL-eket helyesen egy szolgáltatásnévhez?

Amikor ACL-eket definiál a szolgáltatásnevekhez, fontos, hogy a szolgáltatásnév objektumazonosítóját (OID) használja a létrehozott alkalmazásregisztrációhoz. Fontos megjegyezni, hogy a regisztrált alkalmazások külön szolgáltatásnévvel rendelkeznek az adott Microsoft Entra-bérlőben. A regisztrált alkalmazások rendelkeznek egy OID-tal, amely látható az Azure Portalon, de a szolgáltatásnév egy másik (eltérő) OID-tal rendelkezik. Cikk Az alkalmazásregisztrációnak megfelelő szolgáltatásnév OID-jának lekéréséhez használhatja a az ad sp show parancsot. Paraméterként adja meg az alkalmazásazonosítót. Íme egy példa a szolgáltatásnév OID-jának beszerzésére, amely megfelel egy alkalmazásregisztrációnak az alkalmazásazonosítóval = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Az Azure CLI-ben futtassa a következő parancsot:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

Ekkor megjelenik az OID.

Ha a szolgáltatásnévhez megfelelő OID-tal rendelkezik, lépjen a Storage Explorer Manage Access (Hozzáférés kezelése) lapra az OID hozzáadásához és az OID megfelelő engedélyeinek hozzárendeléséhez. Győződjön meg arról, hogy a Mentés lehetőséget választja

Beállíthatom egy tároló ACL-ét?

Szám A tárolók nem rendelkeznek ACL-sel. Azonban beállíthatja a tároló gyökérkönyvtárának ACL-jét. Minden tároló rendelkezik gyökérkönyvtárral, és ugyanazzal a névvel rendelkezik, mint a tároló. Ha például a tároló neve el van nevezve my-container, akkor a gyökérkönyvtár neve my-container/.

Az Azure Storage REST API tartalmaz egy Set Container ACL nevű műveletet, de ez a művelet nem használható tároló vagy tároló gyökérkönyvtárának ACL-jének beállítására. Ehelyett ez a művelet azt jelzi, hogy a tárolóban lévő blobok névtelen kéréssel érhetők-e el. Javasoljuk, hogy a blobadatokra vonatkozó összes kéréshez megkövetelje az engedélyezést. További információ : Áttekintés: A blobadatok névtelen olvasási hozzáférésének szervizelése.

Hol tudhatok meg többet a POSIX hozzáférés-vezérlési modellről?

• POSIX hozzáférés-vezérlési listák Linux rendszeren
• HDFS-engedélyek útmutatója
• POSIX – gyakori kérdések
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• POSIX ACL Ubuntu rendszeren

Lásd még

• Hozzáférés-vezérlési modell az Azure Data Lake Storage Gen2-ben