Точка принятия решения по политике (PDP) Policy Decision Point (PDP)
Простыми словами
Это функция, а не коробка. Одно и то же изделие может нести и точку решения, и точку исполнения, и руководство прямо оговаривает, что их соседство обычно оправдывают производительностью, а разделять их бывает желательно. Главное количественное правило записано в определении: «There may be multiple PDPs and PEPs, but overall there should be fewer PDPs than PEPs» — и названы обе причины: меньше мест администрирования политики и возможность снять с исполнителей сложную логику. Второе определение короче и точнее описывает работу: «The engine that evaluates requests against the policy (or rules) data and makes policy decisions». Частая ошибка — считать, что решение и есть действие: решение упаковывается в ответ и возвращается исполнителю, который и запрещает или пропускает.
Примеры
«Some policy decision points (Central PDPs) may operate directly off the central policy repositories», и это полнофункциональные точки, не сращённые с исполнителем. Локальные бывают слабее и тесно сращены с проприетарным хранилищем политики и реализацией PEP.
Open Enterprise Security Architecture (O-ESA), The Open Group Guide G112 (April 2011), разд. 6.3 — модель автоматизации политики, часть про исполнение во время…
«Once the decision has been made by the PDP, the result would be packaged into a decision reply and returned back to the PEP for enforcement». Поэтому в реестре точка решения и точка исполнения — две строки: у них разные обязанности и разные точки отказа.
Open Enterprise Security Architecture (O-ESA), The Open Group Guide G112 (April 2011), разд. 4.3.1 — завершение описания хода работы модели PDP/PEP
Хотя схема опирается на ISO/IEC 10181-3:1996 Access Control Framework, руководство распространяет её на все службы управления политикой и безопасности, включая настройку, а не только на работу под нагрузкой. Это и отличает точку решения O-ESA от одноимённого понятия в моделях контроля доступа.
Open Enterprise Security Architecture (O-ESA), The Open Group Guide G112 (April 2011), разд. 4.3.1 — вводная к модели PDP/PEP со ссылкой на ISO/IEC 10181-3:1996
Определение из первоисточника
дословная выпискаThe PDP accesses electronic policy information and makes runtime policy decisions at the request of a Policy Enforcement Point (PEP). The PDP is sometimes collocated with the PEP due to product packaging, often justified by performance considerations. In other situations, it is desirable to decouple the PDP from the PEP. There may be multiple PDPs and PEPs, but overall there should be fewer PDPs than PEPs, so as to reduce policy administration and/or allow PDPs to offload complex logic from PEPs.
PDP обращается к сведениям об электронной политике и принимает решения по политике во время выполнения по запросу точки обеспечения исполнения политики (PEP). PDP иногда размещается совместно с PEP из-за особенностей комплектации продукта, что часто оправдывают соображениями производительности. В других случаях PDP желательно отделить от PEP. PDP и PEP может быть несколько, но в целом PDP должно быть меньше, чем PEP, чтобы сократить администрирование политики и (или) позволить PDP снять с PEP сложную логику.
ИсточникOpen Enterprise Security Architecture (O-ESA): A Framework and Template for Policy-Driven Security. The Open Group Guide, April 2011, № документа G112, ISBN 1-931624-94-1
Основные параметры
Атрибуты этой сущности по справочнику источника.
- Разд. 4.3.1 добавляет определение той же точки как участника модели
«The engine that evaluates requests against the policy (or rules) data and makes policy decisions». Разд. 6.3 различает центральные PDP, работающие прямо от центральных репозиториев политик, и локальные, тесно сращённые с проприетарным хранилищем и PEP.
Связанные понятия
Опишите архитектуру своей компании в Storm
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormАрхитектура систем и интеграцийГраф связей реестраРеестр процессов