Delen via

Aanbevelingen voor identiteits- en toegangsbeheer

  • Artikel

Geldt voor deze aanbeveling voor een goed ontworpen Power Platform Well-Architected-beveiligingschecklist:

SE:05 Implementeer strikt, voorwaardelijk en controleerbaar identiteits- en toegangsbeheer (IAM) voor alle workloadgebruikers, teamleden en systeemonderdelen. Beperk de toegang uitsluitend tot indien nodig. Gebruik moderne industriestandaarden voor alle authenticatie- en autorisatie-implementaties. Beperk en controleer streng de toegang die niet op identiteit is gebaseerd.

In deze gids worden de aanbevelingen beschreven voor het verifiëren en autoriseren van identiteiten die proberen toegang te krijgen tot uw workloadresources.

Vanuit technisch controleperspectief is identiteit altijd de primaire perimeter. Dit bereik omvat niet alleen de randen van uw workload. Het bevat ook afzonderlijke onderdelen die binnen uw workload vallen.

Typische identiteiten zijn onder meer:

  • Mensen. Toepassingsgebruikers, beheerders, operators, auditors en kwaadwillenden.
  • Systemen. Workloadidentiteiten, beheerde identiteiten, API-sleutels, service-principals en Azure-resources.
  • Anoniem. Entiteiten die geen enkel bewijs hebben geleverd over wie ze zijn.

Definities

Voorwaarden Definitie
Tokenverificatie (AuthN) Een proces dat verifieert dat een identiteit is wie of wat hij of zij zegt te zijn.
Autorisatiecode (AuthZ) Een proces dat verifieert of een identiteit toestemming heeft om een ​​gevraagde actie uit te voeren.
Voorwaardelijke toegang Een set regels die acties mogelijk maakt op basis van gespecificeerde criteria.
IdP Een identiteitsprovider, zoals Microsoft Entra ID.
Persona Een functie of titel met een reeks verantwoordelijkheden en acties.
Vooraf gedeelde sleutels Een soort geheim dat wordt gedeeld tussen een aanbieder en een consument en wordt gebruikt via een veilig en overeengekomen mechanisme.
Resource-identiteit Een identiteit die is gedefinieerd voor cloudbronnen die worden beheerd door het platform.
- Rol Een set machtigingen die bepalen wat een gebruiker of groep kan doen.
Scope Verschillende niveaus van de organisatiehiërarchie waar een rol in mag functioneren. Ook een groep functies in een systeem.
Beveiligingsprincipal Een identiteit die machtigingen biedt. Dit kan een gebruiker, een groep of een beveiligingsprincipal zijn. Alle groepsleden krijgen hetzelfde toegangsniveau.
Gebruikersidentiteit Een identiteit voor een persoon, zoals een medewerker of een externe gebruiker.
Workloadidentiteit Een systeemidentiteit voor een toepassing, service, script, container of ander onderdeel van een workload die wordt gebruikt om zichzelf te verifiëren bij andere services en resources.

Opmerking

Een identiteit kan worden gegroepeerd met andere, vergelijkbare identiteiten onder een bovenliggend element, genaamd een beveiligingsprincipal. Een beveiligingsgroep is een voorbeeld van een beveiligingsprincipal. Deze hiërarchische relatie vereenvoudigt het onderhoud en verbetert de consistentie. Omdat identiteitskenmerken niet op individueel niveau worden afgehandeld, wordt de kans op fouten ook verkleind. In dit artikel wordt de term identiteit bedoeld als inclusief beveiligingsprincipals.

Microsoft Entra ID als de identiteitsprovider voor Power Platform

Alle Power Platform-producten gebruiken Microsoft Entra ID (voorheen Azure Active Directory of Azure AD) voor identiteits- en toegangsbeheer. Met Entra ID kunnen organisaties de identiteit voor hun hybride en multicloud-omgevingen beveiligen en beheren. Entra ID is ook essentieel voor het beheren van zakelijke gasten die toegang nodig hebben Power Platform-resources. Power Platform gebruikt ook Entra ID om andere applicaties te beheren die geïntegreerd moeten worden met Power Platform API's die gebruikmaken van de mogelijkheden van Service-Principals. Door gebruik te maken van Entra ID kan Power Platform gebruikmaken van de geavanceerdere beveiligingsfuncties van Entra ID, zoals voorwaardelijke toegang en doorlopende toegangsevaluatie.

Verificatie

Authenticatie is een proces dat identiteiten verifieert. Van de aanvragende identiteit is een vorm van verifieerbare identificatie vereist. Bijvoorbeeld:

  • Een gebruikersnaam en wachtwoord.
  • Een vooraf gedeeld geheim, zoals een API-sleutel die toegang verleent.
  • Een Shared Access Signature (SAS)-token
  • Een certificaat dat wordt gebruikt in de wederzijdse verificatie van Transport Layer Security (TLS).

Power Platform-verificatie omvat een reeks aanvragen, reacties en omleidingen tussen de browser van de gebruiker en Power Platform of Azure-services. De reeks volgt de Stroom van toekenning voor de Microsoft Entra ID-autorisatiecode.

Verbinden en verifiëren bij een gegevensbron vindt onafhankelijk van het verifiëren bij een Power Platform-service plaats. Zie Verbinding maken met en verifiëren bij gegevensbronnen voor meer informatie.

Autorisatie

Power Platform gebruikt Microsoft Entra Microsoft Identity Platform voor autorisatie van alle API-aanroepen met het industriestandaard OAuth 2.0-protocol.

Belangrijke ontwerpstrategieën

Om de identiteitsbehoeften voor een workload te begrijpen, moet u de gebruikers- en systeemstromen, de workloadactiva en persona's vermelden, en de acties die ze zullen ondernemen.

Elk gebruikersscenario heeft waarschijnlijk zijn eigen set besturingselementen die u moet ontwerpen vanuit de gedachte dat er sprake is van inbreuk. Identificeer de voorwaardelijke keuzes op basis van de identiteitsvereisten van de gebruikersscenario's of de persona’s. Vermijd het gebruik van één oplossing voor alle gebruiksscenario's. Omgekeerd mogen de controles niet zo gedetailleerd zijn dat u onnodige beheeroverhead introduceert.

U moet het identiteitstoegangstraject registreren. Als u dit doet, worden de controles gevalideerd en kunt u de logboeken gebruiken voor nalevingscontroles.

Alle identiteiten voor verificatie bepalen

Outside-in-toegang. Power Platform-verificatie omvat een reeks aanvragen, reacties en omleidingen tussen de browser van de gebruiker en Power Platform of Azure-services. De reeks volgt de Stroom van toekenning voor de Microsoft Entra ID-autorisatiecode. Power Platform verifieert automatisch alle gebruikers die toegang hebben tot de workload voor verschillende doeleinden.

Inside-out-toegang. Uw workload heeft toegang nodig tot andere bronnen. Bijvoorbeeld lezen van of schrijven naar het gegevensplatform, het ophalen van geheimen uit de geheime opslag en het loggen van telemetrie naar bewakingsservices. Mogelijk heeft de workload zelfs toegang nodig tot services van derden. Dit zijn allemaal workloadidentiteitsvereisten. U moet echter ook rekening houden met de vereisten voor de resource-identiteit; bijvoorbeeld hoe implementatiepijplijnen uitgevoerd en geverifieerd zullen worden.

Autorisatieacties bepalen

Vervolgens moet u weten wat elke geverifieerde identiteit probeert te doen, zodat deze acties kunnen worden geautoriseerd. De acties kunnen worden onderverdeeld naar het type toegang dat ze vereisen:

  • Gegevensvlak-toegang. Acties die plaatsvinden in het gegevensvlak veroorzaken gegevensoverdracht. Een toepassing leest of schrijft bijvoorbeeld gegevens van Microsoft Dataverse, of schrijft logboeken naar Application Insights.

  • Besturingsvlak-toegang. Acties die plaatsvinden op het besturingsvlak zorgen ervoor dat een Power Platform-resource wordt gemaakt, gewijzigd of verwijderd. Bijvoorbeeld het wijzigen van omgevingseigenschappen of het maken van een gegevensbeleid.

Toepassingen zijn doorgaans gericht op gegevensvlakbewerkingen, terwijl bewerkingen vaak toegang hebben tot zowel besturings- als gegevensvlakken.

Zorgen voor rolgebaseerde autorisatie

Op basis van de verantwoordelijkheid van elke identiteit autoriseert u acties die moeten worden toegestaan. Een identiteit mag alleen worden toegestaan het nodige te doen. Voordat u autorisatieregels instelt, moet u duidelijk inzicht hebben in wie of wat verzoeken indient, wat die rol mag doen en in hoeverre deze dat kan doen. Deze factoren leiden tot keuzes die identiteit, rol en bereik combineren.

Denk aan het volgende:

  • Moet de workload gegevensvlaktoegang hebben in Dataverse voor zowel lees- als schrijftoegang?
  • Heeft de workload ook toegang tot omgevingseigenschappen nodig?
  • Als de identiteit wordt aangetast door een kwaadwillende, wat zou dan de impact zijn op het systeem in termen van vertrouwelijkheid, integriteit en beschikbaarheid?
  • Heeft de workload permanente toegang nodig of kan voorwaardelijke toegang worden overwogen?
  • Voert de workload acties uit waarvoor administratieve/verhoogde machtigingen vereist zijn?
  • Hoe zal de workload omgaan met services van derden?
  • Zijn er voor intelligente toepassingsworkloads zoals agenten vereisten voor eenmalige aanmelding?
  • Werkt de agent in de niet-geverifieerde modus, de geverifieerde modus of beide?

Roltoewijzing

Een rol is een machtigingenset die aan een identiteit is toegewezen. Wijs rollen toe die alleen de identiteit in staat stellen de taak te voltooien, en niet meer. Wanneer de machtigingen van gebruikers beperkt zijn tot hun taakvereisten, is het gemakkelijker om verdacht of ongeautoriseerd gedrag in het systeem te identificeren.

Stel uzelf vragen als de volgende:

  • Is alleen-lezen toegang voldoende?
  • Heeft de identiteit machtigingen nodig om resources te verwijderen?
  • Heeft de rol alleen toegang nodig tot de records die ze hebben gemaakt?
  • Is hiërarchische toegang vereist op basis van de business unit waarin de gebruiker zich bevindt?
  • Heeft de rol administratieve of verhoogde machtigingen nodig?
  • Heeft de rol permanente toegang tot deze machtigingen nodig?
  • Wat gebeurt er als de gebruiker van baan verandert?

Door het toegangsniveau van gebruikers, toepassingen of services te beperken, wordt het potentiële gebied van aanval kleiner. Als u alleen de minimale machtigingen verleent die nodig zijn om specifieke taken uit te voeren, wordt het risico op een succesvolle aanval of ongeautoriseerde toegang aanzienlijk verminderd. Ontwikkelaars hebben bijvoorbeeld alleen makertoegang nodig tot de ontwikkelomgeving, maar niet tot de productieomgeving; ze hebben alleen toegang nodig om resources te creëren, maar ze mogen de omgevingseigenschappen niet veranderen; en ze hebben mogelijk alleen toegang nodig om gegevens te lezen/schrijven uit Dataverse, maar mogen het gegevensmodel of de kenmerken van de Dataverse-tabel niet wijzigen.

Vermijd machtigingen die gericht zijn op individuele gebruikers. Gedetailleerde en aangepaste machtigingen zorgen voor complexiteit en verwarring, en kunnen moeilijk te onderhouden worden als gebruikers van rol veranderen en binnen het bedrijf een andere functie krijgen, of als nieuwe gebruikers met vergelijkbare authenticatievereisten zich bij het team voegen. Deze situatie kan leiden tot een complexe verouderde configuratie die moeilijk te onderhouden is en een negatieve invloed heeft op zowel de veiligheid als de betrouwbaarheid.

Afweging: met een gedetailleerde aanpak voor toegangscontrole kunnen activiteiten van gebruikers beter worden gecontroleerd en bijgehouden.

Ken rollen toe die beginnen met de minste rechten en voeg er meer toe op basis van uw operationele wensen of wensen op het gebied van gegevenstoegang. Uw technische teams moeten duidelijke richtlijnen hebben voor het implementeren van machtigingen.

Maak keuzes voor voorwaardelijke toegang

Geef niet alle identiteiten hetzelfde toegangsniveau. Baseer uw beslissingen op twee belangrijke factoren:

  • Tijd. Hoe lang de identiteit toegang heeft tot uw omgeving.
  • Privilege. Het machtigingsniveau.

Die factoren sluiten elkaar niet uit. Een gecompromitteerde identiteit die meer rechten heeft en een onbeperkte toegangsduur heeft, kan meer controle krijgen over het systeem en de gegevens, of die toegang gebruiken om de omgeving te blijven veranderen. Beperk deze toegangsfactoren, zowel als preventieve maatregel als om de ontploffingsradius te beheersen.

Just in Time (JIT)-benaderingen bieden de vereiste bevoegdheden alleen wanneer ze nodig zijn.

Just Enough Access (JEA) biedt alleen de vereiste bevoegdheden.

Hoewel tijd en bevoegdheid de belangrijkste factoren zijn, zijn er ook andere voorwaarden van toepassing. U kunt bijvoorbeeld ook het apparaat, het netwerk en de locatie waar de toegang vandaan komt gebruiken om beleid in te stellen.

Gebruik sterke controles die ongeautoriseerde toegang filteren, detecteren en blokkeren, inclusief parameters als gebruikersidentiteit en -locatie, apparaatstatus, workloadcontext, gegevensclassificatie en afwijkingen.

Uw workload moet bijvoorbeeld mogelijk toegankelijk zijn voor identiteiten van derden, zoals leveranciers, partners en klanten. Ze hebben het juiste toegangsniveau nodig in plaats van de standaardmachtigingen die u aan voltijdwerknemers verleent. Een duidelijk onderscheid tussen externe accounts maakt het gemakkelijker om aanvallen die afkomstig zijn van deze vectoren te voorkomen en te detecteren.

Kritieke impactaccounts

Beheeridentiteiten brengen enkele van de grootste beveiligingsrisico's met zich mee, omdat de taken die zij uitvoeren geprivilegieerde toegang vereisen tot een brede reeks van deze systemen en toepassingen. Compromissen of misbruik kunnen een schadelijk effect hebben op uw bedrijf en zijn informatiesystemen. Beveiliging van het bestuur is een van de meest kritieke veiligheidsgebieden.

Om bevoegde toegang te beschermen tegen vastberaden tegenstanders, moet u een volledige en doordachte aanpak volgen om deze systemen te isoleren van risico's. Hieronder volgen een aantal strategieën:

  • Minimaliseer het aantal accounts met kritieke impact.

  • Gebruik aparte rollen in plaats van de bevoegdheden voor bestaande identiteiten te verhogen.

  • Vermijd permanente of blijvende toegang door gebruik te maken van de JIT-functies van uw IdP. Voor situaties waarbij sprake is van noodgevallen, volgt u een noodtoegangsproces.

  • Gebruik moderne toegangsprotocollen zoals wachtwoordloze authenticatie of meervoudige verificatie. Externaliseer deze mechanismen naar uw IdP.

  • Dwing belangrijke beveiligingskenmerken af ​​met behulp van beleid voor voorwaardelijke toegang.

  • Ontmantel beheeraccounts die niet worden gebruikt.

Processen opzetten om de identiteitslevenscyclus te beheren

Toegang tot identiteiten mag niet langer duren dan de bronnen waartoe de identiteiten toegang hebben. Zorg ervoor dat u over een proces beschikt voor het uitschakelen of verwijderen van identiteiten wanneer er zich wijzigingen voordoen in de teamstructuur of softwareonderdelen.

Deze richtlijnen zijn van toepassing op bronbeheer, gegevens, controlevlakken, workloadgebruikers, infrastructuur, hulpprogramma's, het monitoren van gegevens, logboeken, metrische gegevens en andere entiteiten.

Zet een identiteitsgovernanceproces op om de levenscyclus van digitale identiteiten, gebruikers met hoge bevoegdheden, externe/gastgebruikers en workloadgebruikers te beheren. Implementeer toegangsbeoordelingen om ervoor te zorgen dat wanneer identiteiten de organisatie of het team verlaten, hun workloadmachtigingen worden verwijderd.

Niet-identiteitsgebaseerde geheimen beschermen

Toepassingsgeheimen, zoals vooraf gedeelde sleutels, moeten als kwetsbare punten in het systeem worden beschouwd. Als de aanbieder of consument in gevaar komt, kunnen er bij tweerichtingscommunicatie aanzienlijke veiligheidsrisico's ontstaan. Deze sleutels kunnen ook belastend zijn omdat ze operationele processen introduceren.

Behandel deze geheimen als entiteiten die dynamisch uit een geheime opslag kunnen worden gehaald. Ze mogen niet hardgecodeerd zijn in uw apps, stromen, implementatiepijplijnen of in enig ander artefact.

Zorg ervoor dat u geheimen kunt intrekken.

Pas operationele praktijken toe die taken als sleutelrotatie en -verloop afhandelen.

Voor informatie over roulatiebeleid raadpleegt u De roulatie van een geheim automatiseren voor bronnen die twee sets authenticatiegegevens hebben en Zelfstudie: Certificaat rotatiefrequentie automatisch bijwerken in Key Vault.

Ontwikkelomgevingen veilig houden

Schrijftoegang tot ontwikkelaarsomgevingen moet worden afgesloten en leestoegang tot de broncode moet worden beperkt tot rollen op basis van 'need-to-know'. U moet beschikken over een proces dat resources regelmatig scant en de nieuwste kwetsbaarheden identificeert.

Een audittrail bijhouden

Eén aspect van identiteitsbeheer is ervoor zorgen dat het systeem controleerbaar is. Audits valideren of strategieën waarbij uitgegaan wordt van inbreuken, effectief zijn. Door een audittrail bij te houden, kunt u:

  • Controleren of de identiteit is geverifieerd met sterke authenticatie. Elke actie moet traceerbaar zijn om afwijzingsaanvallen te voorkomen.

  • Detecteer zwakke of ontbrekende verificatieprotocollen en krijg inzicht in en inzichten over aanmeldingen van gebruikers en toepassingen.

  • Evalueer de toegang van identiteiten tot de workload op basis van beveiligings- en compliancevereisten en houd rekening met gebruikersaccountrisico's, apparaatstatus en andere criteria en beleid die u instelt.

  • Volg de voortgang of afwijking van compliancevereisten.

De meeste resources hebben toegang tot het gegevensvlak. U moet de identiteiten kennen die toegang hebben tot resources en de acties die zij uitvoeren. U kunt die informatie gebruiken voor beveiligingsdiagnostiek.

Power Platform faciliteren

Power Platform-toegangscontrole is een essentieel onderdeel van de algehele beveiligingsarchitectuur. Toegangscontrolepunten kunnen ervoor zorgen dat de juiste gebruikers toegang krijgen tot de Power Platform-resources. In dit gedeelte onderzoeken we de verschillende toegangspunten die u kunt configureren en hun rol in uw algemene beveiligingsstrategie.

Microsoft Entra ID

Alle Power Platform-producten gebruiken Microsoft Entra ID (voorheen Azure Active Directory of Azure AD) voor identiteits- en toegangsbeheer. Met Entra ID kunnen organisaties de identiteit voor hun hybride en multicloud-omgevingen beveiligen en beheren. Entra ID is ook essentieel voor het beheren van zakelijke gasten die toegang nodig hebben Power Platform-resources. Power Platform gebruikt ook Entra ID om andere applicaties te beheren die geïntegreerd moeten worden met Power Platform API's die gebruikmaken van de mogelijkheden van Service-Principals. Door gebruik te maken van Entra ID kan het Power Platform gebruikmaken van de geavanceerdere beveiligingsfuncties van Entra ID, zoals voorwaardelijke toegang en doorlopende toegangsevaluatie.

Diagram van een cloud computing-systeem.

Licentietoewijzing

Toegang tot Power Apps en Power Automate begint met een licentie. Tot welke activa en gegevens een gebruiker toegang heeft, wordt bepaald door het type licentie waarover de gebruiker beschikt. De volgende tabel schetst op een hoog niveau de verschillen in de voor een gebruiker beschikbare resources op basis van het abonnementstype. Gedetailleerde licentiegegevens zijn te vinden in het Licentieoverzicht.

Beleid voor voorwaardelijke toegang

Voorwaardelijke toegang beschrijft uw beleid voor een toegangsbesluit. Als u voorwaardelijke toegang wilt gebruiken, moet u de beperkingen begrijpen die vereist zijn voor het gebruikersscenario. Configureer Microsoft Entra voorwaardelijke toegang door een toegangsbeleid in te stellen dat is gebaseerd op uw operationele behoeften.

Zie voor meer informatie:

Doorlopende toegang

Doorlopende toegang wordt versneld wanneer bepaalde gebeurtenissen worden geëvalueerd om te bepalen of de toegang moet worden ingetrokken. Traditioneel verloopt bij OAuth 2.0-verificatie het toegangstoken wanneer er een controle wordt uitgevoerd tijdens vernieuwing van het token. Bij doorlopende toegang worden de kritieke gebeurtenissen en veranderingen in de netwerklocatie van een gebruiker voortdurend geëvalueerd om te bepalen of de gebruiker nog steeds toegang moet behouden. Deze evaluaties kunnen resulteren in het vroegtijdig beëindigen van actieve sessies of kunnen herverificatie noodzakelijk maken. Als een gebruikersaccount bijvoorbeeld is uitgeschakeld, verliest deze de toegang tot de app. De locatie is ook belangrijk; Het token kan bijvoorbeeld zijn geautoriseerd vanaf een vertrouwde locatie, maar de gebruiker heeft de verbinding gewijzigd naar een niet-vertrouwd netwerk. Doorlopende toegang zou de evaluatie van het beleid voor voorwaardelijke toegang aanroepen en de gebruiker zou de toegang verliezen omdat hij geen verbinding meer maakt vanaf een goedgekeurde locatie.

Momenteel ondersteunt Power Platform alleen doorlopende toegangsevaluatie van Dataverse. Microsoft werkt eraan om ondersteuning toe te voegen aan andere Power Platform-services en -clients. Zie Continue toegangsevaluatie voor meer informatie.

Met de voortdurende acceptatie van hybride werkmodellen en het gebruik van cloudtoepassingen is Entra ID een cruciale primaire beveiligingsperimeter geworden voor het beschermen van gebruikers en resources. Voorwaardelijke toegang breidt die perimeter uit tot buiten de netwerkperimeter en omvat de identiteit van gebruikers en apparaten. Doorlopende toegang zorgt ervoor dat wanneer evenementen of gebruikerslocaties veranderen, de toegang opnieuw wordt geëvalueerd. Power Platform's gebruik van Entra ID stelt u in staat beveiligingsbeheer op organisatieniveau te implementeren dat u consistent kunt toepassen in uw toepassingsportfolio. Bekijk deze best practices voor identiteitsbeheer voor meer begeleiding bij het opstellen van uw eigen plan voor het gebruik van Entra ID met Power Platform.

Groepstoegangsbeheer

In plaats van rechten te verlenen aan specifieke gebruikers, kunt u toegang toewijzen aan groepen in Microsoft Entra ID. Als er geen groep bestaat, werk dan samen met uw identiteitsteam om er een te maken. Vervolgens kunt u groepsleden buiten Azure toevoegen en verwijderen en ervoor zorgen dat de machtigingen actueel zijn. U kunt de groep ook voor andere doeleinden gebruiken, zoals mailinglijsten.

Zie Beveiligde toegangscontrole met behulp van groepen in Microsoft Entra ID voor meer informatie.

Detectie van bedreigingen

Microsoft Entra ID Protection kan u helpen bij het detecteren, onderzoeken en verhelpen van op identiteit gebaseerde risico's. Zie Wat houdt Identity Protection in? voor meer informatie.

Bedreigingsdetectie kan de vorm aannemen van reageren op een waarschuwing over verdachte activiteit of proactief zoeken naar afwijkende gebeurtenissen in activiteitenlogboeken. User and Enty Behavior Analytics (UEBA) in Microsoft Sentinel maakt het eenvoudig om verdachte activiteiten te detecteren. Zie Geavanceerde bedreigingen identificeren met UEBA in Microsoft Sentinel.

Identiteitsregistratie

Power Apps, Power Automate, Copilot Studio, connectoren en logboekregistratie van activiteiten ter voorkoming van gegevensverlies worden bijgehouden en bekeken vanuit de Microsoft Purview-complianceportal. Zie voor meer informatie Informatie over Microsoft Purview.

Registreert wijzigingen die zijn aangebracht in klantrecords in een omgeving met een Dataverse-database. Dataverse-controle registreert ook gebruikerstoegang via een app of via de SDK in een omgeving. Deze controle wordt ingeschakeld op omgevingsniveau, en er is aanvullende configuratie vereist voor afzonderlijke tabellen en kolommen.

Servicebeheerrollen

Entra ID bevat een reeks vooraf vastgestelde rollen die aan beheerders kunnen worden toegewezen om hen toestemming te geven beheertaken uit te voeren. U kunt de toestemmingsmatrix voor een gedetailleerd overzicht van de rechten van elke rol beoordelen.

Gebruik Microsoft Entra Privileged Identity Management (PIM) om beheerdersrollen met hoge bevoegdheden te beheren in het Power Platform-beheercentrum.

Dataverse-gegevens beveiligen

Een van de belangrijkste kenmerken van Dataverse is het uitgebreide beveiligingsmodel, dat zich kan aanpassen aan veel zakelijke gebruiksscenario's. Dit beveiligingsmodel is alleen beschikbaar wanneer er zich een Dataverse-database in de omgeving bevindt. Als beveiligingsprofessional bouwt u waarschijnlijk niet het hele beveiligingsmodel zelf, maar bent u er mogelijk wel bij betrokken om ervoor te zorgen dat het gebruik van de beveiligingsfuncties consistent is met de gegevensbeveiligingsvereisten van de organisatie. Dataverse maakt gebruik van op rollen gebaseerde beveiliging om een verzameling rechten te groeperen. Deze beveiligingsrollen kunnen rechtstreeks aan gebruikers worden gekoppeld of kunnen worden geassocieerd met Dataverse-teams en -bedrijfsonderdelen. Voor meer informatie raadpleegt u Beveiligingsconcepten in Microsoft Dataverse.

Gebruikersverificatie configureren in Copilot Studio

Microsoft Copilot Studio ondersteunt verschillende verificatieopties. Kies de optie die aan uw behoeften voldoet. Met verificatie kunnen gebruikers zich aanmelden, waardoor uw agent toegang krijgt tot beperkte resources of informatie. Gebruikers kunnen zich aanmelden met Microsoft Entra ID of een OAuth 2.0-id-provider, zoals Google of Facebook. Meer informatie vindt u in Gebruikersverificatie configureren in Copilot Studio.

Met op Direct Line gebaseerde beveiliging kunt u toegang beperken tot locaties die u beheert door beveiligde toegang in te schakelen met Direct Line-geheimen of -tokens.

Copilot Studio ondersteunt eenmalige aanmelding, wat betekent dat agenten de gebruiker kunnen aanmelden. Eenmalige aanmelding moet worden geïmplementeerd op uw webpagina's en mobiele toepassingen. Voor Microsoft Teams verloopt eenmalige aanmelding naadloos als u de verificatieoptie 'Alleen in Teams' selecteert. Het kan ook handmatig worden geconfigureerd met Azure AD v2. In dat geval moet de Teams-app echter worden geïmplementeerd als een zip-bestand en niet via de 1-klik Teams-implementatie van Copilot Studio.

Meer informatie:

Veilig toegang krijgen tot klantgegevens met behulp van Klanten-lockbox

Voor de meeste bewerkingen, ondersteuning en probleemoplossing die worden uitgevoerd door Microsoft-personeel (inclusief subverwerkers) is geen toegang tot klantgegevens vereist. Met Power Platform Klanten-lockbox bieden we een interface voor de klanten voor het beoordelen en goedkeuren (of afwijzen) van gegevenstoegang in het zeldzame geval dat gegevenstoegang tot klantgegevens nodig is. Het wordt bijvoorbeeld gebruikt wanneer een Microsoft-technicus toegang moet krijgen tot klantgegevens, hetzij als reactie op een door de klant geïnitieerd ondersteuningsticket of een door Microsoft geïdentificeerd probleem. Zie Veilig toegang krijgen tot klantgegevens met behulp van Klanten-lockbox in Power Platform en Dynamics 365 voor meer informatie.

Controlelijst voor beveiliging

Raadpleeg de volledige reeks aanbevelingen.

Controlelijst voor beveiliging