접근 제어 목록 탐색

ACL의 구성요소

모든 접근 제어 목록 규칙에는 다음과 같은 사항이 명시되어 있습니다.

보호 중인 객체 및 작업
객체에 접근하는 데 필요한 권한

객체는 접근에 대한 제어가 필요한 대상입니다. 각 객체는 특정 테이블, 필드 또는 기록을 고유하게 식별하는 유형과 이름으로 구성됩니다.

예를 들어, 이러한 항목은 모두 객체를 지정합니다.


유형	이름	객체 보안
기록	[인시던트]. [--없음--]	인시던트 테이블입니다.
기록	[인시던트]. [사용 효과]	인시던트 테이블의 활성 필드입니다.
REST_Endpoint	user_role_inheritance	user_role_inheritance Scripted REST API에 대한 기록입니다.

각 작업은 시스템이 지정된 객체에 대해 수행할 수 있는 유효한 동작을 설명합니다. 기록과 같은 일부 객체는 여러 작업을 지원하지만 REST_Endpoint 등의 다른 객체는 하나의 작업만 지원합니다.

예를 들어, 이러한 항목은 모두 작업을 지정합니다.


유형	이름	운영	작업 보안
기록	[인시던트]. [-- 없음 --]	작성	인시던트 테이블에서 기록을 생성합니다.
기록	[인시던트]. [사용 효과]	쓰기	인시던트 테이블에서 활성 필드를 업데이트하는 중입니다.
REST_Endpoint	user_role_inheritance	실행	user_role_inheritance Scripted REST API를 실행합니다.

권한은 누군가가 명명된 객체 및 작업에 접근할 수 있는 시기를 지정합니다. 보안 관리자는 다음을 추가하여 권한 요구 사항을 지정할 수 있습니다.

역할 필요 목록에 하나 이상의 사용자 역할.
하나 이상의 조건
true 또는 false로 평가하거나 응답 변수를 true 또는 false로 설정하는 스크립트

객체 및 작업에 대한 액세스 권한을 얻으려면 사용자가 액세스 제어에 나열된 모든 권한을 전달해야 합니다. 예를 들어, 이 접근 제어는 인시던트 테이블에서 보기 작업에 대한 액세스를 제한합니다.

인시던트 기록의 ACL.

인시던트 테이블의 기록을 업데이트하려면 사용자에게 나열된 역할이 있어야 하고 기록이 조건을 충족해야 합니다.


권한 유형	요구 사항	설명
역할 필요	role:itil 필요	itil 역할을 가진 사용자만 인시던트를 업데이트할 수 있도록 합니다.
조건	[인시던트 상태] [일치하지 않음] [휴관일]	활성 인시던트 기록에 대한 업데이트만 허용합니다.

ACL 평가 프로세스

ACL 규칙은 사용자가 일치하는 ACL 규칙에 필요한 모든 사용 권한을 충족하는 경우에만 개체에 대한 액세스 권한을 부여합니다.

조건은 true로 평가되어야 합니다.
스크립트는 true 로 평가되거나 true 값을 가진 응답 변수를 반환해야 합니다.
사용자는 필요한 역할 목록에 있는 역할 중 하나를 가지고 있어야 합니다. 목록이 비어 있으면 이 조건은 true로 평가됩니다.
[기록 ACL 규칙만] 일치하는 테이블 수준 ACL 규칙과 필드 수준 ACL 규칙은 모두 true로 평가되어야 합니다.

하나의 세션이 데이터를 요청할 때마다 시스템은 요청된 객체 및 운영과 일치하는 접근 제어 규칙을 검색합니다. 일치하는 접근 제어 규칙이 있는 경우 시스템은 사용자가 객체 및 운영에 접근하는 데 필요한 권한이 있는지 평가합니다. 접근 제어 규칙이 둘 이상의 권한을 지정할 경우, 사용자는 객체 및 운영에 접근하기 위한 모든 권한을 충족해야 합니다. 하나의 권한 검사를 통과하지 못할 경우, 사용자는 일치하는 객체 및 운영에 접근할 수 없습니다.

사용자가 첫 번째로 일치하는 규칙의 권한을 충족하지 않을 경우, 시스템은 접근 제어 처리 순서에 따라 지정된 바와 같이 그 다음으로 일치하는 접근 제어 규칙의 권한을 평가합니다. 사용자가 일치하는 접근 제어 규칙의 권한을 충족하지 못하면 시스템은 요청된 객체 및 운영에 대한 접근을 거부합니다.

주:

요청된 객체 및 운영에 대해 일치하는 접근 제어 규칙이 없는 경우 시스템은 사용자에게 접근 권한을 부여합니다. 실제로 시스템에는 모든 기록 작업을 보호하는 기본 접근 제어 규칙 세트가 있기 때문에 시스템에서 일치하는 규칙을 찾을 수 없는 경우는 드뭅니다.

개체에 대한 액세스 거부의 영향은 사용자가 실패한 ACL 규칙에 따라 달라집니다. 예를 들어, 읽기 작업 ACL 규칙이 실패하면 사용자가 객체를 볼 수 없습니다. 보안된 객체에 따라 ACL 규칙은 양식에서 필드를 숨기거나, 목록에서 행을 숨기거나, 사용자가 UI 페이지에 액세스하지 못하게 합니다. 다음 표에는 지정된 작업 및 객체 유형에 대한 ACL 규칙 실패 결과의 전체 목록이 포함되어 있습니다.

사전 및 사후 쿼리 ACL 검사

인스턴스는 사용자가 쿼리하기 전과 후에 ACL 규칙을 확인합니다. 쿼리 전후에 사용할 수 있는 정보가 다르기 때문에 결과가 다를 수 있습니다.

사전 쿼리 ACL 검사

인스턴스는 데이터베이스 쿼리를 실행하기 전에 쿼리된 테이블의 각 필드에 대한 ACL 규칙을 검사하여 사용자가 액세스할 수 있는 필드를 결정합니다. 이 검사는 사용자의 역할만 살펴보고 이러한 역할이 필드에 대한 액세스를 허용하는지 확인합니다. 이 검사는 쿼리 전에 실행되기 때문에 ACL은 테이블의 레코드에 액세스할 수 없으므로 해당 데이터를 고려할 수 없습니다. 기록의 콘텐츠 파악에 의존하는 스크립트와 조건은 평가되지 않습니다.

이 시점에서 사용자에게 읽기 권한이 없는 경우 필드 값이 사용자에게 표시되지 않습니다.

쿼리 후 ACL 검사

쿼리 후 인스턴스는 쿼리에서 반환된 각 기록을 확인합니다. 이 검사 중에 ACL에 대한 컨텍스트가 있으므로 ACL의 역할, 조건 및 스크립트 부분이 평가됩니다. 이 시점에서 사용자에게 읽기 액세스 권한이 없는 경우 필드 값이 사용자에게 표시되지 않지만 해당 역할이 필드에 대한 액세스를 허용하는 경우 사용자에게 필드 레이블이 표시됩니다.


운영	객체에 대한 ACL 규칙 실패의 결과
실행	사용자는 기록 또는 UI 페이지에서 스크립트를 실행할 수 없습니다.
작성	사용자는 양식에서 새 UI 작업을 볼 수 없습니다. 또한 사용자는 웹 서비스와 같은 API 프로토콜을 사용하여 테이블에 레코드를 삽입할 수 없습니다. 필드에 특정 값이 포함되어야 한다는 조건이 있는 ACL 생성 은 항상 false로 평가됩니다. 새 기록의 필드는 기록이 저장될 때까지 비어 있는 것으로 간주됩니다.
read	사용자는 양식 또는 목록에서 객체를 볼 수 없습니다. 또한 사용자는 웹 서비스와 같은 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 규칙이 있는 경우). 객체의 이름과 일치하는 첫 번째 ACL 규칙입니다(작업에 대한 ACL 규칙이 있는 경우).	기본적으로 이러한 개체 형식에는 와일드카드(*) 규칙이 없습니다. 이러한 개체 중 하나에 대해 와일드카드 ACL 규칙을 생성하면 이 유형의 모든 개체에 ACL 규칙이 적용됩니다.
프로세서
UI 페이지	사용자는 다음 두 가지 ACL 규칙의 권한을 충족해야 합니다. 기록의 필드와 일치하는 첫 번째 ACL 규칙입니다(작업에 대한 ACL 규칙이 있는 경우). 기록의 테이블과 일치하는 첫 번째 ACL 규칙입니다(작업에 대한 ACL 규칙이 있는 경우).	기본적으로 생성, 읽기, 쓰기 및 삭제 작업을 위한 와일드카드 테이블 규칙()과 personalize_choices, 생성 및 save_as_template 작업을 위한 와일드카드 필드 규칙(.*)이 있습니다. 테이블을 생성할 때 제공된 와일드카드 ACL 규칙을 사용하지 않으려면 테이블에 대한 ACL 규칙을 생성합니다.
기록

주:

보안 관리자 기본 동작(glide.sm.default_mode) 특성은 사용자가 와일드카드 테이블 ACL 규칙에 대해서만 일치하는 오브젝트에 액세스할 수 있는지 여부를 판별합니다. 이 속성을 액세스 거부로 설정하면 관리자만 와일드카드 테이블 ACL 규칙과 일치하는 객체에 액세스할 수 있습니다.

주:

생성 작업에 대한 와일드카드 필드 ACL 규칙(*.*)은 쓰기 작업과 동일한 권한을 다시 사용합니다. 즉, 생성 권한은 명시적 생성 작업 ACL 규칙을 정의하지 않는 한 쓰기 권한과 동일합니다.

처리 순서의 동일한 지점에 있는 여러 ACL 규칙

두 개 이상의 규칙이 처리 순서의 동일한 지점에서 일치하는 경우 사용자는 ACL 규칙 권한 중 하나를 전달해야 개체에 액세스할 수 있습니다. 예를 들어, 에 대해 incident.number두 개의 필드 ACL 규칙을 만드는 경우, 한 규칙을 통과한 사용자는 처리 순서의 동일한 지점에서 다른 필드 ACL 규칙을 실패했는지 여부에 관계없이 번호 필드에 액세스할 수 있습니다.

필요한 역할

일반 관리자 사용자는 접근 제어 규칙을 보고 디버그할 수 있습니다. 그러나 기존 접근 제어 규칙을 만들거나 업데이트하려면 관리자가 security_admin 역할에 대한 권한을 높여야 합니다. 지침은 권한 있는 역할로 상승 문서를 참조하십시오.

범위가 지정된 애플리케이션의 ACL 규칙

ACL 규칙과 동일한 범위에 있는 객체에 대한 ACL 규칙을 만들 수 있습니다. ACL 규칙과 같은 범위에 있는 필드가 하나 이상 있는 테이블에 대한 ACL 규칙을 만들 수도 있습니다.

ACL 규칙 기록과 다른 범위에 있는 테이블의 경우 규칙 유형이 제한됩니다.

ACL 규칙과 동일한 범위에 있는 테이블, UI 페이지 또는 기타 객체에 대해 ACL 규칙을 만들 수 있습니다.
ACL 규칙과 같은 범위에 있는 필드에 대한 ACL을 만들 수 있습니다.
- 테이블이 동일한 범위에 있으면 스크립트를 사용하여 사용 권한을 평가할 수 있습니다.
- 테이블이 다른 범위에 있는 경우 스크립트를 사용하여 사용 권한을 평가할 수 없습니다.
다른 범위의 ACL에 역할을 추가하는 것을 포함하여 애플리케이션 선택기에서 선택한 애플리케이션과 다른 범위에 있는 객체에 대한 ACL 규칙을 만들거나 수정할 수 없습니다.
와일드카드 테이블 규칙(*)은 전역 범위에서만 만들 수 있습니다.
ACL 규칙과 같은 범위에 있는 테이블에 대해서만 와일드카드 필드 규칙(*)을 생성할 수 있습니다.