액세스 제어 패턴: RBAC, ABAC
보안에서는 토큰이나 세션을 통해서 인가를 구성하는 것도 중요하지만, "권한"을 정의하고 제한하는 것도 그만큼 중요하다. 얼마전만 해도 페이스북이었나 인스타북이었나, 리소스에 대한 권한이 설정되지 않아서 남들 정보를 마음대로 엿볼 수 있는 취약점으로 시끄러웠었다.
이런 문제를 잘 해결하려면 적합한 액세스 제어 패턴을 선택하고 관리하는 것이 중요하다.
역할 기반 액세스 제어 (RBAC:Role-Based Access Control)
각각의 유저에게 "역할(Role)"을 부여하고 역할에 따라서 권한을 정의하는 접근 방법을 말한다.
.png?type=w800)
예를 들면, 사장, 부장, 과장, 사원의 단위로 역할을 정의하고 각 역할에 맞는 권한 제어를 구현할 수 있을 것이다.
각 역할에는 고정된 형태로 할 수 있는 것과 할 수 없는 것들에 대한 권한이 정해져있다.
구현이 비교적 간단하고 직관적이지만, 권한을 세밀하게 조정할 수 없다는 단점이 있다.
예를 들어 John 사원이 "A 작업"을 해야 하는데 이게 "과장" 역할 이상에만 부여된 권한이라면, John에게 "과장"의 역할을 추가해주거나, "사원" 역할에 "A 작업"의 권한을 줘야 한다. 특수화된 권한 부여를 할 수가 없다.
속성 기반 액세스 제어 (ABAC:Attribute-Based Access Control)
속성 기반 액세스 제어는 RBAC의 경직된 권한제어를 좀 개선할 수 있는 방법론이다.
그대신 구현이 조금 더 복잡하다.
ABAC은 단순 역할 단위에서 벗어나서 어떠한 속성 기반으로 조건을 건다.
예를 들면
- "어떤 사용자가" 작업을 시도했고
- "어떤 데이터에" 접근을 시도했고
- "언제" 접근을 시도했는지
등을 전부 고려해서 권한 제약을 걸 수 있도록 할 수 있는 것이다.
이러한 조건들에는 딱히 정해진 형태가 없다. 연봉이 5000 이상인 사람만 접근이 가능하도록 구성한다고 하면 그것도 ABAC이라고 할 수 있다.
무엇을 써야 하는가?
사실 대부분의 시스템은 초기 구현부터 RBAC을 적용할 필요는 없다. 간단한 경우에는 RBAC 구조만으로도 충분하다.
게다가 RBAC과 ABAC은 배타적인 관계가 아니라 보완적인 관계다. RBAC을 기반으로 뼈대를 잡고 ABAC으로 부족한 부분들을 보완해나가는 것이 일반적인 형태다.
대표적으로 AWS의 IAM 권한시스템만 해도, "Role"이라는 RBAC 기반으로 해서 여러가지 ABAC 구조를 쌓아나간 형태인 것을 볼 수 있다.
어떤 리소스에, 어떤 Action을 할 수 있는지 정의할 수 있으며, 좀더 복잡하게 제어한다면 태그를 기반으로 권한을 제어할 수도 있다.
참조
https://www.cloudflare.com/ko-kr/learning/access-management/role-based-access-control-rbac/
https://www.okta.com/kr/identity-101/role-based-access-control-vs-attribute-based-access-control/
https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/introduction_attribute-based-access-control.html
https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html