Řízení přístupu ve službě Azure Data Lake Storage Gen1

Azure Data Lake Storage Gen1 implementuje model řízení přístupu odvozený z HDFS, který je zase odvozený z modelu řízení přístupu POSIX. Tento článek shrnuje základy modelu řízení přístupu pro Data Lake Storage Gen1.

Seznamy řízení přístupu k souborům a složkám

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

• Přístupové seznamy ACL: Řídí přístup k objektu. Přístupové seznamy ACL jsou definovány pro soubory i složky.

• Výchozí seznamy ACL: „Šablona“ seznamů ACL přidružených ke složce, které určují přístupové seznamy ACL pro všechny podřízené položky vytvořené v rámci příslušné složky. Výchozí seznamy ACL nejsou definovány pro soubory.

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

Oprávnění

Pro objekt systému souborů jsou definována oprávnění Číst, Zapisovat a Provést a pro soubory a složky je lze používat podle následující tabulky:

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ů.

Oprávnění se nedědí

V modelu stylu POSIX, který používá Data Lake Storage Gen1, jsou oprávnění k položce uložená na samotné položce. Jinými slovy: oprávnění pro položku nelze zdědit z nadřazených položek.

Běžné scénáře týkající se oprávnění

Následuje několik běžných scénářů, které vám pomůžou pochopit, která oprávnění jsou potřebná k provádění určitých operací s Data Lake Storage Gen1 účtem.

Uživatelé a identity

Každý soubor a složka má samostatná oprávnění pro tyto identity:

• Vlastnící uživatel
• Vlastnící skupina
• Pojmenovaní uživatelé
• Pojmenované skupiny
• Všichni ostatní uživatelé

Identity uživatelů a skupin jsou Microsoft Entra identit. Pokud tedy není uvedeno jinak, může "uživatel" v kontextu Data Lake Storage Gen1 znamenat buď Microsoft Entra uživatele, nebo Microsoft Entra skupinu zabezpečení.

Superuživatel

Superuživatel má nejvíce práv ze všech uživatelů v účtu Data Lake Storage Gen1. 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.

Všichni uživatelé, kteří jsou součástí role Vlastníci účtu Data Lake Storage Gen1, jsou automaticky superuživateli.

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.

Vlastnící skupina

Pozadí

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

Vzhledem k tomu, že v Data Lake Storage Gen1 není k uživatelům přidružená žádná "primární skupina", vlastnící skupina se přiřadí následujícím způsobem.

Přiřazení vlastnící skupiny k novému souboru nebo složce

• Případ 1: Kořenová složka „/“. Tato složka se vytvoří při vytvoření účtu Data Lake Storage Gen1. V tomto případě je vlastnící skupina nastavená na úplně nulový identifikátor GUID. Tato hodnota nepovoluje žádný přístup. Jedná se o zástupný symbol, dokud není přiřazena skupina.
• Případ 2 (všechny ostatní případy): Při vytvoření nové položky se vlastnící skupina zkopíruje z nadřazené složky.

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.

Algoritmus kontroly přístupu

Následující pseudokód představuje algoritmus kontroly přístupu pro účty Data Lake Storage Gen1.

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 folder
  # Note: the "sticky bit" is not illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask IS NOT 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.permmissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
      member_count += 1
      perms | =  entry.permissions
  if (member_count>0) :
    return ((desired_perms & perms & mask ) == desired_perms)
 
  # 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.

Bit sticky

Bit sticky představuje pokročilejší funkci systému souborů POSIX. V kontextu Data Lake Storage Gen1 je nepravděpodobné, že bude bit sticky potřeba. Stručně řečeno, pokud je bit sticky ve složce povolený, podřízenou položku může odstranit nebo přejmenovat pouze vlastnící uživatel podřízené položky.

Bit sticky se na webu Azure Portal nezobrazuje.

Výchozí oprávnění pro nové soubory a složky

Při vytvoření nového souboru nebo složky v rámci existující složky se podle výchozího seznamu ACL pro nadřazenou složku určí:

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

umask

Při vytváření souboru nebo složky se umask používá ke změně nastavení výchozích seznamů ACL u podřízené položky. umask je 9bitová hodnota nadřazených složek, která obsahuje hodnotu RWX pro vlastnícího uživatele, vlastnící skupinu a další.

Umask pro Azure Data Lake Storage Gen1 je konstantní hodnota nastavená na 007. Tato hodnota se přeloží na

Hodnota umask používaná Azure Data Lake Storage Gen1 ve skutečnosti znamená, že hodnota pro jiné se u nových podřízených položek ve výchozím nastavení nikdy nepřenáší – bez ohledu na to, co označuje výchozí seznam ACL.

Následující pseudokód ukazuje, jak se umask použije při vytváření seznamů ACL pro podřízenou položku.

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

Běžné dotazy týkající se seznamů ACL v Data Lake Storage Gen1

Je třeba povolit podporu pro seznamy ACL?

No. Řízení přístupu prostřednictvím seznamů ACL je pro Data Lake Storage Gen1 účet vždy zapnuté.

Jaká oprávnění jsou vyžadována pro rekurzivní odstranění složky a jejího obsahu?

• Pro nadřazenou složku musí být nastavena oprávnění Zapisovat + Provést.
• Pro složku, která se má odstranit, a všechny složky, které obsahuje, se vyžadují oprávnění Číst + Zapisovat + Provést.

Kdo je vlastníkem souboru nebo složky?

Vlastníkem souboru nebo složky se stane příslušný tvůrce.

Jaká skupina je nastavena jako vlastnící skupina souboru nebo složky při vytvoření?

Vlastnící skupina se zkopíruje z vlastnící skupiny nadřazené složky, v rámci které se nový soubor nebo složka vytvoří.

Jsem vlastnícím uživatelem souboru, ale nemám potřebné oprávnění RWX. Co mám udě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.

Když se podívám na seznamy ACL na webu Azure Portal, zobrazí se uživatelská jména, ale přes rozhraní API se zobrazí identifikátory GUID. Proč?

Položky v seznamech ACL jsou uložené jako identifikátory GUID, které odpovídají uživatelům v Microsoft Entra ID. Rozhraní API vrací identifikátory GUID tak, jak jsou. Azure Portal se snaží zjednodušit práci se seznamy ACL tím, že překládá identifikátory GUID na popisné názvy, pokud je to možné.

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

Identifikátor GUID se zobrazí, když uživatel už v Microsoft Entra neexistuje. K tomu obvykle dochází, když uživatel opustil společnost nebo pokud byl jeho účet odstraněn v Microsoft Entra ID. Ujistěte se také, že pro nastavení seznamů ACL používáte správné ID (podrobnosti najdete níže).

Jaké ID mám při použití instančního objektu použít k nastavení seznamů ACL?

Na webu Azure Portal přejděte na Microsoft Entra ID –> Podnikové aplikace a vyberte svou aplikaci. Na kartě Přehled by se mělo zobrazit ID objektu, které by se mělo použít při přidávání seznamů ACL pro přístup k datům (a ne ID aplikace).

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

Ne, ale výchozí seznamy ACL je možné použít k nastavení seznamů ACL pro podřízené soubory a složku nově vytvořené v nadřazené složce.

Jaká jsou omezení položek seznamu ACL pro soubory a složky?

Pro každý soubor a adresář je možné nastavit 32 seznamů ACL. Přístupový seznam ACL a výchozí seznamy ACL mají vlastní limit 32 položek. Pokud je to možné, použijte pro přiřazení seznamu ACL skupiny zabezpečení. Při použití skupin je méně pravděpodobné, že překročíte maximální počet položek seznamu ACL na soubor nebo adresář.

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

• POSIX Access Control Lists on Linux (Seznamy řízení přístupu v rámci specifikace POSIX v Linuxu)
• Průvodce oprávněními HDFS
• Nejčastější dotazy týkající se specifikace POSIX
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• POSIX ACL na Ubuntu

Viz také

• Přehled Azure Data Lake Storage Gen1