Access Control

dmswl·5일 전

System Security

목록 보기
14/15

1. Access Control Examples

1.1 Access Control: Discretionary Access Control

Authorization (Permission mode) on Linux

Discretionary는 '자유 재량의'라는 뜻으로, DAC는 파일 소유자가 다른 사용자들에게 어떤 권한을 줄지 직접 결정하는 방식이다. 리눅스에서는 이러한 권한이 'rwx'로 표현되고 user, group, others에 대해 각각 별도로 설정된다.

  • Subject, Object, Access rights

2. Access Control

2.1 Access Control

  • Access Control (ITU-T Recommendation X.800 Definition)
    • Its function is to control which (active) subject have access to a which (passive) object with some specific access operation
    • "The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner

Access Control은 누가 어떤 자원에 어떤 방식으로 접근할 수 있는지 정하고, 허가되지 않은 사용을 막는 기능이다.

  • RFC 2828 defines computer security as:
    • Measures that implement and assure security services in a computer system, particularly those that assure access control service

2.2 Relationship Among Access Control and Other Security Functions

1. Authentication

  • 로그인을 통해 User A가 자신이 A임을 인증 \rightarrow 누구인지 확인

2. Access Control

  • 인증이 끝난 확인된 사용자에 대해 Authorization DB를 참고해서 어떤 시스템 자원(object(file), system resource)에 어떤 연산을 허용/거부 결정

3. Security Administrator

  • Authorization DB 안에 '누가 어떤 자원에 어떤 권한을 가지는지' 정책을 미리 설정하고 변경/관리

4. Auditing

  • 누가 언제 어떤 자원에 접근했는지 기록
  • 보안 정책 위반이나 침입 흔적을 추적/분석
  • An access control system assumes that a user is unthentic
  • thus, an authentication mechanism is needed as a front end to an access control system

2.3 Authentication vs. Authorization

  • Authorization deals with the question of what an authenticated user is allowed to do
    • We are really looking at your access privileges, roles, and permissions

Authentication(인증)은 사용자가 누구인지 확인하는 단계이고, Authorization(인가)는 이미 인증된 사용자가 무엇을 할 수 있는지 결정하는 단계다.


2.3 Authentication and Access Control

Identification & Authentication

  • Identification -> username (UID), GID
  • Authentication -> password, fingerprint, iris, face, voice, gesture

Access Contorl

  • The selective restriction of access to a place or other resource

Authorization

  • The determination if a subject is allowed access to resources, based on an access control policy
    • Granting/Denying permission(s) to access a resource
    • After a person or process has successfully been identified and authenticated then it must be determined what resources they are permitted to access and what actions they will be allowed to perform (run, view, print, create, delete or change)
    • Authorization ensures that specific entities may perform specific operations on a secure object

접근제어 정책에 따라서 사용자가 어떤 자원에 접근할 수 있는지, 어떤 동작을 할 수 있는지를 정한다.


2.4 Access Control Overview

Access

  • The flow of information between subject and object

Basic Elements of Access Control

  • Subject: An active entity that requests access to an object or the data in an object
    • person(user), group, program(process), computer
  • Object(Resource): A passive entity that contains information
    • file/directory/device, memory, IPC, IP address/Port number, ...
  • Access right(Operation): read(view), write, append, execute, create, delete, print, ...

Operation = Action = Access right = Permission

  • The act of accessing may mean consuming, entering, or using
    • read(view), write, append, execute(run), create, delete, change, copy, print
  • In Unix/Linux, access control is specified with three operations
    • Read, Write, Execute as applied to a file or directory for an owner

실제로 수행하려는 동작 하나가 곧 권한 하나이다.


2.5 Access Contorl Basic Elements

Subject

  • Owner(user), group, world
  • Program(process), App
  • System
  • Virtual machine

객체에 접근할 수 있는 능동적인 엔티티이다.

Object

  • records, blocks, pages, segments, files, directories, document, mailboxes, messages, programs
  • devices, processors, communication ports, clocks, ...

접근이 통제되는 자원으로, subject가 접근하고 싶어하는 대상이다.

Access right

subject가 object에 대해 어떤 방식으로 접근할 수 있는지를 나타내는 권한이다.


2.6 Motivation of Access Control

Why do we need access control?

1. Confidentiality

  • A user should be able to deny other users read access to his files
    • No READ

사용자 입장에서 내 파일은 원하지 않는 다른 사용자에게 읽히면 안 된다는 요구를 만족해야 한다. 허가되지 않은 사용자는 READ 자체가 안 되도록 막아 기밀성을 보장한다.

2. Integrity

  • A user should be able to protect his files from modification or deletion by ohter users
    • No WRITE

내 파일 내용이 다른 사람에 의해 멋대로 수정/삭제되면 안 된다는 요구를 만족해야 한다. 허가되지 않은 사용자는 WRITE/DELETE가 안 되도록 막아 데이터의 정확성과 일관성을 지킨다.

  • Help users to avoid unintentional read/change of important system files
  • Help users to avoid unintentional change of important personal files
    • E.g., photos

3. Access Control Requirements

3.1 Access Control Requirements

1. Reliable input

  • An authentication mechanism is needed as a front end to an access control system

2. Support for fine and coarse specifications

  • The level of files, records in files, and individual fileds within records

3. Least privilege

  • 꼭 필요한 최소한의 권한만 부여 \rightarrow Zero-Trust: 불필요한 권한을 없애서 침해 시 피해 범위 최소화

4. Separation of duty

  • The practice of dividing the steps in a system function among different individuals, so as to keep a single individual from subverting the process

중요한 기능을 여러 단계로 나누고 서로 다른 사람에게 역할을 분산해 한 사람이 전체 절차를 마음대로 바꾸거나 악용하지 못하게 한다.

5. Open and closed policies

  • In a closed policy, only accesses that are specifically authorized are allowed
  • Closed policy = white-list
    • White-List
      • 기본은 전부 거부하고, 명시적으로 허가된 접근만 허용
      • 구현이 어렵지만 안전함
    • Black-List
      • 기본은 허용하고, 금지 목록에 있는 것만 차단

6. Policy combinations and conflict resolution

  • An access control mechanism may apply multiple policies to a given class of resource
  • E.g., 0 - 1000: deny 이후에 80: open이 들어오면 conflict 발생
    • Time \rightarrow 나중에 적용되는 정책에 우선순위 부여

7. Administrative policies

  • Are needed to specify who can add, delete or modify authorization rules

8. Dual control

  • When a task requires two or more individuals working in tandem

민감한 작업은 두 명 이상이 함께 승인/수행해야만 완료되도록 한다.


3.2 Requirement: Least Privilege

  • A subject should be given only those privilege that it needs in order to complete its task
    • Each program and user should operate with the bare minimum privileges necessary to function properly
    • A task should be accomplished with the absolute lowest level of privilege required
    • A policy that limits users'&processes' access to only those resources necessary to only those resources necessary to perform their functions

가능한 가장 낮은 수준의 권한으로도 수행되도록 설계해야 한다.

동적 sandbox를 이용하여 least privilege를 자동으로 부여한다.

  • This principle requires that processes should be confined to as small a protection domain as possible
    • If this principle is enforced, the damage caused by the compromise of a particular application or user account is minimized

User의 영역은 최대한 작게 구성

  • It is the analogue of the "need-to-know" rule
    • If the subject does not need access to an object to perform its task, it should not habe the right to access that object
    • If a subject needs to append to an object, but not to alter the info already contained in the object, it should be given append right and not write rights
      • Fine granularity of privileges and permissions is better

업무에 필요하지 않은 정보는 아예 보지 못하게 한다.


3.3 Requirement: Separation of Day

= Segregation of Duty (SoD)

  • No one person should be able to affect a breach of security
  • SoD address the splitting of various functions with in a process to different users so that it will not create an opportunity for a single user to perform conflicting
    • The participation of two or more persons in a transaction creates a system
  • Main objective is to prevents fraud and errors
    • Speration of duties forces rogue employees into attempting collusion and thus risking discovery by honest coworkers
  • Sometimes difficult to achieve
    • Example 1: designer/implementer should not be same as tester
    • Example 2: the person who writes a check should not be the one to sign it
    • Example 3: The credit card printing personal should not print the credit card PINs
    • Example 4: The person who submits a paper should not be the one to review it

Purpose is to ensure that a single point of compromise dose NOT have significant impacts on the business

  • The risk being that if a single post is responsible for highly privileged actions and is not monitored or controlled, then compromise of that role could result in disastrous impacts to the organization
  • For example, malicious system or network admins managing the network could greatly disrupt or leak highly sensitive data if not controlled and monitored through controls

Segregation of Duties for Cash Receipts

하나의 업무 프로세스를 여러 단계로 쪼개서 서로 다른 사용자에게 맡기고 서로가 서로를 견제하도록 만든다. 목적은 어느 한 계정, 역할이 뚫려도(compromise) 사업 전체에 치명적인 영향(disastroud impacts)을 주지 않게 만드는 것이다.

Equivalent to the separation of privilege

  • The prevention of fraud and errors is primary goal
    • It is achieved by disseminating the tasks and associated privileges for a specific business process among multiple users
  • E.g.,
    • The crypto security officer is not allowed access to the encrypted data

3.4 Requirement: Dual Control

  • A security procedure requiring two people(or possibly process or devices) to cooperate in gaining authorized access to a system resource(data, files, devices)
  • Dual control enforces the concept of keeping a duo responsible for an activity
    • It requires more than one employee available to perform a task
    • It utilizes two or more separate entities (usually persons), operating together, to protect sensitive functions of information

3.5 Requirements

  • Separation of Duties
    • The crypto security officer is not allowed access to the encrypted data
    • The data user is not allowed to create/manage keys
  • Dual Control
    • Two or more crypto security officers are responsible for generating the encryption keys
  • Split Knowledge
    • No one person has the whole encryption key when it is in the clear

4. Access Control Models

4.1 Three main types

세 가지 정책은 서로 배타적이지 않고, 시스템에 혼합되어 사용될 수 있다.

DAC (Discretionary Access Control)

  • Traditional method of implementing access control

파일 소유자가 ACL에서 '누가 read/write/execute 가능하지'를 직접 설정한다.

MAC

  • Access based on comparing security labels (which indicate how sensitive or critical system resources are) with security clearances (system entities are eligible to access certatin resources)

시스템 내부에서 일일이 access control을 지정하기 때문에 복잡하지만 강력하다.

RBAC

  • Control access based on the roles that users have within the system and on rules stating what accesses are allowed to users in given roles

사용자에게 직접 권한을 붙이는 대신, role에 권한을 부여하고 사용자는 하나 이상의 역할에 배정되는 모델이다. 예를 들어 감시자 역할에는 로그 조회 권한만, 운영자는 서비스 재시작 권한만 부여하는 것이다.

0개의 댓글