Del via

Anbefalinger for identitets- og tilgangsstyring

  • Artikkel

Gjelder til denne Power Platform Well-Architected Security-sjekklisteanbefalingen:

SE:05 Implementer strenge, betingede og identitets- og tilgangsstyringsoppgaver som kan overvåkes på tvers av alle arbeidsbelastningsbrukere, teammedlemmer og systemkomponenter. Begrens tilgangen eksklusivt til etter behov. Bruk moderne bransjestandarder for alle godkjennings- og godkjenningsimplementeringer. Begrens revisjonstilgang som ikke er basert på identitet.

Denne veiledningen beskriver anbefalingene for godkjenning og autorisasjon av identiteter som prøver å få tilgang til arbeidsbelastningsressursene dine.

Fra et teknisk kontrollperspektiv er identitet alltid hovedperimeteren. Dette omfanget inkluderer ikke bare kantene på arbeidsbelastningen. Den inkluderer også enkeltkomponenter som er i arbeidsbelastningen.

Vanlige identiteter inkluderer:

  • Mennesker. Programbrukere, administratorer, operatører, revisorer og ondsinnede aktører.
  • Systemer. Identiteter for arbeidsbelastning, administrerte identiteter, API-nøkler, tjenestekontohavere og Azure-ressurser.
  • Anonym. Entiteter som ikke har oppgitt noen form for bevis om hvem de er.

Definisjoner

Termer Definisjon
Godkjenning (AuthN) En prosess som kontrollerer at en identitet er hvem den sier den er.
Autorisasjon (AuthZ) En prosess som kontrollerer om en identitet har tillatelse til å utføre en forespurt handling.
Betinget tilgang Et sett med regler som tillater handlinger basert på angitte vilkår.
IdP En identitetsleverandør, for eksempel Microsoft Entra ID.
Identitet En jobbfunksjon eller en stilling som har et sett med ansvar og handlinger.
Forhåndsdelte nøkler En type hemmelighet som deles mellom en leverandør og forbruker og brukes via en sikker og avtalt mekanisme.
Ressursidentitet En identitet definert for skyressurser som administreres av plattformen.
Rolle Et sett med tillatelser som definerer hva en bruker eller gruppe kan gjøre.
Omfang Ulike nivåer i organisasjonshierarkiet der en rolle har tillatelse til å operere. Også en gruppe funksjoner i et system.
Sikkerhetskontohaver En identitet som gir tillatelser. Det kan være en bruker, en gruppe eller en sikkerhetskontohaver for tjenester. Alle gruppemedlemmer får samme tilgangsnivå.
Brukeridentitet En identitet for en person, for eksempel en ansatt eller en ekstern bruker.
Arbeidsbelastningsidentitet En systemidentitet for et program, en tjeneste, et skript, en beholder eller en annen komponent i en arbeidsbelastning som brukes til å godkjenne seg selv til andre tjenester og ressurser.

Merk

En identitet kan grupperes med andre, lignende identiteter under en overordnet, kalt en sikkerhetskontohaver. En sikkerhetsgruppe er et eksempel på en sikkerhetskontohaver. Denne hierarkiske relasjonen forenkler vedlikehold og forbedrer konsekvensen. Siden identitetsattributter ikke håndteres på individuelt nivå, reduseres også sjansen for feil. I denne artikkelen inkluderer begrepet identitet også sikkerhetskontohavere.

Microsoft Entra ID er identitetsleverandøren for Power Platform

Alle Power Platform-produkter bruker Microsoft Entra ID (tidligere Azure Active Directory elle Azure AD) for identitets- og tilgangsadministrasjon. Entra-ID gjør det mulig for organisasjoner å sikre og administrere identitet for hybridmiljøer og flerskymiljøer. Entra ID er også viktig for å administrere bedriftsgjester som trenger tilgang til Power Platform-ressurser. Power Platform bruker også Entra ID til å administrere andre programmer som må integreres med Power Platform API-er ved hjelp av funksjonene for sikkerhetskontohaver for tjeneste. Ved å bruke Entra ID kan Power Platform bruke mer avanserte sikkerhetsfunksjoner som betinget tilgang og kontinuerlig tilgangsevaluering.

Autentisering

Autentisering er en prosess som kontrollerer identiteter. Identiteten som spør, må oppgi en eller annen form for verifiserbar identifikasjon. Eksempel:

  • Et brukernavn og passord.
  • En forhåndsdelt hemmelighet, for eksempel en API-nøkkel som gir tilgang.
  • Et SAS-token (signatur for delt tilgang)
  • Et sertifikat brukt i gjensidig TLS-godkjenning (Transport Layer Security).

Power Platform-godkjenning innebærer en rekke forespørsler, svar og omdirigering mellom brukerens nettleser og Power Platform- eller Azure-tjenester. Sekvensen følger tillatelsesflyten for Microsoft Entra ID-godkjenning.

Tilkobling og autentisering til en datakilde gjøres separat fra autentisering til en Power Platform-tjeneste. Hvis du vil ha mer informasjon, kan du se Koble til og godkjenne datakilder.

Autorisasjon

Power Platform bruker Microsoft Entra ID Microsofts identitetsplattform til autorisasjon av alle API-kall med bransjestandardprotokollen OAuth 2.0.

Viktige utformingsstrategier

For å forstå identitetsbehovene for en arbeidsbelastning må du lage en liste over bruker- og systemflyter, arbeidsbelastningsressurser og identiteter samt handlingene de skal utføre.

Hvert brukstilfelle har sannsynligvis et eget sett med kontroller som du må utforme med et tankesett som forutsetter brudd. Identifiser de betingede valgene basert på identitetskravene for brukssaken eller identitetene. Unngå å bruke én løsning for alle brukssaker. Kontrollene bør derimot ikke være så detaljerte at du innfører unødvendig administrasjon.

Du må logge identitetstilgangssporet. Dette bidrar til å validere kontrollene, og du kan bruke loggene for samsvarsrevisjoner.

Fastslå alle identiteter for godkjenning

Utenfor-inn-tilgang. Power Platform-godkjenning innebærer en rekke forespørsler, svar og omdirigering mellom brukerens nettleser og Power Platform- eller Azure-tjenester. Sekvensen følger tillatelsesflyten for Microsoft Entra ID-godkjenning. Power Platform godkjenner automatisk alle brukere som har tilgang til arbeidsbelastningen, for ulike formål.

Innenfra-ut-tilgang. Arbeidsbelastningen din må ha tilgang til andre ressurser. Dette kan for eksempel være å lese fra eller skrive til dataplattformen, hente hemmeligheter fra det hemmelige lageret og logge telemetri på overvåkingstjenester. Det kan til og med være nødvendig å få tilgang til tredjepartstjenester. Alt dette er krav til arbeidsbelastningsidentitet. Du må imidlertid også vurdere krav til ressursidentitet, for eksempel hvordan utrullingskanaler kjører og godkjennes.

Fastslå handlinger for godkjenning

Deretter må du vite hva hver godkjente identitet prøver å gjøre, slik at disse handlingene kan godkjennes. Handlingene kan deles inn etter tilgangstypen de krever:

  • Tilgang til dataplan. Handlinger som foregår på dataplanet, fører til dataoverføring. Eksempel: et program som leser eller skriver data fra Microsoft Dataverse, eller skriver logger til Application Insights.

  • Tilgang til kontrollplan. Handlinger som finner sted på kontrollplanet, fører til at en Power Platform-ressurs blir opprettet, endret eller slettet. Eeksempel: endre miljøegenskaper eller opprette en datapolicy.

Programmer retter seg vanligvis mot operasjoner på dataplanet, mens operasjoner ofte har tilgang til både kontroll- og dataplanet.

Oppgi rollebasert godkjenning

Autoriser handlinger som skal tillates, basert på ansvaret for hver identitet. En identitet må ikke ha lov til å gjøre mer enn den trenger å gjøre. Før du angir autorisasjonsregler, må du ha en klar forståelse av hvem eller hva som kommer med forespørsler, hva denne rollen har tillatelse til å gjøre, og i hvilken utstrekning den kan gjøre det. Disse faktorene fører til valg som kombinerer identitet, rolle og omfang.

Vurder følgende:

  • Må arbeidsbelastningen ha dataplantilgang til Dataverse for både lese- og skrivetilgang?
  • Trenger arbeidsbelastningen også tilgang til miljøegenskaper?
  • Hvis identiteten blir kompromittert av en ondsinnet aktør, hva vil innvirkningen på systemet være når det gjelder konfidensialitet, integritet og tilgjengelighet?
  • Trenger arbeidsbelastningen permanent tilgang, eller kan betinget tilgang vurderes?
  • Utfører arbeidsbelastningen handlinger som krever administrative/opphøyede tillatelser?
  • Hvordan samhandler arbeidsbelastningen med tjenester fra tredjeparter?
  • Har du krav til enkel pålogging for intelligente programarbeidsbelastninger, for eksempel agenter?
  • Drives agenten i uautentisert modus, autentisert modus eller begge deler?

Rolletildeling

En rolle er et sett med tillatelser som er tilordnet en identitet. Tilordne roller som bare tillater at identiteten fullfører oppgaven, og ikke mer. Når brukerens tillatelser er begrenset til jobbkravene, er det enklere å identifisere mistenkelig eller uautorisert virkemåte i systemet.

Still spørsmål som disse:

  • Er skrivebeskyttet tilgang nok?
  • Trenger identiteten tillatelser for å slette ressurser?
  • Trenger rollen bare tilgang til oppføringene de opprettet?
  • Er det nødvendig med hierarkisk tilgang basert på forretningsenheten der brukeren er?
  • Trenger rollen administrative eller opphøyede tillatelser?
  • Trenger rollen permanent tilgang til disse tillatelsene?
  • Hva skjer hvis brukeren endrer jobber?

Hvis du begrenser tilgangsnivået som brukere, programmer eller tjenester har, reduseres den potensielle angrepsoverflaten. Hvis du bare gir minimumstillatelsene som kreves for å utføre bestemte oppgaver, reduseres risikoen for et vellykket angrep eller uautorisert tilgang betydelig. Utviklere trenger for eksempel bare opprettertilgang til utviklingsmiljøet, men ikke produksjonsmiljøet. De trenger bare tilgang til å opprette ressurser, men ikke endre miljøegenskaper. Og det kan hende at de bare trenger tilgang til å lese/skrive data fra Dataverse, men ikke endre datamodellen eller attributtene i Dataverse-tabellen.

Unngå tillatelser som er rettet mot enkeltbrukere. Detaljerte og egendefinerte tillatelser skaper kompleksitet og forvirring og kan bli vanskelige å vedlikeholde når brukere endrer roller og flytter over hele virksomheten, eller etter hvert som nye brukere med lignende godkjenningskrav blir med i teamet. Denne situasjonen kan føre til en kompleks eldre konfigurasjon som er vanskelig å vedlikeholde, og som har negativ innvirkning på både sikkerhet og pålitelighet.

Avveining: En detaljert tilgangskontroll fører til bedre revisjon og overvåking av brukeraktiviteter.

Gi roller som starter med minst rettigheter, og legg til flere roller basert på driftsmessige behov eller datatilgangsbehov. Tekniske team må ha tydelig veiledning for å implementere tillatelser.

Foreta betingede tilgangsvalg

Ikke gi alle identitetene samme tilgangsnivå. Baser avgjørelsene på to hovedfaktorer:

  • Klokkeslett. Hvor lenge identiteten har tilgang til miljøet.
  • Rettighet. Nivået av rettigheter.

Disse faktorene utelukker ikke hverandre. En kompromittert identitet som har flere rettigheter og ubegrenset tilgangsvarighet, kan få mer kontroll over systemet og dataene, eller bruke denne tilgangen til å fortsette å endre miljøet. Begrens disse tilgangsfaktorene både som et preventivt tiltak og for å kontrollere skadeomfanget.

Just in Time (JIT) gir bare de nødvendige rettighetene når det er behov for dem.

Just Enough Access (JEA) gir bare de nødvendige rettighetene.

Selv om tid og rettighet er hovedfaktorene, er det andre betingelser som gjelder. Du kan for eksempel også bruke enheten, nettverket og plasseringen som tilgangen opprinnelig kom fra, til å angi policyer.

Bruk sterke kontroller som filtrerer, oppdager og blokkerer uautorisert tilgang, inkludert parametere som brukeridentitet og sted, enhetstilstand, kontekst for arbeidsbelastning, dataklassifisering og avvik.

Det kan for eksempel hende at tredjeparter, som leverandører, partnere og kunder, trenger tilgang til arbeidsbelastningen din. De trenger riktig tilgangsnivå i stedet for standardtillatelsene du gir til heltidsansatte. Tydelig differensiering av eksterne kontoer gjør det enklere å forhindre og oppdage angrep som kommer fra disse vektorene.

Kontoer med kritisk innvirkning

Administrative identiteter introduserer noen av de største sikkerhetsrisikoene fordi oppgavene de utfører, krever privilegert tilgang til et bredt sett med disse systemene og programmene. Kompromittering eller misbruk kan ha en skadelig effekt på virksomheten og informasjonssystemene. Sikkerhet i administrasjonen er et av de mest kritiske sikkerhetsområdene.

Beskyttelse av privilegert tilgang mot skruppelløse angripere krever at du inntar en fullstendig og gjennomtenkt tilnærming til å isolere disse systemene mot risiko. Her er noen strategier:

  • Minimer antall kontoer med kritisk innvirkning.

  • Bruk separate roller i stedet for å opphøye rettigheter for eksisterende identiteter.

  • Unngå permanent eller stående tilgang ved å bruke JIT-funksjonene fra identitetsleverandøren din. Følg akutte hendelser, følg en tilgangsprosess for nødsituasjoner.

  • Bruk moderne tilgangsprotokoller som godkjenning uten passord eller flerfaktorautentisering. Gjør disse mekanismene eksterne for identitetsleverandøren din.

  • Overfør nøkkelsikkerhetsattributter ved hjelp av betingede tilgangspolicyer.

  • Avvikle administrative kontoer som ikke brukes.

Opprett prosesser for å administrere identitetssyklusen

Tilgang til identiteter må ikke vare lenger enn ressursene som identiteten har tilgang til. Sørg for at du har en prosess for å deaktivere eller slette identiteter når det er endringer i teamstrukturen eller programvarekomponentene.

Denne veiledningen gjelder kildekontroll, data, kontrollplan, arbeidsbelastningsbrukere, infrastruktur, verktøy, overvåking av data, logger, måleverdier og andre enheter.

Etabeler en identitetsstyringsprosess for å administrere livssyklusen til digitale identiteter, høyprivilegerte brukere, eksterne brukere / gjestebrukere og arbeidsbelastningsbrukere. Implementer tilgangsgjennomganger for å sikre at arbeidsbelastningstillatelsene fjernes når identitetene forlater organisasjonen eller teamet.

Beskytt ikke-identitetsbaserte hemmeligheter

Programhemmeligheter som forhåndsdelte nøkler må betraktes som sårbare punkter i systemet. Hvis leverandøren eller forbrukeren er kompromittert, kan dette medføre betydelig sikkerhetsrisiko ved toveis kommunikasjon. Disse nøklene kan også være belastende fordi de innfører driftsprosesser.

Behandle disse hemmelighetene som enheter som kan hentes dynamisk fra et hemmelig lager. De bør ikke være hardkodet i appene, flytene, utrullingskanalene dine eller i andre artefakter.

Sørg for at du har muligheten til å tilbakekalle hemmeligheter.

Bruk driftspraksiser som håndterer oppgaver som nøkkelrotasjon og -utløp.

Hvis du vil ha informasjon om rotasjonspolicyer, kan du se Automatiser rotasjonen av en hemmelighet for ressurser som har to sett med godkjenningslegitimasjon og Opplæring: Oppdatering av hyppigheten for automatisk rotasjon av sertifikater i Key Vault.

Hold utviklingsmiljøer trygge

Skrivetilgang til utviklermiljøer bør inngjerdes, og lesetilgang til kildekode bør begrenses til roller på en trenger-å-vite-basis. Du bør ha en prosess på plass som skanner ressurser regelmessig og identifiserer de nyeste sårbarhetene.

Oppretthold et revisjonsspor

Ett aspekt ved identitetsbehandling er å sørge for at systemet kan revideres. Revisjoner validerer om strategier for å anta brudd er effektive. Det å opprettholde et revisjonsspor hjelper deg med følgende:

  • Kontroller at identiteten er godkjent med sterk godkjenning. Alle handlinger må kunne spores for å hindre avvisningsangrep.

  • Oppdag svake eller manglende godkjenningsprotokoller, og få innsyn i og innsikt om pålogging for brukere og programmer.

  • Evaluer tilgang fra identiteter til arbeidsbelastningen basert på krav til sikkerhet og samsvar, og vurder risikoen for brukerkontoen, enhetsstatusen og andre vilkår og policyer du angir.

  • Spor fremdrift eller avvik fra samsvarskrav.

De fleste ressurser har dataplantilgang. Du må kjenne til identitetene som har tilgang til ressurser, og handlingene de utfører. Du kan bruke denne informasjonen for sikkerhetsdiagnoser.

Tilrettelegging for Power Platform

Power Platform-tilgangskontroll er en viktig del av den generelle sikkerhetsarkitekturen. Tilgangskontrollpunkter kan sikre at de rette brukerne får tilgang til Power Platform-ressursene. I denne delen utforsker vi de ulike tilgangspunktene du kan konfigurere, og deres rolle i den generelle sikkerhetsstrategien.

Microsoft Entra-ID

Alle Power Platform-produkter bruker Microsoft Entra ID (tidligere Azure Active Directory elle Azure AD) for identitets- og tilgangsadministrasjon. Entra-ID gjør det mulig for organisasjoner å sikre og administrere identitet for hybridmiljøer og flerskymiljøer. Entra ID er også viktig for å administrere bedriftsgjester som trenger tilgang til Power Platform-ressurser. Power Platform bruker også Entra ID til å administrere andre programmer som må integreres med Power Platform API-er ved hjelp av funksjonene for sikkerhetskontohaver for tjeneste. Ved å bruke Entra ID kan Power Platform bruke mer avanserte sikkerhetsfunksjoner som betinget tilgang og kontinuerlig tilgangsevaluering.

Diagram over et system for datasystem i skyen.

Lisenstilordning

Tilgang til Power Apps og Power Automate starter med å ha en lisens. Hvilke aktiva og data en bruker har tilgang til, avgjøres av lisenstypen brukeren har. Tabellen nedenfor viser forskjeller mellom ressurser som er tilgjengelige for en bruker basert på plantypen, fra et høyt nivå. Detaljerte lisensdetaljer finner du i Oversikt over lisensiering.

Betingede tilgangspolicyer

Betinget tilgang beskriver policyen for en tilgangsbeslutning. Hvis du vil bruke betinget tilgang, må du forstå begrensningene som kreves for brukstilfellet. Konfigurer betinget tilgang for Microsoft Entra ved å angi en tilgangspolicy som er basert på dine driftsmessige behov.

Hvis du vil ha mer informasjon, kan du se:

Kontinuerlig tilgang

Kontinuerlig tilgang fremskynder når bestemte hendelser evalueres for å avgjøre om tilgangen skal oppheves. Tradisjonelt, med OAuth 2.0-godkjenning, oppstår utløp av tilgangstoken når en kontroll utføres under fornyelse av token. Med kontinuerlig tilgang evalueres en brukers kritiske hendelser og endringer av nettverksplassering kontinuerlig for å avgjøre om brukeren fremdeles skal beholde tilgangen. Disse evalueringene kan føre til at aktive økter avsluttes tidlig, eller nødvendiggjøre en ny godkjenning. Hvis en brukerkonto for eksempel er deaktivert, bør de miste tilgang til appen. Plassering er også viktig. Tokenet kan for eksempel ha blitt godkjent fra en klarert plassering, men brukeren endret tilkoblingen til et uklarert nettverk. Kontinuerlig tilgang starter evalueringen av betinget tilgangspolicy, og brukeren mister tilgangen fordi de ikke lenger kobler til fra en godkjent plassering.

Med Power Platform støtter Dataverse for tiden kun kontinuerlig tilgangsevaluering. Microsoft jobber med å legge til støtte for andre Power Platform-tjenester og -klienter. For mer informasjon, se Kontinuerlig tilgangsevaluering.

Med den pågående innføringen av hybride arbeidsmodeller og bruk av skyprogrammer har Entra ID blitt en viktig primær sikkerhetsperimeter for beskyttelse av brukere og ressurser. Betinget tilgang utvider perimeteren utover en nettverksperimeter for å inkludere bruker- og enhetsidentitet. Kontinuerlig tilgang sikrer at tilgangen blir evaluert på nytt etter hvert som hendelser eller brukerplasseringer endres. Bruken av Entra ID i Power Platform gjør det mulig å implementere sikkerhetsstyring på organisasjonsnivå som du kan bruke konsekvent på tvers av programporteføljen. Gå gjennom disse beste fremgangsmåtene for identitetsadministrasjon for å få mer veiledning om hvordan du bygger din egen plan for bruk av Entra-ID med Power Platform.

Tilgangsadministrasjon for grupper

I stedet for å gi tillatelser til bestemte brukere kan du tilordne tilgang til grupper i Microsoft Entra ID. Hvis en gruppe ikke finnes, kan du arbeide med identitetsteamet for å opprette en. Du kan deretter legge til og fjerne gruppemedlemmer utenfor Azure og kontrollere at tillatelsene er gjeldende. Du kan også bruke gruppen til andre formål, for eksempel adresselister.

Hvis du vil ha mer informasjon, kan du se Sikre tilgangskontroll ved å bruke grupper i Microsoft Entra ID.

Trusselregistrering

Microsoft Entra ID-beskyttelse kan hjelpe deg med å registrere, undersøke og løse identitetsbaserte risikoer. Hvis du vil ha mer informasjon, kan du se Hva er identitetsbeskyttelse?.

Trusselregistrering kan ta form av å reagere på et varsel om mistenkelig aktivitet eller proaktivt søke etter avvikende hendelser i aktivitetslogger. UEBA (analyse av bruker- og enhetsatferd) i Microsoft Sentinel gjør det enkelt å oppdage mistenkelige aktiviteter. Hvis du vil ha mer informasjon, kan du se Identifiser avanserte trusler med UEBA (analyse av bruker- og enhetsatferd) i Microsoft Sentinel.

Identitetslogging

Power Apps, Power Automate, Copilot Studio, koblinger og aktivitetslogging for hindring av datatap og vises fra Microsoft Purview-samsvarsportalen. Hvis du vil ha mer informasjon, kan du se Finn ut mer om Microsoft Purview.

Logger endringer som gjøres i kundeoppføringer i et miljø med en Dataverse-database. Dataverse-sporing av endringer logger også brukertilgang via en app eller via SDK i et miljø. Denne revisjonen aktiveres på miljønivå, og ekstra konfigurasjon kreves for individuelle tabeller og kolonner.

Tjenesteadministratorroller

Entra ID inneholder et sett med forhåndsopprettede roller som kan tilordnes administratorer for å gi dem tillatelse til å utføre administrative oppgaver. Du kan se gjennom tillatelsesmatrisen for å få en detaljert oversikt over rettighetene til hver rolle.

Bruk Microsoft Entra Privileged Identity Management (PIM) til å administrere høyt privilegerte administratorroller i Power Platform-administrasjonssenteret.

Sikring av Dataverse-data

En viktig funksjon i Dataverse er en omfattende sikkerhetsmodell som kan tilpasses mange scenarioer for forretningsbruk. Denne sikkerhetsmodellen er bare tilgjengelig når det er en Dataverse-database i miljøet. Som sikkerhetspersonell vil du sannsynligvis ikke bygge hele sikkerhetsmodellen selv, men du kan være involvert i å sørge for at bruken av sikkerhetsfunksjonene er i samsvar med datasikkerhetskravene i organisasjonen. Dataverse-bruker rollebasert sikkerhet til å gruppere sammen en samling rettigheter. Disse sikkerhetsrollene kan knyttes direkte til brukere, eller de kan knyttes til Dataverse-team og forretningsenheter. Hvis du vil ha mer informasjon, kan du se Sikkerhetskonsepter i Microsoft Dataverse.

Konfigurere sluttbrukergodkjenning i Copilot Studio

Microsoft Copilot Studio støtter flere godkjenningsalternativer. Velge det som oppfyller behovene dine. Godkjenning gjør at brukere kan logge seg på og dermed gi agenten tilgang til en begrensede ressurser eller informasjon. Brukere kan logge seg på med Microsoft Entra ID eller enhver OAuth 2.0-identitetsleverandør, for eksempel Google eller Facebook. Finn ut mer i Konfigurere sluttbrukerautentisering i Copilot Studio.

Med Direct Line-basert sikkerhet kan du begrense tilgang til steder som du styrer, ved å aktivere sikker tilgang med Direct Line-hemmeligheter eller -tokener.

Copilot Studio støtter enkel pålogging, som betyr at agenter kan logge på brukeren. Enkel pålogging må implementeres på nettsidene og i mobilappene. For Microsoft Teams er enkel pålogging sømløst hvis du velger autentiseringsalternativet "Bare i Teams". Den kan også konfigureres manuelt med Azure AD v2; men i dette tilfellet må Teams-appen rulles ut som en zip-fil, ikke gjennom 1-klikk Teams-utrulling fra Copilot Studio.

Finn ut mer:

Få sikker tilgang til data ved hjelp av Customer Lockbox

De fleste operasjoner, kundestøtte og feilsøking som utføres av Microsoft-ansatte (inkludert underbehandlere) krever ikke tilgang til kundedata. Med Power Platform Customer Lockbox tilbyr vi et grensesnitt der kundene kan gå gjennom og godkjenne (eller avvise) datatilgangsforespørsler i sjeldne tilfeller når det er nødvendig med datatilgang til kundedata. Det brukes for eksempel når en Microsoft-tekniker må ha tilgang til kundedata, enten som svar på en kundestartet kundestøtteforespørsel eller et problem identifisert av Microsoft. Hvis du vil ha mer informasjon, kan du se Få sikker tilgang til kundedata ved hjelp av Customer Lockbox i Power Platform og Dynamics 365.

Sikkerhetssjekkliste

Se hele settet med anbefalinger.

Sikkerhetssjekkliste