접근 제어란
인증(Authentication) vs 인가(Authorization)
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(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)

가용성 티켓 (Capability Tickets)

권한 테이블 (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)을 별도로 제공한다.
결론
지금까지 일반적으로 사용되는 접근 제어 모델의 종류에 대해 알아보았다. 하지만 위에서 알아본 일반적인 접근 제어 모델들이 모든 서비스에 적합한 것은 아니다. 각 서비스마다 보호해야 하는 객체의 종류나 정책이 다를 수 있고, 객체들 사이의 관계도 복잡할 수 있다. 그런 경우에는 위에 제시된 접근 제어 모델만으로는 불충분할 수 있다. 결국 완벽한 접근 제어(사용하기도 쉽고 성능도 나쁘지 않은)를 하기 위해서는 그 시스템을 사용하는 사용자가 누구인지, 그리고 보호하려는 객체는 어떤 것이 있으며, 각 객체 사이의 관계와 특징은 무엇인지, 어느 정도 복잡한 접근 제어까지 지원해야 하는지 등의 요구 사항을 명확히 파악하는 것이 무엇보다도 중요하다.