Bedingter Zugriff für Agenten

Bedingter Zugriff für Agents ist eine Erweiterung des Richtlinienmoduls für bedingten Zugriff, das steuert, wie Agents auf Ressourcen zugreifen, die durch Microsoft Entra ID geschützt sind. Sie vereint Echtzeitsignale wie Kontext, Gerät, Standort und Risikoinformationen des Benutzers, um zu bestimmen, wann der Zugriff zugelassen, blockiert oder eingeschränkt werden soll oder weitere Überprüfungsschritte erforderlich sind.

Wenn Sie das Zugriffsmuster des Agents verstehen, können Sie auf die richtige Identität abzielen. Ein Agent kann im Namen eines angemeldeten Benutzers handeln, seine eigene Agent-Identität verwenden oder sein eigenes Agent-Benutzerkonto verwenden.

Erfahren Sie mehr über bedingten Zugriff für Agents:

• Allgemeine Übersicht über bedingten Zugriff: Was ist bedingter Zugriff?
• Leitfaden zum Verwalten von Agentidentitäten in Ihrer Organisation: Verwalten von Agentidentitäten in Ihrer Organisation.
• So legen Sie Agentidentitäten im Bedingten Zugriff als Ziel fest
• Schützen Sie autonome Agenten mit bedingtem Zugriff
• Agentbenutzer mit Microsoft Entra Conditional Access schützen

Anforderungen und Lizenzierung

Microsoft Entra ID bedingter Zugriff für Agents erfordert einen der folgenden Lizenzpläne:

• Microsoft 365 E7, einschließlich Agent 365 und Microsoft Entra Suite.
• Microsoft Agent 365-Lizenz gekoppelt mit mindestens Microsoft Entra P1 oder Microsoft 365 E3.

Weitere Informationen finden Sie unter Microsoft Agent 365-Pläne und -Preise.

Wie der bedingte Zugriff den Agentzugriff auswertet

Um auf eine Ressource wie eine SharePoint Datei, einen MCP-Server oder einen Open-API-Dienst zuzugreifen, fordert ein Benutzer oder Agent ein Zugriffstoken von Microsoft Entra ID an.

Wenn eine Richtlinie für bedingten Zugriff gilt, wertet Microsoft Entra ID die Richtlinienanforderungen aus, bevor das Token ausgibt. Wenn die Anforderungen erfüllt sind, gibt Microsoft Entra ID das Token aus. Die Zielressource überprüft das Token und verwendet seine Ansprüche, um Autorisierungsentscheidungen zu treffen.

Jedes Zugriffstoken verfügt über einen Betreff und eine Zielgruppe:

• Betreff: Die Identität, die das Token empfängt.
  • Im delegierten Zugriff stellt das Token den Benutzer dar und identifiziert gleichzeitig die aufrufende Anwendung oder den Aufrufenden Agent.
  • Im reinen Anwendungszugriff ist die Agentidentität der Betreff.
  • Im Agent-Benutzerzugriff ist das Benutzerkonto des Agents der Betreff.
• Zielgruppe: Die Zielressource, für die das Token bestimmt ist, die in Entra ID registriert werden muss. Wenn ein Subjekt auf mehrere Ressourcen zugreift, benötigt es in der Regel für jede Ressource ein eigenes Token.

Bedingter Zugriff wertet sowohl den Betreff aus, der den Zugriff anfordert, als auch die Zielgruppe, auf die zugegriffen wird. Es wertet Richtlinien aus, wenn Microsoft Entra ID ein Zugriffstoken ausstellt oder aktualisiert. Einige Ressourcen unterstützen auch die kontinuierliche Zugriffsauswertung, die die Nah-Echtzeit-Erzwingung für bestimmte Ereignisse auslösen kann.

Wie Entscheidungen über den bedingten Zugriff getroffen werden

Richtlinien für bedingten Zugriff funktionieren wie if-then-Anweisungen:

• Wenn die in einer Richtlinie definierten Bedingungen erfüllt sind, werden die konfigurierten Zugriffssteuerungen erzwungen.
• Wenn die erforderlichen Steuerelemente erfüllt sind, wird der Zugriff gewährt.
• Wenn die erforderlichen Steuerelemente nicht erfüllt sind, wird der Zugriff verweigert.

Beispielsweise kann eine Organisation eine mehrstufige Authentifizierung erfordern, bevor ein Benutzer einen Agent für den Zugriff auf seine E-Mails autorisieren kann. Ebenso kann eine Organisation eine Richtlinie konfigurieren, um den Zugriff von Agents zu blockieren, die als hohes Risiko identifiziert wurden.

Wenn der bedingte Zugriff ausgewertet wird

Bedingter Zugriff wird jedes Mal ausgewertet, wenn Microsoft Entra ID ein Zugriffstoken ausstellt oder aktualisiert. Einige Ressourcen unterstützen auch die kontinuierliche Zugriffsauswertung, die die Nah-Echtzeit-Erzwingung für bestimmte Ereignisse auslösen kann.

Agent-Zugriffsmuster

Agents können nach einem der folgenden Muster auf durch Microsoft Entra geschützte Ressourcen zugreifen:

Ein Agent kann mehrere Zugriffsmuster verwenden. Erstellen Sie für jedes Token-Subjekt, das der Agent verwendet, eine eigene Richtlinie. Eine Richtlinie, die auf eine Agentidentität abzielt, gilt nicht für das Benutzerkonto des Agents, und eine Richtlinie, die auf das Benutzerkonto des Agents abzielt, gilt nicht für die Agentidentität.

Agents, die im Namen eines Benutzers handeln

Das am häufigsten verwendete Zugriffsmuster ist der On-Behalf-Of-(OBO)-Flow. Im OBO-Fluss meldet sich ein Benutzer bei einer Agentanwendung an. Der Agent greift auf downstream-Ressourcen mit der Identität und delegierten Berechtigungen des Benutzers zu. Wenn beispielsweise ein Agent Ihre E-Mails liest, greift er in Ihrem Auftrag auf Ihr Postfach zu. Weitere Informationen dazu, wie der OBO-Flow für Agents funktioniert, finden Sie unter Agent OAuth flows: On-behalf-of.

In diesem Fluss kann der Agent das ursprüngliche Token des Benutzers nicht wiederverwenden, da es für eine andere Zielgruppe ausgestellt wurde. Stattdessen verwendet der Agent den OBO-Fluss, um Token mit Microsoft Entra ID auszutauschen und ein neues Token für die Zielressource abzurufen. Dieser Tokenaustausch wird auch durch Conditional Access geprüft, sodass Administratoren granulare Zugriffssteuerungen dafür erzwingen können, auf welche Ressourcen Agents im Namen des Benutzers zugreifen dürfen.

Da der angemeldete Benutzer in diesem Fluss das Token-Subjekt ist, wertet Conditional Access Richtlinien aus, die diesem Benutzer zugewiesen sind, unabhängig davon, ob der Benutzer direkt adressiert wird, über eine Gruppe oder über einen anderen unterstützten Mechanismus zur Benutzeradressierung. Wenn Sie eine Agent-Identität als Richtliniensubjekt auswählen, werden Agentanforderungen, die im Namen des Benutzers getätigt wurden, nicht abgedeckt.

Als Anwendungen fungierende Agents

Agents greifen möglicherweise ohne einen angemeldeten Benutzer auf Ressourcen zu. In diesem Fall greift der Agent auf die Ressource mit eigener Identität zu. Dieser Ablauf wird auch als Client-Credentials-Ablauf oder App-Only-Zugriff bezeichnet. Alle Arten von Agenten können diesen Ablauf verwenden. Weitere Informationen dazu, wie Agents sich mit ihrer eigenen Identität authentifizieren, finden Sie unter Agent OAuth Flows: Autonome Apps.

Dieser Fluss gilt in den folgenden gängigen Szenarien:

• Autonome Agents, die unabhängig arbeiten, werden im Hintergrund ausgeführt, reagieren auf Ereignisse oder werden nach einem Zeitplan ausgeführt.
  • Beispielsweise ein Agent, der einen täglichen Bericht generiert und das Ergebnis an eine Gruppe von Mitarbeitern sendet.
  • In diesem Szenario ist kein Benutzer vorhanden, und der Agent arbeitet eigenständig.
• Interaktive Agents, die ihre eigene Identität verwenden, greifen nicht immer auf Ressourcen im Namen eines Benutzers zu; manchmal verwenden sie ihre eigene Identität.
  • Wenn beispielsweise ein Agent einen Hintergrund-SMS-Dienst aufruft, auf den Benutzer keinen Zugriff haben, gilt der OBO-Prozess nicht und der Agent authentifiziert sich direkt.
• Im Web veröffentlichte Agents authentifizieren den Benutzer nicht oder unterstützen nicht das Delegieren des Benutzerkontexts an Unternehmensressourcen.

In diesen Szenarien fordert der Agent ein Zugriffstoken mithilfe seiner eigenen Agent-Identität und Anmeldeinformationen an, die über den Agentidentitäts-Blueprint verwaltet werden. Das Token wird an die Agentidentität (nicht an den Benutzer) ausgegeben. Daher sind Richtlinien für bedingten Zugriff auf die Agentidentität und nicht auf den Benutzer begrenzt. Eine schrittweise Richtlinienkonfiguration finden Sie unter "Sichere autonome Agents mit bedingtem Zugriff".

Agents, die als Benutzer fungieren

Manchmal reicht es nicht aus, dass ein Agent Aufgaben im Auftrag eines Benutzers ausführt oder mit seiner eigenen Identität arbeitet. In bestimmten Szenarien verfügt ein Agent über ein eigenes Agent-Benutzerkonto , das als digitaler Mitarbeiter mit eigenem Postfach, Zugriff auf Chats und die Möglichkeit zur Teilnahme an workflows für die Zusammenarbeit als Teammitglied fungiert.

In diesem Modell erstellt ein Administrator ein Benutzerkonto im Verzeichnis und verknüpft es mit der Identität des Agents. Von dort aus ist es wie jedes andere Benutzerkonto. Lizenzen können zugewiesen werden, um auf Microsoft 365 Ressourcen wie ein Postfach und einen Kalender zuzugreifen. Das Konto kann administrativen Einheiten und Sicherheitsgruppen wie einem menschlichen Benutzerkonto hinzugefügt werden.

Agents, die diesen Fluss verwenden, gelten auch als autonome Agents, da sie keine Benutzeroberfläche für die menschliche Interaktion einbeziehen. In diesem Modell wird das Zugriffstoken an das Benutzerkonto des Agenten (das Token-Subjekt) ausgegeben, und die Richtlinie wird gegen das Benutzerkonto des Agenten und nicht gegen die Agentenidentität ausgewertet. Eine schrittweise Richtlinienkonfiguration finden Sie unter "Bedingter Zugriff für autonome Agents". Weitere Informationen zum OAuth-Fluss des Agentbenutzers finden Sie unter OAuth-Ablauf des Agentbenutzers.

Agents, die auf verwalteten Endpunkten wie Windows 365 Cloud PCs for Agents laufen, können auch Gerätekonformitäts- und Netzwerkzugriffssteuerungen unterliegen. Verwenden Sie die Bedingung „Agent-Ausführungsumgebungen (Vorschau)“, um diese Richtlinien nur auf endpunktbasierte Sitzungen anzuwenden. Weitere Informationen finden Sie unter "Anfordern eines kompatiblen Geräts für die Benutzerkonten von Agents".

Richtlinien für den Bedingten Zugriff und Entwürfe für Agent-Identitäten

Zusätzlich zu den spezifischen Agentzugriffsmustern können Sie auch Identitätsvorlagen für Agenten auswählen, um Richtlinien für den bedingten Zugriff auf eine Agentklasse anzuwenden. Ein Agentidentitäts-Blueprint definiert das Konfigurations- und Governancemodell für darin erstellte Agentidentitäten. Eine Richtlinie, die auf einen Blueprint abzielt, gilt für alle Agentidentitäten, die aus diesem Blueprint erstellt wurden, einschließlich der später erstellten Agentidentitäten.

Das folgende Diagramm zeigt, dass nur Agentidentitäten, die mit Blueprint "A" verknüpft sind, Zugriff gewährt werden; alle anderen Agents werden ausgeschlossen und blockiert.

Stellen Sie sich beispielsweise ein Projekt vor, bei dem Sie über mehrere Agenten verfügen, die jeweils ihren eigenen Zweck haben. Einige arbeiten unabhängig, während andere mit anderen Agents (A2A) zusammenarbeiten, um Aufgaben auszuführen. Wenn sie alle unter demselben Blueprint erstellt werden, erzwingt eine einzelne Richtlinie, die auf diesen Blueprint angewendet wird, einheitliche Zugriffssteuerungen in der gesamten Sammlung.

Attributgesteuerter bedingter Zugriff

Wenn die Anzahl der Agentidentitäten wächst, wird die individuelle Verwaltung der einzelnen Identitäten in jeder Richtlinie unhaltbar. Mit benutzerdefinierten Sicherheitsattributen können Sie Agentidentitäten und -ressourcen mit geschäftsspezifischen Bezeichnungen kategorisieren und diese Attribute dann in Richtlinien für bedingten Zugriff als Ziel festlegen. Richtlinien gelten automatisch für jeden Agent mit übereinstimmenden Attributen, einschließlich derer, die in Zukunft hinzugefügt wurden.

Ein Richtlinienbeispiel finden Sie unter Zulassen genehmigter Agents mithilfe von benutzerdefinierten Sicherheitsattributen.

Grenzen und Einschränkungen

Richtlinien für bedingten Zugriff gelten nicht, wenn:

• Ein Blueprint für Agent-Identitäten bezieht ein Token für Microsoft Graph, um eine Agent-Identität oder ein Benutzerkonto des Agents zu erstellen.
  • Agent-Blueprints verfügen über eingeschränkte Funktionalität. Sie können nicht unabhängig auf Ressourcen zugreifen und sind nur an der Erstellung von Agentidentitäten und den Benutzerkonten der Agents beteiligt.
  • Agent-Aufgaben werden immer von der Agent-Identität ausgeführt.
• Ein Blueprint für eine Agent-Identität oder eine Agent-Identität führt einen intermediären Token-Austausch am AAD Token Exchange Endpoint: Public-Endpunkt durch (Ressourcen-ID: fb60f99c-7a34-4190-8149-302f77469936).
  • Tokens, die sich auf die AAD Token Exchange Endpoint: Public beschränken, können Microsoft Graph nicht aufrufen.
  • Agent-Abläufe sind geschützt, da der Bedingte Zugriff den Tokenerwerb schützt, der über die Identität des Agents oder dessen Benutzerkonto erfolgt.
• Sicherheitsstandardwerte sind aktiviert.
• Bedingter Zugriff schützt nur durch Microsoft Entra ID gesicherte Ressourcen. Wenn beispielsweise ein Agent mit einem API-Schlüssel auf Ressourcen zugreift, wird die Microsoft Entra ID Authentifizierungs- und Tokenausstellungspipeline vollständig umgangen, und Richtlinien für bedingten Zugriff gelten nicht für sie.

Die folgenden Konfigurationen werden derzeit nicht unterstützt:

• Richtlinien, die über die Zuweisung "Benutzer" eingegrenzt sind, gelten nicht für Agent-Benutzerkonten. Diese Grenze gilt unabhängig davon, ob die Richtlinie auf alle Benutzer, ausgewählte Benutzer, Gruppen, Verzeichnisrollen oder externe Benutzer ausgerichtet ist. Um Agent-Benutzerkonten zu schützen, erstellen Sie eine Richtlinie, die für "Agent Users" gilt.
• Festlegen einer Richtlinie für bedingten Zugriff, um das Benutzerkonto des Agenten basierend auf seiner Gruppenmitgliedschaft einzuschließen oder auszuschließen.
• Eine Richtlinie für bedingten Zugriff, die auf Agentidentitäten abzielt, gilt nicht für das Benutzerkonto des Agents.
• Eine Richtlinie für bedingten Zugriff, die unter Verwendung der Agent-Identitätsblaupause auf Agent-Identitäten abzielt, umfasst nur die Agent-Identität, nicht das Benutzerkonto des Agents.

Wenn Sie stattdessen Richtlinien auf Agentbenutzer anwenden möchten, wählen Sie unter Assignments>Users, agents, or workload identities die Option Agents aus, und wählen Sie dann alle oder bestimmte Agentbenutzer aus.

Verwandte Inhalte

• Ziel-Agent-Identitäten in Richtlinien für bedingten Zugriff
• Schützen Sie autonome Agenten mit bedingtem Zugriff
• Sichere Agents, die als Benutzer mit bedingtem Zugriff fungieren