05. Access Control

Access Control

ITU-T Recommendation X.800이 정의한 access control(접근 제어)

resource의 무단 사용 방지를 포함하여, 승인되지 않은 방식으로 resource를 사용하는 것을 방지하는 것

Access Control Principles

RFC 2828이 정의한 computer security(컴퓨터 보안)

컴퓨터 시스템에서 보안 서비스를 구현하고 보증하는 조치, 특히 접근 제어 서비스를 보증하는 조치

Relationship Among Access Control and Other Security Functions

• access control은 authentication(인증) 및 audit(감사)과 밀접하게 관련
• 인증은 사용자의 신원을 확인하고, access control은 확인된 사용자가 특정 resource에 접근할 수 있는지 여부를 결정
• Auditing 기능은 접근 시도를 기록하여 보안 policy 준수 여부를 확인하고 침입을 탐지

Access Control Policies

• Discretionary Access Control(임의 접근 제어, DAC): resource의 소유자가 다른 subject에 대한 접근 권한을 설정
• Mandatory Access Control(강제 접근 제어, MAC): 시스템 전반의 policy에 따라 접근 권한이 중앙에서 관리됨.
• Role-Based Access Control(role 기반 접근 제어, RBAC): 사용자의 조직 내 role에 따라 접근 권한을 부여

Access Control Requirements

• Reliable input(신뢰 가능한 입력)
• Support for fine and coarse specifications(세밀하고 포괄적인 명세 지원)
• Least privilege(최소 권한)
• Separation of duty(직무 분리)
  • 하나의 작업을 완료하기 위해 두 명 이상이 필요
• Open and closed policies(개방 및 폐쇄 policy)
• Policy combinations and conflict resolution(policy 조합 및 충돌 해결)
• Administrative policies(관리 policy)
  • policy 개발 절차 등...

Access Control Basic Elements

• Subject(주체): object에 접근할 수 있는 entity
  • process(process)의 개념과 동일
  • 일반적으로 자신이 시작한 행동에 대해 책임이 있음.
  • 종종 owner(소유자), group(그룹), world(월드)의 세 가지 class를 가짐.
• Object(객체): 접근이 control되는 resource(자원)
  • 정보를 포함 and/or 수신하는 데 사용되는 entity
  • 보호는 access control이 작동하는 환경에 따라 달라짐.
• Access right(접근 권한): subject가 object에 접근하는 방식을 기술
  • 예: read(읽기), write(쓰기), execute(실행), delete(삭제), create(생성), search(검색)

Mandatory Access Control

• MAC(강제 접근 제어)는 더 제한적인 방식
• 소유권과 관계없이 사용자가 파일에 대한 권한을 정의하는 것을 허용하지 않음.
• 대신, 보안 결정은 central policy administrator(중앙 policy 관리자)에 의해 이루어짐.
• 각 보안 규칙은 접근을 시도하는 당사자를 나타내는 subject, 접근 대상 resource를 가리키는 object, 그리고 해당 resource에 접근할 수 있는 범위를 정의하는 일련의 권한으로 구성됨.
• SELinux(Security-Enhanced Linux)는 MAC을 통합함.

SELinux and MAC

• 모든 process와 시스템 resource는 SELinux context(SELinux 컨텍스트, 또는 SELinux 레이블)라는 특별한 보안 레이블을 가짐.
• SELinux policy은 이 context를 일련의 규칙에서 사용하여 process가 서로 및 다양한 시스템 resource과 상호 작용하는 방식을 정의함.
• 기본적으로, policy은 규칙이 명시적으로 접근을 허용하지 않는 한 어떠한 상호 작용도 허용하지 않음.
• SELinux context는 user(사용자), role(role), type(유형), security level(보안 수준) 등 여러 field를 가짐.
• 가장 일반적인 policy 규칙이 전체 SELinux context가 아닌 SELinux 유형을 사용하기 때문에 SELinux 유형 정보가 SELinux policy에서 가장 중요할 수 있음.

Discretionary Access Control (DAC)

• 한 entity가 다른 entity에게 일부 resource에 접근할 수 있도록 허용하는 방식
• 종종 access matrix(접근 행렬)을 사용하여 제공됨.
  • 한 차원은 resource에 대한 데이터 접근을 시도할 수 있는 식별된 subject로 구성됨.
  • 다른 차원은 접근될 수 있는 object를 나열함.
• 행렬의 각 항목은 특정 subject가 특정 object에 대해 갖는 접근 권한을 나타냄.

Access Matrix

• 행은 subject(사용자, process)를 나타내고 열은 object(파일, 장치)를 나타냄.
• 행렬의 각 셀 $(i,~j)$는 subject $i$가 object $j$에 대해 가질 수 있는 접근 권한(예: 읽기, 쓰기, 소유)을 명시함.

Example of Access Control Structures

• Access matrix(접근 행렬): subject와 object 간의 모든 권한을 표로 나타냄.
• Access Control Lists(접근 제어 목록, ACLs): object 중심. 각 object에 대해 어떤 subject가 어떤 권한을 갖는지 목록으로 관리 (access matrix의 열에 해당)
• Capability Lists(능력 목록): subject 중심. 각 subject가 어떤 object에 대해 어떤 권한을 갖는지 목록으로 관리 (access matrix의 행에 해당)

Extended Access Control Matrix

• 기존 access matrix을 확장하여 조건부 access control을 포함할 수 있음.
• 예를 들어, 특정 subject가 object에 대한 권한을 다른 subject에게 copy(복사)하거나 owner(소유권)를 이전하는 권한, 또는 접근을 Audit(감사)하는 권한 등을 추가로 명시.

Access Control Function

• 사용자가 object에 대한 접근을 요청하면, Access Control Function(접근 제어 함수)이 요청을 가로챔.
• 이 function은 Access Control Policy을 참조하여 요청을 grant할지 deny할지 결정함.
• 결정 결과는 Audit File에 기록될 수 있음.

Table 4.2 Access Control System Commands

Protection Domains

• object와 그 object에 대한 접근 권한의 집합
• protection domains(보호 도메인)과 능력을 연관시킬 때 더 큰 유연성을 제공
• Access matrix 측면에서, 한 행은 보호 도메인을 정의함.
• 사용자는 자신의 접근 권한의 일부를 가진 process를 생성할 수 있음.
• process와 도메인 간의 연관은 정적이거나 동적일 수 있음.
• user mode(사용자 모드)에서는 특정 메모리 영역이 사용으로부터 보호되며 특정 명령어는 실행될 수 없음.
• kernel mode(커널 모드)에서는 특권 명령어가 실행될 수 있으며 보호된 메모리 영역에 접근할 수 있음.

UNIX File Access Control

• UNIX 파일은 i-nodes(아이노드, index nodes)를 사용하여 관리됨.
  • 특정 파일에 필요한 주요 정보가 있는 제어 구조
  • 여러 파일 이름이 단일 inode와 연관될 수 있음.
  • 활성 inode는 정확히 하나의 파일과 연관됨.
  • 파일 속성, 권한 및 제어 정보는 inode에 저장됨.
  • 디스크에는 파일 시스템의 모든 파일의 inode를 포함하는 inode 테이블 또는 inode 목록이 있음.
  • 파일이 열리면 해당 inode가 주 메모리로 가져와져 메모리 상주 inode 테이블에 저장됨.
• directory는 계층적 트리 구조로 구성됨.
  • 파일 및/또는 다른 directory를 포함할 수 있음.
  • 파일 이름과 연관된 inode를 가리키는 포인터를 포함함.
• user ID(고유 사용자 식별 번호, 사용자 ID)
• 그룹 ID로 식별되는 주 그룹의 멤버
• 특정 그룹에 속함.
• 12개의 보호 비트
  • 파일의 소유자, 그룹 멤버, 그리고 다른 모든 사용자에 대한 읽기, 쓰기, 실행 권한을 명시
• 소유자 ID, 그룹 ID, 보호 비트는 파일의 inode의 일부임.

Traditional UNIX File Access Control

• "set user ID"(SetUID)
• "set group ID"(SetGID)
  • 시스템이 access control decision을 내릴 때 실제 사용자의 권한에 더하여 파일 소유자/그룹의 권한을 일시적으로 사용함.
  • 특권 프로그램이 일반적으로 접근할 수 없는 파일/resource에 접근할 수 있게 함.
• Sticky bit(스티키 비트)
  • directory에 적용될 때, 해당 directory 내의 파일 소유자만이 파일을 재명명, 이동 또는 삭제할 수 있도록 지정하는 것
  • /tmp directory는 누구나 파일을 생성하고 삭제 가능한데, linux를 공동으로 여러 사용과 사용할 때 quater가 정해져 있는데, tmp directory는 system reboot될 때 다 삭제됨. f1라는 파일을 생성했는데, 다른 사용자가 파일을 삭제할 수 없도록 해야 하는데, rwx로 되어 있으니 누구나 directory 내용을 변경 가능함. 하지만 그렇게 하면 안 되므로 sticky bit가 설정된 directory는 해당 파일의 owner만 rename, move, delete할 수 있음.
• Superuser(슈퍼유저): 모든 것을 다 할 수 있는 사용자
  • 일반적인 access control 제한에서 제외됨.
  • 시스템 전반에 걸친 접근 권한을 가짐.

Access Control Lists (ACLs) in UNIX

• Modern UNIX 시스템은 ACL도 support함.
  • FreeBSD, OpenBSD, Linux, Solaris 등에서
• FreeBSD
  • setfacl 명령은 UNIX 사용자 ID 및 그룹의 목록을 할당함.
  • 파일에 임의의 수의 사용자 및 그룹을 연관시킬 수 있음.
  • 읽기, 쓰기, 실행 보호 비트
  • 파일이 ACL을 가질 필요는 없음.
  • 파일에 확장 ACL이 있는지 여부를 나타내는 추가 보호 비트를 포함함.
• process가 파일 시스템 object에 접근을 요청할 때 두 단계가 수행됨.
  1. 가장 적절한 ACL을 선택 (소유자, 지정된 사용자, 소유 그룹/지정된 그룹, 기타)
  2. 일치하는 항목에 충분한 권한이 포함되어 있는지 확인
• 특정 파일의 삭제 권한은 상위 directory에 대한 write 권한임.

Role-Based Access Control (RBAC)

• 사용자는 role(역할)을 할당받고, role은 resources을 할당받는 구조
• user-role, role-resources 관계를 통해 access control을 관리
• 사용자는 session(세션) 내에서 특정 role을 활성화하여 해당 role에 부여된 권한을 행사

Role-Based Access Control Models

• RBAC는 여러 모델로 구성되며, 계층적 구조를 가질 수 있음.

1. Core RBAC(핵심 RBAC): user, role, permission, session의 기본 요소를 정의
2. Hierarchical RBAC(계층적 RBAC): role 간의 상속 관계를 지원하여 권한 관리의 효율성을 높임.
3. Static Separation of Duty RBAC(정적 직무 분리 RBAC): 상호 배타적인 role을 정의하여 이해 상충을 방지함.
4. Dynamic Separation of Duty RBAC(동적 직무 분리 RBAC): 한 session 내에서 활성화될 수 있는 role들을 제한함.

Constraints

• 조직의 행정 및 보안 policy의 특수성에 RBAC를 적용하는 수단을 제공
• Role 간의 정의된 관계 또는 role과 관련된 조건
• 유형
  • Mutually exclusive roles(상호 배타적 역할)
    • 사용자는 (세션 동안 또는 정적으로) 집합 내의 한 role에만 할당될 수 있음.
    • 모든 권한(접근 권한)은 집합 내의 한 role에만 부여될 수 있음.
  • Cardinality
    • role과 관련하여 maximum number를 설정
  • Prerequisite roles(선행 조건 역할)
    • 사용자가 특정 다른 role에 이미 할당된 경우에만 특정 role에 할당될 수 있음을 지시

NIST RBAC Model

• SSD: Static separation of duty
• DSD: Dynamic separation of duty

Basic Definitions

• Object
  • 파일, 프린터, 터미널, 데이터베이스 레코드 등 access control의 대상이 되는 모든 시스템 resource
• Operation(연산)
  • 프로그램의 실행 가능한 이미지로, 호출 시 사용자를 위해 일부 기능을 실행
• Permission(권한)
  • 하나 이상의 RBAC 보호 object에 대해 연산을 수행하는 것에 대한 허용, 승인

Core RBAC

• Administrative functions(관리 기능)
  • 사용자 집합에서 사용자 추가 및 삭제
  • role 집합에서 role 추가 및 삭제
  • user-to-role 할당 인스턴스 생성 및 삭제
  • permission-to-role 할당 인스턴스 생성 및 삭제
• Supporting system functions(지원 시스템 기능)
  • 기본 활성 role 집합으로 사용자 session 생성
  • session에 활성 role 추가
  • session에서 role 삭제
  • session subject가 요청된 연산을 object에 대해 수행할 권한이 있는지 확인
• Review functions(검토 기능)
  • 관리자가 role assignment나 permission assignment를 확인하고 관리할 수 있게 하는 기능
  • 모델의 모든 요소와 그 관계를 수정하지 않고 볼 수 있게 함.

Hierarchical RBAC

• General role hierarchies: 임의의 partial ordering을 허용
• Limited role hierarchies: tree 구조를 채택하여 cycle이 발생하지 않도록 함

Static Separation of Duty Relations (SSD)

• 한 사용자가 집합 내의 한 role에 할당되면, 해당 집합의 다른 어떤 role에도 할당될 수 없도록 하는 상호 배타적인 role 집합의 정의를 가능하게 함.
• role 집합에 카디널리티 제약을 둘 수 있음.
  • (role set, n) 쌍 형태로 정의되며, 어떤 사용자도 해당 role 집합에서 n개 이상의 role에 할당되지 않음.
• role 집합 생성 및 삭제, role 멤버 추가 및 삭제를 위한 관리 기능을 포함함.
• 기존 SSD 집합의 속성을 보기 위한 검토 기능을 포함함.

Dynamic Separation of Duty Relations (DSD)

• 사용자에게 가용한 권한을 제한함.
• 사용자 session 내에서 또는 session 간에 활성화될 수 있는 role에 제약을 둠.
• 제약은 (role set, n) 쌍으로 정의되며, 여기서 n은 자연수 $n \geq 2$이고, 어떤 사용자 session도 role 집합에서 n개 이상의 role을 활성화할 수 없는 속성을 가짐.
• 관리자가 사용자에 대해 서로 다른, 겹치지 않는 시간대에 특정 능력을 지정할 수 있게 함.
• DSD 관계를 정의하고 보기 위한 관리 및 검토 기능을 포함함.

Example of Access Control Administration

• HR 부서: 사용자 직원 각 ID에 대하여 role을 정의하고, role에 대해서 각 사용자를 특정 role에 assign
  • 따라서, 하나의 사용자가 여러 role에 assign될 수 있음.
• Application 관리자: 어떤 application이 어떤 access 권한을 갖는지 정의
• Authorization 관리자: 어떤 role이 어떤 application에 접근할 수 있는지 정의
• RBAC 환경에서는 관리 role이 user-to-role 할당 및 permission-to-role 할당을 관리함.
• 예를 들어, '사용자 관리자' role은 사용자에게 role을 할당하고, '권한 관리자' role은 role에 권한을 할당하는 작업을 수행함.

Attribute-based Access Control (ABAC)

• 속성을 함께 결합하는 policy에 기반
  • 사용자 속성, resource 속성, 환경 속성 등
  • 예: 나이, role, 직함 등 / 읽기, 삭제, view 등 / object type 등
• 다양한 속성을 평가할 수 있는 복잡한 Boolean rule set을 표현할 수 있음.
• 예:
  • policy: 관리자는 자신의 지역 내의 transaction을 볼 수 있음.
  • policy: user.role == manager인 사용자는 user.region == transaction.region인 경우 table == TRANSACTIONS 테이블에 대해 action == SELECT 작업을 수행할 수 있음.