Warunkowy dostęp dla agentów

Dostęp warunkowy dla agentów to rozszerzenie aparatu zasad dostępu warunkowego, które kontroluje, w jaki sposób agenci uzyskują dostęp do zasobów chronionych przez Microsoft Entra ID. Łączy on sygnały w czasie rzeczywistym, takie jak kontekst użytkownika i agenta, urządzenie, lokalizacja i informacje o ryzyku, aby określić, kiedy zezwolić, zablokować lub ograniczyć dostęp, lub wymagać większej liczby kroków weryfikacji.

Zrozumienie wzorca dostępu używanego przez agenta pomaga wskazać właściwą tożsamość. Agent może działać w imieniu zalogowanego użytkownika, użyć własnej tożsamości agenta lub użyć własnego konta użytkownika agenta.

Dowiedz się więcej o dostępie warunkowym dla agentów:

Wymagania i licencjonowanie

Microsoft Entra ID dostęp warunkowy dla agentów wymaga jednego z następujących planów licencji:

  • Microsoft 365 E7, który obejmuje Agent 365 i Pakiet Microsoft Entra.
  • licencja Microsoft Agent 365 sparowana z co najmniej Microsoft Entra P1 lub Microsoft 365 E3.

Aby uzyskać więcej informacji, zobacz plany i cennik Microsoft Agent 365.

Jak dostęp warunkowy ocenia dostęp agenta

Aby uzyskać dostęp do zasobu, takiego jak plik SharePoint, serwer MCP lub usługa Open API, użytkownik lub agent żąda tokenu dostępu z Microsoft Entra ID.

Gdy zasady dostępu warunkowego mają zastosowanie, Microsoft Entra ID ocenia wymagania zasad przed wydaniem tokenu. Jeśli wymagania są spełnione, Microsoft Entra ID wystawia token. Zasób docelowy weryfikuje token i używa jego oświadczeń do podejmowania decyzji dotyczących autoryzacji.

Diagram przedstawiający wzorce dostępu do danych dla tożsamości agentów.

Każdy token dostępu ma jeden temat i jedną grupę odbiorców:

  • Temat: tożsamość, która odbiera token.
    • W przypadku dostępu delegowanego token reprezentuje użytkownika podczas identyfikowania wywołującej aplikacji lub agenta.
    • W dostępie wyłącznie aplikacyjnym tożsamość agenta jest podmiotem zabezpieczeń.
    • W dostępie agent–użytkownik podmiotem jest konto użytkownika agenta.
  • Odbiorca: zasób docelowy, dla którego jest przeznaczony token i który musi być zarejestrowany w usłudze Entra ID. Jeśli podmiot uzyskuje dostęp do wielu zasobów, zazwyczaj potrzebuje oddzielnego tokenu dla każdego zasobu.

Dostęp warunkowy ocenia zarówno temat, który żąda dostępu, jak i odbiorców, do których jest uzyskiwany dostęp. Ocenia zasady, gdy usługa Microsoft Entra ID wystawia lub odświeża token dostępu. Niektóre zasoby obsługują również Ciągłą ocenę dostępu, która może powodować egzekwowanie zasad w czasie zbliżonym do rzeczywistego w przypadku określonych zdarzeń.

Jak są podejmowane decyzje dotyczące dostępu warunkowego

Zasady dostępu warunkowego działają jak instrukcje if-then:

  • Jeśli warunki zdefiniowane w zasadach są spełnione, skonfigurowane mechanizmy kontroli dostępu są wymuszane.
  • Jeśli wymagane kontrolki są spełnione, zostanie udzielony dostęp.
  • Jeśli wymagane mechanizmy kontrolne nie są spełnione, dostęp zostanie odmówiony.

Na przykład organizacja może wymagać uwierzytelniania wieloskładnikowego, zanim użytkownik będzie mógł autoryzować agenta w celu uzyskania dostępu do poczty e-mail. Podobnie organizacja może skonfigurować zasady w celu blokowania dostępu od agentów zidentyfikowanych jako wysokiego ryzyka.

Gdy oceniany jest dostęp warunkowy

Dostęp warunkowy jest oceniany za każdym razem, gdy Microsoft Entra ID wystawia lub odświeża token dostępu. Niektóre zasoby obsługują również Ciągłą ocenę dostępu, która może powodować egzekwowanie zasad w czasie zbliżonym do rzeczywistego w przypadku określonych zdarzeń.

Wzorce dostępu agenta

Agenci mogą uzyskiwać dostęp do zasobów chronionych Microsoft Entra przy użyciu jednego z następujących wzorców:

Jeśli agent Wzorzec dostępu Obiekt zasad Guidance
Uzyskuje dostęp do zasobów podrzędnych dla zalogowanego użytkownika On-behalf-of (OBO), znany również jako dostęp delegowany Użytkownicy i grupy Przepływy OAuth agenta: w imieniu użytkownika
Uzyskuje dostęp do zasobów za pomocą własnej tożsamości agenta i bez zalogowanego użytkownika Dostęp wyłącznie aplikacyjny, znany również jako poświadczenia klienta lub dostęp wyłącznie aplikacyjny Tożsamość agenta lub model tożsamości agenta Zabezpieczanie agentów autonomicznych przy użyciu dostępu warunkowego
Uzyskuje dostęp do zasobów za pośrednictwem własnego konta użytkownika Dostęp użytkownika agenta Konto użytkownika agenta Zabezpieczanie agentów, którzy działają jako użytkownicy z dostępem warunkowym

Agent może używać więcej niż jednego wzorca dostępu. Utwórz oddzielne zasady dla każdego podmiotu tokenu używanego przez agenta. Zasady, które dotyczą tożsamości agenta, nie mają zastosowania do konta użytkownika agenta, a zasady, które dotyczą konta użytkownika agenta, nie mają zastosowania do tożsamości agenta.

Agenci, którzy działają w imieniu użytkownika

Najczęściej stosowanym modelem dostępu jest przepływ typu on-behalf-of (OBO). W przepływie OBO użytkownik loguje się do aplikacji agenta. Agent uzyskuje dostęp do zasobów podrzędnych przy użyciu tożsamości użytkownika i delegowanych uprawnień. Na przykład gdy agent odczytuje wiadomości e-mail, uzyskuje dostęp do skrzynki pocztowej w Twoim imieniu. Aby uzyskać więcej informacji o tym, jak działa przepływ OBO dla agentów, zobacz temat Przepływy OAuth dla agentów: On-behalf-of.

Uwaga / Notatka

Proces działający w imieniu użytkownika jest również nazywany dostępem delegowanym. „On-behalf-of” opisuje proces uwierzytelniania, a nie typ agenta. Ci agenci interakcyjni obejmują interfejs użytkownika na potrzeby interakcji z ludźmi. Każdy agent może używać tego przepływu, gdy zalogowany użytkownik jest obecny, a agent musi uzyskać dostęp do zasobów przy użyciu tożsamości i uprawnień tego użytkownika.

W tym przepływie agent nie może ponownie użyć oryginalnego tokenu użytkownika, ponieważ został wystawiony dla innej grupy odbiorców. Zamiast tego agent używa przepływu OBO do wymiany tokenów za pomocą Microsoft Entra ID, uzyskując nowy token o określonym zakresie dla zasobu docelowego. Ta wymiana tokenów podlega również ocenie w ramach dostępu warunkowego, co pozwala administratorom egzekwować szczegółowe mechanizmy kontroli dotyczące tego, do których zasobów agenci mogą uzyskiwać dostęp w imieniu użytkownika.

Ponieważ użytkownik jest tematem w tym przepływie, zasady dostępu warunkowego dotyczą użytkowników i grup, a nie tożsamości agentów.

Agenty działające jako aplikacje

Agenci mogą uzyskiwać dostęp do zasobów bez zalogowanego użytkownika. W takim przypadku agent uzyskuje dostęp do zasobu przy użyciu własnej tożsamości. Ten przepływ jest również nazywany przepływem poświadczeń klienta lub dostępem tylko do aplikacji. Wszystkie typy agentów mogą używać tego procesu pracy. Aby uzyskać więcej informacji na temat uwierzytelniania agentów za pomocą własnej tożsamości, zobacz Przepływy OAuth dla agentów: aplikacje autonomiczne.

Ten przepływ ma zastosowanie w następujących typowych scenariuszach:

  • Autonomiczni agenci, którzy działają niezależnie, działają w tle, reagują na zdarzenia lub są uruchamiani zgodnie z harmonogramem.
    • Na przykład agent, który generuje dzienny raport i wysyła wynik do grupy pracowników.
    • W tym scenariuszu nie ma użytkownika, a agent działa samodzielnie.
  • Agenci interaktywni korzystający z własnej tożsamości nie zawsze uzyskują dostęp do zasobów w imieniu użytkownika; czasami używają własnej tożsamości.
    • Na przykład, jeśli agent wywołuje usługę SMS na zapleczu, do której użytkownicy nie mają dostępu, przepływ OBO nie ma zastosowania, a agent uwierzytelnia się bezpośrednio we własnym imieniu.
  • Agenci opublikowani w Internecie do użytku publicznego nie uwierzytelniają użytkownika ani nie obsługują delegowania kontekstu użytkownika do zasobów firmy.

W tych scenariuszach agent żąda tokenu dostępu przy użyciu własnej tożsamości agenta i poświadczeń zarządzanych za pomocą schematu tożsamości agenta. Token jest wystawiany dla tożsamości agenta (a nie użytkownika). W związku z tym zasady dostępu warunkowego są ograniczone do tożsamości agenta, a nie użytkownika. Aby zapoznać się z konfiguracją zasad krok po kroku, zobacz Zabezpieczanie agentów autonomicznych przy użyciu dostępu warunkowego.

Agenci, którzy działają jako użytkownicy

Czasami nie wystarczy, aby agent wykonywał zadania w imieniu użytkownika lub działał z własną tożsamością. W niektórych scenariuszach agent ma własne konto użytkownika agenta , które pełni funkcję cyfrowego procesu roboczego z własną skrzynką pocztową, dostępem do czatu i możliwością udziału we współpracy przepływów pracy jako członek zespołu.

W tym modelu administrator tworzy konto użytkownika w katalogu i łączy je z tożsamością agenta. Z tego miejsca jest to jak każde inne konto użytkownika. Licencje można przypisać do Microsoft 365 zasobów, takich jak skrzynka pocztowa i kalendarz. Konto można dodać do jednostek administracyjnych i grup zabezpieczeń, podobnie jak konto użytkownika ludzkiego.

Agenci korzystający z tego przepływu są również traktowani jako agenci autonomiczni, ponieważ nie obejmują interfejsu użytkownika do interakcji z ludźmi. W tym modelu token dostępu jest wystawiany na koncie użytkownika agenta (podmiot tokenu), a zasady są oceniane względem konta użytkownika agenta, a nie tożsamości agenta. Aby uzyskać szczegółowe informacje na temat konfiguracji zasad, zobacz Dostęp warunkowy dla agentów autonomicznych. Aby uzyskać więcej informacji na temat przepływu OAuth użytkownika agenta, zobacz Przepływ OAuth użytkownika agenta.

Agenci działający w zarządzanych punktach końcowych, takich jak Windows 365 komputery w chmurze dla agentów mogą również podlegać zgodności urządzeń i zgodnym mechanizmom kontroli sieci. Użyj warunku Środowiska wykonywania agenta (wersja zapoznawcza), aby ograniczyć zakres tych zasad tylko do sesji opartych na punktach końcowych. Aby uzyskać więcej informacji, zobacz Wymaganie zgodnego urządzenia dla kont użytkowników agentów.

Zasady dostępu warunkowego i strategie tożsamości agenta

Oprócz określonych wzorców dostępu agenta można również wybrać strategie tożsamości agenta , aby zastosować zasady dostępu warunkowego do klasy agentów. Szablon tożsamości agenta definiuje model konfiguracji i zarządzania dla tożsamości agentów tworzonych na jego podstawie. Zasada dotycząca szablonu ma zastosowanie do wszystkich tożsamości agentów utworzonych na podstawie tego szablonu, w tym tożsamości agentów utworzonych w późniejszym czasie.

Na poniższym diagramie pokazano, że dostęp otrzymują tylko tożsamości agentów skojarzone z strategią "A"; wszyscy inni agenci są wykluczani i blokowani.

Diagram przedstawiający zasady dostępu warunkowego zastosowane do tożsamości agentów z jednej strategii.

Załóżmy na przykład projekt, w którym masz kilku agentów, a każdy z nich ma własny cel. Niektóre działają niezależnie, podczas gdy inne współpracują z innymi agentami (A2A) w celu wykonywania zadań. Jeśli wszystkie zostały utworzone w ramach tej samej strategii, jedna zasada zastosowana do tej strategii wymusza spójne mechanizmy kontroli dostępu w całej kolekcji.

Dostęp warunkowy oparty na atrybutach

Wraz ze wzrostem liczby tożsamości agentów indywidualne zarządzanie każdą z nich w ramach każdej polityki staje się nie do utrzymania. Niestandardowe atrybuty zabezpieczeń umożliwiają kategoryzowanie tożsamości agentów i zasobów przy użyciu etykiet specyficznych dla firmy, a następnie określanie tych atrybutów w zasadach dostępu warunkowego. Zasady są automatycznie stosowane do każdego agenta z pasującymi atrybutami, w tym do tych dodanych w przyszłości.

Diagram przedstawiający przepływ dostępu warunkowego dla tożsamości agenta.

Aby zapoznać się z przykładem zasad, zobacz Zezwalanie zatwierdzonym agentom przy użyciu niestandardowych atrybutów zabezpieczeń.

Granice i ograniczenia

Zasady dostępu warunkowego nie mają zastosowania w następujących przypadkach:

  • Szablon tożsamości agenta uzyskuje token dla Microsoft Graph w celu utworzenia tożsamości agenta lub konta jego użytkownika.
    • Strategie agentów mają ograniczoną funkcjonalność. Nie mogą oni działać niezależnie w celu uzyskania dostępu do zasobów i są zaangażowani tylko w tworzenie tożsamości agentów i kont użytkowników agentów.
    • Zadania agenta są zawsze wykonywane przy użyciu konta agenta.
  • Strategia tożsamości agenta lub tożsamość agenta wykonuje wymianę tokenów pośrednich w punkcie końcowym AAD Token Exchange Endpoint: Public (identyfikator zasobu: fb60f99c-7a34-4190-8149-302f77469936).
    • Tokeny ograniczone do AAD Token Exchange Endpoint: Public nie mogą wywoływać Microsoft Graph.
    • Przepływy agentów są chronione, ponieważ Dostęp warunkowy chroni uzyskiwanie tokenu przez tożsamość agenta lub konto użytkownika agenta.
  • Wartości domyślne zabezpieczeń są włączone.
  • Dostęp warunkowy chroni tylko zasoby zabezpieczone przez Microsoft Entra ID. Na przykład, jeśli agent uzyskuje dostęp do zasobów przy użyciu klucza interfejsu API, całkowicie pomija uwierzytelnianie Microsoft Entra ID oraz proces wystawiania tokenów, a zasady dostępu warunkowego nie będą stosowane.

Następujące konfiguracje nie są obecnie obsługiwane:

  • Zasady skierowane do wszystkich użytkowników nie obejmują kont użytkownika agenta.
  • Określanie zakresu zasad dostępu warunkowego w celu uwzględnienia lub wykluczenia konta użytkownika agenta na podstawie członkostwa w grupie
  • Zasada dostępu warunkowego ukierunkowana na tożsamości agenta nie będzie mieć zastosowania do konta użytkownika agenta.
  • Zasada dostępu warunkowego ukierunkowana na tożsamości agentów przy użyciu szablonu tożsamości agenta obejmuje wyłącznie tożsamość agenta, a nie konto użytkownika agenta.

Treści powiązane

  • Last updated on