Rekommendationer för identitets- och åtkomsthantering

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Security:

SE:05 Implementera strikt, villkorsstyrd och granskningsbar identitets- och åtkomsthantering (IAM) för alla arbetsbelastningsanvändare, teammedlemmar och systemkomponenter. Begränsa åtkomsten exklusivt till vid behov. Använd moderna branschstandarder för alla implementeringar av autentisering och auktorisering. Begränsa och noggrant granska åtkomst som inte baseras på identitet.

Den här guiden beskriver rekommendationerna för att autentisera och auktorisera identiteter som försöker komma åt dina arbetsbelastningsresurser.

Ur ett tekniskt kontrollperspektiv är identitet alltid den primära perimetern. Det här omfånget omfattar inte bara kanterna på din arbetsbelastning. Den innehåller även enskilda komponenter som finns i din arbetsbelastning. Vanliga identiteter är:

  • Människor. Programanvändare, administratörer, operatörer, granskare och dåliga aktörer.

  • System. Arbetsbelastningsidentiteter, hanterade identiteter, API-nycklar, tjänstens huvudnamn och Azure-resurser.

  • Anonym. Entiteter som inte har lagt fram några bevis om vilka de är.

Definitioner 

Termer Definition
Autentisering (AuthN) En process som verifierar att en identitet är vem eller vad den säger att den är.
Auktorisering (AuthZ) En process som verifierar om en identitet har behörighet att utföra en begärd åtgärd.
Villkorlig åtkomst En uppsättning regler som tillåter åtgärder baserat på angivna villkor.
IdP En identitetsprovider, till exempel Microsoft Entra-ID.
Persona En jobbfunktion eller en rubrik som har en uppsättning ansvarsområden och åtgärder.
I förväg delade nycklar En typ av hemlighet som delas mellan en leverantör och konsument och som används via en säker och överenskommen mekanism.
Resursidentitet En identitet som definierats för molnresurser som hanteras av plattformen.
Roll En uppsättning behörigheter som definierar vad en användare eller grupp kan göra.
Omfång Olika nivåer i organisationshierarkin där en roll tillåts att fungera. Även en grupp funktioner i ett system.
Säkerhetsobjekt En identitet som ger behörigheter. Det kan vara en användare, en grupp eller ett huvudnamn för tjänsten. Alla gruppmedlemmar får samma åtkomstnivå.
Användaridentitet En identitet för en person, till exempel en anställd eller en extern användare.
Arbetsbelastningsidentitet En systemidentitet för ett program, en tjänst, ett skript, en container eller en annan komponent i en arbetsbelastning som används för att autentisera sig mot andra tjänster och resurser.

Anteckning

En identitet kan grupperas med andra liknande identiteter under en överordnad som kallas säkerhetsobjekt. En säkerhetsgrupp är ett exempel på ett säkerhetsobjekt. Den här hierarkiska relationen förenklar underhållet och förbättrar konsekvensen. Eftersom identitetsattribut inte hanteras på individuell nivå minskar också risken för fel. I den här artikeln omfattar termen identitet säkerhetsobjekt.

Identitetsproviderns roll

En identitetsprovider (IdP) är en molnbaserad tjänst som lagrar och hanterar användare som digitala identiteter.

Dra nytta av funktionerna som tillhandahålls av en betrodd IdP för din identitets- och åtkomsthantering. Implementera inte anpassade system för att ersätta en IdP. IdP-system förbättras ofta baserat på de senaste attackvektorerna genom att samla in miljarder signaler över flera klienter varje dag. Microsoft Entra ID är IdP för Azure-molnplattformen.

Autentisering

Autentisering är en process som verifierar identiteter. Den begärande identiteten krävs för att tillhandahålla någon form av verifierbar identifiering. Exempel:

  • Ett användarnamn och lösenord.

  • En i förväg delad hemlighet, till exempel en API-nyckel som ger åtkomst.

  • En SAS-token (signatur för delad åtkomst).

  • Ett certifikat som används i ömsesidig TLS-autentisering.

Så mycket som möjligt bör verifieringsprocessen hanteras av din IdP.

Auktorisering

Auktorisering är en process som tillåter eller nekar åtgärder som begärs av den verifierade identiteten. Åtgärden kan vara i drift eller relaterad till resurshantering.

Auktorisering kräver att du tilldelar behörigheter till identiteterna, vilket du behöver göra med hjälp av de funktioner som tillhandahålls av din IdP.

Viktiga designstrategier

För att få en holistisk vy över identitetsbehoven för en arbetsbelastning måste du katalogisera flöden, arbetsbelastningstillgångar och personas, samt de åtgärder som tillgångarna och personas kommer att utföra. Din strategi måste omfatta alla användningsfall som hanterar de flöden som når arbetsbelastningen eller dess komponenter (extern åtkomst) och flöden som når ut från arbetsbelastningen till andra källor (inifrån och ut-åtkomst).

Varje användningsfall har förmodligen en egen uppsättning kontroller som du behöver utforma med ett tänkesätt som förutsätter intrång. Baserat på identitetskraven för användningsfallet eller personanvändarna identifierar du de villkorsstyrda valen. Undvik att använda en lösning för alla användningsfall. Omvänt bör kontrollerna inte vara så detaljerade att du inför onödiga hanteringskostnader.

Du måste logga identitetsåtkomstloggen. Detta hjälper dig att verifiera kontrollerna och du kan använda loggarna för efterlevnadsgranskningar.

Fastställa alla identiteter för autentisering

  • Åtkomst utanför. Din identitetsdesign måste autentisera alla användare som har åtkomst till arbetsbelastningen för olika syften. Till exempel en slutanvändare som har åtkomst till programmet genom att anropa API:er.

    På detaljerad nivå kan komponenter i arbetsbelastningen också behöva åtkomst utifrån. Till exempel en operatör som behöver åtkomst via portalen eller åtkomst till beräkningen för att köra kommandon.

    Båda är exempel på användaridentiteter som har olika profiler.

  • Inifrån och ut-åtkomst. Programmet måste ha åtkomst till andra resurser. Du kan till exempel läsa från eller skriva till dataplattformen, hämta hemligheter från det hemliga arkivet och logga telemetri till övervakningstjänster. Den kan till och med behöva åtkomst till tjänster från tredje part. Dessa åtkomstbehov kräver arbetsbelastningsidentitet, vilket gör att programmet kan autentisera sig mot de andra resurserna.

    Konceptet gäller på komponentnivå. I följande exempel kan containern behöva åtkomst till distributionspipelines för att få dess konfiguration. Dessa åtkomstbehov kräver resursidentitet.

Alla dessa identiteter ska autentiseras av din IdP.

Här är ett exempel på hur identitet kan implementeras i en arkitektur:

Diagram som visar hur identitet kan implementeras i en arkitektur.

Fastställa åtgärder för auktorisering

Därefter behöver du veta vad varje autentiserad identitet försöker göra så att dessa åtgärder kan auktoriseras. Åtgärderna kan delas upp med den typ av åtkomst som de behöver:

  • Dataplansåtkomst. Åtgärder som utförs i dataplanet orsakar dataöverföring för åtkomst inifrån och ut eller utanför. Ett program läser till exempel data från en databas och skriver data till en databas, hämtar hemligheter eller skriver loggar till en övervakningsmottagare. På komponentnivå betraktas beräkning som hämtar eller push-överför avbildningar till eller från ett register som dataplansåtgärder.

  • Åtkomst till kontrollplan. Åtgärder som utförs i kontrollplanet gör att en Azure-resurs skapas, ändras eller tas bort. Till exempel ändringar i resursegenskaper.

Program riktar vanligtvis in sig på dataplansåtgärder, medan åtgärder ofta har åtkomst till både kontroll- och dataplan. Observera de operativa åtgärder som kan utföras på resursen för att identifiera auktoriseringsbehov. Information om tillåtna åtgärder för varje resurs finns i Åtgärder för Azure-resursprovider.

Ange rollbaserad auktorisering

Auktorisera åtgärder som ska tillåtas baserat på varje identitets ansvar. En identitet får inte göra mer än den behöver göra. Innan du anger auktoriseringsregler måste du ha en tydlig förståelse för vem eller vad som gör begäranden, vad den rollen tillåts göra och i vilken utsträckning den kan göra det. Dessa faktorer leder till val som kombinerar identitet, roll och omfång.

Tänk dig en arbetsbelastningsidentitet som exempel. Programmet måste ha dataplansåtkomst till databasen, så läs- och skrivåtgärder till dataresursen måste tillåtas. Men behöver programmet kontrollplansåtkomst till det hemliga arkivet? Om arbetsbelastningsidentiteten komprometteras av en dålig aktör, vad skulle då påverka systemet när det gäller konfidentialitet, integritet och tillgänglighet?

Rolltilldelning

En roll är en uppsättning behörigheter som tilldelas till en identitet. Tilldela roller som endast tillåter att identiteten slutför uppgiften och inte längre. När användarens behörigheter är begränsade till sina jobbkrav är det enklare att identifiera misstänkt eller obehörigt beteende i systemet.

Ställ frågor som dessa:

  • Är skrivskyddad åtkomst tillräckligt?
  • Behöver identiteten behörighet för att ta bort resurser?

Om du begränsar den åtkomstnivå som användare, program eller tjänster har till Azure-resurser minskar risken för angrepp. Om du endast beviljar de minsta behörigheter som krävs för att utföra specifika uppgifter minskas risken för en lyckad attack eller obehörig åtkomst avsevärt. Säkerhetsteam behöver till exempel bara skrivskyddad åtkomst till säkerhetsattribut för alla tekniska miljöer. Den nivån är tillräcklig för att bedöma riskfaktorer, identifiera potentiella minskningar och rapportera om riskerna.

Det finns scenarier där användare behöver mer åtkomst på grund av organisationsstrukturen och teamorganisationen. Det kan finnas en överlappning mellan olika roller, eller så kan enskilda användare utföra flera standardroller. I det här fallet använder du flera rolltilldelningar som baseras på affärsfunktionen i stället för att skapa en anpassad roll för var och en av dessa användare. Det gör rollerna enklare att hantera.

Undvik behörigheter som specifikt refererar till enskilda resurser eller användare. Detaljerade och anpassade behörigheter skapar komplexitet och förvirring eftersom de inte vidarebefordrar avsikten till nya resurser som liknar dem. Detta kan skapa en komplex äldre konfiguration som är svår att underhålla och som påverkar både säkerhet och tillförlitlighet negativt.

Kompromiss: En detaljerad åtkomstkontrollmetod möjliggör bättre granskning och övervakning av användaraktiviteter.

En roll har också ett associerat omfång. Rollen kan användas i den tillåtna hanteringsgruppen, prenumerationen, resursgruppen eller resursomfånget eller i ett annat anpassat omfång. Även om identiteten har en begränsad uppsättning behörigheter är det riskabelt att utvidga omfånget till att omfatta resurser som ligger utanför identitetens jobbfunktion. Läsåtkomst till all källkod och alla data kan till exempel vara farlig och måste kontrolleras.

Du tilldelar roller till identiteter med hjälp av rollbaserad åtkomstkontroll (RBAC). Använd alltid RBAC som tillhandahålls av IdP för att dra nytta av funktioner som gör att du kan tillämpa åtkomstkontroll konsekvent och återkalla den noggrant.

Använd inbyggda roller. De är utformade för att täcka de flesta användningsfall. Anpassade roller är kraftfulla och ibland användbara, men du bör reservera dem för scenarier där inbyggda roller inte fungerar. Anpassning leder till komplexitet som ökar förvirringen och gör automatiseringen mer komplex, utmanande och bräcklig. Alla dessa faktorer påverkar säkerheten negativt.

Bevilja roller som börjar med minsta möjliga behörighet och lägg till mer baserat på dina drift- eller dataåtkomstbehov. Dina tekniska team måste ha tydlig vägledning för att implementera behörigheter.

Om du vill ha detaljerad kontroll över RBAC lägger du till villkor för rolltilldelningen baserat på kontext, till exempel åtgärder och attribut.

Gör alternativ för villkorlig åtkomst

Ge inte alla identiteter samma åtkomstnivå. Basera dina beslut på två huvudfaktorer:

  • Tid. Hur länge identiteten har åtkomst till din miljö.

  • Behörighet. Behörighetsnivån.

Dessa faktorer utesluter inte varandra. En komprometterad identitet som har fler behörigheter och obegränsad åtkomsttid kan få mer kontroll över systemet och data eller använda den åtkomsten för att fortsätta att ändra miljön. Begränsa dessa åtkomstfaktorer både som en förebyggande åtgärd och för att kontrollera sprängradien.

  • Jit-metoder (Just-in-Time) ger endast de behörigheter som krävs när de behövs.

  • JEA (Just Enough Access) ger endast de behörigheter som krävs.

Även om tid och privilegier är de viktigaste faktorerna finns det andra villkor som gäller. Du kan till exempel också använda enheten, nätverket och platsen som åtkomsten kommer från för att ange principer.

Använd starka kontroller som filtrerar, identifierar och blockerar obehörig åtkomst, inklusive parametrar som användaridentitet och plats, enhetens hälsotillstånd, arbetsbelastningskontext, dataklassificering och avvikelser.

Din arbetsbelastning kan till exempel behöva nås av tredjepartsidentiteter som leverantörer, partner och kunder. De behöver lämplig åtkomstnivå i stället för de standardbehörigheter som du anger för heltidsanställda. Tydlig differentiering av externa konton gör det enklare att förhindra och identifiera attacker som kommer från dessa vektorer.

Ditt val av IdP måste kunna tillhandahålla den differentieringen, tillhandahålla inbyggda funktioner som beviljar behörigheter baserat på minsta möjliga behörighet och tillhandahålla inbyggd hotinformation. Detta omfattar övervakning av åtkomstbegäranden och inloggningar. Azure IdP är Microsoft Entra-ID. Mer information finns i avsnittet om förenklade Azure-lösningar i den här artikeln.

Konton med kritisk påverkan

Administrativa identiteter medför några av de största säkerhetsriskerna eftersom de uppgifter de utför kräver privilegierad åtkomst till en bred uppsättning av dessa system och program. Kompromettering eller missbruk kan ha en skadlig effekt på din verksamhet och dess informationssystem. Administrationssäkerhet är ett av de viktigaste säkerhetsområdena.

För att skydda privilegierad åtkomst mot bestämda angripare måste du använda en fullständig och genomtänkt metod för att isolera dessa system från risker. Här följer några strategier:

  • Minimera antalet konton med kritisk påverkan.

  • Använd separata roller i stället för att höja behörigheterna för befintliga identiteter.

  • Undvik permanent eller stående åtkomst med hjälp av JIT-funktionerna i din IdP. Följ en process för nödåtkomst för att få en glasbrytsituation.

  • Använd moderna åtkomstprotokoll som lösenordsfri autentisering eller multifaktorautentisering. Externalisera dessa mekanismer till din IdP.

  • Framtvinga viktiga säkerhetsattribut med hjälp av principer för villkorlig åtkomst.

  • Inaktivera administrativa konton som inte används.

Använd en enda identitet mellan miljöer och associera en enda identitet med användaren eller huvudkontot. Konsekvens av identiteter i molnmiljöer och lokala miljöer minskar mänskliga fel och resulterande säkerhetsrisker. Team i båda miljöerna som hanterar resurser behöver en konsekvent, auktoritativ källa för att uppfylla säkerhetsgarantier. Arbeta med ditt centrala identitetsteam för att säkerställa att identiteter i hybridmiljöer synkroniseras.

Risk: Det finns en risk som är associerad med synkronisering av identiteter med hög behörighet. En angripare kan få fullständig kontroll över lokala tillgångar, vilket kan leda till att ett molnkonto komprometteras. Utvärdera synkroniseringsstrategin genom att filtrera bort konton som kan läggas till på attackytan.

Upprätta processer för att hantera identitetslivscykeln

Åtkomst till identiteter får inte vara längre än de resurser som identiteterna har åtkomst till. Se till att du har en process för att inaktivera eller ta bort identiteter när det finns ändringar i teamstrukturen eller programvarukomponenterna.

Den här vägledningen gäller för källkontroll, data, kontrollplan, arbetsbelastningsanvändare, infrastruktur, verktyg, övervakning av data, loggar, mått och andra entiteter.

Upprätta en process för identitetsstyrning för att hantera livscykeln för digitala identiteter, högprivilegierade användare, externa/gästanvändare och arbetsbelastningsanvändare. Implementera åtkomstgranskningar för att säkerställa att deras arbetsbelastningsbehörigheter tas bort när identiteter lämnar organisationen eller teamet.

Skydda identitetsbaserade hemligheter

Programhemligheter som i förväg delade nycklar bör betraktas som sårbara punkter i systemet. Om leverantören eller konsumenten komprometteras i tvåvägskommunikationen kan betydande säkerhetsrisker införas. Dessa nycklar kan också vara betungande eftersom de inför operativa processer.

När du kan du undvika att använda hemligheter och överväga att använda identitetsbaserad autentisering för användaråtkomst till själva programmet, inte bara till dess resurser.

Följande lista innehåller en sammanfattning av vägledningen. Mer information finns i Rekommendationer för programhemligheter.

  • Behandla dessa hemligheter som entiteter som kan hämtas dynamiskt från ett hemligt arkiv. De bör inte hårdkodas i din programkod, IaC-skript, distributionspipelines eller i någon annan artefakt.

  • Se till att du har möjlighet att återkalla hemligheter.

  • Använd operativa metoder som hanterar uppgifter som nyckelrotation och förfallodatum.

Information om rotationsprinciper finns i Automatisera rotationen av en hemlighet för resurser som har två uppsättningar autentiseringsuppgifter och Självstudie: Uppdatera automatisk rotationsfrekvens för certifikat i Key Vault.

Skydda utvecklingsmiljöer

Alla kod- och skript, pipelineverktyg och källkontrollsystem bör betraktas som arbetsbelastningstillgångar. Åtkomst till skrivningar ska vara gated med automatisering och peer-granskning. Läsåtkomst till källkod bör begränsas till roller som behöver veta. Kodlagringsplatser måste ha versionshantering, och säkerhetskodgranskningar av peer-datorer måste vara en vanlig metod som är integrerad med utvecklingslivscykeln. Du måste ha en process på plats som söker igenom resurser regelbundet och identifierar de senaste säkerhetsriskerna.

Använd arbetsbelastningsidentiteter för att ge åtkomst till resurser från distributionsmiljöer, till exempel GitHub.

Underhålla en spårningslogg

En aspekt av identitetshantering är att säkerställa att systemet är granskningsbart. Granskningar verifierar om strategier för att anta överträdelser är effektiva. Genom att underhålla en spårningslogg kan du:

  • Kontrollera att identiteten autentiseras med stark autentisering. Alla åtgärder måste kunna spåras för att förhindra avvisningsattacker.

  • Identifiera svaga eller saknade autentiseringsprotokoll och få insyn i och insikter om användarinloggningar och programinloggningar.

  • Utvärdera åtkomsten från identiteter till arbetsbelastningen baserat på säkerhets - och efterlevnadskrav och överväg användarkontorisk, enhetsstatus och andra kriterier och principer som du anger.

  • Spåra förlopp eller avvikelse från efterlevnadskrav.

De flesta resurser har åtkomst till dataplanet. Du måste känna till identiteterna som har åtkomst till resurser och de åtgärder som de utför. Du kan använda den informationen för säkerhetsdiagnostik.

Mer information finns i Rekommendationer för säkerhetsövervakning och hotanalys.

Azure-underlättande

Vi rekommenderar att du alltid använder moderna autentiseringsprotokoll som tar hänsyn till alla tillgängliga datapunkter och använder villkorlig åtkomst. Microsoft Entra ID tillhandahåller identitets- och åtkomsthantering i Azure. Den täcker hanteringsplanet i Azure och är integrerat med dataplan för de flesta Azure-tjänster. Microsoft Entra-ID är den klientorganisation som är associerad med arbetsbelastningsprenumerationen. Den spårar och hanterar identiteter och deras tillåtna behörigheter och förenklar den övergripande hanteringen för att minimera risken för tillsyn eller mänskliga fel.

Dessa funktioner integreras internt i samma Microsoft Entra identitets- och behörighetsmodell för användarsegment:

Du kan använda Microsoft Entra-ID för autentisering och auktorisering av anpassade program via Microsoft Authentication Library (MSAL) eller plattformsfunktioner, till exempel autentisering för webbappar. Den omfattar hanteringsplanet i Azure, dataplan för de flesta Azure-tjänster och integreringsfunktioner för dina program.

Du kan hålla dig uppdaterad genom att besöka Nyheter i Microsoft Entra-ID.

Kompromiss: Microsof Microsoft Entra-ID är en felpunkt precis som andra grundläggande tjänster. Det finns ingen lösning förrän avbrottet har åtgärdats av Microsoft. Den omfattande funktionsuppsättningen av Microsoft Entra överväger dock risken för att använda anpassade lösningar.

Azure stöder öppna protokoll som OAuth2 och OpenID Connect. Vi rekommenderar att du använder de här standardmekanismerna för autentisering och auktorisering i stället för att utforma dina egna flöden.

Azure RBAC

Azure RBAC representerar säkerhetsobjekt i Microsoft Entra-ID. Alla rolltilldelningar görs via Azure RBAC. Dra nytta av inbyggda roller som ger de flesta av de behörigheter som du behöver. Mer information finns i Microsoft Entra inbyggda roller.

Här är några användningsfall:

Mer information om RBAC finns i Metodtips för Azure RBAC.

Information om attributbaserade kontroller finns i Vad är Azure ABAC?.

Arbetsbelastningsidentitet

Microsoft Entra ID kan hantera programmets identitet. Tjänstens huvudnamn som är associerat med programmet kan diktera dess åtkomstomfång.

Mer information finns i Vad är arbetsbelastningsidentiteter?.

Tjänstens huvudnamn abstraheras också när du använder en hanterad identitet. Fördelen är att Azure hanterar alla autentiseringsuppgifter för programmet.

Alla tjänster stöder inte hanterade identiteter. Om du inte kan använda hanterade identiteter kan du använda tjänstens huvudnamn. Men om du använder tjänstens huvudnamn ökar hanteringskostnaderna. Mer information finns i Vad är hanterade identiteter för Azure-resurser?

Resursidentitet

Begreppet hanterade identiteter kan utökas till Azure-resurser. Azure-resurser kan använda hanterade identiteter för att autentisera sig till andra tjänster som stöder Microsoft Entra autentisering. Mer information finns i Azure-tjänster som kan använda hanterade identiteter för att få åtkomst till andra tjänster.

Villkorliga åtkomstprinciper

Villkorsstyrd åtkomst beskriver principen för ett åtkomstbeslut. Om du vill använda villkorlig åtkomst måste du förstå de begränsningar som krävs för användningsfallet. Konfigurera Microsoft Entra villkorlig åtkomst genom att konfigurera en åtkomstprincip för som baseras på dina operativa behov.

Mer information finns i Villkorlig åtkomst: Användare, grupper och arbetsbelastningsidentiteter.

Hantering av gruppåtkomst

I stället för att bevilja behörigheter till specifika användare tilldelar du åtkomst till grupper i Microsoft Entra-ID. Om det inte finns någon grupp kan du samarbeta med ditt identitetsteam för att skapa en. Du kan sedan lägga till och ta bort gruppmedlemmar utanför Azure och se till att behörigheterna är aktuella. Du kan också använda gruppen för andra ändamål, till exempel e-postlistor.

Mer information finns i Säker åtkomstkontroll med hjälp av grupper i Microsoft Entra-ID.

Hotidentifiering

Microsoft Entra ID Protection kan hjälpa dig att identifiera, undersöka och åtgärda identitetsbaserade risker. Mer information finns i Vad är Identity Protection?.

Hotidentifiering kan ske i form av att reagera på en avisering om misstänkt aktivitet eller proaktivt söka efter avvikande händelser i aktivitetsloggar. Användar- och entitetsbeteendeanalys (UEBA) i Microsoft Sentinel gör det enkelt att identifiera misstänkta aktiviteter. Mer information finns i Identifiera avancerade hot med UEBA.

Hybridsystem

Synkronisera inte konton i Azure till Microsoft Entra-ID som har hög behörighet i din befintliga Active Directory. Den här synkroniseringen blockeras i standardkonfigurationen Microsoft Entra Anslut synkronisering, så du behöver bara bekräfta att du inte har anpassat den här konfigurationen.

Information om filtrering i Microsoft Entra-ID finns i Microsoft Entra Anslut synkronisering: Konfigurera filtrering.

Identitetsloggning

Aktivera diagnostikinställningar på Azure-resurser för att generera information som du kan använda som granskningslogg. Diagnostikinformationen visar vilka identiteter som försöker komma åt vilka resurser och resultatet av dessa försök. De insamlade loggarna skickas till Azure Monitor.

Kompromiss: Loggning medför kostnader på grund av den datalagring som används för att lagra loggarna. Det kan också orsaka prestandapåverkan, särskilt på koden och loggningslösningar som du lägger till i programmet.

Exempel

I följande exempel visas en identitetsimplementering. Olika typer av identiteter används tillsammans för att tillhandahålla de åtkomstnivåer som krävs.

Diagram som visar en identitetsimplementering.

Identitetskomponenter

  • Systemhanterade identiteter. Microsoft Entra-ID ger åtkomst till tjänstdataplan som inte möter användare, till exempel Azure Key Vault och datalager. Dessa identiteter styr också åtkomsten via RBAC till Azure-hanteringsplanet för arbetsbelastningskomponenter, distributionsagenter och teammedlemmar.

  • Arbetsbelastningsidentiteter. Programtjänsterna i aks-klustret (Azure Kubernetes Service) använder arbetsbelastningsidentiteter för att autentisera sig mot andra komponenter i lösningen.

  • Hanterade identiteter. Systemkomponenter i klientrollen använder systemhanterade identiteter, inklusive byggagenter.

  • Mänskliga identiteter. Användar- och operatörsautentisering delegeras till Microsoft Entra-ID eller Microsoft Entra-ID (internt, B2B eller B2C).

Säkerheten för i förväg delade hemligheter är viktig för alla program. Azure Key Vault tillhandahåller en säker lagringsmekanism för dessa hemligheter, inklusive Redis och hemligheter från tredje part.

En rotationsmekanism används för att säkerställa att hemligheter inte komprometteras. Token för Microsofts identitetsplattform implementering av OAuth 2 och OpenID Connect används för att autentisera användare.

Azure Policy används för att säkerställa att identitetskomponenter som Key Vault använder RBAC i stället för åtkomstprinciper. JIT och JEA ger traditionella stående behörigheter för mänskliga operatörer.

Åtkomstloggar aktiveras för alla komponenter via Azure Diagnostics eller via kod för kodkomponenter.

Säkerhetskontrollista

Se den fullständiga uppsättningen rekommendationer.

Säkerhetskontrollista