Dela via

Rekommendationer för identitets- och åtkomsthantering

  • Artikel

Gäller för den här checklisterekommendationen för Power Platform Välstrukturerad säkerhet:

SE:05 Implementera strikt och villkorlig granskningsbar identitet- och åtkomsthantering (IAM) för arbetsbelastningens alla användare, teammedlemmar och systemkomponenter. Begränsa åtkomsten till enbart det som behövs. Använd de modernaste branschstandarderna för alla implementeringar av autentisering och auktorisering. Begränsa och granska rigoröst åtkomst som inte bygger på identitet.

Den här guider beskriver rekommendationerna för autentisering och auktorisering av identiteter som försöker få åtkomst till arbetsbelastningsresurserna.

Ur ett tekniskt kontrollperspektiv är identitet alltid det primära området. Den här omfattningen omfattar inte bara arbetsbelastningens utkanter. Den innehåller även enskilda komponenter som finns i arbetsbelastningen.

Typiska identiteter inkluderar:

  • Människor. Programanvändare, administratörer, operatörer, granskare och skadliga aktörer.
  • System. Arbetsbelastningsidentiteter, hanterade identiteter, API-nycklar, tjänsthuvudkonton och Azure-resurser.
  • Anonyma. Entiteter som inte har angett information om vilka de är.

Definitioner

Villkor Definition
Autentisering (AuthN) En process som bekräftar att en identitet är den eller det som den säger att den är.
Auktorisering (AuthZ) En process som bekräftar om en identitet har behörighet att utföra en begärd åtgärd.
Villkorsstyrd åtkomst En uppsättning regler som tillåter åtgärder som bygger på angivna villkor.
IdP En identitetsprovider, såsom Microsoft Entra ID.
Profil En befattning eller en titel som har en uppsättning ansvarsområden och åtgärder.
Fördelade nycklar En hemlighetstyp som delas mellan en provider och konsument och används genom en säker och avtalad mekanism.
Resursidentitet En identitet definierad för molnresurser som plattformen hanterar.
Roll En uppsättning behörigheter som anger vad en användare eller grupp får göra.
Definitionsområde Olika organisationshierarkinivåer där en roll får utföra åtgärder. Även en grupp funktioner i ett system.
Säkerhetsobjekt En identitet som ger behörigheter. Den kan vara en användare, en grupp eller ett tjänsthuvudkonto. Alla gruppmedlemmar får samma åtkomstnivå.
Användaridentitet Identitet för en person, såsom en anställd eller extern användare.
Arbetsbelastningsidentitet En systemidentitet för ett program, en tjänst, ett skript, en behållare eller någon annan komponent i en arbetsbelastning som används till att autentisera sig själv för andra tjänster och resurser.

Kommentar

En identitet kan grupperas med andra liknande identiteter under en överordnad identitet kallad säkerhetsobjekt. En säkerhetsgrupp är ett exempel på ett säkerhetsobjekt. Den här hierarkiska relationen förenklar underhåll och förbättrar enhetligheten. Eftersom identitetsattribut inte hanteras på enskild nivå minskar även risken för fel. I den här artikeln inkluderar termen identitet säkerhetsobjekt.

Microsoft Entra ID som identitetsprovider för Power Platform

Alla Power Platform-produkter använder Microsoft Entra ID (tidigare Azure Active Directory eller Azure AD) för identitets- och åtkomsthantering. Entra ID gör det möjligt för organisationer att skydda och hantera identitet för sina hybrid- och flermolnmiljöer. Entra ID är även viktigt för att hantera verksamhetens gäster som vill få åtkomst till Power Platform-resurser. Power Platform använder även Entra ID till att hantera andra program som måste integrera med Power Platform API:er genom tjänsthuvudkontots funktioner. Genom att använda Entra ID kan Power Platform använda mer avancerade säkerhetsfunktioner i Entra ID såsom villkorsstyrd åtkomst och kontinuerlig tillgänglighetskontroll.

Autentisering

Autentisering är en process som verifierar identiteter. Den begärande identiteten krävs för att ge någon form av kontrollerbar identifiering. Till exempel:

  • Ett användarnamn och lösenord.
  • En fördelad kod, såsom en API-nyckel som ger åtkomst.
  • En token för delad åtkomstsignatur (SAS)
  • Ett certifikat som används i Transport Layer Security (TLS) för ömsesidig autentisering.

Power Platform autentisering innebär en sekvens av förfrågningar, svar och omdirigerar mellan användarens webbläsare och Power Platform eller Azure-tjänster. Sekvensen följer Microsoft Entra ID autentiseringskod som beviljar flödet.

Att ansluta till och autentisera till en datakälla görs fristående från autentisering till en Power Platform-tjänst. Mer information: Ansluta till och autentisera för datakällor.

Auktorisering

Power Platform använder Microsoft Entra ID Microsoft Identity Platform för auktorisering av alla API-anrop med industristandard OAuth 2.0-protokoll.

Viktiga designstrategier

Om du vill förstå arbetsbelastningens identitetsbehov måste du ange användar- och systemflöden, arbetsbelastningsresurser och profiler, samt vilka åtgärder som de vidtar.

Varje användningsfall har förmodligen en egen uppsättning kontroller som du måste utforma genom att anta överträdelse. Identifiera de villkorliga alternativen grundade på användningsfallets eller profilens identitetskrav. Undvik att använda en lösning för alla användningsfall. Omvänt får kontrollerna inte vara så detaljerade att du ökar onödigt hanteringsarbete.

Du måste logga identitetsåtkomsten. Det här validerar kontrollerna och du kan använda loggarna till efterlevnadsgranskning.

Fastställ alla identiteter för autentisering

Åtkomst utifrån och in. Power Platform autentisering innebär en sekvens av förfrågningar, svar och omdirigerar mellan användarens webbläsare och Power Platform eller Azure-tjänster. Sekvensen följer Microsoft Entra ID autentiseringskod som beviljar flödet. Power Platform autentiserar automatiskt alla användare som har olika syften för åtkomst till arbetsbelastningen.

Åtkomst inifrån och ut. Arbetsbelastning måste ha åtkomst till andra resurser. Till exempel läsa från eller skriva till dataplattformen, hämta hemligheter från hemlighetslagringen och logga telemetri till övervakningstjänster. Den måste till och med få åtkomst till tjänster från tredje part. Allt det här är arbetsbelastningens identitetskrav. Du måste dock även ta hänsyn till resursidentitetskraven. Till exempel hur distributionspipelines körs och autentiseras.

Fastställa auktoriseringsåtgärder

Sedan måste du känna till vad varje autentiserad identitet försöker göra så att sådana åtgärder kan auktoriseras. Åtgärderna kan delas in i vilken åtkomsttyp de kräver:

  • Dataplanåtkomst. Åtgärder som vidtas i dataplanen orsakar dataöverföring. Till exempel ett program som läser eller skriver data från Microsoft Dataverse eller skriver loggar i Application Insights.

  • Kontrollplanåtkomst. Åtgärder som vidtas i kontrollplanet orsakar att en Power Platform-resurs skapas, ändras eller tas bort. Till exempel ändrade miljöegenskaper eller att skapa en datapolicy.

Program inriktar sig oftast på åtgärder i dataplanet, medan åtgärder ofta har åtkomst till både kontroll- och dataplaner.

Tillhandahåll rollbaserad auktorisering

Auktorisera åtgärder som tillåts enligt varje identitets ansvar. En identitet får inte tillåtas göra mer än den måste göra. Innan du anger auktoriseringsregler måste du tydligt förstå vem eller vad som begär, vad den rollen får göra och i vilken utsträckning den kan göra det. Dessa faktorer leder till val som kombinerar identitet, roll och omfattning.

Tänk på följande:

  • Måste arbetsbelastningen ha dataplanåtkomst till Dataverse för både läs- och skrivbehörighet?
  • Kräver arbetsbelastningen även åtkomst till miljöegenskaper?
  • Om identiteten avslöjas av en skadlig aktör, vilka effekter får det för systemets sekretess, integritet och tillgänglighet?
  • Kräver arbetsbelastningen permanent åtkomst eller kan villkorsstyrd åtkomst övervägas?
  • Utför arbetsbelastningen åtgärder som kräver administrativa/utökad behörigheter?
  • Hur interagerar arbetsbelastningen med tjänster från tredje part?
  • Har du krav på enkel inloggning (SSO) för intelligenta programarbetsbelastningar, till exempel agenter?
  • Fungerar agenter i oautentiserat läge, autentiserat läge eller båda?

Rolltilldelning

En roll är en uppsättning behörigheter tilldelade en identitet. Tilldela roller som endast tillåter att identiteten slutför uppgiften och inget mer. När användarens behörighet är begränsad till jobbkraven är det lättare att identifiera misstänkt eller obehörigt beteende i systemet.

Ställ frågor som dessa:

  • Räcker det med skrivskyddad åtkomst?
  • Kräver identiteten behörighet för att ta bort resurser?
  • Kräver rollen bara åtkomst till posterna den skapade?
  • Grundas hierarkisk åtkomst på att affärsenheten där användaren finns krävs?
  • Kräver rollen administratörsbehörighet eller utökade behörigheter?
  • Kräver rollen permanent åtkomst till dessa behörigheter?
  • Vad händer om användaren byter jobb?

Om du begränsar åtkomstnivån för användare, program eller tjänster minskar risken för angrepp. Om du endast ger den lägsta behörighet som krävs för att utföra specifika uppgifter minskar risken för lyckade angrepp eller obehörig åtkomst betydligt. Utvecklare behöver till exempel endast utvecklaråtkomst till utvecklingsmiljön men inte produktionsmiljön. De behöver bara åtkomst för att skapa resurser men inte för att ändra miljöegenskaper och de kanske endast behöver åtkomst till läs-/skrivdata från Dataverse, men inte för att ändra datamodellen eller attributen i Dataverse-tabellen.

Undvik behörigheter som riktar sig till enskilda användare. Detaljerade och anpassade behörigheter skapar komplexitet och förvirring och kan bli svåra att underhålla när användare byter roller och flyttar i verksamheten eller när nya användare med liknande autentiseringskrav ansluter till teamet. Den här situationen 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: Ett granulärt tillvägagångssätt för åtkomstkontroll möjliggör bättre granskning och övervakning av användaraktiviteter.

Tilldela roller som börjar med lägsta privilegium och lägg till fler enligt verksamhets- eller dataåtkomstbehoven. De tekniska teamen måste ha tydliga anvisningar för hur de implementerar behörigheter.

Skapa villkorsstyrda åtkomstalternativ

Ge inte alla identiteter samma åtkomstnivå. Grunda besluten på två viktiga faktorer:

  • Tid. Hur länge identiteten får åtkomst till miljön.
  • Privilegium. Behörighetsnivå.

Dessa faktorer utesluter inte varandra. En avslöjad identitet som har fler privilegier och längre åtkomstvaraktighet kan få mer kontroll över systemet och data eller använda åtkomsten till att fortsätta ändra miljön. Begränsa åtkomstfaktorerna både som en förebyggande åtgärd och för att kontrollera skadans omfattning.

Just in time (JIT) ger endast privilegierna som krävs när de behövs.

Endast tillräcklig åtkomst (JEA) har endast privilegierna som krävs.

Även om tid och privilegium är de främsta faktorerna finns det andra villkor som gäller. Det går till exempel även att använda enheten, nätverket och platsen varifrån åtkomsten ursprungligen kommer för att ange principer.

Använd kraftfulla kontroller som filtrerar, identifierar och blockerar obehörig åtkomst, inklusive parametrar såsom användaridentitet och plats, enhetshälsa, arbetsbelastningskontext, dataklassificering och avvikelser.

Arbetsbelastningen kan till exempel kräva åtkomst från identiteter från tredje part, såsom leverantörer, partner och kunder. De måste ha lämplig åtkomstnivå i stället för standardbehörigheterna som du ger till heltidsanställda. En tydlig åtskillnad mellan externa konton gör det enklare att förhindra och upptäcka angrepp från dem.

Konton med kritisk inverkan

Administrativa identiteter har bland de största säkerhetsriskerna eftersom uppgifterna de utför kräver att de får privilegierad åtkomst till en mängd olika system och program. Avslöjande eller felaktig användning kan påverka företagets verksamhet och dess informationssystem. Administrationssäkerhet är ett av de viktigaste säkerhetsområdena.

Om du vill skydda priviligierad åtkomst mot bestämda motståndare 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 antal konton med allvarlig inverkan.

  • Använd separata roller i stället för att ändra befintliga identiteters privilegier.

  • Undvik permanent eller stående åtkomst genom att använda JIT-funktioner för IDP. Följ processen för åtkomst vid nödsituationer när nödfall uppstår.

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

  • Genomför viktiga säkerhetsattribut genom att använda principer för villkorsstyrd åtkomst.

  • Inaktivera administrativa konton som inte används.

Upprätta processer för hantering av identitetslivscykeln

Åtkomst till identiteter får inte vara längre än resurserna identiteten har åtkomst till. Säkerställ att du har en process för att inaktivera eller ta bort identiteter när teamstruktur eller programvarukomponenter ändras.

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

Skapa en identitetsstyrningsprocess för att hantera de digitala identiteternas livscykel, användare med hög behörighet, externa/gästanvändare eller arbetsbelastningsanvändare. Implementera åtkomstgranskningar för att säkerställa att arbetsbelastningsbehörigheter tas bort när identiteter lämnar organisationen eller teamet.

Skydda icke-identitetsbaserade hemligheter

Programhemligheter såsom fördelade nycklar måste betraktas som känsliga punkter i systemet. Om leverantören eller konsumenten avslöjas kan tvåvägskommunikationen introducera avsevärda säkerhetsrisker. Dessa nycklarna kan även vara betungande eftersom de introducerar verksamhetsprocesser.

Betrakta sådana hemligheter som entiteter som går att hämta dynamiskt från en hemlighetslagring. De får inte vara hårdkodade i appar, flöden, distributionskanaler eller i andra artefakter.

Kontrollera att du har möjlighet att återkalla hemligheter.

Använd verksamhetsrutiner som hanterar uppgifter såsom nyckelrotation och giltighet.

Information om rotationsprinciper finns i Automatisera rotation av resurser med två uppsättningar autentiseringsuppgifter och Självstudier: Uppdatera frekvens för automatisk rotation av certifikat i Key Vault.

Skydda utvecklingsmiljöerna

Skrivbehörighet till utvecklarmiljöer måste vara stängd och läsbehörighet till källkod måste begränsas till roller på need-to-know-basis. Du måste ha en process som regelbundet söker igenom resurser och identifierar de senaste säkerhetsproblemen.

Underhålla spårning

En sida av identitetshantering är att säkerställa att systemet går att granska. Granskningar verifierar om strategierna för antagen överträdelse är effektiva. Underhåll av spårning gör det möjligt att:

  • Bekräfta att identiteten autentiseras med stark autentisering. Alla åtgärder måste går att spåra för att avvisningsangrepp.

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

  • Utvärdera åtkomst från identiteter till arbetsbelastningen utifrån säkerhets- och regelefterlevnadskrav och fundera på risker för användarkonto, enhetsstatus och övriga villkor och principer du anger.

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

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

Underlätta Power Platform

Power Platform åtkomstkontroll är en viktig del av den övergripande säkerhetsarkitekturen. Åtkomstkontrollpunkter kan säkerställa att rätt användare får åtkomst till Power Platform-resurserna. I det här avsnittet utforskar vi vilka olika åtkomstpunkter du kan konfigurera och deras roll i den övergripande säkerhetsstrategin.

Microsoft Entra-ID

Alla Power Platform-produkter använder Microsoft Entra ID (tidigare Azure Active Directory eller Azure AD) för identitets- och åtkomsthantering. Entra ID gör det möjligt för organisationer att skydda och hantera identitet för sina hybrid- och flermolnmiljöer. Entra ID är även viktigt för att hantera verksamhetens gäster som behöver åtkomst till Power Platform-resurser. Power Platform använder även Entra ID till att hantera andra program som måste integrera med Power Platform API:er genom tjänsthuvudkontots funktioner. Genom att använda Entra ID kan Power Platform använda mer avancerade säkerhetsfunktioner i Entra ID såsom villkorsstyrd åtkomst och kontinuerlig tillgänglighetskontroll.

Diagram med ett molnbaserat databehandlingssystem.

Licenstilldelning

Åtkomst till Power Apps och Power Automate börjar med att ha en licens. Tillgångar och data en användare har åtkomst till bestäms av användarens licenstyp. Följande tabell visar skillnader i resurser på hög nivå som är tillgängliga för en användare grundat på plantyp. Detaljerad licensieringsinformation hittar du i licensieringsöversikten.

Principer för villkorsstyrd åtkomst

Villkorsstyrd åtkomst beskriver principen för ett åtkomstbeslut. Om du vill använda villkorsstyrd åtkomst måste du förstå vilka begränsningar som användningsfallet kräver. Konfigurera Microsoft Entra villkorsstyrd åtkomst genom att konfigurera en åtkomstprincip som baseras på verksamhetsbehoven.

Mer information finns i

Kontinuerlig åtkomst

Kontinuerlig åtkomst ökar när vissa händelser utvärderas för att fastställa om åtkomsten måste upphävas. Traditionellt, med OAuth 2.0-autentisering, upphör åtkomsttoken att gälla när en kontroll görs under tokenförnyelsen. Med kontinuerlig åtkomst utvärderas en användares viktiga händelser och ändringar i nätverksplatsen kontinuerligt för att avgöra om användaren fortfarande bör behålla åtkomsten. Utvärderingarna kan leda till att aktiva sessioner avslutas tidigt eller föranleder omautentisering. Om ett användarkonto till exempel är inaktiverat måste det förlora åtkomst till appen. Platsen är också viktig. Token kan till exempel ha auktoriserats från en betrodd plats, men användaren har ändrat sin anslutning till ett nätverk som inte är betrott. Kontinuerlig åtkomst kan användas för utvärdering av principen för villkorsstyrd åtkomst och användaren förlorar åtkomst eftersom den inte längre ansluter på en godkänd plats.

För tillfället stöder endast Dataverse kontinuerlig tillgänglighetskontroll i Power Platform. Microsoft arbetar med att lägga till support för andra Power Platform-tjänster och klienter. Mer information finns i Kontinuerlig tillgänglighetskontroll.

Med pågående anpassning av hybridarbetsmodeller och molnprogram har Entra ID blivit en viktig primär säkerhetsgräns för att skydda användare och resurser. Villkorsstyrd åtkomst utvidgar det området utanför ett nätverksområde för att inkludera användar- och enhetsidentitet. Kontinuerlig åtkomst säkerställer att åtkomst omvärderas när händelser eller användarplatser ändras. Power Platforms användning av Entra ID gör det möjligt att implementera säkerhetsstyrning på organisationsnivå som går att tillämpa konsekvent i hela programportföljen. Läs rekommendationer om identitetshantering om du vill ha mer hjälp med att skapa en egen plan för hur du använder Entra ID med en Power Platform.

Gruppåtkomsthantering

I stället för att ge behörigheter till specifika användare tilldelar du åtkomst till grupper i Microsoft Entra ID. Om en grupp inte finns går det att skapa en tillsammans med identitetsteamet. Det går sedan att lägga till och ta bort gruppmedlemmar utanför Azure och kontrollera att behörigheterna är aktuella. Du kan också använda gruppen i andra syften, till exempel för utskickslistor.

Mer information finns i Säker åtkomstkontroll med grupper i Microsoft Entra ID.

Hotidentifiering

Microsoft Entra ID-skydd hjälper dig att identifiera, undersöka och åtgärda identitetsbaserade problem. Mer information finns i Vad är Identity Protection?.

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

Identitetsloggning

Power Apps, Power Automate, Copilot Studio, anslutningsprogram och aktivitetsloggning för dataförlustskydd följs upp och visas i Microsoft Purview-portalen för regelefterlevnad. Mer information finns i Läs mer om Microsoft Purview.

Loggar förändringar som görs i kundposter i en miljö med en Dataverse-databas. Dataverse-granskning loggar även användaråtkomst via ett program eller via SDK i en miljö. Den här granskningen aktiveras på miljönivå och ytterligare konfiguration krävs för enskilda tabeller och kolumner.

Tjänstadministratörsroller

Entra ID innehåller en uppsättning med fördefinierade roller som kan tilldelas administratörer för att ge dem behörighet att utföra administrativa uppgifter. Granska behörighetsmatrisen för en detaljerad uppdelning av varje rolls privilegier.

Använd Microsoft Entra Privileged Identity Management (PIM) för att hantera högt priviligierade administratörsroller i Power Platform administrationscenter.

Skydda Dataverse-data

En av nyckelfunktionerna i Dataverse är dess omfattande säkerhetsmodell som kan anpassas till många affärsanvändningsscenarier. Den här säkerhetsmodellen är endast tillgänglig om en Dataverse-databas finns i miljön. Som säkerhetsproffs bygger du förmodligen inte hela säkerhetsmodellen själv, men du kanske är delaktig i att säkerställa att säkerhetsfunktionernas användning överensstämmer med organisationens datasäkerhetskrav. Dataverse använder rollbaserad säkerhet för att gruppera en samling med privilegier. De här säkerhetsrollerna kan associeras direkt till användare, eller till Dataverse team och affärsenheter. Mer information finns i Säkerhetskoncept i Microsoft Dataverse.

Konfigurera användarautentisering i Copilot Studio

Microsoft Copilot Studio har stöd för flera autentiseringsalternativ. Välj den som uppfyller dina behov. Autentisering tillåter användare att logga in, vilket ger din agent åtkomst till begränsade resurser eller information. Användare kan logga in med Microsoft Entra ID eller något OAuth 2.0 identitetsprovider, t.ex. Google eller Facebook. Läs mer i Konfigurera slutanvändarautentisering i Copilot Studio.

Med Direct Line-baserad säkerhet kan begränsa åtkomsten till platser som du kontrollerar genom att aktivera säker åtkomst med Direct Line-hemligheter eller -token.

Copilot Studio stöder enkel inloggning (SSO), vilket innebär att agenter kan logga in användaren. SSO måste implementeras på dina webbsidor och mobilapplikationer. För Microsoft Teams är enkel inloggning sömlös om du väljer autentiseringsalternativet "Endast i Teams". Den kan också konfigureras manuellt med Azure AD v2, men i det här fallet måste Teams-appen distribueras som en zip-fil, inte via Teams-distributionen med 1 klick från Copilot Studio.

Läs mer:

Säker åtkomst till data med Customer Lockbox

De flesta åtgärder, support och felsökning som utförs av Microsoft-personal (inklusive underprocessorer) kräver inte åtkomst till kunddata. Med Power Platform Customer Lockbox, vi tillhandahåller ett gränssnitt för kunderna att granska och godkänna (eller avvisa) begäranden om dataåtkomst i det sällsynta tillfället då dataåtkomst till kunddata behövs. Den används till exempel i fall när en Microsoft-tekniker behöver åtkomst till kunddata, oavsett om det är svar på en supportbiljett startad av kunden eller ett problem som Microsoft identifierade. Mer information finns i Säker åtkomst till kunddata med Customer Lockbox i Power Platform och Dynamics 365.

Checklista för säkerhet

Se den fullständiga uppsättningen med rekommendationer.

Checklista för säkerhet