Глава 42. Объект определяет возможные отношения

В предыдущих главах мы рассматривали одну и ту же модель в разных системах.

В корпоративной системе объектом мог быть документ.

В PLM — изделие, деталь, спецификация или версия.

В RAG — документ или его фрагмент.

В SaaS — ресурс конкретной организации.

В B2B — объект, принадлежащий одной стороне взаимодействия или доступный нескольким сторонам.

Предметные области различаются.

Но во всех них остаётся одна общая закономерность:

модель доступа начинается не с набора разрешений, а с понимания того, какие отношения вообще могут существовать вокруг объекта.

Это важный переход.

Объект не определяет, кто получит доступ.

Но объект определяет, какие виды отношений с ним имеют смысл.

42.1 Нельзя определить доступ, не определив объект

Начнём с простого вопроса:

Что является предметом действия?

Пока на него нет ответа, невозможно точно определить разрешение.

Например:

READ

само по себе ничего не говорит.

READ чего?

READ Document
READ Project
READ User
READ Part
READ Invoice

Это разные действия над разными объектами.

Поэтому модель начинается с:

Subject
Action
Object

Но и этого недостаточно.

Нужно понять, какие отношения связывают этот объект с остальной моделью.

42.2 У объекта есть предметная семантика

Объект существует не только как идентификатор.

У него есть смысл в предметной области.

Например:

Document

может:

• принадлежать проекту;

• иметь владельца;

• быть опубликованным;

• иметь статус;

• быть связанным с другой версией.

Для:

Project

могут существовать:

• участники;

• руководители;

• документы;

• задачи;

• внешние организации.

Для:

Part

могут существовать:

• состав изделия;

• версии;

• спецификации;

• документы;

• изменения.

Таким образом, тип объекта задаёт пространство возможных отношений.

42.3 Не каждое отношение можно применить к любому объекту

Предположим, в системе существует отношение:

member of

Для пользователя оно естественно:

User → member of → Project

Но:

Document → member of → Project

уже означает что-то другое.

А:

Part → member of → Project

может быть вообще недопустимой семантикой конкретной системы.

Для объектов могут использоваться другие отношения:

Document → belongs to → Project
Part → component of → Assembly
Revision → revision of → Part
User → member of → Project

Все эти связи имеют разные значения.

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

42.4 Тип объекта ограничивает пространство отношений

Можно представить объект как точку, вокруг которой существует определённое множество допустимых отношений.

Например:

Project
 ├── member
 ├── manager
 ├── document
 ├── task
 └── external participant

Для документа:

Document
 ├── owner
 ├── project
 ├── publication
 ├── revision
 └── related change

Для пользователя:

User
 ├── member of
 ├── role in
 ├── owner of
 ├── delegate of
 └── authenticated by

Это не список разрешений.

Это список отношений, которые могут участвовать в построении контекста.

Именно поэтому объект является отправной точкой модели.

42.5 Отношение не возникает только потому, что его можно технически записать

В базе данных можно создать таблицу:

relation(subject_id, object_id)

Но техническая возможность записать пару идентификаторов ещё не означает существование предметного отношения.

Например:

Document → manages → User

можно представить в универсальной таблице.

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

Следовательно, модель отношений должна исходить из предметной области, а не из удобства хранения.

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

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

42.6 Объект не определяет право, но определяет возможные основания

Это различие принципиально.

Пусть:

Document D

и известно, что документ:

owned by User A
belongs to Project P
published to Group G

Из этого ещё не следует:

User B → READ → D

Но мы уже знаем, какие отношения могут участвовать в принятии решения.

Например:

ownership
project membership
group membership
publication

Дальше правила определят, какое значение имеет каждое из них.

Получается:

Object
   ↓
possible relationships
   ↓
relevant relationships
   ↓
access grounds
   ↓
effective permission

Объект задаёт пространство.

Правила выбирают значение.

42.7 Один объект может иметь несколько независимых отношений

Рассмотрим документ:

Document D

Он может одновременно быть:

owned by User A
belongs to Project P
published to Group G
related to Change C

Эти отношения не являются разными способами хранения одного и того же факта.

Они описывают разные стороны объекта.

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

Другое — для видимости.

Третье — для участия в проекте.

Четвёртое — для жизненного цикла.

И только часть из них может быть релевантна конкретному действию.

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

42.8 Релевантность отношения определяется действием

Для одного действия отношение может иметь значение.

Для другого — нет.

Например:

Document D
owned by User A

может быть важно для:

CLOSE

но не иметь значения для:

READ

если система разрешает чтение всем участникам проекта.

А отношение:

Document D → Project P

может быть ключевым для READ.

Получается:

RelevantRelations
=
f(Object, Action, Subject)

Это ещё одна причина, по которой контекст нельзя считать постоянным свойством объекта.

42.9 Объект может быть связан с другими объектами

В сложных системах отношения возникают не только между пользователем и объектом.

Например:

User
   ↓
Project
   ↓
Document

или:

User
   ↓
Company
   ↓
Project
   ↓
Product
   ↓
Part

Здесь сам объект является частью цепочки отношений.

Это означает, что доступ может зависеть от промежуточных объектов.

Но снова действует важное ограничение:

path ≠ permission

Путь становится основанием доступа только тогда, когда модель определяет его как допустимый путь.

42.10 Один объект может иметь разные security boundaries

Не всегда вся информация об объекте имеет одну границу доступа.

Например, документ может содержать:

metadata
content
attachments
comments
audit

Эти данные физически или логически могут иметь разные ограничения.

Тогда:

Document

остаётся одним логическим объектом, но вокруг него существует несколько security boundaries.

Поэтому нельзя автоматически считать:

access to object
=
access to every representation of object

Нужно определить, какие отношения и правила относятся к каждой части данных.

Это связывает модель объекта с тем, что мы раньше называли data enforcement.

42.11 Физическое представление не определяет предметную идентичность

Объект может быть представлен:

в одной таблице;
в нескольких таблицах;
в документном хранилище;
в поисковом индексе;
в кэше;
в нескольких сервисах.

Но физические представления не становятся разными объектами только потому, что они хранятся отдельно.

И наоборот, несколько физических строк могут представлять один логический объект.

Поэтому сначала определяется:

Object identity

а уже затем:

physical representation

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

Иначе можно случайно построить разные правила доступа для разных частей одного объекта, не понимая, что они относятся к одной предметной сущности.

42.12 Объект может изменять набор релевантных отношений

Жизненный цикл объекта может менять не его идентичность, а значение окружающих отношений.

Например:

Document D
Draft

затем:

Document D
Review

затем:

Document D
Released

Сам объект остаётся тем же.

Но для него могут измениться:

• допустимые действия;

• роль согласующего;

• область публикации;

• возможность изменения;

• возможность удаления;

• доступность внешним пользователям.

То есть состояние объекта может менять контекст доступа.

42.13 Изменение одного отношения может менять доступ к объекту

Пусть:

User A
   ↓
member of
   ↓
Project P

и:

Document D
   ↓
belongs to
   ↓
Project P

Если пользователь покидает проект:

User A
   ↓
removed from
   ↓
Project P

Документ не изменился.

Но результат:

Can(User A, READ, Document D)

может измениться.

Это ещё раз показывает, почему доступ нельзя хранить только внутри пользователя или объекта.

Он зависит от отношения между ними и другими объектами.

42.14 Изменение самого объекта тоже может менять доступ

Обратная ситуация:

User A
   ↓
member of
   ↓
Project P

остаётся неизменной.

Но документ:

Document D

переносится из:

Project P

в:

Project Q

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

Изменился объектный факт.

Получается симметрия:

Subject relation changes
        ↓
Access may change

и:

Object relation changes
        ↓
Access may change

Поэтому модель доступа нельзя строить как одностороннюю функцию только от пользователя.

42.15 Некоторые отношения создают видимость, другие — возможность действия

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

Например:

Publication

может определять, что объект становится видимым в определённой области.

А:

Role

может определять допустимые действия.

При этом:

Owner

может быть отдельным основанием.

То есть вокруг одного объекта могут существовать отношения разного назначения:

visibility
ownership
membership
responsibility
delegation
lifecycle

Нельзя объединять их в одну категорию только потому, что все они используются при принятии решения.

Их смысл должен сохраняться.

42.16 Объект определяет не только отношения, но и допустимые действия

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

Например:

Document
→ READ
→ UPDATE
→ APPROVE
→ PUBLISH

а:

User
→ READ
→ UPDATE
→ CLOSE

а:

Project
→ READ
→ UPDATE
→ ARCHIVE

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

Это не означает, что сам объект содержит permissions.

Он задаёт предметную семантику, внутри которой permission имеет смысл.

42.17 Тип объекта и тип отношения образуют семантическое ограничение

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

Relation(ObjectType A, RelationType, ObjectType B)

Например:

User
 └── member of → Project

Document
 └── belongs to → Project

Part
 └── component of → Assembly

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

Она ограничивает пространство возможных security facts.

Если отношение не имеет смысла для данного типа объекта, оно не должно становиться основанием доступа.

Таким образом, корректная модель доступа начинается ещё раньше, чем появляется permission.

Она начинается с корректной модели объектов и отношений.

42.18 Почему нельзя начинать проектирование с ACL

Если начать сразу с таблицы:

user_id
object_id
permission

можно быстро получить работающий механизм.

Но такая таблица ничего не объясняет о происхождении права.

Почему пользователь получил permission?

Потому что:

• владелец;

• участник проекта;

• член группы;

• представитель другой организации;

• делегат;

• согласующий?

Если источник отношения не представлен отдельно, его невозможно корректно изменить без изменения самой ACL.

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

Objects
   ↓
Relationships
   ↓
Rules
   ↓
Permissions

а не наоборот.

42.19 Объект является точкой входа, но не центром всей модели

Можно легко впасть в другую крайность и считать, что вся модель строится вокруг объекта.

Но объект — только один из элементов:

Subject
Action
Object
Relationships
Context
Rules

Объект определяет:

• свою идентичность;

• предметную семантику;

• возможные отношения;

• допустимые действия;

• связи с другими объектами.

Но субъект определяет, кто выполняет действие.

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

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

Правила определяют, какое значение имеют эти связи.

И только после этого появляется эффективное разрешение.

42.20 Главный вывод

Мы начали книгу с вопроса:

почему недостаточно знать роль пользователя?

Теперь можно сформулировать следующий уровень ответа.

Проблема не только в том, что у пользователя может быть несколько ролей.

Проблема в том, что вокруг объекта существует множество отношений, и разные объекты допускают разные отношения.

Поэтому модель начинается с предметной сущности:

Object

Затем определяются:

какие отношения вокруг него возможны

затем:

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

затем:

какие правила применяются

и только после этого:

какое эффективное разрешение возникает

Получается цепочка:

Object
   ↓
Possible relationships
   ↓
Relevant relationships
   ↓
Context
   ↓
Rules
   ↓
Effective permission
   ↓
Access decision

Объект поэтому не является разрешением.

Но именно объект задаёт пространство предметных отношений, внутри которого вообще может быть построено решение о доступе.

Это возвращает нас к главному принципу книги:

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

Следующая глава сделает следующий шаг: если объект определяет возможные отношения, то именно отношения начинают формировать контекст, в котором принимается решение о доступе.