Sdílet prostřednictvím

Seznamy řízení přístupu (seznamy ACL) v Azure Data Lake Storage Gen2

  • Článek

Azure Data Lake Storage Gen2 implementuje model řízení přístupu, který podporuje řízení přístupu na základě role v Azure (Azure RBAC) i seznamy řízení přístupu podobné poSIX (ACL). Tento článek popisuje seznamy řízení přístupu v Data Lake Storage Gen2. Další informace o tom, jak začlenit Azure RBAC do seznamů ACL a jak je systém vyhodnocuje za účelem rozhodování o autorizaci, najdete v tématu Model řízení přístupu ve službě Azure Data Lake Storage Gen2.

Seznamy ACL

Objekt zabezpečení můžete přidružit k úrovni přístupu pro soubory a adresáře. Každé přidružení je zachyceno jako položka v seznamu řízení přístupu (ACL). Každý soubor a adresář v účtu úložiště má seznam řízení přístupu. Když se objekt zabezpečení pokusí o operaci v souboru nebo adresáři, zkontroluje seznam ACL, jestli má tento objekt zabezpečení (uživatel, skupina, instanční objekt nebo spravovaná identita) správnou úroveň oprávnění k provedení operace.

Poznámka:

Seznamy ACL se vztahují pouze na objekty zabezpečení ve stejném tenantovi a nevztahují se na uživatele, kteří používají ověřování pomocí sdíleného klíče nebo sdíleného přístupového podpisu (SAS). Důvodem je to, že k volajícímu není přidružena žádná identita, a proto nelze provést autorizaci na základě oprávnění objektu zabezpečení.

Jak nastavit seznamy ACL

Nastavení oprávnění na úrovni souborů a adresářů najdete v některém z následujících článků:

Prostředí Článek
Azure Storage Explorer Použití Průzkumník služby Azure Storage ke správě seznamů ACL ve službě Azure Data Lake Storage Gen2
portál Azure Použití webu Azure Portal ke správě seznamů ACL ve službě Azure Data Lake Storage Gen2
.NET Použití .NET ke správě seznamů ACL v Azure Data Lake Storage Gen2
Java Použití Javy ke správě seznamů ACL ve službě Azure Data Lake Storage Gen2
Python Použití Pythonu ke správě seznamů ACL v Azure Data Lake Storage Gen2
JavaScript (Node.js) Použití sady JavaScript SDK v Node.js ke správě seznamů ACL ve službě Azure Data Lake Storage Gen2
PowerShell Použití PowerShellu ke správě seznamů ACL v Azure Data Lake Storage Gen2
Azure CLI Použití Azure CLI ke správě seznamů ACL ve službě Azure Data Lake Storage Gen2
REST API Cesta – aktualizace

Důležité

Pokud je objekt zabezpečení instančním objektem, je důležité použít ID objektu instančního objektu, nikoli ID objektu související registrace aplikace. Pokud chcete získat ID objektu instančního objektu, otevřete Azure CLI a pak použijte tento příkaz: az ad sp show --id <Your App ID> --query objectId. Nezapomeňte zástupný symbol nahradit <Your App ID> ID aplikace registrace vaší aplikace. Instanční objekt se považuje za pojmenovaného uživatele. Toto ID přidáte do seznamu ACL stejně jako jakýkoli pojmenovaný uživatel. Pojmenovaní uživatelé jsou popsáni dále v tomto článku.

Typy seznamů ACL

Existují dva druhy seznamů řízení přístupu: přístupové seznamy ACL a výchozí seznamy ACL.

Přístup k seznamům ACL řídí přístup k objektu. Soubory i adresáře mají přístupové seznamy ACL.

Výchozí seznamy ACL jsou šablony seznamů ACL přidružených k adresáři, které určují přístupové seznamy ACL pro všechny podřízené položky vytvořené v daném adresáři. Soubory nemají výchozí seznamy ACL.

Oba přístupové seznamy ACL i výchozí seznamy ACL mají stejnou strukturu.

Poznámka:

Změna výchozího seznamu ACL u nadřazené položky nemá vliv na přístupový seznam ACL ani na výchozí seznam ACL u podřízených položek, které již existují.

Úrovně oprávnění

Oprávnění k adresářům a souborům v kontejneru jsou Read, Write a Execute a lze je používat u souborů a adresářů, jak je znázorněno v následující tabulce:

Soubor Adresář
Číst (R) Může číst obsah souboru K výpisu obsahu adresáře vyžaduje čtení a spuštění .
Zapisovat (W) Může zapisovat do souboru nebo k němu připojovat data K vytvoření podřízených položek v adresáři vyžaduje zápis a spuštění .
Provést (X) Neznamená nic v kontextu Data Lake Storage Gen2. Vyžadováno pro procházení podřízených položek adresáře

Poznámka:

Pokud udělujete oprávnění jenom pomocí seznamů ACL (bez Azure RBAC), pak pokud chcete objektu zabezpečení udělit přístup ke čtení nebo zápisu k souboru, budete muset objektu zabezpečení udělit oprávnění Ke spuštění objektu zabezpečení kořenové složce kontejneru a ke každé složce v hierarchii složek, které vedou k souboru.

Zkrácené verze oprávnění

Zápis RWX se používá k označení Číst + Zapisovat + Provést. Používá se i zhuštěná číselná verze, která využívá nahrazení Číst = 4, Zapisovat = 2 a Provést = 1, přičemž oprávnění je vyjádřeno součtem. Dále je uvedeno několik příkladů.

Číselný tvar Krátký tvar Význam
7 RWX Číst + Zapisovat + Provést
5 R-X Číst + Provést
4 R-- Čteno
0 --- Žádná oprávnění

Dědičnost oprávnění

V modelu stylu POSIX používaném službou Data Lake Storage Gen2 jsou oprávnění pro položku uložena přímo s příslušnou položkou. Jinými slovy, oprávnění pro položku nelze dědit z nadřazených položek, pokud jsou oprávnění nastavena až po vytvoření podřízené položky. Oprávnění se dědí pouze v případě, že výchozí oprávnění byla nastavena u nadřazených položek před vytvořením podřízených položek.

V následující tabulce jsou uvedeny položky seznamu ACL potřebné k tomu, aby objekt zabezpečení mohl provádět operace uvedené ve sloupci Operace .

Tato tabulka zobrazuje sloupec, který představuje každou úroveň fiktivní hierarchie adresářů. Existuje sloupec pro kořenový adresář kontejneru (/), podadresář s názvem Oregon, podadresář adresáře Oregon s názvem Portland a textový soubor v adresáři Portland s názvem Data.txt.

Důležité

V této tabulce se předpokládá, že používáte pouze seznamy ACL bez přiřazení rolí Azure. Pokud chcete zobrazit podobnou tabulku, která kombinuje Azure RBAC s seznamy ACL, přečtěte si téma Tabulka oprávnění: Kombinování azure RBAC, ABAC a seznamů ACL.

Operace / Oregon/ Portland/ Data.txt
Čtení Data.txt --X --X --X R--
Připojit k Data.txt --X --X --X RW-
Odstranění Data.txt --X --X -WX ---
Odstranit /Oregon/ -WX RWX RWX ---
Odstranit /Oregon/Portland/ --X -WX RWX ---
Vytvoření Data.txt --X --X -WX ---
Seznam/ R-X --- --- ---
Seznam /Oregon/ --X R-X --- ---
Seznam /Oregon/Portland/ --X --X R-X ---

Odstraňování souborů a adresářů

Jak je znázorněno v předchozí tabulce, oprávnění k zápisu v souboru nejsou nutná k jeho odstranění, pokud jsou správně nastavena oprávnění k adresáři. Pokud ale chcete odstranit adresář a veškerý jeho obsah, musí mít nadřazený adresář oprávnění k zápisu a provedení. Adresář, který se má odstranit, a každý adresář v něm vyžaduje oprávnění ke čtení + zápisu a spuštění.

Poznámka:

Kořenový adresář /nelze nikdy odstranit.

Uživatelé a identity

Každý soubor a adresář mají jedinečná oprávnění pro tyto identity:

  • Vlastnící uživatel
  • Vlastnící skupina
  • Pojmenovaní uživatelé
  • Pojmenované skupiny
  • Pojmenované instanční objekty
  • Pojmenované spravované identity
  • Všichni ostatní uživatelé

Identity uživatelů a skupin jsou identity Microsoft Entra identity. Pokud tedy není uvedeno jinak, může uživatel v kontextu Data Lake Storage Gen2 odkazovat na uživatele Microsoft Entra, instanční objekt, spravovanou identitu nebo skupinu zabezpečení.

Superuživatel

Superuživatel má nejvíce práv všech uživatelů. Superuživatel:

  • Má oprávnění RWX ke všem souborům a složkám.

  • Může měnit oprávnění pro kterýkoli soubor nebo složku.

  • Může měnit vlastnícího uživatele nebo vlastnící skupinu pro kterýkoli soubor nebo složku.

Pokud je kontejner, soubor nebo adresář vytvořen pomocí sdíleného klíče, SAS účtu nebo SAS služby, pak vlastník a vlastnící skupina jsou nastaveny na $superuser.

Vlastnící uživatel

Uživatel, který položku vytvořil, je automaticky jejím vlastníkem. Vlastnící uživatel může:

  • Měnit oprávnění souboru, jehož vlastníkem je.
  • Měnit vlastnící skupinu pro vlastněný soubor, pokud je vlastnící uživatel členem cílové skupiny.

Poznámka:

Vlastnící uživatel nemůže změnit vlastnícího uživatele souboru nebo adresáře. Vlastníka souboru nebo adresáře můžou změnit jenom superuživatelé.

Vlastnící skupina

V seznamech ACL POSIX je každý uživatel přidružený k primární skupině. Uživatel "Alice" může například patřit do skupiny "finance". Alice může patřit také do více skupin, ale jedna skupina je vždy určena jako jejich primární skupina. Když Alice v POSIX vytvoří soubor, vlastnící skupina tohoto souboru je nastavena na její primární skupinu, což v tomto případě je "finance". Vlastnící skupina se jinak chová podobně jako přiřazená oprávnění pro ostatní uživatele nebo skupiny.

Přiřazení vlastnící skupiny pro nový soubor nebo adresář

  • Případ 1: Kořenový adresář /. Tento adresář se vytvoří při vytvoření kontejneru Data Lake Storage Gen2. V tomto případě je vlastnící skupina nastavena na uživatele, který kontejner vytvořil, pokud byl proveden pomocí OAuth. Pokud se kontejner vytvoří pomocí sdíleného klíče, SAS účtu nebo sdíleného přístupového podpisu služby, nastaví $superuserse vlastník a vlastnící skupina .
  • Případ 2 (každý druhý): Při vytvoření nové položky se vlastnící skupina zkopíruje z nadřazeného adresáře.

Změna vlastnící skupiny

Vlastnící skupinu smí změnit:

  • Všichni superuživatelé.
  • Vlastnící uživatel, pokud je také členem cílové skupiny.

Poznámka:

Vlastnící skupina nemůže změnit seznamy ACL souboru nebo adresáře. Zatímco vlastnící skupina je nastavena na uživatele, který účet vytvořil v případě kořenového adresáře, Případ 1 výše, jeden uživatelský účet není platný pro poskytnutí oprávnění prostřednictvím vlastnící skupiny. Toto oprávnění můžete přiřadit platné skupině uživatelů, pokud nějaká existuje.

Jak se vyhodnocují oprávnění

Identity se vyhodnocují v následujícím pořadí:

  1. Superuživatel
  2. Vlastnící uživatel
  3. Pojmenovaný uživatel, instanční objekt nebo spravovaná identita
  4. Vlastnící skupina nebo pojmenovaná skupina
  5. Všichni ostatní uživatelé

Pokud se na objekt zabezpečení vztahuje více než jedna z těchto identit, je udělena úroveň oprávnění přidružená k první identitě. Pokud je například objekt zabezpečení vlastníkem i pojmenovaným uživatelem, použije se úroveň oprávnění přidružená k vlastnícího uživatele.

Pojmenované skupiny jsou všechny považované dohromady. Pokud je objekt zabezpečení členem více pojmenovaných skupin, systém vyhodnocuje každou skupinu, dokud nebude uděleno požadované oprávnění. Pokud žádná z pojmenovaných skupin neposkytuje požadované oprávnění, systém se přesune k vyhodnocení žádosti proti oprávnění přidruženému ke všem ostatním uživatelům.

Následující pseudokód představuje algoritmus kontroly přístupu pro účty úložiště. Tento algoritmus ukazuje pořadí, ve kterém se identity vyhodnocují.

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)

Maska

Jak je znázorněno v algoritmu kontroly přístupu, maska omezuje přístup pro pojmenované uživatele, vlastnící skupinu a pojmenované skupiny.

U nového kontejneru Data Lake Storage Gen2 je maska pro přístupový seznam ACL kořenového adresáře ("/") výchozí hodnota 750 pro adresáře a 640 souborů. Následující tabulka ukazuje symbolickou notaci těchto úrovní oprávnění.

Entity Directories Soubory
Vlastnící uživatel rwx rw-
Vlastnící skupina r-x r--
Jiný důvod --- ---

Soubory nepřijme bit X, protože je pro soubory v systému jen pro ukládání irelevantní.

Masku lze zadat pro jednotlivá volání. To umožňuje různým systémům, jako jsou clustery, mít různé efektivní masky pro své operace se soubory. Pokud je pro daný požadavek zadána maska, zcela přepíše výchozí masku.

Bit sticky

Rychlý bit je pokročilejší funkce kontejneru POSIX. V kontextu Data Lake Storage Gen2 je nepravděpodobné, že by se bit sticky potřeboval. Pokud je v adresáři povolený rychlý bit, může podřízená položka být odstraněna nebo přejmenována pouze vlastníkem podřízené položky, vlastníkem adresáře nebo superuživatelem ($superuser).

Bit sticky se na webu Azure Portal nezobrazuje. Další informace o rychlém bitu a o tom, jak ho nastavit, najdete v tématu Co je rychlý bit Data Lake Storage Gen2?

Výchozí oprávnění pro nové soubory a adresáře

Při vytvoření nového souboru nebo adresáře v rámci existujícího adresáře se podle výchozího seznamu ACL pro nadřazený adresář určí:

  • Výchozí seznam ACL a přístupový seznam ACL podřízeného adresáře.
  • Přístupový seznam ACL podřízeného souboru (pro soubory není definován výchozí seznam ACL).

umask

Při vytváření výchozího seznamu ACL se pro přístupový seznam ACL použije umask, aby určil počáteční oprávnění výchozího seznamu ACL. Pokud je v nadřazeném adresáři definován výchozí seznam ACL, umask se efektivně ignoruje a výchozí seznam ACL nadřazeného adresáře se použije k definování těchto počátečních hodnot.

umask je 9bitová hodnota nadřazených adresářů, která obsahuje hodnotu RWX pro vlastnícího uživatele, vlastnící skupinu a další.

Umask pro Azure Data Lake Storage Gen2 je konstantní hodnota, která je nastavená na 007. Tato hodnota se překládá na:

Komponenta umask Číselný tvar Krátký tvar Význam
umask.owning_user 0 --- Pro vlastnícího uživatele zkopírujte přístupový seznam ACL nadřazeného objektu do výchozího seznamu ACL podřízeného uživatele.
umask.owning_group 0 --- Pro vlastnící skupinu zkopírujte přístupový seznam ACL nadřazeného objektu do výchozího seznamu ACL podřízené položky.
umask.other 7 RWX U ostatních odeberte všechna oprávnění v přístupovém seznamu ACL podřízeného uživatele.

Často kladené dotazy

Je třeba povolit podporu pro seznamy ACL?

Ne. Řízení přístupu prostřednictvím seznamů ACL je pro účet úložiště povolené, pokud je zapnutá funkce Hierarchický obor názvů (HNS).

Pokud je HNS vypnuté, platí i autorizační pravidla Azure RBAC.

Jaký je nejlepší způsob použití seznamů ACL?

Skupiny zabezpečení Microsoft Entra vždy používejte jako přiřazený objekt zabezpečení v položce seznamu ACL. Odolejte pokušení přímo přiřazovat jednotlivé uživatele nebo instanční objekty. Pomocí této struktury můžete přidávat a odebírat uživatele nebo instanční objekty bez nutnosti znovu použít seznamy ACL pro celou adresářovou strukturu. Místo toho můžete přidat nebo odebrat uživatele a instanční objekty z příslušné skupiny zabezpečení Microsoft Entra.

Existuje mnoho různých způsobů, jak nastavit skupiny. Představte si například, že máte adresář s názvem /LogData , který obsahuje data protokolu generovaná vaším serverem. Azure Data Factory (ADF) ingestuje data do této složky. Konkrétní uživatelé z technického týmu služeb budou nahrávat protokoly a spravovat ostatní uživatele této složky a různé clustery Databricks budou analyzovat protokoly z této složky.

Pokud chcete tyto aktivity povolit, můžete vytvořit LogsWriter skupinu a LogsReader skupinu. Potom můžete přiřadit oprávnění následujícím způsobem:

  • LogsWriter Přidejte skupinu do seznamu ACL adresáře /LogData s oprávněnímirwx.
  • LogsReader Přidejte skupinu do seznamu ACL adresáře /LogData s oprávněnímir-x.
  • Přidejte objekt instančního objektu nebo identitu spravované služby (MSI) pro ADF do LogsWriters skupiny.
  • Přidejte do skupiny uživatele v technickém LogsWriter týmu služeb.
  • Přidejte objekt instančního objektu nebo MSI pro Databricks do LogsReader skupiny.

Pokud uživatel v technickém týmu služeb opustí společnost, mohli byste ho LogsWriter ze skupiny odebrat. Pokud jste tohoto uživatele nepřidali do skupiny, ale místo toho jste pro tohoto uživatele přidali vyhrazenou položku seznamu ACL, museli byste tuto položku seznamu ACL odebrat z adresáře /LogData . Je také nutné odebrat položku ze všech podadresářů a souborů v celé adresářové hierarchii adresáře adresáře /LogData .

Pokud chcete vytvořit skupinu a přidat členy, přečtěte si téma Vytvoření základní skupiny a přidání členů pomocí ID Microsoft Entra.

Důležité

Azure Data Lake Storage Gen2 závisí na ID Microsoft Entra pro správu skupin zabezpečení. Microsoft Entra ID doporučuje omezit členství ve skupinách pro daný objekt zabezpečení na méně než 200. Toto doporučení je způsobeno omezením webových tokenů JSON (JWT), které v aplikacích Microsoft Entra poskytují informace o členství ve skupinách instančního objektu zabezpečení. Překročení tohoto limitu může vést k neočekávaným problémům s výkonem data Lake Storage Gen2. Další informace najdete v tématu Konfigurace deklarací identity skupin pro aplikace pomocí ID Microsoft Entra.

Jak se vyhodnocují oprávnění Azure RBAC a ACL?

Informace o tom, jak systém vyhodnocuje azure RBAC a seznamy ACL společně za účelem rozhodování o autorizaci prostředků účtu úložiště, najdete v tématu Jak se vyhodnocují oprávnění.

Jaká jsou omezení pro přiřazení rolí Azure a položky seznamu ACL?

Následující tabulka obsahuje souhrnné zobrazení limitů, které je potřeba zvážit při použití Azure RBAC ke správě "hrubě odstupňovaných" oprávnění (oprávnění, která platí pro účty úložiště nebo kontejnery) a použití seznamů ACL ke správě "jemně odstupňovaných" oprávnění (oprávnění, která platí pro soubory a adresáře). K přiřazení seznamu ACL použijte skupiny zabezpečení. Při použití skupin je méně pravděpodobné, že byste překročili maximální počet přiřazených rolí pro každé předplatné nebo maximální počet položek ACL pro každý soubor nebo adresář.

Mechanismus Obor Omezení Podporovaná úroveň oprávnění
Azure RBAC Účty úložiště, kontejnery.
Přiřazení rolí Azure mezi prostředky na úrovni předplatného nebo skupiny prostředků		 Přiřazení rolí Azure v předplatném 4000 Role Azure (předdefinované nebo vlastní)
ACL Adresář, soubor 32 položek seznamu ACL (efektivně 28 položek seznamu ACL) na soubor a na adresář. Přístupový seznam ACL a výchozí seznamy ACL mají vlastní limit 32 položek. Oprávnění seznamu ACL

Podporuje Data Lake Storage Gen2 dědičnost Azure RBAC?

Přiřazení rolí Azure dědí. Přiřazení proudí z prostředků předplatného, skupiny prostředků a prostředků účtu úložiště do prostředku kontejneru.

Podporuje Data Lake Storage Gen2 dědičnost seznamů ACL?

Výchozí seznamy ACL lze použít k nastavení seznamů ACL pro nové podřízené podadresáře a soubory vytvořené v nadřazeném adresáři. Pokud chcete aktualizovat seznamy ACL pro existující podřízené položky, budete muset přidat, aktualizovat nebo odebrat seznamy ACL rekurzivně pro požadovanou hierarchii adresářů. Pokyny najdete v části Jak nastavit seznamy ACL tohoto článku.

Která oprávnění se vyžadují k rekurzivnímu odstranění adresáře a jeho obsahu?

  • Volající má oprávnění superuživatele.

Nebo

  • Nadřazený adresář musí mít oprávnění k zápisu a provedení.
  • Adresář, který se má odstranit, a každý adresář v něm vyžaduje oprávnění ke čtení + zápisu a spuštění.

Poznámka:

K odstranění souborů v adresářích nepotřebujete oprávnění k zápisu. Kořenový adresář /se také nedá odstranit.

Kdo je vlastníkem souboru nebo adresáře?

Tvůrce souboru nebo adresáře se stane vlastníkem. V případě kořenového adresáře se jedná o identitu uživatele, který kontejner vytvořil.

Která skupina se při vytváření nastaví jako vlastnící skupina souboru nebo adresáře?

Vlastnící skupina se zkopíruje z vlastnící skupiny nadřazeného adresáře, pod kterým se vytvoří nový soubor nebo adresář.

Jsem vlastníkem souboru, ale nemám oprávnění RWX, která potřebuji. Co mám dělat?

Vlastnící uživatel může změnit oprávnění k souboru a sám si udělit veškerá potřebná oprávnění RWX.

Proč se někdy v seznamech ACL zobrazují identifikátory GUID?

Identifikátor GUID se zobrazí, pokud položka představuje uživatele a tento uživatel už v Microsoft Entra neexistuje. K tomu obvykle dochází v případě, že uživatel opustil společnost nebo pokud byl jeho účet odstraněn v Microsoft Entra ID. Instanční objekty a skupiny zabezpečení navíc nemají hlavní název uživatele (UPN) k jejich identifikaci, a proto jsou reprezentovány atributem OID (guid). Pokud chcete seznamy ACL vyčistit, odstraňte tyto položky GUID ručně.

Jak správně nastavím seznamy ACL pro instanční objekt?

Když definujete seznamy ACL pro instanční objekty, je důležité použít ID objektu (OID) instančního objektu pro registraci aplikace, kterou jste vytvořili. Je důležité si uvědomit, že registrované aplikace mají v konkrétním tenantovi Microsoft Entra samostatný instanční objekt. Registrované aplikace mají identifikátor OID, který je viditelný na webu Azure Portal, ale instanční objekt má jiný (jiný) identifikátor OID. Článek Získání identifikátoru OID pro instanční objekt, který odpovídá registraci aplikace, můžete použít az ad sp show příkaz. Jako parametr zadejte ID aplikace. Zde je příklad získání identifikátoru OID pro instanční objekt odpovídající registraci aplikace s ID aplikace = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. V rozhraní příkazového řádku Azure spusťte následující příkaz:

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

Zobrazí se identifikátor OID.

Pokud máte správný identifikátor OID instančního objektu, přejděte na Průzkumník služby Storage Spravovat přístupovou stránku a přidejte identifikátor OID a přiřaďte příslušná oprávnění pro identifikátor OID. Ujistěte se, že jste vybrali Uložit.

Můžu nastavit seznam ACL kontejneru?

Ne. Kontejner nemá seznam ACL. Můžete ale nastavit seznam ACL kořenového adresáře kontejneru. Každý kontejner má kořenový adresář a sdílí stejný název jako kontejner. Pokud je například kontejner pojmenován my-container, kořenový adresář je pojmenován my-container/.

Rozhraní REST API služby Azure Storage obsahuje operaci s názvem Set Container ACL, ale tato operace se nedá použít k nastavení seznamu ACL kontejneru nebo kořenového adresáře kontejneru. Místo toho se tato operace používá k označení, jestli objekty blob v kontejneru mohou být přístupné pomocí anonymního požadavku. Doporučujeme vyžadovat autorizaci pro všechny požadavky na data objektů blob. Další informace najdete v tématu Přehled: Náprava anonymního přístupu pro čtení pro data objektů blob.

Kde najdu další informace o modelu řízení přístupu POSIX?

Viz také