ACL 매핑

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

ACL 만들기

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

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

이 문서에서는 상속, 포함과 같이 ACL 모델링과 생성을 위해 필수적으로 이해하고 있어야 하는 개념에 대해 설명합니다.

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

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

상품의 ID를 다시 매핑한 후 새 ID가 적용되도록 상품을 다시 색인해야 합니다. 자세한 내용은 ID 재매핑을 참고하세요.

ACL 상속

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

상속 설정

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

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

그림 1은 setInheritFrom 메서드를 사용하여 주 구성원을 상속하는 방법을 보여줍니다.

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

그림 1은 이러한 액세스 제어를 나타냅니다.

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

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

사용자 1은 명시적으로 지정되지 않았지만 항목 B의 간접 허용된 주 구성원입니다. 액세스 권한은 항목 A에서 상속됩니다.
사용자 2는 항목 A의 간접 허용된 주 구성원이 아닙니다.

상속 유형 설정

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

BOTH_PERMIT - 하위 및 상위 ACL 모두에서 허용하는 경우에만 액세스 권한을 부여합니다.
CHILD_OVERRIDE - 충돌이 발생할 경우 하위 ACL이 상위 ACL보다 우선합니다. 부모가 허용하지 않더라도 자녀가 액세스할 수 있고, 부모가 허용하더라도 자녀의 액세스가 거부될 수 있습니다.
PARENT_OVERRIDE - 충돌하는 경우 상위 ACL이 하위 ACL보다 우선합니다.

Cloud Search는 리프에서 루트까지 ACL 상속 체인을 평가합니다. 평가는 자녀와 부모로 시작하여 루트 부모로 진행될 수 있습니다.

예를 들어 자녀가 CHILD_OVERRIDE를 사용하고 사용자에게 액세스 권한이 있는 경우 Cloud Search에서 상위 항목을 평가할 필요가 없습니다. 하지만 자녀가 PARENT_OVERRIDE 또는 BOTH_PERMIT를 사용하는 경우 Cloud Search는 체인에서 계속 평가합니다.

포함 및 항목 삭제

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

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

그림 2는 이러한 액세스 제어를 나타냅니다.

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

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

간접 액세스 권한이 setInheritFrom 메서드에서 제공됩니다. 사용자 1은 항목 A에서 상속받으므로 항목 C에 액세스할 수 있습니다.
간접 액세스 권한은 포함에서 제공되지 않습니다. 사용자 2는 항목 C에 액세스할 수 없습니다.

포함에서 ACL 상속이 분리되므로 다양한 구조를 모델링할 수 있습니다.

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

삭제된 항목이 포함된 모든 항목을 검색할 수 없게 되며 삭제가 예약됩니다.
setInheritFrom에서 삭제된 항목을 지정하는 항목을 검색할 수 없게 됩니다.

리소스가 삭제된 항목에 setInheritFrom를 사용하지만 컨테이너가 설정되어 있지 않거나 계층 구조에 삭제된 항목이 없는 경우 항목은 데이터 소스에 남아 있습니다. 삭제 책임은 사용자에게 있습니다.

그림 3은 항목 계층 구조의 삭제 예를 보여줍니다.

그림 3은 다음과 같은 액세스 제어를 나타냅니다.

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

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

setInheritFrom 참조의 모든 하위 요소에 액세스할 수 없습니다.
사용자가 더 이상 항목 A에 액세스할 수 없습니다.
항목 D는 암묵적으로 삭제되고 액세스할 수 없게 됩니다.
항목 E는 삭제되지 않지만 연결할 수 없게 되며 검색할 수 없습니다.