Del via

Anbefalinger til identitets- og adgangsstyring

  • Artikel

Dette gælder for denne anbefaling af Power Platform-kontrolliste til velstruktureret sikkerhed:

SE:05 Implementer en streng, betinget og reviderbar identitets- og adgangsstyring (IAM) på tværs af alle arbejdsbelastningsbrugere, teammedlemmer og systemkomponenter. Begræns adgangen udelukkende til efter behov. Brug moderne branchestandarder til alle implementeringer af godkendelse og autorisation. Begræns og overvåg strengt adgang, der ikke er baseret på identitet.

Denne guide beskriver anbefalingerne til godkendelse og godkendelse af identiteter, der forsøger at få adgang til dine arbejdsbelastningsressourcer.

Fra et teknisk kontrolsynspunkt er identitet altid den primære perimeter. Omfanget omfatter ikke kun kanterne af din arbejdsbelastning. Den indeholder også individuelle komponenter, der indgår i din arbejdsbelastning.

Typiske identiteter omfatter:

  • Personer. Applikationsbrugere, administratorer, operatører, revisiorer, ondsindede personer.
  • Systemer. Identiteter for arbejdsbelastning, administrerede identiteter, API-nøgler, servicekonti og Azure-ressourcer.
  • Anonym. Objekter, der ikke har angivet noget bevis på, hvem de er.

Definitioner

Vilkår Definition
Godkendelse (AuthN) En proces, der kontrollerer, at en identitet er hvem, eller hvad der står i den.
Godkendelse (AuthZ) En proces, der kontrollerer, om et identitet har tilladelse til at udføre den ønskede handling.
Betinget adgang Et sæt regler, der tillader handlinger baseret på angivne kriterier.
Idp En identitetsudbyder, f.eks. Microsoft Entra ID.
Karakter En jobfunktion eller en titel, der har et sæt ansvarsområder og handlinger.
Nøgler, der er delt på forhånd En type hemmelighed, der deles mellem en udbyder og forbruger og bruges via en sikker og aftalt mekanisme.
Ressourceidentitet En identitet, der defineres for cloudressourcer, som administreres af platformen.
Rolle Et sæt tilladelser, der definerer, hvad en bruger eller gruppe kan gøre.
Område Forskellige niveauer af organisationshierarki, hvor en rolle har tilladelse til at fungere. Også en gruppe funktioner i et system.
Sikkerhedskonto En identitet, der giver tilladelser. Det kan være en bruger, en gruppe eller en servicekonto. Alle gruppemedlemmer har samme adgangsniveau.
Brugeridentitet En identitet for en person, f.eks. en medarbejder eller en ekstern bruger.
Identitet af arbejdsbelastning Et systemidentitet for en applikation, en service, et script, en container eller en anden komponent i en arbejdsbelastning, der bruges til at godkende sig selv over for andre services og ressourcer.

Bemærk

En identitet kan grupperes med andre lignende identiteter under en overordnet, der kaldes en sikkerhedskonto. En sikkerhedsgruppe er et eksempel på en sikkerhedskonto. Denne hierarkiske relation forenkler vedligeholdelsen og gør den mere ensartet. Da identitetsattributter ikke håndteres på individuelt niveau, reduceres risikoen for fejl også. I denne artikel er begrebet identitet en betegnelse for sikkerhedskonti.

Microsoft Entra ID er identitetsudbyder for Power Platform

Alle Power Platform-produkter bruger Microsoft Entra ID (tidligere Azure Active Directory eller Azure AD) til identitets- og adgangsstyring. Entra ID gør det muligt for organisationer at sikre og administrere identiteter i deres hybride og flercloudmiljøer. Entra ID er også vigtigt for at administrere virksomhedens gæster, som skal have adgang til Power Platform-ressourcer. Power Platform bruger også Entra ID til at administrere andre applikationer, der skal integreres med Power Platform API'er vha. tjenesteprincipalens funktioner. Ved at bruge Entra ID kan Power Platform udnytte Entra ID til mere avancerede sikkerhedsfunktioner som Betinget adgang og kontinuerlig adgangsevaluering.

Godkendelse

Godkendelse er en proces, der kontrollerer identiteter. Den identitet, der anmodes om, kræves for at kunne levere en eller anden form for identitet, som kan identificeres. Eksempel:

  • Et brugernavn og en adgangskode.
  • En hemmelighed, der er delt på forhånd, som en API-nøgle, der giver adgang.
  • Et SAS-token (Shared Access Signature)
  • Et certifikat, der bruges i gensidig TLS-godkendelse (Transport Layer Security).

Power Platform-godkendelse omfatter en række forespørgsler, svar og omdirigeringer mellem brugerens browser og Power Platform eller Azure-tjenester. Rækkefølgen følger det Microsoft Entra ID-godkendelseskodetildelte flow.

Forbindelse til og godkendelse af en ekstern datakilde foretages separat i forhold til godkendelse i en Power Platform-tjeneste. Du kan få flere oplysninger i Oprette forbindelse til og godkende datakilder.

Autorisation

Power Platform bruger Microsoft Entra-id Microsoft-identitetsplatformen til godkendelse af alle API-kald med branchestandarden OAuth 2.0-protokol.

Vigtigste designstrategier

Hvis du vil have en forståelse af identiteten af en arbejdsbelastning, skal du oprette en liste over bruger- og systemflow, arbejdsbelastningsaktiver og personer samt de handlinger, de skal udføre.

Hver enkelt use case har sikkert sit eget sæt kontrolelementer, som du skal designe med et antaget overensstemmelsessæt. Identificer de betingede valg på baggrund af identitetskravene af use casen eller personerne. Undgå at bruge én løsning til alle use cases. Modsat skal kontrolelementerne ikke være så granulære, at der introduceres unødvendig administration.

Du skal logge identitetsadgangssporet. Hvis du gør det, kan du validere kontrolelementerne, og du kan bruge logfilerne til ar revidere overholdelse af angivne standarder.

Bestemme alle identiteter til godkendelse

Ekstern adgang. Power Platform-godkendelse omfatter en række forespørgsler, svar og omdirigeringer mellem brugerens browser og Power Platform eller Azure-tjenester. Rækkefølgen følger det Microsoft Entra ID-godkendelseskodetildelte flow. Power Platformgodkender automatisk alle brugere, der har adgang til arbejdsbelastningen til forskellige formål.

Intern adgang. Din arbejdsbelastning skal have adgang til andre ressourcer. Du kan f.eks. læse fra eller skrive til dataplatformen, hente hemmeligheder fra det skjulte lager og logge telemetri til overvågningstjenester. Det kan endda være nødvendigt at få adgang til tredjepartsservices. Disse kræver alle adgang til arbejdsbelastningens identitet. Du skal imidlertid også tage ressourceidentitetskrav i betragtning. det kan f.eks. være, hvordan installationspipelines køres og godkendes.

Bestemme handlinger til godkendelse

Derefter skal du vide, hvad de enkelte godkendte identiteter forsøger at gøre, så disse handlinger kan godkendes. Handlingerne kan deles op af den adgangstype, de kræver:

  • Adgang på dataniveau. Handlinger, der finder sted på dataniveau, medfører dataoverførsel. En applikation kan f.eks. læse eller skrive data fra Microsoft Dataverse eller skrive logge til Application Insights.

  • Kontrollere niveauadgang. Handlinger, der foretages på kontrolniveauet, medfører, at en Power Platform-ressource oprettes, ændres eller slettes. Det kan f.eks. være at ændre miljøegenskaber eller oprette en datapolitik.

Applikationer er typiske målrettet mod handlinger på dataniveau, mens handlinger ofte har adgang til både kontrol- og dataniveau.

Giv rollebaseret godkendelse

På basis af ansvaret for de enkelte identiteter skal du godkende handlinger, der skal tillades. En Identitet må ikke gøre mere, end der er behov for. Inden du angiver godkendelsesregler, skal du have en klar forståelse af, hvem eller hvad der foretager anmodninger, hvad denne rolle har tilladelse til at gøre, og i hvilket omfang den kan gøre det. Disse faktorer fører til valg, der kombinerer identitet, rolle og omfang.

Overvej følgende:

  • Skal arbejdsbelastningen have dataniveauadgang til Dataverse for at læse og skrive?
  • Har arbejdsbelastningen også brug for adgang til miljøegenskaber?
  • Hvis en ondsindet bruger kompromitterer identiteten, hvordan vil det så påvirke systemet med hensyn til fortrolighed, integritet og tilgængelighed?
  • Skal arbejdsbelastningen have permanent adgang, eller kan du overveje betinget adgang?
  • Udfører arbejdsbelastningen handlinger, der kræver administrative/øgede rettigheder?
  • Hvordan fungerer arbejdsbelastningen i forbindelse med tredjepartsservices?
  • Har du krav til enkeltlogon (SSO) til intelligente arbejdsbelastninger i programmer, f.eks. agenter?
  • Kører agenten i ikke-godkendt tilstand, godkendt tilstand eller begge dele?

Rolletildeling

En rolle er et sæt tilladelser, der er tildelt en identitet. Tildel roller, der kun tillader, at identiteten fuldfører opgaven, og ikke mere. Når brugerens tilladelser er begrænset til deres jobkrav, er det nemmere at identificere mistænkelige eller uautoriserede funktioner i systemet.

Stil spørgsmål som disse:

  • Er skrivebeskyttet adgang nok?
  • Skal identiteten have tilladelser til at slette ressourcer?
  • Har rollen kun brug for adgang til de poster, de har oprettet?
  • Er hierarkisk adgang baseret på den afdeling, som brugeren har brug for?
  • Skal rollen have administrative eller øgede rettigheder?
  • Skal rollen have permanent adgang til disse tilladelser?
  • Hvad sker der, hvis brugeren skifter job?

Hvis du begrænser det adgangsniveau, som brugere, applikationer eller services har, reduceres den potentielle angrebs overflade. Hvis du kun tildeler de tilladelser, der som minimum kræves for at udføre bestemte opgaver, reduceres risikoen for et vellykket angreb eller uautoriseret adgang betydeligt. Udviklere skal f.eks. kun bruge maker-adgang til udviklingsmiljøet, men ikke til produktionsmiljøet. De skal blot have adgang til at oprette ressourcer, men ikke ændre miljøegenskaber. og de skal måske kun have adgang til læse/skrive data fra Dataverse, men de skal ikke ændre datamodellen eller attributterne i Dataverse-tabellen.

Undgå tilladelser, der er rettet mod de enkelte brugere. Granulære og brugerdefinerede tilladelser skaber kompleksitet og forvirring, og de kan være svære at vedligeholde, efterhånden som brugere får nye roller og bevæger sig på tværs af virksomheden, eller efterhånden som nye brugere med lignende godkendelseskrav bliver medlem af teamet. Denne situation kan oprette en kompleks, ældre konfiguration, der er vanskelig at vedligeholde og have en negativ indvirkning på sikkerhed og pålidelighed.

Tradeoff: En granulær adgangskontrol muliggør bedre revidering og overvågning af brugeraktiviteter.

Tildel roller, der starter med de mindst rettigheder, og tilføj flere baserede dine driftsmæssige behov eller behov for dataadgang. Dine tekniske teams skal have en klar vejledning i at implementere tilladelser.

Opret valg til betinget adgang

Giv ikke alle identiteter det samme adgangsniveau. Basér dine beslutninger på to hovedfaktorer:

  • Tid. Hvor længe skal identiteten have adgang til dit miljø.
  • Rettighed. Niveauet af tilladelser.

Disse faktorer udelukker ikke hinanden. En kompromitteret identitet, der har flere rettigheder og ubegrænset varighed af adgang, kan få mere kontrol over systemet og dataene eller bruge den pågældende adgang til fortsat at ændre miljøet. Begræns disse adgangsfaktorer både som en forebyggende måleenhed og til at kontrollere skadens omfang.

JIT-fremgangsmåder (Just in Time) giver kun de nødvendige rettigheder, når der er brug for dem.

Just Enough Access (JEA) giver kun de påkrævede rettigheder.

Selvom tid og rettigheder er primære faktorer, er der andre betingelser, der gælder. Du kan f.eks. også bruge den enhed, det netværk og den placering, som adgangen stammer fra, til at angive politikker.

Brug stærke kontrolelementer, der filtrerer, registrerer og blokerer uautoriseret adgang, herunder parametre som brugeridentitet og -placering, enhedens tilstand, sammenhæng for arbejdsbelastning, dataklassifikation og abnormiteter.

Det kan f.eks. være nødvendigt af få adgang til arbejdsbelastningen via tredjeparts identiteter som leverandører, partnere og kunder. De skal have det rette adgangsniveau i stedet for de standardtilladelser, du giver til medarbejdere på fuld tid. Klar differentiering af eksterne konti gør det nemmere at forhindre og registrere angreb, der kommer fra disse angreb.

Konti med kritisk effekt

De administrative identiteter indeholder nogle af de sikkerhedsrisici, der er mest alvorlige, da de opgaver, de udfører, kræver adgangsrettigheder til et bredt sæt af disse systemer og applikationer. Kompromitteret eller forkert brug kan påvirke virksomheden og dens informationssystemer. Sikkerhed i administrationen er et af de vigtigste sikkerhedsområder.

Når du beskytter priviligeret adgang mod bestemte fjender, skal du bruge en komplet og gennemtænkt fremgangsmåde til at isolere disse systemer mod risici. Her er nogle strategier:

  • Minimer antallet af konti, som har en kritisk påvirkning af miljøet.

  • Brug separate roller i stedet for at øge rettighederne for eksisterende identiteter.

  • Undgå permanent eller uendelig adgang ved hjælp af JIT-funktionerne i dit IdP. Hvis uheldet er ude, skal du følge en nødadgangsproces.

  • Brug moderne adgangsprotokoller, f.eks. adgangskodefri godkendelse eller multifaktorgodkendelse. Eksternaliser disse mekanismer med idP'et.

  • Gennemtvinge sikkerhedsattributter for nøgler ved hjælp af politikker for betinget adgang.

  • Deaktiver administrative konti, der ikke bruges.

Etabler processer til administration af identitetens livscyklus

Adgang til identiteter må ikke vare længere end de ressourcer, som identiteterne har adgang til. Sørg for, at du har en proces til deaktivering eller sletning af identiteter, når der er ændringer i teamets struktur eller softwarekomponenterne.

Denne vejledning gælder for kildekontrol, data, kontrolposter, brugere af arbejdsbelastning, infrastruktur, værktøjer, overvågning af data, logge, metrikværdier og andre objekter.

Opret en identitetsstyringsproces, der skal styre livscyklussen for digitale identiteter, brugere med meget privilegerede rettigheder, eksterne brugere/gæstebrugere og arbejdsbelastningsbrugere. Implementer adgangsvurderinger for at sikre, at når identiteternes forlader organisationen eller teamet, fjernes deres arbejdsbelastningstilladelser.

Beskytte hemmeligheder, der ikke er identitetsbaserede

Applikationshemmeligheder, som f.eks. nøgler, der er delt på forhånd, skal opfattes som sårbare punkter i systemet. Hvis udbyderen eller den potentielle forbruger kompromitteres, kan der i forbindelse med tovejskommunikation introduceres store sikkerhedsrisici. Disse nøgler kan også være besværlige, fordi de introducerer driftsmæssige processer.

Behandl disse hemmeligheder som objekter, der dynamisk kan trækkes fra et skjult lager. De skal ikke være hårdkodet i dine apps, flow, installationspipelines eller i andre artefakter.

Sørg for, at du har mulighed for at tilbagekalde hemmeligheder.

Anvend driftsmæssige spraksisser, der håndterer opgaver som f.eks. rotation og udløb af nøgler.

Du kan finde oplysninger om rotationspolitikker under Automatisering af rotation af en hemmelighed for ressourcer, der har to sæt legitimationsoplysninger til godkendelse og Selvstudium: Opdatering af hyppigheden af automatisk rotation af certifikater i Key Vault.

Hold udviklingsmiljøer sikre

Skriveadgang til udviklermiljøer skal begrænses, og læseadgang til kildekoden skal begrænses til roller på need-to-know-basis. Du bør have en proces på plads, der jævnligt tester ressourcer og identificerer de seneste sårbarheder.

Vedligeholde et revisionsspor

Et aspekt ved identitetsstyring er at sikre, at systemet kan overvåges. Overvågninger validerer, om strategier med et antaget brud er effektive. Vedligeholdelse af et revisionsspor hjælper dig med følgende:

  • Kontrollér, at identiteten godkendes med stærk godkendelse. Enhver handling skal kunne spores for at forhindre afvisningsangreb.

  • Registrer svage eller manglende godkendelsesprotokoller, og få synlighed og indsigt i bruger- og applikationslogon.

  • Evaluere adgangen fra identiteter til arbejdsbelastningen baseret på sikkerheds- og overholdelseskrav og tage højde for risici i forbindelse med brugerkontoen, enhedens status og andre kriterier og politikker, du angiver.

  • Spor status eller afvigelser fra krav om overholdelse af angivne standarder.

De fleste ressourcer har adgang til dataniveau. Du skal kende de identiteter, der giver adgang til ressourcer, og de handlinger, de udfører. Du kan bruge disse oplysninger til sikkerhedstest.

Power Platform-processtyring

Power Platform-adgangskontrolelementet er en vigtig del af den overordnede sikkerhedsarkitektur. Adgangskontrolpunkter kan sikre, at de rette brugere får adgang til Power Platform-ressourcerne. I dette afsnit gennemgås de forskellige adgangspunkter, du kan konfigurere, og deres rolle i den overordnede sikkerhedsstrategi.

Microsoft Entra ID

Alle Power Platform-produkter bruger Microsoft Entra ID (tidligere Azure Active Directory eller Azure AD) til identitets- og adgangsstyring. Entra ID gør det muligt for organisationer at sikre og administrere identiteter i deres hybride og flercloudmiljøer. Entra ID er også vigtigt for at administrere virksomhedens gæster, som har behov for at få adgang til Power Platform-ressourcer. Power Platform bruger også Entra ID til at administrere andre applikationer, der skal integreres med Power Platform API'er vha. tjenesteprincipalens funktioner. Ved at bruge Entra ID kan Power Platform udnytte Entra ID til mere avancerede sikkerhedsfunktioner som Betinget adgang og kontinuerlig adgangsevaluering.

Diagram over et cloudcomputing-system.

Licenstildeling

Adgang til Power Apps og Power Automate starter med at få en licens. De aktiver og data, en bruger kan få adgang til, er bestemt af den type licens, en bruger har. I følgende tabel beskrives overordnet set forskelle i ressourcer, der er tilgængelige for en bruger, baseret på deres niveautype. Du kan finde detaljerede licensoplysninger i Licensoversigt.

Politikker for betinget adgang

Betinget adgang beskriver politikken for en adgangsbeslutning. Hvis du vil bruge betinget adgang, skal du forstå de begrænsninger, der er nødvendige i forbindelse med use casen. Konfigurer betinget adgang i Microsoft Entra ved at konfigurere en adgangspolitik, der er baseret på dine driftsmæssige behov.

Du kan finde flere oplysninger i:

Kontinuerlig adgang

Kontinuerlig adgang øges, når bestemte hændelser evalueres for at afgøre, om adgangen skal ophæves. Traditionelt sker udløb af adgangstoken med OAuth 2.0-godkendelse, når der udføres en kontrol under tokenfornyelse. Med kontinuerlig adgang evalueres en brugers vigtige hændelser og ændringer af netværksplaceringer løbende for at afgøre, om brugeren stadig skal bevare adgangen. Disse evalueringer kan resultere i, at aktive sessioner kan afsluttes tidligt, eller at godkendelsen ændres. Hvis en brugerkonto f.eks. er deaktiveret, bør brugeren miste adgang til appen. Placering er også vigtig. Tokenet kan f.eks. være godkendt fra en placering, der er tillid til, men brugeren har ændret forbindelsen til et netværk, der ikke er tillid til. Kontinuerlig adgang aktiverer evalueringen af politikken for betinget adgang, og brugeren mister adgangen, fordi der ikke længere oprettes forbindelse fra en godkendt placering.

I øjeblikket understøtter Power Platform kun Dataverse-kontinuerlig adgangsevaluering. Microsoft arbejder på at føje support til andre Power Platform-tjenester og klienter. Du kan få flere oplysninger i Kontinuerlig adgangsevaluering.

Med den løbende indføring af arbejdsmodeller og brugen af cloudapplikationer er Entra ID blevet en vigtig primær sikkerhedsafskærming for brugere og ressourcer, der bliver klar til at blive brugt. Betinget adgang udvider denne perimeter ud over en netværksperimeteren, så den omfatter bruger- og enhedsidentitet. Kontinuerlig adgang sikrer, at efterhånden som hændelser eller brugerplaceringer ændres, evalueres adgangen igen. Power Platforms brug af Entra ID lader dig implementere styring af sikkerhed på organisationsniveau, som du kan anvende ensartet på tværs af applikationerne. Gennemgå disse bedste fremgangsmåder for identitetsstyring for at få mere vejledning i at opbygge din egen plan for brug af Entra ID med Power Platform.

Styring af gruppeadgang

I stedet for at tildele tilladelser til bestemte brugere, skal du tildele adgang til grupper i Microsoft Entra ID. Hvis der ikke findes en gruppe, kan du arbejde sammen med dit identitetsteam om at oprette en. Du kan derefter tilføje og fjerne gruppemedlemmer uden for Azure og sikre dig, at tilladelserne er aktuelle. Du kan også bruge gruppen til andre formål, f.eks. malingslister.

Du kan finde flere oplysninger i Sikre adgangskontrol ved hjælp af grupper i Microsoft Entra ID.

Trusselsregistrering

Microsoft Entra ID-beskyttelse kan hjælpe dig med at registrere, undersøge og håndtere identitetsbaserede risici. Du kan finde flere oplysninger om under Hvad er identitetsbeskyttelse?.

Registrering af trusler kan tage form af at reagere på en advarsel om aktivitet, der er aktiv, eller som proaktivt søger efter unormale hændelser i aktivitetslogfiler. Bruger- og objektfunktionsanalyser (UEBA) i Microsoft Sentinel gør det nemt at registrere aktiviteter, der kan identificeres. Du kan finde flere oplysninger i Identificere avancerede trusler med UEBA i Microsoft Sentinel.

Identitetslogføring

Power Apps, Power Automate, Copilot Studio, connectorer og aktiviteter, der bruges til at forhindre datatab, spores og vises fra Microsoft Purview-portalen for overholdelse af angivne standarder. Der er flere oplysninger i Få mere at vide om Microsoft Purview.

Indlæs ændringer der er foretaget i kundeposter i et miljø med en Dataverse-database. Dataverse-overvågning logfører også brugeradgang via en app eller via SDK'en i et miljø. Denne overvågning er aktiveret på miljøniveau, og der kræves yderligere konfiguration for de enkelte tabeller og kolonner.

Serviceadministratorroller

Entra ID indeholder et sæt foruddefinerede roller, som kan tildeles til administratorer for at give dem tilladelse til at udføre administrative opgaver. Du kan gennemse tilladelsesmatrixen for at se, om den enkelte rolle har rettigheder i granuleret form.

Brug Microsoft Entra Privileged Identity Management (PIM) i til at administrere administratorroller med mange rettigheder i Power Platform Administration.

Sikre Dataverse-data

En af de vigtigste funktioner i Dataverse er en omfattende sikkerhedsmodel, der kan tilpasses i mange scenarier for forretningsbrug. Sikkerhedsmodellen er kun tilgængelig, når der er en Dataverse-database i miljøet. Som sikkerhedsmedarbejder vil du sandsynligvis ikke selv opbygge hele sikkerhedsmodellen, men du kan være involveret i at sikre, at brugen af sikkerhedsfunktionerne er i overensstemmelse med organisationens datasikkerhedskrav. Dataverse bruger rollebaseret sikkerhed til at gruppere en samling af rettigheder. Disse sikkerhedsroller kan knyttes direkte til brugere, eller de kan knyttes til Dataverse-teams og -afdelinger. Du kan finde flere oplysninger under Sikkerhedsbegreber i Microsoft Dataverse.

Konfigurere brugergodkendelse i Copilot Studio

Microsoft Copilot Studio understøtter flere godkendelsesindstillinger. Vælg ét produkt, der opfylder til dine behov. Godkendelse giver brugere mulighed for at logge på og giver din agent adgang til begrænsede ressourcer eller oplysninger. Brugere kan logge på med en Microsoft Entra ID eller med en hvilken som helst OAuth 2.0-identitetsudbyder, for eksempel Google eller Facebook. Få mere at vide i Konfigurer slutbrugergodkendelse i Copilot Studio.

Med Direct Line-baseret sikkerhed, kan du kun aktivere adgang til placeringer, som du styrer ved at aktivere sikker adgang med Direct Line-hemmeligheder eller -tokens.

Copilot Studio understøtter enkeltlogon (SSO), hvilket betyder, at agenter kan logge brugeren på. SSO skal implementeres på dine websider og mobilapplikationer. til Microsoft Teams SSO er problemfri, hvis du vælger godkendelsesindstillingen "Kun i Teams". Den kan også konfigureres manuelt med Azure AD v2, men i dette tilfælde skal Teams-appen installeres som en zip-fil, ikke via Teams-udrulningen med 1 klik fra Copilot Studio.

Få mere at vide:

Sikker adgang til data ved hjælp af kundelockbox

De fleste handlinger, support og fejlfinding, der udføres af Microsoft-medarbejdere (herunder underprocessorer), kræver ikke adgang til kundedata. Med Power Platform-kundelockbox'en giver vi en grænseflade, hvor kunder kan gennemse og godkende (eller afvise) anmodninger om dataadgang i de sjældne tilfælde, hvor der er behov for dataadgang til kundedata. Det bruges f.eks., hvor en Microsoft-tekniker skal have adgang til kundedata, uanset om det er som svar på en kundeinitieret supportanmodning eller et problem, der identificeres af Microsoft. Du kan finde flere oplysninger i Sikre adgang til kundedata ved hjælp af Kundelockbox i Power Platform og Dynamics 365.

Kontrolliste til sikkerhed

Se det fuldstændige sæt anbefalinger.

Kontrolliste til sikkerhed