동적 URL 인가

동적 인가란?

기존 Spring Security는 Java 코드에 정의된 정적 URL 매처를 사용합니다. 인가 규칙을 변경하려면 코드 수정, 빌드, 재배포가 필요합니다. Contexa의 CustomDynamicAuthorizationManager는 근본적으로 다른 접근 방식을 취합니다: 인가 정책을 데이터베이스에서 로드하여 런타임에 평가합니다.

이 아키텍처는 세 가지 핵심 기능을 가능하게 합니다:

• 재배포 없는 정책 변경 — 애플리케이션을 다시 빌드하거나 배포하지 않고도 인가 규칙을 수정, 추가, 삭제할 수 있습니다. 편집 후 핫 리로드를 트리거하면 재초기화됩니다.
• 관리자 콘솔 관리 — 현재 OSS 기준의 기본 관리 화면은 Policy Center이며, 관련 관리자 정책 흐름을 통해 정책을 생성하고 관리할 수 있습니다.
• AI 생성 정책 통합 — AI가 생성하고 발전시킨 정책을 사람의 승인 후 인가 파이프라인에 통합할 수 있습니다.

동작 방식

CustomDynamicAuthorizationManager는 Spring Security의 AuthorizationManager<RequestAuthorizationContext> 인터페이스를 구현합니다. 데이터베이스에 저장된 정책과 Spring Security의 런타임 평가 엔진 사이의 다리 역할을 합니다.

정책 평가 흐름

단계별 평가

1. PolicyRetrievalPoint (PRP)가 ContextRefreshedEvent 리스너를 통해 애플리케이션 시작 시 데이터베이스에서 모든 정책을 로드합니다.
2. 각 정책에 대해 CustomDynamicAuthorizationManager가 URL 대상을 추출하고 정책을 SpEL 표현식 문자열로 변환합니다.
3. PolicyExpressionConverter가 활성 URL 정책을 Spring Security가 평가할 SpEL 문자열로 정규화합니다.
4. 요청 시, ExpressionAuthorizationManagerResolver가 수신 요청 URL을 캐시된 RequestMatcherEntry 목록에 매칭합니다.
5. 매칭된 SpEL 표현식이 현재 Authentication 컨텍스트에 대해 평가됩니다.
6. AI 생성 정책(source = AI_GENERATED 또는 AI_EVOLVED)은 approvalStatus가 APPROVED가 아닌 한 완전히 건너뜁니다.
7. 인가 결정이 적용되며, 거부 결과는 요청 URI, 액션, 결과, 선택적 AI 평가 맥락과 함께 CentralAuditFacade에 기록됩니다.

정적 + 동적 통합

Contexa의 동적 인가는 표준 Spring Security 정적 규칙과 공존합니다. 정적 규칙이 필터 체인(Filter Chain)에서 먼저 평가되며, .anyRequest()에 도달하는 요청만 동적 인가 매니저가 처리합니다.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
        // Static rules: evaluated first, bypasses dynamic authorization
        .requestMatchers("/", "/home", "/css/**", "/js/**").permitAll()
        .requestMatchers("/login", "/register").permitAll()
        .requestMatchers("/user/list/**").hasRole("USER")

        // Dynamic authorization: all remaining requests
        // Policies loaded from database, hot-reloadable at runtime
        .anyRequest().access(customDynamicAuthorizationManager)
    );
    return http.build();
}

평가 흐름

중요 동작

• 순서가 중요합니다 — 정적 requestMatchers는 .anyRequest() 앞에 선언해야 합니다. Spring Security는 위에서 아래로 평가하며 첫 번째 매칭을 사용합니다.
• 단락 평가(Short-circuit evaluation) — 정적 매처가 매칭되면 동적 매니저는 호출되지 않습니다. 이는 permitAll() 라우트가 데이터베이스 정책으로 제한될 수 없음을 의미합니다.
• 중복 지정 비권장 — 이미 정적으로 매칭된 URL에 대해 데이터베이스 정책을 정의하지 마십시오. 정적 규칙이 항상 우선합니다.
• 감사(Audit) 영향 — 정적으로 허용된 요청은 XACML 엔진을 통과하지 않으며 인가 감사 추적(Audit Trail)에 나타나지 않습니다.

매칭되지 않는 요청의 기본 결정

요청 URL이 데이터베이스의 어떤 정책과도 매칭되지 않으면 CustomDynamicAuthorizationManager는 기본 인가 결정을 반환합니다. 기본적으로 매칭되지 않는 요청은 허용(AuthorizationDecision(true))됩니다. 즉, 명시적으로 정의된 DENY 정책만 접근을 차단합니다.

구성 패턴

글로벌 커스터마이저 내의 authorizeHttpRequests 블록은 정적 매처가 동적 인가 엔진과 어떻게 상호작용하는지를 결정합니다. 보안 태세에 맞는 패턴을 선택하십시오.

패턴 1: 공개 자산 + 완전 동적

가장 일반적인 패턴입니다. 정적 자산은 인가를 완전히 우회하고, 나머지 모든 것은 XACML 정책 엔진이 평가합니다.

http.authorizeHttpRequests(authReq -> authReq
    .requestMatchers("/css/**", "/js/**", "/images/**", "/favicon.ico").permitAll()
    .anyRequest().access(customDynamicAuthorizationManager)
);

패턴 2: 관리자 고정 + 나머지 동적

특정 잘 알려진 라우트가 자산 경로와 함께 정적으로 허용되고, 나머지 라우트는 동적 평가를 거치는 하이브리드 접근 방식입니다. 정책 상태와 관계없이 특정 페이지에 대한 보장된 접근이 필요할 때 유용합니다.

http.authorizeHttpRequests(authReq -> authReq
    .requestMatchers("/css/**", "/js/**").permitAll()
    .requestMatchers("/home", "/user/list/**").permitAll()
    .anyRequest().access(customDynamicAuthorizationManager)
);

패턴 3: 완전 동적

정적 자산을 포함한 모든 요청이 정책 엔진에 의해 평가되는 엔터프라이즈 패턴입니다. 모든 접근 규칙이 컴파일 시점 예외 없이 데이터베이스에 있습니다.

http.authorizeHttpRequests(authReq -> authReq
    .anyRequest().access(customDynamicAuthorizationManager)
);

패턴 비교

핵심 구현

매니저는 Spring 컨텍스트 리프레시 시 초기화되며 런타임 정책 업데이트를 위한 핫 리로드를 지원합니다.

public class CustomDynamicAuthorizationManager
        implements AuthorizationManager<RequestAuthorizationContext> {

    private final PolicyRetrievalPoint policyRetrievalPoint;
    private final ExpressionAuthorizationManagerResolver managerResolver;
    private final ContextHandler contextHandler;
    private final ZeroTrustEventPublisher zeroTrustEventPublisher;
    private final AuthorizationMetrics metricsCollector;

    // Initializes on application context refresh
    @EventListener
    public void onApplicationEvent(ContextRefreshedEvent event) {
        initialize();
    }

    @Override
    public AuthorizationDecision check(
            Supplier<Authentication> authenticationSupplier,
            RequestAuthorizationContext context) {
        // 1. Match request URL to cached RequestMatcherEntry
        // 2. Resolve the SpEL expression for the matched policy
        // 3. Evaluate the expression against the Authentication
        // 4. Log result to CentralAuditFacade
        // 5. Return AuthorizationDecision(granted/denied)
    }

    // Hot-reload: clears PRP cache and re-initializes mappings
    public synchronized void reload() {
        policyRetrievalPoint.clearUrlPoliciesCache();
        policyRetrievalPoint.clearMethodPoliciesCache();
        initialize();
    }
}

정책 모델

데이터베이스에 저장된 각 Policy 엔티티는 대상, 규칙, AI 생성 정책 메타데이터를 포함한 전체 인가 정의를 담고 있습니다.

public class PolicyDto {
    Long id;
    String name;
    String description;
    Policy.Effect effect;
    int priority;
    List targets;
    List rules;
    Policy.PolicySource source;
    Policy.ApprovalStatus approvalStatus;
    Boolean isActive;
    Double confidenceScore;
    String aiModel;
}

정책 필드 참조

PolicyTarget

각 대상은 리소스 유형, 대상 식별자, 선택적 HTTP 메서드, 정렬 순서, 소스 유형을 함께 표현합니다.

public class TargetDto {
    String targetType;         // URL 또는 METHOD
    String targetIdentifier;   // 예: "/api/admin/**"
    String httpMethod;         // GET, POST, PUT, DELETE, ...
    int targetOrder;
    String sourceType;         // RESOURCE 또는 MANUAL
}

PolicyRule과 Conditions

각 규칙은 하나 이상의 조건을 포함합니다. 조건은 요청 시 평가되는 실제 SpEL 표현식 문자열을 담고 있습니다.

public class PolicyRule {
    String name;
    List<PolicyCondition> conditions;
}

public class PolicyCondition {
    String expression;  // SpEL expression, e.g. "hasAnyAuthority('ROLE_ADMIN')"
}

SpEL 표현식 지원

Contexa는 Zero Trust AI 액션 검사를 위한 AbstractAISecurityExpressionRoot의 커스텀 메서드로 표준 Spring Security SpEL 표현식을 확장합니다.

표준 Spring Security 표현식

Zero Trust AI 표현식

이 표현식들은 AbstractAISecurityExpressionRoot에서 제공되며 Contexa의 Zero Trust AI 평가 파이프라인과 통합됩니다.

정책-표현식 변환 규칙

CustomDynamicAuthorizationManager의 getExpressionFromPolicy() 메서드는 다음 변환 로직을 적용합니다:

XACML 통합

동적 인가는 XACML 엔진(eXtensible Access Control Markup Language)에 의해 구동됩니다. 5개의 XACML 컴포넌트가 함께 작동하여 완전한 정책 생명주기를 관리합니다. 자세한 내용은 XACML 엔진 페이지를 참조하십시오.

사용 예제

다음 예제는 동적 인가 정책의 생성부터 적용까지의 전체 생명주기를 보여줍니다.

1단계: 정책 생성

정책은 현재 OSS 기준으로 Policy Center에서 생성하며, 서버 측 정책 API/서비스 경로를 통해서도 처리할 수 있습니다.

GET  /admin/policy-center
POST /admin/policy-center/create-policy
POST /admin/policy-center/api/quick-create
POST /admin/api/policies/build-from-business-rule

// 현재 OSS 작성 경로
// - Policy Center 폼 기반 작성
// - Policy Center의 quick-create 보조 경로
// - 비즈니스 규칙 기반 정책 초안 API

2단계: 데이터베이스에 정책 저장

PAP가 정책을 JPA 엔티티로 저장합니다: Policy, PolicyTarget, PolicyRule, PolicyCondition. 수동 생성 정책의 경우 source는 MANUAL로, approvalStatus는 NOT_REQUIRED로 설정됩니다.

3단계: 매니저가 정책을 인식

다음 핫 리로드(또는 애플리케이션 재시작) 시, CustomDynamicAuthorizationManager가 PRP에서 새 정책을 로드하고 RequestMatcherEntry 매핑을 생성합니다:

URL Pattern: /api/admin/**
HTTP Methods: GET, POST, PUT, DELETE
SpEL Expression: hasAuthority('ROLE_ADMIN')
Source: MANUAL
Approval: NOT_REQUIRED (active immediately)

4단계: 요청이 자동으로 보호됨

/api/admin/users로 요청이 들어올 때:

1. Request: GET /api/admin/users
2. CustomDynamicAuthorizationManager.check() is invoked
3. URL matches pattern /api/admin/** (Ant path matching)
4. SpEL expression "hasAuthority('ROLE_ADMIN')" is evaluated
5a. User has ROLE_ADMIN -> AuthorizationDecision(granted=true)
5b. User lacks ROLE_ADMIN -> AuthorizationDecision(granted=false) -> 403
6. 결과가 거부인 경우 CustomDynamicAuthorizationManager가 요청 URI, 액션, 결과, 사용 가능한 AI 맥락을 포함한 감사 이벤트를 기록

AI 생성 정책 예제

AI 모델이 정책을 생성하면 PENDING 승인 상태로 시스템에 입력되며, 사람 검토자가 승인할 때까지 적용되지 않습니다.

{
  "name": "AI: Restrict Sensitive Reports",
  "description": "AI-detected sensitive data endpoint requiring elevated access",
  "effect": "ALLOW",
  "priority": 90,
  "targets": [
    {
      "targetType": "URL",
      "targetIdentifier": "/api/reports/sensitive/**",
      "httpMethod": "GET",
      "targetOrder": 0,
      "sourceType": "RESOURCE",

    }
  ],
  "rules": [
    {
      "name": "Require manager role and AI clearance",
      "conditions": [
        { "expression": "hasAuthority('ROLE_MANAGER')" },
        { "expression": "#ai.isAllowed()" }
      ]
    }
  ],
  "source": "AI_GENERATED",
  "approvalStatus": "PENDING",
  "confidenceScore": 0.87,
  "aiModel": "contexa-policy-gen-v2"
}

이 정책은 관리자가 Policy Center 상세/승인 흐름 또는 서버 측 정책 엔드포인트를 통해 approvalStatus를 APPROVED로 바꿀 때까지 인가 평가에서 건너뜁니다.

구성

동적 인가는 contexa-iam 모듈이 클래스패스에 있으면 자동으로 활성화됩니다. 런타임 동작은 IAM 및 Zero Trust 속성으로 제어되며, 현재 OSS 관리 화면의 중심은 Policy Center와 관련 관리자 흐름입니다.

핫 리로드

Policy Center나 관련 관리자 서비스에서 정책이 변경되면, 서버 측 흐름이 CustomDynamicAuthorizationManager.reload()를 호출해 PRP 캐시를 지우고 URL 매핑을 다시 구성합니다. 현재 OSS 코드베이스에는 이 페이지에서 별도로 호출할 수 있는 공개 reload REST 엔드포인트가 노출되어 있지 않습니다.

authorizationManager.reload();
// PRP 캐시를 지우고 RequestMatcherEntry 매핑을 다시 구성

관련 구성

IAM 속성 구성은 구성 문서를 참조하십시오. 핵심 속성은 다음과 같습니다.

Zero Trust 속성

임계값 속성

캐시 및 세션 속성

관련 문서

• 인가 개요 — 전체 XACML 아키텍처, AI 표현식, 빠른 시작
• 정책 관리 — 정책 생명주기, Policy Center 작성 흐름, 조건 템플릿
• 리소스 스캐너 — 자동 리소스 발견 및 엔드투엔드 워크플로
• 권한 평가기 — hasPermission()을 사용한 메서드 레벨 권한 평가
• 관리자 콘솔 — 정책, 역할, 권한 관리를 위한 UI

기본 정책 관리

들어오는 요청이 구성된 URL 정책과 하나도 매칭되지 않으면 CustomDynamicAuthorizationManager.check(...)는 new AuthorizationDecision(true)로 폴백합니다. 즉 현재 OSS 런타임에서는 매칭되지 않은 요청이 기본적으로 허용됩니다.

// 기본 동작: 매칭되지 않은 요청은 허용
return new AuthorizationDecision(true);

기본 거부 방향으로 이동

현재 OSS 코드베이스는 매칭되지 않은 URL 요청에 대해 default-policy 같은 전용 YAML 속성을 제공하지 않습니다. 기본 거부 방향으로 운영하려면 보호 대상 URL 영역에 대해 포괄적인 DENY 정책을 명시적으로 만들거나, 인가 매니저를 코드에서 직접 커스터마이즈해야 합니다.

관리자 콘솔을 통한 URL 정책 생성

현재 OSS 기준 URL 기반 인가 정책 생성의 기본 UI는 Policy Center입니다. 다음 단계에 따라 URL 패턴을 보호하는 정책을 생성합니다:

1. Policy Center 열기 — 관리자 콘솔에서 Policy Center(/admin/policy-center)로 이동합니다.
2. 리소스 컨텍스트 선택 — Resources/Create 표면에서 보호할 URL 또는 METHOD 리소스를 찾고 Create Permission & Policy를 눌러 작성 흐름을 시작합니다.
3. 정책 메타데이터 설정 — 설명적인 정책 이름을 입력하고, 효과(ALLOW 또는 DENY)를 선택하고, 우선순위를 설정합니다(낮은 숫자가 먼저 평가됨).
4. URL 대상 추가 — Manual 모드에서는 Targets 섹션에서 다음을 지정해 URL 대상을 추가합니다:
   • URL 패턴 (예: /api/admin/**)
   • HTTP 메서드 (GET, POST, PUT, DELETE, 또는 ANY)
5. 조건이 있는 규칙 추가 — SpEL 조건 표현식을 포함하는 규칙을 추가합니다. 예를 들어:
   SpEL Copy

   hasAnyAuthority('ROLE_ADMIN')

6. 저장 및 검증 — 정책을 저장합니다. CustomDynamicAuthorizationManager가 자동으로 새 정책을 핫 리로드합니다. 실시간 보안 현황에서 적용을 확인하고, 다양한 사용자 역할로 테스트합니다.

정책 핫 리로드

CustomDynamicAuthorizationManager는 애플리케이션 재시작 없이 정책의 핫 리로딩을 지원합니다. 이를 통해 인가 변경이 즉시 적용됩니다.

자동 리로드

애플리케이션 컨텍스트가 ContextRefreshedEvent를 발행하면 정책이 자동으로 리로드됩니다. 리로드 프로세스:

1. PolicyRetrievalPoint가 데이터베이스에서 최신 정책을 가져옵니다.
2. CustomDynamicAuthorizationManager가 RequestMatcherEntry 목록을 다시 구축합니다.
3. 새 요청은 업데이트된 정책 세트에 대해 평가됩니다.

수동 리로드

수동 리로드는 Policy Center 저장, 기본 정책 서비스 갱신, 시스템 설정 저장 같은 서버 측 관리자 흐름에서 발생합니다. 이 페이지는 별도의 공개 정책 리로드 REST 엔드포인트를 문서화하지 않습니다.

캐시 무효화

CustomDynamicAuthorizationManager.reload()는 URL 및 메서드 정책 캐시를 비우고 매핑을 다시 구축합니다. 플랫폼 다른 영역에서 분산 인프라가 참여할 수는 있지만, 여기서 문서화하는 런타임 계약은 인가 매니저와 PRP 캐시 재설정입니다.