Ověřování aplikací C++ ve službách Azure pomocí sady Azure SDK pro C++

Pokud aplikace potřebuje přístup k prostředku Azure, jako je Azure Storage, Azure Key Vault nebo služby Zasílání zpráv Azure, musí se aplikace ověřit v Azure. Tento požadavek platí pro všechny aplikace, ať už jsou 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žití sady Azure SDK pro C++.

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

Při ověřování prostředků Azure místo připojovacích řetězců pro vaše aplikace používejte ověřování založené na tokenech. Klientská knihovna Azure Identity pro C++ poskytuje třídy, které podporují ověřování založené na tokenech. Tyto třídy 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ý aplikace používá k ověření prostředků Azure, závisí na tom, kde se aplikace spouští. Typy ověřování založeného na tokenech jsou znázorněny v následujícím diagramu.

• Když vývojář spouští aplikaci během místního vývoje: Aplikace se ověřuje v Azure pomocí instančního objektu aplikace pro místní vývoj nebo přihlašovacích údajů Azure vývojáře. Tyto možnosti jsou popsány v části Ověřování během místního vývoje.
• Když je aplikace hostovaná v Azure: Aplikace se ověřuje v prostředcích Azure pomocí spravované identity. Tato možnost je popsána v části Ověřování v serverových prostředích.
• Když je aplikace hostovaná a nasazena lokálně: Aplikace se ověřuje vůči prostředkům Azure pomocí principálu aplikační služby. Tato možnost je popsána v části Ověřování v serverových prostředích.

VýchozíAzureCredential

DefaultAzureCredential třída poskytovaná klientskou knihovnou Azure Identity umožňuje aplikacím používat různé metody ověřování v závislosti na prostředí, ve kterém se spouští. Tímto způsobem je možné 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 automaticky zjistí a použije tuto metodu ověřování. Použití DefaultAzureCredential je 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žití DefaultAzureCredential třídy jsou popsány v části Použití DefaultAzureCredential v aplikaci.

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

Při vytváření aplikací pro Azure místo použití připojovacích řetězců používejte ověřování na základě tokenů. 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ů:

• Metody ověřování založené na tokenech popsané v tomto článku umožňují vytvořit konkrétní oprávnění potřebná aplikací v prostředku Azure. Tento postup se řídí principem nejnižšího oprávnění. Naproti tomu připojovací řetězec uděluje úplná práva k prostředku Azure.
• Kdokoli nebo jakákoli aplikace s připojovacím řetězcem se může připojit k prostředku Azure, ale metody ověřování založené na tokenech mají přístup k prostředku jenom aplikacím určeným pro přístup k prostředku.
• U spravované identity neexistuje žádný tajný kód aplikace, který se má uložit. Aplikace je 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 za vás získává a spravuje tokeny Microsoft Entra, což usnadňuje použití ověřování na základě tokenů jako připojovací řetězec.

Omezte použití připojovacích řetězců na počáteční aplikace pro testování konceptu nebo prototypy vývoje, které nepřistupují k produkčním nebo citlivým datům. V opačném případě se třídy ověřování založené na tokenech dostupné v klientské knihovně azure Identity vždy preferují při ověřování prostředků Azure.

Ověřování v serverových prostředích

Když hostujete v serverovém prostředí, každé aplikaci se přiřadí jedinečná identita aplikace pro každé prostředí, ve kterém se aplikace spouští. V Azure je identita aplikace reprezentována služebním principálem. Tento speciální typ objektu zabezpečení identifikuje a ověřuje aplikace v Azure. Typ služebního principálu, který se má použít pro vaši aplikaci, závisí na tom, kde vaše aplikace běží:

Metoda ověřování	Popis
Aplikace hostované v Azure	Aplikace hostované v Azure by měly používat služební principál 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 Django hostovaná ve službě Azure App Service by byla přiřazena spravovaná identita. Spravovaná identita přiřazená aplikaci by se pak použila k ověření aplikace v jiných službách Azure. Aplikace spuštěné ve službě Azure Kubernetes Service (AKS) můžou používat přihlašovací údaje identity úloh. Tyto přihlašovací údaje jsou založené na spravované identitě, která má vztah důvěryhodnosti s účtem služby AKS.
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. Instanční objekt aplikace představuje identitu aplikace v Azure a vytvoří se prostřednictvím procesu registrace aplikace. Představte si například webovou aplikaci Django hostované místně, která využívá službu Azure Blob Storage. Pomocí procesu registrace aplikace byste pro aplikaci vytvořili hlavní službu aplikace. A AZURE_CLIENT_ID, AZURE_TENANT_ID a AZURE_CLIENT_SECRET by byly uloženy jako proměnné prostředí, které aplikace čte za běhu, a umožnily aplikaci ověřit se vůči Azure pomocí service principal aplikace.

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

Když aplikace běží 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á. Při místním vývoji existují dvě hlavní strategie ověřování aplikací v Azure:

Metoda ověřování	Popis
Vytvořte vyhrazené objekty hlavního aplikačního služby, které se použijí při místním vývoji.	V této metodě jsou pomocí procesu registrace aplikace nastaveny vyhrazené objekty principálu služby aplikace pro použití během místního vývoje. 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. Tento postup zajistí, ž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 nutnost vytvořit samostatné objekty instančního objektu pro každého vývojáře, který pracuje na aplikaci.
Ověřte aplikaci 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 z Azure CLI, Azure PowerShellu nebo Azure Developer CLI 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 prostřednictvím některého z výše uvedených vývojářských nástrojů. Nevýhodou tohoto přístupu je, že účet vývojáře má pravděpodobně více oprávnění, než vyžaduje aplikace. V důsledku toho aplikace přesně nereplikuje oprávnění, která 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, která implementuje tokenCredential protokol a označuje se jako přihlašovací údaje. Během běhu aplikace se DefaultAzureCredential pokusí ověřit pomocí prvního přihlašovacího údaje. 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 v aplikaci C++, přidejte do aplikace balíček azure-identity pomocí vcpkg.

vcpkg add port azure-identity-cpp

Pak do souboru CMake přidejte následující:

find_package(azure-identity-cpp CONFIG REQUIRED)
target_link_libraries(<your project name> PRIVATE Azure::azure-identity)

Ke službám Azure se přistupuje pomocí specializovaných klientských tříd z různých klientských knihoven Azure SDK. Následující příklad kódu ukazuje, jak vytvořit instanci objektu DefaultAzureCredential a použít ho s klientskou třídou sady Azure SDK. V tomto případě se jedná o SecretClient objekt, který se používá pro přístup k tajným kódům služby Azure KeyVault.

#include <azure/identity.hpp>
#include <azure/keyvault/secrets.hpp>

int main(){
  
  auto const keyVaultUrl = std::getenv("AZURE_KEYVAULT_URL");
  auto credential = std::make_shared<Azure::Identity::DefaultAzureCredential>();

  
  Azure::Security::KeyVault::Secrets::SecretClient secretClient(keyVaultUrl, credential);
}

Když předchozí kód běží na místní vývojové pracovní stanici, hledá ve variabilách prostředí služební principál aplikace nebo v místně nainstalovaných vývojářských nástrojích, jako je Azure CLI, sadu vývojářských přihlašovacích údajů. 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 prostředcích Azure. DefaultAzureCredential může načíst nastavení prostředí a konfigurace spravovaných identit pro automatické ověřování ve službách Azure.

Související obsah

• Klientská knihovna Azure Identity pro C++ README na GitHubu