접근제어모델 종류

들어가며

• 현시대 클라우드를 비롯한 모든 플랫폼의 컴퓨팅 자원은 보안이 중요해진 시점이 왔다. (그 누구도 부정할 수 없다.)
  그러므로 우리는 권한이란 부분이 존재해야 하고, 그 권한을 가진 사용자에게만 접근을 허용해야 한다.
  하지만 점점 많은 시스템과 어플리케이션이 클라우드로 옮겨지면서, 권한관리가 어려워진 부분이 존재한다.
  이에 따라 접근 제어 모델의 종류를 알아보고, 어떤 권한 관리에 초점을 두면 될지 고민해보자.

접근 제어란

• 웹 서비스나 클라우드 서비스 등을 개발하면서, 가장 중요하게 고려해야 하는 부분 중 하나는 바로 각 사용자들이 서비스의 어느 부분까지 사용할 수 있고, 어느 부분은 사용을 못하게 할지, 접근을 막을지 등을 제어하는 것이다.
  이건 보안에 매우 밀접한 관련이 있기 때문에 올바르게 접근 제어를 구현하는 것은 매우 중요하다.
• 서비스 개발자는 해당 서비스를 통해 어떤 기능을 제공할 것인지에 대한 고민 뿐만 아니라, 서로 다른 사용자들의 서비스 접근 권한을 어떻게 제어할 지도 고민해야 한다.
  그러기 위해서는 접근제어 모델의 종류와 예시를 아는 것이 매우 중요하다.

인증(Authentication) vs 인가(Authorization)

• 인증(Authentication)과 인가(Authorization)는 항상 함께 등장하는 개념이면서 사용하기에 헷갈리는 용어이기도 하다.
  하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다.

인증 (Authentication)

• 사용자가 누구인지 판별하는것.
  • 보통 서비스의 로그인 하는 과정이 이에 해당함
  • 사용자가 서비스에 회원가입을 한 사용자이며, 그 사용자가 맞는지를 판별하는 작업

예시 : 은행에서 돈을 인출하려 할때 은행직원은 신분증을 제시해 달라고 요청한다.
비행기 티켓을 구매하려고 하면, 비행기를 탈수 있는 자격이 되는지 증명하기 위해 여권을 제시해야 할 수도 있다.

• 두 예시 모두 신원(인증된 사용자)를 확인하기 위해 인증절차가 어떻게 진행되는지를 보여준다.
• 뒤집어서, 온라인이나 서비스개발도 마찬가지이다.
  • naver.com.com 에 접속하려고 할때, 여권이나 신분증을 제시하는 대신 아이디/패스워드를 입력하거나, 휴대폰에 전달된 SMS 에 적혀있는 2차 인증코드를 입력하는것.
    • 이처럼 인증요소는 하나일수도 있고, 두개(two-factor) 또는 그 이상(multi-factor) 일 수도 있다.

인가 (Authorization)

• 어떤 사용자가 어떤 행위를 수행할 권한을 가지고 있는가를 판별하는것.
  • 어떤 개체가 어떤 리소스에 접근할 수 있는지 또는 어떤 동작을 수행할 수 있는지를 검증하는 것 (즉 접근 권한을 얻는 일을 말함)

예시 : 공연장에 입장하기 위해 티켓을 구매하는 상황, 기획사는 신원이 무엇인지에는 관심이 없음. 단지 공연장에 입장할 권한이 있는지에 대한 여부만 관심이 있음
신원정보를 포함하지 않더라도, 인가 과정에서 검증이 실패하거나 하는것이 아닌것처럼..

• 인터넷 기반 앱에서는 일반적으로 토큰이라 부르는 가공물을 사용하여, 인가를 다룬다.
  유저가 로그인을 하고 오면, 무엇을 할수 있는가에 대한 관심을 갖는것.
  사용자 신원을 바탕으로 인가 세부사항을 가진 토큰을 생성하게 된다.
  시스템은, 인가 토큰을 이용해서 어떤 권한을 부여할지, 리소스 접근 요청을 허용할지 거부할지를 결정함

인증 VS 인가

• 위에서 무엇을 뜻하는지 밝히기는 했지만, 이 용어들은 자주 중복해서 사용되고 혼란의 원인이 된다.

  예시 : 은행에서처럼 신분증을 제시했지만, 그 신분증은 본인의 계좌에 접근하기 위한 인가에도 사용되기 때문
  사원증을 아무리 찍어도, 대표님 방문은 열수 없는것처럼..

• 인증과 인가는 밀접하게 연관되어 있으나, 어떤 시나리오에서는 서로 바꿔서 사용할 수 있는 주제가 되기도 하다.

• 여기서 중요한 점은 인증은 인가로 이어지지만, 인가가 인증으로 이어지지는 않는다는 점이다.

  • 신원증명이 접근권한을 증명하기에는 충분하다 할지라도.. 무언가를 얻는 인가가 항상 개체를 식별하는데 사용할수 있는게 아닌것처럼.

예시 : 비행기탈때 탑승권으로 승무원은 내 신원을 알수 있지만.. 공연티켓으로 공연을 볼수있다 할지라도, 공연장에 입장할수 있지만, 그 다른 무엇도 아닌것처럼..

돌아와서..

• 당연하게도 ‘인가’를 수행하기 위해서는 ‘인증’이 선행되어야 한다.
  먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.

용어 정의

• 접근 제어 모델을 설명하기 전에 먼저 접근 제어 모델에서 사용하는 용어에 대해 알 필요가 있다.

  • 접근 제어 모델에서 인가를 받으려는 사용자를 ‘주체(Subject)’ 라고 한다.

    • ‘주체’는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다.

  • ‘객체(Object)’는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다.

    • 네이버 카페의 게시판이 ‘객체’의 예이다.
    • ‘권한(Permission)’은 ‘객체’에 허용된 ‘주체’가 수행할 수 있는 행위의 목록을 말한다. 보통 ‘권한’에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다.

• 결국 접근 제어(Access Control)라는 것은 ‘객체(Object)’에 접근하고자 하는 ‘주체(Subject)’가 해당 ‘객체(Object)’에 접근할 수 있는 ‘권한(Permission)’을 가지고 있는지 판단하는 것이다.

접근 제어 모델의 종류

• 접근 제어를 어떻게 구현할지에 대해서는 많은 고민이 필요하다.
  • 하지만 이미 잘 정립된 여러 종류의 접근 제어 모델들이 제시되어 있으므로, 어떤 것들이 있는지 살펴보고 각각의 장단점을 파악하면 자신만의 접근 제어 모델을 수립하는 데 도움이 될 것이다.

강제적 접근 제어 모델 (Mandatory Access Control, MAC)

• 미리 정해진 정책과 보안 등급에 의거하여 주체(Subject)에게 허용된 접근 권한과 객체(Object)에 부여된 허용 등급을 비교하여 접근을 제어하는 방법

예시 : 네이버나 다음 까페에서 회원 등급에 따라 접근할 수 있는 게시판과 없는 게시판을 구분하는것.
각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다.

• 강제적 접근 제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다.

  • 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다.
  • 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다.

• 장점 : 강제적 접근 제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다.

• 단점 : 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근 제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다.

임의적 접근 제어 모델 (Discretionary Access Control, DAC)

• 객체에 대한 접근을 사용자나 그룹의 신분을 기준으로 제한하는 방법
  • 객체의 소유자는 다른 주체에 대해 객체에 대한 접근 권한을 설정할 수 있다.

예시 : 리눅스 파일이나, 디렉토리에 대해 접근제어 방식을 말한다.
이 유저의 권한은 읽기쓰기수정, 이 유저의 권한은 읽기.. 등
파일은 파일의 소유자가 그 파일에 대한 접근 제어를 설정할 수 있다.

• 여기서 ‘임의적(Discretionary)’이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻

• DAC 을 구현하는 방법은 대표적으로 다음 4가지의 구현 방법이 있다. (이것에 대한 구현방법은 내용이 너무 길어지므로, 종류만 소개한다.)

  • 접근 제어 행렬 (Access Control Matrix)
  • 접근 제어 목록 (Access Control List: ACL)
  • 가용성 티켓 (Capability Tickets)
  • 권한 테이블 (Permission Table)

• 장점 : 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있다.

• 단점 : 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.
  어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.

역할 기반 접근 제어 모델 (Role Based Access Control, RBAC)

• 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근 제어를 하는 방식

• 이름 그대로 역할에 따라 자원에 대한 접근을 제어한다.

  • 대부분의 상용 플랫폼이 지원하는 권한 관리 체계로 권한 영역에 역할이라는 개념을 도입해 표현력을 확장한 방식이다.
  • 임의적 접근 제어(DAC)과 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다.
    • 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델

• 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근 제어 방법으로 강제적 접근 제어(MAC)과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근 제어가 이루어진다.

실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다.

• 사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다.

  • 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.

• 역할 정의

{
	"name": "roles/testRole",
	"title": "billing role",
	"includedPermissions": [
		"paymentStatement.list",
		"usage.list"
	]
}

• 역할 부여

{
	"bindings": [{
		"role": "roles/testRole",
		"members": [
			"user:viewrain@hohoho.com"
		]
    }]
}

• 장점 : 권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다.
• 단점 : 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다.

속성 기반 접근 제어 모델 (Attribute Based Access Control, ABAC)

• 객체와 주체의 속성에 대한 조건을 기술하여 접근 제어를 하는 방식
  • 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근 제어를 수행한다.
  • 속성은 주체 이름, 자원 유형, 현재 시간 등 다양하게 존재하며 지원하는 속성의 종류는 각 플랫폼마다 상이하다.

예시 : 예를 들어 파일 1에 접근하기 위해서는 사용자의 type 속성에 admin이라는 태그가 달려 있어야 한다고 정의할 수 있다.

• 속성 기반 접근 제어 적용

{
 	"bindings": [{
    	 "role": "roles/testRole",
      	 "members": [
         	 "user:viewrain@hohoho.com"
     	 ]}
   	],	
	"condition": {
		"title": "DateTime Expires",
		"description": "Expires at noon on 2023-12-31 UTC",
		"expression": "request.time < timestamp('2022-06-01T12:00:00Z')"
    }
}

• 장점 : 시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋다.
• 단점 : 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다.

결론

• 지금까지 일반적으로 사용되는 접근 제어 모델의 종류에 대해 알아보았다.
  하지만 위에서 알아본 일반적인 접근 제어 모델들이 모든 서비스에 적합한 것은 아니다.

• 각 서비스마다 보호해야 하는 객체의 종류나 정책이 다를 수 있고, 객체들 사이의 관계도 복잡할 수 있다.

• 결국 완벽한 접근 제어(사용하기도 쉽고 성능도 나쁘지 않은)를 하기 위해서는 그 시스템을 사용하는 사용자가 누구인지, 그리고 보호하려는 객체는 어떤 것이 있으며, 각 객체 사이의 관계와 특징은 무엇인지, 어느 정도 복잡한 접근 제어까지 지원해야 하는지 등의 요구 사항을 명확히 파악하는 것이 무엇보다도 중요하다.

• 인터넷에 권한관리에 대한 내용을 검색해보면, 큰 틀이지만 공통된 방안을 제시한다.

  • 1. 미리 제공되는 역할을 사용할 것
  • 2. 서비스별 계정을 분리할 것
  • 3. 최소 권한만 부여할 것

• 플랫폼에 따라 지원 수준과 표현법은 다르지만 역할 기반 및 속성 기반 접근 제어는 권한 관리의 기본이기 때문에 조금 복잡하더라도 한 번만 제대로 익혀두면 다양한 서비스에 적용할 수 있다.
  권한 관리의 허점을 파고든 클라우드 보안 사고의 발생 가능성은 항상 존재합니다. 특히 클라우드가 기업 IT 전략 방향의 중심에 위치하면서 시스템, 애플리케이션 및 데이터에 대한 접근 권한 관리에 많은 신경을 써야 한다.

reference

• https://velog.io/@aaronddy/인증Authentication과-인가Authorization
• https://dextto.tistory.com/234 (인증 vs 인가)
• https://www.samsungsds.com/kr/insights/cloud_platform_manage.html
• https://tino1999.tistory.com/40