Authorization Models
API 권한 부여(Authorization)는 인증(Authentication)이 완료된 후, 사용자가 어떤 리소스에 접근할 수 있는지를 결정하는 중요한 보안 메커니즘이다. 권한 부여는 사용자의 신원이 확인된 후(인증), 해당 사용자가 특정 API 리소스나 작업에 접근할 수 있는 권한이 있는지를 확인하는 과정이다.
인증(Authentication)과 권한 부여(Authorization)의 차이
API 보안 맥락에서 이 두 개념의 차이를 명확히 이해하는 것이 중요하다:
인증(Authentication):
- “당신이 누구인지” 확인하는 과정
- 사용자나 시스템의 신원을 검증
- 주로 자격 증명(사용자 이름/비밀번호, 토큰, 인증서 등)을 통해 이루어짐
권한 부여(Authorization):
- “무엇을 할 수 있는지” 결정하는 과정
- 인증된 사용자의 접근 권한과 작업 권한을 정의
- 인증 이후에 진행되는 프로세스
주요 API 권한 부여 방법
모델 | 설명 | 주요 특징 | 장점 | 단점 | 적용 사례 | 보안 수준 |
---|---|---|---|---|---|---|
ABAC (Attribute Based Access Control) | 사용자, 리소스, 환경의 속성을 기반으로 접근을 제어하는 모델 | • 다양한 속성 기반 결정 • 동적 정책 적용 • 상황 인식 가능 | • 세밀한 접근 제어 • 유연한 정책 설정 • 상황에 따른 동적 제어 | • 구현 복잡도 높음 • 성능 오버헤드 • 정책 관리 어려움 | • 클라우드 서비스 • IoT 시스템 • 의료 정보 시스템 | 높음 |
DAC (Discretionary Access Control) | 리소스 소유자가 직접 접근 권한을 제어하는 모델 | • 소유자 중심 제어 • 권한 위임 가능 • 유연한 권한 관리 | • 사용자 자율성 높음 • 구현 용이 • 유연한 관리 | • 보안 일관성 부족 • 권한 남용 위험 • 중앙 통제 어려움 | • 파일 시스템 • 개인용 컴퓨터 • 소규모 조직 | 낮음 |
MAC (Mandatory Access Control) | 중앙에서 정의한 보안 정책에 따라 엄격히 접근을 제어하는 모델 | • 중앙 집중식 제어 • 엄격한 보안 레벨 • 정책 강제 적용 | • 높은 보안성 • 일관된 정책 적용 • 중앙 통제 용이 | • 유연성 부족 • 관리 부담 큼 • 사용자 불편 | • 군사 시스템 • 정부 기관 • 높은 보안 요구 환경 | 매우 높음 |
PBAC (Purpose Based Access Control) | 데이터 사용 목적을 기반으로 접근을 제어하는 모델 | • 목적 기반 결정 • 데이터 사용 추적 • 규정 준수 강조 | • 개인정보 보호 • 규정 준수 용이 • 투명한 관리 | • 목적 정의 어려움 • 검증 복잡 • 오버헤드 발생 | • 의료 서비스 • 금융 시스템 • 개인정보 처리 | 높음 |
RBAC (Role Based Access Control) | 사용자의 역할을 기반으로 접근을 제어하는 모델 | • 역할 기반 권한 • 계층적 구조 • 권한 그룹화 | • 관리 효율성 • 구현 용이 • 확장성 좋음 | • 복잡한 정책 구현 어려움 • 동적 변경 제한 • 역할 폭발 현상 | • 기업 시스템 • 웹 애플리케이션 • 대규모 조직 | 중간 |
역할 기반 접근 제어 (Role-Based Access Control, RBAC)
사용자에게 역할을 할당하고, 각 역할에 특정 권한을 부여하는 방식이다.
작동 방식:
- 사용자는 하나 이상의 역할(role)에 할당된다.
- 각 역할은 특정 API 리소스나 작업에 대한 권한 집합을 가진다.
- 사용자의 API 요청이 들어오면, 시스템은 사용자의 역할을 확인하고 해당 역할에 필요한 권한이 있는지 검증한다.
예시 역할:
- 관리자(Admin): 모든 리소스에 대한 전체 접근 권한
- 편집자(Editor): 읽기 및 쓰기 권한, 일부 삭제 권한
- 조회자(Viewer): 읽기 전용 권한
장점:
- 관리가 용이하다 - 역할 변경만으로 여러 사용자의 권한을 한 번에 수정할 수 있다.
- 직관적인 모델로 이해하기 쉽다.
- 대부분의 조직 구조에 자연스럽게 맞다.
단점:
- 매우 세분화된 권한 제어가 필요한 경우 관리가 복잡해질 수 있다.
- 특정 상황이나 조건에 따른 동적 권한 부여가 제한적이다.
적합한 사용 사례:
- 기업용 애플리케이션
- 팀 기반 협업 도구
- 조직 구조가 명확한 시스템
속성 기반 접근 제어 (Attribute-Based Access Control, ABAC)
사용자, 리소스, 환경의 속성을 기반으로 접근 권한을 결정하는 더 유연한 모델.
속성의 종류:
- 사용자 속성: 역할, 부서, 직급, 소속 등
- 리소스 속성: 유형, 소유자, 민감도 등급, 생성 날짜 등
- 환경 속성: 시간, 위치, 사용 기기, 네트워크 등
작동 방식:
- 정책(policy)으로 접근 규칙을 정의한다: “부서가 X이고 직급이 Y 이상인 사용자는 민감도 등급 Z 이하의 리소스에 접근 가능”
- 사용자가 요청할 때 관련된 모든 속성을 평가하여 정책 준수 여부를 확인한다.
장점:
- 매우 세분화된 권한 제어가 가능하다.
- 동적인 상황에 기반한 유연한 권한 부여가 가능하다.
- 복잡한 규정 준수 요구사항을 충족시킬 수 있다.
단점:
- 구현 및 관리가 복잡하다.
- 많은 속성과 정책이 있을 경우 성능에 영향을 줄 수 있다.
- 직관적으로 이해하기 어려울 수 있다.
적합한 사용 사례:
- 의료 정보 시스템
- 금융 서비스 API
- 정부 시스템
- 복잡한 규정 준수가 필요한 산업
OAuth 2.0 범위 (Scopes)
OAuth 2.0 프레임워크에서 제공하는 권한 부여 메커니즘으로, 클라이언트 애플리케이션이 사용자 리소스에 접근할 수 있는 범위를 제한한다.
작동 방식:
- 클라이언트 애플리케이션이 특정 범위(scope)에 대한 접근을 요청한다.
- 사용자는 이러한 권한 부여에 동의한다.
- 서버는 요청된 범위로 제한된 액세스 토큰을 발급한다.
- 클라이언트는 해당 토큰으로 범위 내의 API 엔드포인트에만 접근할 수 있다.
예시 범위:
read:users
: 사용자 정보 읽기 권한write:posts
: 게시물 작성 권한delete:comments
: 댓글 삭제 권한
장점:
- 사용자가 제3자 애플리케이션에 제공할 권한을 명시적으로 제어할 수 있다.
- 최소 권한 원칙을 효과적으로 구현할 수 있다.
- 널리 채택된 표준으로 다양한 라이브러리와 도구가 존재한다.
단점:
- 설계와 구현이 복잡할 수 있다.
- 범위 정의에 신중한 계획이 필요하다.
적합한 사용 사례:
- 소셜 미디어 API 통합
- 제3자 애플리케이션 에코시스템
- 사용자 데이터에 접근하는 공개 API
권한 기반 접근 제어 (Permission-Based Access Control)
세분화된 개별 권한을 직접 사용자나 그룹에 할당하는 방식이다. RBAC의 변형으로 볼 수 있다.
작동 방식:
- 시스템에서 가능한 모든 작업에 대해 개별 권한을 정의한다.
- 사용자나 그룹에 직접 이러한 권한을 할당한다.
- API 요청 시 사용자가 필요한 특정 권한을 가지고 있는지 확인한다.
장점:
- 매우 세분화된 제어가 가능하다.
- 역할보다 더 유연한 권한 할당이 가능하다.
- 최소 권한 원칙을 정확하게 구현할 수 있다.
단점:
- 권한 수가 많아지면 관리가 복잡해진다.
- 사용자 수가 많은 시스템에서는 유지보수가 어려울 수 있다.
적합한 사용 사례:
- 복잡한 워크플로우가 있는 시스템
- 세분화된 리소스 접근 제어가 필요한 애플리케이션
- 다양한 사용자 유형이 있는 복잡한 시스템
JWT 클레임 기반 권한 부여 (JWT Claims-Based Authorization)
JWT(JSON Web Token)의 클레임을 활용하여 권한 정보를 토큰에 직접 포함시키는 방식.
작동 방식:
- 인증 서버는 사용자 권한 정보(역할, 권한 등)를 JWT 클레임에 포함시켜 토큰 발급
- 클라이언트는 API 요청 시 이 토큰을 전송
- API 서버는 토큰을 검증하고 포함된 클레임을 확인하여 접근 권한 결정
예시 JWT 클레임:
장점:
- 상태 비저장(stateless) 방식으로 확장성이 높다.
- 권한 정보가 토큰에 포함되어 있어 추가 조회가 필요 없다.
- 마이크로서비스 아키텍처에 적합하다.
단점:
- 토큰이 발급된 후에는 권한을 즉시 취소하기 어렵다.
- 권한 정보가 많을 경우 토큰 크기가 커질 수 있다.
- 토큰 탈취 시 포함된 모든 권한이 노출된다.
적합한 사용 사례:
- 마이크로서비스 아키텍처
- 분산 시스템
- 단일 페이지 애플리케이션(SPA)
- 모바일 애플리케이션
정책 기반 접근 제어 (Policy-Based Access Control)
중앙 집중식 정책 엔진을 사용하여 동적인 권한 부여 결정을 내리는 방식이다. 종종 ABAC와 함께 사용된다.
작동 방식:
- 접근 정책을 특정 언어나 형식으로 정의한다(예: XACML, OPA Rego 등).
- 중앙화된 정책 의사 결정 지점(Policy Decision Point, PDP)이 요청을 평가한다.
- 정책 집행 지점(Policy Enforcement Point, PEP)이 결정을 적용한다.
장점:
- 접근 제어 로직을 애플리케이션 코드에서 분리할 수 있다.
- 정책을 중앙에서 관리하고 동적으로 업데이트할 수 있다.
- 복잡한 조건부 로직과 비즈니스 규칙을 표현할 수 있다.
단점:
- 구현이 복잡하고 추가 인프라가 필요하다.
- 성능 오버헤드가 발생할 수 있다.
- 정책 작성과 디버깅이 어려울 수 있다.
적합한 사용 사례:
- 대규모 엔터프라이즈 시스템
- 복잡한 규정 준수 요구사항이 있는 산업
- 자주 변경되는 접근 정책이 필요한 환경
맥락 기반 접근 제어 (Contextual Access Control)
사용자의 행동 패턴, 위치, 시간 등 맥락 정보를 기반으로 접근 권한을 동적으로 결정하는 방식이다.
고려되는 맥락 요소:
- 접근 시간과 날짜
- 지리적 위치
- IP 주소 및 네트워크 정보
- 사용 기기 및 브라우저
- 이전 사용 패턴
작동 방식:
- 사용자 인증 시 다양한 맥락 정보를 수집한다.
- 이 정보를 정상적인 사용 패턴과 비교한다.
- 위험도를 평가하여 접근 수준을 동적으로 조정한다.
장점:
- 보안을 강화하면서도 정상적인 사용은 방해하지 않는다.
- 위험 기반 접근 방식으로 이상 행동을 탐지할 수 있다.
- 적응형 보안 모델을 구현할 수 있다.
단점:
- 구현이 복잡하고 고급 분석 능력이 필요하다.
- 오탐지가 발생할 수 있어 사용자 경험에 영향을 줄 수 있다.
- 개인정보 보호 문제가 발생할 수 있다.
적합한 사용 사례:
- 금융 API
- 의료 정보 시스템
- 고급 보안이 필요한 기업 애플리케이션
- 민감한 데이터를 처리하는 서비스
API 권한 부여 구현 패턴
API 게이트웨이를 통한 중앙 집중식 권한 부여
작동 방식:
- 모든 API 요청이 게이트웨이를 통과한다.
- 게이트웨이는 인증 및 권한 부여 검사를 수행한다.
- 권한이 있는 요청만 해당 백엔드 서비스로 전달된다.
장점:
- 권한 부여 로직을 중앙화하여 일관성을 보장한다.
- 백엔드 서비스는 권한 부여에 대해 걱정할 필요가 없다.
- 정책 변경을 한 곳에서 적용할 수 있다.
단점:
- 단일 장애 지점이 될 수 있다.
- 성능 병목 현상이 발생할 수 있다.
- 세분화된 권한 부여를 위해 백엔드 컨텍스트가 필요할 수 있다.
마이크로서비스 아키텍처의 분산 권한 부여
작동 방식:
- 각 마이크로서비스가 자체 권한 부여 로직을 구현한다.
- 서비스 간 통신 시 권한 정보가 전파된다(토큰, 컨텍스트 등).
- 각 서비스는 자신의 도메인 내에서 접근 결정을 내린다.
장점:
- 서비스의 자율성과 독립성을 유지한다.
- 도메인별로 특화된 권한 부여 로직을 구현할 수 있다.
- 단일 장애 지점을 방지한다.
단점:
- 일관된 정책 적용이 어려울 수 있다.
- 서비스 간 권한 전파 메커니즘이 필요하다.
- 중복 코드와 로직이 발생할 수 있다.
외부 권한 부여 서비스 (External Authorization Service)
작동 방식:
- 전용 권한 부여 서비스(예: OPA, ORY Keto)를 구축한다.
- 모든 서비스가 접근 결정을 위해 이 서비스에 쿼리한다.
- 권한 부여 서비스는 중앙 정책 저장소를 유지하고 결정을 내린다.
장점:
- 권한 부여 로직을 완전히 분리한다.
- 일관된 정책 적용을 보장한다.
- 전문화된 서비스로 복잡한 권한 부여 로직을 처리할 수 있다.
단점:
- 추가적인 네트워크 호출로 인한 지연이 발생한다.
- 권한 부여 서비스에 대한 의존성이 생긴다.
- 구현과 유지보수가 복잡할 수 있다.
API 권한 부여 모범 사례
최소 권한 원칙 적용
- 사용자와 애플리케이션에 필요한 최소한의 권한만 부여한다.
- 기본적으로 모든 접근을 거부하고, 명시적으로 허용된 접근만 허용한다.
- 권한을 정기적으로 검토하고 불필요한 권한을 제거한다.
권한 부여 로직의 세분화
- 리소스 수준에서 권한을 제어한다(전체 API가 아닌 특정 엔드포인트나 데이터).
- 작업 유형(읽기, 쓰기, 삭제 등)에 따라 권한을 분리한다.
- 필요한 경우 데이터 필드 수준의 접근 제어를 구현한다.
권한 부여 결정 캐싱
- 권한 부여 결정을 적절히 캐싱하여 성능을 향상시킨다.
- 캐시 무효화 전략을 구현하여 변경된 권한이 적시에 적용되도록 한다.
- 분산 시스템에서는 일관된 캐싱 메커니즘을 사용한다.
보안 로깅 및 감사
- 모든 권한 부여 결정과 접근 시도를 로깅한다.
- 감사 추적을 위해 누가, 무엇을, 언제, 어디서 접근했는지 기록한다.
- 권한 변경 이력을 추적하고 변경 사유를 문서화한다.
권한 상승 경로 제공
- 특수한 상황을 위한 임시 권한 상승 메커니즘을 구현한다.
- 권한 상승 요청에 대한 승인 프로세스를 구축한다.
- 상승된 권한의 사용을 면밀히 모니터링하고 감사한다.
산업별 API 권한 부여 요구사항
금융 서비스
- FAPI(Financial-grade API) 표준 준수
- 트랜잭션 수준의 권한 부여
- 이중 인증(MFA)과 결합된 권한 부여
- 규제 요구사항에 따른 세분화된 접근 제어
의료
- HIPAA 규정 준수를 위한 엄격한 접근 제어
- 환자 동의 기반 권한 부여
- 비상 접근 프로토콜(Break-glass 프로토콜)
- 역할 기반 접근과 맥락 기반 접근의 조합
소매 및 전자상거래
- 고객 데이터에 대한 개인정보 보호 중심 접근 제어
- 판매자와 구매자에 대한 차별화된 권한 모델
- 결제 처리에 대한 엄격한 권한 제어
- 프로모션 및 할인 적용에 대한 특별 권한
정부 시스템
- 다단계 승인 워크플로우
- 법적 권한에 기반한 접근 제어
- 엄격한 데이터 분류와 접근 제어
- 상세한 감사 추적 요구사항
권한 부여 표준 및 프레임워크
XACML (eXtensible Access Control Markup Language)
XML 기반의 정책 언어와 처리 모델을 제공하는 표준으로, 속성 기반 접근 제어(ABAC)를 구현하는 데 사용된다.
구성 요소:
- PAP(Policy Administration Point): 정책 관리
- PDP(Policy Decision Point): 정책 결정
- PEP(Policy Enforcement Point): 정책 집행
- PIP(Policy Information Point): 속성 정보 제공
장점:
- 세분화된 정책 표현이 가능하다.
- 다양한 환경과 조직 간에 정책을 공유할 수 있다.
- 많은 기업용 솔루션에서 지원한다.
단점:
- 복잡하고 구현하기 어렵다.
- 성능 오버헤드가 발생할 수 있다.
- XML 구문이 번거롭고 읽기 어려울 수 있다.
OPA (Open Policy Agent)
클라우드 네이티브 애플리케이션을 위한 오픈소스 정책 엔진으로, Rego라는 선언적 정책 언어를 사용한다.
특징:
- 선언적 정책 언어(Rego)
- JSON/YAML 데이터 모델
- 컨테이너와 마이크로서비스 아키텍처에 최적화
- Kubernetes 통합
장점:
- 클라우드 네이티브 환경에 적합하다.
- 경량화되고 높은 성능을 제공한다.
- 다양한 시스템과 통합이 용이하다.
단점:
- 학습 곡선이 가파를 수 있다.
- 복잡한 규칙에 대한 디버깅이 어려울 수 있다.
OAuth 2.0 + UMA (User-Managed Access)
OAuth 2.0의 확장으로, 사용자가 여러 애플리케이션과 서비스에 걸쳐 자신의 리소스에 대한 접근을 관리할 수 있게 한다.
특징:
- 사용자 중심의 권한 관리
- 자원 세트(Resource Sets)와 정책
- 클레임 토큰 기반 권한 부여
- 권한 부여 서버(Authorization Server)와 리소스 서버(Resource Server) 분리
장점:
- 사용자가 자신의 데이터 접근을 직접 제어할 수 있다.
- 다양한 애플리케이션과 서비스에 일관된 권한 관리를 제공한다.
- OAuth 2.0 기반 시스템과 호환된다.
단점:
- 구현이 복잡하다.
- 아직 널리 채택되지 않았다.
- 최종 사용자 인터페이스가 복잡할 수 있다.
권한 부여의 미래 동향
제로 트러스트 권한 부여 (Zero Trust Authorization)
네트워크 위치나 사용자 신원만으로 접근 권한을 부여하지 않고, 매 요청마다 다양한 요소를 고려하여 지속적으로 접근 권한을 검증하는 모델이다.
핵심 원칙:
- “항상 검증, 절대 신뢰하지 않음”
- 모든 요청을 잠재적 위협으로 간주
- 최소 권한 접근
- 지속적인 인증과 권한 부여
- 종합적인 보안 모니터링
발전 방향:
- 실시간 위험 평가 기반 접근 제어
- 행동 분석과 머신러닝을 통한 이상 탐지
- 세션 기반이 아닌 요청 기반의 권한 부여
용어 정리
용어 | 설명 |
---|---|