Voorwaardelijke toegang voor agentidentiteiten

Voorwaardelijke toegang is een intelligente beleidsengine waarmee organisaties kunnen bepalen hoe gebruikers en agentidentiteiten toegang hebben tot bedrijfsbronnen. Het brengt realtime-signalen samen, zoals de context van de gebruiker, het apparaat, de locatie en sessierisicogegevens, om te bepalen wanneer de toegang moet worden toegestaan, geblokkeerd of beperkt, of om meer verificatiestappen te vereisen.

Zie Wat is voorwaardelijke toegang? voor een algemeen overzicht van voorwaardelijke toegang. Zie Agentidentiteiten in uw organisatie beheren voor een handleiding op hoog niveau voor het beheren van agentidentiteiten in uw organisatie.

Kenmerkgestuurde voorwaardelijke toegang

Naarmate het aantal agentidentiteiten toeneemt, wordt het afzonderlijk toevoegen van elke agentidentiteit in elk beleid voor voorwaardelijke toegang operationeel onhoudbaar. Voordat u begint met het maken van beleid voor voorwaardelijke toegang, is het belangrijk om de agentidentiteiten te ordenen, waardoor consistente, schaalbare afdwinging van toegangsbeheer mogelijk is.

Aangepaste beveiligingskenmerken in Microsoft Entra ID zijn een handige manier om agentidentiteiten op schaal te organiseren. Aangepaste beveiligingskenmerken zijn bedrijfsspecifieke sleutel-waardekenmerken die u kunt definiëren en toewijzen aan Microsoft Entra objecten, waaronder gebruikers, agentidentiteiten en bedrijfstoepassingen (service-principals). Met deze kenmerken kunt u zinvolle informatie over elke agentidentiteit opslaan, zoals het vertrouwelijkheidsniveau van de gegevens die de agent verwerkt.

In het volgende diagram ziet u dat agentidentiteiten waarvoor het kenmerk 'Gegevensgevoeligheid' is ingesteld op Vertrouwelijk, worden geblokkeerd; alle andere agents worden uitgesloten en toegestaan. Deze aangepaste beveiligingskenmerkwaarden kunnen worden gebruikt als filters tijdens de evaluatie van voorwaardelijke toegang, waardoor op kenmerken gebaseerde targeting mogelijk is. In plaats van handmatige agentidentiteiten of doelbronnen te onderhouden, kunt u een regel definiëren, zoals: 'Als het kenmerk Vertrouwelijkheid van gegevens vertrouwelijk is', blokkeert u de toegang. Het beleid wordt vervolgens automatisch toegepast op elke agentidentiteit met deze kenmerken, inclusief de kenmerken die in de toekomst zijn toegevoegd.

In de volgende tabel ziet u enkele voorbeelden van hoe u uw agentidentiteiten kunt categoriseren:

Aangepaste beveiligingskenmerken zijn niet alleen voor agentidentiteiten. U kunt ze ook gebruiken om de bedrijfsmiddelen te classificeren die de agents raadplegen en vervolgens beide gebruiken in uw beleidsregels voor voorwaardelijke toegang voor een consistent labelsysteem in de volledige toegangsketen. Zie Wat zijn aangepaste beveiligingskenmerken in Microsoft Entra ID voor meer informatie.

Blauwdrukken voor agentidentiteiten

Een andere manier om een beleid voor voorwaardelijke toegang toe te passen op meerdere agentidentiteiten tegelijk, is door zich te richten op de blauwdruk van hun bovenliggende agentidentiteit. Elke agentidentiteit wordt afgeleid van een blauwdruk voor de agentidentiteit, die het configuratie- en governancemodel definieert. Het toepassen van een beleid op blauwdrukniveau omvat automatisch alle agents die ermee zijn afgeleid, inclusief nieuwe agents die in de toekomst worden toegevoegd.

In het volgende diagram ziet u dat alleen agentidentiteiten die zijn gekoppeld aan blauwdruk A, toegang krijgen; alle andere agents worden uitgesloten en geblokkeerd.

Stel bijvoorbeeld een project voor waarin u meerdere agents hebt, elk met een eigen doel. Sommige werken onafhankelijk, terwijl anderen samenwerken met andere agents (A2A) om taken te voltooien. Als ze allemaal onder dezelfde blauwdruk worden gemaakt, dwingt één beleid dat op die blauwdruk wordt toegepast consistente toegangsbeheer af in de hele verzameling.

Overzicht van patronen voor gegevenstoegang

Om toegang te krijgen tot een bedrijfsresource, zoals een SharePoint-bestand, MCP-servers of Open API-services, vraagt een gebruiker of agent eerst een toegangstoken aan bij Microsoft Entra ID. Toegangstokens worden echter pas uitgegeven nadat aan de vereiste controles voor voorwaardelijke toegang is voldaan. Zodra het toegangstoken is uitgegeven, presenteert de agent dat token aan de resource om de identiteit te bewijzen. De resource valideert het token en gebruikt de claims om autorisatie af te dwingen.

In het volgende diagram ziet u de patronen voor gegevenstoegang.

Beleidsregels voor voorwaardelijke toegang zijn if-then-instructies: als een gebruiker of agent toegang wil krijgen tot een resource, moet er eerst iets gebeuren. Als een agent bijvoorbeeld namens de Work IQ MCP e-mail van een gebruiker moet lezen, moet de gebruiker meervoudige verificatie voltooien voordat toegang wordt verleend. Als een agent toegang probeert te krijgen tot een resource die niet expliciet is opgenomen in het beleid, wordt de toegang standaard geblokkeerd.

Microsoft Entra ID geeft een toegangstoken uit aan een onderwerp voor een specifieke doelgroep (resource). Elk token heeft precies één onderwerp en één doelgroep.

• Het 'onderwerp' geeft aan aan wie het token is uitgegeven:
  • Wanneer een toepassing of agent namens een gebruiker een token aanvraagt, is de gebruiker het onderwerp.
  • Wanneer een toepassing of agent een token voor zichzelf aanvraagt, is de toepassing of de agent het onderwerp.
• De doelgroep identificeert de doelresource waarvoor het token is bedoeld:
  • Deze resource moet worden geregistreerd in Microsoft Entra ID.
  • Als het onderwerp meerdere resources moet aanroepen (bijvoorbeeld twee verschillende MCP-servers), heeft het doorgaans een afzonderlijk toegangstoken nodig voor elke resource, elk met een eigen doelgroep en machtigingen.

Beleid voor voorwaardelijke toegang wordt telkens opnieuw geëvalueerd wanneer een toegangstoken wordt aangevraagd, wat meestal gebeurt bij het verlopen van tokens of wanneer een kritieke gebeurtenis wordt geactiveerd, zoals Evaluatie van continue toegang.

Agents hebben toegang tot bedrijfsbronnen die worden beveiligd door Microsoft Entra ID met behulp van een van de volgende patronen:

• Namens een gebruiker
• Alleen toepassing
• Account van agentgebruiker

Zie Beveiliging voor AI voor meer informatie over de typen agents en de uitdagingen voor identiteits- en toegangsbeheer die ze presenteren.

Proces Op-Aanvraag-Van (OBO)

De meest voorkomende toegang is de stroom van de aangemelde gebruiker (OBO). In deze stroom heeft de agent toegang tot resources met de identiteit en machtigingen van de gebruiker om gegevens op te halen of acties uit te voeren die de gebruiker ook kan uitvoeren. Wanneer een agent bijvoorbeeld uw e-mailberichten leest, heeft de agent namens u toegang tot uw postvak.

In het volgende diagram ziet u de OBO-stroom die wordt gebruikt wanneer een agent namens een gebruiker een resource opent, met inbegrip van de volgende onderdelen:

• Gebruiker: Wie verzendt prompts naar de agent
• Agent/clienttoepassing: de gebruikersinterface waar gebruikers hun prompts verzenden
• Microsoft Entra ID: de id-provider die de agentidentiteit, het gebruikersaccount beheert en waar de resources zijn geregistreerd
• AI-platform: de runtime-omgeving waarin het LLM (Large Language Model) wordt uitgevoerd
• Resource: de resource die de agent aanroept om gegevens op te halen of een actie uit te voeren, zoals Werk-IQ, SharePoint online of een aangepaste MCP-server

In de volgende stappen wordt de stroom uitgebreider beschreven:

1. Gebruiker heeft toegang tot de agenttoepassing.

   1. De agenttoepassing is geregistreerd in Microsoft Entra ID en de toegang ervan valt onder Microsoft Entra ID.
   2. Voor toegang tot de app moeten gebruikers zich eerst verifiëren met hun account. Beheerders kunnen zich richten op de agenttoepassing in het beleid voor voorwaardelijke toegang.

2. Nadat de gebruiker zich heeft aangemeld, valideert de app het toegangstoken van de gebruiker en verleent deze toegang.

   1. De gebruiker verzendt een prompt naar het AI-platform (bijvoorbeeld Copilot Studio, Microsoft Foundry of een niet-Microsoft platform).
   2. Om de aanvraag te verwerken en erop te reageren, roept de LLM een bedrijfsresource aan.

3. De bedrijfsresource (SharePoint, e-mail, enzovoort) wordt beveiligd door Microsoft Entra ID en vereist een eigen toegangstoken.

   • U kunt het token niet doorgeven vanuit stap 1, omdat het is uitgegeven voor een andere doelgroep en machtigingen.
   • Gebruik in plaats daarvan de OBO-stroom om tokens uit te wisselen met Microsoft Entra ID en een nieuw token te verkrijgen dat is afgestemd op de resource.
   • Deze tokenuitwisseling wordt ook geëvalueerd door het beleid voor voorwaardelijke toegang, zodat beheerders gedetailleerde controles kunnen afdwingen waartoe resources agents namens de gebruiker toegang hebben.
   • Afhankelijk van uw agentarchitectuur kan de OBO-tokenuitwisseling plaatsvinden op verschillende lagen: de agenttoepassing zelf, een aangepaste middleware-API, een AI-platform zoals Copilot Studio of Azure AI Foundry, of zelfs de MCP-server.

4. Wanneer het nieuwe toegangstoken is verkregen, roept de agent de resource aan, waarbij het token voor verificatie wordt weergegeven.

   • De resource valideert het binnenkomende token, retourneert het antwoord en de stroom is voltooid.

Beleid voor voorwaardelijke toegang configureren voor OBO-flow

Als u een beleid voor voorwaardelijke toegang wilt maken voor agents die namens een gebruiker werken, gebruikt u de volgende instellingen:

• Toewijzingen: In een OBO-stroom wordt het toegangstoken uitgegeven aan de gebruiker (het tokenonderwerp), zodat u het beleid toewijst aan gebruikers of groepen, maar niet aan de agent of het gebruikersaccount van de agent.
• Doelbronnen: selecteer wat de gebruiker of de agent namens de gebruiker probeert te openen:
  • Voor elke doelresource kiest u ervoor om 'alle resources', 'alle agents' te targeten of selecteert u elke afzonderlijke resource die u wilt targeten met dat beleid.
• Netwerktoewijzing: beheerders kunnen beleidsregels maken die zijn gericht op specifieke netwerklocaties als signaal, samen met andere voorwaarden in hun besluitvormingsproces. In deze context verwijst het netwerk naar de locaties waar de gebruiker zich aanmeldt, niet waar de agent wordt uitgevoerd.
• Voorwaarden: Configureer de signalen die voorwaardelijke toegang evalueert, zoals gebruikersrisico, aanmeldingsrisico of andere factoren.
• Toegangsbeheer: afdwingen of toegang tot een doelresource wordt verleend, geweigerd, de toegang wordt beperkt of dat er meer verificatiestappen van de gebruiker nodig zijn.

Toegangsstroom voor alleen toepassingen

Agents hebben mogelijk toegang tot resources zonder een aangemelde gebruiker. In dit geval heeft de agent toegang tot de resource met een eigen identiteit. In het volgende diagram ziet u hoe agents toegang krijgen tot resources met hun eigen identiteit.

Deze flow wordt ook wel de client credentials flow genoemd of alleen toegang voor apps. Voor alle agenttypen kan deze stroom worden gebruikt.

Het volgende diagram toont de autorisatiestroom voor alleen-toepassings toegang.

Diagram dat de applicatie-exclusieve toegangsstroom toont voor agenten die met hun eigen identiteit toegang tot resources hebben.

Deze stroom is van toepassing in de volgende veelvoorkomende scenario's:

• Autonome agenten die onafhankelijk van elkaar werken:
  • Deze agents draaien op de achtergrond, reageren op gebeurtenissen of werken volgens een schema.
  • Een agent die bijvoorbeeld een dagelijks rapport genereert en het resultaat naar een groep werknemers verzendt. In dit scenario is er geen gebruiker aanwezig en werkt de agent zelfstandig.
• Interactieve agents die hun eigen identiteit gebruiken:
  • Deze agents hebben niet altijd namens een gebruiker toegang tot resources; soms gebruiken ze hun eigen identiteit.
  • Als een agent bijvoorbeeld een back-end sms-service aanroept waartoe gebruikers geen toegang hebben, is de OBO flow niet van toepassing en wordt de agent direct als zichzelf geverifieerd.
• Agents die op internet zijn gepubliceerd voor openbaar gebruik:
  • Deze agents verifiëren de gebruiker niet of bieden geen ondersteuning voor het delegeren van de context van de gebruiker aan bedrijfsbronnen.

In deze scenario's vraagt de agent een toegangstoken aan met behulp van zijn eigen agentidentiteit en referenties die worden beheerd via de blauwdruk voor de agentidentiteit. Het token wordt uitgegeven aan de agent-id (niet de gebruiker). Daarom is het beleid voor voorwaardelijke toegang gericht op de agentidentiteit in plaats van de gebruiker.

Beleid voor voorwaardelijke toegang configureren voor toegangsstroom voor toepassingen

Als u een beleid voor voorwaardelijke toegang wilt maken voor agents die met hun eigen identiteit werken, gebruikt u de volgende instellingen:

• Toewijzingen: In een agent-toegangsstroom wordt het toegangstoken uitgegeven aan de agentidentiteit (het tokenonderwerp), zodat u het beleid toewijst aan agentidentiteiten of aan de blauwdruk voor de agentidentiteit.
• Doelbronnen: selecteer de resources die de agentidentiteit nodig heeft om toegang te krijgen.
• Voorwaarden: Configureer of de agentidentiteit risico loopt. Zie voor meer informatie ID Protection voor agents.
• Toegangsbeheer: omdat deze agent toegang heeft tot resources met een eigen identiteit, is geen herstel mogelijk en is de enige beschikbare optie het blokkeren van toegang.

Gebruikersaccount van agent

Soms is het niet voldoende voor een agent om taken uit te voeren namens een gebruiker of met een eigen identiteit te werken. In bepaalde scenario's is een agent eigenlijk een gebruiker. Digitale werknemers die werken als teamleden met hun eigen postvakken, toegang tot chats en kunnen deelnemen aan gezamenlijke werkstromen als teamlid.

In dit model maakt een beheerder een gebruikersaccount in de directory en koppelt deze aan de identiteit van de agent. Van daaruit is het net als elk ander gebruikersaccount. Licenties kunnen worden toegewezen voor toegang tot Microsoft 365 resources, zoals postvakken en agenda's. Het account kan worden toegevoegd aan beheereenheden en beveiligingsgroepen, net als een menselijk gebruikersaccount.

Agenten die deze stroom gebruiken, worden soms 'digitale werknemer' of 'AI-teamgenoot' genoemd. Ze worden ook beschouwd als autonome agenten omdat ze geen gebruikersinterface voor interactie met mensen vereisen.

In dit model wordt het toegangstoken uitgegeven aan het gebruikersaccount van de agent (het tokenonderwerp) en wordt het beleid geëvalueerd op basis van het gebruikersaccount van de agent, niet de agentidentiteit. Tegenwoordig kunt u zich richten op het gebruikersaccount van een agent met één bereik: 'alle agents die als gebruiker fungeren'.

Beleid voor voorwaardelijke toegang configureren voor het gebruikersaccount van een agent

Als u een beleid voor voorwaardelijke toegang wilt maken voor het gebruikersaccount van een agent, gebruikt u de volgende instellingen:

• Toewijzingen: Kies in de gebruikersaccountstroom van een agent de optie Agents selecteren die actief zijn als gebruikers en selecteer vervolgens Alle agentgebruikers
• Doelbronnen: Alle middelen
• Voorwaarden: Configureer of de agentidentiteit risico loopt. Zie voor meer informatie ID Protection voor agenten.
• Toegangsbeheer: Omdat dit beleid betrekking heeft op het gebruikersaccount van een agent, is er geen oplossing voor verificatieuitdagingen, waardoor de enige beschikbare optie de toegang blokkeert

Selecteer de doelresource

Als u een doelresource in een beleid voor voorwaardelijke toegang wilt selecteren, moet de resource een ondernemingstoepassing (service-principal) hebben met de set machtigingen in uw Microsoft Entra ID-tenant. Dit beleid is van toepassing op alle resourcetypen, waaronder SharePoint Online, Exchange Online, Work IQ MCP-servers, de Azure MCP-server, de Microsoft 365 MCP-server, Microsoft Graph, Open API, MCP-servers, niet-Microsoft-hulpmiddelen en aangepaste hulpprogramma's die je bouwt.

De bedrijfstoepassing is vereist, ongeacht het gegevenstoegangspatroon, of agents toegang hebben namens een gebruiker, alleen voor toepassingen of het gebruikersaccount van een agent. Het type machtigingen dat wordt verleend, verschilt tussen toegang gedelegeerd door de gebruiker en applicatietoegang, maar de vereiste service-principalaccount is in alle gevallen van toepassing.

Sommige Microsoft-services vereisen een expliciete provisieerstap voordat ze in uw directory worden weergegeven. Schakel bijvoorbeeld de vereiste licentie in of voer een PowerShell-opdracht uit. Zie de relevante productdocumentatie voor meer informatie.

Voor aangepaste MCP-servers, open API-hulpprogramma's of een ander aangepast hulpprogrammatype, registreert u het hulpprogramma als een toepassing in Microsoft Entra ID en stelt u de set machtigingen (gedelegeerde of app-rollen) beschikbaar. Zie Een toepassing configureren om een web-API beschikbaar te maken voor meer informatie.

Voorwaardelijke toegang plannen

Het plannen van de implementatie van voorwaardelijke toegang is essentieel voor het bereiken van de toegangsstrategie van uw organisatie voor agents, gebruikers en resources. Beleidsregels voor voorwaardelijke toegang bieden aanzienlijke configuratieflexybiliteit. Deze flexibiliteit betekent echter dat u zorgvuldig moet plannen om ongewenste resultaten te voorkomen. Zie Een implementatie van voorwaardelijke toegang plannen voor meer informatie.

Als u de dekking voor alle toegangspatronen voor agents wilt garanderen, ontwerpt u uw beleid om de drie toegangspatronen te behandelen die in dit artikel worden beschreven: namens aangemelde gebruikers, agenttoegang met behulp van de eigen identiteit van de agent en agents die werken als gebruikers (gebruikersaccounts van agents).

Grenzen en beperkingen voor voorwaardelijke toegang

Beleid voor voorwaardelijke toegang is niet van toepassing wanneer:

• Een blauwdruk voor de agentidentiteit verwerft een token voor Microsoft Graph om een agentidentiteit of een gebruikersaccount voor de agent aan te maken.
  • Agent-blauwdrukken hebben beperkte functionaliteit. Ze kunnen niet onafhankelijk handelen om toegang te krijgen tot resources en zijn alleen betrokken bij het maken van agentidentiteiten en gebruikersaccounts van agents.
  • Agentische taken worden altijd uitgevoerd door de agentidentiteit.
• Een agentidentiteitsblauwdruk of agentidentiteit voert een tussenliggende tokenuitwisseling uit op het AAD Token Exchange Endpoint: Public-eindpunt (Resource ID: fb60f99c-7a34-4190-8149-302f77469936).
  • Tokens binnen het bereik van de AAD Token Exchange Endpoint: Public kunnen geen Microsoft Graph aanroepen.
  • Agentische stromen worden beveiligd omdat met voorwaardelijke toegang tokenverwerving wordt beschermd tegen de agentidentiteit of het gebruikersaccount van de agent.
• Standaardinstellingen voor beveiliging zijn ingeschakeld.
• Voorwaardelijke toegang beveiligt alleen resources die worden beveiligd door Microsoft Entra ID. Als een agent bijvoorbeeld toegang krijgt tot resources met behulp van een API-sleutel, wordt de Microsoft Entra ID verificatie- en tokenuitgiftepijplijn volledig overgeslagen en is beleid voor voorwaardelijke toegang niet van toepassing op deze resources.

De volgende configuraties worden momenteel niet ondersteund:

• Het afbakenen van een voorwaardelijk-toegangsbeleid om het gebruikersaccount van de agent op te nemen of uit te sluiten op basis van hun groepslidmaatschap en aangepaste beveiligingsattributen.
• Een beleid voor voorwaardelijke toegang dat is gericht op agentidentiteiten in een agent-naar-agentscenario met behulp van aangepaste beveiligingskenmerken, is niet van toepassing op het gebruikersaccount van de agent.
• Een beleid voor voorwaardelijke toegang gericht op agentidentiteiten in een agent-naar-agentscenario met behulp van agentidentiteitsblauwdruk omvat alleen de agentidentiteit, niet het gebruikersaccount van de agent.

Beleidsevaluatie onderzoeken met behulp van aanmeldingslogboeken

Beheerders kunnen de aanmeldingslogboeken gebruiken om te onderzoeken waarom beleid voor voorwaardelijke toegang wel of niet is toegepast. Voor agentspecifieke vermeldingen, filtert u op agentType. Sommige van deze gebeurtenissen worden weergegeven in de Gebruikers-aanmeldingen (niet-interactief) terwijl andere worden weergegeven onder Service-principal-aanmeldingen. Zie Microsoft Entra Agent-ID aanmeldings- en auditlogboeken voor meer informatie.

• Agentidentiteiten (actor) die toegang hebben tot resources → aanmeldingslogboeken van de service-principal → agentType: agentidentiteit
• Het gebruikersaccount van de agent die toegang heeft tot resources → aanmeldingen van niet-interactieve gebruikers → agentType: gebruikersaccount van agent
• Gebruikers die toegang krijgen tot agents → Gebruikersaanmeldingen

Volgende stappen

Meer informatie over het configureren van beleid voor voorwaardelijke toegang voor agentidentiteiten:

• Agents werken namens een aangemelde gebruiker
• Agents werken met hun eigen identiteit
• Agent fungeert als gebruiker