Del 2: Autentiseringsbehov i det här exempelscenariot

Föregående del: Introduktion och bakgrund

I det här exempelscenariot har huvudprogrammet tre olika autentiseringskrav:

• Azure 密钥保管库

  Programmet måste autentisera med Azure Key Vault för att hämta en säkert lagrad API-nyckel som behövs för att anropa en tjänst från tredje part.

• API från tredje part

  När programmet hämtar API-nyckeln använder det nyckeln för att autentisera med det externa API:et från tredje part.

• Azure-könlagringstjänst

  När du har bearbetat begäran måste programmet autentisera med Azure Queue Storage för att skicka ett meddelande för asynkron eller uppskjuten bearbetning.

Dessa uppgifter kräver att appen hanterar tre uppsättningar autentiseringsuppgifter:

• Två uppsättningar för Azure resurser (Key Vault och Lagring)

• En uppsättning för en extern tjänst (API från tredje part)

Viktiga autentiseringsutmaningar

Att skapa säkra molnprogram kräver noggrann hantering av autentiseringsuppgifter, särskilt när det gäller flera tjänster. Det här exempelscenariot medför flera kritiska utmaningar:

• Cirkulärt beroende av Key Vault

  Programmet använder Azure Key Vault för att lagra hemligheter på ett säkert sätt, till exempel API-nycklar från tredje part eller autentiseringsuppgifter för Azure Storage. Men för att hämta dessa hemligheter måste appen först autentisera med Key Vault. Den här situationen skapar ett cirkulärt problem: Appen behöver autentiseringsuppgifter för att komma åt Key Vault, men du måste lagra dessa autentiseringsuppgifter på ett säkert sätt. Utan en säker lösning kan det här problemet leda till hårdkodade autentiseringsuppgifter eller osäkra konfigurationer i utvecklingsmiljöer.

• Säker hantering av API-nycklar från tredje part

  När du har hämtat API-nyckeln från Key Vault måste programmet använda den för att anropa en extern tjänst från tredje part. Hantera den här nyckeln med extrem försiktighet:

  • Hårdkoda den aldrig i källkods- eller konfigurationsfiler
  • Logga den aldrig till stdout-, stderr- eller programloggar
  • Behåll det bara i minnet och kom åt det under körning, precis innan det används
  • Ta bort den omedelbart när begäran har slutförts

  Om du inte följer dessa metoder ökar risken för läckage av autentiseringsuppgifter eller obehörig användning.

• Skydda autentiseringsuppgifter för Azure Queue Storage

  Om du vill skriva meddelanden till Azure Queue Storage behöver appen vanligtvis en anslutningssträng eller en token för delad åtkomst. Dessa autentiseringsuppgifter:

  • Måste lagras på en säker plats, till exempel Key Vault
  • Får inte visas i loggar, stackspårningar eller utvecklarverktyg
  • Bör endast nås via säkra driftrutiner
  • Kräv rätt RBAC-konfiguration om du använder hanterad identitet

• Flexibilitet för miljön

  Appen måste köras tillförlitligt i både lokala utvecklings- och molnproduktionsmiljöer med samma kodbas och minimal villkorlig logik.

  Det här kravet innebär:

  • Bädda inte in miljöspecifika hemligheter i koden
  • Växla inte autentiseringsuppgifter eller logiksökvägar manuellt
  • Använda identitetsbaserad autentisering konsekvent i olika miljöer

Azure första autentiseringen med Microsoft Entra ID

I takt med att molnprogram skalas i komplexitet och integreras med fler tjänster blir säker och strömlinjeformad autentisering avgörande. Azure erbjuder en Azure första identitetsmodell via Microsoft Entra ID, vilket möjliggör enhetlig identitetshantering och sömlös integrering med Azure tjänster för säker autentisering utan autentiseringsuppgifter.

I stället för att manuellt hantera hemligheter eller bädda in autentiseringsuppgifter i programkod – en metod som är utsatt för säkerhetsrisker – Microsoft Entra ID gör det möjligt för appar att autentisera på ett säkert sätt med hjälp av hanterade identiteter.

De viktigaste fördelarna med Microsoft Entra-hanterade identiteter är:

• Inga hemligheter i kod

  Program kräver inte längre hårdkodade anslutningssträngar, klienthemligheter eller nycklar.

• Inbyggd identitet för appar

  Azure kan automatiskt tilldela en hanterad identitet till din app, så att den på ett säkert sätt kan komma åt tjänster som Key Vault, Storage och SQL utan extra autentiseringsuppgifter.

• Miljökonsistens

  Samma kod- och identitetsmodell fungerar både i lokal utveckling och i Azure miljöer med hjälp av Azure SDKs.DefaultAzureCredential

Miljöspecifikt identitetsflöde

Program som använder Microsoft Entra-ID för autentisering drar nytta av en flexibel identitetsmodell som fungerar sömlöst i både Azure-värdbaserade och lokala utvecklingsmiljöer. Azure SDKs DefaultAzureCredential ger den här konsekvensen genom att automatiskt välja lämplig identitetsmetod baserat på miljön.

Azure-miljö

När du distribuerar programmet till Azure:

• Programmet får automatiskt en hanterad identitet.
• Azure hanterar tokenutfärdning och livscykel för autentiseringsuppgifter internt, så du behöver inte hantera några hemligheter.
• Programmet får åtkomst till tjänster med hjälp av Role-Based Access Control (RBAC) eller Key Vault åtkomstprinciper.

Lokal utvecklingsmiljö

Under lokal utveckling:

• Ett huvudnamn för tjänsten fungerar som appens identitet.
• Utvecklare autentiserar med hjälp av Azure CLI (az login), miljövariabler eller Visual Studio/VS Code-integreringar.
• Samma programkod körs utan någon ändring – endast identitetskällan ändras.

I båda miljöerna använder Azure SDK:er DefaultAzureCredential, som döljer identitetskällan och automatiskt väljer rätt metod.

Metodtips för säker utveckling

Du kan ange hemligheter som miljövariabler (till exempel via Azure App Inställningar), men den här metoden har nackdelar:

• Du måste replikera hemligheter manuellt i lokala miljöer.
• Det finns en risk för att hemligheter läcker ut i källkontrollen.
• Du kan behöva extra logik för att skilja mellan miljöer.

Använd i stället följande metod:

• Använd Key Vault för att lagra API-nycklar från tredje part och andra hemligheter.
• Tilldela en hanterad identitet till din distribuerade app.
• Använd tjänstens huvudnamn för lokal utveckling och tilldela det samma åtkomsträttigheter.
• Använd DefaultAzureCredential i koden för att abstrahera autentiseringslogik.
• Undvik att lagra eller logga autentiseringsuppgifter.

Autentiseringsflöde i praktiken

Så här fungerar autentisering vid körning:

• Koden skapar en DefaultAzureCredential instans.
• Du använder den här autentiseringsuppgiften för att instansiera en klient (till exempel SecretClient, QueueServiceClient).
• När appen anropar en metod (till exempel get_secret()) använder klienten autentiseringsuppgifterna för att autentisera begäran.
• Azure verifierar identiteten och kontrollerar om den har rätt roll eller princip för att utföra åtgärden.

Det här flödet säkerställer att din app på ett säkert sätt kan komma åt Azure-tjänster utan att bädda in hemligheter i kod- eller konfigurationsfiler. Det gör också att du smidigt kan växla mellan lokal utveckling och molndistribution utan att ändra din autentiseringslogik.