Hoe u AI-agenten van Microsoft Entra kunt blokkeren

Belangrijkste Conclusies

Microsoft Entra kan AI-agenten die als hoog risico zijn gemarkeerd automatisch blokkeren voordat ze toegang krijgen tot bronnen.
Een beleid voor voorwaardelijke toegang dat gericht is op de identiteit van agents zorgt voor handhaving op het authenticatieniveau, waardoor wordt voorkomen dat risicovolle agents tokens verkrijgen.
Door het beleid eerst in de modus ‘Alleen rapportage’ uit te voeren, kunt u valse positieven opsporen en voorkomen dat legitieme, door AI aangestuurde workflows worden verstoord.
De risicobeoordelingen van agents worden mogelijk gemaakt door Microsoft Entra ID Protection, dat de identiteiten van agents continu controleert en onmiddellijk maatregelen kan nemen wanneer het risiconiveau stijgt.
Deze beveiliging geldt alleen voor agentidentiteiten; voor agenten die werken met 'on-behalf-of' (OBO)-gebruikersrechten zijn aparte, op de gebruiker gerichte controles voor voorwaardelijke toegang vereist.

Autonome AI-agenten verifiëren zich met hun eigen identiteit in uw Microsoft Entra-tenant, los van welke gebruiker dan ook, en een gecompromitteerde of zich misdragende agent is in feite een aanvaller die over geldige inloggegevens beschikt en zich met de snelheid van een machine voortbeweegt.

Microsoft Entra ID Protection beoordeelt de risico's van agentidentiteiten op dezelfde manier als bij gebruikers, en u kunt agenten met een hoog risico al bij de authenticatie blokkeren, nog voordat ze toegang krijgen tot een bron.

Deze blog is een stapsgewijze handleiding voor het instellen van het juiste beveiligingsbeleid voor AI-agents, waarmee u kunt voorkomen dat agents met een hoog risico toegang krijgen tot Microsoft Entra.

Blokkeer risicovolle actoren met een beleid voor voorwaardelijke toegang

Dit is het juiste technische onderdeel. Een beleid voor voorwaardelijke toegang is erop gericht de toegang op authenticatieniveau af te dwingen, en niet alleen op het niveau van de gebruikersinterface.

Opmerking: Agents die namens anderen handelen, vallen niet onder dit beleid. Als een gebruiker zich aanmeldt bij een agent, kan de agent toegang krijgen tot bronnen met behulp van de gedelegeerde machtigingen van die gebruiker. In dit scenario geldt het beleid voor voorwaardelijke toegang voor de gebruiker, niet voor de identiteit van de agent, waardoor het agentrisico niet in werking treedt.

Stappen:

1. Meld u aan bij entra.microsoft.com als algemeen beheerder.

2. Ga naar Entra ID > Voorwaardelijke toegang > Beleid.

3. Klik op Nieuw beleid.

4. Geef het beleid een naam (bijvoorbeeld: CA-Block-Entra-Admin-Center-Non-Admins)

5. Klik op ‘Gebruikers en agenten’. Selecteer onder ‘Waarop is dit beleid van toepassing?’ de optie ‘Agenten’:

Opnemen: alle identiteiten van agenten

6. Selecteer onder 'Doelbronnen' de optie 'Bronnen' (voorheen 'Cloudapps').

7. Selecteer ‘Opnemen’ > ‘Alle bronnen’ (voorheen ‘Alle cloudapps’).

8. Klik onder 'Voorwaarden'.

9. Klik onder 'Agentrisico (Voorbeeld) ' en selecteer 'Configureren' > 'Ja' > 'Hoog'.

10. Klik op ‘Gereed’.

11. Selecteer onder 'Toegang' de optie 'Toegang blokkeren'.

12. Stel het beleid ‘Inschakelen’ in op ‘Aan’ (of ‘Alleen rapporteren’ voor een eerste test).

13. Klik op Maken.

Beste praktijk: handhaving van beleid

Voer het beleid minstens een week lang uit in de modus ‘Alleen rapportage’ voordat u overschakelt naar ‘Aan’. Controleer gedurende die periode onder Entra ID > Monitoring > Aanmeldingslogboeken en filter op agentidentiteiten om te zien wat er geblokkeerd zou zijn.

Let vooral op legitieme agents die worden gemarkeerd, want dit zijn je valse positieven, en die wil je oplossen voordat de handhaving ingaat. Zet de optie pas op ‘Aan’ als je er zeker van bent dat het beleid de juiste identiteiten detecteert en geen echte workflows verstoort.

Waarom dit van belang is

Naarmate AI-agenten toegang krijgen tot bedrijfssystemen, worden ze in feite niet-menselijke identiteiten binnen uw tenant. Een gehackte agent kan geldige inloggegevens gebruiken om toegang te krijgen tot bronnen, acties te automatiseren en risico’s te vergroten in een tempo dat mensen nauwelijks kunnen bevatten. Het beperken van de toegang voor risicovolle agenten biedt om verschillende redenen een belangrijke verdedigingslaag:

Het houdt de dreiging tegen voordat deze uw gegevens bereikt: de handhaving vindt plaats op het authenticatieniveau, zodat een gemarkeerde agent het token überhaupt niet krijgt en u niet hoeft op te ruimen nadat deze al een bron heeft geraakt.
Het gebeurt automatisch en onmiddellijk: de blokkering wordt geactiveerd op basis van het risicosignaal van Identity Protection, dus zodra een account de score ‘Hoog’ krijgt – ook wanneer u zelf bevestigt dat het account is gehackt – wordt de blokkering automatisch doorgevoerd, zonder dat er menselijke tussenkomst nodig is.
Het schaalbaar is waar handmatige controle dat niet is: er komen steeds meer agents bij dan je kunt bijhouden. Door de risicovolle agents te blokkeren, laat je de risicomotor de selectie doen, in plaats van dat je elke agent zelf handmatig moet controleren.
Het werkt nauwkeurig: een goed afgestemd beleid blokkeert alleen agents die een hoog risico vormen, terwijl uw gebruikers en gezonde agents ongemoeid blijven. Dit biedt krachtige bescherming zonder dat dit ten koste gaat van de productiviteit.

Veelgestelde Vragen

Wat houdt 'makelaarsrisico' in, en hoe wordt dit beoordeeld?

Het agentrisico is afkomstig van Microsoft Entra ID Protection, dat de identiteiten van agenten op dezelfde manier beoordeelt als risicovolle gebruikers en aanmeldingen. U kunt gemarkeerde agents bekijken in het rapport Risky Agents in het Entra-beheercentrum, waar risicodetecties tot 90 dagen zichtbaar blijven, met details over de weergavenaam, risicostatus, risiconiveau, type en sponsors van de agent. Een agent kan ook handmatig worden ingesteld op hoog risico wanneer u bevestigt dat een agent is gecompromitteerd.

Wat gebeurt er met een legitieme agent die als risicovol wordt aangemerkt?

Het wordt, net als elke andere risicovolle agent, geblokkeerd bij het aanvragen van tokens. Dit is een vals-positief resultaat dat een echte workflow kan verstoren. Daarom voer je het beleid eerst uit in de modus ‘Alleen rapporteren’: schakel het minstens een week voor de daadwerkelijke handhaving in deze modus in en controleer de aanmeldingslogboeken om te zien wat er zou zijn opgemerkt.

Heeft dit beleid gevolgen voor agenten die namens een gebruiker optreden?

Nee. In de ‘on-behalf-of’ (OBO)-workflow meldt een gebruiker zich aan bij de agent-applicatie, waarna de agent toegang krijgt tot bronnen met behulp van de gedelegeerde rechten van de gebruiker. Het subject van de voorwaardelijke toegang in die workflow is de gebruiker, niet de identiteit van de agent. Daarom wordt het agentrisico niet beoordeeld en heeft dit beleid geen effect. Om te bepalen waartoe OBO-agenten toegang hebben, hebt u een op de gebruiker gericht beleid voor voorwaardelijke toegang nodig dat is afgestemd op de relevante bronnen.

Over
Laatste berichten

Ahona Rudra

Expert op het gebied van domein- en e-mailbeveiliging bij PowerDMARC

Ahona is marketingmanager bij PowerDMARC en heeft meer dan vijf jaar ervaring met het schrijven over cybersecurity, gespecialiseerd in domein- en e-mailbeveiliging. Ahona heeft een masterdiploma in journalistiek en communicatie, en heeft sinds 2019 haar carrière in de beveiligingssector verder uitgebouwd.

Laatste berichten van Ahona Rudra (Bekijk alle berichten)

Hoe u risicovolle AI-agenten in Microsoft Entra kunt blokkeren