Access Control: 정책과 구현 방식

Access Control

시스템은 지금까지 배운 방법들을 기반으로 사용자를 인증(Authenticated)한다.

이제 모든 사용자의 리소스에 대한 접근은 시스템의 Access Control Mechanism(접근 제어 메커니즘)에 의해 중재된다. (Principle of Complete Mediation)

 

Complete Mediation: Memory Access Control

대표적인 Complete Mediation 접근 제어 전략 중 하나는 커널의 메모리 엑세스 제어이다.

커널은 커널 스스로와 유저 프로세스를 위한 페이지 테이블들을 구성하고, 메모리 접근 권한을 제어한다. 예) 수정되서는 안되는 코드 혹은 read-only 데이터

 

Complete Mediation: System Calls

• 커널 프로그램 권한
  • 하드웨어에 직접 접근
  • 시스템 상태를 변경 가능
• 유저 프로그램 권한
  • 하드웨어와 상호작용하기 위해서는 시스템 콜을 요청해야 한다.
  • 시스템 상태를 변경할 수 없다.

 

Bell-Lapadula Properties (BLP)

• 정부 및 군용 응용 시스템의 접근 제어를 위해 Bell과 Lapadula에 의해 제안된 접근 통제 모델
• 대표적인 Multi Level Security 모델
• Subjects와 objects의 구분에 따라 접근을 제어한다.
• 비밀 정보가 허가되지 않는 방식으로 접근되는 것을 방지
• Confidentiality를 강조
• O가 object, S 가 subject일 때, security level을 L(O), L(S)라 하자.
  • L(O)<=L(S) 이면 S에게 읽기만 허용 (상향 읽기 금지-No read up)
  • L(S)<=(O) 이면 S에게 쓰기 허용 (하향 쓰기 금지-No write down)

 

Access Control Policies

아래는 어떻게 접근들을 제어할 것인지 결정하는 High-level guideline이다.

Discretionary Access Control (DAC)

• 사용자의 아이덴티티만으로 오브젝트에 대한 접근을 제한하는 형태
• 접근 제어를 오브젝트 주인(object owner)에 의존한다.
• 대부분의 운영체제는 DAC를 적용한다.
• 유연하고(flexible) 사용하기 쉽다(easy-to-use).

Mandatory Access Control (MAC)

• 오브젝트 주인에게 접근 제어를 허용하지 않는다.
• 오로지 중앙 기관(Central Authority)이 접근 제어 권리를 갖는다.
• 예) Military

Role-Based Access Control (RAC)

• 유저에게 role(역할)을 부여하고, role에 따라 접근 권한을 할당한다.
• Hierarchical roles
  • Hierarchical roles를 기반으로 권한을 상속한다.
• Least privilege
  • 특정 task를 수행하기 위해 필요한 최소한의 권리를 유저에게 허용한다.
• Separation of duties
  • 단일 사용자에게 많은 권한을 주지 않는다.
• Object Classes
  • 오브젝트는 분류에 의해 그룹화된다.

 

Access Control Implementation Approaches

지금까지 배운 접근 제어 정책들을 기반으로 어떻게 access control scheme을 구현할까?

Access Control Lists (ACLs)

• Subjects (Users): Rows
• Objects (Resources): Collumns

접근 제어 행렬(Access Control Matrix)을 column으로 저장하는 방식으로, 해당 데이터에 누가 접근할 수 있는지 설명한다. (File->User Association)

Capabilities

유저들이 각 리소스에 대해 위조 불가능한 토큰(non-forgeable token)을 보유하는 것을 말한다.

중앙 액세스 제어자(Central Access Controller)는 토큰이 유효한지, 그리고 토큰에 적용된 허가을 확인한다. (if the token is valid and permissions on the token)

접근 제어 행렬(Access Control Matrix)을 row로 저장하는 방식으로, 해당 유저가 무슨 데이터에 접근할 수 있는지 설명한다. (User->File Association)

NIX Access Control Model

• Permissions
  • r은 읽기 허용
  • w은 쓰기 허용
  • x는 실행 허용
  • -는 허용하지 않음
• File Type
  • -는 파일
  • d는 디렉토리
  • b/c는 장치 파일(Device file)

 

Confused Deputy

혼동된 대리인 문제라고도 불린다. 소프트웨어와 시스템의 권한 분리 과정에서 발생한다. 클라이언트는 권한이 없지만 대리인은 권한이 있는 일을 부탁했을 때 대리인이 혼동하여 일을 수행해 줄 때 발생하는 보안 문제이다. 사용자가 자신보다 높은 권한을 가지는 프로세스(대리인)를 통해 작업을 수행할 때 발생한다.

• ACLs는 이 문제를 예방하기 어렵다.
• Capabilities로 이 문제를 해결할 수 있다.
  • 예를 들어 권한이 설정된 파일에 접근해서 수정하려는 명령을 주기 위해서 capability를 증명할 수 있는 토큰을 보내도록 강제한다면 이런 문제를 예방할 수 있다.

 

ACLs vs Capabilities

ACLS

• 사용자가 그들 소유의 파일을 관리하기에 좋다.
• 데이터로부터의 보호(Data-oriented Protection)이다.
• 리소스에 대한 권한을 변경하기 쉽다.

Capabilities

• Easy to delecate - 혼동된 대리인 문제를 예방할 수 있다.
• 유저를 추가 / 삭제하기 쉽다.
• 구현하기 더 어렵다.

 

SET-UID

사용자가 owner의 권한으로 프로그램을 실행할 수 있도록 허용한다. 즉, 사용자에게 일시적으로 상향된 권한으로 프로그램을 실행할 수 있도록 허용한다.

Concept

• 모든 프로세스는 두 개의 User ID가 있다.
  • Real UID(RUID): 프로세스의 실제 주인을 판별한다.
  • Effective UID(EUID):프로세스의 권한을 판별한다.
    • Access Control은 EUID에 기반한다.
  • 일반 프로그램이 실행될 때, RUID=EUID이다. 둘 다 프로그램을 실행하는 사용자의 ID이다.
  • Set-UID가 수행된 경우 RUID!=EUID이다. RUID는 여전히 사용자의 ID이지만, EUID는 program owner의 ID이다.

 

References

https://devage.tistory.com/66

https://cyber0946.tistory.com/53