RBAC과 ABAC의 차이: 권한 관리는 역할만으로 충분할까?

서비스에 관리자와 일반 사용자가 있다면 보통 가장 먼저 이런 코드를 작성하게 된다.

if (user.role === 'admin') {
  // 관리자 기능
}

규모가 작은 서비스라면 이것만으로도 충분하다.

하지만 서비스가 커지면 요구사항이 조금씩 달라진다.

관리자는 모든 게시물을 수정할 수 있다.
매니저는 자신이 속한 팀의 게시물만 수정할 수 있다.
일반 사용자는 자신이 작성한 게시물만 수정할 수 있다.

여기서부터 단순한 admin / user 구분만으로는 권한을 표현하기 어려워진다.

이때 알아두면 좋은 개념이 RBAC(Role-Based Access Control)과 ABAC(Attribute-Based Access Control)이다.

RBAC이란?

RBAC은 사용자의 역할(Role)을 기준으로 권한을 부여하는 방식이다.

NIST에서는 RBAC의 핵심을 사용자에게 권한을 직접 연결하는 대신, 권한을 Role에 연결하고 사용자를 적절한 Role에 소속시키는 방식으로 설명한다.

예를 들어 서비스에 다음과 같은 역할이 있다고 해보자.

ADMIN
MANAGER
MEMBER

그리고 각 역할에 권한을 부여한다.

ADMIN
├─ 게시물 조회
├─ 게시물 생성
├─ 게시물 수정
└─ 게시물 삭제

MANAGER
├─ 게시물 조회
├─ 게시물 생성
└─ 게시물 수정

MEMBER
└─ 게시물 조회

코드에서는 이런 식으로 표현할 수 있다.

const rolePermissions = {
  admin: [
    'post.read',
    'post.create',
    'post.update',
    'post.delete',
  ],

  manager: [
    'post.read',
    'post.create',
    'post.update',
  ],

  member: [
    'post.read',
  ],
};

이제 사용자마다 권한을 일일이 저장할 필요 없이 Role만 지정하면 된다.

사용자 A → ADMIN
사용자 B → MANAGER
사용자 C → MEMBER

권한 정책이 단순하고 조직의 역할 구분이 명확하다면 RBAC은 관리하기 쉽다.

RBAC의 한계

문제는 같은 Role을 가진 사용자라도 접근 가능한 데이터가 달라져야 할 때 발생한다.

예를 들어 모든 MANAGER에게 다음 권한이 있다고 해보자.

post.update

그렇다면 MANAGER는 모든 게시물을 수정할 수 있는 것일까?

실제 서비스에서는 이런 요구사항이 더 흔하다.

MANAGER는 게시물을 수정할 수 있다.

단,
자신이 담당하는 팀의 게시물만 수정할 수 있다.

MANAGER라는 Role만으로는 이런 데이터 범위를 자연스럽게 표현하기 어렵다.
RBAC에서도 역할을 더 세분화해 해결할 수 있지만, 조건이 많아질수록 역할의 수가 빠르게 증가할 수 있다.

여기서 ABAC이 등장한다.

ABAC이란?

ABAC은 사용자와 대상이 가지고 있는 속성(Attribute)을 이용해 접근 권한을 판단하는 방식이다.

NIST에서는 ABAC을 사용자, 접근 대상, 요청된 행위, 경우에 따라 환경 조건 등의 속성을 정책과 비교하여 접근을 허용하거나 거부하는 방식으로 정의한다.

예를 들어 사용자가 다음과 같다고 해보자.

const user = {
  id: 'user-1',
  teamId: 'team-a',
};

게시물에는 다음 정보가 있다.

const post = {
  id: 'post-1',
  teamId: 'team-a',
  authorId: 'user-2',
};

정책을 다음과 같이 만들 수 있다.

사용자의 teamId === 게시물의 teamId

두 값이 같을 때만 수정할 수 있다.

개념적으로 표현하면 다음과 같다.

const canUpdatePost =
  user.teamId === post.teamId;

이것이 ABAC의 기본적인 형태이다.

Role뿐만 아니라 사용자와 리소스가 가지고 있는 실제 값을 이용해 판단한다.

RBAC과 ABAC의 가장 큰 차이

한 문장으로 줄이면 다음과 같다.

RBAC은 "어떤 역할을 가지고 있는가?"를 기준으로 판단하고, ABAC은 "사용자와 리소스가 어떤 속성과 관계를 가지고 있는가?"까지 보고 판단한다.

실제 서비스에서는 둘 중 하나만 사용할까?

꼭 그렇지는 않다.

오히려 RBAC을 기본으로 두고 필요한 곳에 ABAC을 추가하는 방식이 실용적이다.

예를 들어 다음과 같은 권한이 있다고 해보자.

ADMIN
→ 모든 게시물 관리

MANAGER
→ 게시물 수정 가능

MEMBER
→ 게시물 수정 가능

여기까지만 보면 RBAC이다.

그런데 조건을 추가한다.

ADMIN
→ 모든 게시물 수정 가능

MANAGER
→ 자신이 담당하는 팀의 게시물만 수정 가능

MEMBER
→ 자신이 작성한 게시물만 수정 가능

이제 구조는 다음과 같이 된다.

Role
  ↓
Permission
  ↓
Condition

MANAGER
  ↓
post.update
  ↓
post.teamId === user.teamId

Role과 Permission은 RBAC이 담당하고, 데이터 접근 범위는 ABAC이 담당하는 형태이다.

Permission과 Scope로 생각해도 쉽다

여기서 Permission과 Scope는 RBAC과 ABAC의 공식적인 구분이라기보다, 권한 정책을 이해하기 쉽게 나누어 생각하는 방법이다.

권한을 설계할 때는 다음 두 질문을 나누면 이해하기 쉽다.

Permission
무엇을 할 수 있는가?

Scope
어디까지 할 수 있는가?

예를 들어:

Permission
post.read

은 게시물을 조회할 수 있다는 의미이다.

여기에:

Scope 같은 팀의 게시물만

이라는 조건이 붙을 수 있다.

결국 정책은 다음과 같다.

게시물을 조회할 수 있다.
+
자신이 속한 팀의 게시물만 조회할 수 있다.

예를 들어 JS/TS용 권한 제어 라이브러리인 CASL과 유사한 형태로 표현하면 :

can('read', 'Post', {
  teamId: user.teamId,
});

같은 형태가 된다.

어떤 Attribute를 사용할 수 있을까?

ABAC에서 Attribute는 특정한 종류로 제한되지 않는다.

예를 들어 사용자 속성을 이용할 수 있다.

user.id
user.teamId
user.departmentId
user.companyId

리소스 속성을 이용할 수도 있다.

post.authorId
post.teamId
document.companyId
document.status

환경이나 상태 역시 정책에 포함할 수 있다.

특정 시간에만 접근 가능
특정 상태의 문서만 수정 가능
승인되지 않은 데이터만 수정 가능

NIST 역시 ABAC에서 Subject, Object뿐 아니라 환경 조건까지 정책 판단에 이용할 수 있다고 설명한다.

그렇다면 처음부터 ABAC으로 만들면 되지 않을까?

가능하지만 반드시 좋은 선택은 아니다.

예를 들어 단순한 서비스에서:

ADMIN
MEMBER

두 역할만 있고 ADMIN만 관리 페이지에 접근할 수 있다면:

user.role === 'admin'

정도로도 충분하다.

그런데 처음부터 모든 정책을:

role
department
company
resource owner
resource status
time
location
...

조건으로 만들어 버리면 권한 시스템 자체가 하나의 거대한 도메인이 된다.

권한 시스템은 복잡할수록 좋은 것이 아니다.

필요한 만큼만 복잡해야 한다.

그래서 일반적인 접근은 다음과 같다.

단순한 역할 구분
        ↓
      RBAC

데이터 범위 조건 발생
        ↓
   RBAC + ABAC

아주 복잡한 정책 발생
        ↓
별도의 Policy 시스템 검토

정리

RBAC과 ABAC은 서로 경쟁하는 개념이라기보다 권한 문제를 해결하는 서로 다른 기준에 가깝다.

RBAC은 다음 질문에 강하다.

이 사용자는 어떤 역할이고, 어떤 기능을 사용할 수 있는가?

ABAC은 다음 질문에 강하다.

사용할 수 있다면, 정확히 어떤 데이터까지 접근할 수 있는가?

그래서 서비스 초기에는 RBAC만으로 충분할 수 있다.

하지만 다음과 같은 요구사항이 나오기 시작한다면 ABAC을 함께 고려할 시점이다.

"자신이 작성한 것만"
"자신이 속한 팀만"
"자신이 담당하는 고객만"
"특정 상태의 데이터만"

결국 권한 설계에서 중요한 것은 RBAC과 ABAC 중 무엇이 더 좋은지를 결정하는 것이 아니다.

현재 서비스의 권한이 Role만으로 설명되는지, 아니면 데이터와 사용자의 관계까지 알아야 하는지를 구분하는 것이 먼저이다.