인가와 권한 관리 : 권한 기반 접근 제어

- 인가와 권한 기반 접근 제어의 개념

- 역할 기반 접근 제어(RBAC)의 구성 요소(사용자, 역할, 권한, 리소스, 행위)를 정의하고 연결하기

- 작은 애플리케이션을 가정한 프레임워크 비종속(Java) 예를 통한 권한 설계, 구현 방법

- 권한 검증 워크플로우를 PEP/PDP 관점과 머메이드 다이어그램으로 이해

- 최소 권한, 기본 거부, 로깅/감사 등 팁

---

권한 기반 접근 제어 개념

권한 기반 접근 제어는 "인증된 주체가 어떤 리소스에 어떤 행위를 할 수 있는가"를 규칙적으로 명시하고, 요청시 규칙에 따라 허용/거부를  결정하는 체계임

 - 인증(Authentication) : 사용자가 누구인지 식별함

 - 인가(Authorization) : 식별된 사용자가 무엇을 할 수 있는지 결정함

 

1. 용어

용어	의미	예시
사용자(User)	시스템을 이용하는 주체	B1uffer, Alice, Bob
역할(Role)	사용자의 업무 묶음	ADMIN, EDITOR, VIEWER 등
권한(Permission)	특정 리소스에 대한 행위 허용 규칙	POST:READ, POST:WRITE 등
리소스(Resource)	보호 대상	게시글(Post), 파일(File), 주문(Order) 등
행위(Action)	리소스에 대한 조작	READ, CREATE, UPDATE, DELETE 등
정책(Policy)	조건이 있는 권한 규칙	본인 소유 글만 UPDATE 허용하기

 

 

 

2. RBAC(역할 기반)의 핵심

RBAC는 사용자(User) - 역할(Role) - 권한(Permission)을 맵핑한다.

사용자는 역할을 부여받고, 역할에 권한을 부여하는 형태

RBAC(역할 기반 접근 제어)

 

RBAC를 선택하는 이유

 - 관리가 용이함 : 사용자의 수가 많아도 역할 단위로 권한을 변경하면 끝임

 - 일관성 : 비슷한 사용자들에게 동일한 정책을 적용하기 쉬움

 - 감사가 용이함 : "이 역할을 어떠한 권한을 갖는가?"에 대한 답이 빠르게 나온다

 

* ACL은 리소스 주체별 목록, ABAC는 속성 기반(시간, 부서, 위치 등) 이라고 한다

---

권한 설계와 구현 방법

1. 권한 설계와 5대 원칙

원칙	설명	체크 질문
최소 권한(Least Privilege)	필요한 최소 권한만 부여함	이 역할이 이런 기능이 없이도 업무가 가능한가?
기본 거부(Default Deny)	명시적으로 허용된 것만 허용함	정책이 없을 때 기본값은 거부인가?
책임 분리 (Separation of Duties)	서로 충돌 가능한 권한을 분리함	생성과 승인 권한이 같은 사람에게 있지 않나?
감사 가능성(Auditability)	누가/무엇을/왜 했는지 추적 가능해야함	로그에 정책 키와 사유가 남는가?
단순성 우선(Keep It Simple)	정책은 이해, 검토, 운영이 쉬워야 함	정책 문서만 보고도 신입이 이해할 수 있나?

 

* 권한은 추가보다 회수가 어렵다. 초기에 보수적으로 설계하고 필요한 경우 점진적으로 허용을 넓힐 수 있음

 

 

 

2. 도메인 인벤토리 : 리소스, 행위 목록화

권한 설계는 도메인을 리소스와 행위로 쪼개는 일에서 시작한다.

# 도메인 인벤토리 예시
리소스(Resource)     : POST, COMMENT, FILE, ORDER
행위(Action)         : READ, CREATE, UPDATE, DELETE, EXPORT
상태(State)          : DRAFT, PUBLISHED, ARCHIVED, DELETED
소유(Ownership)      : OWNER, TEAM, ORG, PUBLIC

 

리소스	핵심 속성	민감도	비교
POST	ownerId, status	중간	소유자의 개념이 중요함
FILE	ownerId, size, type	높음	다운로드/외부공유 고려
ORDER	buyerId, amount, state	높음	정산/환불 플로우 존재

 

* 누가(주체) 어떤 리소스에 어떤 행위를, 어떤 조건(상태, 소유, 시간, 위치)에서 하는가?

 

 

 

3. 역할(Role) 도출 방법

 1) 업무 단위로 묶기 : 실사용자의 업무 시나리오에서 공통 행위를 묶어서 역할 후보를 만듬

 2) 최소 공통권한과 확장 권한을 분리하기

 3) 충돌 권한 분리 : 생성자와 승인자를 분리하는 등 SoD 적용하기

     * SoD(Segregation of Duties, 직무 분리)

사용자	주요 목표	역할 후보
콘텐츠 작성자	초안 작성, 수정	EDITOR
검수자	퍼블리시 승인, 회수	REVIEWER
열람자	읽기 전용	VIEWER
운영 관리	정책, 역할 관리	ADMIN

 

* 역할 수는 작게 시작하고, 필요시 세분화하기(과도한 역할은 운영 복잡도가 급증한다)

 

 

 

 

4. 권한 매트릭스 작성하기(Roles x Resources x Actions)

가장 중요한 '산출물'

역할\리소스:행위	POST\:READ	POST\:CREATE	POST\:UPDATE	POST\:DELETE	FILE\:EXPORT
VIEWER	공개만 O	X	X	X	X
EDITOR	O	O	O(소유자만)	X	X
REVIEWER	O	X	O(승인 전에 검수)	O(규정에 한함)	X
ADMIN	O	O	O	O	O

 

역할\리소스:행위	POST\:READ	POST\:CREATE	POST\:UPDATE	POST\:DELETE	FILE\:DELETE
일반회원	O	O	O(내것만)	O(내것만)	X
관리자	O	O	O	O	O

 

* 역할로 허용된 행위 위에 정책 조건을 겹쳐서 최종 허용이 결정된다

 

 

 

 

5. 정책(Policy) 조건 설계 : RBAC의 한계 보완

• 소유 기반 : POST.UPDATE는 userId == ownerId 일때만 허용하기
• 상태 기반 : POST.DELETE는 status == DRAFT 일때만 허용하기
• 시간/위치 기반(선택) : EXPORT는 근무 시간(9~18) 내 사내망에서만 허용하기
• 리스크 기반(선택) : 고액 ORDER.REFUND는 2인 이상 승인이 필요하게 하기

정책은 역할 권한을 필터링하거나 추가 제약을 주는 형태로 동작한다

 

 

 

6. 정책 문서화 포맷(예시)

실무에서는 사람이 읽고 리뷰하기 쉬운 포맷을 권장한다고 함

# 정책 정의 예시
resource: POST
rules:
  - id: post_update_owner_only
    when:
      action: UPDATE
      role: [EDITOR, REVIEWER]
    condition:
      expression: user.id == resource.ownerId
    effect: PERMIT

  - id: post_delete_only_draft
    when:
      action: DELETE
      role: [REVIEWER, ADMIN]
    condition:
      expression: resource.expression == 'DRAFT'
    effect: PERMIT

  - id: tenant_isolation
    when:
      action: [READ, CREATE, UPDATE, DELETE]
      role: [*]
    condition:
      expression: user.tenantId == resource.tenantId
    effect: PERMIT

  - id: delete_deny
    effect: DENY # 위 규칙과 매칭되지 않으면 거부하기

 

* 사람이 리뷰 가능해야 하며, 정책 키(id)는 로그/감사와 연결된다고 한다.

 

 

 

7. 권한 검증 워크플로우

정책 권한 워크플로우

https://b1uffer.tistory.com/361

---

권한 검증 플로우

1. 요청 처리 흐름

위와 비슷한 권한 검증 워크플로우

권한이 없으면 바로 403, 있으면 조건이 충족하지 않을 경우 403이고 있다면 로직 실행 후 200 반환

 

* 일련의 과정은 모두 '인증' 이후에 이루어져야 한다.

 

 

 

2. 테스트 시나리오

케이스	사용자 역할	리소스 소유자	요청 행위	기대 결과
1	EDITOR	본인	UPDATE	허용(200)
2	VIEWER	타인	UPDATE	거부(403)
3	VIEWER	본인	READ	허용(200)
4	권한이 없음	본인(비회원)	CREATE	거부(403)

---

팁

* 최소 권한 원칙(PoLP) : 기본은 읽지만, 쓰기는 필요한 역할에만 권한을 주기

* 권한 명세서를 산출물로 관리하기(스프레드시트 등등..) : 역할 - 권한 목록, 변경 이력, 승인자 등

* 감사/로깅 : 403 발생 시 정책 키, 리소스 ID, 사용자 ID를 함께 남겨 분석 가능하게끔 하기

* 성능 : 역할 권한은 캐시, 정책 판단은 조건만 캐시하기(과도한 캐시 금지)

* 국소성 : 컨트롤러, 서비스 초입의 단일 PEP에서 일괄 검사하기(중복 로직 방지)

---

정리

항목	핵심
RBAC 기본	사용자 -> 역할 -> 권한 맵핑으로 관리를 단순하게 하기
정책 분리	RBAC로 표현이 어려운 조건(소유자, 상태, 시간 등)은 PDP 규칙으로 하기
검증 순서	(인증 완) -> RBAC 권한 -> 정책 조건 -> 처리
안전 기본값	기본은 거부(Default Deny), 최소 권한만 부여하기
실무 포인트	명명 규칙, 로깅/감사, 캐시 전략, 단일 PEP 배치하기