Návod: Integrované ověřování pro aplikace v Pythonu se službami Azure

Microsoft Entra ID, když se používá se službou Azure Key Vault, poskytuje robustní a bezpečný přístup pro ověřování aplikací pro služby Azure i platformy třetích stran, které vyžadují přístupové klíče nebo přihlašovací údaje. Tato kombinace eliminuje nutnost pevně zakódovat tajné kódy v kódu aplikace, místo toho se spoléhá na spravované identity, řízení přístupu na základě role (RBAC) a centralizovanou správu tajných kódů prostřednictvím služby Key Vault. Tento přístup zjednodušuje správu identit a vylepšuje stav zabezpečení v cloudových prostředích.

Tento názorný postup zkoumá tyto mechanismy ověřování prostřednictvím praktického příkladu uvedeného v úložišti GitHub: github.com/Azure-Samples/python-integrated-authentication.

Ukázka ukazuje, jak může aplikace v Pythonu:

• Ověřování pomocí Azure pomocí DefaultAzureCredential

• Přístup k tajným kódům služby Azure Key Vault bez uložení přihlašovacích údajů

• Zabezpečená komunikace s dalšími službami Azure, jako je Azure Storage, Cosmos DB a další

Tento článek je součástí série, která obsahuje podrobný návod, jak ověřit aplikaci v Pythonu pomocí Microsoft Entra ID, Azure Key Vaultu a Azure Queue Storage pomocí knihovny azure Python SDK azure-identity .

Část 1: Pozadí

I když mnoho Azure služeb spoléhá výhradně na řízení přístupu na základě role (RBAC), jiné vyžadují přístup prostřednictvím tajných kódů nebo klíčů. Mezi tyto služby patří Azure Storage, databáze, nástroje Foundry, Key Vault a Event Hubs.

Při vytváření cloudových aplikací, které s těmito službami pracují, můžou vývojáři pomocí webu Azure Portal, rozhraní příkazového řádku nebo PowerShellu generovat a konfigurovat přístupové klíče specifické pro službu. Tyto klíče jsou svázané s konkrétními zásadami přístupu, aby se zabránilo neoprávněnému přístupu. Tento model ale vyžaduje, aby vaše aplikace spravovala klíče explicitně a ověřovala se samostatně u každé služby, což je proces, který je zdlouhavý i náchylný k chybám.

Vkládání tajných kódů přímo do kódu nebo jejich ukládání na vývojářské počítače riskuje jejich zveřejnění:

• Správa zdrojového kódu
• Nezabezpečená místní prostředí
• Nechtěné protokoly nebo exporty konfigurace

Azure nabízí dvě klíčové služby pro zlepšení zabezpečení a zjednodušení ověřování:

• Azure Key Vault Azure Key Vault poskytuje zabezpečené cloudové úložiště tajných kódů, včetně přístupových klíčů, připojovacích řetězců a certifikátů. Načtením tajných kódů ze služby Key Vault pouze za běhu se aplikace vyhýbají zveřejnění citlivých dat ve zdrojovém kódu nebo konfiguračních souborech.

• Pomocí spravovaných identit Microsoft Entra se vaše aplikace může jednou ověřit pomocí ID Microsoft Entra. Odtud může přistupovat k dalším službám Azure , včetně služby Key Vault, bez přímé správy přihlašovacích údajů.

Tento přístup poskytuje:

• Kód bez přihlašovacích údajů (bez tajných kódů ve správě zdrojového kódu)
• Bezproblémová integrace se službami Azure
• Konzistence prostředí: Stejný kód běží místně a v cloudu s minimální konfigurací.

Tento názorný postup ukazuje, jak používat spravovanou identitu Microsoft Entra a službu Key Vault společně ve stejné aplikaci. Díky společnému ID Microsoft Entra a Key Vaultu se vaše aplikace nikdy nemusí ověřovat v jednotlivých službách Azure a může snadno a bezpečně přistupovat ke všem klíčům nezbytným pro služby třetích stran.

Ukázkový scénář cloudové aplikace

Pokud chcete lépe porozumět procesu ověřování Azure, zvažte následující scénář: Webová aplikace Flask se nasadí do služby Azure App Service. Zveřejňuje veřejný neověřený koncový bod rozhraní API, který vrací data JSON v reakci na požadavky HTTP.

• K vygenerování odpovědi rozhraní API vyvolá rozhraní API třetí strany, které vyžaduje přístupový klíč. Místo uložení tohoto klíče do kódu nebo konfiguračních souborů ji aplikace bezpečně načte za běhu ze služby Azure Key Vault pomocí spravované identity Microsoft Entra.

• Před vrácením odpovědi klientovi aplikace zapíše zprávu do fronty služby Azure Storage pro asynchronní zpracování. Zpráva může představovat úkol, protokol nebo signál, i když zpracování podřízeného procesu není fokusem tohoto scénáře.