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

Azure Data Lake Storage Gen2 implementuje model řízení přístupu, který podporuje řízení přístupu na základě role azure (azure RBAC) a seznamy řízení přístupu (acl) typu POSIX. tento článek popisuje seznamy řízení přístupu v Data Lake Storage Gen2. další informace o tom, jak začlenit službu Azure RBAC společně s seznamy acl a jak ji systém vyhodnocuje k rozhodování o autorizaci, najdete v tématu model řízení přístupu v Azure Data Lake Storage Gen2.

O seznamech ACL

K souborům a adresářům můžete přidružit objekt zabezpečení s úrovní přístupu. 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í operaci u souboru nebo adresáře, zkontroluje seznam řízení přístupu (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.

Postup nastavení seznamů ACL

Chcete-li nastavit oprávnění na úrovni souborů a adresářů, přečtěte si některé z následujících článků:

Typy seznamů ACL

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

Přístup k ovládacímu prvku ACL přístup k objektu. Přístupové seznamy ACL mají přístup k souborům a adresářům.

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, které jsou vytvořeny v tomto adresáři. Soubory nemají výchozí seznamy ACL.

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

Úrovně oprávnění

Oprávnění k adresářům a souborům v kontejneru, jsou čtení, zápis a spouštění a lze je použít u souborů a adresářů, jak je znázorněno v následující tabulce:

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

Dědičnost oprávnění

v modelu stylu POSIX, který používá Data Lake Storage Gen2, jsou oprávnění pro položku uložena na samotné položce. Jinými slovy oprávnění pro položku nelze zdědit z nadřazených položek, pokud jsou oprávnění nastavena po vytvoření podřízené položky. Oprávnění jsou zděděna pouze v případě, že pro nadřazené položky byly nastaveny výchozí oprávnění před vytvořením podřízených položek.

Běžné scénáře související s oprávněními ACL

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

Tato tabulka obsahuje sloupec, který představuje jednotlivé úrovně fiktivní hierarchie adresářů. Existuje sloupec pro kořenový adresář kontejneru ( / ), podadresář s názvem Brno, podadresáře adresáře Brno s názvem Portland a textový soubor v adresáři Portland s názvem Data.txt.

Uživatelé a identity

Každý soubor a adresář má odlišná oprávnění pro tyto identity:

• Vlastnící uživatel
• Vlastnící skupina
• Pojmenovaní uživatelé
• Pojmenované skupiny
• Pojmenované objekty služby
• Pojmenované spravované identity
• Všichni ostatní uživatelé

Identity uživatelů a skupin jsou identity Azure Active Directory (Azure AD). takže pokud není uvedeno jinak, může uživatel v kontextu Data Lake Storage Gen2 odkazovat na uživatele služby Azure AD, instanční objekt, spravovanou identitu nebo skupinu zabezpečení.

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

V seznamech ACL pro 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 označena jako jejich primární skupina. Když Alice vytvoří soubor v rámci specifikace POSIX, bude jako vlastnící skupina tohoto souboru nastavena její primární skupina, což je v tomto případě skupina „finance“. Jinak se vlastnící skupina chová podobně jako přiřazená oprávnění pro jiné 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 takovém případě je vlastnící skupina nastavena na uživatele, který kontejner vytvořil, pokud byl proveden pomocí protokolu OAuth. Pokud se kontejner vytvoří pomocí sdíleného klíče, SAS účtu nebo SAS služby, nastaví se vlastník a vlastnící skupina na $superuser .
• Případ 2 (všechny ostatní případy): 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.

Jak se vyhodnocují oprávnění

Identity jsou vyhodnocovány v následujícím pořadí:

1. Superuživatele
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 více než jedna z těchto identit vztahuje na objekt zabezpečení, pak je udělená úroveň oprávnění přidružená k první identitě. Pokud je například objekt zabezpečení vlastnící uživatel i pojmenovaný uživatel, uplatní se úroveň oprávnění spojené s vlastníkem uživatele.

Následující pseudokódu představuje algoritmus kontroly přístupu pro účty úložiště. Tento algoritmus zobrazuje pořadí, ve kterém jsou identity vyhodnocovány.

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.

pro nový kontejner Data Lake Storage Gen2 je maska pro seznam ACL přístupu kořenového adresáře ("/") standardně 750 pro adresáře a 640 pro soubory. V následující tabulce jsou uvedeny symbolické zápisy těchto úrovní oprávnění.

Soubory neobdrží bit X, protože to není podstatné pro soubory v systému pouze v úložišti.

Maska může být určena pro volání podle volání. To umožňuje různým náročným systémům, jako jsou clustery, mít různé efektivní masky pro jejich souborové operace. Pokud je pro daný požadavek zadána maska, zcela přepíše výchozí masku.

Bit sticky

Bit Sticky je pokročilejší funkcí kontejneru POSIX. v kontextu Data Lake Storage Gen2 je nepravděpodobné, že bude potřeba nacházet v rychlém bitu. Pokud je v adresáři zapnutý bit s rychlým nastavením, může být podřízená položka pouze smazána nebo přejmenována vlastníkem uživatele podřízené položky.

Bit Sticky není zobrazený v Azure Portal.

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

Když se v existujícím adresáři vytvoří nový soubor nebo adresář, určí výchozí seznam ACL v nadřazeném adresáři:

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

umask

Při vytváření souboru nebo adresáře se umask používá k úpravě způsobu nastavení výchozích seznamů ACL pro podřízenou položku. umask je 9 bitová hodnota v nadřazených adresářích, které obsahují hodnotu RWX pro vlastnícího uživatele, vlastnící skupinu a Další.

umask pro Azure Data Lake Storage Gen2 konstantní hodnotu, která je nastavena na 007. Tato hodnota se převede na:

hodnota umask používaná Azure Data Lake Storage Gen2 efektivně znamená, že hodnota pro jinou se nikdy nepřenáší ve výchozím nastavení u nových podřízených objektů, pokud není výchozí seznam ACL definovaný v nadřazeném adresáři. V takovém případě je umask ve skutečnosti ignorováno a oprávnění definovaná výchozím seznamem ACL jsou použita pro podřízenou položku.

Následující pseudokódu ukazuje, jak je použit umask 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 )

Časté otázky

Je třeba povolit podporu pro seznamy ACL?

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

Pokud je funkce HNS vypnutá, pravidla autorizace služby Azure Azure RBAC se pořád použijí.

Jaký je nejlepší způsob, jak použít seznamy ACL?

V položce seznamu ACL vždy používejte skupiny zabezpečení Azure AD jako přiřazený objekt zabezpečení. Naodporujte příležitosti k přímému přiřazení jednotlivých uživatelů nebo instančních objektů. Pomocí této struktury budete moct přidávat a odebírat uživatele nebo instanční objekty, aniž byste museli 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í služby Azure AD.

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 týmu Service Engineering budou nahrávat protokoly a spravovat ostatní uživatele této složky a různé clustery datacihly budou analyzovat protokoly z této složky.

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

• Přidejte LogsWriter skupinu do seznamu ACL adresáře /LogData s rwx oprávněními.
• Přidejte LogsReader skupinu do seznamu ACL adresáře /LogData s r-x oprávněními.
• Přidejte instanční objekt služby nebo Identita spravované služby (MSI) pro ADF do LogsWriters skupiny.
• Přidejte uživatele v rámci technického týmu služeb do LogsWriter skupiny.
• Do skupiny přidejte instanční objekt služby nebo MSI pro datacihly LogsReader .

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

Chcete-li 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í Azure Active Directory.

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

Informace o tom, jak systém vyhodnocuje v Azure RBAC a seznamy ACL dohromady a provádí autorizační rozhodnutí pro prostředky úč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?

V následující tabulce najdete Přehled limitů, které je potřeba vzít v úvahu při používání Azure RBAC ke správě "hrubých" oprávnění (oprávnění, která se vztahují na účty úložiště nebo kontejnery) a používání seznamů ACL ke správě "jemně odstupňovaného" oprávnění (oprávnění, která se vztahují na soubory a adresáře). Použijte skupiny zabezpečení pro přiřazení seznamu ACL. Při použití skupin je méně pravděpodobnější, že bude překročen maximální počet přiřazení rolí na předplatné a maximální počet položek seznamu ACL na soubor nebo adresář.

podporuje Data Lake Storage Gen2 dědění Azure RBAC?

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

podporuje Data Lake Storage Gen2 dědění 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. Chcete-li aktualizovat seznamy ACL pro existující podřízené položky, budete muset pro požadovanou hierarchii adresářů přidat, aktualizovat nebo odebrat seznamy ACL rekurzivně. Pokyny najdete v části nastavení seznamů ACL v tomto článku.

Která oprávnění jsou nutná k rekurzivnímu odstranění adresáře a jeho obsahu?

• Volající má oprávnění Super User,

Nebo

• Nadřazený adresář musí mít oprávnění zapisovat + provést.
• Adresář, který se má odstranit, a každý adresář v něm vyžaduje oprávnění číst + zapisovat + provést.

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

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

Která skupina je nastavená jako vlastnící skupina souboru nebo adresáře při vytvoření?

Vlastnící skupina je zkopírována z vlastnící skupiny nadřazeného adresáře, pod nímž je vytvořen nový soubor nebo adresář.

Jsem vlastnící uživatel souboru, ale nemáte oprávnění RWX, která potřebuji. 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.

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

Zobrazí se identifikátor GUID, pokud položka představuje uživatele a tento uživatel ve službě Azure AD již neexistuje. K tomu obvykle dochází, když uživatel opustí společnost nebo když je jeho účet odstraněn ve službě Azure AD. Instanční objekty a skupiny zabezpečení navíc nemají hlavní název uživatele (UPN), aby je identifikovali a tak byly reprezentované atributem OID (identifikátor GUID).

Návody pro instanční objekt správně nastavit seznamy ACL?

Při definování seznamů 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í samostatný instanční objekt v konkrétním tenantovi služby Azure AD. Registrované aplikace mají identifikátor OID, který je viditelný v Azure Portal, ale instanční objekt má jiný (odlišný) identifikátor OID.

K získání OID objektu služby, který odpovídá registraci aplikace, můžete použít az ad sp show příkaz. Jako parametr zadejte ID aplikace. Tady je příklad získání OID objektu služby, který odpovídá registraci aplikace s ID aplikace = 18218b12-1895-43E9-ad80-6e8fc1ea88ce. V Azure CLI 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 pro instanční objekt správný identifikátor oid, přejděte na stránku Průzkumník služby Storage spravovat přístup a přidejte identifikátor oid a přiřaďte příslušná oprávnění identifikátoru objektu. Ujistěte se, že jste vybrali možnost Uložit.

Můžu nastavit seznam řízení přístupu kontejneru?

No. Kontejner nemá seznam ACL. Můžete ale nastavit seznam řízení přístupu kořenového adresáře kontejneru. Každý kontejner má kořenový adresář a sdílí stejný název jako kontejner. Například pokud má kontejner název my-container , pak kořenový adresář má název my-container/ .

Azure Storage REST API obsahuje operaci s názvem seznam acl kontejneru, 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í, zda mohou být objekty BLOB v kontejneru přístupné veřejně.

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)
• Příručka k oprávnění 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
• ACL: Using Access Control Lists on Linux (Seznamy ACL: Používání seznamů řízení přístupu v Linuxu)

Viz také

• model řízení přístupu v Azure Data Lake Storage Gen2