Model řízení přístupu ve službě Azure Data Lake Storage
Data Lake Storage podporuje následující mechanismy autorizace:
- Autorizace sdíleného klíče
- Autorizace sdíleného přístupového podpisu (SAS)
- Řízení přístupu na základě role (Azure RBAC)
- Řízení přístupu na základě atributů (Azure ABAC)
- Seznamy řízení přístupu
Sdílený klíč, SAS účtu a autorizace SAS služby uděluje přístup uživateli (nebo aplikaci), aniž by musel mít identitu v Microsoft Entra ID. Tyto formy ověřování nemají žádný vliv na Azure RBAC, Azure ABAC a seznamy ACL. Seznamy ACL je možné použít u tokenů SAS delegovaných uživatelem, protože tyto tokeny jsou zabezpečené pomocí přihlašovacích údajů Microsoft Entra. Viz Sdílený klíč a autorizace SAS.
Azure RBAC i seznam ACL vyžadují, aby měl uživatel (nebo aplikace) identitu v Microsoft Entra ID. Azure RBAC umožňuje udělit „hrubě odstupňovaný“ přístup k datům účtu úložiště, jako například přístup pro čtení nebo zápis ke všem datům v účtu úložiště. Azure ABAC umožňuje upřesnit přiřazení rolí RBAC přidáním podmínek. Přístup ke čtení nebo zápisu můžete například udělit všem datovým objektům v účtu úložiště, které mají určitou značku. Seznamy ACL umožňují udělit „jemně odstupňovaný“ přístup, například přístup k zápisu do určitého adresáře nebo souboru.
Tento článek se zaměřuje na azure RBAC, ABAC a seznamy ACL a na to, jak je systém vyhodnocuje společně a rozhoduje o autorizaci prostředků účtu úložiště.
Řízení přístupu na základě role (Azure RBAC)
Azure RBAC používá přiřazení rolí k použití sad oprávnění pro objekty zabezpečení. Objekt zabezpečení je objekt, který představuje uživatele, skupinu, instanční objekt nebo spravovanou identitu definovanou v Microsoft Entra ID. Sada oprávnění může instančnímu objektu udělit "hrubou úroveň" přístupu, jako je například přístup pro čtení nebo zápis ke všem datům v účtu úložiště nebo všechna data v kontejneru.
Následující role umožňují instančnímu objektu zabezpečení přístup k datům v účtu úložiště.
| Role | Popis |
|---|---|
| Vlastník dat v objektech blob služby Storage | Úplný přístup k kontejnerům a datům úložiště objektů blob. Tento přístup umožňuje objektu zabezpečení nastavit položku vlastníka a upravit seznamy ACL všech položek. |
| Přispěvatel dat objektů blob úložiště | Čtení, zápis a odstranění přístupu k kontejnerům a objektům blob úložiště objektů blob Tento přístup neumožňuje objektu zabezpečení nastavit vlastnictví položky, ale může upravit seznam ACL položek vlastněných objektem zabezpečení. |
| Čtenář dat v objektech blob služby Storage | Čtení a výpis kontejnerů úložiště objektů blob a objektů blob |
Role, jako je Vlastník, Přispěvatel, Čtenář a Přispěvatel účtu úložiště, umožňují objekt zabezpečení spravovat účet úložiště, ale neposkytují přístup k datům v rámci tohoto účtu. Tyto role (kromě čtenáře) ale můžou získat přístup k klíčům úložiště, které je možné použít v různých klientských nástrojích pro přístup k datům.
Řízení přístupu na základě atributů (Azure ABAC)
Azure ABAC staví na Azure RBAC přidáním podmínek přiřazení rolí na základě atributů v kontextu konkrétních akcí. Podmínka přiřazení role je další kontrola, kterou můžete volitelně přidat do přiřazení role, abyste zajistili přesnější řízení přístupu. Pomocí podmínek nelze explicitně odepřít přístup ke konkrétním prostředkům.
Další informace o použití Azure ABAC k řízení přístupu ke službě Azure Storage najdete v tématu Autorizace přístupu ke službě Azure Blob Storage pomocí podmínek přiřazení rolí Azure.
Seznamy ACL
Seznamy ACL umožňují použít jemně odstupňovanou úroveň přístupu k adresářům a souborům. Seznam ACL je konstruktor oprávnění, který obsahuje řadu položek seznamu ACL. Každá položka seznamu ACL přidruží objekt zabezpečení k úrovni přístupu. Další informace najdete v tématu Seznamy řízení přístupu (ACL) ve službě Azure Data Lake Storage.
Jak se vyhodnocují oprávnění
Během autorizace založené na objektech zabezpečení se oprávnění vyhodnocují, jak je znázorněno v následujícím diagramu.
- Azure určuje, jestli pro objekt zabezpečení existuje přiřazení role.
- Pokud existuje přiřazení role, vyhodnotí se další podmínky přiřazení role (2).
- Pokud ne, seznamy ACL (4) se vyhodnocují jako další.
- Azure určuje, jestli existují nějaké podmínky přiřazení role ABAC.
- Pokud neexistují žádné podmínky, přístup se udělí.
- Pokud existují podmínky, vyhodnocují se, jestli odpovídají požadavku (3).
- Azure určuje, jestli všechny podmínky přiřazení role ABAC odpovídají atributům požadavku.
- Pokud se všechny shodují, udělí se přístup.
- Pokud alespoň jeden z nich neodpovídá, budou seznamy ACL (4) vyhodnoceny jako další.
- Pokud se přístup po vyhodnocení přiřazení a podmínek rolí explicitně neudělil, vyhodnocují se seznamy ACL.
- Pokud seznamy ACL povolují požadovanou úroveň přístupu, udělí se přístup.
- Pokud ne, přístup byl odepřen.
Důležité
Vzhledem k tomu, jak systém vyhodnocuje přístupová oprávnění, nemůžete použít seznam ACL k omezení přístupu, který už bylo uděleno přiřazením role a jeho podmínkami. Důvodem je to, že systém nejprve vyhodnotí přiřazení a podmínky role Azure a pokud přiřazení udělí dostatečná oprávnění k přístupu, seznamy ACL se ignorují.
Následující diagram znázorňuje tok oprávnění pro tři běžné operace: výpis obsahu adresáře, čtení souboru a zápis souboru.
Tabulka oprávnění: Kombinování azure RBAC, ABAC a seznamů ACL
Následující tabulka ukazuje, jak kombinovat role, podmínky a položky seznamu ACL Azure, 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. V těchto sloupcích se zobrazují krátké reprezentace položky seznamu ACL vyžadované k udělení oprávnění. Není k dispozici (není k dispozici) ve sloupci, pokud není k provedení operace vyžadována položka seznamu ACL.
| Operace | Přiřazená role Azure (s podmínkami nebo bez) | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Čtení Data.txt | Vlastník dat objektů blob úložiště | – | – | – | N/A |
| Přispěvatel dat objektů blob úložiště | – | – | – | N/A | |
| Čtenář dat v objektech blob služby Storage | – | – | – | N/A | |
| Nic | --X |
--X |
--X |
R-- |
|
| Připojit k Data.txt | Vlastník dat objektů blob úložiště | – | – | – | N/A |
| Přispěvatel dat objektů blob úložiště | – | – | – | N/A | |
| Čtenář dat v objektech blob služby Storage | --X |
--X |
--X |
-W- |
|
| Nic | --X |
--X |
--X |
RW- |
|
| Odstranění Data.txt | Vlastník dat objektů blob úložiště | – | – | – | N/A |
| Přispěvatel dat objektů blob úložiště | – | – | – | N/A | |
| Čtenář dat v objektech blob služby Storage | --X |
--X |
-WX |
– | |
| Nic | --X |
--X |
-WX |
– | |
| Vytvoření nebo aktualizace Data.txt | Vlastník dat objektů blob úložiště | – | – | – | N/A |
| Přispěvatel dat objektů blob úložiště | – | – | – | N/A | |
| Čtenář dat v objektech blob služby Storage | --X |
--X |
-WX |
– | |
| Nic | --X |
--X |
-WX |
– | |
| Seznam/ | Vlastník dat objektů blob úložiště | – | – | – | N/A |
| Přispěvatel dat objektů blob úložiště | – | – | – | N/A | |
| Čtenář dat v objektech blob služby Storage | – | – | – | N/A | |
| Nic | R-X |
– | – | N/A | |
| Seznam /Oregon/ | Vlastník dat objektů blob úložiště | – | – | – | N/A |
| Přispěvatel dat objektů blob úložiště | – | – | – | N/A | |
| Čtenář dat v objektech blob služby Storage | – | – | – | N/A | |
| Nic | --X |
R-X |
– | N/A | |
| Seznam /Oregon/Portland/ | Vlastník dat objektů blob úložiště | – | – | – | N/A |
| Přispěvatel dat objektů blob úložiště | – | – | – | N/A | |
| Čtenář dat v objektech blob služby Storage | – | – | – | N/A | |
| Nic | --X |
--X |
R-X |
– |
Poznámka:
Pokud chcete zobrazit obsah kontejneru v Průzkumník služby Azure Storage, musí se objekty zabezpečení přihlásit k Průzkumník služby Storage pomocí ID Microsoft Entra a (minimálně) mají přístup pro čtení (R--) ke kořenové složce (\) kontejneru. Tato úroveň oprávnění jim dává možnost vypsat obsah kořenové složky. Pokud nechcete, aby byl obsah kořenové složky viditelný, můžete jim přiřadit roli Čtenář . Díky této roli budou moct vypsat kontejnery v účtu, ale nebudou mít obsah kontejneru. Přístup ke konkrétním adresářům a souborům pak můžete udělit pomocí seznamů ACL.
Skupiny zabezpečení
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:
LogsWriterPřidejte skupinu do seznamu ACL adresáře /LogData s oprávněnímirwx.LogsReaderPř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
LogsWritersskupiny. - Přidejte do skupiny uživatele v technickém
LogsWritertýmu služeb. - Přidejte objekt instančního objektu nebo MSI pro Databricks do
LogsReaderskupiny.
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.
Omezení přiřazení rolí Azure a položek seznamu ACL
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ář. Tato omezení jsou popsána v následující tabulce.
| 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 |
Autorizace sdíleného klíče a sdíleného přístupového podpisu (SAS)
Azure Data Lake Storage také podporuje metody sdíleného klíče a SAS pro ověřování.
V případě sdíleného klíče volající efektivně získá přístup superuživatele, což znamená úplný přístup ke všem operacím se všemi prostředky, včetně dat, nastavení vlastníka a změny seznamů ACL. Seznamy ACL se nevztahují na uživatele, kteří používají autorizaci pomocí sdíleného klíče, protož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í. Totéž platí pro tokeny sdíleného přístupového podpisu (SAS), s výjimkou případů, kdy se používá token SAS delegovaný uživatelem. V takovém případě Azure Storage provede kontrolu seznamu ACL POSIX s ID objektu, než autorizuje operaci, pokud se použije volitelný suoid parametru. Další informace najdete v tématu Vytvoření SAS delegování uživatele.
Další kroky
Další informace o seznamech řízení přístupu najdete v tématu Seznamy řízení přístupu (ACL) ve službě Azure Data Lake Storage.