정책 결정 지점
더 많은 작업
- Policy Decision Point, PDP / Policy Enforcement Point, PEP; 정책 결정 지점·정책 집행 지점
- 접근 요청을 판단하는 곳(PDP)과 그 판단을 실제로 집행하는 곳(PEP)을 분리한 접근 정책 집행 구조의 구성 요소
애플리케이션마다 "이 사용자가 이 작업을 해도 되는가"를 코드 안에 따로 구현하면 정책이 수십 곳에 흩어지고, 정책 하나를 바꾸려면 모든 시스템을 고쳐야 한다. 결정 로직을 한곳(PDP)에 모으고 각 시스템 앞단(PEP)은 묻고 따르기만 하게 하면, 정책을 중앙에서 일관되게 관리하고 감사할 수 있다. 이 구조는 XACML 표준에서 체계화되었고, 속성 기반 접근통제와 제로 트러스트 아키텍처의 공통 뼈대가 되었다. CISSP 5.4 항목은 접근 정책 집행의 예로 PDP와 PEP를 직접 든다.
| 구성 요소 | 역할 | 비유 | 구현 예 |
|---|---|---|---|
| PAP(Policy Administration Point, 정책 관리 지점) | 정책을 작성·시험·관리하고 저장소에 저장한다. | 법을 만드는 곳 | 정책 관리 콘솔, 정책 저장소(Git 등) |
| PDP(Policy Decision Point, 정책 결정 지점) | 요청과 정책, 속성을 대조해 허용·거부를 결정한다. | 판사 | 인가 서버, 정책 엔진, 조건부 접근 엔진 |
| PEP(Policy Enforcement Point, 정책 집행 지점) | 요청을 가로채 PDP에 묻고, 결정대로 통과시키거나 막는다. | 출입문 경비 | API 게이트웨이, 리버스 프록시, 서비스 메시 사이드카, 방화벽 |
| PIP(Policy Information Point, 정책 정보 지점) | PDP가 판단에 필요한 속성을 가져오는 출처이다. | 증거·기록 보관소 | 디렉터리, 인사 DB, 자산·기기 관리 시스템, 위협 인텔리전스 |
NIST 용어집(SP 800-95 출처)은 PDP를 자원 접근 요청을 그 자원에 적용되는 정책과 비교해 특정 요청자에게 접근을 허용할지 결정하는 메커니즘으로, PEP를 자원을 실제로 보호하는(접근을 통제하는) 메커니즘으로 정의한다.
XACML 원형 기준의 흐름은 다음과 같다.
- 주체가 자원에 접근을 요청한다.
- PEP가 요청을 가로채, 주체·자원·행위 정보를 담은 결정 요청을 PDP로 보낸다.
- PDP는 PAP가 저장해 둔 정책 중 적용 대상을 찾는다.
- PDP는 판단에 부족한 속성(부서, 기기 상태 등)을 PIP에서 가져온다. 이 과정은 컨텍스트 핸들러가 조정하기도 한다.
- PDP가 허용(Permit)·거부(Deny) 같은 결정과 함께 의무 사항(obligation, 예: "로그를 남겨라")을 PEP에 돌려준다.
- PEP가 결정과 의무 사항을 집행한다. PDP에 연결할 수 없으면 미리 정한 기본 동작(보통 거부)을 따른다.
XACML(eXtensible Access Control Markup Language)은 OASIS가 만든 XML 기반 정책 언어로, 정책·규칙과 이 네 지점을 정의한다. 오늘날에는 XACML 자체보다 같은 구조를 JSON·코드형 정책(policy as code)으로 구현한 정책 엔진이 더 흔하지만, 결정과 집행을 분리하는 원리는 같다.
NIST SP 800-207은 PDP를 정책 엔진과 정책 관리자 두 논리 구성 요소로 나눈다.
| 800-207 구성 요소 | 역할 | XACML 대응 |
|---|---|---|
| 정책 엔진(PE, Policy Engine) | 기업 정책과 외부 신호(CDM, 위협 인텔리전스 등)를 신뢰 알고리즘에 넣어 접근 허용·거부·취소를 최종 결정하고 기록한다. | PDP(결정) |
| 정책 관리자(PA, Policy Administrator) | PE의 결정에 따라 주체와 자원 사이 통신 경로를 열거나 닫도록 PEP에 명령하고, 세션별 인증 토큰·자격 증명을 만든다. | PDP(결정 전달·세션 관리) |
| 정책 집행 지점(PEP) | 주체와 자원 사이 연결을 열고, 감시하고, 끊는다. 단말 에이전트와 자원 앞 게이트웨이로 나뉠 수도 있다. | PEP |
| 데이터 출처(CDM, 위협 인텔리전스, 활동 로그, 신원 관리 시스템, PKI, SIEM 등) | 정책 엔진의 판단 입력을 제공한다. | PIP |
PE·PA와 PEP는 별도의 제어 평면으로 통신하고, 실제 업무 데이터는 데이터 평면으로 흐른다. 이 구분은 데이터 평면과 제어 평면 문서와 연결된다. PEP 뒤쪽은 신뢰 영역(implicit trust zone)이므로, PEP는 보호 대상 자원에 최대한 가깝게 두어야 한다.
| 구현 | PEP 위치 | PDP 형태 |
|---|---|---|
| API 게이트웨이 | API 호출 진입점 | 게이트웨이 정책 + 외부 인가 서버(OAuth 토큰 검증, 스코프 확인) |
| 서비스 메시 | 각 서비스 옆의 사이드카 프록시 | 메시 제어 평면이 배포한 정책 또는 외부 정책 엔진 호출. 서비스 간(동서) 호출마다 상호 TLS 신원으로 인가한다. |
| ZTNA 프록시 | 애플리케이션 앞 접속 브로커 | 클라우드 정책 엔진이 사용자·기기 상태를 평가해 애플리케이션 단위로 연결을 허용한다(SASE 참고). |
| 클라우드 IAM | 클라우드 API 엔드포인트 | 클라우드 공급자의 정책 평가 엔진 |
| 네트워크 접근 제어 | 스위치·무선 AP(IEEE 802.1x 인증자) | RADIUS 서버 |
- PDP는 모든 접근의 관문이 되므로 단일 실패 지점이 된다. 이중화하고, PDP 장애 시 PEP의 기본 동작(fail-closed 원칙)을 정해 둔다.
- 결정을 매번 원격으로 물으면 지연이 생긴다. 결정 캐시나 PEP 옆 로컬 PDP를 두되, 캐시 수명은 권한 회수가 반영되는 시간을 고려해 짧게 잡는다.
- PEP를 우회하는 경로(직접 DB 접속, 내부 관리 포트)가 있으면 구조 전체가 무의미하다. 모든 경로가 PEP를 거치게 한다. 이는 참조 모니터의 완전 중재(complete mediation) 요건과 같다.
- PDP의 결정과 근거를 로그로 남겨 감사와 정책 개선에 쓴다.
- PDP는 결정, PEP는 집행이다. "요청을 가로채 막는 구성 요소"는 PEP, "정책을 평가하는 구성 요소"는 PDP이다.
- PIP는 속성 제공, PAP는 정책 관리이다. 네 지점의 역할을 바꿔 묻는 문제에 대비한다.
- NIST SP 800-207은 PDP를 정책 엔진(PE)과 정책 관리자(PA)로 나누고, PEP가 연결을 실제로 열고 닫는다.
- 모든 접근이 PEP를 거쳐야 한다는 요구는 참조 모니터의 완전 중재 원칙과 연결된다.
- PDP 장애 시 기본 동작은 고위험 자원일수록 거부(fail-closed)가 원칙이다. 다만 인명 안전과 관련된 물리 출입은 fail-safe를 우선한다.