Share
Sign In
🎫

접근 제어 모델 종류

💡
접근 제어의 종류와 구현 방법에 대한 소개를 바탕으로 재작성 되었습니다.
인증 vs 인가
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다.
인증(Authentication)은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가(Authorization)는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가(Authorization)에 해당한다.
당연하게도 ‘인가’를 수행하기 위해서는 ‘인증’이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.
용어 정의
접근 제어 모델을 설명하기 전에 먼저 접근 제어 모델에서 사용하는 용어에 대해 알 필요가 있다.
접근 제어 모델에서 인가를 받으려는 사용자를 ‘주체(Subject)’ 라고 한다. ‘주체’는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. ‘객체(Object)’는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. 네이버 카페의 게시판이 ‘객체’의 예이다. ‘권한(Permission)’은 ‘객체’에 허용된 ‘주체’가 수행할 수 있는 행위의 목록을 말한다. 보통 ‘권한’에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다.
결국 접근 제어(Access Control)라는 것은 ‘객체(Object)’에 접근하고자 하는 ‘주체(Subject)’가 해당 ‘객체(Object)’에 접근할 수 있는 ‘권한(Permission)’을 가지고 있는지 판단하는 것이다.
접근 제어 모델의 종류
강제적 접근 제어 모델 (Mandatory Access Control, MAC)
강제 접근 제어(MAC)는 미리 정해진 정책과 보안 등급에 의거하여 주체(Subject)에게 허용된 접근 권한과 객체(Object)에 부여된 허용 등급을 비교하여 접근을 제어하는 방법이다. 대표적인 예로 네이버나 다음 카페에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다.
강제적 접근 제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다.
이러한 강제적 접근 제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근 제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.
임의적 접근 제어 모델 (Discretionary Access Control, DAC)
임의적 접근 제어(DAC)는 객체에 대한 접근을 사용자나 그룹의 신분을 기준으로 제한하는 방법이다. 객체의 소유자는 다른 주체에 대해 객체에 대한 접근 권한을 설정할 수 있다. 대표적인 예는 전통적인 유닉스나 윈도우 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근 제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근 제어를 설정할 수 있다. 여기서 ‘임의적(Discretionary)’이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다.
대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근 제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근 제어(MAC)에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근 제어가 어렵다. 또한 접근 제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다.
DAC 을 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.
접근 제어 행렬(Access Control Matrix)
접근 제어 행렬은 위 그림과 같이 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 위 그림에서 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.
접근 제어 목록 (Access Control List: ACLs)
가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.
가용성 티켓 (Capability Tickets)
접근 제어 목록(ACLs) 과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근 제어 목록(ACLs) 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.
권한 테이블 (Permission Table)
관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.
역할 기반 접근 제어 모델 (Role Based Access Control, RBAC)
역할 기반 접근 제어(RBAC)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근 제어를 하는 방식이다. 임의적 접근 제어(DAC)과 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다.
권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근 제어 방법으로 강제적 접근 제어(MAC)과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근 제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다.
사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.
구현 수준에 따라 RBAC0부터 RBAC3까지 나뉠 수 있다.
속성 기반 접근 제어 모델 (Attribute Based Access Control, ABAC)
속성 기반 접근 제어(ABAC)는 객체와 주체의 속성에 대한 조건을 기술하여 접근 제어를 하는 방식이다. 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근 제어를 수행한다. 예를 들어 파일 1에 접근하기 위해서는 사용자의 type 속성에 admin이라는 태그가 달려 있어야 한다고 정의할 수 있다.
시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋은 것이 장점이지만, 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다. 속성을 일일이 수동으로 정의하기 힘들기 때문에 접근 제어를 정의하기 위한 언어인 XACML (eXtensible Access Control Markup Language)을 별도로 제공한다.
💡
접근 제어의 종류와 구현 방법에 대한 소개를 바탕으로 재작성 되었습니다.
인증 vs 인가
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다.
인증(Authentication)은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가(Authorization)는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가(Authorization)에 해당한다.
당연하게도 ‘인가’를 수행하기 위해서는 ‘인증’이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.
용어 정의
접근 제어 모델을 설명하기 전에 먼저 접근 제어 모델에서 사용하는 용어에 대해 알 필요가 있다.
접근 제어 모델에서 인가를 받으려는 사용자를 ‘주체(Subject)’ 라고 한다. ‘주체’는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. ‘객체(Object)’는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. 네이버 카페의 게시판이 ‘객체’의 예이다. ‘권한(Permission)’은 ‘객체’에 허용된 ‘주체’가 수행할 수 있는 행위의 목록을 말한다. 보통 ‘권한’에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다.
결국 접근 제어(Access Control)라는 것은 ‘객체(Object)’에 접근하고자 하는 ‘주체(Subject)’가 해당 ‘객체(Object)’에 접근할 수 있는 ‘권한(Permission)’을 가지고 있는지 판단하는 것이다.
접근 제어 모델의 종류
강제적 접근 제어 모델 (Mandatory Access Control, MAC)
강제 접근 제어(MAC)는 미리 정해진 정책과 보안 등급에 의거하여 주체(Subject)에게 허용된 접근 권한과 객체(Object)에 부여된 허용 등급을 비교하여 접근을 제어하는 방법이다. 대표적인 예로 네이버나 다음 카페에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다.
강제적 접근 제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다.
이러한 강제적 접근 제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근 제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.
임의적 접근 제어 모델 (Discretionary Access Control, DAC)
임의적 접근 제어(DAC)는 객체에 대한 접근을 사용자나 그룹의 신분을 기준으로 제한하는 방법이다. 객체의 소유자는 다른 주체에 대해 객체에 대한 접근 권한을 설정할 수 있다. 대표적인 예는 전통적인 유닉스나 윈도우 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근 제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근 제어를 설정할 수 있다. 여기서 ‘임의적(Discretionary)’이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다.
대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근 제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근 제어(MAC)에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근 제어가 어렵다. 또한 접근 제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다.
DAC 을 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.
접근 제어 행렬(Access Control Matrix)
접근 제어 행렬은 위 그림과 같이 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 위 그림에서 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.
접근 제어 목록 (Access Control List: ACLs)
가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.
가용성 티켓 (Capability Tickets)
접근 제어 목록(ACLs) 과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근 제어 목록(ACLs) 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.
권한 테이블 (Permission Table)
관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.
역할 기반 접근 제어 모델 (Role Based Access Control, RBAC)
역할 기반 접근 제어(RBAC)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근 제어를 하는 방식이다. 임의적 접근 제어(DAC)과 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다.
권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근 제어 방법으로 강제적 접근 제어(MAC)과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근 제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다.
사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.
구현 수준에 따라 RBAC0부터 RBAC3까지 나뉠 수 있다.
속성 기반 접근 제어 모델 (Attribute Based Access Control, ABAC)
속성 기반 접근 제어(ABAC)는 객체와 주체의 속성에 대한 조건을 기술하여 접근 제어를 하는 방식이다. 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근 제어를 수행한다. 예를 들어 파일 1에 접근하기 위해서는 사용자의 type 속성에 admin이라는 태그가 달려 있어야 한다고 정의할 수 있다.
시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋은 것이 장점이지만, 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다. 속성을 일일이 수동으로 정의하기 힘들기 때문에 접근 제어를 정의하기 위한 언어인 XACML (eXtensible Access Control Markup Language)을 별도로 제공한다.
💡
접근 제어의 종류와 구현 방법에 대한 소개를 바탕으로 재작성 되었습니다.
인증 vs 인가
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다.
인증(Authentication)은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가(Authorization)는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가(Authorization)에 해당한다.
당연하게도 ‘인가’를 수행하기 위해서는 ‘인증’이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.
용어 정의
접근 제어 모델을 설명하기 전에 먼저 접근 제어 모델에서 사용하는 용어에 대해 알 필요가 있다.
접근 제어 모델에서 인가를 받으려는 사용자를 ‘주체(Subject)’ 라고 한다. ‘주체’는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. ‘객체(Object)’는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. 네이버 카페의 게시판이 ‘객체’의 예이다. ‘권한(Permission)’은 ‘객체’에 허용된 ‘주체’가 수행할 수 있는 행위의 목록을 말한다. 보통 ‘권한’에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다.
결국 접근 제어(Access Control)라는 것은 ‘객체(Object)’에 접근하고자 하는 ‘주체(Subject)’가 해당 ‘객체(Object)’에 접근할 수 있는 ‘권한(Permission)’을 가지고 있는지 판단하는 것이다.
접근 제어 모델의 종류
강제적 접근 제어 모델 (Mandatory Access Control, MAC)
강제 접근 제어(MAC)는 미리 정해진 정책과 보안 등급에 의거하여 주체(Subject)에게 허용된 접근 권한과 객체(Object)에 부여된 허용 등급을 비교하여 접근을 제어하는 방법이다. 대표적인 예로 네이버나 다음 카페에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다.
강제적 접근 제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다.
이러한 강제적 접근 제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근 제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.
임의적 접근 제어 모델 (Discretionary Access Control, DAC)
임의적 접근 제어(DAC)는 객체에 대한 접근을 사용자나 그룹의 신분을 기준으로 제한하는 방법이다. 객체의 소유자는 다른 주체에 대해 객체에 대한 접근 권한을 설정할 수 있다. 대표적인 예는 전통적인 유닉스나 윈도우 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근 제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근 제어를 설정할 수 있다. 여기서 ‘임의적(Discretionary)’이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다.
대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근 제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근 제어(MAC)에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근 제어가 어렵다. 또한 접근 제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다.
DAC 을 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.
접근 제어 행렬(Access Control Matrix)
접근 제어 행렬은 위 그림과 같이 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 위 그림에서 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.
접근 제어 목록 (Access Control List: ACLs)
가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.
가용성 티켓 (Capability Tickets)
접근 제어 목록(ACLs) 과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근 제어 목록(ACLs) 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.
권한 테이블 (Permission Table)
관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.
역할 기반 접근 제어 모델 (Role Based Access Control, RBAC)
역할 기반 접근 제어(RBAC)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근 제어를 하는 방식이다. 임의적 접근 제어(DAC)과 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다.
권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근 제어 방법으로 강제적 접근 제어(MAC)과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근 제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다.
사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.
구현 수준에 따라 RBAC0부터 RBAC3까지 나뉠 수 있다.
속성 기반 접근 제어 모델 (Attribute Based Access Control, ABAC)
속성 기반 접근 제어(ABAC)는 객체와 주체의 속성에 대한 조건을 기술하여 접근 제어를 하는 방식이다. 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근 제어를 수행한다. 예를 들어 파일 1에 접근하기 위해서는 사용자의 type 속성에 admin이라는 태그가 달려 있어야 한다고 정의할 수 있다.
시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋은 것이 장점이지만, 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다. 속성을 일일이 수동으로 정의하기 힘들기 때문에 접근 제어를 정의하기 위한 언어인 XACML (eXtensible Access Control Markup Language)을 별도로 제공한다.
💡
접근 제어의 종류와 구현 방법에 대한 소개를 바탕으로 재작성 되었습니다.
인증 vs 인가
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다.
인증(Authentication)은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가(Authorization)는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가(Authorization)에 해당한다.
당연하게도 ‘인가’를 수행하기 위해서는 ‘인증’이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.
용어 정의
접근 제어 모델을 설명하기 전에 먼저 접근 제어 모델에서 사용하는 용어에 대해 알 필요가 있다.
접근 제어 모델에서 인가를 받으려는 사용자를 ‘주체(Subject)’ 라고 한다. ‘주체’는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. ‘객체(Object)’는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. 네이버 카페의 게시판이 ‘객체’의 예이다. ‘권한(Permission)’은 ‘객체’에 허용된 ‘주체’가 수행할 수 있는 행위의 목록을 말한다. 보통 ‘권한’에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다.
결국 접근 제어(Access Control)라는 것은 ‘객체(Object)’에 접근하고자 하는 ‘주체(Subject)’가 해당 ‘객체(Object)’에 접근할 수 있는 ‘권한(Permission)’을 가지고 있는지 판단하는 것이다.
접근 제어 모델의 종류
강제적 접근 제어 모델 (Mandatory Access Control, MAC)
강제 접근 제어(MAC)는 미리 정해진 정책과 보안 등급에 의거하여 주체(Subject)에게 허용된 접근 권한과 객체(Object)에 부여된 허용 등급을 비교하여 접근을 제어하는 방법이다. 대표적인 예로 네이버나 다음 카페에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다.
강제적 접근 제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다.
이러한 강제적 접근 제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근 제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.
임의적 접근 제어 모델 (Discretionary Access Control, DAC)
임의적 접근 제어(DAC)는 객체에 대한 접근을 사용자나 그룹의 신분을 기준으로 제한하는 방법이다. 객체의 소유자는 다른 주체에 대해 객체에 대한 접근 권한을 설정할 수 있다. 대표적인 예는 전통적인 유닉스나 윈도우 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근 제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근 제어를 설정할 수 있다. 여기서 ‘임의적(Discretionary)’이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다.
대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근 제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근 제어(MAC)에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근 제어가 어렵다. 또한 접근 제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다.
DAC 을 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.
접근 제어 행렬(Access Control Matrix)
접근 제어 행렬은 위 그림과 같이 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 위 그림에서 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.
접근 제어 목록 (Access Control List: ACLs)
가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.
가용성 티켓 (Capability Tickets)
접근 제어 목록(ACLs) 과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근 제어 목록(ACLs) 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.
권한 테이블 (Permission Table)
관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.
역할 기반 접근 제어 모델 (Role Based Access Control, RBAC)
역할 기반 접근 제어(RBAC)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근 제어를 하는 방식이다. 임의적 접근 제어(DAC)과 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다.
권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근 제어 방법으로 강제적 접근 제어(MAC)과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근 제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다.
사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.
구현 수준에 따라 RBAC0부터 RBAC3까지 나뉠 수 있다.
속성 기반 접근 제어 모델 (Attribute Based Access Control, ABAC)
속성 기반 접근 제어(ABAC)는 객체와 주체의 속성에 대한 조건을 기술하여 접근 제어를 하는 방식이다. 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근 제어를 수행한다. 예를 들어 파일 1에 접근하기 위해서는 사용자의 type 속성에 admin이라는 태그가 달려 있어야 한다고 정의할 수 있다.
시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋은 것이 장점이지만, 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다. 속성을 일일이 수동으로 정의하기 힘들기 때문에 접근 제어를 정의하기 위한 언어인 XACML (eXtensible Access Control Markup Language)을 별도로 제공한다.
💡
접근 제어의 종류와 구현 방법에 대한 소개를 바탕으로 재작성 되었습니다.
인증 vs 인가
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다.
인증(Authentication)은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가(Authorization)는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가(Authorization)에 해당한다.
당연하게도 ‘인가’를 수행하기 위해서는 ‘인증’이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.
용어 정의
접근 제어 모델을 설명하기 전에 먼저 접근 제어 모델에서 사용하는 용어에 대해 알 필요가 있다.
접근 제어 모델에서 인가를 받으려는 사용자를 ‘주체(Subject)’ 라고 한다. ‘주체’는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. ‘객체(Object)’는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. 네이버 카페의 게시판이 ‘객체’의 예이다. ‘권한(Permission)’은 ‘객체’에 허용된 ‘주체’가 수행할 수 있는 행위의 목록을 말한다. 보통 ‘권한’에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다.
결국 접근 제어(Access Control)라는 것은 ‘객체(Object)’에 접근하고자 하는 ‘주체(Subject)’가 해당 ‘객체(Object)’에 접근할 수 있는 ‘권한(Permission)’을 가지고 있는지 판단하는 것이다.
접근 제어 모델의 종류
강제적 접근 제어 모델 (Mandatory Access Control, MAC)
강제 접근 제어(MAC)는 미리 정해진 정책과 보안 등급에 의거하여 주체(Subject)에게 허용된 접근 권한과 객체(Object)에 부여된 허용 등급을 비교하여 접근을 제어하는 방법이다. 대표적인 예로 네이버나 다음 카페에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다.
강제적 접근 제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다.
이러한 강제적 접근 제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근 제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.
임의적 접근 제어 모델 (Discretionary Access Control, DAC)
임의적 접근 제어(DAC)는 객체에 대한 접근을 사용자나 그룹의 신분을 기준으로 제한하는 방법이다. 객체의 소유자는 다른 주체에 대해 객체에 대한 접근 권한을 설정할 수 있다. 대표적인 예는 전통적인 유닉스나 윈도우 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근 제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근 제어를 설정할 수 있다. 여기서 ‘임의적(Discretionary)’이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다.
대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근 제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근 제어(MAC)에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근 제어가 어렵다. 또한 접근 제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다.
DAC 을 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.
접근 제어 행렬(Access Control Matrix)
접근 제어 행렬은 위 그림과 같이 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 위 그림에서 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.
접근 제어 목록 (Access Control List: ACLs)
가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.
가용성 티켓 (Capability Tickets)
접근 제어 목록(ACLs) 과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근 제어 목록(ACLs) 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.
권한 테이블 (Permission Table)
관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.
역할 기반 접근 제어 모델 (Role Based Access Control, RBAC)
역할 기반 접근 제어(RBAC)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근 제어를 하는 방식이다. 임의적 접근 제어(DAC)과 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다.
권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근 제어 방법으로 강제적 접근 제어(MAC)과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근 제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다.
사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.
구현 수준에 따라 RBAC0부터 RBAC3까지 나뉠 수 있다.
속성 기반 접근 제어 모델 (Attribute Based Access Control, ABAC)
속성 기반 접근 제어(ABAC)는 객체와 주체의 속성에 대한 조건을 기술하여 접근 제어를 하는 방식이다. 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근 제어를 수행한다. 예를 들어 파일 1에 접근하기 위해서는 사용자의 type 속성에 admin이라는 태그가 달려 있어야 한다고 정의할 수 있다.
시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋은 것이 장점이지만, 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다. 속성을 일일이 수동으로 정의하기 힘들기 때문에 접근 제어를 정의하기 위한 언어인 XACML (eXtensible Access Control Markup Language)을 별도로 제공한다.
💡
접근 제어의 종류와 구현 방법에 대한 소개를 바탕으로 재작성 되었습니다.
인증 vs 인가
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다.
인증(Authentication)은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가(Authorization)는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가(Authorization)에 해당한다.
당연하게도 ‘인가’를 수행하기 위해서는 ‘인증’이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.
용어 정의
접근 제어 모델을 설명하기 전에 먼저 접근 제어 모델에서 사용하는 용어에 대해 알 필요가 있다.
접근 제어 모델에서 인가를 받으려는 사용자를 ‘주체(Subject)’ 라고 한다. ‘주체’는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. ‘객체(Object)’는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. 네이버 카페의 게시판이 ‘객체’의 예이다. ‘권한(Permission)’은 ‘객체’에 허용된 ‘주체’가 수행할 수 있는 행위의 목록을 말한다. 보통 ‘권한’에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다.
결국 접근 제어(Access Control)라는 것은 ‘객체(Object)’에 접근하고자 하는 ‘주체(Subject)’가 해당 ‘객체(Object)’에 접근할 수 있는 ‘권한(Permission)’을 가지고 있는지 판단하는 것이다.
접근 제어 모델의 종류
강제적 접근 제어 모델 (Mandatory Access Control, MAC)
강제 접근 제어(MAC)는 미리 정해진 정책과 보안 등급에 의거하여 주체(Subject)에게 허용된 접근 권한과 객체(Object)에 부여된 허용 등급을 비교하여 접근을 제어하는 방법이다. 대표적인 예로 네이버나 다음 카페에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다.
강제적 접근 제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다.
이러한 강제적 접근 제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근 제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.
임의적 접근 제어 모델 (Discretionary Access Control, DAC)
임의적 접근 제어(DAC)는 객체에 대한 접근을 사용자나 그룹의 신분을 기준으로 제한하는 방법이다. 객체의 소유자는 다른 주체에 대해 객체에 대한 접근 권한을 설정할 수 있다. 대표적인 예는 전통적인 유닉스나 윈도우 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근 제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근 제어를 설정할 수 있다. 여기서 ‘임의적(Discretionary)’이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다.
대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근 제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근 제어(MAC)에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근 제어가 어렵다. 또한 접근 제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다.
DAC 을 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.
접근 제어 행렬(Access Control Matrix)
접근 제어 행렬은 위 그림과 같이 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 위 그림에서 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.
접근 제어 목록 (Access Control List: ACLs)
가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.
가용성 티켓 (Capability Tickets)
접근 제어 목록(ACLs) 과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근 제어 목록(ACLs) 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.
권한 테이블 (Permission Table)
관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.
역할 기반 접근 제어 모델 (Role Based Access Control, RBAC)
역할 기반 접근 제어(RBAC)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근 제어를 하는 방식이다. 임의적 접근 제어(DAC)과 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다.
권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근 제어 방법으로 강제적 접근 제어(MAC)과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근 제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다.
사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.
구현 수준에 따라 RBAC0부터 RBAC3까지 나뉠 수 있다.
속성 기반 접근 제어 모델 (Attribute Based Access Control, ABAC)
속성 기반 접근 제어(ABAC)는 객체와 주체의 속성에 대한 조건을 기술하여 접근 제어를 하는 방식이다. 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근 제어를 수행한다. 예를 들어 파일 1에 접근하기 위해서는 사용자의 type 속성에 admin이라는 태그가 달려 있어야 한다고 정의할 수 있다.
시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋은 것이 장점이지만, 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다. 속성을 일일이 수동으로 정의하기 힘들기 때문에 접근 제어를 정의하기 위한 언어인 XACML (eXtensible Access Control Markup Language)을 별도로 제공한다.
💡
접근 제어의 종류와 구현 방법에 대한 소개를 바탕으로 재작성 되었습니다.
인증 vs 인가
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다.
인증(Authentication)은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가(Authorization)는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가(Authorization)에 해당한다.
당연하게도 ‘인가’를 수행하기 위해서는 ‘인증’이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.
용어 정의
접근 제어 모델을 설명하기 전에 먼저 접근 제어 모델에서 사용하는 용어에 대해 알 필요가 있다.
접근 제어 모델에서 인가를 받으려는 사용자를 ‘주체(Subject)’ 라고 한다. ‘주체’는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. ‘객체(Object)’는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. 네이버 카페의 게시판이 ‘객체’의 예이다. ‘권한(Permission)’은 ‘객체’에 허용된 ‘주체’가 수행할 수 있는 행위의 목록을 말한다. 보통 ‘권한’에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다.
결국 접근 제어(Access Control)라는 것은 ‘객체(Object)’에 접근하고자 하는 ‘주체(Subject)’가 해당 ‘객체(Object)’에 접근할 수 있는 ‘권한(Permission)’을 가지고 있는지 판단하는 것이다.
접근 제어 모델의 종류
강제적 접근 제어 모델 (Mandatory Access Control, MAC)
강제 접근 제어(MAC)는 미리 정해진 정책과 보안 등급에 의거하여 주체(Subject)에게 허용된 접근 권한과 객체(Object)에 부여된 허용 등급을 비교하여 접근을 제어하는 방법이다. 대표적인 예로 네이버나 다음 카페에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다.
강제적 접근 제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다.
이러한 강제적 접근 제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근 제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.
임의적 접근 제어 모델 (Discretionary Access Control, DAC)
임의적 접근 제어(DAC)는 객체에 대한 접근을 사용자나 그룹의 신분을 기준으로 제한하는 방법이다. 객체의 소유자는 다른 주체에 대해 객체에 대한 접근 권한을 설정할 수 있다. 대표적인 예는 전통적인 유닉스나 윈도우 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근 제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근 제어를 설정할 수 있다. 여기서 ‘임의적(Discretionary)’이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다.
대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근 제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근 제어(MAC)에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근 제어가 어렵다. 또한 접근 제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다.
DAC 을 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.
접근 제어 행렬(Access Control Matrix)
접근 제어 행렬은 위 그림과 같이 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 위 그림에서 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.
접근 제어 목록 (Access Control List: ACLs)
가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.
가용성 티켓 (Capability Tickets)
접근 제어 목록(ACLs) 과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근 제어 목록(ACLs) 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.
권한 테이블 (Permission Table)
관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.
역할 기반 접근 제어 모델 (Role Based Access Control, RBAC)
역할 기반 접근 제어(RBAC)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근 제어를 하는 방식이다. 임의적 접근 제어(DAC)과 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다.
권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근 제어 방법으로 강제적 접근 제어(MAC)과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근 제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다.
사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.
구현 수준에 따라 RBAC0부터 RBAC3까지 나뉠 수 있다.
속성 기반 접근 제어 모델 (Attribute Based Access Control, ABAC)
속성 기반 접근 제어(ABAC)는 객체와 주체의 속성에 대한 조건을 기술하여 접근 제어를 하는 방식이다. 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근 제어를 수행한다. 예를 들어 파일 1에 접근하기 위해서는 사용자의 type 속성에 admin이라는 태그가 달려 있어야 한다고 정의할 수 있다.
시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋은 것이 장점이지만, 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다. 속성을 일일이 수동으로 정의하기 힘들기 때문에 접근 제어를 정의하기 위한 언어인 XACML (eXtensible Access Control Markup Language)을 별도로 제공한다.
💡
접근 제어의 종류와 구현 방법에 대한 소개를 바탕으로 재작성 되었습니다.
인증 vs 인가
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다.
인증(Authentication)은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가(Authorization)는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가(Authorization)에 해당한다.
당연하게도 ‘인가’를 수행하기 위해서는 ‘인증’이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.
용어 정의
접근 제어 모델을 설명하기 전에 먼저 접근 제어 모델에서 사용하는 용어에 대해 알 필요가 있다.
접근 제어 모델에서 인가를 받으려는 사용자를 ‘주체(Subject)’ 라고 한다. ‘주체’는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. ‘객체(Object)’는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. 네이버 카페의 게시판이 ‘객체’의 예이다. ‘권한(Permission)’은 ‘객체’에 허용된 ‘주체’가 수행할 수 있는 행위의 목록을 말한다. 보통 ‘권한’에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다.
결국 접근 제어(Access Control)라는 것은 ‘객체(Object)’에 접근하고자 하는 ‘주체(Subject)’가 해당 ‘객체(Object)’에 접근할 수 있는 ‘권한(Permission)’을 가지고 있는지 판단하는 것이다.
접근 제어 모델의 종류
강제적 접근 제어 모델 (Mandatory Access Control, MAC)
강제 접근 제어(MAC)는 미리 정해진 정책과 보안 등급에 의거하여 주체(Subject)에게 허용된 접근 권한과 객체(Object)에 부여된 허용 등급을 비교하여 접근을 제어하는 방법이다. 대표적인 예로 네이버나 다음 카페에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다.
강제적 접근 제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다.
이러한 강제적 접근 제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근 제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.
임의적 접근 제어 모델 (Discretionary Access Control, DAC)
임의적 접근 제어(DAC)는 객체에 대한 접근을 사용자나 그룹의 신분을 기준으로 제한하는 방법이다. 객체의 소유자는 다른 주체에 대해 객체에 대한 접근 권한을 설정할 수 있다. 대표적인 예는 전통적인 유닉스나 윈도우 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근 제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근 제어를 설정할 수 있다. 여기서 ‘임의적(Discretionary)’이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다.
대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근 제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근 제어(MAC)에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근 제어가 어렵다. 또한 접근 제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다.
DAC 을 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.
접근 제어 행렬(Access Control Matrix)
접근 제어 행렬은 위 그림과 같이 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 위 그림에서 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.
접근 제어 목록 (Access Control List: ACLs)
가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.
가용성 티켓 (Capability Tickets)
접근 제어 목록(ACLs) 과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근 제어 목록(ACLs) 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.
권한 테이블 (Permission Table)
관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.
역할 기반 접근 제어 모델 (Role Based Access Control, RBAC)
역할 기반 접근 제어(RBAC)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근 제어를 하는 방식이다. 임의적 접근 제어(DAC)과 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다.
권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근 제어 방법으로 강제적 접근 제어(MAC)과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근 제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다.
사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.
구현 수준에 따라 RBAC0부터 RBAC3까지 나뉠 수 있다.
Made with SlashPage