사전 역할 기반 접근 제어
패턴

역할 기반 접근 제어

gabury1

누가 무엇을 할 수 있는지를 사람마다 정하지 않고 역할에 붙여 두는 방식입니다. 사람에게는 역할만 줍니다. 권한을 손보는 자리가 사람 수만큼이 아니라 역할 수만큼이 됩니다.

상세

흔히 RBAC(Role-Based Access Control)로 줄여 부릅니다. Ferraiolo 와 Kuhn 은 1992년 논문에서 이것을 비임의적 접근 제어의 한 갈래로 소개했습니다. 접근 판정을 사용자가 조직 안에서 수행하도록 허락된 기능에 근거해 내린다고 적습니다. 사용자는 자기 재량으로 접근 권한을 다른 사용자에게 넘길 수 없습니다. 같은 논문은 이것이 임의적 접근 제어(DAC, Discretionary Access Control)와 갈리는 근본 차이라고 적습니다.

역할은 조직의 직무에 대응합니다. 논문이 든 예는 병원에서 개인이 맡을 수 있는 의사·간호사·임상의·약사, 그리고 은행의 창구직원·대출담당자·회계담당자입니다. 논문은 역할을 사용자나 사용자 집단이 조직의 맥락 안에서 수행할 수 있는 트랜잭션의 집합으로 볼 수 있다고 적습니다. 트랜잭션은 시스템 관리자가 역할에 배정합니다. 역할마다 그 역할에 배정된 트랜잭션 묶음이 유지되고, 역할마다 개별 구성원의 집합이 딸립니다. 그래서 개인과 권리 사이의 다대다 관계에 이름을 붙여 기술하는 수단이 됩니다.

Sandhu 와 동료들은 1996년 논문에서 이 구조를 사용자·역할·권한 세 집합과 세션 모음으로 적었습니다. 사용자는 사람입니다. 역할은 조직 안의 직무나 직함이고, 그 역할의 구성원에게 부여되는 권한과 책임에 관한 의미가 딸립니다. 권한은 시스템의 객체 하나 이상에 대한 특정 접근 방식의 승인입니다. 사용자 배정과 권한 배정은 둘 다 다대다 관계입니다. 세션은 한 사용자를 여러 역할에 대응시키는 사상입니다. 사용자가 세션을 열고 그 세션에서 자신이 구성원으로 속한 역할 중 일부를 활성화합니다. 그 세션에서 쓸 수 있는 권한은 활성화된 모든 역할의 권한을 합친 것입니다.

flowchart TD
    U["사용자"] -->|사용자 배정| R["역할"]
    P["권한"] -->|권한 배정| R
    U -->|연다| S["세션"]
    S -->|역할 활성화| R

권한은 역할에만 붙습니다. 사용자에게는 역할만 붙습니다. 사용자가 실제로 무엇을 할 수 있는지는 세션에서 어떤 역할을 활성화했는지로 그때그때 정해집니다.

1992년 논문은 세 가지 기본 규칙을 요구합니다. 역할 배정은 주체가 역할을 골랐거나 배정받았을 때에만 트랜잭션을 실행할 수 있다는 규칙입니다. 활동 중인 모든 사용자는 활성 역할을 하나 가져야 합니다. 역할 인가는 주체의 활성 역할이 그 주체에게 인가된 것이어야 한다는 규칙입니다. 사용자가 인가받은 역할만 맡게 하는 장치입니다. 트랜잭션 인가는 주체의 활성 역할에 인가된 트랜잭션만 실행할 수 있다는 규칙입니다.

대가

이 결정은 직무 하나에 필요한 권한이 한 덩이로 온전히 묶인다고 전제합니다. NIST 의 접근 제어 시스템 평가 보고서는 실제로 역할 설계가 어려운 일로 드러났다고 적습니다. 그리고 이 방식의 난점이 강한 보안과 수월한 관리 사이의 다툼이라고 적습니다. 보안을 세게 하려면 역할이 더 잘게 쪼개져 있어야 하고, 그러면 사용자 한 명이 여러 역할을 갖게 됩니다. 관리 부담을 줄이려면 관리할 역할 수가 적어야 합니다. 같은 문서는 제품들이 때로는 도입하기 까다로운 것으로 드러났고, 일부 조직에서는 규칙 기반을 비롯한 더 오래 검증된 접근 제어 방법과 함께 써야 실용적 가치를 얻는다고 적습니다.

역할이라는 한정자로 못 담는 판정이 있습니다. NIST 의 속성 기반 접근 제어 안내서는 신원과 역할 같은 주체 한정자가 현실의 접근 제어 요구를 표현하기에 부족한 경우가 잦다고 적습니다. 역할 기반 방식은 주체가 어떤 역할에 결부되어 있는지를 보고 판정합니다. 그래서 다요인 판정을 쉽게 받치지 못합니다. 문서가 든 예는 물리적 위치에 따라 달라지는 판정, 그리고 HIPAA(Health Insurance Portability and Accountability Act) 기록 접근처럼 특수 교육 이수를 전제로 하는 판정입니다. 역할 배정은 비교적 정적인 조직 내 직위에 근거하는 경향이 있어서, 동적인 접근 판정이 필요한 일부 구조에서는 어려움이 생긴다고 적습니다. 이런 판정을 굳이 구현하려 들면 임시적이고 구성원이 몇 안 되는 역할을 잔뜩 만들게 되며, 문서는 이것을 흔히 역할 폭발(role explosion)이라 부른다고 적습니다.

직무 분리를 실제로 강제하는 쪽은 제품에서 얇습니다. 평가 보고서는 기존 제품들이 초보적인 직무 분리 기능만 갖고 있다고 적습니다. 정적 직무 분리는 지원되기도 하지만 동적 직무 분리를 제공하는 제품은 아주 적다고 적습니다. 문서가 든 구멍의 예는 이렇습니다. 지출을 기안하는 역할과 승인하는 역할을 직무 분리로 갈라 놓습니다. 나중에 세 번째 역할에 승인 권한이 붙고, 어떤 사용자가 기안 역할과 그 세 번째 역할을 함께 가지면 직무 분리가 깨집니다. 역할 구조에 구멍이 생긴 것입니다. 문서는 한 사람이 어떤 중요 기능을 해내는 데 필요한 권한 전부에 닿을 수 있으면 역할 구조와 무관하게 시스템이 무너질 수 있다고 적습니다. 최소 권한 조건도 여러 속성이나 제약에 맞춰 접근을 재단하기가 어려워서 달성하기 어렵거나 비용이 큰 경우가 잦다고 적습니다.

모델 자체가 원칙을 강제해 주지는 않습니다. 1996년 논문은 이 방식이 정책 중립이면서도 최소 권한과 직무 분리와 데이터 추상화 세 원칙을 직접 받친다고 적습니다. 다만 원칙의 적용을 강제할 수는 없다고 적습니다. 보안 담당자가 그 원칙을 어기도록 설정할 수 있습니다. 같은 논문은 연산의 열을 통제해야 하는 상황에는 더 정교한 형태의 접근 제어가 필요하다고 적습니다. 역할 기반 접근 제어는 그런 사건 열에 대한 권한을 직접 통제하려 하지 않고, 저자들은 그것을 이 방식의 범위 밖으로 본다고 적습니다.

권한을 사용자 재량에서 걷어낸 대가도 있습니다. 평가 보고서는 이 방식이 사용자를 역할에 묶고 그 역할을 객체에 대한 권한과 연결하므로 접근 제어를 사용자나 역할의 재량에 맡기지 않는다고 적습니다. 그래서 임의적 접근 제어 정책을 받치는 데 쓰기는 어렵다고 적습니다. 또한 특정 접근 제어 정책 아래에서 구현되므로 정책을 조합해야 할 때 유연성을 받치기 어렵다고 적습니다.

예시

Kubernetes 의 Role 과 RoleBinding

Kubernetes 문서가 default 네임스페이스에서 파드 읽기 권한을 주는 예로 든 Role 입니다.

YAML
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

rules 한 항목이 어느 API(Application Programming Interface) 그룹의 어느 리소스에 어떤 동사를 허용하는지 정합니다. 빈 문자열은 코어 API 그룹을 가리킵니다. 여기서 허용되는 동사는 get 과 watch 와 list 셋입니다. 이 Role 은 아직 아무에게도 붙어 있지 않습니다. 권한 묶음만 만들어 둔 상태입니다.

사용자 배정은 RoleBinding 이 합니다.

YAML
apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
  name: jane # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

subjects 가 사용자 쪽이고 roleRef 가 역할 쪽입니다. 이 바인딩은 pod-reader 역할을 default 네임스페이스의 사용자 jane 에게 줍니다. 문서는 subjects 에 하나 이상을 지정할 수 있고 roleRef 의 kind 는 Role 이나 ClusterRole 이어야 하며 name 이 붙이려는 역할 이름과 일치해야 한다고 주석으로 적습니다. 권한 목록은 jane 쪽 어디에도 적히지 않습니다.

PostgreSQL 의 역할 멤버십

PostgreSQL 은 데이터베이스 접근 권한을 역할이라는 개념으로 관리합니다. 공식 문서는 역할을 데이터베이스 사용자로도, 데이터베이스 사용자의 그룹으로도 볼 수 있다고 적습니다. 역할은 테이블과 함수 같은 데이터베이스 객체를 소유할 수 있고, 그 객체에 대한 권한을 다른 역할에 배정할 수 있습니다. 한 역할의 멤버십을 다른 역할에 부여하는 것도 됩니다. 8.1 이전 판에서는 사용자와 그룹이 별개 종류였지만 지금은 역할만 있습니다.

멤버십을 주고 거두는 명령은 GRANT 와 REVOKE 입니다.

GRANT role_name [, ...] TO role_specification [, ...]
    [ WITH { ADMIN | INHERIT | SET } { OPTION | TRUE | FALSE } ]
    [ GRANTED BY role_specification ]

문서가 든 실제 예입니다.

SQL
CREATE ROLE joe LOGIN;
CREATE ROLE admin;
CREATE ROLE wheel;
CREATE ROLE island;
GRANT admin TO joe WITH INHERIT TRUE;
GRANT wheel TO admin WITH INHERIT FALSE;
GRANT island TO joe WITH INHERIT TRUE, SET FALSE;

joe 로 접속한 직후의 세션은 joe 에게 직접 부여된 권한에 더해 admin 과 island 의 권한을 씁니다. 그 둘은 INHERIT 로 물려받기 때문입니다. wheel 의 권한은 쓰지 못합니다. joe 가 admin 을 거쳐 간접적으로 wheel 의 구성원이기는 하지만, 그 멤버십이 WITH INHERIT FALSE 로 부여됐기 때문입니다. 문서는 SET 옵션으로 멤버십을 받은 역할은 SET ROLE 로 일시적으로 그 그룹 역할이 될 수 있고, INHERIT 옵션으로 받은 역할은 직접이든 간접이든 자신이 속한 역할의 권한을 자동으로 쓰되 INHERIT 이 없는 멤버십에서 그 사슬이 끊긴다고 적습니다.

갈래

1996년 논문은 네 개의 개념 모델을 패밀리로 정의했습니다. 기본 모델에 무엇을 더하느냐가 축입니다. RBAC0 이 맨 아래 있고 RBAC1 과 RBAC2 가 각각 독립된 기능을 얹습니다. 논문은 이 둘을 진보 모델이라 부르고 서로 비교 불가라고 적습니다. RBAC3 이 둘을 합칩니다.

RBAC0

기본 모델입니다. 논문은 이것을 역할 기반 접근 제어를 지원한다고 표방하는 시스템이 갖춰야 할 최소 요건이라고 적습니다. 사용자·역할·권한 세 집합과 세션 모음이 있고, 권한을 역할에 잇는 권한 배정과 사용자를 역할에 잇는 사용자 배정이 둘 다 다대다 관계입니다.

세션은 한 사용자에 대응하고 그 대응은 세션이 사는 동안 바뀌지 않습니다. 세션이 활성화한 역할 집합은 시간에 따라 바뀔 수 있습니다.

RBAC1

역할 계층을 더합니다. 역할이 다른 역할의 권한을 물려받는 상황을 다룹니다. 논문은 역할 계층을 조직의 지휘 계통과 책임 계통을 반영해 역할을 구조화하는 자연스러운 수단이라고 적습니다. 관례상 더 강한 상위 역할을 도표 위쪽에, 덜 강한 하위 역할을 아래쪽에 그립니다. 논문이 든 예에서 의사 역할은 의료 제공자보다 상위이고 그래서 의료 제공자 역할의 권한을 전부 물려받습니다. 수학적으로 이 계층은 부분 순서입니다.

flowchart TD
    D["의사"] -->|권한을 물려받음| H["의료 제공자"]

실제 제품에서 이 계층을 켜고 끄는 자리가 PostgreSQL 의 INHERIT 옵션입니다.

RBAC2

제약을 더합니다. RBAC0 과 나머지는 같고, 구성 요소들의 값이 받아들여질 수 있는지 판정하는 제약 모음을 요구합니다. 받아들여지는 값만 허용됩니다. 논문은 제약이 이 방식의 중요한 측면이고 때로는 이 방식의 주된 동기로 주장되기도 한다고 적습니다.

가장 자주 언급되는 제약은 상호 배타 역할입니다. 한 사용자는 상호 배타 집합 안에서 최대 하나의 역할에만 배정될 수 있고, 이것이 직무 분리를 받칩니다. 논문이 든 예는 구매 관리자와 미지급금 관리자입니다. 같은 사람이 두 역할의 구성원이 되면 부정을 저지를 가능성이 생깁니다. 다른 제약으로는 역할이 가질 수 있는 구성원 수의 상한을 정하는 기수 제약, 그리고 역할 B 의 구성원인 사용자만 역할 A 에 배정할 수 있게 하는 선행 역할이 있습니다.

RBAC3

RBAC1 과 RBAC2 를 합쳐 역할 계층과 제약을 둘 다 제공합니다. 논문은 이행성에 의해 RBAC0 도 포함한다고 적습니다.

관련 항목

이 결정이 딛는 원칙

최소 권한 · 직무 분리 · 데이터 추상화

나란히 놓이는 접근 제어 방식

임의적 접근 제어 · 강제적 접근 제어 · 접근 제어 목록 · 속성 기반 접근 제어 · 규칙 기반 접근 제어(Rule-Based Access Control)

모델을 이루는 구성 요소

역할 계층 · 상호 배타 역할 · 기수 제약 · 선행 역할 · 세션 · 권한

이 결정이 속하는 상위 분류

인증과 인가 · 보안 엔지니어링 · 비임의적 접근 제어(Non-Discretionary Access Control, NDAC)

이 결정에서 자주 나는 문제

역할 폭발 · 권한 상승

이것을 구현했거나 채택한 제품·회사

Kubernetes · PostgreSQL · IBM · Sybase · Secure Computing · Siemens

다른 이름: RBAC · Role-Based Access Control · role based access control · Role Based Access Control · 역할기반 접근제어

이 용어를 쓴 노트 1

AWS 05-1 누가 무엇을 할 수 있나 — IAM·IAM Identity Center·Cognito·Verified Permissions