RBAC: 역할 기반 액세스 제어

시작하기 전에

지금까지 옮겨다니면서 지낸 회사에서보다, 지금 회사에서 배우는 게 훨씬 많은 것 같다.

친하게 지내는 분이 있는데 막말을 정말 잘하신다. 내가 좋아하지 않는 개발자에게 이번에 “그 정도 아니세요”라고 면전에 대놓고 말하실 정도로 할 말을 하시는 분인데, 최근에 RBAC가 조금 문제가 되면서 어떻게 해야 할지 이야기를 나누던 와중에 나왔던 이야기였다.

RBAC(Role-Based Access Control)

개별 사용자가 아닌 조직 내 역할(Role)에 따라 시스템 및 데이터 접근 권한을 부여하는 보안 방식이다. 직무별로 권한을 정의하는 가장 대중적인 인가(Authorization) 모델이다.

예를 들어서, 우리 회사에는 개발자도 있고, 인사팀도 있고, 현장직도 있고, 현장을 관리하시는 분들도 계시다. 이분들 모두가 우리의 관리자 페이지에 접근을 해서 각자의 작업을 수행해야 한다.

이때, 인사팀은 인증/인가를 관리하는 페이지에 들어올 이유가 없고, 현장직은 여러 고객들을 관리하는 페이지에 들어올 이유가 없다.

이처럼, 모두에게 현관문을 열 수 있는 열쇠는 줬지만, 그 열쇠로 들어갈 수 있는 방은 제한적이다.

이렇게 하지 않으면?

사실 사람이 적을 땐 큰 문제가 되지 않는다. 어차피 옆자리에 있는데 문제가 발생하더라도 파악하는 데 많은 시간이 들지 않는다.

하지만 사람이 늘어나면 늘어날수록 엔지니어가 생각하지 못했던 이슈들이 발생할 수 있고, 서비스 도중에 멈춰버리거나 페이지가 다운되어버리는 이슈가 발생할 수 있다. 이렇기 때문에 효율적으로 직급/역할에 맞게 권한을 부여하거나, 회수할 수 있어야 한다.

이러한 방법 중에 가장 대표적인 방법이 RBAC, 역할 기반 접근 제어이다.

“쉽게 제어할 수 있고, 사용자별로 접근할 수 있는 페이지와 API가 달라져야 한다”라고 생각했을 때 가장 먼저 “역할”별로 나누는 걸 떠올린다. 그만큼 가장 대표적으로 생각나기도 하고, 추적하기에 용이하다.

단점

아쉽게도 뭔가 부족한 느낌을 받는다. 예를 들어 똑같은 역할을 하더라도, 팀장/리더급의 직책을 갖고 있다면 더 높은 권한이 필요할 때도 있고, 그러다 보면 점점 세분화해서 역할을 관리하다 보면 조금씩 다른 역할들이 너무 많이 생겨나 관리하기가 어려워진다.

나도 처음에는 팀별로 역할을 나누어 권한을 부여했다. 그러다 보니 다른 팀 리더님은 해당 페이지가 보이지 않았고, 이런 페이지가 있는지도 모르니 새로운 기능을 요청했다고 한다. “나는 팀장이고 회사 이사인데 왜 안 보이냐” 하셔서 추가적인 역할을 만들어서 보여줬다.

그리고 우리 팀에서도 개발팀이지만 개발자보단 현장 관리 엔지니어에 가까우신 분은 사실 역할 관리 페이지에 접근할 이유가 없었기 때문에, 또 세부적인 권한을 나누어 관리하기 시작하다 보니 팀 x 직급으로 권한이 세분화되기 시작해서 비슷한 권한을 가진 역할이 목적이 다르다 보니 너무 많이 생겨나기 시작했다.

RBAC의 주요 규칙

그럼 어떻게 설계해야 할까? RBAC의 주요 규칙은 다음과 같다.

해당 규칙들을 사용하면 그래도 쉽게 접근해볼 수 있다. 현실과 딱 맞게 떨어지진 않지만, 그래도 쉽고 직관적이며 효율적으로 통제가 가능한 솔루션이라고 생각한다.

마치며

우리 팀 리더님께서는 페이지와 API를 역할/직급에 맞춰서 읽기 권한, 쓰기 권한, 전체 권한을 나누어 스위치로 관리하는 걸 제안하셨고, 현재는 그렇게 관리를 하고 있다.

그때그때 요청하는 걸 스위치 딸깍 하면서 쉽게 제어하고 있지만, 애초에 해당 제어 방법에는 한계가 있다 보니 점점 요구사항들이 생겨날 때마다 “아 어떻게 하지” 하는 생각이 들 때가 있다.

클로드랑 해서 열심히 고민은 해보고 있긴 한데 정답은 없는 것 같다.

참고

• Cloudflare - RBAC란?
• 권한관리 어디까지 해봤니 - RBAC, ABAC, ReBAC