Атрибутная модель доступа (ABAC).

Атрибутная модель доступа заменяет статические ролевые назначения динамическими политиками. Движок принятия решений оценивает правила по атрибутам четырёх видов: субъекта (отдел, уровень допуска, роль), ресурса (классификация, владелец, тег), действия (чтение, удаление, экспорт) и среды (время суток, исходный IP, состояние устройства, уровень угрозы). Это позволяет принимать очень детальные, контекстно-зависимые решения — например, разрешать врачу читать карту пациента только во время его дежурства и только с управляемого устройства. ABAC формально определён в NIST SP 800-162 (обновление 2019 года), где он представлен как способ управлять обменом информацией без предварительной подготовки учётных записей под каждый ресурс.

Большинство реальных внедрений следуют эталонной архитектуре XACML, которая разделяет применение политик на четыре взаимодействующие функции: Policy Enforcement Point (PEP) перехватывает запрос, Policy Decision Point (PDP) его оценивает, Policy Information Point (PIP) подтягивает недостающие атрибуты, а Policy Administration Point (PAP) управляет правилами. Современные стеки часто заменяют многословный XML XACML на Rego от Open Policy Agent или атрибутные условия AWS/Azure. Сильные стороны ABAC — гибкость и масштаб: горстка политик способна выразить то, что потребовало бы тысяч ролей RBAC, — но её слабости в сложности политик, более трудном аудите (вопрос «кто может получить доступ к X?» превращается в задачу для решателя) и полной зависимости от надёжных, актуальных источников атрибутов.

flowchart LR
  U[Субъект запрашивает действие] --> PEP[Policy Enforcement Point]
  PEP --> PDP[Policy Decision Point]
  PDP -->|нужны атрибуты| PIP[Policy Information Point]
  PIP -->|субъект / ресурс / среда| PDP
  PAP[Policy Administration Point] -->|правила| PDP
  PDP -->|Разрешить или Запретить| PEP
  PEP -->|разрешено| R[Ресурс]
  PEP -->|запрещено| X[Заблокировано]