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

ACL 매핑

항목에 대한 액세스 권한이 있는 사용자만 액세스제어 목록 (ACL)을 사용해 항목의 색인을 생성해야 합니다. 가져올 수 있습니다 먼저 저장소의 ACL을 모델링해야 합니다. 이러한 ACL을 포함하는 것이 좋습니다. 콘텐츠 커넥터 SDK는 객체의 ACL을 모델링할 수 있을 만큼 강력한 ACL 메소드 집합을 다양하게 제공합니다. 스토리지 용량을 늘릴 수도 있습니다

ACL 만들기

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

만들기 Principal 드림 정적 메서드를 사용하여 ACL 클래스에 대해 자세히 알아보세요.
Acl.Builder 사용 클래스를 사용하여 주 구성원을 사용하여 ACL을 빌드합니다.

이 문서의 나머지 부분에서는 모델링을 위해 알아야 하는 몇 가지 개념을 다룹니다. 상속 및 격리와 같은 ACL을 만들 수 있습니다

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

Google Cloud Search에서는 사용자와 그룹을 Google 이메일 주소로 확인 합니다. 저장소 항목 색인을 생성하면 콘텐츠 커넥터에 이러한 이메일 주소가 없을 수 있습니다. 하지만 콘텐츠 커넥터 SDK를 사용하면 외부 ID (저장소 항목에 대한 액세스 권한을 사용자 또는 그룹에 부여하는 ID) 항목 색인을 생성합니다. 사용 getUserPrincipal() 드림 메서드 또는 getGroupPrincpal() 메서드를 사용하여 외부 ID가 포함된 주 구성원을 만들 수 있습니다. 이 외에도 여러 가지 정적 메서드를 ACL 드림 Cloud Build를 사용하여 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에서 사용자에게 액세스 권한이 부여되더라도 사용자가 하위 항목의 거부된 리더라면 액세스할 수 없습니다.
PARENT_OVERRIDE - 상속 유형을 PARENT_OVERRIDE로 설정하여 상위 항목의 ACL이 하위 항목의 ACL보다 우선 적용됩니다. 있습니다. 따라서 하위 항목의 ACL에서 사용자의 액세스가 거부된 리더로 인해 거부되더라도 사용자에게 상위 항목에 대한 리더 권한이 있으면 계속 액세스할 수 있습니다. 이와 반대로 하위 항목의 ACL에서 사용자에게 액세스 권한이 부여되더라도 사용자가 상위 항목의 거부된 리더라면 액세스할 수 없습니다.

ACL 상속 체인을 평가할 때 평가 순서에 따라 승인 결과가 바뀔 수 있습니다. Cloud Search는 ACL 상속 체인에 리프-루트(leaf-to-root) 평가 순서를 제공합니다. 특히 ACL 결정은 부모와 함께 자녀를 평가하는 것으로 시작해서 발전할 수 있다는 것을 루트 상위 요소로 이동할 수 있습니다.

예를 들어 하위 요소에 CHILD_OVERRIDE 상속 유형이 있고 사용자가 하위 항목에 액세스할 수 있는 경우 Drive에서 상위 항목을 평가할 필요가 없습니다. 그러나 자녀의 계정이 PARENT_OVERRIDE 또는 BOTH_PERMIT인 경우에는 드라이브가 계속 실행됩니다. 상속을 평가하는 방법을 살펴보겠습니다.

포함 및 항목 삭제

항목의 색인을 생성할 때 다음을 사용하여 항목에 컨테이너로 라벨을 지정할 수 있습니다. setContainer() 메서드 IndexingItemBuilder 클래스에 대해 자세히 알아보세요. 컨테이너/컨테이너 관계는 항목이 제대로 삭제되도록 합니다. 컨테이너를 삭제하면 포함된 항목도 함께 삭제됩니다.

포함 관계는 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에 액세스할 수 없습니다.

를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">

포함 계층 구조에서 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를 검색할 수 없습니다.