Kluczowe wnioski
- Microsoft Entra może automatycznie blokować agenty AI oznaczone jako wysokiego ryzyka, zanim uzyskają one dostęp do zasobów.
- Polityka dostępu warunkowego ukierunkowana na tożsamości agentów zapewnia egzekwowanie zasad na poziomie uwierzytelniania, uniemożliwiając agentom stwarzającym zagrożenie uzyskanie tokenów.
- Uruchomienie reguły najpierw w trybie wyłącznie raportowania pozwala zidentyfikować fałszywe alarmy i uniknąć zakłócenia prawidłowego przebiegu procesów opartych na sztucznej inteligencji.
- Oceny ryzyka agentów są realizowane przez usługę Microsoft Entra ID Protection, która na bieżąco weryfikuje tożsamości agentów i może natychmiast uruchomić odpowiednie środki w przypadku wzrostu poziomu ryzyka.
- Ochrona ta dotyczy wyłącznie tożsamości agentów; agenci działający w ramach uprawnień użytkownika typu „w imieniu” (OBO) wymagają oddzielnych mechanizmów kontroli dostępu warunkowego ukierunkowanych na użytkownika.
Autonomiczne agenty AI uwierzytelniają się w Twojej dzierżawie Microsoft Entra przy użyciu własnej tożsamości, niezależnej od jakiegokolwiek użytkownika, a agens, którego bezpieczeństwo zostało naruszone lub który zachowuje się nieprawidłowo, stanowi w praktyce zagrożenie – jest to osoba atakująca dysponująca ważnymi danymi uwierzytelniającymi, działająca z prędkością maszyny.
Usługa Microsoft Entra ID Protection ocenia poziom ryzyka związanego z tożsamościami agentów w taki sam sposób, jak w przypadku użytkowników, co pozwala na blokowanie agentów wysokiego ryzyka już na etapie uwierzytelniania, zanim jeszcze uzyskają dostęp do zasobów.
Ten blog stanowi szczegółowy przewodnik dotyczący konfiguracji odpowiedniej polityki bezpieczeństwa dla agentów AI, która pomoże zablokować dostęp do platformy Microsoft Entra agentom wysokiego ryzyka.
Blokuj czynniki wysokiego ryzyka za pomocą zasad dostępu warunkowego
To jest właściwy blok techniczny. Polityka dostępu warunkowego ma na celu egzekwowanie kontroli dostępu na poziomie uwierzytelniania, a nie tylko w interfejsie użytkownika.
Uwaga: Niniejsza polityka nie obejmuje agentów działających w imieniu użytkownika. Jeśli użytkownik zaloguje się do agenta, agent może uzyskać dostęp do zasobów, korzystając z uprawnień przekazanych przez tego użytkownika. W tym scenariuszu zakresem polityki dostępu warunkowego jest użytkownik, a nie tożsamość agenta, więc mechanizm zarządzania ryzykiem agenta nie zostaje uruchomiony.
Kroki:
1. Zaloguj się na stronie entra.microsoft.com jako administrator globalny.
2. Przejdź do sekcji Entra ID > Dostęp warunkowy > Zasady.
3. Kliknij opcję „Nowa polityka”.
4. Nadaj nazwę zasadzie (na przykład: CA-Block-Entra-Admin-Center-Non-Admins)
5. Kliknij pozycję „Użytkownicy i agenci”. W sekcji „Do kogo ma zastosowanie ta polityka?” wybierz opcję „Agenci”:
- Uwzględnij: wszystkie tożsamości agentów
6. W sekcji „Zasoby docelowe” wybierz op cję „Zasoby” (wcześniej „Aplikacje w chmurze”).
7. Wybierz opcję „Uwzględnij” > „Wszystkie zasoby” (wcześniej „Wszystkie aplikacje w chmurze”).
8. Kliknij w sekcji „Warunki”.
9. Kliknij w sekcji „Ryzyko agenta” (Podgląd) i wybierz opcję „Konfiguruj” > „Tak” > „Wysokie”.
10. Kliknij przycisk „Gotowe”.
11. W sekcji „Uprawnienia” wybierz opcję „Zablokuj dostęp”.
12. Ustaw opcję „Włącz zasadę” na „Włączone” (lub „Tylko raportowanie” w przypadku wstępnych testów).
13. Kliknij przycisk „Utwórz”.
Najlepsze praktyki: egzekwowanie zasad
Przez co najmniej tydzień uruchom tę politykę w trybie „Tylko raportowanie”, a dopiero potem przełącz ją do trybu „Włączone”. W tym czasie sprawdź sekcję Entra ID > Monitorowanie > Logi logowania i zastosuj filtr według tożsamości agentów, aby zobaczyć, jakie działania zostałyby zablokowane.
Zwróć szczególną uwagę na legalne podmioty, które zostały oznaczone jako podejrzane, ponieważ są to fałszywe alarmy i należy je rozwiązać przed rozpoczęciem egzekwowania zasad. Ustaw opcję na „Włączone” dopiero wtedy, gdy upewnisz się, że zasada prawidłowo identyfikuje odpowiednie podmioty i nie zakłóca rzeczywistych procesów.
Dlaczego to ma znaczenie
W miarę jak agenci AI uzyskują dostęp do systemów przedsiębiorstwa, stają się oni w praktyce podmiotami niebędącymi ludźmi w ramach danej instancji. Zhakowany agent może wykorzystać prawidłowe dane uwierzytelniające do uzyskania dostępu do zasobów, automatyzacji działań oraz zwiększania ryzyka w tempie, które człowiekowi trudno sobie wyobrazić. Ograniczenie dostępu agentom wysokiego ryzyka stanowi ważną warstwę zabezpieczeń z kilku powodów:
- Zatrzymuje zagrożenie, zanim dotrze ono do danych: kontrola odbywa się na poziomie uwierzytelniania, więc agent, który został oznaczony jako podejrzany, w ogóle nie otrzymuje tokenu, a użytkownik nie musi usuwać skutków jego działania po tym, jak dotknął on już zasobów.
- Działa to automatycznie i natychmiastowo: blokada uruchamia się na podstawie sygnału ryzyka z systemu Identity Protection, więc w momencie, gdy agent otrzyma ocenę „Wysokie”, w tym gdy potwierdzisz, że został on przejęty, blokada zostaje uruchomiona bez udziału człowieka.
- Rozwiązanie to sprawdza się tam, gdzie ręczna weryfikacja zawodzi: nowi agenci pojawiają się szybciej, niż ktokolwiek jest w stanie ich sprawdzić. Blokowanie tych, którzy stanowią wysokie ryzyko, pozwala silnikowi oceny ryzyka dokonać selekcji zamiast ręcznego sprawdzania każdego agenta.
- To działa precyzyjnie: dobrze ukierunkowana polityka blokuje wyłącznie agentów wysokiego ryzyka, nie zakłócając pracy użytkowników i agentów o niskim ryzyku, co zapewnia skuteczną ochronę bez utraty wydajności.
Najczęściej zadawane pytania
Co oznacza pojęcie „ryzyko agenta” i w jaki sposób jest ono oceniane?
Ryzyko związane z agentami pochodzi z usługi Microsoft Entra ID Protection, która ocenia tożsamości agentów w taki sam sposób, jak ocenia użytkowników i logowania stwarzające ryzyko. Możesz przejrzeć oznaczonych agentów w raporcie „Ryzykowne agenty” w centrum administracyjnym Entra, gdzie wykryte zagrożenia są widoczne przez maksymalnie 90 dni wraz ze szczegółami dotyczącymi nazwy wyświetlanej agenta, stanu ryzyka, poziomu ryzyka, typu i sponsorów. Agenta można również ręcznie ustawić jako wysokiego ryzyka, gdy potwierdzisz, że został on przejęty.
Co dzieje się z legalnym agentem, który zostaje uznany za podmiot wysokiego ryzyka?
Został zablokowany w zakresie żądania tokenów, tak jak każdy inny podmiot wysokiego ryzyka, co stanowi fałszywy alarm i może zakłócić rzeczywisty przebieg pracy. Dlatego warto najpierw uruchomić tę politykę w trybie wyłącznie raportowania: włącz ją w tym trybie na co najmniej tydzień przed rozpoczęciem egzekwowania i sprawdź logi logowania, aby zobaczyć, co zostałoby wykryte.
Czy niniejsza polityka dotyczy agentów działających w imieniu użytkownika?
Nie. W schemacie działania typu „w imieniu” (OBO) użytkownik loguje się do aplikacji agenta, a agent uzyskuje dostęp do zasobów przy użyciu uprawnień przekazanych przez użytkownika. Podmiotem w ramach funkcji dostępu warunkowego w tym schemacie jest użytkownik, a nie tożsamość agenta, więc ocena ryzyka związanego z agentem nie ma miejsca, a ta zasada nie ma żadnego wpływu. Aby kontrolować, do jakich zasobów mają dostęp agenci działający w trybie OBO, potrzebna jest zasada dostępu warunkowego skierowana do użytkownika, której zakres obejmuje odpowiednie zasoby.
- Czym jest raportowanie TLS? Jak raporty TLS protokołu SMTP wykrywają niepowodzenia w dostarczaniu wiadomości e-mail – 9 lipca 2026 r.
- Najlepsze serwery DMARC MCP w 2026 roku: Połącz sztuczną inteligencję z danymi dotyczącymi uwierzytelniania wiadomości e-mail – 9 lipca 2026 r.
- Studium przypadku DMARC MSP: Firma The Great Geek rozszerza ofertę usług w zakresie bezpieczeństwa poczty elektronicznej dla małych i średnich przedsiębiorstw dzięki PowerDMARC – 25 czerwca 2026 r.

