[스프링 시큐리티] 역할기반접근제어(RBAC)와 정책기반접근제어(PBAC)

대분류는 스프링 시큐리티이지만, 이 포스팅에서는 스프링 시큐리티에 대한 내용이 없다.

스프링 시큐리티에 대한 본격적인 이야기는 다음 포스팅에서 할 예정이다.

 

스프링 시큐리티를 프로젝트에 도입하기 전에 알아두면 좋을 배경 지식이니 찬찬히 정리해보았다.

---

 

1. 인증과 권한

1-1) 인증

사용자가 누구인지 확인하는 과정이다.

예를 들어, 아이디와 패스워드, 인증 토큰, 인증서 등으로 신뢰할 수 있는 사용자인지 검증하는 것이다.

 

1-2)권한

인증된 사용자가 무엇을 할 수 있는지 결정하는 과정이다.

주로 역할이나 권한 기반으로 관리한다.

역할: 관리자, 사용자 등.

권한: 읽기, 쓰기, 삭제 등.

 

예시)

네이버 블로그에 내 계정으로 로그인 하면, 내 블로그를 관리할 수 있는 계정 관리에 접근할 수 있다.

그리고 글을 쓸 수 있고 수정할 수도 있다.

타 사용자의 블로그를 들어가면 설정버튼이 안보이고 글을 읽기만 할 수 있다.

내 댓글을 읽고, 쓰고, 삭제할 수 있지만, 다른 사용자의 댓글은 읽기만 할 수 있다.

만약, 모두에게 모든 권한을 준다면 모든 웹사이트가 혼돈의 카오스가 될 것이다.

 

2. 역할 기반 접근제어(RBAC)와 정책기반접근제어(PBAC)

2-1) 역할 기반 접근제어(RBAC)란?

사용자에게 부여된 역할(Role)을 기반으로 리소스 접근 권한을 제어하는 방식이다.

 

예시)

개발자가 일반 사용자, 관리자, 시스템 관리자 역할을 정의했다.

사용자에게 하나 이상의 역할을 부여할 수 있다.

- 일반 사용자 : 자신의 정보를 읽기만 할 수 있다.

- 관리자 : 부서의 데이터를 읽고, 쓸 수 있고 일반 사용자가 업무 승인 요청을 했을 때, 승인을 해줄 수 있다.

- 시스템 관리자 : 모든 데이터에 대한 읽기, 쓰기, 삭제 권한이 있다.

이렇게 역할을 정의하고 사용자에게 역할을 주고 그에 따른 리소스 접근 권한을 주는 것이 역할 기반 접근제어다.

 

💡RBAC를 적용하기 적합한 시스템

RBAC는 역할 체계가 단순하고 권한 변경이 자주 발생하지 않는 시스템에 적합하다.

특정 역할에 대해 모든 리소스나 기능을 고정적으로 허용할 때 간단하게 구현할 수 있다.

다만, 동적으로 권한을 변경하는 일이 잦거나 세분화된 권한을 위해 역할을 지나치게 많이 정의하면 관리 복잡도가 확 오른다..^^

 

2-2) 정책기반접근제어(PBAC)란?

사용자의 접근 권한을 정책(Policy)로 정의해서, 동적으로 접근 여부를 결정하는 접근 제어 방식이다.

정적이고 고정된 역할(Role)에 의존하는 대신, 조건을 종합적으로 고려하여 접근 권한을 판단한다.

 

PBAC를 사용하면 특정 프로세스(ex. 승인 요청, 승인 완료)에 따라 권한을 동적으로 부여할 수 있다.

 

사용자 상태, 접근하려는 리소스, 수행하려는 작업(읽기,쓰기,삭제), 정책(특정 조건), 환경 변수(위치, 시간, IP, 디바이스)등에 따라 권한을 판단할 수 있다.

 

예시)

사용자 상태 기반 : 사용자가 approved 된 이후에만 시스템 핵심 서비스에 접근 가능.

리소스 상태 기반 : 시스템 핵심 서비스에서 승인 요청을 했다면, approved 상태가 되어야 다음 단계 서비스에 접근 가능.

 

💡 PBAC를 적용하기 적합한 시스템

PBAC는 사용자의 상태, 요청의 상태등 다양한 조건에 따라 권한이 달라지는 시스템에 적합하다. 

비즈니스 요구사항(정책)이 자주 변경되어 권한 체계를 빠르게 수정해야 하는 경우, 역할 체계가 복잡하여 다양한 단계로 접근 제어가 필요한 경우에 PBAC를 적용하는 것이 좋다.

 

PBAC는 새로운 조건이나 정책 추가가 RBAC에 비해 쉽기 때문에 확장성이 있다.

또한, 정책을 코드가 아닌 데이터베이스나 정책 서버에 저장하기 때문에, 시스템 재배포 없이 정책을 변경할 수 있다.

다만, 정책 정의가 평가 로직이 복잡할 수 있고, 조건 평가가 많아지면 성능이 저하될 수 있다.

 

2-3) RBAC + PBAC 혼합 접근 제어

기본 역할(RBAC)로 접근 제어를 처리하되, PBAC를 통해 상태 변화와 조건을 반영하는 경우.

승인 시스템이 있는 곳에 적용하기 좋다.

 

 

3. 역할기반접근제어(RBAC)를 RBAC + PBAC로 전환하는 방법

역할은 최소한으로 유지하고 정책과 조건으로 세부 권한을 제어할 수 있다.

 

다만, 이 설계는 테이블 수가 증가하기 때문에 기존 데이터를 마이그레이션 하는데에 시간과 리소스가 필요하고 쿼리 성능에 문제가 생길 수 있다. 쿼리 성능 저하는 캐싱, 인덱스 등으로 해결할 수 있다.

 

환경에 따라 분리된 테이블을 합칠 수 있다. (역정규화?)

조건이나 권한이 복잡해지면 데이터 중복이 발생할 수 있고 한 테이블에서 여러 개념을 관리하게 되어 유지보수가 어려워질 수 있음에 주의해야한다.

 

 

3-1) 기존 데이터 분석

기존 역할에 읽기, 쓰기 등 권한을 포함하여 역할이 세분화되어 있다면 역할(Role)과 권한(Permission)을 분리한다.

역할을 단순화하는 작업이 필요하다.

 

3-2) 권한 분리

읽기, 쓰기, 삭제 등의 권한을 별도로 정의한다.

 

3-3) 정책 추가

조건과 프로세스에 따라 권한을 동적으로 관리할 수 있는 정책을 추가한다.

 

3-4) 데이터 전환

기존 데이터를 새로운 매핑 테이블로 옮긴다.

 

💡 필요한 테이블 개요

✔️ 사용자 테이블

✔️ 역할 및 권한 테이블

✔️ 리소스 테이블

✔️ 정책 테이블

 

 

💡 테이블 이름과 목적

테이블 이름	목적
사용자 (User)	사용자 정보 관리
사용자-역할매핑 (UserRoleMapping)	사용자와 역할 간의 매핑 정보를 관리
역할 (Role)	시스템 내의 역할 정의(ex.관리자, 일반 사용자 등)
권한 (Permission)	시스템 내 수행 가능한 작업 정의(ex. 읽기, 쓰기, 삭제 등)
역할-권한 매핑 (RolePermissionMapping)	역할과 권한 간의 관계 정의
리소스 (Resource)	시스템 리소스(URL, API 등)을 정의
리소스-권한 매핑 (ResourcePermissionMapping)	특정 리소스에 필요한 권한을 정의
정책 (Policy)	정책의 메타 정보 관리(ex. 이름, 설명, 상태 등)
정책 조건 (PolicyCondition)	정책의 조건을 정의(ex. 시간, 사용자 상태 등)
정책-리소스 매핑 (PolicyResourceMapping)	정책과 리소스를 매핑
정책-권한 매핑 (PolicyPermissionMapping)	정책과 권한을 매핑

 

 

4. 권한 처리 프로세스 예시

스프링 시큐리티와 RBAC+PBAC 테이블을 이용해서 권한 처리를 실질적으로 어떻게 하는 지 이해해보자.

 

4-1) 시나리오

✔️사용자 요청

사용자가 특정 리소스(URL)에 대해 작업을 요청한다. 

관리자가 승인하기 전까지는 접근이 제한된다.

 

✔️ 관리자 승인

관리자는 요청 내역을 보고 승인 여부를 결정한다.

관리자가 요청을 승인하면 사용자의 상태를 업데이트한다.

 

위 시나리오를 위해 요청 테이블이 추가로 필요하다.

 

* 요청 테이블(AccessRequest)

컬럼명	타입	설명
request_id	UUID(PK)	요청ID
user_id	FK	요청사용자ID
resource_id	FK	요청리소스ID
action	VARCHAR	요청작업(ex.READ,WRITE,DELETE)
requested_at	TIMESTAMP	요청생성시간
status	ENUM	요청상태(ex.PENDING,APPROVED,REJECTED)
approved_by	FK	승인관리자ID
approved_at	TIMESTAMP	승인 시간

•  

 

4-2) 데이터 흐름

✔️ 사용자 요청

- 사용자가 /admin URL에 WRITE 작업을 요청한다.

- 요청 정보가 요청테이블에 저장된다.

 

✔️ 관리자 승인

- 관리자가 대기 중인 요청을 조회한다.

- 요청을 승인 또는 거부한다.

- 승인 후, 승인된 사용자는 정책 조건에 따라 리소스에 접근이 가능하다.