권한 시스템 설계

권한 시스템은 보통 하나의 모델만 고집하면 운영이 어려워져서,

실무에서는 RBAC + ACL + 일부 ABAC를 섞는 방향이 가장 안정적이고 무난하다.

기본은 RBAC
세부 데이터 제어는 ACL
조건 판단은 ABAC

 

OWASP도 최소 권한 원칙과 서버 측 접근제어를 강조하고, NIST RBAC 모델도 사용자-역할, 역할-권한의 다대다 구조를 기본으로 본다.

1. 추천 구조

USER
 ↓
USER_ROLE
 ↓
ROLE
 ↓
ROLE_PERMISSION
 ↓
PERMISSION

 

그리고 데이터 단위 권한이 필요하면:

RESOURCE_ACL

 

을 추가한다.

2. 기본 테이블

 

USER
- user_id
- login_id
- user_name
- dept_id
- status

ROLE
- role_id
- role_code   -- ADMIN, MANAGER, USER
- role_name

PERMISSION
- permission_id
- permission_code -- ORDER_READ, ORDER_UPDATE
- permission_name

USER_ROLE
- user_id
- role_id

ROLE_PERMISSION
- role_id
- permission_id

 

3. ACL 테이블

본인 글만 수정, 특정 문서 공유 같은 경우.

 

RESOURCE_ACL
- acl_id
- resource_type   -- POST, FILE, ORDER
- resource_id
- subject_type    -- USER, ROLE, DEPT
- subject_id
- permission_code -- READ, UPDATE, DELETE

 

예:

문서 100번
- hoon: READ, UPDATE
- ADMIN: READ, UPDATE, DELETE

 

4. ABAC는 코드/정책으로 처리

예:

주문 수정 가능 조건:
- ORDER_UPDATE 권한 있음
- 같은 매장 데이터
- 마감 전 상태

 

이건 테이블 권한만으로 끝내기보다 서비스 로직에서 검사하는 게 실무적으로 좋다.

 

if (!auth.hasPermission("ORDER_UPDATE")) {
    throw new AccessDeniedException("권한 없음");
}

if (!order.getStoreId().equals(loginUser.getStoreId())) {
    throw new AccessDeniedException("다른 매장 데이터 접근 불가");
}

if (order.isClosed()) {
    throw new AccessDeniedException("마감된 주문 수정 불가");
}

 

5. API 권한은 Permission 기준으로

Role로 직접 막기보다 권한 코드 기준이 더 좋다.

좋은 예:

 

@PreAuthorize("hasAuthority('ORDER_UPDATE')")

 

 

 

나쁜 예:

 

@PreAuthorize("hasRole('ADMIN')")

 

 

이유는 나중에 MANAGER에게도 주문 수정 권한을 주고 싶을 때, Role이 아니라 Permission 매핑만 바꾸면 되기 때문.

6. 최종 판단 흐름

1. 로그인 여부 확인        → 인증
2. API 권한 확인          → RBAC Permission
3. 데이터 소유/범위 확인   → ACL 또는 ABAC
4. 업무 상태 확인         → ABAC

 

결론

가장 추천하는 설계는 이거야.

USER - ROLE - PERMISSION 구조를 기본으로 두고,
"본인 데이터/공유 문서/매장별 데이터"는 ACL 또는 조건 검사로 보완한다.

 

즉, RBAC만으로 끝내지 말고 Permission 중심 RBAC + 데이터 범위 검증까지 넣어야 실무에서 안전하다.

 

종류	저장 위치
로그인 여부	세션/JWT
ROLE_ADMIN	세션/JWT
메뉴 권한	Redis/세션
API 권한	Redis/세션
데이터 권한(store_id)	DB WHERE 조건
주문 상태(closed)	DB 조회 결과

* 메뉴 상세 권한은 로그인시 캐싱 하거나 Redis 캐시 혹은 매 요청시 DB조회하는 방법이 있다. 서비스의 규모와 성격에 따라 어디에서 어떻게 관리하고 조회할지가 달라진다.