# 권한 관리 (Authorization Management)

## 1. 개요
권한 관리란 인증된 사용자가 시스템 내의 특정 자원(Resource)에 접근하거나 특정 동작(Action)을 수행할 수 있는 권한이 있는지 확인하고 제어하는 보안 프로세스이다.

많은 이들이 인증과 권한 부여를 혼동하지만, 보안 아키텍처 관점에서 두 개념은 엄격히 구분된다.
*   **인증 (Authentication, AuthN):** "당신은 누구인가?"를 확인하는 과정이다. ID/PW, 생체 인식, MFA(다요소 인증) 등을 통해 사용자의 신원을 증명하는 단계이다.
*   **권한 부여 (Authorization, AuthZ):** "당신이 이 작업을 수행할 권한이 있는가?"를 결정하는 과정이다. 인증이 완료된 사용자에게 허용된 리소스의 범위와 작업 종류(읽기, 쓰기, 삭제 등)를 정의하고 검증하는 단계이다.

## 2. 권한 관리의 핵심 원칙
보안 사고의 피해를 최소화하고 내부 통제를 강화하기 위해 다음과 같은 설계 철학을 적용한다.

### 2.1 최소 권한 원칙 (Principle of Least Privilege, PoLP)
사용자나 프로세스에게 업무 수행에 필요한 **최소한의 권한만 부여**하는 원칙이다. 불필요한 권한을 제거함으로써 계정 탈취 시 공격자가 수행할 수 있는 피해 범위를 제한(Blast Radius 감소)하고, 실수로 인한 데이터 삭제나 변조를 방지한다.

### 2.2 직무 분리 (Separation of Duties, SoD)
단일 사용자가 전체 프로세스를 독점하여 부정행위를 저지르는 것을 막기 위해, **중요한 업무 프로세스를 여러 단계로 나누어 서로 다른 사람에게 할당**하는 원칙이다. 예를 들어, 결제 요청자와 결제 승인자를 분리하여 내부 횡령이나 조작 가능성을 차단한다.

## 3. 권한 제어 모델 (Access Control Models)
시스템의 성격과 보안 요구 수준에 따라 다양한 권한 제어 모델이 사용된다.

### 3.1 모델별 비교 분석
| 모델 | 정의 | 장점 | 단점 | 적합한 사례 |
| :--- | :--- | :--- | :--- | :--- |
| **DAC** (임의적 제어) | 자원 소유자가 권한을 직접 부여 | 유연성이 매우 높음 | 관리가 어렵고 보안성이 낮음 | 개인 PC 파일 시스템 |
| **MAC** (강제적 제어) | 시스템 정책(보안 등급)에 따라 강제 부여 | 매우 강력한 보안성 | 설정이 복잡하고 유연성 부족 | 군사/정부 기밀 시스템 |
| **RBAC** (역할 기반 제어) | 사용자에게 '역할'을 부여하고 역할에 권한 할당 | 관리 효율성 높음, 직관적 | 역할 폭발(Role Explosion) 가능성 | 기업 ERP, 일반 웹 서비스 |
| **ABAC** (속성 기반 제어) | 사용자, 자원, 환경 속성을 조합해 동적 결정 | 매우 세밀한 제어 가능 | 정책 정의 및 평가 비용 높음 | 클라우드 인프라, 복잡한 규제 환경 |

**※ RBAC의 '역할 폭발(Role Explosion)' 해결 방안:**
역할이 지나치게 세분화되어 관리 대상이 급증하는 현상을 막기 위해 다음과 같은 방법을 사용한다.
*   **계층적 RBAC (Hierarchical RBAC):** 상위 역할이 하위 역할의 권한을 상속받게 하여 중복 정의를 줄인다. (예: `Admin` $\rightarrow$ `Editor` $\rightarrow$ `Viewer`)
*   **역할 기반 제어와 속성 기반 제어의 혼합:** 기본 권한은 RBAC로 관리하고, 세부적인 제약 조건(시간, IP, 소유권 등)은 ABAC의 속성 검증을 통해 처리한다.

### 3.2 모델 선택 결정 트리 (Decision Tree)
권한 모델 선택 시 다음의 흐름을 따른다.

```mermaid
graph TD
    Start([시작]) --> Q1{보안 등급이 극도로 높고<br/>중앙 통제가 절대적인가?}
    Q1 -- YES --> MAC[MAC]
    Q1 -- NO --> Q2{사용자 속성에 따라<br/>동적으로 권한이 변해야 하는가?}
    Q2 -- YES --> ABAC[ABAC]
    Q2 -- NO --> Q3{사용자 그룹별로<br/>정형화된 권한 세트가 있는가?}
    Q3 -- YES --> RBAC[RBAC]
    Q3 -- NO --> DAC[DAC]
```

## 4. 권한 관리의 구현 메커니즘

### 4.1 ACL vs Capability-based Security
*   **ACL (Access Control List):** 자원(Object) 중심의 관리 방식이다. 특정 파일이나 폴더에 "누가 접근할 수 있는가"에 대한 리스트를 저장한다.
    *   **특징:** 권한 취소(Revocation)가 매우 용이하다. 리스트에서 특정 사용자의 이름만 삭제하면 즉시 권한이 회수된다.
*   **Capability-based Security:** 사용자(Subject) 중심의 관리 방식이다. 사용자가 자원에 접근할 수 있는 '티켓(Capability)'을 소유하며, 이 티켓을 제시함으로써 권한을 증명한다.
    *   **특징:** 이미 발행된 티켓(토큰)을 개별적으로 회수하기 어렵다. 이를 해결하기 위해 토큰 만료 시간을 짧게 설정하거나, 블랙리스트(Blacklist)를 운영하는 추가 메커니즘이 필요하다.

### 4.2 권한 부여 흐름도 (Sequence Diagram)
사용자가 요청을 보냈을 때 시스템 내부에서 권한을 검증하는 일반적인 흐름이다.

```mermaid
sequenceDiagram
    participant User as 사용자
    participant API as API 게이트웨이/서버 (PEP)
    participant AuthZ as 권한 검증 모듈 (PDP)
    participant DB as 권한 저장소 (DB/LDAP)

    User->>API: 리소스 요청 (Token 포함)
    API->>AuthZ: 권한 검증 요청 (User ID, Resource, Action)
    AuthZ->>DB: 사용자의 역할 및 권한 조회
    DB-->>AuthZ: 권한 정보 반환
    AuthZ->>AuthZ: 정책 평가 (Policy Evaluation)
    AuthZ-->>API: 허용(Allow) 또는 거부(Deny) 응답
    API-->>User: 요청 결과 반환 (200 OK 또는 403 Forbidden)
```
*   **PEP (Policy Enforcement Point):** 권한 요청을 가로채어 PDP에 전달하고, PDP의 결정 결과(허용/거부)를 실제로 집행하는 지점이다.
*   **PDP (Policy Decision Point):** 설정된 정책과 사용자 정보를 바탕으로 해당 요청의 권한 허용 여부를 최종적으로 결정하는 지점이다.

### 4.3 RBAC 기반 권한 체크 로직 예시 (Python)
```python
# 간단한 RBAC 구현 예시
user_roles = {
    "alice": ["admin"],
    "bob": ["editor"],
    "charlie": ["viewer"]
}

role_permissions = {
    "admin": ["read", "write", "delete"],
    "editor": ["read", "write"],
    "viewer": ["read"]
}

def check_permission(user, action):
    # 1. 사용자의 역할 조회
    roles = user_roles.get(user, [])
    
    # 2. 역할에 따른 권한 확인
    for role in roles:
        if action in role_permissions.get(role, []):
            return True
    return False

# 테스트 케이스
test_cases = [
    ("bob", "write"),     # 기대값: True
    ("charlie", "write"), # 기대값: False
    ("alice", "delete"),  # 기대값: True
    ("guest", "read")     # 기대값: False (등록되지 않은 사용자)
]

for user, action in test_cases:
    result = check_permission(user, action)
    print(f"User: {user}, Action: {action} -> Allowed: {result}")
```

## 5. 현대적 권한 관리 체계 및 표준

### 5.1 OAuth 2.0 및 OpenID Connect (OIDC)
*   **OAuth 2.0:** 사용자가 자신의 자원 접근 권한을 제3자 애플리케이션에 안전하게 **위임(Delegation)**하기 위한 프레임워크이다. 'Access Token'을 통해 권한 범위를 제한하는 **Scope** 개념을 사용하여, 앱이 사용자의 전체 데이터가 아닌 필요한 부분에만 접근하도록 제어한다.
*   **OIDC:** OAuth 2.0 위에 인증 계층을 추가한 표준으로, 'ID Token'을 통해 사용자의 신원 정보를 안전하게 전달한다.

### 5.2 IAM (Identity and Access Management)
클라우드 환경(AWS, Azure, GCP 등)에서 사용하는 통합 관리 체계이다. 사용자, 그룹, 역할(Role), 정책(Policy)을 하나의 프레임워크에서 관리하며, 특히 **임시 보안 자격 증명(Temporary Credentials)**을 통해 권한 노출 위험을 최소화한다.

### 5.3 실제 서비스 권한 매트릭스 예시
서비스 내 기능별로 역할에 따른 접근 권한을 정의한 매트릭스이다.

| 기능 / 역할 | Guest | Viewer | Editor | Admin |
| :--- | :---: | :---: | :---: | :---: |
| 게시글 조회 | $\checkmark$ | $\checkmark$ | $\checkmark$ | $\checkmark$ |
| 게시글 작성 | $\times$ | $\times$ | $\checkmark$ | $\checkmark$ |
| 게시글 수정 | $\times$ | $\times$ | $\checkmark$ (본인) | $\checkmark$ (전체) |
| 사용자 관리 | $\times$ | $\times$ | $\times$ | $\checkmark$ |
| 시스템 설정 | $\times$ | $\times$ | $\times$ | $\checkmark$ |

## 6. 권한 관리의 취약점 및 대응 방안

### 6.1 주요 취약점
*   **IDOR (Insecure Direct Object Reference):** 사용자가 입력값(예: URL의 ID 값)을 조작하여 자신이 권한이 없는 다른 사용자의 데이터에 접근하는 취약점이다.
*   **권한 상승 (Privilege Escalation):** 일반 사용자가 시스템의 허점을 이용하여 관리자 권한을 획득하는 공격이다. (수직적 상승) 또는 동일 권한의 다른 사용자 데이터를 조작하는 경우이다. (수평적 상승)

### 6.2 보안 코딩 가이드 및 대응 방안
1. **서버 측 검증 필수:** 클라이언트(Frontend)에서 버튼을 숨기는 것은 UI/UX 편의일 뿐이며, 모든 API 요청에 대해 서버에서 다시 한번 권한을 검증해야 한다.
2. **간접 참조 사용:** 데이터베이스의 PK(Primary Key)를 URL에 직접 노출하지 않고, 무작위 문자열(UUID)이나 매핑 테이블을 통한 간접 참조를 사용한다.
3. **Fail-Safe Defaults:** 권한 설정이 누락되었을 경우 기본적으로 '거부(Deny)' 상태가 되도록 설계한다.
4. **정기적인 권한 감사:** 불필요하게 부여된 권한이나 퇴사자/부서 이동자의 권한이 남아있는지 주기적으로 검토하고 회수한다.