접근제어(RBAC, ABAC)

인가 (Authorization)

인증(Authentication)이 완료된 후, 특정 리소스에 대한 접근 권한이 있는지 확인하는 절차

📝 NOTE 인증 vs 인가

• 인증: 너 누구야? (로그인)
• 인가: 너 이거 해도 돼? (권한 확인)

인가 설정은 크게 RBAC, ABAC으로 나눌 수 있음

RBAC (Role-Based Access Control)

• 역할(Role) 기반으로 접근 권한을 부여
• 사용자에게 직접 권한을 주는 게 아니라, 역할에 권한을 부여하고 사용자에게 역할을 할당
• 구조: 사용자 → 역할 → 권한

예시

역할	권한
ADMIN	모든 리소스 읽기/쓰기/삭제
MANAGER	리소스 읽기/쓰기
USER	리소스 읽기만 가능

장점

• 구조가 단순하고 이해하기 쉬움
• 역할만 관리하면 되므로 대규모 조직에서 관리가 편함
• Spring Security 등 대부분의 프레임워크에서 기본 지원

단점

• 세밀한 제어가 어려움 — “본인이 작성한 글만 수정 가능” 같은 조건을 역할만으로 표현하기 힘듦
• 역할이 많아지면 역할 폭발(Role Explosion) 문제 발생

ABAC (Attribute-Based Access Control)

• 속성(Attribute) 기반으로 접근 권한을 판단
• 사용자, 리소스, 환경 등 다양한 속성을 조합하여 정책을 정의
• 구조: 정책(Policy) = 주체 속성 + 리소스 속성 + 환경 속성 + 행위

속성의 종류

구분	예시
주체(Subject) 속성	부서, 직급, 나이, 보안등급
리소스(Resource) 속성	문서 분류, 생성자, 민감도
환경(Environment) 속성	접속 시간, IP 대역, 디바이스
행위(Action)	읽기, 쓰기, 삭제

예시

• “인사팀 소속이고 사내 IP에서 접속한 경우에만 급여 데이터 열람 가능”
• “본인이 작성한 게시글만 수정 가능”
• “근무 시간 내에만 관리자 페이지 접근 가능”

장점

• 매우 세밀한 접근 제어 가능
• 역할 폭발 문제 없음
• 동적 조건(시간, 위치 등)도 정책에 포함 가능

단점

• 정책 설계와 관리가 복잡
• 디버깅이 어려움 — 왜 접근이 거부됐는지 추적하기 힘듦
• 구현 비용이 높음

RBAC vs ABAC 비교

구분	RBAC	ABAC
기준	역할	속성 (주체/리소스/환경)
세밀도	낮음	높음
관리 복잡도	낮음	높음
동적 조건	불가	가능
적합한 경우	역할 구분이 명확한 시스템	세밀한 정책이 필요한 시스템

💡 TIP 실무에서는 RBAC을 기본으로 사용하고, 세밀한 제어가 필요한 부분만 ABAC을 적용하는 하이브리드 방식이 일반적