Ověřování aplikací .NET ve službách Azure pomocí knihovny identit Azure

Aplikace můžou použít knihovnu Identit Azure k ověření v Microsoft Entra ID, což umožňuje aplikacím přístup ke službám a prostředkům Azure. Tento požadavek na ověřování se vztahuje na to, jestli je aplikace nasazená v Azure, hostovaná místně nebo spuštěná místně na vývojářské pracovní stanici. V následujících částech jsou popsané doporučené přístupy k ověření aplikace v Microsoft Entra ID v různých prostředích při použití klientských knihoven sady Azure SDK.

Doporučený přístup pro ověřování aplikací

Ověřování pomocí tokenů prostřednictvím Microsoft Entra ID je doporučeným přístupem pro ověřování aplikací v Azure místo použití připojovacích řetězců nebo možností založených na klíčích. Knihovna identit Azure poskytuje třídy, které podporují ověřování na základě tokenů a umožňují aplikacím ověřovat prostředky Azure bez ohledu na to, jestli aplikace běží místně, v Azure nebo na místním serveru.

Výhody ověřování založeného na tokenech

Ověřování na základě tokenů nabízí následující výhody oproti připojovacím řetězcům:

• Ověřování na základě tokenů zajišťuje, že k prostředku Azure budou mít přístup jenom konkrétní aplikace určené pro přístup, zatímco kdokoli nebo jakákoli aplikace s připojovacím řetězcem se může připojit k prostředku Azure.
• Ověřování na základě tokenů umožňuje dále omezit přístup k prostředkům Azure jenom na konkrétní oprávnění potřebná aplikací. To se řídí zásadou nejnižších oprávnění. Naproti tomu připojovací řetězec uděluje úplná práva k prostředku Azure.
• Když používáte spravovanou identitu pro ověřování na základě tokenů, Azure za vás zpracovává funkce správy, takže se nemusíte starat o úlohy, jako je zabezpečení nebo obměně tajných kódů. Díky tomu je aplikace bezpečnější, protože neexistuje žádný připojovací řetězec ani tajný klíč aplikace, které by bylo možné ohrozit.
• Knihovna Identit Azure za vás získává a spravuje tokeny Microsoft Entra.

Použití připojovacích řetězců by mělo být omezené na scénáře, kdy ověřování na základě tokenů není dostupné, počáteční ověřovací aplikace nebo vývojové prototypy, které nepřistupují k produkčním prostředí nebo citlivým datům. Pokud je to možné, použijte třídy ověřování založené na tokenech dostupné v knihovně identit Azure k ověření prostředků Azure.

Ověřování v různých prostředích

Konkrétní typ ověřování na základě tokenů, který by aplikace měla použít k ověření prostředků Azure, závisí na tom, kde aplikace běží. Následující diagram obsahuje pokyny pro různé scénáře a prostředí:

Když je aplikace:

• Hostované v Azure: Aplikace by se měla ověřovat u prostředků Azure pomocí spravované identity. Tato možnost je podrobněji popsána v rámci ověřování v serverových prostředích .
• Spuštění místně během vývoje: Aplikace se může ověřit v Azure pomocí instančního objektu aplikace pro místní vývoj nebo pomocí přihlašovacích údajů Azure vývojáře. Každá možnost je podrobněji popsána během ověřování během místního vývoje.
• Hostovaná místně: Aplikace by se měla ověřovat u prostředků Azure pomocí instančního objektu aplikace nebo spravované identity v případě Azure Arc. Místní pracovní postupy jsou podrobněji popsány při ověřování v serverových prostředích.

Ověřování pro aplikace hostované v Azure

Když je vaše aplikace hostovaná v Azure, může používat spravované identity k ověřování prostředků Azure bez nutnosti spravovat přihlašovací údaje. Existují dva typy spravovaných identit: přiřazené uživatelem a přiřazené systémem.

Použití spravované identity přiřazené uživatelem

Spravovaná identita přiřazená uživatelem se vytváří jako samostatný prostředek Azure. Dá se přiřadit k jednomu nebo několika prostředkům Azure, což těmto prostředkům umožňuje sdílet stejnou identitu a oprávnění. Pokud se chcete ověřit pomocí spravované identity přiřazené uživatelem, vytvořte ji, přiřaďte ji k prostředku Azure a pak aplikaci nakonfigurujte tak, aby tuto identitu používala k ověřování zadáním ID klienta, ID prostředku nebo ID objektu.

Ověřování pomocí spravované identity přiřazené uživatelem

Použití spravované identity přiřazené systémem

Spravovaná identita přiřazená systémem je povolená přímo u prostředku Azure. Identita je svázaná s životním cyklem tohoto prostředku a při odstranění prostředku se automaticky odstraní. Pokud se chcete ověřit pomocí spravované identity přiřazené systémem, povolte identitu ve vašem prostředku Azure a nakonfigurujte aplikaci tak, aby tuto identitu používala k ověřování.

Ověřování pomocí spravované identity přiřazené systémem

Ověřování během místního vývoje

Během místního vývoje se můžete autentizovat k prostředkům Azure pomocí přihlašovacích údajů pro vývojáře nebo servisního principálu. To vám umožní otestovat logiku ověřování vaší aplikace bez nasazení do Azure.

Použití přihlašovacích údajů pro vývojáře

Při místním vývoji můžete k ověřování prostředků Azure použít vlastní přihlašovací údaje Azure. Obvykle se to provádí pomocí vývojového nástroje, jako je Azure CLI nebo Visual Studio, který vaší aplikaci poskytne potřebné tokeny pro přístup ke službám Azure. Tato metoda je pohodlná, ale měla by být použita pouze pro účely vývoje.

Místní ověřování pomocí přihlašovacích údajů vývojáře

Použijte služebního hlavního prvku

Principál služby se vytvoří v tenantovi Microsoft Entra, aby reprezentoval aplikaci a sloužil k autentizaci k prostředkům Azure. Aplikaci můžete nakonfigurovat tak, aby používala přihlašovací údaje instančního objektu během místního vývoje. Tato metoda je bezpečnější než použití přihlašovacích údajů vývojáře a blíží se způsobu ověřování vaší aplikace v produkčním prostředí. Je ale stále méně ideální než použití spravované identity kvůli potřebě tajných kódů.

Místní ověření pomocí servisního účtu

Ověřování pro aplikace hostované místně

U aplikací hostovaných místně můžete k ověřování k prostředkům Azure použít služební účet. To zahrnuje vytvoření instančního objektu v MICROSOFT Entra ID, přiřazení potřebných oprávnění a konfiguraci aplikace tak, aby používala jeho přihlašovací údaje. Tato metoda umožňuje vaší místní aplikaci zabezpečený přístup ke službám Azure.

Ověřte lokální aplikaci pomocí principálu služby