Část 2: Požadavky na ověřování v tomto ukázkovém situaci

Předchozí část: Úvod a pozadí

V tomto ukázkovém scénáři má hlavní aplikace tři odlišné požadavky na ověřování:

• Azure Key Vault

  Aplikace se musí ověřit pomocí Azure Key Vault, aby načetla bezpečně uložený klíč rozhraní API potřebný k volání služby třetí strany.

• API třetí strany

  Jakmile aplikace načte klíč rozhraní API, použije ho k ověření pomocí externího rozhraní API třetí strany.

• Azure Queue Storage

  Po zpracování požadavku se musí aplikace ověřit ve službě Azure Queue Storage, aby vložila zprávu pro asynchronní nebo odložené zpracování.

Tyto úlohy vyžadují, aby aplikace spravuje tři sady přihlašovacích údajů:

• Dvě sady pro prostředky Azure (Key Vault a Storage)

• Jedna sada pro externí službu (API třetí strany)

Problémy s klíčovými ověřováními

Vytváření zabezpečených cloudových aplikací vyžaduje pečlivé zpracování přihlašovacích údajů, zejména pokud je zapojeno více služeb. Tento ukázkový scénář představuje několik kritických problémů:

• Cyklická závislost na službě Key Vault

  Aplikace používá Azure Key Vault k bezpečnému ukládání tajných kódů, jako jsou klíče rozhraní API třetích stran nebo přihlašovací údaje služby Azure Storage. Pokud ale chcete tyto tajné kódy načíst, musí se aplikace nejprve ověřit ve službě Key Vault. Tato situace vytvoří cyklický problém: Aplikace potřebuje přihlašovací údaje pro přístup k Key Vault, ale tyto přihlašovací údaje musíte bezpečně uložit. Bez zabezpečeného řešení by tento problém mohl vést k pevně zakódovaným přihlašovacím údajům nebo nezabezpečeným konfiguracím ve vývojových prostředích.

• Zabezpečené zpracování klíčů rozhraní API třetích stran

  Po načtení klíče rozhraní API ze služby Key Vault ji musí aplikace použít k volání externí služby třetí strany. S tímto klíčem zacházejte velmi opatrně:

  • Nikdy ho nezakódujte ve zdrojovém kódu nebo konfiguračních souborech.
  • Nikdy to nezaznamenávejte do stdout, stderr ani do aplikačních logů.
  • Podržte ho pouze v paměti a přistupujte k němu za běhu, těsně před použitím
  • Okamžitě ho vyřaďte po dokončení požadavku.

  Při nedodržení těchto postupů se zvyšuje riziko úniku přihlašovacích údajů nebo neoprávněného použití.

• Zabezpečení přihlašovacích údajů azure Queue Storage

  K zápisu zpráv do azure Queue Storage obvykle aplikace potřebuje připojovací řetězec nebo sdílený přístupový token. Tyto přihlašovací údaje:

  • Musí být uložená v zabezpečeném umístění, například ve službě Key Vault.
  • Nesmí se zobrazovat v protokolech, výpisech zásobníků nebo v nástrojích pro vývojáře.
  • Přístup by se měl provádět pouze prostřednictvím bezpečných runtime mechanismů.
  • Vyžadování správné konfigurace RBAC, pokud používáte spravovanou identitu

• Flexibilita prostředí

  Aplikace musí běžet spolehlivě v místním vývojovém i cloudovém produkčním prostředí s použitím stejného základu kódu a minimální podmíněné logiky.

  Tento požadavek znamená:

  • Nevkládejte tajné kódy specifické pro prostředí do kódu.
  • Nepřepínejte ručně přihlašovací údaje ani větve logiky
  • Konzistentní používání ověřování na základě identit napříč prostředími

Ověřování primárně pomocí Azure s využitím Microsoft Entra ID

S tím, jak se cloudové aplikace škálují složitostí a integrují se s více službami, je nezbytné zabezpečené a zjednodušené ověřování. Azure nabízí model Azure první identity prostřednictvím Microsoft Entra ID, který umožňuje jednotnou správu identit a bezproblémovou integraci se službami Azure pro zabezpečené ověřování bez přihlašovacích údajů.

Namísto ruční správy tajných údajů nebo vkládání přihlašovacích údajů do kódu aplikace, což je postup náchylný k bezpečnostním rizikům, umožňuje Microsoft Entra ID aplikacím bezpečně se ověřovat pomocí spravovaných identit.

Mezi klíčové výhody spravovaných identit Microsoft Entra patří:

• Žádné tajné kódy v kódu

  Aplikace už nevyžadují pevně zakódované připojovací řetězce, tajné kódy klienta ani klíče.

• Integrovaná identita pro aplikace

  Azure můžou aplikaci automaticky přiřadit spravovanou identitu, aby mohl bezpečně přistupovat ke službám, jako jsou Key Vault, Storage a SQL bez dalších přihlašovacích údajů.

• Konzistentní prostředí

  Stejný model kódu a identity fungují jak v místním vývojovém prostředí, tak v prostředích hostovaných Azure pomocí Azure SDK DefaultAzureCredential.

Identitní tok specifický pro prostředí

Aplikace, které pro ověřování používají ID Microsoft Entra, využívají flexibilní model identit, který bezproblémově funguje v prostředích azure hostovaných i místních vývojových prostředích. Tato konzistence poskytuje Azure SDK DefaultAzureCredential automatickým výběrem příslušné metody identity na základě prostředí.

Prostředí Azure

Když nasadíte aplikaci do Azure:

• Aplikace automaticky získá spravovanou identitu.
• Azure spravuje vystavování tokenů a životní cyklus přihlašovacích údajů interně, takže nemusíte zpracovávat žádné tajné kódy.
• Aplikace přistupuje ke službám pomocí Role-Based Access Control (RBAC) nebo Key Vault zásad přístupu.

Místní vývojové prostředí

Během místního vývoje:

• Instanční objekt služby slouží jako identita aplikace.
• Vývojáři se ověřují pomocí Azure CLI (az login), proměnných prostředí nebo integrace Visual Studio/VS Code.
• Stejný kód aplikace se spouští bez jakýchkoli úprav – pouze změny zdroje identity.

V obou prostředích sady Azure SDK používají DefaultAzureCredential, který skrývá zdroj identity a automaticky zvolí správnou metodu.

Osvědčené postupy pro zabezpečený vývoj

I když můžete tajné kódy nastavit jako proměnné prostředí (například prostřednictvím Aplikace Azure Nastavení), má tento přístup nevýhodu:

• Tajné kódy musíte ručně replikovat v místních prostředích.
• Existuje riziko úniku tajných kódů do správy zdrojového kódu.
• Možná budete potřebovat další logiku, abyste mohli rozlišovat mezi prostředími.

Místo toho použijte následující přístup:

• Key Vault slouží k ukládání klíčů rozhraní API třetích stran a dalších tajných kódů.
• Přiřaďte ke své nasazené aplikaci spravovanou identitu.
• Použijte službu pro místní vývoj a přidělte jí stejná přístupová práva.
• V kódu se používá DefaultAzureCredential k abstrakci logiky ověřování.
• Vyhněte se ukládání nebo protokolování přihlašovacích údajů.

Praktické použití autentizačního toku

Tady je postup, jak funguje ověřování za běhu:

• Váš kód vytvoří DefaultAzureCredential instanci.
• Pomocí těchto přihlašovacích údajů vytvoříte instanci klienta (například SecretClient, QueueServiceClient).
• Když aplikace vyvolá metodu (například get_secret()), klient k ověření požadavku použije přihlašovací údaje.
• Azure ověří identitu a zkontroluje, jestli má k provedení operace správnou roli nebo zásadu.

Tento tok zajišťuje, že vaše aplikace bude mít zabezpečený přístup ke službám Azure bez vkládání tajných kódů do kódu nebo konfiguračních souborů. Umožňuje také bezproblémově přepínat mezi místním vývojem a cloudovým nasazením beze změny logiky ověřování.