ACL 작동 방법
특정 액세스 제어 규칙에 정의된 참여자에 대한 권한이 다른 규칙에 정의된 다른 권한과 충돌할 수 있습니다. 예를 들어, /Acme 도메인에 속한 모든 문제 보고서가 검토 중 상태에 있을 때 이러한 객체에 대한 삭제 권한을 Team 1 그룹의 모든 사람에게 부여하는 액세스 제어 규칙을 정의할 수 있습니다. 그러나 다른 액세스 제어 규칙에서 Team 1의 멤버인 사용자 Audrey.Carmen에게 명시적으로 삭제 권한을 거부할 수 있습니다. 이 경우, ACL 메커니즘은 참여자에 대한 네트 권한을 계산합니다.
다음은 권한이 서로 어떻게 작용하는지를 빠르게 확인할 수 있게 표로 간단히 정리한 것입니다. 자세한 설명은 표 다음에 나와 있습니다.
 | 가역할 OWNER에 대한 권한을 거부하는 액세스 제어 규칙은 ACL 계산 시 무시됩니다. |
다음 규칙에 따라 참여자의 네트 권한이 계산됩니다.
• 각 참여자(사용자, 사용자 정의 그룹, 시스템 그룹 또는 조직)는 부여 ACL 엔트리, 거부 ACL 엔트리 및 절대적 거부 ACL 엔트리를 하나씩만 가질 수 있습니다. 한 명의 참여자에게 같은 권한 유형의 여러 ACL 엔트리가 허용되지 않습니다. 각 엔트리는 부여, 거부 또는 절대적 거부되는 권한 세트를 지정합니다. 가역할은 부여 ACL 엔트리와 거부 ACL 엔트리를 하나씩만 가질 수 있습니다. 가역할에는 절대적 거부 권한을 지정할 수 없습니다.
| | 동적 역할은 ACL이 생성되기 전에 특정 시스템 그룹에 적용됩니다. 규칙의 동적 역할 적용 시 고려 사항 항목을 참조하십시오. |
• 지정된 참여자를 제외한 모든 참여자에게 부여, 거부 또는 완전 거부되는 권한은 관리자 사용자, 선택한 사용자나 선택한 그룹, 동적 역할 또는 조직의 사용자를 제외한 모든 사용자로 구성된 그룹에 지정된 권한과 같이 처리됩니다.
• 특정 사용자, 그룹, 가역할 또는 조직에 대한 ACL 엔트리가 없으면 해당 참여자는 널 권한 세트를 갖습니다. 실제로 널 권한 세트가 있으면 객체에 대한 참여자 액세스가 거부됩니다.
• 참여자에게 권한을 주는 부여 엔트리와 참여자 및 동일한 권한에 대한 거부 또는 절대적 거부 엔트리가 있으면 권한이 부여되지 않습니다.
• 가역할 OWNER에게 명시적으로 부여된(+) 권한은 개별 사용자 또는 사용자가 속한 그룹이나 조직에 대한 거부 엔트리를 통해 소유 가능 객체의 소유자인 사용자에게 거부된(-) 권한보다 우선합니다.
• 가역할 OWNER에게 명시적으로 부여된(+) 권한은 개별 사용자 또는 사용자가 속한 그룹이나 조직에 대한 절대적 거부 엔트리를 통해 소유 가능 객체의 소유자인 사용자에게 절대적 거부된(!) 권한보다 우선하지 않습니다.
• 가역할 OWNER에게 거부된(-) 권한은 소유 가능 객체의 소유자인 사용자 또는 사용자가 속한 그룹이나 조직에게 명시적으로 부여된(+) 권한보다 우선하지 않습니다. 가역할 OWNER에게 거부된 권한은 무시됩니다.
• 개별 사용자에 대해 명시적으로 부여된(+) 권한은 해당 사용자의 그룹이나 조직에 대해 거부된(-) 권한과 가역할 ALL에 대해 거부된 권한보다 우선합니다. 예를 들어, 사용자 ReneN은 그룹 1의 멤버입니다. Acme 도메인에 대한 액세스 제어 규칙에 따라 그룹 1의 모든 멤버에게는 라이프 사이클 상태가 검토 중인 문제 보고서에 대한 수정 권한이 거부됩니다. 그러나 다른 액세스 규칙이 ReneN에게 문제 보고서를 수정할 수 있는 권한을 명백히 부여하면 ReneN은 그룹 1의 멤버이더라도 수정 권한을 부여받습니다.
• 사용자에게 절대적 거부(!) 또는 거부된(-) 권한은 해당 사용자의 그룹이나 조직에 대해 부여된(+) 권한보다 우선합니다. 예를 들어, Acme 도메인에 대한 액세스 제어 규칙에 따라 그룹 1의 모든 멤버에게는 라이프 사이클 상태가 검토됨인 변경 고지에 대한 수정 권한이 부여됩니다. 다른 액세스 규칙에서는 ReneN에게 변경 고지에 대한 수정 권한을 거부합니다. ReneN이 그룹 1의 멤버이더라도 ReneN에게 수정 권한이 거부됩니다.
• 그룹이나 조직의 멤버인 개별 사용자에게 명시적으로 권한을 부여(+)하여 해당 그룹이나 조직에 절대적 거부된(!) 권한을 무시할 수 없습니다. 예를 들어, Acme 도메인에 대한 액세스 제어 규칙에 따라 그룹 1의 모든 멤버에게는 라이프 사이클 상태가 완료됨인 변경 요청에 대한 관리 권한이 절대적으로 거부됩니다. 다른 액세스 규칙이 ReneN에게 변경 요청을 관리할 수 있는 권한을 명백히 부여하더라도 ReneN에게는 관리 권한이 거부됩니다.
• 특정 사용자에 대한 네트 그룹 부여 권한 세트는 사용자가 속한 각 그룹 및 조직의 부여 권한을 모두 결합한 것입니다. 여기에는 가역할 ALL에 대해 부여된 권한이 포함됩니다. 예를 들어, 사용자 ReneN이 그룹 1, 그룹 2 및 그룹 3에 속할 경우 ReneN의 부여 그룹 권한 세트에는 이러한 그룹에 부여된 모든 권한이 포함됩니다.
• 특정 사용자에 대한 네트 그룹 거부 권한 세트는 사용자가 속한 각 그룹 및 조직의 거부 권한(-)을 모두 결합한 것입니다. 여기에는 가역할 ALL에 대해 거부된 권한이 포함됩니다. 예를 들어, 사용자 ReneN이 그룹 1, 그룹 2 및 그룹 3에 속할 경우 ReneN의 거부 그룹 권한 세트에는 이러한 그룹에 거부된 모든 권한이 포함됩니다.
• 특정 사용자에 대한 네트 그룹 절대적 거부 권한 세트는 사용자가 속한 각 그룹 및 조직의 절대적 거부 권한(!)을 모두 결합한 것입니다. 예를 들어, 사용자 ReneN이 그룹 1, 그룹 2 및 그룹 3에 속할 경우 ReneN의 거부 그룹 권한 세트에는 이러한 그룹에 거부된 모든 권한이 포함됩니다. 가역할 ALL에 대해서는 권한을 절대적으로 거부할 수 없습니다.
ACL에 대해 권한을 계산할 때 액세스 권한을 결정하기 위해 사용자 ReneN에 대한 부여, 거부 및 절대적 거부 권한 세트가 결합됩니다. 예를 들어, /Acme 도메인에서 라이프 사이클 상태가 검토 중인 모든 문제 보고서에 대한 읽기 권한이 그룹 1의 멤버인 ReneN에게 부여됩니다. 그러나 ReneN은 같은 도메인에 있는 문제 보고서에 대한 읽기 액세스가 거부되는 그룹 2의 멤버이기도 합니다. 권한 계산 시 문제 보고서에 대한 ReneN의 읽기 권한이 /Acme 도메인에 대해 널로 설정되므로 ReneN은 액세스가 거부됩니다.
다음 표는 권한 계산에 대한 자세한 예를 보여줍니다. 여러 도메인에 대한 액세스 제어 정책을 작성 중인 관리자의 경우를 가정해 봅시다. 지정한 사용자 중의 하나인 Ann은 그룹 G1에 속하지만 G2에는 속하지 않습니다. 표에 나온 것과 같이 권한을 할당할 경우 Ann의 결과 권한은 마지막 열에 나타납니다.
G1 권한 | G2를 제외한 모두 권한 | G1과 G2를 제외한 모두 결합 | 개별 권한 | 결과 권한 | |
|---|---|---|---|---|---|
+ - ! | 수정(M) 널 세트 널 세트 | 작성(C) 널 세트 널 세트 | (C)+(M) 널 세트 널 세트 | 삭제(D) + 관리(A) 널 세트 널 세트 | (C)+(M)+(D)+(A) |
+ - ! | (M) (D) (A) | (C) (M) 널 세트 | (C)+(M) (D)+(M) (A) | (D) 널 세트 널 세트 | (C)+(D) |
+ - ! | (M)+(A) (D) 널 세트 | (D) (C) 널 세트 | (M)+(A)+(D) (C)+(D) 널 세트 | (C) (M) (A) | (C) |
+ - ! | (M) 널 세트 널 세트 | (C) 널 세트 (A) | (M)+(C) 널 세트 (A) | (D)+(A) (M) 널 세트 | (C)+(D) |
도메인에 대해 액세스 제어 규칙을 정의하면 규칙이 작성된 같은 도메인에 속하게 되고 특정 상태에 있는 모든 객체 유형의 인스턴스가 ACL을 공유합니다. 따라서 ACL과 객체 유형, 상태 및 도메인 간에 이 연관이 유지됩니다. 참여자가 객체 액세스를 시도할 때는(예: 객체를 보거나 수정하기 위해) 연관된 ACL을 읽어들이고 정책을 시행하게 됩니다. 계산된 ACL은 캐시되므로 다음에 액세스 요청이 있을 때 빨리 읽어들일 수 있습니다.
예를 들어, /Acme 도메인 내에서 사용자 Audrey.Carmen이 닫힘 상태인 WTObject 유형의 모든 객체에 대한 읽기 및 삭제 권한이 있는 그룹의 멤버라고 가정해 봅시다. 또한 Audrey.Carmen은 /Acme/Support 도메인 내에서 닫힘 상태인 모든 문제 보고서에 대한 수정 권한이 있는 그룹의 멤버이며, IncidentReport는 WTObject의 하위 유형입니다. 그러나 /Acme 도메인 내에는 개별 사용자인 Audrey.Carmen에 대한 다른 액세스 제어 규칙이 있으며, 이 규칙은 닫힘 상태인 문제 보고서에 대한 삭제 권한을 명시적으로 거부합니다.
다음은 /Acme/Support 도메인 내에서 닫힘 상태인 문제 보고서와 연관된 Audrey.Carmen에 대한 ACL 엔트리를 보여줍니다.
Audrey.Carmen +읽기, +수정, -삭제
/, /Acme 및 /Acme/Support 도메인에 대한 액세스 제어 정책에서 이 ACL 엔트리가 파생될 때 Audrey.Carmen에게 읽기 및 수정 권한이 주어졌습니다. IncidentReport는 WTObject의 하위 유형이기 때문에 WTObject 유형의 객체에 대한 Audrey의 읽기 및 삭제 권한도 문제 보고서에 적용됩니다. 그러나 닫힘 상태인 문제 보고서에 대해 삭제 권한을 명시적으로 거부하는 다른 액세스 제어 규칙이 있으므로 Audrey의 결과 권한은 읽기 및 수정이며 Audrey는 /Acme/Support 도메인에 속한 해당 유형/상태 조합의 객체를 삭제할 수 없습니다.