RBAC, ABAC, PBAC, MAC, ReBAC. 접근 제어를 논의하는 자리에서 이 용어들은 흔히 같은 목록에 나란히 놓인 채 "당신 시스템은 어떤 모델을 쓰는가"라는 하나의 질문에 대한 경쟁 후보처럼 다뤄진다. IdPro에 실린 이 글은 그 관행 자체가 혼란의 근원이라고 지적한다. 이 용어들은 사실 서로 다른 질문에 대한 답인데, 마치 하나의 질문에 대한 답인 것처럼 취급되면서 상호 보완적인 기술들이 라이벌처럼 비교된다는 것이다.
필자가 든 대표적 예가 PBAC다. RBAC와 ABAC는 결정이 무엇을 근거로 내려지는지, 즉 규칙의 모양을 설명한다. 역할을 보는가, 속성을 보는가의 문제다. 반면 PBAC는 그 결정이 어떻게 내려지는지, 즉 규칙이 애플리케이션 코드에 박혀 있는 대신 중앙화된 정책 엔진에서 평가되는지를 말한다. 하나는 규칙의 형태에 대한 것이고 다른 하나는 규칙이 어디에 살고 누가 평가하는가에 대한 것이다. 필자의 비유를 빌리면 이 둘을 경쟁 선택지로 놓는 것은 레시피와 주방을 비교하는 셈이다. 같은 문제는 MAC와 DAC에도 있다. 이 둘은 규칙이 어떻게 생겼는지가 아니라 누가 규칙을 관리하는지를 말하는데도 RBAC, ABAC와 한 줄에 세워진다.
하나의 요청, 다섯 단계
인가는 결국 하나의 질문으로 환원된다. 이 주체가 이 객체에 대해 이 행동을 할 수 있는가. 파일을 읽는 사용자, API를 호출하는 서비스, 데이터베이스에 쓰는 프로세스 모두 주체, 행동, 객체라는 같은 삼각 구조로 정리된다. 필자는 자기 방 서랍 속 일기장 비유를 든다. 원하는 사람과 결정하는 사람이 같다면 인가는 존재하지 않는다. 서랍을 열고 읽으면 그만이다. 그러나 그 일기장을 룸메이트가 있는 집이나 회사 캐비닛에 넣는 순간, 누군가는 사안별로 누가 열 수 있는지를 정해야 한다. 소프트웨어에서 그 역할을 하는 것이 리소스 서버다.
하나의 인가 요청을 리소스 서버 안에서 따라가면 기술과 무관하게 일관된 단계가 드러난다. 요청이 도착하고, 서버가 사용자와 리소스에 관한 맥락을 모으고, 정책이 그 맥락을 규칙에 비추어 평가하고, 허용 또는 거부라는 결정이 나오고, 서버가 그 결정을 집행한다. 이 다섯 단계는 접근 제어 아키텍처에서 오래 쓰인 PAP, PIP, PDP, PEP 어휘와 대응한다. 글은 또 Mohamed 등의 2022년 체계적 문헌 리뷰를 인용해, 전략과 모델과 정책과 메커니즘이 별개의 층위이며 이들을 뭉뚱그리는 지점에서 용어가 무너진다고 정리한다.
여섯 개의 축
핵심 제안은 다섯 단계를 여섯 개의 독립적인 축으로 펼치는 것이다. 정책은 모델과 분리되는데, 하나의 모델이 여러 종류의 구체적 정책 산출물로 구현될 수 있기 때문이다. 필자는 이 여섯 축을 법 체계에 빗댄다. 첫째는 규칙을 쓸 권한이 누구에게 있는가, 즉 관리 전략이다. 의회가 전체를 위해 입법하듯 중앙화될 수도 있고, 이웃끼리 경계를 합의하거나 집주인이 열쇠를 나눠주듯 분산될 수도 있다. 흥미로운 데이터로, 앞의 문헌 리뷰가 RBAC와 ABAC와 ReBAC 계열을 이 축에 분류했을 때 모두 DAC나 MAC이 아닌 하이브리드로 떨어졌다. 관리 전략이 모델과 진짜로 독립적이라는 근거다.
둘째는 규칙이 실제로 무엇을 근거로 판단하는가, 즉 대부분이 인가 모델이라고 부를 때 떠올리는 축이다. 여기에 ACL, RBAC, ABAC, ReBAC가 놓인다. 다만 필자는 학술 문헌에 따라 ACL과 RBAC가 속성이 신원이나 역할일 뿐인 ABAC의 특수 사례로 기술되기도 한다는 모호함을 솔직히 인정한다. 셋째는 그 모델이 어떤 구체적 산출물로 기록되는가라는 정책 축이다. 같은 RBAC라도 정책을 어떻게 표현하느냐에 따라 유지보수성과 감사 가능성이 완전히 달라질 수 있다. 넷째는 규칙이 의존하는 데이터가 무엇이며 런타임에 어디서 오는가다. 필자는 시간대에 의존한다는 사실은 모델링 질문이지만 그 값을 얻기 위해 디렉터리 서비스로 네트워크 왕복을 해야 한다는 사실은 지연과 실패 양태에 실제 영향을 주는 아키텍처 질문이라며, 둘을 섞는 것이 바로 문제의 축소판이라고 짚는다.
다섯째와 여섯째는 결정과 집행이다. 규칙과 데이터가 준비되면 무언가가 실제로 평가를 실행해야 하는데, 그 평가가 어디서 일어나는가가 결정 축이다. PBAC는 바로 여기에 산다. 결정 지점을 정책 엔진으로 중앙화하는 것은 평가가 어디서 일어나는지에 대한 아키텍처 선택이며, 역할 기반이든 속성 기반이든 어떤 모델과도 결합할 수 있다. 그래서 PBAC는 RBAC나 ABAC의 대등한 동료가 아니라 다른 질문에 대한 답이다. 마지막 집행 축은 결정이 내려진 곳과 같을 필요가 없다. API 게이트웨이로 집행하든 인라인 미들웨어로 집행하든 ABAC 시스템은 여전히 ABAC다. 법정이 판결하고 경찰이 집행하듯, 결정과 집행은 분리된다.
실무자에게 남는 것
이 분류가 실무에 주는 값은 도구 선택 논쟁의 성격을 바꾼다는 데 있다. "우리는 RBAC를 쓸까 PBAC를 쓸까" 같은 질문은 서로 다른 축을 하나로 뭉갠 잘못된 대립이며, 여섯 축으로 나누면 각각을 독립적으로 답한 뒤에야 익숙한 라벨이 어디에 떨어지는지 보인다. 역할 기반 모델을 쓰면서 결정은 중앙 엔진에 두고 집행은 게이트웨이에서 하는 조합이 얼마든지 가능하다는 뜻이다. 다만 글 스스로 인정하듯 이 네 가지 모델 범주는 수학적으로 상호 배타적이지 않으며 가장 유용한 절단선일 뿐이다. 또한 이 글은 특정 벤더 제품이나 성능 수치를 다루지 않는, 어디까지나 용어와 개념 정리에 머무는 제안이라는 점도 함께 감안해 읽을 필요가 있다. 그럼에도 인가 설계를 문서화하거나 팀 내 논의를 정렬할 때, 축을 나눠 각각을 묻는 습관은 불필요한 대립을 걷어내는 실용적인 도구가 된다.