롤

롤은 권한을 사람마다 따로 주지 않고 한 묶음으로 건네게 해 줍니다. 계정에 롤 하나를 주면 그 안에 든 권한을 한꺼번에 받습니다. 데이터베이스와 쿠버네티스와 클라우드가 모두 이 이름을 씁니다. 뜻의 줄기는 같고 쓰는 방식이 조금씩 다릅니다.

상세

회사에서 누군가 회계 담당이 되면 회계 담당이 드나드는 방의 문이 다 열립니다. 출입 목록은 사람마다 적혀 있지 않고 직책마다 적혀 있습니다. 담당이 바뀌면 직책만 옮겨 주면 됩니다.

롤(role)은 권한 여러 개를 한 이름으로 묶어 계정에 건네는 단위입니다. 우리말로는 역할이라고도 합니다. 여기서 권한은 「이 테이블을 읽어도 된다」 같은 허락 한 건입니다. 주문 테이블과 회원 테이블을 읽는 권한을 analyst 롤에 넣어 두면, 분석 담당 계정 셋에는 이 롤만 주면 됩니다.

롤을 받는 쪽은 사용자 계정입니다. 사용자 계정은 시스템이 요청을 낸 쪽이 누구인지 알아보려고 만들어 두는 기록입니다. 계정 하나가 롤을 여럿 받을 수도 있습니다. 그때 계정이 쓸 수 있는 권한은 받은 롤들에 든 권한을 모두 합친 것입니다.

권한을 사람에게 바로 주지 않고 롤에 붙여 관리하는 방식이 역할 기반 접근 제어(Role-Based Access Control, RBAC)입니다. 롤은 이 방식의 중심에 있는 부품입니다.

롤이 없을 때 늘어나는 부여 건수

분석 담당이 열 명이고, 이들이 읽어야 할 테이블이 스무 개라고 합시다. 권한을 계정마다 직접 주면 열 명에게 스무 건씩, 모두 200건을 줘야 합니다. 사람 수와 테이블 수를 곱한 만큼입니다.

롤을 두면 곱이 합으로 바뀝니다. 롤 하나에 읽기 권한 스무 건을 넣습니다. 열 명에게는 롤을 한 건씩 줍니다. 모두 30건입니다.

차이는 무언가 바뀔 때 더 크게 벌어집니다. 아래 표는 흔히 생기는 변경 셋을 두 방식으로 견준 것입니다.

직접 주는 방식에서는 한 건만 빠뜨려도 구멍이 납니다. 새 테이블을 한 사람에게만 못 열어 주거나, 떠난 사람에게 권한 하나가 남습니다. 롤을 두면 고칠 곳이 한 군데로 모입니다.

아래 그림은 롤을 둔 모양입니다. 계정 셋이 롤 하나를 받고, 롤이 권한 셋을 품습니다. 계정과 권한 사이에 직접 이어진 선이 없습니다.

flowchart TD
    subgraph 계정
        K["kim"]
        L["lee"]
        P["park"]
    end
    R["롤 · analyst"]
    subgraph 권한
        A["주문 테이블 읽기"]
        B["회원 테이블 읽기"]
        C["상품 테이블 읽기"]
    end
    K --> R
    L --> R
    P --> R
    R --> A
    R --> B
    R --> C

데이터베이스에서 롤을 쓰는 순서

관계형 데이터베이스에서는 SQL(Structured Query Language) 문장 몇 줄로 롤을 다룹니다. 제품마다 문법이 조금씩 다르지만 뼈대는 아래 네 줄과 같습니다. 네 줄은 세 걸음입니다. 순서는 롤 만들기, 롤에 권한 두 건 넣기, 계정에 롤 주기입니다.

CREATE ROLE analyst;     -- 롤을 만든다
GRANT SELECT ON orders   -- 롤에 권한을
  TO analyst;
GRANT SELECT ON members  -- 하나 더
  TO analyst;
GRANT analyst TO kim;    -- 계정에 롤을

GRANT 는 무언가를 주는 명령입니다. 앞의 두 번은 롤에 테이블 읽기 권한을 줍니다. SELECT 가 읽기를 뜻합니다.

마지막 한 번은 권한이 아니라 롤 자체를 계정 kim 에게 줍니다. 같은 명령이 권한도 주고 롤도 줍니다.

거둬들일 때는 REVOKE 를 씁니다. kim 이 팀을 떠나면 REVOKE analyst FROM kim; 한 줄로 롤에 든 권한이 한꺼번에 빠집니다.

어떤 데이터베이스는 계정과 롤을 따로 두지 않습니다. 모두 롤로 둡니다. 로그인할 수 있는 롤이 곧 계정입니다. 이런 제품에서는 「사용자를 만든다」와 「로그인할 수 있는 롤을 만든다」가 같은 일입니다.

롤 안의 롤

롤은 계정에게만 줄 수 있는 것이 아닙니다. 롤을 다른 롤에게 줄 수도 있습니다. 그러면 받은 쪽 롤이 건네진 롤의 권한을 물려받습니다. 이것이 롤 상속입니다.

예를 들어 reader 롤에는 읽기 권한을, writer 롤에는 쓰기 권한을 넣습니다. 그리고 reader 를 writer 에게 줍니다. 이제 writer 를 받은 계정은 쓰기와 읽기를 둘 다 할 수 있습니다. 쓰기 권한이 있는데 읽지 못하는 일이 드물어서 이렇게 쌓는 경우가 많습니다.

아래 그림에서 화살표는 가진 것을 가리킵니다. 계정이 롤을 가지고, 롤이 권한과 다른 롤을 가집니다.

flowchart TD
    W["롤 · writer"] --> WR["쓰기 권한"]
    W --> R["롤 · reader"]
    R --> RR["읽기 권한"]
    U["계정 · kim"] --> W

그림에서 kim 은 writer 하나만 받았습니다. 그런데 화살표를 따라 내려가면 읽기 권한까지 닿습니다. 계정이 쓸 수 있는 권한은 이렇게 닿는 권한을 모두 합친 것입니다.

롤이 속하는 범위

테이블은 스키마 안에 들어 있습니다. 스키마는 테이블 여럿을 한 이름 아래 모아 두는 이름 공간입니다.

롤은 스키마 안에 들지 않습니다. 그래서 롤 하나가 여러 스키마의 테이블에 두루 권한을 받을 수 있습니다. analyst 가 주문 스키마의 테이블과 회원 스키마의 테이블을 함께 읽는 식입니다.

롤을 어디까지 나눠 쓰는지는 제품마다 다릅니다. 어떤 제품은 서버 하나가 롤 목록 하나를 둡니다. 그 서버의 모든 데이터베이스가 이 목록을 나눠 씁니다. 데이터베이스마다 롤을 따로 두는 제품도 있습니다.

롤을 두는 대가

첫째 대가는 계정이 무엇을 할 수 있는지가 한눈에 안 보인다는 것입니다. 계정에는 롤 이름만 붙어 있어서 실제 권한을 알려면 롤을 열어 봐야 합니다. 그 롤이 품은 롤까지 따라 내려가야 합니다. 상속이 깊어질수록 이 일이 길어집니다.

둘째는 롤이 넓어지기 쉽다는 것입니다. 한 사람이 권한 하나가 더 필요하다고 하면, 그 사람의 롤에 넣는 것이 제일 빠릅니다. 그러면 같은 롤을 받은 모든 계정이 그 권한을 함께 받습니다. 일에 꼭 필요한 만큼만 주자는 최소 권한 원칙과 멀어집니다.

셋째는 반대 방향의 문제입니다. 롤을 넓히지 않으려고 조금씩 다른 롤을 계속 만들면 롤 수가 계정 수만큼 불어납니다. 그러면 롤로 묶은 이득이 사라집니다. 이런 상태를 흔히 role explosion 이라고 합니다.

그래서 계정이 한둘이고 권한이 거의 안 바뀌는 시스템에서는 롤 없이 계정에 직접 주는 쪽이 더 단순합니다. 롤은 계정과 권한이 늘고 자주 바뀔수록 값을 합니다.

롤이라는 이름의 여러 쓰임

롤이라는 낱말은 데이터베이스 밖에서도 쓰입니다. 대부분은 데이터베이스의 롤과 같은 권한 묶음입니다. 뜻이 조금 비껴가는 곳과 이름만 같은 곳도 있어서 아래 표로 가릅니다.

클라우드 쪽을 조금 더 봅니다. 여기서는 신원이라는 말을 씁니다. 신원은 시스템이 요청을 낸 쪽을 알아보는 이름입니다. 사용자 계정도 신원의 하나입니다.

AWS IAM(Amazon Web Services Identity and Access Management)의 롤은 주인이 없는 신원입니다. 서버나 함수 같은 프로그램이 필요할 때 그 롤을 넘겨받습니다. 넘겨받은 동안에만 그 롤의 이름으로 요청을 내고 롤에 적힌 권한을 씁니다.

데이터베이스의 롤은 계정에 붙어 계정이 쓸 권한을 늘립니다. 클라우드의 롤은 프로그램이 잠깐 그 롤의 이름으로 행세하게 해 줍니다.

Ansible 같은 설정 관리 도구의 롤은 권한과 관계가 없습니다. 웹 서버 설치나 방화벽 설정처럼 서버에 할 일을 묶어 다시 쓰려고 붙인 이름입니다. 같은 낱말이 나와도 문맥이 접근 제어가 아니면 이 뜻일 수 있습니다.

관련 항목

롤이 묶어 건네는 권한과 받는 주체

권한 · 사용자 계정 · 서비스 계정 · 그룹 · 주체 · 대상 · 소유자

롤을 다루는 SQL 명령

CREATE ROLE · GRANT · REVOKE · SET ROLE · ALTER ROLE

롤로 권한을 관리하는 접근 제어 방식

역할 기반 접근 제어 · 접근 제어 · 속성 기반 접근 제어 · 접근 제어 목록 · 임의적 접근 제어 · 강제적 접근 제어

롤을 설계할 때 지키는 원칙

최소 권한 원칙 · 직무 분리 · 권한 상승 · 인가 · 인증

롤이 권한을 거는 데이터베이스 객체

데이터베이스 · 스키마 · 테이블 · 뷰 · 데이터베이스 클러스터

롤이라는 이름을 쓰는 다른 도구와 그 부품

쿠버네티스 RBAC · ClusterRole · AWS IAM · 신뢰 정책 · 임시 자격 증명 · 설정 관리 · Ansible