RBAC (Role-Based Access Control)

RBAC

사용자당 Identity 를 따지는게 아닌, 속해있는 역할에 따라서 접근 권한을 부여한다.
(역할이 허용되는 권한들을 가지고 있는다)

사용자 -> 역할 -> 권한 의 3계층 매핑

• 사용자 : User, 시스템을 사용하는 사용자
• 역할 : Role, 권한들을 묶은 집합
• Permission : 개별 동작, READ_ELEMENT, DELETE_ELEMENT

RBAC 유형

• RBAC0 : Flat, Role -> Permission 단순 매핑

특정 Role 이 그냥 권한을 가지고 있는 가장 기본적 형태

VIEWER: `READ_ELEMENT`, `READ_MEMBER` ...
MEMBER: `WRITE_ELEMENT`, `INVITE_MEMBER`

• RBAC1 : Hierarchical, 상속

Role 간 상속을 하는 형태

VIEWER → MEMBER → ADMIN → ROOT

하위 요소가 가지는 권한에 자신의 권한을 더해가는 형태

• RBAC2 : Constrained, 상호 배타 조약

한 사용자가 동시에 권한을 부여 받지 않게 설정할 수 있다.
EX) 금융 시스템에서 결제 요청자 & 결제 승인자는 동시 부여 받을 수 없다.

굳이 필요할까...? 싶긴 하지만, 세세하게 제약을 걸어야 할 때 필요할 거 같다.

• RBAC3 : Symmetric, 대칭 조약

RBAC1 과 RBAC2 를 결합한 형태이다.
-> 계층 상속을 따르면서, 상호 배타 제약 조건을 만족해야 한다.

꼭 하나만 따를 필요는 없다.
RBAC0 과 RBAC1 을 결합해서 사용해도 문제될 건 없다.

간단한 원칙

• 최소 권한 원칙 : 사용자의 업무에 필요한 최소한의 권한만 부여해야 한다.

특정 요소에 대한 권한이 필요하다면?
특정 요소 관련 권한만 제공해주는게 사고 위험 을 방지할 수 있다.

• 권한 체크 레이어 중첩 : 한 곳에서만 처리하려고 하면, 우회가 되거나 놓칠 수 있다.

EX) Spring Security 가 알아서 해주겠지? ALB 가 알아서 해주겠지??

비즈니스 적으로 중요한 데이터나, 로직 이라면?
로직 레이어에서도 검증을 한번더 하자.

언제나 그렇듯, 코드의 깔끔한 보단 안정성과 실제로 동작을 하는지가 1순위다.

• 네이밍 컨벤션 : 동사_리소스 형태로 작성하자.

Spring Security 관례이다
READ_ELEMENT, DELETE_ELEMENT ...

리소스:동사 형태는 좀 더 복잡하거나 Scope 형태의 구조에서 사용하는거 같다. (AWS IAM, OAuth Scope...)

element:read, element:delete, element:patch