Azure AI 검색 문서 수준 액세스 제어

메모

Azure AI 검색 Azure 포털, REST API 및 Azure SDK 통해 사용할 수 있습니다. 또한 엔터프라이즈 콘텐츠를 Microsoft Foundry 포털의 에이전트에 대해 재사용 가능한 사용 권한 인식 기술 자료로 변환하는 관리되는 기술 계층인 Foundry IQ를 뒷받침합니다.

Important

이러한 기능과 기능은 2026-05-01-preview REST API의 일부입니다. 2026-05-01-preview는 Azure 구독의 일부로 사용자에게 라이선스가 부여되며, Microsoft Product Terms의 "미리 보기"에 적용되는 약관, Microsoft 제품 및 서비스 데이터 보호 부록("DPA") 및 Microsoft Azure 미리 보기용 추가 사용 약관의 적용을 받습니다.

2026-05-01-preview는 다른 Microsoft 서비스 및 타사 서비스에 대한 연결을 지원합니다. 이러한 서비스의 사용은 해당 약관의 적용을 받으며 Azure 규정 준수 경계 외부의 데이터 처리 또는 스토리지뿐만 아니라 Azure 규정 준수 경계로 데이터가 유입될 수 있습니다.

2026-05-01-preview는 2026-05-01-preview 외부에서 설정된 액세스 권한을 수정할 수 없습니다. 액세스 또는 권한 제한 콘텐츠와 함께 2026-05-01-preview를 사용하는 경우 2026-05-01-preview에서 해당 액세스 또는 권한 제한에 대한 변경 내용을 인식하기 전에 타이밍 지연이 발생합니다.

데이터가 조직의 규정 준수 및 지리적 경계를 벗어나는지 여부와 관련된 의미를 관리하고 적절한 권한, 경계 및 승인이 프로비전되는지를 관리하는 것은 사용자의 책임입니다.

특정 사용 사례의 컨텍스트에서 빌드한 애플리케이션을 신중하게 검토하고 테스트하고 모든 적절한 결정 및 사용자 지정을 수행할 책임이 있습니다. 이 책임에는 메타프롬프트, 콘텐츠 필터 또는 기타 안전 시스템과 같은 책임 있는 AI 완화를 구현하고 애플리케이션이 적절한 품질, 안정성, 보안 및 신뢰성 표준을 충족하도록 보장하는 것이 포함됩니다. 자세한 내용은 Azure AI 검색 투명성 정보를 참고하세요.

Azure AI 검색 문서 수준 액세스 제어를 지원하므로 조직에서는 데이터 수집부터 쿼리 실행까지 문서 수준에서 세분화된 권한을 적용할 수 있습니다. 이 기능은 보안 AI 에이전트 시스템 접지 데이터, RAG(검색 보강 생성) 애플리케이션 및 문서 수준에서 권한 부여 검사가 필요한 엔터프라이즈 검색 솔루션을 빌드하는 데 필수적입니다.

문서 수준 액세스 제어에 대한 접근 방식

Azure AI 검색 각각 다른 데이터 원본 및 ID 모델에 적합한 문서 수준 권한을 적용하는 네 가지 기본 방법을 제공합니다.

접근 설명
보안 필터 문자열 비교. 애플리케이션은 사용자 또는 그룹의 ID를 문자열로 제공하여 쿼리의 필터를 설정합니다. 이 필터는 문자열과 일치하지 않는 문서를 제외합니다.

보안 필터는 문서 수준 액세스 제어를 달성하기 위한 기술입니다. 이 방법은 API에 바인딩되지 않으므로 모든 버전 또는 패키지를 사용할 수 있습니다.
POSIX와 유사한 ACL/RBAC 범위(미리 보기) 쿼리 토큰에 연결된 Microsoft Entra 보안 주체는 검색 결과로 반환된 문서의 권한 메타데이터와 비교되며, 권한이 일치하지 않는 문서는 제외됩니다. ACL(액세스 제어 목록) 권한은 ADLS(Azure Data Lake Storage) Gen2 디렉터리 및 파일에 적용됩니다. RBAC(역할 기반 액세스 제어) 범위는 ADLS Gen2 콘텐츠 및 Azure Blob에 적용됩니다.

문서 수준에서 ID 기반 액세스에 대한 기본 제공 지원은 미리 보기로 제공되며, REST API 및 기능을 제공하는 미리 보기 Azure SDK 패키지에서 사용할 수 있습니다. 기능 지원의 증거는 SDK 버전 지원 세부 정보를 확인하세요.
Microsoft Purview 민감도 레이블(미리 보기) 인덱서는 지원되는 데이터 원본(Azure Blob Storage, ADLS Gen2, Microsoft 365 OneLake의 SharePoint)에서 Microsoft Purview 정의된 민감도 레이블을 추출합니다. 이러한 레이블은 메타데이터로 저장되고 쿼리 시간에 평가되어 Microsoft Entra 토큰 및 Purview 정책 할당에 따라 사용자 액세스를 적용합니다. 또한 지식 원본 및 에이전트 검색 응답을 통해 레이블이 표시되므로 기술 자료를 사용하는 AI 에이전트 및 채팅 앱이 동일한 레이블 인식 필터링을 받을 수 있습니다. 이 방법은 Azure AI 검색 권한 부여를 엔터프라이즈의 Microsoft Information Protection 모델에 맞춥니다.
Microsoft 365 ACL의 SharePoint(미리 보기) Azure AI 검색 인덱서는 지원되는 SharePoint 콘텐츠에서 권한 메타데이터를 추출하고 쿼리 시간 액세스 검사에 사용합니다. 지원되는 콘텐츠, 보안 주체, 그룹 관계, 동기화 동작 및 사용 권한은 SharePoint 인덱서를 사용하여 사용 권한 메타데이터를 수집합니다.

인덱싱된 지식 소스의 경우 ingestionPermissionOptions는 assetStore와 함께 사용할 수 없습니다. 따라서 네이티브 문서 수준 권한 수집을 사용하는 경우 이미지 서비스(미리 보기) 를 사용할 수 없습니다.

방법 선택

다음 조건을 사용하여 데이터 원본, ID 모델 및 규정 준수 요구 사항에 가장 적합한 접근 방식을 식별합니다.

Scenario 권장되는 접근 방식 이유
사용자 지정 ID 시스템, Microsoft 이외의 보안 프레임워크 또는 푸시 모델 인덱스 보안 필터 API에 구애받지 않으며 일반적으로 사용 가능하며 간단한 문자열 일치를 기반으로 합니다.
ADLS Gen2의 콘텐츠 또는 기존 ACL 또는 RBAC 할당이 있는 Azure Blob Storage. POSIX와 유사한 ACL/RBAC 범위 기본 제공 Microsoft Entra 통합; 쿼리 시 강제 적용은 문서화된 동기화 메커니즘을 통해 인덱스에 기록된 권한 메타데이터를 사용합니다.
Microsoft Purview 정보 보호 정책의 적용을 받는 엔터프라이즈 콘텐츠입니다. Microsoft Purview 민감도 레이블 Azure AI 검색 중앙 집중식 분류 및 정책 할당을 다시 사용합니다.
Microsoft 365 SharePoint 원본 콘텐츠(라이브러리, 목록, ASPX 사이트 페이지). Microsoft 365 ACL의 SharePoint SharePoint 사이트 그룹을 포함한 기본 SharePoint 권한을 그대로 따릅니다.

필터를 사용한 보안 트리밍 패턴

네이티브 ACL/RBAC 범위 통합이 실행 가능하지 않은 시나리오의 경우 보안 문자열 필터를 사용하여 제외 기준에 따라 결과를 트리밍합니다. 패턴에는 다음 구성 요소가 포함됩니다.

  • 사용자 또는 그룹 ID를 저장하려면 인덱스로 문자열 필드를 만듭니다.
  • 연결된 ACL을 포함하는 원본 문서를 사용하여 인덱스를 로드합니다.
  • 문자열에서 일치하도록 쿼리 논리에 필터 식을 포함합니다.
  • 쿼리 시 호출자의 ID를 가져옵니다.
  • 호출자의 ID를 필터 문자열로 전달합니다.
  • 결과는 사용자 또는 그룹 ID 문자열을 포함하지 않는 일치 항목을 제외하도록 잘립니다.

푸시 또는 끌어오기 모델 API를 사용할 수 있습니다. 이 방법은 API에 구애받지 않으므로 인덱스 및 쿼리에 여과 단계에 대한 유효한 문자열(ID)이 있는지 확인해야 합니다.

이 방법은 사용자 지정 액세스 모델 또는 비 Microsoft 보안 프레임워크가 있는 시스템에 유용합니다. 이 방법에 대한 자세한 내용은 Azure AI 검색 결과 트리밍에 대한 보안 필터를 참조하세요.

POSIX와 유사한 ACL 및 RBAC 범위 권한에 대한 네이티브 지원 패턴(미리 보기)

기본 지원은 인덱싱 및 쿼리하려는 문서와 연결된 Microsoft Entra 사용자 및 그룹을 기반으로 합니다.

ADLS(Azure Data Lake Storage) Gen2 컨테이너는 컨테이너 및 파일에서 ACL을 지원합니다. ADLS Gen2의 경우 ADLS Gen2 인덱서 또는 Blob 지식 원본(ADLS Gen2 지원) 및 미리 보기 API를 사용하여 콘텐츠를 수집하는 경우 문서 수준의 RBAC 범위 보존이 기본적으로 지원됩니다. Azure Blob 인덱서 또는 기술 자료를 사용하는 Azure Blob의 경우 RBAC 범위 유지는 컨테이너 수준에 있습니다.

ACL 보안 콘텐츠의 경우 관리 용이성을 위해 개별 사용자 액세스에 대한 그룹 액세스를 사용합니다. 패턴에는 다음 구성 요소가 포함됩니다.

클라이언트 앱은 검색 인덱스 데이터 판독기 또는 검색 인덱스 데이터기여자 역할을 통해 인덱스에 대한 읽기 권한을 받습니다. 쿼리 시 액세스는 인덱싱된 콘텐츠의 사용자 또는 그룹 권한 메타데이터에 의해 결정됩니다. 권한 필터를 포함하는 쿼리는 요청 헤더에서와 같이 x-ms-query-source-authorization 사용자 또는 그룹 토큰을 전달합니다. 쿼리 시 사용 권한 필터를 사용하는 경우 Azure AI 검색 다음 두 가지를 확인합니다.

  • 먼저 클라이언트 애플리케이션이 인덱스에 액세스할 수 있도록 하는 검색 인덱스 데이터 판독기 권한을 확인합니다.

  • 둘째, 요청에 대한 추가 토큰이 제공되면 일치하지 않는 토큰을 제외하고 검색 결과에 반환된 문서에 대한 사용자 또는 그룹 권한을 확인합니다.

인덱스에 권한 메타데이터를 얻으려면 푸시 모델 API를 사용하여 JSON 문서를 검색 인덱스에 푸시합니다. 여기서 페이로드에는 각 문서에 POSIX와 유사한 ACL을 제공하는 문자열 필드가 포함됩니다. 이 접근 방식과 보안 트리밍의 중요한 차이점은 인덱스와 쿼리의 권한 필터 메타데이터가 Microsoft Entra ID 인증으로 인식되는 반면 보안 트리밍 해결 방법은 간단한 문자열 비교라는 것입니다. 또한 Graph SDK를 사용하여 ID를 검색할 수 있습니다.

데이터 원본이 ADLS(Azure Data Lake Storage) Gen2이고 코드에서 인덱싱을 위해 미리 보기 API를 호출하는 경우에도 끌어오기 모델(인덱서) API를 사용할 수 있습니다.

데이터 수집 프로세스 중 ACL 권한 메타데이터 검색(미리 보기)

ACL 권한을 검색하는 방법은 문서 페이로드를 푸시하는지 또는 ADLS Gen2 인덱서를 사용하는지에 따라 달라집니다.

기능을 제공하는 미리 보기 API로 시작합니다.

푸시 모델 접근 방식의 경우:

  1. 인덱스 스키마가 미리 보기 또는 시험판 SDK를 사용하여 만들어졌으며 스키마에 권한 필터가 있는지 확인합니다.
  2. Microsoft Graph SDK를 사용하여 그룹 또는 사용자 ID를 가져오는 것이 좋습니다.
  3. 인덱스 문서 또는 해당하는 Azure SDK API를 사용하여 문서 및 관련 권한 메타데이터를 검색 인덱스에 푸시합니다.

풀 모델 ADLS Gen2 인덱서 접근 방식 또는 Blob(ADLS Gen2) 지식 소스의 경우:

  1. ADLS Gen2 액세스 제어 모델을 사용하여 디렉터리의 파일이 보호되는지 확인합니다.
  2. 인덱서 사용 - CREATE(REST API), Knowledge Sources - CREATE(REST API) 또는 이와 동등한 Azure SDK API를 사용하여 인덱서, 인덱스 및 데이터 원본을 만듭니다.

기술 세트가 문서를 청크로 분할하는 경우(예: 통합 벡터화를 위한 Text Split 기술 사용), 권한 메타데이터 필드는 인덱서 필드 매핑에서 인덱스 프로젝션으로 옮겨집니다. ACL 필드를 채울 위치 선택을 참조하세요.

Microsoft 365 기본 ACL 권한 수집의 SharePoint 패턴(미리 보기)

인덱싱된 SharePoint 콘텐츠의 경우 Azure AI 검색 원본 권한을 메타데이터로 저장하고 이를 사용하여 쿼리 결과를 필터링할 수 있습니다. 이 기능은 Microsoft 365의 SharePoint 인덱서 및 2026-05-01-preview REST API 또는 이에 상응하는 미리 보기 SDK 패키지를 통해 미리 보기로 사용할 수 있습니다.

사용 권한 요구 사항, 지원되는 그룹 관계, 권한 동기화 및 제한 사항은 SharePoint 인덱서를 사용하여 사용 권한 메타데이터를 수집하는 방법을 참조하세요.

기술 집합이 문서를 청크로 분할하는 경우(예: 통합 벡터화를 위해 텍스트 분할 기술을 사용하는 경우) ACL 필드는 인덱서 필드 매핑에서 인덱스 프로젝션으로 이동합니다. ACL 필드를 채울 위치 선택을 참조하세요.

Microsoft Purview 민감도 레이블 패턴(미리 보기)

레이블 수집을 사용하도록 설정하면 Azure AI 검색 지원되는 데이터 원본에서 민감도 메타데이터를 추출합니다. 이러한 데이터 원본에는 Azure Blob Storage, ADLS Gen2(Azure Data Lake Storage Gen2), Microsoft 365 SharePoint 및 Microsoft OneLake가 포함됩니다. 추출된 레이블은 문서 콘텐츠와 함께 인덱스에 저장됩니다.

쿼리 시 Azure AI 검색 각 문서의 민감도 레이블, 사용자의 Microsoft Entra 토큰 및 조직의 Purview 정책을 확인하여 액세스를 확인합니다. 시스템은 사용자의 ID 및 레이블 기반 사용 권한이 구성된 Purview 정책에 따라 액세스를 허용하는 경우에만 문서를 반환합니다.

이 패턴에는 다음 구성 요소가 포함됩니다.

  • 2026-05-01-preview REST API 또는 Purview 레이블 수집을 지원하는 해당 SDK를 사용하여 인덱스, 데이터 원본 및 인덱서(예약을 위해)를 구성하세요.
  • 검색 서비스에서 시스템 할당 관리 ID 를 사용하도록 설정합니다. 사용자 할당 관리형 ID는 Purview 레이블 추출에 지원되지 않으며, 서비스 자체 ID에 더 높은 수준의 Purview 권한이 부여되어 있어야 합니다. 그런 다음, 테넌트 전역 관리자 또는 권한 있는 역할 관리자에게 검색 서비스가 Microsoft Purview 인증하고 레이블 메타데이터를 추출할 수 있도록 필요한 액세스 권한을 부여합니다.
  • 인덱싱 전에 문서에 민감도 레이블을 적용하여 시스템이 수집 중에 이를 인식하고 유지할 수 있도록 합니다.
  • 쿼리 시 헤더 x-ms-query-source-authorization 통해 각 쿼리 요청에 유효한 Microsoft Entra 토큰을 연결합니다. Azure AI 검색 토큰 및 관련 레이블 메타데이터를 평가하여 레이블 기반 액세스 제어를 적용합니다.

Purview 민감도 레이블 적용은 단일 테넌트 시나리오로 제한되며 RBAC 인증이 필요합니다. 미리 보기 중에는 REST API 및 Azure SDK 통해서만 지원됩니다. 자동 완성 및 제안 API는 현재 Purview 사용 인덱스에 사용할 수 없습니다.

민감도 레이블이 표시되는 위치

시스템에서 쿼리 시간에 레이블을 적용하거나 응답을 검색할 때 반환하려면 먼저 레이블 메타데이터를 인덱스에 동기화해야 합니다. 이 섹션에 설명된 두 사용 경로는 이 동기화 단계에 따라 달라집니다. 지원되는 데이터 원본에 대해 직접 Azure AI 검색 인덱서를 구성하거나 기술 자료를 만들 때 동등한 수집 옵션을 사용하도록 설정하여 레이블을 동기화할 수 있습니다. 두 경우 모두 환경이 민감도 레이블 메타데이터 동기화 구성 필수 조건(관리 ID, 검색 서비스의 RBAC 및 필요한 Microsoft Purview 및 데이터 원본 권한)을 충족해야 합니다. 엔드 투 엔드 인덱서 설정은 Azure AI 검색 인덱서를 사용하여 Microsoft Purview 민감도 레이블 수집 참조하세요. 지식 원본 기반 수집의 경우 ingestionPermissionOptions 시 sensitivityLabel가 을 포함하도록 설정합니다.

레이블을 동기화한 후 두 쿼리 경로는 동일한 인덱싱된 레이블 메타데이터를 사용합니다. 애플리케이션이 Azure AI 검색 호출하는 방법과 일치하는 경로를 선택합니다.

  • 직접 쿼리 API(/docs/search): x-ms-query-source-authorization에 사용자의 Microsoft Entra 토큰을 연결합니다. 관리자는 감사 가능한 조사를 위해 상승된 읽기 요청을 실행할 수도 있습니다. 설정 및 예제는 Microsoft Purview 민감도 레이블의 쿼리 시간 적용 참조하세요.

  • 지식 소스 및 에이전트형 검색(MCP): 지식 소스에 ingestionPermissionOptions을(를) 포함하도록 sensitivityLabel을(를) 설정합니다. 검색 작업 및 MCP knowledge_base_retrieve 도구는 클라이언트가 표시 배너 및 정책 적용에 사용할 수 있는 참조별 sensitivityLabelInfo 및 응답 수준 metadata.responseSensitivityLabelInfo를 반환합니다. 설정하려면 지식 원본 만들기 및 검색 응답에서 민감도 레이블 메타데이터 검사를 참조하세요.

기술 원본이 통합 벡터화 또는 사용자 지정 텍스트 분할 기술을 통해 채워진 인덱스와 같은 청크 인덱스를 가리키는 경우 기술 세트는 각 청크 행에 민감도 레이블을 프로젝션해야 합니다. 이 프로젝션이 없으면 청크 수준 참조가 필터링되지 않습니다.

자세한 내용은 Azure AI 검색 인덱서를 사용하여 Microsoft Purview 민감도 레이블 수집 참조하세요.

쿼리 시 문서 수준 권한 적용

토큰 기반 쿼리 강제 적용은 POSIX 유사 ACL 및 RBAC 범위, Microsoft Purview 민감도 레이블, 그리고 Microsoft 365의 SharePoint ACL 패턴 전반에 걸쳐 적용되는 기능입니다. 네이티브 토큰 기반 쿼리를 사용하여 Azure AI 검색 각 요청에서 호출자의 Microsoft Entra 토큰의 유효성을 검사하고 문서 ACL 메타데이터가 인덱스에 동기화되는 한 호출자가 문서 ACL에 따라 읽을 수 있는 권한이 있는 문서로만 결과 집합을 트리밍합니다.

x-ms-query-source-authorization 헤더를 통해 쿼리 요청에 사용자의 토큰을 연결하면 Azure AI 검색는 다음을 수행합니다:

  1. 토큰에서 사용자, 그룹 및 범위 클레임을 추출합니다.
  2. 이러한 클레임을 인덱싱된 문서(ACL 항목, RBAC 범위, Purview 레이블 할당 또는 SharePoint ACL)와 함께 저장된 권한 메타데이터와 비교합니다.
  3. 동기화된 권한 메타데이터가 호출자 액세스 권한을 부여하는 문서만 반환합니다.

쿼리 시간 적용은 인덱스에 이미 저장된 권한 메타데이터에 대해 호출자의 Microsoft Entra 클레임을 평가합니다. 원본 시스템(Microsoft Entra 그룹 멤버 자격, ADLS Gen2 ACL, Purview 레이블 할당 또는 SharePoint ACL)의 권한 변경은 원본별 메커니즘(예: 후속 인덱서 실행, 푸시-API 업데이트 또는 Purview 기반 새로 고침)을 통해 해당 메타데이터가 인덱스에 동기화된 후에만 검색 결과에 반영됩니다. SharePoint의 경우 2026-05-01-preview REST API부터는 고유 권한이 있는 항목의 ACL 변경 사항이 인덱서가 성공적으로 실행될 때마다 증분 방식으로 감지되지만, 부모 범위(사이트, 라이브러리, 목록 또는 폴더)에서 상속된 변경 사항은 명시적 새로 고침이 필요합니다. 자세한 내용은 인덱싱된 콘텐츠와 원본 콘텐츠 간에 사용 권한 동기화를 참조하세요.

엔드 투 엔드 쿼리 구현 단계는 Azure AI 검색 참조하세요.

문서 수준 액세스 제어의 이점

Azure AI 검색 네이티브 문서 수준 액세스 제어는 애플리케이션 쪽 필터링보다 구체적인 이점을 제공합니다.

  • 사용자 지정 권한 코드를 제거합니다. 애플리케이션에서 중첩된 그룹 확인, 다단계 ACL 순회 또는 사후 쿼리 트리밍을 구현할 필요가 없습니다. Azure AI 검색 쿼리 실행 중에 비교 및 필터링을 처리합니다.
  • 기존 규정 준수 제어와 일치: Microsoft Entra, Microsoft Purview 및 SharePoint의 권한 메타데이터를 재사용하면 검색 결과가 원본 ID 시스템과 일치하도록 유지하는 데 도움이 됩니다. 각 원본에 대한 권한 동기화 모델을 검토하여 해당 제한 사항을 이해합니다.
  • 각 ACL 동기화 후 원본 사용 권한을 적용합니다. 토큰 기반 방법(ACL, RBAC 범위, Purview 레이블, SharePoint ACL)의 경우 쿼리 시간 적용은 문서화된 원본별 동기화 메커니즘(인덱서 실행, 푸시 API 업데이트 또는 Purview 새로 고침)이 이미 인덱스에 쓴 권한 메타데이터를 사용합니다.
  • 쿼리 후 트리밍에 비해 성능이 향상됩니다. 검색 파이프라인 내에서 필터링하는 것은 더 큰 결과 집합을 애플리케이션에 로드하고, 특히 높은 쿼리 볼륨에서 트리밍하는 것보다 빠릅니다.
  • 기존 ID 인프라를 재사용: Microsoft Entra 및 SharePoint ID는 계속해서 액세스 결정의 기준 정보로 유지되므로 ID 중복과 별도의 권한 저장소를 병행 운영하는 데 따르는 운영 오버헤드를 줄일 수 있습니다.

자습서 및 샘플

더 많은 문서와 샘플을 사용하여 Azure AI 검색 문서 수준 액세스 제어를 탐색합니다.

관련 콘텐츠

  • Last updated on