버전 8.0 이전의 ClearCase 릴리스에서는 각 VOB 요소가 소유자, 그룹 및 기타와 같은 세 개의 보호 카테고리를 가집니다. 각 카테고리마다 관리자는 읽기 및 실행 비트를 설정 또는 해제할 수 있습니다. 예를 들어, 요소 그룹의 소유자와 구성원은 읽을 수 있지만 네트워크에 있는 모든 사용자는 읽을 수 없는 소스 파일이 있는 경우 owner=read, group=read, other=none으로 설정합니다. 프로그래밍 도구에 대한 실행 파일이 있는 경우 소유자, 그룹, 기타를 모두 읽기 및 실행으로 설정할 수 있습니다.
실제적으로는 이러한 모델의 경우 각 요소 클래스에 대해 동일한 보호를 공유하는 별도의 그룹을 사용해야 합니다. 모든 사용자에게 VOB에 있는 요소를 읽도록 허용하지 않을 경우 기타=없음으로 설정하고 소유자 및 그룹 카테고리를 사용하여 액세스를 제어해야 합니다.
요소 소유자는 제한된 요소 보호 기능만 사용하며 그룹만 제어할 수 있습니다. 요소의 소유자는 기본적으로 요소를 작성한 사용자 계정으로 설정됩니다. 개발자가 여러 명인 경우 요소의 소유자가 각기 다르므로 액세스 제어에 편리하지 않습니다. 일부 관리자는 요소를 작성한 후 소유자를 VOB 소유자 계정으로 변경하는 트리거를 구성하지만 대부분의 사용자가 VOB 소유자의 ID를 사용하지 않으므로 이 또한 액세스 제어에 적합하지 않습니다.
이는 요소의 그룹을 각 요소에 대한 액세스를 제어하기 위한 메커니즘으로 사용합니다. 관리자는 보호해야 하는 각 요소 클래스마다 별도의 그룹을 정의해야 합니다. 예를 들어, 요소 클래스 1은 컴포넌트 A의 개발자, 요소 클래스 2는 컴포넌트 B의 개발자, 요소 클래스 3은 모든 개발자(공유 코드)에 대한 것입니다. 25개의 컴포넌트(A-Y)와 한 개의 공유 컴포넌트(Z)가 있는 경우 액세스를 제어하기 위해 26개의 그룹이 필요합니다. 컴포넌트 A에 있는 모든 요소를 그룹 A에는 읽기 가능하지만 전체 읽기 가능하지 않도록 보호해야 합니다. 컴포넌트 B-Y에 대해서도 이와 같습니다. 컴포넌트 A-Y의 각 개발자는 해당 그룹의 구성원이면서 그룹 Z의 구성원이기도 합니다. 모든 코드를 빌드하고 통합하는 데 사용되는 계정은 모든 그룹 A-Z의 구성원이어야 합니다.
ClearCase에서 사용되는 그룹은 운영 체제(Windows Domain, UNIX NIS 또는 LDAP)에 의해 정의되고 사용자가 ClearCase를 실행하는 호스트에 로그인할 때 사용자 신임 정보에 추가됩니다. 그러나 운영 체제 및 ClearCase에서 사용되는 네트워크 프로토콜의 제한점 때문에 단일 사용자는 ClearCase에서 한 번에 16개 그룹(UNIX 및 Linux) 또는 32개 그룹(Windows)만 사용할 수 있습니다. 위의 예에서 빌드/통합 계정은 ClearCase에 대해 활성화되는 그룹을 정의하는 신임 정보 변경사항 및 빌드 단계의 복잡한 순서를 사용하거나 요소 보안 구현에 대한 절충을 하는 보다 적은 그룹을 사용해야 하는 빌드를 완료하기 위해 26개의 그룹을 사용해야 합니다. 어느 옵션도 적절하지는 않습니다.
ClearCase 8.0.1의 기능 레벨 8 VOB에서 요소 보호에 ACL을 사용하는 경우 사용자별 그룹 멤버십 제한에 부딪치는 여러 경우를 제거하기 위해 액세스 제어 전략을 변경할 수 있습니다. ACL을 사용하여 사용자를 여러 그룹으로 나누는 대신 요소를 여러 그룹으로 나눌 수 있습니다. 요소 유효 ACL에 허용되는 그룹 수가 사용자 계정의 그룹 수와 동일한 하한으로 제한되지 않기 때문에 이 보안 메커니즘은 새 보호 유스 케이스를 사용 가능하게 하고 다른 것은 간소화합니다.
요소에 대한 ACL을 사용하여 여러 개별 사용자, 여러 그룹 및 "모두"의 몇몇 카테고리에 대한 액세스를 부여할 수 있습니다. 이 주제에서는 요소에 대한 ACL을 해당 유효 ACL에 대해 설명합니다. 이 주제 및 관련 주제에는 유효 ACL을 생성하기 위한 역할 맵 및 정책 결합의 예가 나와 있습니다.
위의 예에는 25개의 컴포넌트 A-Y가 있으며, 이는 각각 다른 팀과 빌드 계정("빌더")에 의해 액세스되지만 아무도 액세스 권한을 갖지 않습니다. ACL을 사용하는 경우, 그룹 A 및 빌더에 변경 권한을 부여한 공유 유효 ACL을 통해 지정된 컴포넌트의 모든 요소를 보호합니다.
각 컴포넌트 B-Y는 유사한 유효 ACL을 가집니다. 컴포넌트 Z(공유 컴포넌트)도 유사한 유효 ACL을 가집니다. 이러한 구성에서 각 팀 구성원의 계정은 해당 컴포넌트에 대한 그룹과 Z에 대한 그룹(이전처럼)에 들어 있습니다. 그러나 빌더 계정은 "빌더" 그룹에만 있어야 합니다. 빌더 계정에 대한 동시 그룹 멤버십의 한계에 부딪치지 않아야 합니다.
또한 시스템 빌드 중에 복잡한 전략을 사용하거나 컴포넌트 A-Y에 대한 보안을 타협할 필요가 없습니다. 요소에 읽기 전용 액세스 및 추가 그룹을 추가할 수 있는 유연성을 갖게 됩니다. 컴포넌트 Z가 자체 팀에서 유지보수되지만 팀 A-Y에서만 참조되어야 하며 Z 이외의 개발자를 "groupZ" 대신 "alldevelopers" 그룹으로 포함시킨다고 가정하십시오. groupZ가 변경 권한을 갖도록 컴포넌트 Z의 요소 ACL을 구성할 수 있으며, alldevelopers는 읽기 권한을 갖고 빌더는 변경 권한을 가집니다.
팀 A의 개발자는 컴포넌트 Z의 요소를 읽을 수 있지만 이를 수정할 수 없습니다. (ACL을 사용하지 않는 경우, 요소를 수정할 수 있는 권한을 검사하고 권한이 없는 경우 조작을 거부하기 위한 사전 조작 체크아웃 및 mkbranck 트리거가 필요합니다.)
개별 계정을 요소 ACL에 포함시킬 수도 있습니다. 이는 컴포넌트에 대해 특정 액세스가 필요한 소수 개인이 있는 경우에 해당될 수 있으며 이러한 용도로만 새 운영 체제 그룹을 작성하는 것은 적당하지 않습니다. 따라서 컴포넌트 B를 해당 팀과 다른 사용자("extrauser")가 수정해야 하는 경우 ACL은 groupB, extrauser, builders에게 변경 권한을 부여합니다.
여러 팀에서 유지보수되는 일부 컴포넌트가 있는 경우 이전에 사용된 일부 그룹을 제거할 수 있어야 합니다. 컴포넌트 E가 컴포넌트 C와 D의 모든 팀 구성원에 의해 유지보수된다고 가정하십시오. 8.0 예제에서는 그룹 C와 D 모두의 구성원을 모두 포함하기 위해 그룹 E가 필요했습니다. ACL을 사용하면 두 그룹을 모두 이름 지정하기 위해 컴포넌트 E의 ACL을 설정한 다음, 그룹 E를 사용하지 않을 수 있습니다(팀 C와 D의 계정에 대한 그룹 목록에서 이를 제거함).
앞에 있는 설명은 유효 ACL에 대한 설명입니다. VOB에서 유효 ACL은 정책에 대한 역할 맵을 적용하여 생성됩니다. VOB 데이터베이스는 각 역할 맵에 대한 유효 ACL을 계산하고 캐시합니다. 각 요소는 역할 맵과 연관됩니다. 위의 예를 구현하기 위해서는 요소의 각 클래스에 대한 고유 역할 맵이 필요합니다(컴포넌트 A-Z). 이러한 모든 역할 맵을 일반 보호 모델을 설명하는 단일 정책으로 링크할 수 있습니다. 다음은 위에 표시된 유효 ACL을 생성하는 역할 맵 세트와 정책의 예입니다. (실제로는 모든 요소에 대한 전체 제어를 갖는 관리 사용자 또는 그룹을 추가할 수 있습니다.)