Кто побеждает, когда агенту одновременно разрешено и запрещено действие?

Агент предлагает провести платёж. Финансовая политика разрешает его: сумма укладывается в делегированный бюджет. Политика безопасности запрещает его: счёт получателя новый. Юридическая политика разрешает платёж по подписанному договору с поставщиком. Политика управления данными не может принять решение: отсутствует обязательный атрибут риска.

Сложность не в том, способен ли рантайм вычислить эти политики. Сложность в том, кто определяет смысл их совокупного результата. Если рантайм отвечает на этот вопрос неявным значением по умолчанию в движке, то значимое организационное решение принимает деталь реализации, а не система управления организацией.

Управляемому рантайму агентов нужна метаполитика: исполнимые правила о правилах. NIST SP 800-162 определяет метаполитику как политику о политиках, включая назначение приоритетов и разрешение конфликтов между цифровыми политиками или другими метаполитиками. Именно этого слоя не хватает, когда одно действие регулируют несколько легитимных центров полномочий.

Результат политики ещё не является решением

Безопасность, юридическая служба, финансы, операции и управление данными не просто добавляют условия в единый свод правил. У них разные мандаты, разные источники доказательств и разная приемлемость ошибок. Финансовый контроль может оценивать бюджетные полномочия, контроль безопасности — доверие к счёту, юридический — договорное основание. Их выводы могут расходиться, и ни один из авторов не обязан быть неправ.

Поэтому рантайм должен различать отдельный результат политики и итоговое исполнимое решение. Как минимум нужны типизированные исходы: Permit, Deny, NotApplicable, Indeterminate и Conflict. NotApplicable — не запрет: политика не регулирует этот запрос. Indeterminate тоже не запрет: потенциально релевантная политика не смогла надёжно вычислиться, например из-за отсутствующего атрибута. Conflict означает, что применимые результаты нельзя скомпоновать по выбранному правилу.

Слишком раннее сведение этих состояний делает управление непрозрачным. Признать отсутствие результата проверки санкций обычным отказом может быть разумной операционной мерой для одного платёжного сценария, но это скроет проблему качества данных, которую надо устранить. Считать отсутствие этого результата разрешением, потому что другая политика одобрила перевод, — иной и гораздо более рискованный выбор. Ни один из этих исходов не должен быть случайным.

Движки политик уже показывают: способ объединения — это проектное решение

В самом понятии авторизации нет универсального правила приоритета. XACML 3.0 задаёт несколько алгоритмов объединения политик: deny-overrides, permit-overrides, first-applicable, only-one-applicable, упорядоченные варианты, deny-unless-permit и permit-unless-deny. Само наличие этого набора показательно: разные способы объединения выражают разные операционные допущения.

Cedar выбирает конкретную модель. Авторизация по умолчанию запрещена; сработавшая политика forbid имеет приоритет над сработавшей permit; а политики с ошибкой вычисления пропускаются. Это ясная и детерминированная семантика, но не нейтральная. Организации, использующей Cedar, всё равно нужно решить, соответствуют ли её центры полномочий, области действия и обработка недостающих данных этой модели для каждого значимого действия.

Open Policy Agent даёт полезный контраст. Он может сообщать о конфликте вычисления, когда полное правило Rego производит несколько результатов. Здесь несогласованность может быть выведена как ошибка, а не автоматически преобразована в разрешение или запрет. Вывод опять не в выборе универсального движка. Организация должна явно определить реакцию на несогласованность на границе исполнения.

“Движок политик вычисляет правила. Метаполитика делает исполнимой полномочность организации разрешать их результаты.

Сначала ограничьте области полномочий, затем назначайте приоритеты

Одного числа приоритета для метаполитики недостаточно. Для равных приоритетов тоже нужно правило. Как и для исключений с ограниченной областью, пересекающихся юрисдикций, отсутствующих атрибутов и неопределённых вычислений. Формула «безопасность побеждает» также неполна, пока не ясно, какой именно орган безопасности, для какого класса действий, над каким другим органом и что происходит, если политика безопасности не может вычислиться.

Начните с наборов политик, ограниченных областью полномочий. Каждую политику привяжите к именованному центру ответственности с определённым мандатом: например, риск платежа, делегированные расходы, договорная допустимость или обработка информации. Изолированные коллекции политик и пространства имён помогают устранить неоднозначность имён и задать технические границы, но сами по себе не устанавливают организационный приоритет. Это отношение должно быть задано метаполитикой.

Затем выбирайте стратегии объединения по классу действий, а не по привычке платформы. Для внутреннего поиска с низким риском может быть достаточен простой путь разрешения. Платёж новому контрагенту может требовать Permit от всех назначенных органов, при этом любой Deny блокирует исполнение, а любой Indeterminate создаёт случай для рассмотрения. Экспорт данных клиента может потребовать иной композиции: у него другие регулирующие органы и требования к доказательствам.

Смысл не в том, что deny-overrides всегда безопаснее или юридически вернее. Модель решения должна раскрывать свои допущения. Какой орган может блокировать действие? Какой — разрешать? Отсутствующий атрибут — это блокировка, конфликт или запрос на обогащение данных? Может ли исключение отменить общее ограничение и на основании каких доказательств? Это операционные правила, а не выбор синтаксиса.

Сделайте разрешение конфликтов наблюдаемым и тестируемым

Для каждого значимого действия сохраняйте запись решения, которую может восстановить ответственный проверяющий. В ней должны быть действие и релевантные входные атрибуты; применимые политики и их версии; результаты каждой из них; алгоритм объединения и версия метаполитики; итоговое решение; а также эскалация или решение человека. Событие с итогом «отклонено» без этой структуры не объясняет, был ли причиной жёсткий запрет, нехватка сведений, ошибка политики или неразрешённый конфликт.

Такая запись важна для операций не меньше, чем для аудита. Командам необходимо видеть, где накапливаются конфликты: в новом классе поставщиков, в устаревшем источнике риск-данных, в пересечении областей двух органов или в исключении, незаметно вышедшем за первоначальные границы. Без отдельных результатов организация видит только конечный симптом.

Тестирование также должно выйти за пределы синтаксиса. Валидация схемы перед развёртыванием полезна, поскольку обнаруживает структурные ошибки и ошибки типов. Например, Amazon Verified Permissions может проверять новые и обновлённые политики по схеме хранилища политик и отклонять невалидные изменения. Но валидная схема не доказывает, что независимо написанные бизнес-политики непротиворечивы или дают ожидаемый результат.

• Проводите тесты конфликтов с намеренно противоположными применимыми политиками для каждого класса значимых действий.
• Проводите мутационные тесты: изменяйте permit, deny, область действия, приоритет или обязательный атрибут и проверяйте ожидаемое изменение решения и объяснения.
• Используйте теневое вычисление предлагаемых изменений политик на репрезентативных запросах до изменения режима исполнения.
• Явно тестируйте отсутствующие, устаревшие и некорректные атрибуты; не оставляйте их обработку на усмотрение интеграции.
• Направляйте неразрешённые Conflict и определённые для действия исходы Indeterminate ответственному человеку вместе с доказательствами, нужными для решения.

Эскалация — часть системы принятия решений

Некоторые конфликты нельзя разрешать механически. Агент, получивший обоснованное финансовое разрешение и обоснованный юридический запрет, не должен изобретать компромисс. Для отдельных классов действий рантайм может немедленно блокировать операцию, но он всё равно должен создать кейс для назначенного владельца, если конфликт отражает вопрос управления, а не обычный отказ.

Для пути исключений нужна ответственная человеческая роль, а не безличная очередь. Этот человек должен видеть органы полномочий, версии политик, входные данные и отдельные результаты, а затем выносить ограниченное по рамкам решение. В нём следует зафиксировать область действия и срок истечения, чтобы оно не стало невидимым постоянным обходом правил. Так человеческое суждение остаётся на своём месте — на неразрешённых организационных границах, а не служит скрытой заменой нормальному проектированию политик.

Архитектурное следствие

Автономные организации будут накапливать авторов политик быстрее, чем формировать единый взгляд на полномочия. Это нормально. Ошибка — ожидать, что язык политик, поле приоритета или режим default deny сами решат возникший конституционный вопрос.

Стройте слой разрешения конфликтов намеренно. Определите органы полномочий и их области действия. Типизируйте важные исходы. Выберите стратегию объединения для каждого класса действий. Валидируйте структуру, затем проверяйте семантические конфликты и предлагаемые изменения. Сохраняйте полный путь решения. Передавайте то, что осталось неопределённым, ответственному человеку.

Агенту могут одновременно разрешить и запретить действие. Зрелый рантайм не скрывает этот факт. Он превращает конфликт в явное, проверяемое организационное решение до наступления любого внешнего эффекта.

Источники

• NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-162.pdf
• Глоссарий NIST, Policy Decision Point: https://csrc.nist.gov/glossary/term/policy_decision_point
• OASIS, спецификация XACML 3.0 Core: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cos01-en.html
• Модель авторизации Cedar: https://docs.cedarpolicy.com/auth/authorization.html
• Ошибка конфликта вычисления Open Policy Agent: https://www.openpolicyagent.org/docs/errors/eval-conflict-error/complete-rules-must-not-produce-multiple-outputs
• Валидация политик Amazon Verified Permissions: https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-validation-mode.html