Ověřování pro analýzy v cloudovém měřítku v Azure
Ověřování je proces ověření identity uživatele nebo aplikace. Preferuje se jeden zdrojový zprostředkovatel identity, který zpracovává správu a ověřování identit. Tento poskytovatel se označuje jako adresářová služba. Poskytuje metody pro ukládání dat adresáře a zpřístupnění těchto dat uživatelům a správcům sítě.
Jakékoli řešení Data Lake by mělo používat a integrovat s adresářovou službou, která se už používá. Ve většině organizací je Active Directory adresářovou službou pro všechny služby související s identitami. Je to primární a centralizovaná databáze pro všechny účty služeb a uživatelů.
V cloudu je Microsoft Entra ID centralizovaným zprostředkovatelem identity a upřednostňovaným zdrojem pro správu identit. Delegování ověřování a autorizace na Microsoft Entra ID umožňuje scénáře, jako jsou zásady podmíněného přístupu, které vyžadují, aby byl uživatel v určitém umístění. Podporuje vícefaktorové ověřování za účelem zvýšení úrovně zabezpečení přístupu. Pokud je to možné, nakonfigurujte služby Data Lake Data Store s integrací Microsoft Entra.
Pro datové služby, které nepodporují ID Microsoft Entra, použijte pro ověřování přístupový klíč nebo token. Klient by měl přístupový klíč uložit do úložiště pro správu klíčů, jako je Azure Key Vault.
Scénáře ověřování pro analýzy v cloudovém měřítku jsou:
- Ověřování uživatele
- Ověřování mezi aplikacemi a službami
Ověřování uživatele
Uživatelé, kteří se připojují k datové službě nebo prostředku, musí předložit přihlašovací údaje. Tyto přihlašovací údaje ukazují, že uživatelé jsou tím, o koho se hlásí. Pak mají přístup ke službě nebo prostředku. Ověřování také umožňuje službě znát identitu uživatelů. Služba rozhodne, co může uživatel zobrazit a dělat po ověření identity.
Azure Data Lake Storage Gen2, Azure SQL Database a Azure Synapse podporují integraci Microsoft Entra. Interaktivní režim ověřování uživatelů vyžaduje, aby uživatelé zadali přihlašovací údaje v dialogovém okně.
Důležité
Nepoužívejte pevně zakódované přihlašovací údaje uživatele do aplikace pro účely ověřování.
Ověřování mezi aplikacemi a službami
Tyto požadavky nejsou přidružené ke konkrétnímu uživateli nebo není k dispozici žádný uživatel pro zadání přihlašovacích údajů.
Ověřování služba-služba
I když služba přistupuje k jiné službě bez zásahů člověka, musí tato služba předložit platnou identitu. Tato identita prokáže, že služba je skutečná. Přístupová služba může pomocí identity rozhodnout, co může služba dělat.
Pro ověřování mezi službami je upřednostňovanou metodou ověřování služeb Azure spravované identity. Spravované identity pro prostředky Azure umožňují ověřování pro libovolnou službu, která podporuje ověřování Microsoft Entra bez explicitních přihlašovacích údajů. Další informace najdete v tématu Co jsou spravované identity pro prostředky Azure.
Spravované identity jsou instanční objekty, které je možné použít pouze s prostředky Azure. Spravovanou identitu je například možné vytvořit přímo pro instanci služby Azure Data Factory. Tato spravovaná identita je objekt zaregistrovaný v Microsoft Entra ID. Představuje tuto instanci služby Data Factory. Tuto identitu pak můžete použít k ověření v jakékoli službě, jako je Data Lake Storage, bez jakýchkoli přihlašovacích údajů v kódu. Azure se postará o přihlašovací údaje, které používá instance služby. Identita může udělit autorizaci prostředkům služeb Azure, jako je složka ve službě Azure Data Lake Storage. Když odstraníte tuto instanci služby Data Factory, Azure vyčistí identitu v Microsoft Entra ID.
Výhody používání spravovaných identit
Spravované identity by se měly použít k ověření služby Azure v jiné službě Nebo prostředku Azure. Poskytují následující výhody:
- Spravovaná identita představuje službu, pro kterou je vytvořena. Nepředstavuje interaktivního uživatele.
- Přihlašovací údaje spravované identity se spravují, spravují a ukládají v Microsoft Entra ID. Pro uživatele neexistuje žádné heslo, které by si uživatel nechal.
- U spravovaných identit klientské služby nepoužívají hesla.
- Spravovaná identita přiřazená systémem se odstraní při odstranění instance služby.
Tyto výhody znamenají, že přihlašovací údaje jsou lépe chráněné a ohrožení zabezpečení je méně pravděpodobné.
Ověřování mezi aplikacemi
Dalším scénářem přístupu je aplikace, jako je mobilní webová aplikace, která přistupuje ke službě Azure. Kdo podle toho, že přistupuje ke službě Azure, musí přístupový objekt poskytnout svou identitu a tato identita se musí ověřit.
Instanční objekt Azure je alternativou pro aplikace a služby, které nepodporují spravované identity pro ověřování prostředků Azure. Instanční objekt Azure je identita vytvořená pro použití v aplikacích, hostovaných službách a automatizovaných nástrojích, kde umožňuje přístup k prostředkům Azure. Tento přístup je omezený rolemi přiřazenými k instančnímu objektu. Z bezpečnostních důvodů doporučujeme používat instanční objekty s automatizovanými nástroji nebo aplikacemi, místo aby se mohly přihlašovat pomocí identity uživatele. Další informace naleznete v tématu Aplikace a instanční objekty v Microsoft Entra ID.
Poznámka
Spravované identity i instanční objekty se vytvářejí a udržují pouze v MICROSOFT Entra ID.
Rozdíl mezi spravovanou identitou a instančním objektem
| Instanční objekt | Spravovaná identita |
|---|---|
| Identita zabezpečení ručně vytvořená v Microsoft Entra ID pro použití aplikacemi, službami a nástroji pro přístup ke konkrétním prostředkům Azure. | Speciální typ instančního objektu. Jedná se o automatickou identitu, která se vytvoří při vytvoření služby Azure. |
| Může je používat libovolná aplikace nebo služba. Není svázaný s konkrétní službou Azure. | Představuje samotnou instanci služby Azure. Nedá se použít k reprezentaci jiných služeb Azure. |
| Má nezávislý životní cyklus. Musíte ho explicitně odstranit. | Po odstranění instance služby Azure se automaticky odstraní. |
| Ověřování založené na heslech nebo na základě certifikátů | Pro ověřování není zadané explicitní heslo. |
Ověřování a oprávnění databáze
Analýzy v cloudovém měřítku pravděpodobně obsahují polyglotové úložiště. Mezi příklady patří PostgreSQL, MySQL, Azure SQL Database, SQL Managed Instance a Azure Synapse Analytics.
- Použití ID Microsoft Entra pro ověřování s PostgreSQL
- Použití ověřování Microsoft Entra se službou Azure SQL Database, SQL Managed Instance a Azure Synapse Analytics
- Ověřování pomocí MySQL pomocí Microsoft Entra ID
Doporučujeme používat skupiny Microsoft Entra k zabezpečení databázových objektů místo jednotlivých uživatelských účtů Microsoft Entra. Tyto skupiny Microsoft Entra slouží k ověřování uživatelů a ochraně databázových objektů. Podobně jako v modelu data Lake můžete k vytvoření těchto skupin použít onboarding datové aplikace.
Poznámka
Datové aplikace můžou ukládat citlivé datové produkty ve službě Azure SQL Database, SQL Managed Instance nebo ve fondech Azure Synapse Analytics. Další informace najdete v tématu Citlivá data.
Zabezpečení Azure Data Lake v analýzách v cloudovém měřítku
Pokud chcete řídit přístup k datům v datovém jezeře, doporučujeme použít seznam řízení přístupu (ACL) na úrovni souborů a složek. Azure Data Lake také přijímá model seznamu řízení přístupu podobný POSIX. POSIX (přenosné rozhraní operačního systému) je řada standardů pro operační systémy. Jeden standard definuje jednoduchou, ale výkonnou strukturu oprávnění pro přístup k souborům a složkám. POSIX byl široce přijat pro síťové sdílené složky a unixové počítače.
Podobně jako obecné postupy Azure RBAC by se na seznam ACL měly vztahovat následující pravidla:
Správa přístupu pomocí skupin Přiřaďte přístup ke skupinám Microsoft Entra a spravujte členství ve skupinách pro průběžnou správu přístupu. Viz Řízení přístupu a konfigurace data lake ve službě Azure Data Lake Storage.
Nejnižší oprávnění. Ve většině případů by uživatelé měli mít oprávnění jen ke čtení složek a souborů, které potřebují v datovém jezeře. Spravovaná identita nebo instanční objekt, například identita používaná službou Azure Data Factory, má oprávnění ke čtení, zápisu a spouštění. Uživatelé dat by neměli mít přístup k kontejneru účtu úložiště.
Zarovnejte se se schématem dělení dat. Návrh seznamu ACL a datových oddílů musí být v souladu, aby se zajistilo efektivní řízení přístupu k datům. Další informace najdete v tématu [Dělení Data Lake].
Další kroky
Správa dat a řízení přístupu na základě role pro analýzy v cloudovém měřítku v Azure