접근 제어 목록 탐색
접근 제어 목록(ACL)을 탐색합니다.
- ACL을 정의하는 결정 유형, 규칙 유형 및 작업
- 보호 중인 객체
- 객체에 접근하는 데 필요한 조건
ACL의 구성요소
결정 유형은 조건이 충족되면 사용자가 객체에 액세스할 수 있는지 또는 조건이 충족되지 않으면 객체에 대한 접근을 거부할지 정의합니다.
| 결정 유형 | 설명 |
|---|---|
| 거부-미충족 | 조건이 전달되지 않는 한 접근을 명시적으로 거부하여 자원에 대한 접근을 제한합니다. 자세한 내용은 acl-denial-behavior.html#acl-denial-behavior__section_qnd_snl_zbc 문서를 참조하십시오. |
| Allow-If (조건) | 조건이 통과되면 자원에 대한 액세스를 허용합니다. |
객체는 접근에 대한 제어가 필요한 대상입니다. 각 객체는 특정 테이블, 필드 또는 기록을 고유하게 식별하는 유형과 이름으로 구성됩니다. 적용 대상 필드를 사용하면 사용자가 이 ACL을 적용할 특정 기록을 세부적으로 제어할 수 있습니다.
예를 들어, 이러한 항목은 모두 객체를 지정합니다.
| 유형 | 이름 | 객체 보안됨 |
|---|---|---|
| 기록 | [인시던트]. [--없음--] | 인시던트 테이블입니다. |
| 기록 | [인시던트]. [사용 효과] | 인시던트 테이블의 활성 필드입니다. |
| 기록 | [incident] 적용 대상: 우선순위 = P1 |
인시던트 테이블의 우선순위 1 인시던트만 표시됩니다. |
| REST_Endpoint | user_role_inheritance | user_role_inheritance 스크립팅된 REST API에 대한 기록입니다. |
각 작업은 시스템이 지정된 객체에 대해 수행할 수 있는 유효한 동작을 설명합니다. 기록과 같은 일부 객체는 여러 작업을 지원하지만 REST_Endpoint 등의 다른 객체는 하나의 작업만 지원합니다.
예를 들어, 이러한 항목은 모두 작업을 지정합니다.
| 유형 | 이름 | 운영 | 운영 보안 |
|---|---|---|---|
| 기록 | [인시던트]. [-- 없음 --] | 생성 | 인시던트 테이블에 기록을 생성합니다. |
| 기록 | [인시던트]. [사용 효과] | 쓰기 | 인시던트 테이블에서 활성 필드를 업데이트하는 중입니다. |
| REST_Endpoint | user_role_inheritance | 실행 | user_role_inheritance 스크립트된 REST API를 실행합니다. |
- 역할 필요 목록에 하나 이상의 사용자 역할.
- 하나 이상의 보안 속성을 true로 평가해야 합니다.
- 하나 이상의 데이터 조건입니다.
- true 또는 false로 평가하거나
응답변수를 true 또는 false로 설정하는 스크립트
객체 및 작업에 대한 액세스 권한을 획득하려면 사용자는 액세스 제어에 나열된 모든 조건을 통과해야 합니다. 예를 들어, 이 액세스 제어는 인시던트 테이블에서 작업을 보기 위한 액세스를 제한합니다.
인시던트 테이블의 기록을 업데이트하려면 사용자에게 나열된 역할이 있어야 하고 기록이 조건을 충족해야 합니다.
| 조건 유형 | 요구 사항 | 설명 |
|---|---|---|
| 역할 필요 | 필요한 역할:itil | itil 역할을 가진 사용자만 인시던트를 업데이트할 수 있도록 허용합니다. |
| 보안 속성 | UserIsAuthenticated | 인증된 사용자만 인시던트를 업데이트할 수 있습니다. |
| 데이터 조건 | [인시던트 상태] [일치하지 않음] [휴관일] | 활성 인시던트 기록에 대한 업데이트만 허용합니다. |
기본 동작 거부
- 정의된 역할
- 보안 속성
- 데이터 조건
- 스크립트
- 존재하지 않는 역할이 있는 ACL(예: 데이터베이스에 행이 없음)
- 존재하지 않는 보안 속성이 있는 ACL(예: 데이터베이스에 행이 없음)
- "answer=true" 또는 "true"가 포함된 스크립트가 있는 ACL
시스템에서 사용자가 ACL을 만드는 것을 감지하면 사용자에게 역할 또는 기존 보안 속성을 선택하라는 메시지를 표시합니다.
ACL 평가 프로세스
ACL 규칙은 사용자가 일치하는 ACL 규칙에서 요구하는 모든 조건을 충족하는 경우에만 객체에 대한 접근 권한을 부여합니다.
- 조건은 true로 평가되어야 합니다.
- 스크립트는 true 로 평가하거나 true 값을 가진 응답 변수를 반환해야 합니다.
- 사용자에게 필수 역할 목록에 있는 역할 중 하나가 있어야 합니다. 목록이 비어 있으면 이 조건은 true로 평가됩니다.
- [기록 ACL 규칙만] 일치하는 테이블 수준 및 필드 수준 ACL 규칙은 모두 true로 평가해야 합니다.
하나의 세션이 데이터를 요청할 때마다 시스템은 요청된 객체 및 운영과 일치하는 접근 제어 규칙을 검색합니다. 일치하는 접근 제어 규칙이 있는 경우 시스템은 사용자가 객체 및 운영에 접근하는 데 필요한 조건을 갖추고 있는지 평가합니다. 접근 제어 규칙이 둘 이상의 조건을 지정할 경우, 사용자는 객체 및 운영에 접근하기 위해 모든 조건을 충족해야 합니다. 한 가지 조건 검사를 통과하지 못할 경우, 사용자는 일치하는 객체 및 운영에 접근할 수 없습니다.
개체에 대한 액세스가 거부되는 경우의 영향은 사용자가 실패했다는 ACL 규칙에 따라 달라집니다. 예를 들어, 읽기 작업 ACL 규칙에 실패하면 사용자가 객체를 볼 수 없습니다. 보호되는 객체에 따라 ACL 규칙은 양식에서 필드를 숨기거나, 목록에서 행을 숨기거나, 사용자가 UI 페이지에 액세스하지 못하게 합니다. 다음 표에는 지정된 작업 및 객체 유형에 대한 ACL 규칙 실패의 전체 결과 목록이 포함되어 있습니다.
사전 및 사후 쿼리 ACL 검사
- 사전 쿼리 ACL 검사
-
인스턴스는 데이터베이스 쿼리를 실행하기 전에 쿼리된 테이블의 각 필드에 대한 ACL 규칙을 검사하여 사용자가 액세스할 수 있는 필드를 결정합니다. 이 검사는 사용자의 역할만 보고 이러한 역할이 필드에 대한 액세스를 허용하는지 확인합니다. 이 검사는 쿼리 전에 실행되므로 ACL은 테이블의 레코드에 액세스할 수 없으므로 해당 데이터를 고려할 수 없습니다. 기록의 내용 파악에 의존하는 스크립트와 조건은 평가되지 않습니다.
이 시점에서 사용자에게 읽기 액세스 권한이 없는 경우 필드 값이 사용자에게 표시되지 않습니다.
- 쿼리 후 ACL 검사
-
쿼리 후에 인스턴스는 쿼리에서 반환된 각 레코드를 확인합니다. 이 검사 중에 ACL에 대한 컨텍스트가 있으므로 ACL의 역할, 조건 및 스크립트 부분이 평가됩니다. 사용자에게 이 시점에서 읽기 액세스 권한이 없는 경우 필드 값이 사용자에게 표시되지 않지만 역할이 필드에 대한 액세스를 허용하는 경우 사용자에게 필드 레이블이 표시됩니다.
| 운영 | 객체에 대한 ACL 규칙 실패의 결과 |
|---|---|
| 실행 | 사용자는 기록 또는 UI 페이지에서 스크립트를 실행할 수 없습니다. |
| 생성 | 사용자는 양식에서 새 UI 작업을 볼 수 없습니다. 또한 사용자는 웹 서비스와 같은 API 프로토콜을 사용하여 테이블에 기록을 삽입할 수 없습니다. 필드에 특정 값이 포함되어야 한다는 조건이 있는 ACL 생성 은 항상 false로 평가됩니다. 새 기록의 필드는 기록이 저장될 때까지 비어 있는 것으로 간주됩니다. |
| 읽음 | 사용자는 양식 또는 목록에서 객체를 볼 수 없습니다. 또한 사용자는 웹 서비스와 같은 API 프로토콜을 사용하여 레코드를 검색할 수 없습니다. |
| 쓰기 | 사용자는 양식과 목록에서 읽기 전용 필드를 볼 수 있으며 웹 서비스와 같은 API 프로토콜을 사용하여 기록을 업데이트할 수 없습니다. |
| 삭제 | 사용자는 양식에서 UI 삭제 작업을 볼 수 없습니다. 또한 사용자는 웹 서비스와 같은 API 프로토콜을 사용하여 테이블에서 레코드를 제거할 수 없습니다. |
| edit_task_relations | 사용자는 작업 테이블 간의 관계를 정의할 수 없습니다. |
| edit_ci_relations | 사용자는 구성 항목 [cmdb_ci] 테이블 간의 관계를 정의할 수 없습니다. |
| save_as_template | 템플릿을 만들 때 저장해야 하는 필드를 제어하는 데 사용됩니다. |
| add_to_list | 사용자는 정비사 목록의 특정 열을 보거나 개인화할 수 없습니다. |
| list_edit | 사용자는 목록에서 기록(행)을 업데이트할 수 없습니다. |
| report_on | 사용자는 ACL 테이블에서 보고서를 생성할 수 없습니다. 자세한 내용은 ACL 규칙으로 보고서 생성 제한을 참조하세요. |
| report_view | 사용자는 ACL 테이블 또는 ACL 필드에서 보고서의 내용을 볼 수 없습니다. 자세한 내용은 Reporting 문서를 참조하십시오. |
| personalize_choices | 사용자는 목록 필드를 마우스 오른쪽 단추로 클릭하고 선택 사항 구성을 선택할 수 없습니다. |
객체에 대한 ACL 일치 요구 사항
| 객체 유형 | 객체에 접근하는 데 필요한 일치하는 ACL 규칙 | 기존 와일드카드 ACL 규칙 |
|---|---|---|
| 클라이언트 호출 가능 스크립트 포함 | 사용자는 다음 두 ACL 규칙의 조건을 충족해야 합니다.
|
기본적으로 이러한 개체 유형에는 와일드카드(*) 규칙이 없습니다. 이러한 개체 중 하나에 대해 와일드카드 ACL 규칙을 생성하면 ACL 규칙이 이 유형의 모든 개체에 적용됩니다. |
| 프로세서 | ||
| UI 페이지 | 사용자는 다음 두 ACL 규칙의 조건을 충족해야 합니다.
|
기본적으로 생성, 읽기, 쓰기 및 삭제 작업에는 와일드카드 테이블 규칙(*)이 있고 personalize_choices, 생성 및 save_as_template 작업에는 와일드카드 필드 규칙(*.*)이 있습니다. 테이블을 생성할 때 제공된 와일드카드 ACL 규칙을 사용하지 않으려면 테이블에 대한 ACL 규칙을 생성합니다. |
| 기록 |
처리 순서의 동일한 지점에 있는 여러 ACL 규칙
두 개 이상의 규칙이 처리 순서의 동일한 지점에서 일치하는 경우 사용자는 ACL 규칙 조건 중 하나를 통과해야 객체에 액세스할 수 있습니다. 예를 들어, 에 대해 incident.number두 개의 필드 ACL 규칙을 만드는 경우, 한 규칙을 통과한 사용자는 처리 순서의 동일한 지점에서 다른 필드 ACL 규칙을 실패했는지 여부에 관계없이 번호 필드에 액세스할 수 있습니다.
필요한 역할
일반 관리자 사용자는 접근 제어 규칙을 확인하고 디버그할 수 있습니다. 그러나 기존 접근 제어 규칙을 생성하거나 업데이트하려면 관리자가 security_admin 역할에 대한 권한을 높여야 합니다. 지침은 권한 있는 역할로 승격 문서를 참조하십시오.
범위가 지정된 애플리케이션의 ACL 규칙
ACL 규칙과 동일한 범위에 있는 객체에 대해 ACL 규칙을 만들 수 있습니다. ACL 규칙과 동일한 범위에 있는 하나 이상의 필드가 있는 테이블에 대한 ACL 규칙을 생성할 수도 있습니다.
- ACL 규칙과 동일한 범위에 있는 모든 테이블, UI 페이지 또는 기타 객체에 대해 ACL 규칙을 생성할 수 있습니다.
- ACL 규칙과 같은 범위에 있는 필드에 대한 ACL을 만들 수 있습니다.
- 테이블이 동일한 범위에 있으면 스크립트를 사용하여 조건을 평가할 수 있습니다.
- 테이블이 다른 범위에 있으면 스크립트를 사용하여 조건을 평가할 수 없습니다.
- 애플리케이션 선택기에서 선택한 애플리케이션과 다른 범위에 있는 객체에 대해서는 ACL 규칙을 만들거나 수정할 수 없습니다(다른 범위의 ACL에 역할 추가 포함).
- 와일드카드 테이블 규칙(*)은 전역 범위에서만 생성할 수 있습니다.
- 와일드카드 필드 규칙(*)은 ACL 규칙과 같은 범위에 있는 테이블에 대해서만 생성할 수 있습니다.