웹 서비스에서 사용자의 신원을 확인하는 과정이 인증(Authentication)이라면, 그 사용자가 무엇을 할 수 있는지 결정하는 과정이 바로 인가(Authorization) 입니다. 예를 들어 로그인까지는 모두 할 수 있지만 관리자 페이지 접근은 특정 사용자만 가능하도록 제한해야 합니다. 이때 역할을 구분하고 권한을 관리하는 과정이 인가입니다.
인가(Authorization)란
인가(Authorization) 은 이미 인증된 사용자에게 어떤 기능, 리소스, API, 화면 등에 접근할 수 있는 권한을 부여하거나 제한하는 과정입니다. 인증은 신원 확인이고 인가는 행동 허용 범위 결정이라 할 수 있습니다.
| 상황 | 인증 상태 | 인가 결과 |
|---|---|---|
| 로그인하지 않은 사용자 | 인증 실패 | 접근 불가 |
| 일반 유저 | 인증 성공 | 일반 기능만 사용 가능 |
| 관리자 유저 | 인증 성공 | 관리자 기능까지 사용 가능 |
권한 관리를 제대로 하지 않으면 다음과 같은 문제가 발생합니다.
| 문제 | 설명 | 결과 |
|---|---|---|
| 수평적 권한 침해 | 일반 유저가 다른 유저 데이터를 변경 가능 | 정보 유출 |
| 수직적 권한 침해 | 일반 유저가 관리자 기능 접근 가능 | 시스템 통제권 상실 |
| 의도치 않은 기능 노출 | 내부 기능이 외부에 노출 | 서비스 공격에 취약 |
따라서 인가는 단순 메뉴 처리 수준이 아니라, 서비스 전체의 보안 아키텍처의 핵심 요소입니다.
인가 방식: RBAC vs ABAC vs ACL
1. RBAC (Role Based Access Control, 역할 기반 접근 제어)
사용자의 역할(Role)에 따라 권한을 부여하는 방식입니다.
- ROLE_USER
- ROLE_ADMIN
- ROLE_MANAGER
RBAC의 장점은 관리가 쉽고 구조가 명확하기 때문에 조직 내 권한 설계가 효율적입니다.
2. ABAC (Attribute Based Access Control, 속성 기반 접근 제어)
사용자의 속성, 리소스 속성, 환경 조건 등을 조합하여 권한을 부여하는 방식입니다.
- 사용자 부서:
HR - 요청 시간:
근무시간대 - 리소스 민감도:
High
ABAC의 장점은 유연성이 매우 높기 때문에 대규모 시스템에서 정교한 조건 제어가 가능합니다.
3. ACL (Access Control List, 접근 제어 목록)
각 리소스에 누가 접근 가능한지 직접 기록하는 방식입니다.
- 문서 #108 → 접근 가능 사용자: userA, userC
ACI의 장점은 특정 리소스 단위로 정밀 제어가 가능합니다.
광고
주의사항
| 항목 | 설명 |
|---|---|
| 최소 권한 원칙 | 필요한 권한만 최소한으로 부여 |
| 역할 정의 기준 명확화 | 역할별 책임 범위를 명확하게 설정 |
| 감사 로그 기록 | 누가 무엇에 접근했는지 추적 가능해야 함 |
| 권한 변경 프로세스 관리 | 운영자가 권한을 쉽게 조정할 수 있어야 함 |
정리
- 인가는 인증 이후 사용자가 수행할 수 있는 행동을 결정하는 과정입니다.
- RBAC, ABAC, ACL 등 다양한 권한 관리 방식이 존재합니다.
- 비즈니스 규모와 요구사항에 따라 적절한 인가 전략을 선택해야 합니다.
- 인가는 서비스 보안과 운영 효율성에 직결되는 핵심 설계 요소입니다.
참고자료
- NIST RBAC Model: https://csrc.nist.gov/projects/role-based-access-control
- AWS IAM 정책 예시: https://docs.aws.amazon.com/iam/latest/UserGuide/access_policies.html
- OWASP Access Control Cheat Sheet: https://cheatsheetseries.owasp.org/