Voorwaardelijke toegang voor agents

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

Voorwaardelijke toegang voor agents vereist Microsoft Entra ID P1 of P2 en een Microsoft Agent 365-licentie voor elke gebruiker. Het afdwingen van agent 365-licenties is binnenkort beschikbaar. Netwerkbeheeropties voor agents vereisen Microsoft Entra Internettoegang. Zie What is Microsoft Entra Agent-ID voor meer informatie.

Meer informatie over voorwaardelijke toegang voor agents:

• Overzicht op hoog niveau van voorwaardelijke toegang: Wat is voorwaardelijke toegang?
• Handleiding voor het beheren van agentidentiteiten in uw organisatie: Agentidentiteiten in uw organisatie beheren.
• Agentidentiteiten als doel instellen in Voorwaardelijke toegang
• Beleid configureren voor autonome agenttoegang

Hoe voorwaardelijke toegang agenttoegangsaanvragen evalueert

Voor toegang tot een bedrijfsresource, zoals SharePoint-bestand, MCP-servers of Open API-services, vraagt een gebruiker of agent eerst een toegangstoken aan bij Microsoft Entra ID.

Wanneer beleid voor voorwaardelijke toegang van toepassing is, evalueert Microsoft Entra ID de geconfigureerde beleidsvereisten voordat het token wordt uitgegeven. Als aan de vereisten wordt voldaan, wordt er een toegangstoken uitgegeven. Het token wordt vervolgens gepresenteerd aan de doelresource, waarmee het token wordt gevalideerd en de claims worden gebruikt om autorisatiebeslissingen te nemen.

In het volgende diagram ziet u dit proces.

Hoe onderwerpen en doelgroepen worden gebruikt

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

Onderwerp: De identiteit die het token ontvangt.

• In scenario's met gedelegeerde toegang vertegenwoordigt het token de gebruiker en identificeert het ook de aanroepende toepassing of agent.
• In scenario's met alleen toepassingen is de toepassing of autonome agent het onderwerp.
• In scenario's met gebruikersaccounts van de agent is het gebruikersaccount van de agent het onderwerp.

Doelgroep: De doelresource waarvoor het token is bedoeld.

• De resource moet worden geregistreerd in Microsoft Entra ID.
• Als een onderwerp toegang moet hebben tot meerdere resources (bijvoorbeeld meerdere MCP-servers of API's), is doorgaans een afzonderlijk toegangstoken vereist voor elke resource, elk met een eigen doelgroep en machtigingen.

Beleidsregels voor voorwaardelijke toegang worden geëvalueerd op basis van zowel de entiteit die toegang aanvraagt als de doelresource waartoe toegang wordt gevraagd.

Hoe beslissingen voor voorwaardelijke toegang worden genomen

Beleidsregels voor voorwaardelijke toegang werken als als-dan-instructies:

• Als aan de voorwaarden in een beleidsregel wordt voldaan, worden de geconfigureerde toegangscontroles afgedwongen.
• Als aan de vereiste controles is voldaan, wordt toegang verleend.
• Als niet aan de vereiste besturingselementen wordt voldaan, wordt de toegang geweigerd.

Een organisatie kan bijvoorbeeld meervoudige verificatie vereisen voordat een gebruiker een agent kan machtigen om toegang te krijgen tot hun e-mail. Op dezelfde manier kan een organisatie een beleid configureren om de toegang van agents te blokkeren die zijn geïdentificeerd als een hoog risico.

Wanneer voorwaardelijke toegang wordt geëvalueerd

Voorwaardelijke toegang wordt geëvalueerd wanneer Microsoft Entra ID problemen ondervindt of een toegangstoken vernieuwt. Sommige resources bieden ook ondersteuning voor continue toegangsevaluatie, waardoor afdwinging in bijna realtime kan worden geactiveerd voor specifieke gebeurtenissen.

Toegangspatronen voor agents

Agents hebben toegang tot Microsoft Entra beveiligde resources met behulp van een van de volgende patronen:

Agents die namens een gebruiker handelen

Het meest voorkomende toegangspatroon is de on-behalf-of-flow (OBO). In deze stroom meldt een gebruiker zich aan bij een agenttoepassing en heeft de agent toegang tot downstreambronnen met behulp van de identiteit en gedelegeerde machtigingen van de gebruiker. Wanneer een agent bijvoorbeeld uw e-mailberichten leest, krijgt deze namens u toegang tot uw postvak. Zie OAuth-flows voor agents: On-behalf-of voor meer informatie over hoe de OBO-flow werkt voor agents.

In deze stroom kan de agent het oorspronkelijke token van de gebruiker niet opnieuw gebruiken omdat het is uitgegeven voor een andere doelgroep. In plaats daarvan gebruikt de agent de OBO-stroom om tokens te uitwisselen met Microsoft Entra ID, waarbij een nieuw token wordt verkregen dat is afgestemd op de doelresource. Deze tokenuitwisseling wordt ook geëvalueerd door voorwaardelijke toegang, zodat beheerders gedetailleerde controles afdwingen waartoe resources agents namens de gebruiker toegang hebben.

Omdat de gebruiker het onderwerp in deze stroom is, richt het beleid voor voorwaardelijke toegang zich op gebruikers en groepen, niet op agentidentiteiten.

Agents die fungeren als een toepassing

Agents hebben mogelijk toegang tot resources zonder een aangemelde gebruiker. In dit geval heeft de agent toegang tot de resource met een 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. Zie Agent OAuth-stromen: Autonome apps voor meer informatie over hoe agents worden geverifieerd met hun eigen identiteit.

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

• Autonome agents die zelfstandig werken werken op de achtergrond, reageren op gebeurtenissen of worden volgens een schema uitgevoerd.
  • 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 , 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 zijn gepubliceerd op internet voor openbaar gebruik , 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. Zie Voorwaardelijke toegang voor autonome agents voor stapsgewijze beleidsconfiguratie.

Agents die fungeren als gebruiker

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 heeft een agent een eigen gebruikersaccount van een agent dat fungeert als een digitale werknemer met een eigen postvak, toegang tot chatten en de mogelijkheid om als teamlid deel te nemen aan werkstromen voor samenwerking.

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 een postvak en agenda. Het account kan worden toegevoegd aan beheereenheden en beveiligingsgroepen, net als een menselijk gebruikersaccount.

Agents die deze stroom gebruiken, worden ook beschouwd als autonome agents, omdat ze geen gebruikersinterface voor menselijke interactie 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. Zie Voorwaardelijke toegang voor autonome agents voor stapsgewijze beleidsconfiguratie. Zie OAuth-stroom voor agentgebruikers voor meer informatie over de OAuth-stroom voor agentgebruikers.

Agents die worden uitgevoerd op beheerde eindpunten, zoals Windows 365 Cloud-pc's voor agents kunnen ook worden onderworpen aan apparaatcompatibiliteit en compatibele netwerkcontroles. Gebruik de voorwaarde Agentuitvoeringsomgevingen (Preview) om deze beleidsregels alleen toe te passen op sessies op basis van eindpunten. Zie Een compatibel apparaat vereisen voor gebruikersaccounts van agenten voor meer informatie.

Blauwdrukken voor voorwaardelijke toegang en agentidentiteit

Naast de specifieke toegangspatronen voor agents kunt u ook identiteitsblauwdrukken voor agents selecteren om Conditional Access-beleid toe te passen op een categorie agents. 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 agentidentiteiten die ermee zijn afgeleid, inclusief nieuwe identiteiten die in de toekomst worden toegevoegd. Richten op de blauwdruk voor de identiteit van de agent omvat niet de gebruikersaccounts van agenten.

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.

Kenmerkgestuurde voorwaardelijke toegang

Naarmate het aantal agentidentiteiten groeit, wordt het afzonderlijk beheren van elk beleid onhoudbaar. Met aangepaste beveiligingskenmerken kunt u agentidentiteiten en -resources categoriseren met bedrijfsspecifieke labels en deze kenmerken vervolgens richten op beleidsregels voor voorwaardelijke toegang. Beleidsregels zijn automatisch van toepassing op elke agent met overeenkomende kenmerken, inclusief de kenmerken die in de toekomst zijn toegevoegd.

Zie Voorwaardelijke toegang voor autonome agents voor een volledig overzicht van het maken van aangepaste beveiligingskenmerken en het gebruik ervan in een beleid voor voorwaardelijke toegang.

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.
  • Agenttaken worden altijd uitgevoerd door de agent-id.
• 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.
  • Agentwerkstromen zijn beveiligd omdat Voorwaardelijke toegang het verkrijgen van tokens via de identiteit van de agent of het gebruikersaccount van de agent beschermt.
• 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:

• Beleidsregels die zijn gericht op alle gebruikers, bevatten geen gebruikersaccounts van de agent.
• Het bereik van beleid voor voorwaardelijke toegang bepalen om het gebruikersaccount van een agent op basis van groepslidmaatschap op te nemen of uit te sluiten
• Een beleid voor voorwaardelijke toegang dat is gericht op agentidentiteiten, is niet van toepassing op het gebruikersaccount van de agent.
• Een beleid voor voorwaardelijke toegang dat is gericht op agentidentiteiten met behulp van blauwdruk voor agentidentiteiten, heeft alleen betrekking op de agentidentiteit, niet op het gebruikersaccount van de agent.

Volgende stappen

• Agentidentiteiten als doel instellen in Voorwaardelijke toegang
• Beleid configureren voor autonome agenttoegang