Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Глава 6. Факты вокруг объекта

Мы определили объект как предмет действия.

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

Ответ начинается с простого понятия — факта.

6.1. Объект существует внутри множества фактов

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

О системе может быть известно:

Alice created D
Bob owns D
D belongs to Project P
Alice is member of Group G
Group G has access to D
D is in state REVIEW

Сам документ — только один элемент этой картины.

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

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

6.2. Факт — это утверждение о состоянии системы

Факт отвечает на некоторый конкретный вопрос.

Например:

  • Alice создала D;

  • Bob владеет D;

  • Alice состоит в G;

  • D опубликован в P;

  • P связан с G.

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

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

Например, для:

Can(Alice, READ, D)

может иметь значение членство Alice в группе.

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

6.3. Факт и отношение

Многие факты имеют форму отношения:

Subject → Relation → Object

Например:

Alice → member_of → G

Bob → owns → D

D → published_in → P

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

Объект отвечает на вопрос:

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

Отношение отвечает на вопрос:

Как этот объект связан с другими участниками модели?

6.4. Не каждый факт является фактом безопасности

Предметная модель обычно содержит гораздо больше информации, чем требуется для авторизации.

Документ может иметь:

  • название;

  • дату создания;

  • автора;

  • размер;

  • формат;

  • статус;

  • проект;

  • владельца.

Но конкретному решению о доступе может быть нужна только часть этих сведений.

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

Нужны только релевантные факты.

6.5. Релевантность определяется запросом

Предположим, система получает запрос:

Can(Alice, READ, D)

Для ответа может потребоваться знать:

  • кто владеет D;

  • опубликован ли D;

  • состоит ли Alice в группе, которой доступен D;

  • какую роль Alice имеет в соответствующем проекте.

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

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

Таким образом:

RelevantFacts = f(Subject, Action, Object)

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

6.6. Один объект — множество отношений

Объект может одновременно находиться в нескольких структурах.

Например:

Alice ──owns──────→ D
D     ──belongs───→ P
Alice ──member────→ G
G     ──access────→ D

Эти отношения не являются взаимозаменяемыми.

Владение — не членство.

Членство — не публикация.

Публикация — не право изменения.

Каждое отношение имеет собственный смысл.

6.7. Отношения могут соединять не только пользователя и объект

Отношение может связывать:

  • пользователя и объект;

  • пользователя и группу;

  • группу и проект;

  • объект и проект;

  • объект и другой объект;

  • организацию и пользователя;

  • сервис и ресурс.

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

User → Object.

В реальной системе отношения образуют сеть.

Но сама по себе сеть ещё не является разрешением.

6.8. Связь не равна праву

Пусть:

Alice → member_of → G

Это ещё не означает:

Alice → READ → D.

Чтобы получить второе утверждение, необходимо дополнительное правило.

Например:

Alice ∈ G
G has access to D
        ↓
Alice can READ D

Но другое правило может дать другой результат.

Следовательно:

отношение является фактом, а право — результатом применения правил к фактам.

Это одно из главных разделений всей модели.

6.9. Изменение отношения может изменить доступ

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

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

Alice ∈ G
G has access to D

и поэтому Alice может читать D.

Если Alice покидает G:

Alice ∉ G

сам D не изменился.

Но набор релевантных фактов изменился.

Следовательно, может измениться и результат:

Can(Alice, READ, D)

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

Изменилось отношение вокруг объекта.

6.10. Отношение может быть многошаговым

Связь между субъектом и объектом не всегда существует напрямую.

Например:

Alice
  ↓
member of
  ↓
Group G
  ↓
member of
  ↓
Project P
  ↓
contains
  ↓
Document D

Или:

Alice
  ↓
role in Project P
  ↓
Project P
  ↓
publication
  ↓
Document D

В обоих случаях конечное разрешение может зависеть от нескольких исходных фактов.

Это уже не простая таблица:

User → Permission.

Это структура отношений, из которой система получает производные факты.

6.11. Иерархия тоже создаёт отношения

Иерархические структуры являются частным случаем сети отношений.

Например:

Group A
   ↓
Group B
   ↓
Group C

Но из самой иерархии ещё не следует, что право автоматически распространяется между всеми уровнями.

Нужно отдельное правило, определяющее, как отношение на одном уровне влияет на другой.

Поэтому:

Hierarchy ≠ Permission

Иерархия предоставляет факты.

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

6.12. Факты могут быть исходными и производными

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

Например, исходные факты:

Alice ∈ Group G
G has access to D

могут позволить получить производный факт:

Alice can READ D

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

Это особенно важно для больших систем.

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

6.13. Производный факт не меняет исходную модель

Если система вычислила:

Alice can READ D

это не означает, что в предметной области появился новый объект или новое бизнес-отношение.

Это результат применения модели.

Условно:

Исходные факты
      ↓
Правила
      ↓
Производный security-факт

Поэтому полезно разделять:

источник истины и результат вычисления.

Предметные отношения описывают состояние системы.

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

6.14. Факты могут меняться независимо от объекта

Документ D может оставаться неизменным в течение месяца.

При этом:

  • пользователь может войти в группу;

  • выйти из группы;

  • получить роль;

  • потерять роль;

  • получить доступ;

  • потерять доступ;

  • изменить владельца объекта.

В каждом случае изменяются отношения вокруг D.

Поэтому безопасность объекта имеет собственную динамику.

Она не обязана совпадать с изменениями самого объекта.

6.15. Что именно входит в контекст

Теперь можно уточнить определение из главы 3.

Контекст конкретного решения можно рассматривать как множество релевантных фактов:

Context(Subject, Action, Object) = RelevantFacts

Это не означает, что контекст — отдельная сущность в базе данных.

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

Часть этих фактов может быть исходной.

Часть — производной.

Часть может храниться рядом с объектом.

Часть — в отдельных структурах безопасности.

6.16. Контекст строится не вокруг объекта одного

Хотя объект является предметом действия, контекст формируется из нескольких элементов:

Subject
   +
Action
   +
Object
   +
Relevant Facts
   +
Relations

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

«Контекст — это свойства объекта».

И нельзя сказать:

«Контекст — это свойства пользователя».

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

6.17. От фактов к основаниям доступа

На этом этапе появляется следующий вопрос.

Мы знаем, что:

Alice ∈ Group G
G has access to D

Но почему это означает право Alice читать D?

Потому что существует правило, связывающее эти факты с разрешением.

Значит, нам нужно отделить:

Факт
   ↓
Основание
   ↓
Разрешение

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

И наоборот, один факт может вообще не давать никаких прав, пока не будет применено соответствующее правило.

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

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

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

Вокруг него существует множество фактов и отношений.

Но не каждый факт имеет значение для каждого решения.

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

Object

Fact

Relation

Effective Permission

И самое важное:

из факта ещё не следует право.

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

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