콘텐츠로 이동

RBAC 설계 — 역할을 어떻게 조직하고 제약할까

핵심 RBAC가 "사용자-역할-권한"을 잇는 기본이라면, 실무에서는 역할이 많아질수록 관리가 복잡해져요. 역할이 수십 개로 불면 "누가 뭘 할 수 있는지"를 일일이 보기 어렵거든요. 그래서 NIST 모델은 계층(상속)과 제약을 통해 역할을 조직적으로 설계하는 방법을 제시해요.

개요

RBAC 설계의 두 축은 역할 계층(Hierarchy)과 제약(Constraints)이에요. 계층은 겹치는 권한을 상속으로 묶어 관리의 중복을 줄이고, 제약은 위험한 조합(예: 상충하는 권한을 한 역할이 갖는 것)을 못 하게 막습니다.

핵심 개념

역할 계층과 권한 상속. 역할은 다른 역할의 권한을 상속할 수 있어요. 상위 역할은 하위 역할이 가진 권한을 물려받죠. 예를 들어 "편집자"가 "뷰어"의 권한(읽기)을 포함한다면, 편집자는 읽기까지 자동으로 할 수 있어요. 이러면 공통 권한을 최하위 역할에 한 번만 두고 나머지는 그 위로 쌓을 수 있어요.

관리자 (편집자 + 관리 기능)
  └── 편집자 (뷰어 + 쓰기)
        └── 뷰어 (읽기)

상속은 편리하되 전파를 조심해요. 하위 역할에 어떤 권한을 추가하면 그 위 모든 역할에 전파돼요. 그래서 계층을 설계할 때 "상위 역할이 예상 밖의 권한을 물려받지는 않는지"를 확인해야 해요. 상속이 과하면 의도치 않게 넓은 권한이 생길 수 있어요.

제약(Constraints)으로 위험한 조합을 막아요. 가장 대표적인 게 직무 분리(SoD)예요. 상충하는 권한(예: 청구를 만드는 권한과 승인하는 권한)을 같은 역할이 갖지 못하게 하고, 경우에 따라 같은 사람이 두 역할을 동시에 활성화하지 못하게도 해요. 세션 제약으로 "한 번에 활성화할 수 있는 역할 수"를 제한하는 것도 제약의 한 형태예요.

역할 설계는 직무(기능) 중심으로. 사람이나 직함이 아니라 업무 기능을 기준으로 역할을 나누는 게 좋아요. 역할은 서비스의 접근 지도가 되므로, 기능이 바뀔 때 역할도 함께 재검토돼야 해요.

실제 적용(데이터스케쳐스)

역할이 늘어날 때 계층으로 공통 권한을 묶고, 위험한 조합은 직무 분리 제약으로 막아 설계해요. 예를 들어 고객 데이터를 보는 역할과 그 데이터를 삭제·이관하는 역할을 분리해, 한 역할이 너무 많은 것을 다루지 않게 해요.

테넌트 단위로 역할을 나눌 때도 계층을 테넌트 안에서만 적용하고, "남의 테넌트 권한"이 상속으로 전파되지 않게 객체(데이터) 범위를 테넌트와 함께 고정해요. 역할 목록을 코드/설정으로 관리하고 변경 이력을 남기면, 감사 시점에 어떤 역할 계층이었는지 되짚을 수 있어요.

더 알아보기