View a markdown version of this page

문서 수준 액세스 제어 - Amazon Bedrock

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

문서 수준 액세스 제어

ACL 인식은 권한 부여가 아닙니다.

Bedrock 관리형 지식 기반은 보안 경계가 아닌 ACL 인식 필터링을 제공합니다. Bedrock 관리형 지식 기반은 최종 사용자를 인증하지 않습니다. 애플리케이션은 사용자를 인증하고 확인된 자격 증명 컨텍스트를 전달할 책임이 있습니다. Bedrock 관리형 지식 기반은 사용자가 제공한 사용자 컨텍스트의 신뢰성을 확인할 수 없으므로이 기능은 사용자가 제공한 자격 증명을 기반으로 결과를 필터링하지만 실제 권한 부여를 구성하지는 않습니다. 업스트림 인증 없이이 기능을 유일한 액세스 제어 메커니즘으로 사용해서는 안 됩니다.

Amazon S3 데이터 소스는 선택적으로 문서 수준 액세스 제어를 지원합니다. 다른 커넥터와 달리 Amazon S3에는 크롤링할 기본 권한 시스템이 없으므로 관리하는 구성 파일을 통해 ACLs을 정의합니다. 모든 커넥터의 ACL 인식에 대한 개요는 섹션을 참조하세요액세스 제어 목록 인식 활성화.

작동 방식

ACL 지원 Amazon S3 데이터 소스의 경우 Bedrock 관리형 지식 기반은 검색 전 필터링 중에 고객이 제공한 액세스 제어 목록을 적용하여 쿼리 사용자가 액세스할 수 있는 문서만 반환합니다. 고객이 제공한 ACL 메타데이터가 정확한 출처이므로 Amazon S3에서는 실시간 ACL 확인이 지원되지 않습니다.

ACL 인식 활성화

Amazon S3 데이터 소스에 대한 ACL 인식을 활성화하려면 true에서를 aclEnabled로 설정하고 다음 두 가지 방법 중 하나를 사용하여 액세스 권한을 connectorParameters 정의합니다.

  • 글로벌 ACL 구성 파일 - 폴더(접두사) 수준에서 액세스 권한을 정의하는 단일 중앙 집중식 JSON 파일입니다. 안정적인 권한 구조를 가진 조직에 적합합니다. 전역 파일을 변경하려면 영향을 받는 접두사를 다시 인덱싱해야 합니다.

  • 문서 수준 메타데이터 파일 - 각 문서에는 액세스 제어 정보가 포함된 자체 메타데이터 파일이 있습니다. 이렇게 하면 영향을 받는 문서만 다시 인덱싱해야 하므로 권한이 변경될 때 인덱스 업데이트 속도가 빨라집니다.

중요

ACL이 활성화된 Amazon S3 데이터 소스의 경우 연결된 ACL 항목이 없는 문서는 수집되지 않습니다. 모든 문서에 글로벌 ACL 파일 또는 메타데이터 파일을 통해 정의된 ACL이 있는지 확인합니다.

"connectorParameters": { "type": "S3", "version": "1", "aclEnabled": true, "connectionConfiguration": { "bucketName": "your-bucket-name", "bucketOwnerAccountId": "123456789012" }, "aclConfiguration": { "globalAccessControlListS3Uri": "s3://your-bucket-name/acl/global-acl.json" } }

글로벌 ACL 파일 구조

글로벌 ACL 파일은 각 항목이 키 접두사를 액세스 제어 항목 세트에 매핑하는 JSON 배열입니다. 각 keyPrefix는 폴더(아래의 모든 문서에 적용) 또는 개별 문서의 절대 Amazon S3 URI입니다.

[ { "keyPrefix": "s3://your-bucket-name/finance/", "aclEntries": [ { "Name": "user1@example.com", "Type": "USER", "Access": "ALLOW" } ] } ]

aclEntries 요소에는 다음이 포함됩니다.

  • Name - 사용자의 이메일 주소입니다.

  • Type - 여야 합니다USER.

  • Access - ALLOW 또는 DENY. 거부 재정의 허용.

문서별 메타데이터 파일

글로벌 ACL 파일의 대안으로 메타데이터 파일을 사용하여 문서당 ACLs 정의할 수 있습니다. 각 문서에 대해 동일한 Amazon S3 경로filename.metadata.json에 라는 파일을 생성합니다. 전역 파일과 동일한 입력 형식의 accessControlList 배열을 포함합니다.

{ "metadataAttributes": {}, "accessControlList": [ { "Name": "user1@example.com", "Type": "USER", "Access": "ALLOW" }, { "Name": "user2@example.com", "Type": "USER", "Access": "DENY" } ] }

문서별 메타데이터는 글로벌 ACL 파일보다 우선합니다. 문서에 일치하는 전역 접두사 항목과 문서별 메타데이터 파일이 모두 있는 경우 문서별 메타데이터가 사용됩니다.

참고

ACL 구성 파일은 데이터 소스 콘텐츠와 동일한 Amazon S3 버킷에 저장되어야 합니다.

구성 확인

Amazon S3 ACLs은 고객이 제공하므로 쿼리하기 전에 검증하세요.

  1. aclEnabled가 데이터 소스의 true에 있는지 확인합니다connectorParameters.

  2. 모든 문서에 글로벌 ACL 파일의 항목 또는 문서별 .metadata.json 파일인 ACL이 있는지 확인합니다. ACL이 없는 문서는 수집되지 않습니다.

  3. ACL JSON 검증: 각 항목에 Name (사용자 이메일), Type (USER) 및 Access (ALLOW 또는 DENY)가 있고 ACL 파일은 콘텐츠와 동일한 버킷에 있습니다.

  4. 테스트 사용자의 이메일이 검색하려는 문서의 Name ALLOW 항목에 있는와 정확히 일치하는지 확인합니다.

문제 해결

참고

ACL 구성 오류는 검색 중에 명시적 오류를 생성하지 않습니다. 검색 실패 닫힘: 영향을 받는 문서는 자동으로 생략되므로 쿼리는 오류가 아닌 더 적거나 0의 결과를 반환합니다. 위의 확인 검사를 사용하여 이러한 문제를 진단합니다.

ACL 지원 Amazon S3 증상, 원인 및 수정 사항
증상 가능한 원인 수정
검색은 액세스 권한이 있어야 하는 사용자에 대해 0개의 결과를 반환합니다. 사용자의 이메일이 ACL 항목과 일치하지 않습니다(이메일 불일치). ACL이 사용자의 이메일과 정확히 Name 일치하는지 확인합니다.
문서는 아무에게도 반환되지 않습니다. 문서에는 ACL 항목이 없으므로 수집되지 않았습니다. 글로벌 ACL 파일 또는 문서별 .metadata.json 파일을 통해 문서에 대한 ACL을 추가한 다음 다시 동기화합니다.
문서별 ACL은 적용되지 않습니다. .metadata.json 파일 이름이 잘못 지정되었거나 잘못된 경로에 있습니다. 동일한 S3 경로filename.metadata.json에서 이름을 지정합니다. 문서별 메타데이터는 전역 파일을 재정의합니다.
ACL 변경 사항은 반영되지 않습니다. 전역 ACL 파일을 변경하려면 영향을 받는 접두사를 다시 인덱싱해야 합니다. 영향을 받는 접두사를 다시 동기화합니다.