Hantering av programidentitet och åtkomst
Den här artikeln beskriver överväganden och rekommendationer som programägare och utvecklare kan använda för att utforma identitets- och åtkomsthantering för molnbaserade program.
Om ditt team migrerar eller skapar molnbaserade program måste du överväga autentiserings- och åtkomstkraven för programmen. Dessa krav avgör hur användare autentiserar till program och hur programresurser autentiseras mot varandra, till exempel när ett webbprogram får åtkomst till en SQL-databas.
I designområdet plattformsautomatisering och DevOps rekommenderar vi att ditt programteam övergår arbetsbelastningar till prenumerationsautomater. Som en del av prenumerationsautomatprocessen måste ditt programteam tillhandahålla identitets- och åtkomstkrav till plattformsteamet så att de kan skapa lämpliga prenumerationer. Programägare ansvarar för identitets- och åtkomsthantering för enskilda program. De bör hantera sina program med hjälp av de centraliserade tjänster som plattformsteamet tillhandahåller.
Utformningsbeaktanden
För att minska risken för obehörig åtkomst till dina program bör du ta med följande överväganden i din design.
Det finns flera autentiserings- och auktoriseringsstandarder, till exempel OAuth 2.0, OpenID Connect, JSON-webbtoken (JWT) och SAML (Security Assertion Markup Language). Avgör vilka autentiserings- och auktoriseringsstandarder som ska användas för ditt program.
När du begär en programlandningszon från plattformsteamet kan du se till att de skapar lämpliga prenumerationer genom att ställa följande frågor till dem:
Hur autentiserar slutanvändarna till och kommer åt programmet?
Vem behöver rollbaserad åtkomstkontroll (RBAC) behörighet för resurser och tjänster som programmet använder?
Täcker befintliga inbyggda roller kraven på RBAC-åtkomst för både åtkomst till kontrollplan och dataplan, eller behöver du skapa nya anpassade roller?
Implementerade plattformsteamet några efterlevnadsprinciper som kan orsaka problem med programmet?
Vilka programkomponenter behöver kommunicera med varandra?
Finns det några krav för åtkomst till delade resurser, till exempel Microsoft Entra Domain Services, som distribueras i plattformslandningszonen?
Azure Key Vault och hanterade identiteter
Säkerhetsöverträdelser av offentliga molnresurser kommer ofta från läckta autentiseringsuppgifter som är inbäddade i kod eller annan text. Du kan använda hanterade identiteter och Key Vault för att implementera programmatisk åtkomst och minska risken för stöld av autentiseringsuppgifter.
Om ditt program eller din arbetsbelastning kräver en tjänst för att lagra autentiseringsuppgifter på ett säkert sätt kan du använda Key Vault för att hantera hemligheter, nycklar och certifikat.
För att undvika att ha autentiseringsuppgifter i koden kan du använda hanterade identiteter med virtuella Azure-datorer för att autentisera till alla tjänster som stöder Microsoft Entra-ID-autentisering. Mer information finns i Använda hanterade identiteter för Azure-resurser på en virtuell dator för att hämta en åtkomsttoken.
Hanterade identiteter tillhandahåller ett automatiskt hanterat identitetshuvudnamn som program och resurser använder när de ansluter till resurser som stöder Microsoft Entra-ID-autentisering. Program kan använda hanterade identiteter för att hämta Microsoft Entra-ID-token utan att behöva hantera några autentiseringsuppgifter.
Du kan använda systemtilldelade eller användartilldelade hanterade identiteter.
Det är enkelt att förvirra hur tjänstens huvudnamn och hanterade identiteter får åtkomst till Azure-resurser. Information om skillnaden mellan de två finns i Avmystifiera tjänstens huvudnamn – Hanterade identiteter.
Om möjligt kan du använda hanterade identiteter för att stödja autentisering i stället för att använda tjänstens huvudnamn och Appregistreringar för Microsoft Entra-ID. Du måste ha RBAC-rollerna Programadministratör eller Programutvecklare för att kunna skapa tjänstens huvudnamn och appregistreringar. Dessa privilegierade roller tilldelas vanligtvis till plattformsteamet eller identitetsteamet. Använd hanterade identiteter för att eliminera behovet av att plattformsteamet skapar tjänstens huvudnamn och appregistreringar för ditt programteam.
Du kan använda hanterade identiteter för att autentisera till alla tjänster som stöder Microsoft Entra-autentisering. Alla tjänster stöder dock inte hanterade identiteter för åtkomst till andra tjänster. För vissa tjänster kan det vara nödvändigt att lagra autentiseringsuppgifter. Du bör lagra autentiseringsuppgifter på ett säkert sätt, undvika att dela autentiseringsuppgifter med andra tjänster och följa principen om lägsta behörighet. Mer information finns i Azure-tjänster som kan använda hanterade identiteter för att få åtkomst till andra tjänster.
Du kan använda hanterade identiteter med virtuella Azure-datorer för att autentisera till alla tjänster som stöder Microsoft Entra-ID-autentisering. Mer information finns i Använda hanterade identiteter för Azure-resurser på en virtuell dator för att hämta en åtkomsttoken.
Det finns begränsningar för att flytta resurser med hanterade identiteter mellan prenumerationer och regioner. Du kan till exempel flytta resurser mellan prenumerationer eller regioner för sammanslagning, förvärv eller repatriering av resurser av datasuveränitetsskäl.
Om en Azure-resurs har användartilldelade eller systemtilldelade identiteter kan du inte överföra resursen till en annan Azure-prenumeration eller region. Du måste ta bort de hanterade identiteterna innan du flyttar resursen. Efter flytten måste du återskapa de hanterade identiteterna och tilldela dem till resursen. Mer information finns i Flytta resurser till en ny resursgrupp eller prenumeration.
Om du flyttar en prenumeration från en katalog till en annan bevaras inte hanterade identiteter. Du måste flytta resursen och sedan manuellt återskapa de hanterade identiteterna.
I likhet med rolltilldelningar för användar-RBAC följer du principen om minsta behörighet när du beviljar en hanterad identitet åtkomst till en resurs.
Externa användare
Du kan utvärdera scenarier som omfattar att konfigurera externa användare, kunder eller partner så att de kan komma åt resurser. Avgör om dessa scenarier omfattar Konfigurationer av Microsoft Entra B2B eller Azure Active Directory B2C (Azure AD B2C). Mer information finns i Översikt över Externt ID för Microsoft Entra.
Designrekommendationer
Tänk på följande rekommendationer när du utformar identitets- och åtkomsthantering för dina program.
OpenID Connect
Om programteamet använder CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans) för att distribuera program programmatiskt konfigurerar du OpenID Connect-autentisering till dina Azure-tjänster. OpenID Connect använder en tillfällig, autentiseringsfri token för att autentisera till Azure-tjänster. Mer information finns i Arbetsbelastningsidentitetsfederation.
Om OpenID Connect inte stöds skapar du ett huvudnamn för tjänsten och tilldelar de behörigheter som krävs för att tillåta att infrastruktur eller programkod distribueras. Mer information finns i utbildningsmodulen autentisera din Azure-distributionspipeline med hjälp av tjänstens huvudnamn.
Attributbaserad åtkomstkontroll
Om du vill begränsa åtkomsten ytterligare och förhindra obehörig åtkomst till data använder du attributbaserad åtkomstkontroll (ABAC) där det stöds, till exempel med Azure Blob Storage.
Åtkomst till virtuella datorer
Använd där det är möjligt Microsoft Entra ID-identiteter för att styra åtkomsten till virtuella Azure-datorer. Använd Microsoft Entra-ID i stället för lokal autentisering för att ge åtkomst till virtuella datorer, dra nytta av villkorsstyrd åtkomst i Microsoft Entra, granskningsloggning och Microsoft Entra multifaktorautentisering (MFA). Den här konfigurationen minskar risken för att angripare utnyttjar osäkra lokala autentiseringstjänster. Mer information finns i Logga in på en virtuell Linux-dator i Azure med hjälp av Microsoft Entra ID och OpenSSH och logga in på en virtuell Windows-dator i Azure med microsoft entra-ID, inklusive lösenordslöst.
Microsoft-identitetsplattform
När utvecklare skapar ett molnbaserat program bör de använda Microsoft platforma za identitete för utvecklare som identitetsprovider för sina program. Microsoft platforma za identitete tillhandahåller en standardkompatibel autentiseringstjänst för OpenID Connect som utvecklare kan använda för att autentisera flera identitetstyper, inklusive:
Arbets- eller skolkonton som etablerats via Microsoft Entra-ID
Personliga Microsoft-konton (Skype, Xbox, Outlook.com)
Sociala eller lokala konton med hjälp av Microsoft Entra-ID
Checklistan Microsoft platforma za identitete bästa praxis och rekommendationer ger vägledning om hur du effektivt integrerar programmet med Microsoft platforma za identitete.
Hanterade identiteter
Om du vill aktivera åtkomst mellan Azure-resurser som inte behöver använda autentiseringsuppgifter använder du hanterade identiteter.
Du bör inte dela autentiseringsuppgifter eller hanterade identiteter mellan olika miljöer eller program. Använd till exempel inte identiteter för produktionsresurser och även i utvecklings-/testresurser, inte ens för samma program. Skapa separata autentiseringsuppgifter för varje instans av ett program för att minska sannolikheten för att en komprometterad testinstans påverkar produktionsdata. Separata autentiseringsuppgifter gör det också lättare att återkalla autentiseringsuppgifter när de inte längre krävs.
När det finns ett krav på att använda hanterade identiteter i stor skala använder du en användartilldelad hanterad identitet för varje resurstyp i varje region. Den här metoden förhindrar en omsättning av identiteter. Azure Monitor-agenten kräver till exempel en hanterad identitet på övervakade virtuella Azure-datorer, vilket kan leda till att Microsoft Entra-ID skapar (och tar bort) ett stort antal identiteter. Du kan skapa användartilldelade hanterade identiteter en gång och dela dem på flera virtuella datorer. Använd Azure Policy för att implementera den här rekommendationen.
Key Vault
Du kan använda Key Vault för att hantera hemligheter, nycklar och certifikat som program använder.
Om du vill hantera åtkomst till hemligheter (dataplan) och för administrativ åtkomst (kontrollplan) använder du RBAC.
Om du vill styra programåtkomsten till Key Vault använder du hanterade identiteter.
Du bör använda separata nyckelvalv för varje programmiljö (utveckling, förproduktion, produktion) i varje region. Använd RBAC för att hantera åtkomst till hemligheter, nycklar och certifikat (dataplansåtgärder) och åtkomst till Key Vault (kontrollplan). Distribuera nyckelvalv som har programhemligheter i programmets landningszoner.
Microsoft Entra-programproxy
Om du vill få åtkomst till program som använder lokal autentisering via Microsoft Entra-ID använder du Microsoft Entra-programproxy. Microsoft Entra-programproxy ger säker fjärråtkomst till lokala webbprogram, inklusive program som använder äldre autentiseringsprotokoll. Efter en enkel inloggning till Microsoft Entra-ID kan användarna komma åt både molnbaserade och lokala program via en extern URL eller en intern programportal.
Du kan distribuera Microsoft Entra-programproxy som en enda instans till en Microsoft Entra ID-klientorganisation. Konfigurationen kräver minst rollen Programadministratörsprivilegierad Microsoft Entra-ID. Om din organisation använder prenumerationsdemokratisering som en rolltilldelningsmodell kanske programägare inte har de behörigheter som krävs för att konfigurera Microsoft Entra-programproxy. I det här fallet bör plattformsteamet konfigurera Microsoft Entra-programproxy för programägaren.
Om du använder CI/CD-distributionspipelines med tillräcklig behörighet kan programägare konfigurera Microsoft Entra-programproxy med hjälp av Microsoft Graph API.
Om programmet använder äldre protokoll, till exempel Kerberos, kontrollerar du att programlandningszonen har nätverksanslutning till domänkontrollanter i Microsoft platforma za identitete-prenumerationen.