От объекта к контексту

Глава 2. Доступ — это отношение

2.1. От разрешения к действию над объектом

Простая модель доступа выглядит так:

User → Role → Permission

Она полезна, пока вопрос звучит достаточно абстрактно:

Что вообще может делать этот пользователь?

Но реальные системы задают другой вопрос:

Может ли этот субъект выполнить конкретное действие над конкретным объектом?

Тогда появляется объект:

Subject → Action → Object

Subject — субъект действия.

Action — действие.

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

Например:

Иван → READ → Документ X

или:

Сервис A → UPDATE → Заказ Y

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

2.2. Субъект и объект

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

Объектом является то, над чем выполняется действие. Важно, что объект не обязан быть строкой базы данных. Физическая строка — это способ хранения. Объект — понятие предметной модели. Один объект может быть представлен несколькими строками, таблицами или даже несколькими хранилищами. Поэтому вопрос доступа начинается не с SQL-запроса:

к какой строке разрешён доступ?

а с вопроса:

c каким объектом выполняется действие?

Только после этого можно определить, какие физические данные должны быть доступны.

2.3. Действие

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

READ
UPDATE
CLOSE
APPROVE

Субъект может иметь право читать объект, но не изменять его. Может изменять, но не закрывать. Может согласовывать, но не изменять. Поэтому:

Access(Object)

слишком грубая формулировка. Нужна как минимум:

Can(Subject, Action, Object)

2.4. Откуда появляется отношение

Связь между субъектом и объектом редко возникает непосредственно. Она может быть следствием других отношений. Например:

User
  ↓ member of
Group
  ↓ participates in
Project
  ↓ publishes
Object

Или:

User
  ↓ assigned
Role
  ↓ valid in
Project
  ↓ applies to
Object

Или:

User
  ↓ owns
Object

Каждая такая связь является фактом. Но ни одна из них сама по себе ещё не обязана быть разрешением. Членство в группе — не право READ. Владение объектом — не обязательно право APPROVE. Публикация объекта — не разрешение выполнить любое действие.

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

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

Предположим, пользователь может читать документ потому, что:

• он владелец;
• он участник проекта;
• его группа получила доступ;
• объект опубликован в области, доступной его роли.

Это разные основания. Но результат может быть один:

READ

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

основание доступа

и

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

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

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

2.6. Доступ как отношение между сущностями

Такой способ мышления приводит к классу моделей, в которых доступ определяется отношениями между сущностями. Один из распространённых терминов для такого подхода — ReBAC (Relationship-Based Access Control, управление доступом на основе отношений).

Смысл здесь не в конкретном продукте или протоколе. Смысл в том, что отношения становятся частью основания решения:

Subject
   ↓
Relationships
   ↓
Object

Роль, членство, владение, публикация, принадлежность к проекту или делегирование становятся входными данными модели. Но это ещё не означает, что любая существующая связь автоматически даёт право.

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

2.7. Отношение ещё не объясняет решение

Пусть известно:

User U is member of Group G

Из этого нельзя автоматически вывести:

U can READ Object O

Нужно знать:

• связан ли G с O;
• в какой области действует связь;
• какое действие рассматривается;
• какие права имеет отношение;
• есть ли дополнительные ограничения;
• не изменяет ли состояние объекта применимость правила.

Поэтому между отношением и разрешением появляется ещё один уровень.

Это контекст.

Контекст связывает релевантные факты с конкретным вопросом доступа.

2.8. От отношения к контексту

Первый вопрос системы:

Can(Subject, Action, Object)?

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

какие отношения и факты имеют значение именно для этого решения?

Это уже другой вопрос. Из него возникает следующий уровень модели:

Object
   ↓
Relationships
   ↓
Relevant facts
   ↓
Context
   ↓
Rules
   ↓
Effective permission
   ↓
Access decision

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