Глава 26. Что происходит при изменении отношений

26.1. Изменение отношения меняет безопасность

До этого мы рассматривали отношение как один из источников контекста.

Теперь важно увидеть обратную сторону.

Если отношение изменяется, может измениться доступ.

Например:

User A
   ↓ member
Group G

Удаление этой связи может изменить:

effective_user_group

что затем изменит:

effective_user_permission

и в результате:

object authorization

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

26.2. Добавление связи

Рассмотрим обратный случай:

User A joins Group G

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

KUserGroupLink
      ↓
effective_user_group
      ↓
Scope Barrier
      ↓
effective_user_permission
      ↓
object authorization

Не каждая связь должна пройти именно такую цепочку.

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

26.3. Изменение публикации

Другой пример:

Object X
    ↓
KPublish
    ↓
Project P

Изменение публикации затрагивает уже объектную сторону:

KPublish
    ↓
object_scope
    ↓
object authorization

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

26.4. Отзыв важнее выдачи не меньше, чем выдача важнее отзыва

Предположим:

Grant

создал право.

Затем:

Revoke

отменил основание.

Если производная модель не обновилась, старое право остаётся.

Поэтому механизм распространения изменений должен одинаково хорошо обрабатывать:

ADD
CHANGE
REMOVE

Нельзя проектировать только путь выдачи.

26.5. Инкрементальная обработка

Если изменение локальное, можно обновить только затронутую часть проекции.

Например:

Changed group
      ↓
Affected users
      ↓
Affected permissions

Это позволяет не перестраивать всю компанию после каждого изменения.

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

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

Иногда проще и безопаснее перестроить модель заново:

Source facts
      ↓
Security rules
      ↓
Full rebuild
      ↓
Projection

Такой режим нужен для:

• восстановления;

• проверки;

• миграции;

• изменения правил;

• исправления накопленного расхождения.

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

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

26.7. Два времени авторизации

На этом уровне можно различить два момента.

Время построения модели:

Fact changed
      ↓
Projection updated

Время проверки:

Request
      ↓
Prepared security state
      ↓
Authorization

Это важное свойство сложной модели.

Авторизация не обязательно вычисляется целиком в момент запроса.

Часть её вычисления происходит раньше.

26.8. Временное расхождение

Если обновление асинхронное:

Source updated
      ↓
Projection still old

то некоторое время система видит старое состояние безопасности.

Поэтому необходимо определить:

• допустима ли задержка;

• сколько она может продолжаться;

• когда запрос должен ждать;

• что делать при ошибке обновления;

• как обнаружить потерю изменения.

Это уже часть семантики безопасности.

26.9. Что должно быть наблюдаемым

Для изменения отношения желательно иметь возможность ответить:

Какой факт изменился?
Какие проекции затронуты?
Какие пользователи затронуты?
Какие разрешения изменились?
Когда новое состояние стало доступно?

Без такой трассировки ошибка авторизации превращается в поиск причины по нескольким независимым таблицам.

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

Связь — это не просто строка отношения.

Если она входит в модель безопасности, изменение связи имеет последствия:

Relationship change
      ↓
Security projection change
      ↓
Effective permission change
      ↓
Access change

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