Az Azure Data Lake Storage hozzáférés-vezérlési listái (ACL-ek)
Az Azure Data Lake Storage egy 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 hozzáférés-vezérlési listáit ismerteti. Az Azure RBAC ACL-ekkel való együttes beépítésének és a rendszer engedélyezési döntések meghozatalára történő kiértékelésének módjáról az Azure Data Lake Storage hozzáférés-vezérlési modelljében olvashat.
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. Az ACL-ek nem vonatkoznak a megosztott kulcsú hitelesítést használó felhasználókra, mert nincs identitás társítva a hívóhoz, ezért a rendszerbiztonsági tagok engedélyalapú hitelesítése nem hajtható végre. Ugyanez érvényes a közös hozzáférésű jogosultságkódok (SAS) jogkivonatokra is, kivéve, ha felhasználó által delegált SAS-jogkivonatot használnak. Ebben az esetben az Azure Storage POSIX ACL-ellenőrzést végez az objektumazonosítón, mielőtt engedélyezi a műveletet, amíg az opcionális suoid paramétert használja. További információ: Felhasználói delegálási SAS létrehozása.
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:
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 kontextusában | 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 által használt POSIX-stílusú modellben az elem engedélyeit maga az elem tárolja. 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 |
--- |
| Törlés /Oregon/Portland/ | --X |
-WX |
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, amíg a címtárengedélyek megfelelően vannak beállítva. 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 környezetében egy felhasználó hivatkozhat 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-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:
- Superuser felhasználó
- Tulajdonos felhasználó
- Elnevezett felhasználó, szolgáltatásnév vagy felügyelt identitás
- Tulajdonoscsoport vagy elnevezett csoport
- 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-tároló esetében a gyökérkönyvtár ("/") hozzáférési ACL-jének maszkja alapértelmezés szerint 750 a könyvtá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 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. Ha többet szeretne megtudni a ragadós bitről és annak beállításáról, olvassa el a Mi a ragadós bit Data Lake Storage?.
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 Azure Data Lake Storage umaskja egy 007-re beállított állandó érték. 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
LogsWritercsoportot a /LogData könyvtár ACL-éhez engedélyekkelrwx. - Adja hozzá a
LogsReadercsoportot 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
LogsWriterscsoporthoz. - 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
LogsReadercsoporthoz.
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 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 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 : ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0. 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