이 페이지는 Cloud Translation API를 통해 번역되었습니다.

ACL 매핑

항목에 대한 액세스 권한이 있는 사용자만 검색결과 내에서 해당 항목을 볼 수 있도록 하려면 엔터프라이즈 저장소의 액세스제어 목록 (ACL)으로 항목의 색인을 생성해야 합니다. 저장소에서 항목의 색인을 생성할 때 저장소의 ACL을 모델링하고 이 ACL을 포함해야 합니다. 콘텐츠 커넥터 SDK는 대부분의 저장소의 ACL을 모델링할 수 있을 만큼 강력한 다양한 ACL 메서드 집합을 제공합니다.

ACL 만들기

ACL을 만드는 프로세스는 두 단계로 이뤄집니다.

ACL 클래스의 정적 메서드를 사용하여 Principal를 만듭니다.
Acl.Builder 클래스를 사용하여 주 구성원을 사용하여 ACL을 빌드합니다.

이 문서의 나머지 부분에서는 상속, 포함과 같은 ACL을 모델링하고 만들기 위해 알아야 하는 몇 가지 개념을 설명합니다.

외부 ID를 사용하여 주 구성원 만들기

Google Cloud Search에서는 사용자와 그룹을 Google 이메일 주소로 확인 합니다. 저장소 항목 색인을 생성하면 콘텐츠 커넥터에 이러한 이메일 주소가 없을 수 있습니다. 하지만 콘텐츠 커넥터 SDK를 사용하면 이메일 주소 대신 외부 ID (저장소 항목에 대한 액세스 권한을 사용자 또는 그룹에 부여하는 ID)를 사용하여 항목의 색인을 생성할 수 있습니다. getUserPrincipal() 메서드 또는 getGroupPrincpal() 메서드를 사용하여 외부 ID가 포함된 주 구성원을 만듭니다. ACL 클래스에는 Principal 객체를 빌드하는 데 사용되는 여러 다른 정적 메서드가 있습니다.

ACL 상속

ACL 상속은 항목의 ACL과 상속 체인의 ACL 조합 결과에 따라 특정 항목 또는 사용자를 승인하는 것을 의미합니다. 승인 결정을 내리는 데 사용되는 규칙은 저장소와 항목의 속성에 따라 다릅니다.

상속 설정

각 항목에는 setReaders() 및 setDeniedReaders() 메서드를 사용하여 지정된 직접 허용된 주 구성원과 직접 거부된 주 구성원이 있을 수 있습니다. 직접 허용된 주 구성원은 특정 항목에 직접 액세스 할 수 있다고 ACL에서 식별된 사용자입니다. 직접 거부된 주 구성원은 특정 항목에 액세스할 수 없다고 ACL에서 식별된 사용자입니다.

항목은 setInheritFrom() 메서드를 사용하여 간접 허용된 주 구성원과 간접 거부된 주 구성원을 상속할 수도 있습니다. 간접 허용된 주 구성원은 ACL 상속을 통해 특정 항목에 간접적으로 액세스할 수 있는 사용자입니다. 간접 거부된 주 구성원은 ACL 상속을 통해 특정 항목에 액세스할 수 없는 사용자입니다.

그림 1에서는 setInheritFrom() 메서드를 사용하여 간접 허용된 주 구성원과 간접 거부된 주 구성원을 상속하는 방법을 보여줍니다.

항목 간 연결 그림 — **그림 1.** `setInheritFrom()` 메서드

그림 1은 다음과 같은 액세스 제어를 설명합니다.

사용자 1은 항목 A의 직접 허용된 주 구성원입니다.
사용자 2는 항목 B의 직접 허용된 주 구성원입니다.
항목 B는 항목 A의 ACL을 상속합니다.

이러한 액세스 제어에 따른 액세스 규칙은 다음과 같습니다.

사용자 1은 항목 B의 간접 허용된 주 구성원이 되기 위해 명시적으로 항목 B의 주 구성원으로 지정될 필요는 없습니다. 사용자 1은 항목 A의 직접 허용된 주 구성원으로 나열되고 항목 B가 항목 A의 ACL을 상속하므로 액세스 권한이 상속됩니다.
사용자 2는 항목 A의 간접 허용된 주 구성원이 아닙니다.

상속 유형 설정

setInheritFrom() 메서드를 사용하여 상속을 설정하는 경우 setInheritanceType() 메서드를 사용하여 상속 유형을 설정해야 합니다. 상속 유형은 하위 ACL과 상위 ACL이 결합되는 방식을 결정합니다. Acl.InheritanceType는 세 가지 상속 유형을 구현합니다.

BOTH_PERMIT - 상속 유형을 BOTH_PERMIT으로 설정하면 하위 항목의 ACL과 상속된 상위 항목 ACL 모두에서 사용자의 항목 액세스가 허용된 경우에만 사용자에게 항목에 대한 액세스 권한이 부여됩니다.
CHILD_OVERRIDE - 상속 유형을 CHILD_OVERRIDE로 설정하면 하위 항목의 ACL이 상속된 상위 항목의 ACL과 충돌할 때 하위 항목의 ACL이 상속된 상위 항목의 ACL보다 우선적으로 강제 적용됩니다. 따라서 상위 항목의 ACL에서 사용자의 액세스가 거부된 리더로 인해 거부되더라도 사용자에게 하위 항목에 대한 리더 권한이 있으면 계속 액세스할 수 있습니다. 이와 반대로 상위 항목의 ACL에서 사용자에게 액세스 권한이 부여되더라도 사용자가 하위 항목의 거부된 리더라면 액세스할 수 없습니다.
PARENT_OVERRIDE - 상속 유형을 PARENT_OVERRIDE로 설정하면 상위 항목의 ACL이 하위 항목의 ACL과 충돌 할 때 상위 항목의 ACL이 하위 항목의 ACL보다 우선적으로 강제 적용됩니다. 따라서 하위 항목의 ACL에서 사용자의 액세스가 거부된 리더로 인해 거부되더라도 사용자에게 상위 항목에 대한 리더 권한이 있으면 계속 액세스할 수 있습니다. 이와 반대로 하위 항목의 ACL에서 사용자에게 액세스 권한이 부여되더라도 사용자가 상위 항목의 거부된 리더라면 액세스할 수 없습니다.

ACL 상속 체인을 평가할 때 평가 순서에 따라 승인 결과가 바뀔 수 있습니다. Cloud Search는 ACL 상속 체인에 리프-루트(leaf-to-root) 평가 순서를 제공합니다. 특히 체인의 ACL 결정은 상위 요소가 있는 하위 요소 평가로 시작되며 루트 상위 요소까지 진행될 수 있습니다.

예를 들어 하위 요소에 CHILD_OVERRIDE 상속 유형이 있고 사용자에게 하위 요소에 대한 액세스 권한이 있는 경우 Drive는 상위 요소를 평가할 필요가 없습니다. 그러나 하위 요소에 PARENT_OVERRIDE 또는 BOTH_PERMIT이 있으면 Drive는 체인 상위에서 상속을 계속 평가합니다.

포함 및 항목 삭제

항목의 색인을 생성할 때 IndexingItemBuilder 클래스의 setContainer() 메서드를 사용하여 항목에 컨테이너로 라벨을 지정할 수 있습니다. 컨테이너/컨테이너 관계는 항목의 물리적 계층 구조를 설정하고 항목이 올바르게 삭제되도록 합니다. 컨테이너를 삭제하면 포함된 항목도 함께 삭제됩니다.

포함 관계는 ACL 상속 규칙과는 완전히 별개입니다. 예를 들어 파일 시스템의 파일은 삭제 목적으로 폴더에 포함될 수 있지만 다른 폴더에서 ACL을 상속합니다. ACL을 상속하는 항목이 폴더의 포함 계층 구조에 있지 않는 한 폴더를 삭제해도 이 항목은 삭제되지 않습니다.

그림 2는 다음과 같은 액세스 제어를 설명합니다.

사용자 1은 항목 A의 직접 허용된 주 구성원입니다.
사용자 2는 항목 B의 직접 허용된 주 구성원입니다.
사용자 3은 항목 C의 직접 허용된 주 구성원입니다.
항목 C는 항목 A의 ACL을 상속합니다.
항목 B는 항목 A를 자신의 컨테이너로 명명합니다.
항목 C는 항목 B를 자신의 컨테이너로 명명합니다.

이러한 액세스 제어에 따른 액세스 규칙은 다음과 같습니다.

간접 액세스는 setInheritFrom() 메서드에서 가져옵니다. 따라서 항목 C가 항목 A의 ACL을 상속하므로 사용자 1이 항목 C에 액세스할 수 있습니다.
간접 액세스 권한은 항목 B에 포함된 항목 C에서 제공되지 않습니다. 따라서 사용자 2는 항목 C에 액세스할 수 없습니다.

포함 계층 구조에서 ACL 상속을 분리하면 다양한 기존 구조를 모델링할 수 있습니다.

항목을 삭제하면 다음과 같은 결과가 발생합니다.

삭제된 항목이 포함된 모든 항목을 검색할 수 없게 되며, Google의 데이터 소스에서 삭제가 예약됩니다.
setInheritFrom() 메서드를 사용하여 삭제된 항목을 지정한 모든 항목을 검색할 수 없게 됩니다.

리소스에 setInheritFrom() 메서드를 사용하는 삭제된 항목이 있지만 setContainer()를 사용하는 컨테이너 세트가 없거나 포함 계층 구조에 삭제된 항목이 없는 경우 해당 항목과 데이터는 Google의 데이터 소스에 남아 있습니다. 개발자가 항목을 삭제할 수 있습니다.

그림 3은 항목 계층 구조에서 삭제가 작동하는 예시입니다.

그림 3은 다음과 같은 액세스 제어를 설명합니다.

사용자 1은 항목 A의 직접 허용된 주 구성원입니다.
사용자 2는 항목 D의 직접 허용된 주 구성원입니다.
항목 D와 항목 E 모두 항목 A의 ACL을 상속합니다.
항목 D는 항목 A를 자신의 컨테이너로 명명합니다.
항목 A와 항목 E는 컨테이너 항목이 없는 루트 수준 항목입니다.

삭제 작업은 컨테이너 참조 관계를 통해 전파됩니다. 항목 A를 삭제하면 다음과 같은 결과가 발생합니다.

모든 사용자가 setInheritFrom() 참조의 모든 하위 요소에 액세스할 수 없게 됩니다.
어떠한 사용자도 항목 A에 액세스할 수 없습니다.
항목 D는 암묵적으로 삭제됩니다. 어떠한 사용자도 항목 D에 액세스할 수 없습니다.
삭제 작업은 컨테이너 참조를 통해서만 삭제되므로 항목 E는 삭제되지 않습니다.
항목 E에 연결할 수 없으며 사용자가 항목 E를 검색할 수 없습니다.