# Authorization(권한 부여)
권한 부여(Authorization)는 시스템이나 서비스가 특정 주체(subject, 예: 사용자, 서비스 계정)에게 특정 자원(resource)에 대해 특정 행동(action)을 수행할 수 있는 권한을 부여하는 과정이다. 인증(Authentication)이 주체의 신원을 확인하는 반면, 권한 부여는 확인된 신원에게 어떤 행위를 허용할지 결정한다. 현대의 보안 아키텍처에서는 인증과 권한 부여가 분리되어 동작하는 경우가 많으며, 정책 기반 접근 제어(Policy-based Access Control, PBAC) 원칙에 따라 유연하고 세밀한 권한 관리가 가능하다.
## 주요 용어와 개념
- Subject: 접근하려는 주체. 예: 사용자, 서비스 계정, 애플리케이션.
- Resource: 접근 대상 자원. 예: 파일, API 엔드포인트, 데이터베이스 레코드.
- Action: 허용되거나 차단될 수 있는 행위. 예: read, write, delete, execute.
- Context: 권한 판단에 영향을 주는 환경적 요소. 예: 시간대, 위치, 관련 정책, 신뢰도 등.
- Policy: 어떠한 조합의 조건에서 어떤 주체가 어떤 자원에 어떤 행동을 할 수 있는지 정의하는 규칙 집합.
- PDP (Policy Decision Point): 정책을 평가하고 접근 허용 여부를 결정하는 컴포넌트.
- PEP (Policy Enforcement Point): PDP의 판단 결과에 따라 실제 접근을 허용하거나 차단하는 엔드포인트.
- PAP (Policy Administration Point): 정책의 관리 및 배포를 담당하는 컴포넌트.
- PIP (Policy Information Point): 정책 평가에 필요한 외부 정보(주체의 속성, 자원의 속성 등)를 제공하는 컴포넌트.
- RBAC (Role-Based Access Control): 역할을 통해 권한을 부여하는 모델.
- ABAC (Attribute-Based Access Control): 속성(Attribute)을 기준으로 권한을 부여하는 모델.
- ACL (Access Control List): 자원 단위의 허용/차단 목록.
## 권한 부여 모델
- RBAC
- 역할(Role)을 중심으로 접근 권한을 부여하는 모델.
- 예: admin, editor, viewer 같은 역할에 각기 다른 권한을 매핑.
- ABAC
- 주체의 속성, 자원의 속성, 환경 조건 등을 조합해 접근을 결정하는 모델.
- 예: user.department = "engineering" && resource.classification = "public"일 때만 허용.
- MAC (Mandatory Access Control)
- 시스템의 보안 정책에 의해 강제되는 모델로, 일반적으로 위험 환경이나 고보안 환경에서 사용.
- ACL 기반 접근 제어
- 자원별로 허용된 주체의 목록을 유지하는 방식.
- 세분화된 제어보다 관리 복잡도가 증가할 수 있음.
## 권한 부여 흐름과 아키텍처
1. 사용자는 시스템에 접근하려 시도한다.
2. PEP가 요청을 가로채고 PDP에 판단을 의뢰한다.
3. PDP는 정책(PBAC, ABAC 등)과 컨텍스트 정보를 바탕으로 허용/비허용 판단을 내린다.
4. PEP가 판단 결과에 따라 접근을 허용하거나 차단한다.
5. 필요 시 PAP가 정책을 관리하고 PIP가 외부 정보를 공급한다.
6. 감사 로그가 남겨져 추후 분석에 활용된다.
참고로 제어 흐름은 분산형과 중앙집중형으로 구현될 수 있다.
- 분산형: 각 서비스가 자체적으로 PDP/PEP를 가지고 지역적으로 권한 판단.
- 중앙집중형: API 게이트웨이나 서비스 메쉬가 중앙 PDP를 호출해 일괄 관리.
## 구현 패턴 및 기술 스택
- 토큰 기반 권한 부여
- OAuth 2.0, OIDC를 활용한 Access Token에 권한(scopes)나 청구(claims) 정보를 포함.
- JWT(JSON Web Token) 형식으로 주체의 속성과 권한 정보를 전달.
- 정책 엔진과 정책 표현 언어
- OPA(Open Policy Agent) + Rego: 중앙 정책 엔진으로 다양한 서비스에 정책을 적용.
- XACML: 엔터프라이즈 수준의 정책 표현 표준.
- ALFA: XACML 정책의 사람 친화적 작성을 돕는 규격.
- 실행 환경
- API 게이트웨이에서의 권한 부여 집중 관리.
- 서비스 메쉬 내의 사이드카에서 PEP 역할 수행.
- 데이터베이스 레벨의 접근 제어와 파일 시스템 수준의 ACL 병합.
- 데이터 형식
- 정책은 JSON/YAML/XML 형태로 표현되며, 속성 기반 비교나 정규식 매칭 등을 지원.
- 시큐어 코딩 및 운영 고려사항
- 최소 권한 원칙(Least Privilege) 적용.
- 시점에 따른 권한 만료/갱신 정책.
- 감사 로그 및 모니터링, 비정상 패턴 탐지.
- 정책 변경 시 실시간 또는 안전한 배포 전략(롤백, 캐시 무효화).
## 정책 언어와 엔진의 비교 포인트
- 선택 기준
- 표현력: ABAC의 속성 기반 조건 vs RBAC의 역할 중심
- 성능: 정책 복잡도와 캐시 전략
- 운영 편의성: 정책 관리 UI/CLI, 버전 관리, 감사
- 통합성: 기존 서비스/인프라와의 연계 용이성
- 대표 도구
- Open Policy Agent (OPA) + Rego
- XACML 기반 엔진
- ACL 기반 관리 도구
## 보안 고려사항
- 최소 권한 원칙 준수
- 주체 속성 및 환경 컨텍스트의 신뢰성 확보
- 동적 정책 업데이트와 캐시 무효화 전략
- 다단계 인증(Multi-Factor Authentication)과 연계된 권한 관리
- 감사 로그의 무결성과 보관 기간 정책
- 권한 남용 탐지 및 신속한 권한 회수 절차
## 사례 시나리오
- 웹 애플리케이션
- RBAC를 적용하여 관리자(admin)와 일반 사용자(user)의 API 접근 권한 구분.
- 예: 관리자만 /admin/ 엔드포인트 접근 허용.
- 문서 관리 시스템
- ABAC를 활용해 문서의 기밀성(classification)과 사용자의 부서(department)에 따라 읽기/쓰기 권한 결정.
- 데이터베이스 접근
- 정책 엔진이 쿼리 단위의 권한을 판단하고, 특정 컬럼 또는 테이블에 대한 읽기/쓰기 권한을 제어.
## 구현 예시
- RBAC 예시 (간단한 정책 구조)
- Roles: admin, editor, viewer
- Permissions:
- /documents/*: admin, editor
- /admin/*: admin
- ABAC 예시 (JSON 정책 예시)
- 주체 속성, 자원 속성, 환경 조건을 결합한 예시 정책
```json
{
"policy": {
"id": "doc-read-engineering-public",
"effect": "allow",
"action": "read",
"resource": "/documents/*",
"conditions": {
"user.department": "engineering",
"document.classification": "public"
}
}
}
```
- OPA(Rego) 예시
- 엔진에 전달되는 입력(input)과 정책 규칙에서 허용 여부 판단
```rego
package authorization
default allow = false
allow {
input.method = "GET"
input.path = "/documents/"
input.user.role = "admin"
}
```
- 정책 엔진 기반의 흐름 예시
- PEP: API 엔드포인트
- PDP: OPA에 정책 질의
- PIP: 사용자 속성, 자원 속성 공급
- PAP: 정책 관리
## 구현 권고
- 상황에 맞는 모델 선정
- 고정된 권한이 많고 관리가 단순한 경우 RBAC를 먼저 도입.
- 속성 다양성과 상황 의존성이 큰 경우 ABAC 확장 또는 하이브리드 모델 고려.
- 정책의 버전 관리와 변경 관리 체계 확립
- 로그와 모니터링으로 의심스러운 권한 남용 탐지
- 인증과 권한 부여의 경계 명확화
- 성능 고려: 정책 캐시 전략, 지연 최소화, 캐시 무효화 규칙 정의
---
관련 문서: [[권한 부여 정책 언어 소개]], [[RBAC의 이해와 구현 가이드]], [[ABAC와 정책 엔진 비교]]