Глава 5. Объект как предмет действия

В предыдущих главах мы пришли к формуле:

Subject → Action → Object

Она важна не своей простотой, а тем, что заставляет задать точный вопрос:

Над чем именно субъект пытается выполнить действие?

Ответом является объект.

5.1. Объект — это предмет действия

Если Alice читает документ D:

Alice → READ → D

объектом является D.

Если Alice изменяет проект P:

Alice → UPDATE → P

объектом является P.

Если администратор изменяет данные пользователя B:

Administrator → UPDATE → B

объектом является B.

Таким образом, объект в модели доступа — это не обязательно «документ», «запись» или какая-либо другая заранее определённая сущность.

Объект — это сущность, над которой в данном решении выполняется действие.

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

5.2. Объект имеет собственную идентичность

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

Недостаточно знать:

Alice → READ → Document

Нужно знать:

Alice → READ → Document D

Потому что у Alice может быть право читать один документ и не быть права читать другой.

Следовательно, объект должен иметь устойчивую идентичность.

Она позволяет различать:

D1 ≠ D2

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

5.3. Идентичность объекта не равна его физическому хранению

В информационной системе объект может храниться в нескольких таблицах, документах или других структурах.

Одна физическая запись может быть частью более сложного объекта.

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

Поэтому:

Object ≠ Database Row

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

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

5.4. Объект существует до решения о доступе

Сначала существует объект.

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

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

Условно:

Object D
   ↓
кто может выполнить действие?
   ↓
Access Decision

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

Сам объект от этого не становится другим объектом.

5.5. Один объект может участвовать в разных решениях

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

Alice → READ   → D
Alice → UPDATE → D
Bob   → READ   → D
Carol → APPROVE → D

Это четыре разных решения.

Даже если речь идёт об одном и том же объекте, результат может отличаться в зависимости от:

• субъекта;

• действия;

• других фактов, участвующих в решении.

Поэтому нельзя говорить просто:

«Пользователь имеет доступ к объекту».

Точнее сказать:

«Для данного субъекта допустимо определённое действие над данным объектом».

5.6. Объект не определяет право доступа

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

Наличие документа не говорит, кто может его читать.

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

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

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

Поэтому модель:

Object → Permission

так же недостаточна, как и старая модель:

User → Role → Permission.

Для решения нужно сохранить как минимум тройку:

Subject → Action → Object

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

5.7. Один и тот же объект может быть предметом разных отношений

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

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

Но сами эти отношения не являются частью определения объекта.

Это принципиальное разделение:

Object
   +
Relations
   +
Rules
   ↓
Access Decision

Объект задаёт над чем выполняется действие.

Отношения и правила позволяют определить, допустимо ли это действие.

5.8. Почему объект — отправная точка, а не вся модель

До этого момента мы сознательно говорили преимущественно о субъекте.

Теперь становится видно, почему этого недостаточно.

Нельзя определить доступ, зная только:

Who?

Нужно также знать:

What action?

и:

Over what object?

Но и это пока не даёт ответа.

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

Именно из этих фактов начинает формироваться конкретная ситуация доступа.

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

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

Он имеет собственную идентичность и не обязан совпадать с физической записью в базе данных.

При этом объект сам по себе не определяет доступ.

Базовая конструкция остаётся:

Subject → Action → Object

Но для принятия решения этого недостаточно.

Следующий вопрос:

Какие факты должны быть известны о субъекте, объекте и их отношениях, чтобы принять это решение?