PDP (Policy Decision Point)

Что такое PDP (Policy Decision Point)

PDP расшифровывается как Policy Decision Point — точка принятия решения. Это компонент архитектуры контроля доступа, который получает запрос вида «субъект X хочет сделать Y с объектом Z», сверяется с политикой и возвращает решение: Permit или Deny.

Ключевая идея — вынести решение о доступе из кода приложения. Обычно проверка прав размазана по сотне мест: if (user.role == 'admin') в контроллерах, условия в шаблонах, что-то в middleware. Ответить на вопрос «кто имеет доступ к финансовым отчётам» становится невозможно, не перечитав весь проект. PDP превращает это в единую политику, живущую отдельно от кода, — её можно прочитать, протестировать и изменить, не выкатывая релиз.

Сразу оговорка про многозначность: PDP также означает Plasma Display Panel (плазменная панель), Product Detail Page в e-commerce и Packet Data Protocol в мобильных сетях. Здесь речь строго о безопасности.

PDP, PEP и остальные

Модель родом из XACML (OASIS) и AAA-архитектуры IETF. Четыре компонента:

Поток выглядит так:

Запрос → PEP (API Gateway / sidecar / middleware)
            │  «можно ли ivanov сделать DELETE /orders/42?»
            ↓
          PDP ──→ PIP (подтянуть: отдел, статус, время, MFA?)
            │
            ↓  Permit / Deny
          PEP → пропустить запрос или вернуть 403

Разделение принципиальное: PDP только решает, PEP только исполняет. PDP ничего не блокирует — он вернёт «Deny», и если PEP это проигнорирует, доступ произойдёт. Отсюда правило: PEP обязан быть на пути запроса, а не сбоку, и обязан fail-closed — при недоступности PDP запрещать, а не разрешать.

Зачем это нужно

PDP — естественный дом для ABAC (атрибутивной модели): решение считается из атрибутов субъекта, объекта и контекста, а не только из роли. «Разрешить, если отдел = финансы И время рабочее И устройство корпоративное И был MFA» — такое в RBAC не выразить, а в политике PDP это несколько строк.

Плюс архитектурные бонусы: единый аудит всех решений о доступе (в SIEM уходит «кому что запретили» из одного места), одинаковые правила для десятка микросервисов на разных языках, и тестируемость — политику можно покрыть unit-тестами.

OPA как PDP

OPA (Open Policy Agent) — самая распространённая реализация. Политики пишутся на языке Rego, PDP работает как sidecar или демон рядом с сервисом.

package authz

default allow := false

allow if {
    input.method == "GET"
    input.path == ["orders", _]
    input.user.department == "finance"
}

allow if {
    input.method == "DELETE"
    "admin" in input.user.roles
    input.user.mfa == true          # удаление — только с подтверждённым MFA
}

curl -s localhost:8181/v1/data/authz/allow \
  -d '{"input":{"method":"DELETE","path":["orders","42"],
       "user":{"roles":["admin"],"mfa":true}}}'
# {"result":true}

default allow := false — не стилистика, а суть: политика по умолчанию запрещает, разрешения добавляются явно.

Где PDP встречается на практике: OPA Gatekeeper в Kubernetes решает, можно ли применить манифест (запретить привилегированные контейнеры, потребовать лимиты ресурсов); Istio/Envoy обращаются к OPA как внешнему PDP перед пропуском трафика; API Gateway — типичный PEP на входе в инфраструктуру.

Что учесть

• Латентность. PDP вызывается на каждый запрос — это плюс к latency. Отсюда sidecar рядом с сервисом, а не общий сервис за полсети.
• Отказоустойчивость. PDP на критическом пути: лежит он — не работает ничего. Локальный агент с копией политик надёжнее централизованного.
• Политики — это код. В Git, с ревью и тестами, выкатка через CI/CD. Политика доступа, которую правят руками в проде, ничем не лучше if в контроллере.

Стоит ли вообще: для монолита с тремя ролями — нет, обычного RBAC хватит. PDP окупается, когда сервисов много, правила сложные, а регулятор требует доказуемого и единообразного контроля доступа.

Связанные термины

• RBAC и ACL — модели, которые PDP вычисляет
• IAM / IdP — откуда PDP берёт личность и атрибуты
• Аутентификация — шаг, предшествующий решению о доступе
• API Gateway — типичный PEP
• Несанкционированный доступ — что предотвращает верное решение PDP