Dela via

Hantering av programidentitet och åtkomst

  • Artikel

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 prenumerationsförsäljning. 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 Anslut, 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 åtkomstkontrollbehörighet (RBAC) 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 Anslut-autentisering till dina Azure-tjänster. OpenID Anslut använder en tillfällig, autentiseringsfri token för att autentisera till Azure-tjänster. Mer information finns i Arbetsbelastningsidentitetsfederation.

Om OpenID-Anslut inte stöds skapar du ett huvudnamn för tjänsten och tilldelar de behörigheter som krävs för att tillåta distribution av infrastruktur eller programkod. 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 Microsofts identitetsplattform för utvecklare som identitetsprovider för sina program. Microsofts identitetsplattform tillhandahåller en OpenID-Anslut standardkompatibel autentiseringstjänst 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 Microsofts identitetsplattform bästa praxis och rekommendationer ger vägledning om hur du effektivt integrerar programmet med Microsofts identitetsplattform.

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.

  • 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 de programadministratörs- eller globala administratörsprivilegerade Microsoft Entra-ID-rollerna. 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 Microsofts identitetsplattform-prenumerationen.

Nästa steg

Resursorganisation