Rekommendationer för identitets- och åtkomsthantering

Gäller för den här checklistan för Azure Well-Architected Framework Security:

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 inkluderar inte bara arbetsbelastningens kanter. 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 lämnat några bevis om vilka de är.

Definitioner 

Rollen för en identitetsprovider

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

Dra nytta av de funktioner 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 i flera klienter varje dag. Microsoft Entra ID är IdP för Azure-molnplattformen.

Autentisering

Autentisering är en process som verifierar identiteter. Den begärde identiteten krävs för att tillhandahålla någon form av verifierbar identifiering. Till 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, och de åtgärder som tillgångar 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åtkomstspåret. 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 i olika syften. Till exempel en slutanvändare som kommer åt 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 personas.

• Åtkomst inifrån och ut. 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. Den här åtkomsten 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:

Fastställa åtgärder för auktorisering

Därefter måste 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 krävs:

• Åtkomst till dataplanet. Åtgärder som utförs i dataplanet orsakar dataöverföring för åtkomst inifrån och ut eller utanför. Till exempel ett program som läser 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.

• Kontrollplansåtkomst. Å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 tillåtas 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 ett 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? Vad skulle påverka systemet när det gäller konfidentialitet, integritet och tillgänglighet om arbetsbelastningsidentiteten komprometteras av en dålig aktör?

Rolltilldelning

En roll är en uppsättning behörigheter som har tilldelats till en identitet. Tilldela roller som bara tillåter att identiteten slutför uppgiften och inte längre. När användarens behörigheter är begränsade till deras jobbkrav är det lättare 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 den potentiella attackytan. Om du endast beviljar de minsta behörigheter som krävs för att utföra specifika uppgifter minskar 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äcker för att bedöma riskfaktorer, identifiera potentiella minskningar och rapportera om riskerna.

Det finns scenarier där användarna 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 negativt påverka både säkerhet och tillförlitlighet.

Kompromiss: En detaljerad metod för åtkomstkontroll 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. Anpassningen leder till komplexitet som ökar förvirringen och gör automatiseringen mer komplex, utmanande och bräcklig. Dessa faktorer påverkar säkerheten negativt.

Bevilja roller som börjar med minsta möjliga behörighet och lägg till mer baserade 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 privilegier 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 ett förebyggande mått och för att kontrollera explosionsradien.

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

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

Även om tid och behörighet är de primära 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 identiteter från tredje part 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 differentiering, 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 azure-underlättande i den här artikeln.

Skydda 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å ditt företag och dess informationssystem. Administrationssäkerhet är ett av de mest kritiska säkerhetsområdena.

För att skydda privilegierad åtkomst mot beslutsamma 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örigheter för befintliga identiteter.

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

• Använd moderna åtkomstprotokoll som lösenordslös 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 i olika miljöer och associera en enda identitet med användaren eller huvudnamnet. Konsekvens av identiteter i molnmiljöer och lokala miljöer minskar de mänskliga felen och de resulterande säkerhetsriskerna. Team i båda miljöerna som hanterar resurser behöver en konsekvent, auktoritativ källa för att uppfylla säkerhetsgarantierna. 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, och detta kan leda till en lyckad kompromiss för ett molnkonto. Utvärdera synkroniseringsstrategin genom att filtrera bort konton som kan lägga till attackytan.

Upprätta processer för att hantera identitetens livscykel

Åtkomsten 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 introducerar operativa processer.

När du kan kan du undvika att använda hemligheter och överväg 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 se till att systemet är granskningsbart. Granskningar verifierar om strategier för att anta intrång ä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 ta hänsyn till risker för användarkonton, 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 de identiteter som har åtkomst till resurser och vilka åtgärder de utför. Du kan använda den informationen för säkerhetsdiagnostik.

Mer information finns i Rekommendationer om 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:

• Microsoft Entra-ID. Anställda och företagsresurser.

• Externt ID för Microsoft Entra. Partner.

• Azure AD B2C. Kunder.

• Microsoft Entra-federationskompatibilitetslista. Federationslösningar från tredje part.

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: Microsoft Entra-ID är en enskild 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 i Microsoft Entra överväger dock risken för att använda anpassade lösningar.

Azure Support öppna protokoll som OAuth2 och OpenID Connect. Vi rekommenderar att du använder dessa standardmekanismer 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 Inbyggda roller i Microsoft Entra.

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

• Genom att tilldela användare till roller kan du styra åtkomsten till Azure-resurser. Mer information finns i Översikt över rollbaserad åtkomstkontroll i Microsoft Entra-ID.

• Du kan använda Privileged Identity Management för att tillhandahålla tidsbaserad och godkännandebaserad rollaktivering för roller som är associerade med identiteter med hög påverkan. Mer information finns i Vad är Privileged Identity Management?.

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. Om du använder tjänstens huvudnamn ökar dock dina hanteringskostnader. 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 själva 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 din princip 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 villkorsstyrd åtkomst för Microsoft Entra genom att konfigurera en åtkomstprincip för som baseras på dina operativa behov.

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

Gruppåtkomsthantering

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 identitetsskydd?.

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 till Microsoft Entra-ID som har hög behörighet i din befintliga Active Directory i Azure. Den här synkroniseringen blockeras i standardkonfigurationen för Microsoft Entra Connect Sync, 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 Connect Sync: Konfigurera filtrering.

Identitetsloggning

Aktivera diagnostikinställningar för Azure-resurser för att generera information som du kan använda som spårningslogg. 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 på 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.

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.

Relaterade länkar

• Självstudie: Automatisera rotationen av en hemlighet för resurser som har två uppsättningar autentiseringsuppgifter
• Självstudie: Uppdatera automatisk rotationsfrekvens för certifikat i Key Vault
• Vad är nytt i Microsoft Entra-ID?
• Inbyggda Microsoft Entra-roller
• Översikt över rollbaserad åtkomstkontroll i Microsoft Entra ID
• Vad är arbetsbelastningsidentiteter?
• Vad är hanterade identiteter för Azure-resurser?
• Villkorlig åtkomst: Användare, grupper och arbetsbelastningsidentiteter
• Microsoft Entra Connect-synkronisering: Konfigurera filtrering

Säkerhetskontrollista

Se den fullständiga uppsättningen rekommendationer.