Kontrola dostępu na poziomie dokumentu w Wyszukiwanie AI platformy Azure

Note

Wyszukiwanie AI platformy Azure jest dostępna za pośrednictwem portalu Azure, interfejsów API REST i Azure SDKs. Jest także podstawą Foundry IQ — zarządzanej warstwy wiedzy, która przekształca treści przedsiębiorstwa w bazy wiedzy wielokrotnego użytku z uwzględnieniem uprawnień dla agentów w portalu Microsoft Foundry.

Ważna

Funkcje, możliwości lub właściwości oznaczone (wersja zapoznawcza) nie są objęte umową dotyczącą poziomu usług, nie są zalecane w przypadku obciążeń produkcyjnych i mogą ulec zmianie lub ograniczeniu, zanim staną się one ogólnie dostępne. Warunki Wyszukiwanie AI platformy Azure wersji zapoznawczej mają zastosowanie do wszystkich funkcji w wersji zapoznawczej, niezależnie od tego, czy jest ona autonomiczna, czy częścią ogólnie dostępnej funkcji.

Wyszukiwanie AI platformy Azure obsługuje kontrolę dostępu na poziomie dokumentu, umożliwiając organizacjom wymuszanie precyzyjnych uprawnień na poziomie dokumentu od pozyskiwania danych przez wykonywanie zapytań. Ta funkcja jest niezbędna do tworzenia bezpiecznych systemów agentowych sztucznej inteligencji, uzasadniania danych, ekstrakcji rozszerzonej generacji (RAG) oraz rozwiązań do wyszukiwania w przedsiębiorstwie, które wymagają kontroli autoryzacji na poziomie dokumentu.

Metody kontroli dostępu na poziomie dokumentu

Wyszukiwanie AI platformy Azure zapewnia cztery podstawowe podejścia do wymuszania uprawnień na poziomie dokumentu, z których każda jest odpowiednia dla różnych źródeł danych i modeli tożsamości.

Podejście Opis
Filtry zabezpieczeń Porównanie ciągów. Aplikacja przekazuje tożsamość użytkownika lub grupy jako ciąg, który wypełnia filtr zapytania, z wyłączeniem wszystkich dokumentów, które nie są zgodne z ciągiem.

Filtry zabezpieczeń to technika osiągnięcia kontroli dostępu na poziomie dokumentu. Takie podejście nie jest powiązane z interfejsem API, więc można użyć dowolnej wersji lub pakietu.
ACL podobny do POSIX / zakresy RBAC (wersja próbna) Podmiot zabezpieczeń Microsoft Entra za tokenem zapytania jest porównywany z metadanymi uprawnień dokumentów zwracanych w wynikach wyszukiwania, z wyłączeniem dokumentów, które nie są zgodne z uprawnieniami. Uprawnienia listy kontroli dostępu mają zastosowanie do katalogów i plików usługi Azure Data Lake Storage Gen2 (ADLS). Zakresy kontroli dostępu opartej na rolach odnoszą się do zawartości usługi ADLS Gen2 oraz obiektów blob w Azure.

Wbudowana obsługa dostępu opartego na tożsamościach na poziomie dokumentu jest dostępna w wersji zapoznawczej, dostępna w interfejsach API REST i pakietach Azure SDK w wersji zapoznawczej, które udostępniają tę funkcję. Aby uzyskać dowody na obsługę funkcji, zapoznaj się ze szczegółami obsługi wersji zestawu SDK.
Microsoft Purview etykiety poufności (wersja zapoznawcza) Indeksator wyodrębnia etykiety poufności zdefiniowane w Microsoft Purview z obsługiwanych źródeł danych (Azure Blob Storage, ADLS Gen2, SharePoint w Microsoft 365, OneLake). Te etykiety są przechowywane jako metadane i oceniane podczas zapytań, aby wymusić dostęp użytkowników na podstawie tokenów Microsoft Entra i przypisań polityk Purview. Etykiety są również udostępniane za pośrednictwem źródeł wiedzy i odpowiedzi generowanej przez wyszukiwanie agentowe, co umożliwia agentom AI i aplikacjom czatowym korzystającym z bazy wiedzy otrzymywanie takiego samego filtrowania uwzględniającego etykiety. To podejście dostosowuje autoryzację Wyszukiwanie AI platformy Azure do modelu Microsoft Information Protection w Twoim przedsiębiorstwie.
SharePoint w listach ACL Microsoft 365 (wersja zapoznawcza) Wyszukiwanie AI platformy Azure indeksatory wyodrębniają metadane uprawnień z obsługiwanej zawartości SharePoint i używają ich do sprawdzania dostępu w czasie wykonywania zapytań. Aby uzyskać informacje o obsługiwanej zawartości, podmiotach zabezpieczeń, relacjach grup, zachowaniu synchronizacji i uprawnieniach, zobacz Używanie indeksatora SharePoint do pozyskiwania metadanych uprawnień.

W przypadku indeksowanych źródeł wiedzy nie można używać jednocześnie opcji ingestionPermissionOptions i assetStore. W związku z tym obsługa obrazów (wersja zapoznawcza) nie jest dostępna, gdy jest włączone natywne pozyskiwanie uprawnień na poziomie dokumentu.

Wybieranie podejścia

Użyj poniższych kryteriów, aby zidentyfikować podejście, które najlepiej pasuje do źródła danych, modelu tożsamości i wymagań dotyczących zgodności.

Scenario Zalecane podejście Dlaczego
Niestandardowy system tożsamości, architektura zabezpieczeń inna niż Microsoft lub dowolny indeks oparty na modelu wypychania. Filtry zabezpieczeń Niezależny od interfejsu API, ogólnie dostępny i oparty na prostym dopasowaniu ciągów.
Zawartość w ADLS Gen2 lub Azure Blob Storage z istniejącymi przypisaniami ACL lub RBAC. Zakresy ACL typu POSIX / RBAC Natywna integracja z usługą Microsoft Entra; egzekwowanie uprawnień podczas wykonywania zapytań wykorzystuje metadane uprawnień zapisane w indeksie przez udokumentowany mechanizm synchronizacji.
Zawartość przedsiębiorstwa podlega już zasadom ochrony informacji Microsoft Purview. Etykiety poufności Microsoft Purview Ponownie wykorzystuje scentralizowane przypisania klasyfikacji i zasad w usłudze Wyszukiwanie AI platformy Azure.
Zawartość źródłowa z SharePoint w Microsoft 365 (biblioteki, listy, strony witryny ASPX). SharePoint w listach ACL Microsoft 365 Respektuje natywne uprawnienia programu SharePoint, w tym grupy witryn programu SharePoint.

Wzorzec ograniczania dostępu za pomocą filtrów

W przypadku scenariuszy, w których integracja natywnych zakresów ACL/RBAC nie jest opłacalna, użyj filtrów ciągów zabezpieczeń, aby przyciąć wyniki na podstawie kryteriów wykluczania. Wzorzec zawiera następujące składniki:

  • Aby przechowywać tożsamości użytkowników lub grup, utwórz pole ciągu w indeksie.
  • Załaduj indeks przy użyciu dokumentów źródłowych, które zawierają skojarzone ACL.
  • Uwzględnij wyrażenie filtrujące w logice zapytania w celu dopasowania ciągu.
  • Podczas kwerendy uzyskaj tożsamość podmiotu wywołującego.
  • Przekaż tożsamość obiektu wywołującego jako ciąg filtru.
  • Wyniki są przycinane, aby wykluczyć wszystkie dopasowania, które nie zawierają ciągu tożsamości użytkownika lub grupy.

Możesz użyć interfejsów API modelu push lub pull. Ponieważ takie podejście jest niezależne od interfejsu API, wystarczy potwierdzić, że indeks i zapytanie mają prawidłowe ciągi (tożsamości) dla kroku filtrowania.

Takie podejście jest przydatne w przypadku systemów z niestandardowymi modelami dostępu lub strukturami zabezpieczeń innych niż Microsoft. Aby uzyskać więcej informacji na temat tego podejścia, zobacz Filtry bezpieczeństwa do filtrowania wyników w Wyszukiwanie AI platformy Azure.

Wzorzec natywnej obsługi listy ACL i zakresu kontroli dostępu opartej na rolach (wersja zapoznawcza)

Natywna obsługa jest oparta na użytkownikach i grupach Microsoft Entra powiązanych z dokumentami, które chcesz indeksować i przeprowadzać zapytania.

kontenery usługi Azure Data Lake Storage (ADLS) Gen2 obsługują listy ACL w kontenerze i plikach. W przypadku usługi ADLS Gen2 zachowywanie zakresu RBAC na poziomie dokumentu jest natywnie obsługiwane w przypadku używania indeksatora usługi ADLS Gen2 lub źródła wiedzy obiektu blob (obsługuje usługę ADLS Gen2) i interfejsu API w wersji zapoznawczej do pobierania zawartości. W przypadku obiektów blob Azure, korzystając z indeksatora Azure blob lub źródła wiedzy, zachowywanie zakresu RBAC odbywa się na poziomie kontenera.

W przypadku treści zabezpieczonych mechanizmem ACL używaj dostępu grupowego zamiast indywidualnego dostępu użytkowników, aby ułatwić zarządzanie. Wzorzec zawiera następujące składniki:

Aplikacja kliencka otrzymuje uprawnienia do odczytu do indeksu za pomocą roli Czytelnik danych indeksu wyszukiwania lub Współautor danych indeksu wyszukiwania . Dostęp w czasie zapytania jest określany przez metadane uprawnień użytkownika lub grupy w indeksowanej zawartości. Zapytania zawierające filtr uprawnień przekazują token użytkownika lub grupy, tak jak x-ms-query-source-authorization w nagłówku żądania. Jeśli używasz filtrów uprawnień w czasie wykonywania zapytania, Wyszukiwanie AI platformy Azure sprawdza, czy istnieją dwie rzeczy:

  • Najpierw sprawdza uprawnienia Czytelnik danych indeksu wyszukiwania , które umożliwia aplikacji klienckiej dostęp do indeksu.

  • Po drugie, biorąc pod uwagę dodatkowy token w żądaniu, sprawdza uprawnienia użytkownika lub grupy w dokumentach zwracanych w wynikach wyszukiwania, z wyłączeniem tych, które nie są zgodne.

Aby dodać metadane uprawnień do indeksu, użyj interfejsu API modelu push, przesyłając dokumenty JSON do indeksu wyszukiwania, przy czym treść żądania zawiera pole tekstowe z listami ACL podobnymi do POSIX dla każdego dokumentu. Ważną różnicą między tym podejściem a przycinaniem zabezpieczeń jest to, że metadane filtru uprawnień w indeksie i zapytaniu są rozpoznawane jako uwierzytelnianie Microsoft Entra ID, podczas gdy przycinanie zabezpieczeń jest prostym porównaniem ciągów tekstowych. Ponadto możesz użyć zestawu Graph SDK do pobrania tożsamości.

Możesz również użyć API indeksatora w modelu ściągania, jeśli źródłem danych jest Azure Data Lake Storage (ADLS) Gen2 a kod wywołuje API w wersji zapoznawczej na potrzeby indeksowania.

Pobierz metadane uprawnień ACL podczas pozyskiwania danych (wersja zapoznawcza)

Sposób pobierania uprawnień ACL różni się w zależności od tego, czy przesyłasz zestaw danych dokumentów, czy też używasz indeksatora usługi ADLS Gen2.

Zacznij od interfejsu API w wersji zapoznawczej, który udostępnia funkcję:

W przypadku podejścia modelu wypychania:

  1. Upewnij się, że schemat indeksu został utworzony przy użyciu zestawu SDK wersji zapoznawczej lub wersji wstępnej oraz czy schemat ma filtry uprawnień.
  2. Rozważ użycie zestawu SDK Microsoft Graph w celu uzyskania tożsamości grup lub użytkowników.
  3. Użyj interfejsu API Index lub równoważnego interfejsu API Azure SDK, aby wypchnąć dokumenty i skojarzone z nimi metadane uprawnień do indeksu wyszukiwania.

W przypadku modelu ściągania indeksatora ADLS Gen2 lub obiektu blob źródła wiedzy (ADLS Gen2):

  1. Sprawdź, czy pliki w katalogu są zabezpieczone przy użyciu modelu kontroli dostępu usługi ADLS Gen2.
  2. Użyj Indexers - Create (REST API), Knowledge Sources - Create (REST API) lub równoważnego interfejsu API zestawu Azure SDK, aby utworzyć indeksator, indeks i źródło danych.

Jeśli zestaw umiejętności dzieli dokumenty, na przykład przy użyciu umiejętności Text Split na potrzeby zintegrowanej wektoryzacji, pola metadanych uprawnień są przenoszone z mapowań pól indeksatora do projekcji indeksu. Zobacz Wybór miejsca wypełniania pól ACL.

Wzorzec dla SharePoint w Microsoft 365 podstawowego pozyskiwania uprawnień ACL (wersja zapoznawcza)

W przypadku indeksowanej zawartości SharePoint Wyszukiwanie AI platformy Azure mogą przechowywać uprawnienia źródła jako metadane i używać ich do filtrowania wyników zapytania. Możesz uzyskać dostęp do tej funkcji w wersji zapoznawczej za pośrednictwem indeksatora SharePoint w usłudze Microsoft 365 oraz najnowszego interfejsu API REST lub równoważnego pakietu SDK w wersji zapoznawczej.

Aby uzyskać informacje o wymaganiach dotyczących uprawnień, obsługiwanych relacjach grup, synchronizacji uprawnień i ograniczeniach, zobacz Używanie indeksatora SharePoint do pozyskiwania metadanych uprawnień.

Jeśli zestaw umiejętności dzieli dokumenty na fragmenty (na przykład za pomocą umiejętności Text Split na potrzeby zintegrowanego wektoryzowania), pola ACL są przenoszone z mapowań pól indeksatora do projekcji indeksu. Zobacz Wybór miejsca wypełniania pól ACL.

Wzorzec etykiet klasyfikacji poufności Microsoft Purview (wersja zapoznawcza)

Po włączeniu pozyskiwania etykiet usługa Wyszukiwanie AI platformy Azure wyodrębnia metadane dotyczące poufności z obsługiwanych źródeł danych. Te źródła danych obejmują Azure Blob Storage, Azure Data Lake Storage Gen2 (ADLS Gen2), SharePoint w Microsoft 365 i Microsoft OneLake. Wyodrębnione etykiety są przechowywane w indeksie wraz z zawartością dokumentu.

W czasie wykonywania zapytania Wyszukiwanie AI platformy Azure sprawdza etykietę poufności każdego dokumentu, token Microsoft Entra użytkownika i zasady usługi Purview organizacji w celu określenia dostępu. System zwraca dokumenty tylko wtedy, gdy tożsamość użytkownika i uprawnienia oparte na etykietach zezwalają na dostęp zgodnie ze skonfigurowanymi zasadami usługi Purview.

Ten wzorzec zawiera następujące składniki:

  • Skonfiguruj indeks, źródło danych i indeksator (do celów planowania) przy użyciu najnowszego interfejsu API REST w wersji zapoznawczej lub zestawu SDK w wersji zapoznawczej obsługującego pozyskiwanie etykiet usługi Purview.
  • Włącz tożsamość zarządzaną przypisaną przez system w usłudze wyszukiwania. Tożsamości zarządzane przypisane przez użytkownika nie są obsługiwane na potrzeby wyodrębniania etykiet Purview — podwyższone uprawnienia Purview musi mieć własna tożsamość usługi. Następnie poproś administratora globalnego dzierżawy lub administratora ról uprzywilejowanych o przyznanie wymaganego dostępu, aby umożliwić usłudze wyszukiwania uwierzytelnianie w Microsoft Purview i wyodrębnianie metadanych etykiet.
  • Zastosuj etykiety poufności do dokumentów przed indeksowaniem, aby system mógł je rozpoznać i zachować podczas importowania.
  • W czasie zapytania dołącz prawidłowy token Microsoft Entra za pośrednictwem nagłówka x-ms-query-source-authorization do każdego żądania zapytania. Wyszukiwanie AI platformy Azure ocenia token i skojarzone metadane etykiety w celu wymuszania kontroli dostępu opartej na etykietach.

Wymuszanie etykiet poufności usługi Purview jest ograniczone do scenariuszy z pojedynczą dzierżawą i wymaga uwierzytelniania opartego na mechanizmie RBAC. W wersji zapoznawczej jest obsługiwana tylko za pośrednictwem interfejsu API REST i Azure SDKs. Interfejsy API funkcji Autocomplete i Suggest nie są obecnie dostępne dla indeksów z włączoną usługą Purview.

Gdzie są wyświetlane etykiety poufności

Zanim system będzie mógł wymusić etykiety w czasie zapytania lub zwrócić je w odpowiedziach, należy najpierw zsynchronizować metadane etykiety z indeksem. Obie ścieżki zużycia opisane w tej sekcji zależą od tego kroku synchronizacji. Etykiety można synchronizować, konfigurując indeksator Wyszukiwanie AI platformy Azure bezpośrednio względem obsługiwanego źródła danych lub włączając równoważną opcję pozyskiwania podczas tworzenia źródła wiedzy. W obu przypadkach środowisko musi spełniać wymagania wstępne konfiguracji synchronizacji metadanych etykiet poufności (tożsamość zarządzana, kontrola dostępu oparta na rolach (RBAC) w usłudze wyszukiwania oraz wymagane uprawnienia Microsoft Purview i uprawnienia do źródła danych). Aby skonfigurować indeksator od początku do końca, zobacz Używanie indeksatorów Wyszukiwanie AI platformy Azure do importowania etykiet poufności Microsoft Purview. W przypadku pozyskiwania danych sterowanego źródłem wiedzy ustaw ingestionPermissionOptions tak, aby uwzględniało sensitivityLabel podczas tworzenia źródła wiedzy.

Po zsynchronizowaniu etykiet dwie ścieżki zapytania używają tych samych metadanych etykiety indeksowanej. Wybierz ścieżkę zgodną z tym, jak aplikacja wywołuje Wyszukiwanie AI platformy Azure:

Jeśli źródło wiedzy wskazuje na fragmentowany indeks, na przykład zasilany za pomocą zintegrowanej wektoryzacji lub niestandardowej umiejętności Text Split, zestaw umiejętności musi również przypisać etykietę poufności do każdego wiersza fragmentu. Bez tej projekcji odwołania na poziomie fragmentu nie są filtrowane.

Aby uzyskać więcej informacji, zobacz Użyj indeksatory Wyszukiwanie AI platformy Azure do pozyskiwania etykiet poufności Microsoft Purview.

Wymuszanie uprawnień na poziomie dokumentu w czasie wykonywania zapytania (wersja zapoznawcza)

Wymuszanie wykonywania zapytań na podstawie tokenów to funkcja przekrojowa, która ma zastosowanie do zakresów ACL podobnych do POSIX i RBAC, etykiet poufności Microsoft Purview oraz wzorców list ACL programu SharePoint w Microsoft 365. Korzystając z natywnych zapytań opartych na tokenach, Wyszukiwanie AI platformy Azure weryfikuje token Microsoft Entra obiektu wywołującego dla każdego żądania i przycina zestawy wyników tylko do dokumentów, do których obiekt wywołujący jest autoryzowany do odczytu zgodnie z listami ACL dokumentów, o ile metadane listy ACL dokumentu są synchronizowane z indeksem.

Po dołączeniu tokenu użytkownika do żądania zapytania za pośrednictwem nagłówka x-ms-query-source-authorization, Wyszukiwanie AI platformy Azure:

  1. Wyodrębnia z tokenu atrybuty użytkownika, grupy i zakresu.
  2. Porównuje te oświadczenia z metadanymi dotyczącymi uprawnień przechowywanymi wraz z indeksowanymi dokumentami (wpisy ACL, zakresy RBAC, przypisania etykiet usługi Purview lub listy ACL platformy SharePoint).
  3. Zwraca tylko dokumenty, których zsynchronizowane metadane uprawnień przyznają dostęp osobie wywołującej.

Wymuszanie czasu zapytania ocenia oświadczenia Microsoft Entra obiektu wywołującego względem metadanych uprawnień, które są już przechowywane w indeksie. Zmiany uprawnień w systemie źródłowym (członkostwo w grupie Microsoft Entra, listy kontroli dostępu (ACL) usługi ADLS Gen2, przypisania etykiet usługi Purview lub listy kontroli dostępu (ACL) w programie SharePoint) są odzwierciedlane w wynikach wyszukiwania dopiero po zsynchronizowaniu tych metadanych z indeksem za pośrednictwem mechanizmu właściwego dla danego źródła, na przykład podczas kolejnego uruchomienia indeksatora, aktualizacji za pośrednictwem interfejsu Push API lub odświeżenia inicjowanego przez usługę Purview. W usłudze SharePoint zmiany list ACL dla elementów z unikatowymi uprawnieniami są wykrywane przyrostowo podczas każdego pomyślnego uruchomienia indeksatora, począwszy od wersji interfejsu API REST 2026-05-01-preview, natomiast zmiany dziedziczone z zakresów nadrzędnych (witryna, biblioteka, lista lub folder) wymagają jawnego wymuszenia odświeżenia. Aby uzyskać więcej informacji, zobacz Synchronizowanie uprawnień między indeksowaną i źródłową zawartością.

Instrukcje dotyczące kompleksowej implementacji zapytań można znaleźć w artykule Wymuszanie list ACL i kontroli dostępu opartej na rolach (RBAC) w czasie wykonywania zapytania w Wyszukiwanie AI platformy Azure.

Zalety kontroli dostępu na poziomie dokumentu

Natywna kontrola dostępu na poziomie dokumentu w Wyszukiwanie AI platformy Azure zapewnia konkretne zalety filtrowania po stronie aplikacji:

  • Eliminuje potrzebę stosowania niestandardowego kodu uprawnień: Nie musisz implementować rozpoznawania zagnieżdżonych grup, wielopoziomowego przetwarzania list ACL ani filtrowania wyników po wykonaniu zapytania w swojej aplikacji. Wyszukiwanie AI platformy Azure obsługuje porównanie i filtrowanie podczas wykonywania zapytania.
  • Zgodność z istniejącymi mechanizmami kontroli zgodności: Ponowne użycie metadanych uprawnień w Microsoft Entra, Microsoft Purview i SharePoint pomaga zachować zgodność wyników wyszukiwania ze źródłowym systemem tożsamości. Przejrzyj model synchronizacji uprawnień dla każdego źródła, aby zrozumieć jego ograniczenia.
  • Uwzględnia uprawnienia źródłowe po każdej synchronizacji ACL: W przypadku podejść opartych na tokenach (ACL, zakresów RBAC, etykiet Purview, list ACL programu SharePoint) egzekwowanie w czasie wykonywania zapytania używa metadanych uprawnień, które udokumentowany, specyficzny dla źródła mechanizm synchronizacji (uruchomienie indeksatora, aktualizacja przez interfejs Push API lub odświeżenie Purview) zapisał już w indeksie.
  • Poprawia wydajność w porównaniu z przycinaniem wyników po wykonaniu zapytania: Filtrowanie w potoku wyszukiwania jest szybsze niż ładowanie większych zestawów wyników do aplikacji i przycinanie ich w aplikacji, zwłaszcza przy dużej liczbie zapytań.
  • Wykorzystuje istniejącą infrastrukturę tożsamości: Microsoft Entra i tożsamości w usłudze SharePoint pozostają nadrzędnym źródłem informacji na potrzeby decyzji dotyczących dostępu, co ogranicza duplikację tożsamości oraz nakład pracy związany z utrzymaniem równoległego magazynu uprawnień.

Samouczki i przykłady

Zapoznaj się z kontrolą dostępu na poziomie dokumentów w Wyszukiwanie AI platformy Azure w dodatkowych artykułach i przykładach.

Powiązana zawartość

  • Ostatnia aktualizacja o