Глава 18. Изменение одного факта

18.1. Изменение отношения — это изменение модели безопасности

Рассмотрим простой факт:

User A is member of Group G

На первый взгляд изменяется одна связь.

Но если группа участвует в модели доступа, изменение может затронуть:

Group
  ↓
Project relations
  ↓
Effective permissions
  ↓
Object access

Поэтому изменение отношения является одновременно изменением состояния предметной области и изменением производной модели безопасности.

Это особенно важно для удаления связи.

Добавление доступа обычно заметно.

Отзыв доступа должен гарантированно удалить все результаты, которые больше не имеют основания.

18.2. Радиус влияния

Для каждого исходного факта существует область его влияния.

Например:

UserGroupLink
      ↓
effective_user_group
      ↓
effective_user_permission
      ↓
object authorization

Изменение одной связи может повлиять на множество эффективных разрешений.

Поэтому количество изменённых исходных строк не показывает реальную стоимость изменения.

Важнее знать:

какие производные факты зависят от изменённого факта?

Это можно назвать радиусом влияния.

18.3. Изменение может проходить через несколько проекций

Допустим, пользователь удалён из группы.

Тогда последовательность может выглядеть так:

KUserGroupLink
      ↓
effective_user_group
      ↓
Scope Barrier
      ↓
effective_user_permission
      ↓
object authorization

Другой тип изменения:

KPublish
      ↓
object_scope
      ↓
object authorization

Поэтому разные исходные факты могут иметь разные графы зависимостей.

Это ещё одна причина не пытаться представить всю безопасность одной таблицей.

18.4. Добавление и отзыв должны быть симметричны

Если система умеет построить результат:

Grant → Permission

она должна уметь удалить этот результат после:

Revoke → no longer valid

Нельзя считать отзыв второстепенной операцией.

Для безопасности он не менее важен, чем выдача.

Если выдача обработана, а отзыв потерян, система продолжает считать право действующим.

Это уже не обычная ошибка синхронизации.

Это изменение фактического уровня доступа.

18.5. Инкрементальное изменение

Один подход — пересчитывать только затронутую часть модели.

Например:

Changed fact
     ↓
Affected subjects
     ↓
Affected permissions
     ↓
Affected projections

Это эффективно, если зависимости хорошо известны.

Но оно требует точного определения радиуса влияния.

Ошибка в таком алгоритме может оставить старое производное разрешение.

18.6. Полное перестроение

Другой подход — периодически или по необходимости перестраивать проекцию из исходных фактов:

Source facts
      ↓
Rules
      ↓
Rebuild
      ↓
Projection

Полное перестроение дороже.

Зато оно позволяет проверить саму модель вычисления независимо от истории отдельных изменений.

Поэтому инкрементальное обновление и полное перестроение не являются взаимоисключающими.

Обычно они решают разные задачи:

incremental → normal operation
rebuild      → recovery / validation / rule change

18.7. Асинхронное обновление

Если проекция обновляется не в той же транзакции, в которой изменился исходный факт, между ними возникает промежуточное состояние.

Например:

Source fact changed
        ↓
Projection not updated yet

В этот момент исходная модель и производная модель описывают разные состояния системы.

Это называется задержкой согласования.

Она не обязательно является ошибкой.

Но архитектура должна явно определить её семантику.

18.8. Изменение отношения → изменение разрешения

Для модели доступа цепочка должна быть явной:

Source fact changed
       ↓
Affected projection
       ↓
Effective permission changed
       ↓
Object authorization changed
       ↓
Data access changed

Это позволяет анализировать безопасность не как набор отдельных таблиц, а как граф зависимостей.

При проектировании необходимо понимать, какие изменения могут привести к изменению доступа.

18.9. Идемпотентность не заменяет согласованность

Операция обновления проекции должна по возможности быть идемпотентной.

То есть повторная обработка одного изменения не должна создавать другой результат.

Но:

Idempotence ≠ Consistency

Идемпотентная операция всё равно может быть применена не к тому набору исходных фактов.

Поэтому нужны оба свойства:

correct dependency propagation
+
idempotent processing

18.10. Что должна гарантировать модель

Для каждого класса производных данных должно быть понятно:

1. из каких исходных фактов он строится;

2. какими правилами;

3. какие изменения его затрагивают;

4. как обрабатывается отзыв;

5. как выполняется восстановление;

6. как определяется завершённость обновления.

Только тогда проекция становится управляемой частью архитектуры.

18.11. Модель должна учитывать переходные состояния

В реальной системе существуют состояния:

Source updated
Projection updating
Projection current
Projection rebuilding
Projection unavailable

Нельзя делать вид, что существует только:

correct

и

incorrect

Для каждого переходного состояния должна существовать определённая политика безопасности.

Например, система может временно запрещать операцию, пока критичная проекция не готова.

Или использовать предыдущую согласованную версию.

Главное — не получать это поведение случайно.

18.12. Главный вывод

Изменение отношения нельзя рассматривать как локальную запись в таблице.

Если отношение участвует в модели доступа, оно запускает цепочку:

Domain change
      ↓
Security model change
      ↓
Projection update
      ↓
Effective permission update
      ↓
Access change

Поэтому распространение изменений является частью самой модели безопасности.