Living Rough
Access Control이란? 본문
Access Control은 직역하면 접근 제어를 의미한다.
이 단어는 어떤 의미를 가지고 있을까?
Access Control(접근 제어)
Access Control은 누가 어떤 자원에 접근할 수 있는지를 제어하는 것을 말한다.
- 주체 : 객체에 접근할 수 있는 존재
- 객체 : 접근이 제어되는 자원(파일, 디렉토리, 데이터베이스, 프로그램 등)
- 접근 권한 : 주체가 객체에 접근하는 방법을 말한다.(Read, Write, Execute 권한 등)
RFC 4949에는 다음과 같은 내용이 있다 : 보안 정책에 따라 시스템 자원 사용을 규제하고, 인가된 존재에게 사용을 허가한다.
즉 허가되지 않은 사용자의 자원 접근을 막고, 정당한 사용자라도 허가되지 않은 방법으로 접근하는 것을 막는 것이다.
이때 조금 더 세부적으로 나누어 보면 :
- Authentication Function : 사용자가 시스템에 접근할 수 있는지 결정한다. 예) 로그인
- Access Control Function : 사용자의 요청이 허용되는지 결정. 예) 앱 접속 시 권한을 요청하는 창 등
- Security Admin : 사용자의 요청이 자원에 어떻게 접근하는지 명시한 권한 데이터베이스를 관리
- Audit : 사용자가 시스템 자원에 접근하는 것을 기록, 감시한다. 예) 로그 기록 등
즉 위 과정을 정리해보면, 접근 제어는 식별, 인증, 인가와 책임추적성 단계로 구성된다.
식별 : 본인이 누구라는 것을 시스템에 밝히는 것이다.
인증 : 본인임을 주장하는 사용자가 그 본인이 맞다고 시스템이 인정하는 것이다.
인가 : 인증된 주체에게 접근을 허용하고, 특정 업무를 수행할 권리를 부여하는 과정이다.
책임추적성 : 시스템에 접근한 주체가 시스템에 어떤 행위를 하고 있는지를 기록함으로써, 문제발생 시 원인 및 책임 소재를 파악하기 위한 과정
즉 User는 Authentication Function과 Access Control Function을 통해 시스템 자원에 접근할 수 있고, 이에 따라 Access Control Function 은 사용자의 요청에 따른 자원 접근 방법을 명시하는 데이터베이스인 Authorization Database(Policy가 존재함)에 연결되어 있다. 이 데이터베이스를 Security Adminstrator가 관리하고, 이 모든 접근 기록을 Audit이 관리한다.
Access Control Policy(접근 제어 정책)
Access Control Policy는 접근 제어 정책을 의미하며, 어떤 상황에서 누구에게 어떤 종류의 접근이 허용되는지를 결정한다.
권한 DB 속에 저장되며, 보안 admin이 관리한다.
이 접근 제어 정책은 크게 4가지로 나뉜다.
- Discretionary Access Control (DAC)
- Mandatory Access Control (MAC)
- Role-based Access Control (RBAC)
- Attribute-based Access Control (ABAC)
하나씩 살펴보면서 각 접근 제어 정책의 특징에 대해 알아보도록 하자.
Discretionary Access Control(DAC)
임의 접근 제어라는 의미로, 요청자의 신분(신원)에 따라 무엇을 할 수 있는지를 정의한다.
이는 Window, UNIX 등 여러 컴퓨터 시스템에 널리 사용되며, DAC를 사용하는 경우 주로 Access Matrix를 사용하여 주체와 객체, 권한을 행렬로 표현하게 된다.
위에 보이는 것이 Access Matrix이다.
보다시피 각 사람이 각 파일에 대해 어떤 접근 권한을 가지고 있는지 행렬로 표시하는 것을 알 수 있다.
Entry는 허용되는 접근을 의미하며, Access Control을 추가하려 할 때도 이 matrix를 이용한다.
보다시피 구현이 쉽고 권한 변경이 유연하지만, 하나의 주체마다 객체에 대한 접근 권한을 부여해야 하며, 사용자가 추가할 때마다 메모리가 크게 낭비된다는 단점이 있다.
DAC의 또다른 구현 방법에는 Access Control Lists와 Capability Tickets가 있다.
Access Control List는 Access Matrix를 열으로 분리한 것이다. 위와 같이 각 파일에 대해, 사용자에 대한 권한을 연결 리스트의 형태로 나타낸 것이다. 이를 이용하면 Matrix의 형태보다 메모리 낭비가 덜하여 보완할 수 있다.
Capability Tickets는 Access Matrix를 행으로 분리한 것이다. 특정 주체에 대해 승인된 객체와 권한을 명시하는 것을 말한다. 특정 사용자에 허가된 객체와 권한들을 정리하기가 쉽다는 장점이 있다. 그러나 다른 주체에게 티켓을 빌려주거나 양도하면 보안 문제가 발생할 수 있다는 단점이 있다. 주로 OS가 관리하며, 티켓은 무결성, 기밀성, 인증성이 보장된다. 분산 / 클라우드 환경에 적합하다.
추가적으로, 주로 DB를 이용할 경우 많이 사용하는 Authorization Table이 있다.
DAC의 방식을 보면 알겠지만, 위 방법 중 어느 것을 사용하더라도 메모리 낭비가 꽤 심하며, 이에 따른 메모리나 배터리의 소모가 심할 수 있다. 또한 파일이 지나치게 많아질수록 권한 관리가 힘들다는 특징이 있다.
또한 주체나 객체별로 제어하므로 전체 자원의 일관성 있는 제어가 어렵다.
MAC(Mandatory Access Control)
보안 레이블과 보안 허가증을 비교하는 것에 기반을 두는 접근 제어 방식으로, MAC을 기반으로 하는 운영시스템은 보안 목적을 위해 사용자가 가지는 권한, 허가 그리고 기능을 크게 감소시킨다. MAC 모델은 자동적으로 시행되는 엄격한 규칙에 기반해 접근통제를 수행하며 사용자의 의도와는 관계없이 의무적으로 접근을 제어한다.(Rule-based 접근통제)
전통적 MAC 시스템은 다중수준 보안(MLS) 정책에 기반한다. MLS는 정보가 상위 보안 수준에서 하위 보안 수준으로 흐르는 것을 방지하는 보안 정책이다.
주체가 객체로 접근하는데 적용되는 규칙은 보안전문가에 의해 생성되며, 운영자에 의해 설정되고, 운영시스템에 의해 집행되며, 다른 보안기술들에 의해 지원된다.
RBAC(Role-based Access Control)
DAC와 달리 사용자가 아닌 역할 단위로 권한을 관리하는 방법을 말한다.
특히 회사, 조직, 기관 등에서 직무(직책)에 따른 권한을 관리할 때 많이 사용한다.
메모리 낭비를 줄일 수 있다는 특징이 있으며, 각 사용자에게 역할만 부여한다.
예를 들어 보면 : 팀장이라는 "역할"이 존재하고, 이 역할은 작업 문서를 모두 열람하고, 수정이 가능하다고 하자.
그리고 각 팀원은 작업 문서를 모두 열람하지는 못하지만, 수정만 가능하다고 하자.
우리는 이제 각 사람에게 팀장 또는 팀원이라는 역할만 부여하면 된다.
또한 역할을 단순히 부여할 뿐만 아니라 권한을 바꾸기 위해서는 "역할"만 바꿔주면 되므로 관리가 상당히 수월하다.
이는 프리미엄 회원과 일반 회원 등을 구분하고 이에 따른 접근 가능 기능들을 관리할 때도 용이할 것이다.
이 RBAC 방식은 Security Requirements for Cryptographic Modules에서 NIST 2009에 표준 제정하였다.
위 이미지처럼 사용자, 역할, 자원은 서로 일대일 대응이 아니라 다대다 대응이고, 관계는 동적이다.
정리해보면 :
- 장점 : 일관성 있게 역할에 따라 권한 부여가 가능하고, 직무 분석이 용이하다.
- 단점 : 각 주체, 객체별로 유연하게 권한을 부여하기가 쉽지 않다.
ABAC(Attribute-based Access Control)
접근이나 작업에 대한 권한을 사용자, 리소스 속성 또는 환경에 따라 결정한다.
- 사용자 : 사람의 직급과 연공서열에 따라서 등등..
- 리소스 속성 : 파일유형, 만든사람, 문서의 중요도 등등...
- 환경 : 파일에 액세스하고 있는 위치, 시간대 또는 날짜
- DAC, RBAC의 기본 기능 사용 가능
- 속성을 이용해 if문의 조건과 비슷하게 속성에 따른 권한 부여가 가능하다.
- 권한을 직접 바꿔줘야 하는 DAC, RBAC과 달리 규칙 하나만 추가하면 권한을 변경하고 수정이 가능하다.
정리
ABAC은 RBAC과 비슷하지만 특성에 다른 조건을 조금 더 추가할 수 있다고 알면 될 것 같다.
이상으로 접근 제어에 대해 알아보았다.
글을 마친다.
'System & Security > Security' 카테고리의 다른 글
| IPsec은 무엇일까? (0) | 2023.12.11 |
|---|---|
| TLS / SSL이란? (0) | 2023.12.10 |
| Kerberos(커보로스)란? (0) | 2023.12.10 |
| Diffie - Hellman(디피-헬만 키 교환) (1) | 2023.12.10 |
| KDC와 CA (1) | 2023.12.10 |
