[Litis TechDay] RBAC에서 ABAC으로, 권한 관리의 기준을 다시 묻다

Litis는 9월 28일 Tech Day에서 AIM과 관련된 접근권한 관리의 구조를 함께 살펴봤습니다. 진선호 부장은 ‘접근통제의 현재와 다음: 역할에서 속성으로(RBAC → ABAC)’를 주제로 발표하며 한 가지 질문을 던졌습니다. “지금 우리 핵심 시스템에 관리자 권한을 가진 사람이 몇 명인지 바로 답할 수 있나요?” 발표는 그 권한을 왜 갖고 있는지, 누가 승인했는지까지 확인할 수 있어야 한다는 문제로 이어졌습니다.

Tech Day는 구성원들이 각자의 기술 경험을 공유하고, 일상적으로 사용하는 시스템의 원리를 함께 이해하는 자리입니다. 이번 발표도 익숙한 ‘계정’에서 출발해 접근권한을 누가 결정하고 어떻게 유지해야 하는지로 논의를 넓혔습니다.

[Litis TechDay]접근통제의 현재와 다음:역할에서 속성으로

계정은 움직이는데 권한은 남습니다

입사와 발령, 퇴사 정보는 HR 시스템에서 시작해 디렉터리와 애플리케이션으로 전달됩니다. 그러나 계정의 변화가 이전 권한의 회수까지 보장하지는 않습니다. 새 구성원에게 전임자의 권한을 복사하거나, 부서 이동 뒤 새 권한만 추가하면 접근 범위가 누적될 수 있습니다. 발표에서는 정기 접근검토와 계약 종료일에 따른 권한 회수처럼, 계정 관리와 별도로 챙겨야 할 지점을 짚었습니다.

역할이 많아지는 이유는 무엇일까요?

RBAC은 사용자를 역할(Role)에 연결하고, 역할에 권한을 묶어 관리합니다. 이때 Role은 직급이나 부서명과 같지 않습니다. 같은 팀의 같은 직급이라도 맡은 업무에 따라 필요한 기능이 다를 수 있습니다.

조직 범위를 역할 이름에 모두 넣으면 `영업1팀_팀장`, `영업2팀_팀장`처럼 역할이 늘어납니다. 조직개편 때마다 역할과 사용자 매핑을 고치는 부담도 커집니다. NIST 역시 시간이나 조직처럼 변하는 조건을 순수 RBAC으로 표현할 때 생기는 ‘역할 폭발’을 설명합니다.

ABAC은 요청 당시의 속성을 살핍니다

ABAC은 사용자와 자산의 속성, 요청한 행위, 접속 환경을 정책과 비교합니다. 예를 들어 사용자의 부서가 자산 소유 부서와 같고 재직 중일 때만 특정 데이터를 조회하도록 정할 수 있습니다. 이 방식은 조직 이름을 역할마다 반복해서 넣는 일을 줄일 수 있습니다.

발표는 ABAC의 한계도 함께 다뤘습니다. HR 정보나 자산 목록이 틀리면 접근 판단도 틀어집니다. 정책이 복잡해지면 허용 이유를 설명하기 어려워질 수 있습니다. 따라서 기존 역할을 모두 없애기보다, 역할로 기본 권한을 관리하고 필요한 범위에 속성 조건을 더하는 접근이 유용합니다.

권한은 누가 승인했는지 남아야 합니다

권한 모델에 앞서 정해야 할 것은 승인 책임입니다. 발표에서는 자산 소유자가 접근 기준과 승인 여부를 판단하고, IT·보안 조직이 이를 시스템에 적용하는 구조를 강조했습니다. 화면에서 메뉴를 숨기는 것 만으로는 부족하며, API를 직접 호출할 때도 서버가 권한을 확인해야 합니다. 허용·거부 판단과 정기 검토의 기록도 함께 남겨야 합니다.

이번 Tech Day는 신원 정보와 접근 권한이 어떻게 다른지, RBAC과 ABAC을 어떤 문제에 적용할지 구성원들이 함께 생각해 보는 시간이었습니다. Litis는 앞으로도 기술의 개념을 실제 운영의 질문과 연결하며, 서로의 경험을 공유하는 Tech Day를 이어가겠습니다.

출처 및 참고자료

[NIST SP 800-162 - Guide to Attribute Based Access Control]

[NIST·IEEE Computer - Adding Attributes to Role-Based Access Control]