정책 기반 접근 제어 시스템 구현
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
개발 툴
대상자
- API 개발자 및 보안 시스템 설계자
- 중간 수준 Python/FASTAPI 경험자
- 권한 체크 로직 중복 제거 및 모듈화 필요 시
핵심 요약
- 정책 기반 접근 제어 시스템을 사용해
if
문으로 분산된 권한 체크를 중심화 @require_any
데코레이터를 통해 사전 체크(pre-check)와 사후 체크(post-check) 정책을 동시 적용AccessPolicy
추상 클래스를 상속한 3가지 주요 정책(RequireIssuerIdPolicy
,RequireAnyRolePolicy
,RequireOrganizationAdminPolicy
) 구현
섹션별 세부 요약
1. 문제 정의: 분산된 권한 체크
- 기존 시스템에서
/user/123
조회 시 4가지 조건에 따라 접근 허용 여부 판단 - 중복된
if context.issuer_id != user_id
로직으로 인한 코드 품질 저하 - 사전 체크(예: 사용자 권한)와 사후 체크(예: 조직 관리자 여부) 구분 필요
2. 데코레이터 기반 접근 제어 구현
@require_any([정책1, 정책2, ...])
데코레이터를 통해 다중 정책 조합 가능require_any
데코레이터 내부 로직:context
객체에서 사용자 상태 확인 후 비활성 사용자 거부pre_passed
정책 먼저 실행 후 예외 발생 시 즉시 거부post_checks
정책은 함수 실행 후 추가 체크 수행
3. 정책 클래스 구조
- 추상 클래스
AccessPolicy
is_post_check()
추상 메서드로 사전/사후 체크 구분check()
메서드로 기본 권한 검증 로직- 구체 클래스
RequireIssuerIdPolicy
: 사용자 ID 일치 여부 체크RequireAnyRolePolicy
: 사용자 역할 기반 접근 허용RequireOrganizationAdminPolicy
: 조직 관리자 여부 체크 (사후 체크 기능 포함)
4. 사전/사후 체크 구분
- 사전 체크(pre-check):
- 사용자 권한 등 즉시 판단 가능한 조건
- 예:
Is user an admin?
- 사후 체크(post-check):
- 리소스 조회 후 조직 ID 등 추가 정보 필요
- 예:
Is the user a participant in this meeting?
결론
@require_any
데코레이터를 통해 중복된 권한 체크 제거하고 확장 가능한 정책 체계 구축AccessPolicy
추상 클래스를 활용해 새로운 정책 추가 시 기존 코드 변경 없이 확장 가능- 사전 체크로 리소스 조회 전 즉시 거부 처리해 성능 개선
- 예:
@require_any([RequireIssuerIdPolicy(), RequireAnyRolePolicy([UserRole.ADMIN])])
사용하여 다중 조건 병합 가능