contexa-iam

정책 관리

정책 생명주기 관리를 위한 PAP (Policy Administration Point) 서비스: CRUD 작업, 자동 역할 기반 동기화, Policy Center 작성 흐름, 정책 버전 관리, AI 기반 보강, 비즈니스 규칙 변환.

PolicyService

정책 CRUD 작업을 위한 기본 서비스입니다. Policy 엔티티의 생성, 수정, 삭제 및 권한 기반 동기화를 처리합니다.

Java
public interface PolicyService {
    List<Policy> getAllPolicies();
    Policy findById(Long id);
    Policy createPolicy(PolicyDto policyDto);
    void updatePolicy(PolicyDto policyDto);
    void deletePolicy(Long id);
    void synchronizePolicyForPermission(Permission permission);
}

PolicyDto 구조

PolicyDto는 대상, 규칙, 조건을 포함한 전체 정책 정의를 전달합니다:

필드타입설명
idLong정책 ID (생성 시 null)
nameString고유한 정책 이름
descriptionString사람이 읽을 수 있는 설명
effectPolicy.EffectALLOW 또는 DENY
priorityint평가 우선순위 (낮을수록 높음)
targetsList<TargetDto>이 정책이 적용되는 리소스 대상. 각 대상은 URL 패턴 또는 METHOD 타입을 지정합니다.
rulesList<RuleDto>이 정책의 인가 조건을 정의하는 규칙 목록. 각 규칙은 하나 이상의 SpEL 조건을 포함합니다.

PolicySynchronizationService

역할-권한 할당이 변경되면 자동으로 정책을 생성하고 업데이트합니다. Spring의 @EventListener를 통해 RolePermissionsChangedEvent를 수신하고 @Async로 비동기 실행합니다.

Java
public class PolicySynchronizationService {

    @Async
    @EventListener
    @Transactional
    public void handleRolePermissionsChange(
            RolePermissionsChangedEvent event) { ... }
}

동기화 흐름

정책 동기화 파이프라인
RolePermissionsChangedEvent 역할-권한 할당 변경 시 트리거됨
역할 로드 권한 및 관리 리소스와 함께 역할 조회
대상 생성 ManagedResource(URL 또는 METHOD 타입)에서 대상 생성
조건 생성 hasAuthority('ROLE_NAME') and (권한 표현식)
PolicyDto 생성 Name: AUTO_POLICY_FOR_{roleName}, Priority: 500
정책 Upsert 이름으로 기존 정책 존재? 업데이트 : 새로 생성

자동 생성 정책은 AUTO_POLICY_FOR_{roleName} 명명 규칙과 우선순위 500을 사용합니다. 조건 표현식은 역할 권한 검사와 or로 결합된 개별 권한 권한 검사를 결합합니다.

PolicyBuilderService

템플릿 조회, 시각적 정책 모델 변환, 충돌 분석을 담당하는 서버 계층 서비스입니다. 현재 OSS UI에서는 독립 Builder 템플릿보다 Policy Center의 통합 작성 흐름이 기본 운영 화면입니다.

Java
public interface PolicyBuilderService {
    List<PolicyTemplateDto> getAvailableTemplates(PolicyContext context);
    Policy buildPolicyFromVisualComponents(VisualPolicyDto visualPolicyDto);
    List<PolicyConflictDto> detectConflicts(Policy newPolicy);
}

PolicyEnrichmentService

PolicyTranslator에 위임하여 정책 엔티티를 사람이 읽을 수 있는 설명으로 보강합니다. 이 서비스는 정책 조건의 SpEL 표현식을 자연어 설명으로 변환합니다.

Java
public class PolicyEnrichmentService {

    private final PolicyTranslator policyTranslator;

    public void enrichPolicyWithFriendlyDescription(Policy policy) {
        // Translates policy rules/conditions to human-readable text
        // Sets policy.friendlyDescription
    }
}

예시: 조건 hasAuthority('ROLE_ADMIN') and isAuthenticated()가 있는 정책은 "(User has authority ROLE_ADMIN and User is authenticated)"로 보강됩니다.

BusinessPolicyService

비즈니스 수준의 접근 규칙과 기술적 정책 정의 간의 양방향 변환을 제공하여 비기술 관리자가 인가를 관리할 수 있게 합니다.

Java
public interface BusinessPolicyService {
    // Create a technical policy from a business rule definition
    Policy createPolicyFromBusinessRule(BusinessPolicyDto dto);

    // Update an existing policy from business rule changes
    Policy updatePolicyFromBusinessRule(Long policyId, BusinessPolicyDto dto);

    // Get the business rule representation for a technical policy
    BusinessPolicyDto getBusinessRuleForPolicy(Long policyId);

    // Translate an existing technical policy to business rule format
    BusinessPolicyDto translatePolicyToBusinessRule(Long policyId);
}

정책 엔티티 모델

정책 엔티티 구조
Policy name (unique) | description | effect: ALLOW / DENY | priority: int | source | approvalStatus | isActive | friendlyDescription | approvedBy | approvedAt | confidenceScore | aiModel | reasoning
PolicyTarget (set) targetType: URL | METHOD -- targetIdentifier: URL 패턴 또는 메서드 시그니처 -- httpMethod: GET, POST, ANY 등
PolicyRule (set) description: String
PolicyCondition (규칙당 set) expression: String (SpEL) | authorizationPhase: PRE_AUTHORIZE / POST_AUTHORIZE

정책 작성 흐름

현재 OSS 정책 작성 경험은 Policy Center를 중심으로 동작합니다. 관련 관리자 라우트와 정책 상세 편집이 같은 생명주기를 지원하며, 필요 시 레거시 Builder 경로를 함께 사용할 수 있습니다.

5단계 워크플로

  1. 이름 & 설명 — 정책 이름, 설명, 효과(ALLOW/DENY) 설정
  2. 대상 — 이 정책이 적용되는 URL 패턴 또는 메서드 식별자 정의
  3. 규칙 — 우선순위 순서가 있는 ALLOW/DENY 규칙 구성
  4. 조건 — 각 규칙에 대한 SpEL 표현식 작성
  5. 조건 선택기 — 호환되는 조건 템플릿에서 선택

From-Resource 모드

Policy Center의 통합 리소스 영역에서 선택한 리소스에서 정책 생성을 시작하거나, 레거시 /admin/policy-builder/from-resource 경로를 사용하면 from-resource 모드로 진입합니다:

  • 리소스 대상 정보가 자동 채워짐
  • 호환되는 조건 템플릿만 표시됨 (ConditionCompatibilityService로 필터링)
  • 도메인별 변수 및 ABAC 적용 가능성 고려

조건 템플릿 시스템

조건 템플릿은 정책 생성을 간소화하는 재사용 가능한 SpEL 표현식 패턴입니다.

3계층 분류

계층이름범위예시
1UNIVERSAL모든 리소스시간 기반 제한, IP 범위 확인
2CONTEXT_DEPENDENT도메인별사용자 소유권 검증, 부서 확인
3CUSTOM_COMPLEX고급다중 팩터 조건, 복합 규칙

AI 자동 생성

AutoConditionTemplateService가 조건 템플릿을 자동으로 생성합니다:

  • 리소스 타입 및 접근 패턴 기반의 배치 생성
  • 각 템플릿에 대한 복잡도 점수(1-10 척도)
  • 위험한 패턴을 차단하는 SpEL 안전 검증

조건 호환성

ConditionCompatibilityService가 리소스별 조건을 필터링합니다:

  • 도메인 호환성 — 조건 도메인을 리소스 도메인에 매칭
  • 사용 가능한 변수 — 참조된 SpEL 변수가 평가 컨텍스트에 존재하는지 확인
  • ABAC 적용 가능성 — 속성 기반 접근 제어 조건의 관련성 확인

Business Policy Service

BusinessPolicyService는 비즈니스 수준의 인가 규칙을 기술적 SpEL 정책 조건으로 변환합니다.

SpEL 표현식 변환

입력 타입생성된 SpEL예시
역할 기반hasAuthority('ROLE_NAME')hasAuthority('ROLE_ADMIN')
권한 기반hasPermission(targetId, 'DOMAIN', 'ACTION')hasPermission(#id, 'USER', 'READ')
AI 액션#ai.isAllowed() and hasAuthority('ROLE_USER')#ai.isAllowed() and hasAuthority('ROLE_USER')
사용자 정의 SpEL검증 후 직접 사용isAuthenticated() and hasIpAddress('10.0.0.0/8')

안전 검증

사용자 정의 SpEL 표현식은 저장 전 다음을 차단하기 위해 검증됩니다:

  • 시스템 레벨 메서드 호출
  • 리플렉션 기반 접근
  • 런타임 클래스 로딩
  • 파일 시스템 작업

정책 생성 흐름

비즈니스 정책 생성 파이프라인
BusinessPolicyDto UI 폼 입력
Policy 엔티티 DTO에서 생성
보강 사람이 읽을 수 있는 설명
DB에 저장 정책 영속화
핫 리로드 reloadAuthorizationSystem()

Policy Wizard: 빠른 권한 부여 가이드

Policy Wizard는 Policy Center의 quick-create 흐름을 설명하는 빠른 권한 부여 경로입니다. 복잡한 수동 조건 편집 없이 역할, 권한, CRUD 또는 저장된 SpEL 중심으로 단순한 정책을 만들 때 사용합니다.

Wizard 사용 시기

  • 복잡한 조건 없는 단순 역할 기반 권한 부여
  • 하나 이상의 역할에 대한 단일 리소스 접근 부여
  • 초기 리소스 온보딩 시 빠른 설정
  • 시간 기반, IP 기반, AI 지원 조건 불필요

단계별 가이드

Policy Wizard: 4단계 빠른 권한 부여
1
Policy Center 리소스에서 시작
/admin/policy-center?tab=create 에서 리소스를 선택하고 quick-create 흐름을 시작합니다. 선택한 리소스와 관련 권한이 미리 채워집니다.
2
권한 선택
부여할 권한을 선택합니다. 목록은 선택한 리소스와 호환되는 권한만 표시하도록 필터링됩니다.
3
대상 역할 / 그룹 선택
권한을 받을 하나 이상의 역할 또는 그룹을 선택합니다. 마법사가 중복을 방지하기 위해 현재 할당을 표시합니다.
4
확인 및 커밋
요약을 검토하고 저장합니다. 현재 quick-create 흐름은 정책을 저장하고 버전을 기록하며, 연결된 리소스 상태를 갱신하고 인가 매핑을 다시 로드합니다.

Wizard가 자동 생성하는 항목

확인하면 마법사가 다음 엔티티를 자동으로 생성합니다:

Permission 리소스에 연결됨
Policy ALLOW 효과, 역할 기반 조건
역할 할당 선택한 역할에 권한 할당됨

Policy Center 수동/AI 작성: 고급 정책 생성

고급 정책 작성은 현재 Policy Center의 수동/AI 지원 흐름을 중심으로 동작합니다. 대상, 규칙, 조건, 조건 템플릿에 대한 전체 제어가 필요할 때 사용합니다.

Builder 사용 시기

  • 시간 기반, IP 기반, 소유권 조건이 있는 정책
  • AI 지원 인가 표현식 (#ai.isAllowed())
  • 다양한 조건 조합의 다중 규칙 정책
  • DENY 정책 또는 우선순위에 민감한 구성
  • 사용자 정의 SpEL 표현식이 필요한 정책

단계별 가이드

Policy Builder: 5단계 고급 생성
1
이름과 설명
고유한 정책 이름, 사람이 읽을 수 있는 설명, 정책 효과(ALLOW 또는 DENY)를 설정합니다. 우선순위 수준을 선택합니다(낮은 숫자 = 높은 우선순위).
2
대상
이 정책이 적용되는 URL 패턴(예: /api/users/**) 또는 메서드 식별자를 정의합니다. HTTP 메서드(GET, POST, ANY)를 지정합니다. from-resource 모드에서는 이 단계가 미리 채워집니다.
3
규칙
하나 이상의 규칙을 구성합니다. 각 규칙은 자체 설명을 가질 수 있으며 함께 평가되는 조건을 포함합니다. 규칙은 우선순위 순서로 평가됩니다.
4
조건
각 규칙에 대한 SpEL 표현식을 작성합니다. 조건은 누가 어떤 상황에서 대상에 접근할 수 있는지를 정의합니다. 구문 검증이 포함된 표현식 편집기를 사용합니다.
5
조건 선택기
호환되는 조건 템플릿(UNIVERSAL, CONTEXT_DEPENDENT, CUSTOM_COMPLEX)을 찾아 선택합니다. 시스템이 대상 리소스 컨텍스트를 기반으로 템플릿을 추천합니다.

컨텍스트 인식 모드 (from-resource)

Policy Center에서 선택한 리소스에서 시작하거나 레거시 /admin/policy-builder/from-resource 경로를 사용하면 from-resource 모드로 진입합니다:

  • 미리 채워진 대상: 리소스 URL 패턴 또는 메서드 시그니처가 정책 대상으로 자동 설정됨
  • 필터링된 조건: ConditionCompatibilityService가 리소스 도메인과 호환되는 조건 템플릿만 표시하도록 필터링
  • 도메인별 변수: 리소스 타입에 따라 사용 가능한 SpEL 컨텍스트 변수가 표시됨
  • ABAC 적용 가능성: 속성 기반 접근 제어 조건이 리소스와 관련 있을 때만 표시됨

조건 템플릿 선택

계층이름사용 시기AI 추천
1UNIVERSAL모든 리소스에 적용되는 조건: 시간 기반, IP 범위, 인증 수준일반 접근 제어에 추천
2CONTEXT_DEPENDENT도메인별 조건: 소유권 검사, 부서 확인, 데이터 민감도리소스 도메인 분석 기반 추천
3CUSTOM_COMPLEX다중 팩터 조건: 역할 + AI + 시간 검사 결합, 복합 인가 규칙보안 태세 분석 기반 AI 생성

AI 지원 조건 추천

Policy Builder는 AI 엔진과 통합되어 조건을 추천합니다. 리소스에 대한 정책을 생성할 때 AI가 분석하는 항목:

  • 리소스 타입 및 데이터 민감도
  • 유사 리소스의 기존 정책
  • 조직의 보안 태세
  • 리소스 도메인의 일반적인 접근 패턴

추천 사항은 한 번의 클릭으로 적용할 수 있는 제안 조건 템플릿으로 표시됩니다.

Wizard vs. Builder: 결정 가이드

어떤 도구를 사용해야 할까요?

Policy Wizard (빠른 권한 부여)

  • 단순 역할-권한 부여
  • 사용자 정의 조건 불필요
  • 단일 리소스, 하나 이상의 역할
  • ALLOW 효과만
  • 4단계, 30초 이내
  • 모든 엔티티 자동 생성

적합: 초기 리소스 온보딩, 직관적인 접근 부여, 개발 중 빠른 설정.

VS

Policy Builder (고급)

  • 복잡한 다중 조건 정책
  • 시간, IP, AI, 소유권 조건
  • 정책당 다중 규칙
  • ALLOW 또는 DENY 효과
  • 5단계, 완전한 제어
  • AI 지원 추천

적합: 프로덕션 보안 정책, 컴플라이언스 요구사항, 세밀한 접근 제어.

AI 정책 승인 워크플로

AI 엔진이 생성한 정책은 적용 전 사람의 감독을 보장하기 위한 승인 워크플로를 따릅니다.

승인 생명주기

AI 생성 정책 승인 흐름
AI가 정책 생성 source = AI_GENERATED 또는 AI_EVOLVED, approvalStatus = PENDING
PENDING 검토 Policy Center 목록/상세 흐름에는 보이지만 활성 인가 매핑에는 로드되지 않음
APPROVED 관리자 승인 -- isActive = true일 때 적용 가능
REJECTED 관리자 거부 -- 보관되며 적용되지 않음

적용 규칙

CustomDynamicAuthorizationManager는 다음 기준을 모두 충족하는 정책만 평가합니다:

  • isActive = true -- 정책이 현재 활성화됨
  • approvalStatusPENDING 또는 REJECTED가 아님 -- AI 생성 정책은 APPROVED가 필요하고, 수동 정책은 보통 NOT_REQUIRED를 사용합니다.

일반 quick/manual Policy Center 흐름으로 생성된 정책은 보통 source = MANUAL, approvalStatus = NOT_REQUIRED를 사용하며 저장과 활성화 직후 적용될 수 있습니다.

관리자 검토 프로세스

  1. /admin/policy-center?tab=list를 열고 approvalStatus = PENDING 정책을 찾습니다.
  2. 정책 세부 사항 검토: 이름, 설명, 대상, 규칙, 조건
  3. AI 생성 친화적 설명의 정확성 확인
  4. Policy Center 시뮬레이터 또는 /admin/policy-center/api/simulate로 승인 전 영향을 미리 확인합니다.
  5. 검증, AI 검증, 영향 분석 결과를 함께 검토하여 기존 정책과의 충돌을 확인합니다.
  6. /admin/policies/{id}/approve 또는 /admin/policies/{id}/reject를 통해 승인 또는 거부합니다.

조건 템플릿 예제

다음 예제는 정책 규칙에서 사용되는 일반적인 조건 템플릿을 보여줍니다. 각 템플릿은 인가 시점에 평가되는 SpEL 표현식입니다.

카테고리설명SpEL 표현식
시간 기반 업무 시간(오전 9시~오후 6시) 동안만 접근 허용 T(java.time.LocalTime).now().isAfter(T(java.time.LocalTime).of(9,0)) and T(java.time.LocalTime).now().isBefore(T(java.time.LocalTime).of(18,0))
IP 범위 내부 네트워크에서만 접근 허용 hasIpAddress('10.0.0.0/8')
소유권 AI가 승인하고 사용자가 리소스에 대한 권한이 있으면 접근 허용 #ai.isAllowed() and hasPermission(#id, 'USER', 'READ')
AI 평가 AI 분석이 챌린지 없이 통과하면 접근 허용 #ai.isAllowed() and !#ai.needsChallenge()
결합 (역할 + AI) 관리자는 무조건 접근 허용, 그 외에는 AI 승인과 권한 검사 필요 hasAnyAuthority('ROLE_ADMIN') or (#ai.isAllowed() and hasPermission(#id, 'DOCUMENT', 'UPDATE'))
역할 기반 특정 역할을 가진 사용자에게 접근 허용 hasAuthority('ROLE_MANAGER')
인증 수준 완전 인증 필요 (remember-me 제외) isFullyAuthenticated()

Policy Center REST API

현재 Policy Center 서버 표면은 /admin/policy-center를 중심으로 구성되며, 분석 API는 /admin/policy-center/api/, 폼 저장은 /admin/policy-center/create-policy, business-rule 생성은 /admin/api/policies/build-from-business-rule 경로를 사용합니다.

정책 CRUD

메서드엔드포인트설명
POST/api/quick-create간소화된 요청 본문으로 정책을 빠르게 생성합니다.
POST/create-policyPolicy Center 수동 작성 폼의 전체 PolicyDto를 저장합니다.
POST/api/batch-create하나의 요청으로 여러 리소스에 대한 정책을 일괄 생성합니다.
POST/api/validate저장하지 않고 정책 정의를 검증합니다.
POST/api/validate-quick빠른 생성 정책 정의를 검증합니다.

정책 분석

메서드엔드포인트설명
POST/api/simulate테스트 요청에 대해 정책을 시뮬레이션하여 결정을 미리 봅니다.
POST/api/impact-analysis정책 변경이 기존 리소스에 미치는 영향을 분석합니다.
GET/api/{policyId}/ai-validation정책에 대한 AI 생성 검증 보고서를 가져옵니다.
GET/api/matrix정책 매트릭스 보고서(역할 x 리소스 x 작업)를 생성합니다.

정책 버전 관리

버전 관리 엔드포인트는 실제로 구현되어 있습니다. 현재 OSS Policy Center 템플릿에는 전용 버전 히스토리 패널이 없어서, 자동화 도구나 향후 UI 확장에서 주로 사용됩니다.

메서드엔드포인트설명
GET/api/{policyId}/versions타임스탬프와 변경 요약이 포함된 정책의 모든 버전을 나열합니다.
POST/api/{policyId}/rollback/{versionNumber}정책을 이전 버전으로 롤백합니다.
GET/api/{policyId}/versions/{versionNumber}저장된 단일 버전 스냅샷을 조회합니다.
GET/api/{policyId}/versions/compare?v1=...&v2=...두 저장 버전을 비교해 필드 단위 차이를 보여줍니다.

리소스 및 권한 쿼리

메서드엔드포인트설명
GET/api/roles정책 대상 할당에 사용 가능한 역할을 나열합니다.
GET/api/resources등록된 리소스(URL, METHOD 유형)를 나열합니다.
GET/api/available-permissions리소스에 사용 가능한 권한을 나열합니다.
GET/api/conditions호환성 필터링이 적용된 조건 템플릿을 나열합니다.
GET/api/stats정책 통계(전체, 활성, 대기, 충돌)를 가져옵니다.
GET/api/policy-summaries상태 및 승인 정보가 포함된 정책 요약을 가져옵니다.
GET/api/spel-permissions모든 활성 정책의 SpEL 권한 표현식을 가져옵니다.

마이그레이션 및 유지보수

메서드엔드포인트설명
POST/api/reset-policy-status선택한 리소스의 정책 연결 상태를 초기화합니다.
POST/api/migrate-to-crud레거시 SpEL 표현식을 CRUD 기반 권한으로 마이그레이션합니다.
POST/api/cleanup-old-permissions고아 권한 항목을 정리합니다.
POST/refresh-resources데이터베이스에서 리소스 캐시 새로고침을 트리거합니다.