Přehled ověřování aplikací .NET ve službách Azure pomocí knihovny identit Azure
Když aplikace potřebuje přístup k prostředku Azure, musí se aplikace ověřit v Azure. To platí pro všechny aplikace, ať už nasazené v Azure, nasazené místně nebo ve vývoji na místní vývojářské pracovní stanici. Tento článek popisuje doporučené přístupy k ověřování aplikace v Azure při používání klientských knihoven sady Azure SDK.
Doporučený přístup k ověřování aplikací
Doporučuje se, aby aplikace při ověřování prostředků Azure používaly ověřování založené na tokenech místo připojovacích řetězců. Knihovna Azure Identity library poskytuje třídy, které podporují ověřování na základě tokenů a umožňují aplikacím bezproblémově ověřovat prostředky Azure bez ohledu na to, jestli je aplikace v místním vývoji, nasazená v Azure nebo nasazená na místním serveru.
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ěží a která se zobrazuje v následujícím diagramu:
Když je aplikace:
- Spuštěno místně během vývojovéhomůže aplikace 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é v Azureby se aplikace měla ověřit 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 .
- hostováno a nasazeno v místním prostředí, by se aplikace měla ověřovat u prostředků Azure pomocí instančního objektu aplikace. Tato možnost je podrobněji popsána v rámci ověřování v serverových prostředích .
DefaultAzureCredential
Třída DefaultAzureCredential poskytovaná knihovnou identit Azure umožňuje aplikacím používat různé metody ověřování v závislosti na prostředí, ve kterém se spouští. To umožňuje zvýšit úroveň aplikací z místního vývoje na testovací prostředí do produkčního prostředí beze změn kódu. Nakonfigurujete odpovídající metodu ověřování pro každé prostředí a DefaultAzureCredential
tuto metodu ověřování automaticky rozpozná a použije. Použití DefaultAzureCredential
by mělo být upřednostňované před ručním kódováním podmíněné logiky nebo příznaků funkcí pro použití různých metod ověřování v různých prostředích.
Podrobnosti o používání DefaultAzureCredential
najdete v dokumentu . Použijte DefaultAzureCredential
v aplikaci.
Výhody ověřování založeného na tokenech
Ověřování založené na tokenech nabízí následující výhody při ověřování pomocí připojovacích řetězců:
- Níže popsané metody ověřování na základě tokenů umožňují vytvořit konkrétní oprávnění potřebná aplikací v prostředku Azure. 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.
- Zatímco kdokoli nebo jakákoli aplikace s připojovacím řetězcem se může připojit k prostředku Azure, metody ověřování založené na tokenech mají přístup k prostředku pouze aplikacím určeným pro přístup k prostředku.
- V případě spravované identity neexistuje žádný tajný kód aplikace pro ukládání. 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.
- Balíček Azure.Identity získává a spravuje tokeny Microsoft Entra za vás. Díky tomu se ověřování založené na tokenech snadno používá jako připojovací řetězec.
Použití připojovacích řetězců by mělo být omezené na počáteční prototypy testování konceptu nebo prototypy vývoje, které nepřistupují k produkčním nebo citlivým datům. Jinak by se při ověřování prostředků Azure měly vždy upřednostňovat třídy ověřování založené na tokenech, které jsou k dispozici v knihovně identit Azure.
Ověřování v serverových prostředích
Při hostování v serverovém prostředí by měla být každé aplikaci přiřazena jedinečná identita aplikace na prostředí, ve kterém je aplikace spuštěná. V Azure je identita aplikace reprezentována instančním objektem, speciálním typem objektu zabezpečení určeným k identifikaci a ověřování aplikací v Azure. Typ služebního zástupce, který použijete pro svou aplikaci, závisí na tom, kde je vaše aplikace spuštěna.
Metoda ověřování | Popis |
---|---|
Aplikace hostované v Azure | Aplikace hostované v Azure by měly používat služebního principála spravované identity . Spravované identity jsou navržené tak, aby představovaly identitu aplikace hostované v Azure a dají se používat jenom s aplikacemi hostovanými v Azure. Například webová aplikace .NET hostovaná ve službě Azure App Service by byla přiřazena spravovaná identita. Spravovaná identita přiřazená k aplikaci by se pak použila k ověření aplikace v jiných službách Azure. |
Aplikace hostované mimo Azure (například místní aplikace) |
Aplikace hostované mimo Azure (například místní aplikace), které se potřebují připojit ke službám Azure, by měly používat instanční objekt aplikace. Aplikační služba principal představuje identitu aplikace v Azure a je vytvořena pomocí procesu registrace aplikace. Představte si například webovou aplikaci .NET hostované místně, která využívá službu Azure Blob Storage. Pomocí procesu registrace aplikace byste vytvořili služební objekt aplikace. Všechny AZURE_CLIENT_ID , AZURE_TENANT_ID a AZURE_CLIENT_SECRET by se uložily jako proměnné prostředí, které aplikace čtou za běhu, a umožnily tak aplikaci ověřit se v Azure pomocí zástupce služby aplikace. |
Ověřování během místního vývoje
Když je aplikace spuštěná na pracovní stanici vývojáře během místního vývoje, musí se stále ověřovat ve všech službách Azure, které aplikace používá. Mezi dvě hlavní strategie ověřování aplikací v Azure během místního vývoje patří:
Metoda ověřování | Popis |
---|---|
Vytvořte objekty hlavní služby aplikace sloužící k místnímu vývoji. | V této metodě jsou vyhrazené objekty hlavní služby aplikace nastaveny pomocí procesu registrace aplikace pro použití při místním vývoji. Identita instančního objektu se pak uloží jako proměnné prostředí, ke které má aplikace přistupovat, když se spustí v místním vývoji. Tato metoda umožňuje přiřadit objektům služby principal konkrétní oprávnění k prostředkům, které aplikace potřebuje, a které vývojáři používají během místního vývoje. Tím zajistíte, že aplikace má přístup jenom ke konkrétním prostředkům, které potřebuje, a replikuje oprávnění, která bude aplikace mít v produkčním prostředí. Nevýhodou tohoto přístupu je potřeba vytvořit samostatné objekty instančního objektu pro každého vývojáře, který pracuje v aplikaci. |
Ověření aplikace v Azure pomocí přihlašovacích údajů vývojáře během místního vývoje | V této metodě musí být vývojář přihlášený k Azure ze sady Visual Studio, rozšíření Azure Tools pro VS Code, Azure CLI nebo Azure PowerShellu na místní pracovní stanici. Aplikace pak může přistupovat k přihlašovacím údajům vývojáře z úložiště přihlašovacích údajů a pomocí těchto přihlašovacích údajů získat přístup k prostředkům Azure z aplikace. Tato metoda má výhodu jednoduššího nastavení, protože vývojář se musí přihlásit ke svému účtu Azure jenom ze sady Visual Studio, VS Code nebo Azure CLI. Nevýhodou tohoto přístupu je, že účet vývojáře má pravděpodobně více oprávnění, než vyžaduje aplikace. Proto tento přístup přesně nereplikuje oprávnění, se kterými se aplikace bude spouštět v produkčním prostředí. |
Použití DefaultAzureCredential v aplikaci
DefaultAzureCredential je názorově orientovaná, seřazená posloupnost mechanismů pro ověřování pro Microsoft Entra ID. Každý mechanismus ověřování je třída odvozená z třídy TokenCredential a je známá jako přihlašovací údaje. Za běhu se DefaultAzureCredential
pokusí ověřit pomocí prvních přihlašovacích údajů. Pokud se tento přihlašovací údaj nepodaří získat přístupový token, pokusí se další přihlašovací údaje v této sekvenci atd., dokud se přístupový token úspěšně nezíská. Aplikace tak může používat různé přihlašovací údaje v různých prostředích bez psaní kódu specifického pro prostředí.
Pokud chcete použít DefaultAzureCredential
, přidejte do aplikace Azure.Identity a volitelně balíčky Microsoft.Extensions.Azure:
V terminálu podle vašeho výběru přejděte do adresáře projektu aplikace a spusťte následující příkazy:
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Ke službám Azure se přistupuje pomocí specializovaných klientských tříd z různých klientských knihoven Azure SDK. Tyto třídy a vlastní služby by se měly zaregistrovat, aby k nim bylo možné přistupovat prostřednictvím injektáže závislostí v celé aplikaci. V Program.cs
proveďte následující kroky pro zaregistrování klientské třídy a DefaultAzureCredential
:
- Pomocí direktiv
Azure.Identity
zahrňteMicrosoft.Extensions.Azure
ausing
obory názvů. - Zaregistrujte klienta služby Azure pomocí odpovídající metody rozšíření s předponou
Add
. - Předejte instanci
DefaultAzureCredential
metoděUseCredential
.
Například:
using Microsoft.Extensions.Azure;
using Azure.Identity;
builder.Services.AddAzureClients(clientBuilder =>
{
clientBuilder.AddBlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"));
clientBuilder.UseCredential(new DefaultAzureCredential());
});
Alternativou k UseCredential
je vytvoření instance DefaultAzureCredential
přímo:
using Azure.Identity;
builder.Services.AddSingleton<BlobServiceClient>(_ =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
Když předchozí kód běží na místní vývojové pracovní stanici, hledá v proměnných prostředí instanční objekt aplikace nebo v místně nainstalovaných vývojářských nástrojích, jako je Visual Studio, pro sadu přihlašovacích údajů vývojáře. K ověření aplikace v prostředcích Azure se dá použít některý z přístupů během místního vývoje.
Při nasazení do Azure může stejný kód také ověřit vaši aplikaci v jiných prostředcích Azure.
DefaultAzureCredential
může načíst nastavení prostředí a konfigurace spravovaných identit pro automatické ověřování v jiných službách.