RBAC과 ABAC 기초 정리

RBAC(Role-Based access Control)이란

접근이나 작업에 대한 권한을 역할에 따라 결정한다.
여기서 역할은 보통 부서 , 위치 , 연공서열 , 담당 업무 등등... 이다.

역할이 정의되면 다음에 대한 권한을 할당할 수 있다.

• 액세스
  • 무엇에 접근할 수 있을지?
• 운영
  • 무엇을 읽고, 무엇을 작성할 수 있을지?
  • 파일을 생성하거나 삭제할 수 있을지?
• 세션
  • 시스템에 얼마나 오래 머무를 수 있을지?
  • 로그인은 언제 작동하고 언제 만료되는지?

ABAC(Attribute-Based Access Control)

접근이나 작업에 대한 권한을 사용자, 리소스 속성 또는 환경에 따라 결정한다.

권한을 다음과 같이 할당할 수 있다.

• 사용자
  • 사람의 직급과 연공서열에 따라서 등등..
• 리소스 속성
  • 파일유형, 만든사람, 문서의 중요도 등등...
• 환경
  • 파일에 액세스하고 있는 위치, 시간대 또는 날짜

비교

RBAC과 ABAC은 서로 상반되는 개념이 아니다.
사실 ABAC은 RBAC에서 발생할 수 있는 귀찮은 문제를 쉽게 해결할 수 있게 도와준다.

예를 들어서 여러 명의 사람이 존재하고, 이 사람들은 종류에 따라 요리사, 경찰관, 교사 라는 Role을 가진다.

만약 A라는 가게의 주방에는 요리사라는 Role을 가진 사람만 입장 가능하다고 하면 이는 RBAC이다.

그리고 여기서 a, b, c, d라는 사람들이 요리사 role을 가지고 있을 때에, 가격을 바꿀 수 있는 사람은 추가로 정의되어야 한다.

그리고 가장 연봉이 높은 사람이 가격을 변경할 수 있다. 고 가정해 보자.
a, b, c, d 중 c가 가장 많은 연봉을 가지고 있다고 할 때에 c에게 추가로 가격 변경 권한을 주는 것은 비효율적이다.
매번 이 권한들을 확인해야 할 뿐더러, 만약 새로운 직원 e가 들어왔는데, 이 사람이 c보다 연봉이 높으면 권한을 회수한 뒤 e에게 다시 주어야 하기 때문이다.

이럴 때에, 그냥 해당 요리사 role 내에, 추가적인 정책을 정의해 주면 된다.
if 연봉이 가장 높음 then 가격 변경 가능 이라는 정책이 추가로 필요할 것이다.

이렇게 되면 관리하기 편하고 이해하기도 쉽다.
그리고 위의 방식이 ABAC 방식이다.
if ~ then 의 형태로 이런 정책을 차등으로 부여 가능하다.

이는 위에 적힌 것처럼 다양한 방식으로 바꾸어 줄 수 있다.

AWS의 IAM에서 Tag를 사용하면 이 ABAC방식을 적용 가능하다.