Глава 37. Корпоративные системы

Корпоративная система — один из самых понятных примеров того, почему модель доступа постепенно перестаёт укладываться в схему:

User → Role → Permission

В небольшой системе этого действительно может быть достаточно.

Есть сотрудники.

Есть несколько ролей.

Есть набор операций.

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

Тогда возникает уже другой вопрос:

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

37.1 Корпоративный пользователь не является самостоятельным контекстом

Рассмотрим простую организацию:

Company
 ├── Engineering
 │    ├── Team A
 │    └── Team B
 ├── Sales
 └── Finance

Есть пользователь:

User A

Он может одновременно:

• работать в Engineering;

• участвовать в Team A;

• быть владельцем нескольких документов;

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

• временно замещать другого сотрудника.

Поэтому вопрос:

"What can User A do?"

не имеет одного ответа.

Более точный вопрос:

What can User A do
to Object O
in Context C?

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

37.2 Организационная принадлежность — это отношение

Пусть:

User A
   ↓
member of
   ↓
Engineering

Само это отношение ещё не является permission.

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

Например:

Engineering member
   ↓
may READ
   ↓
Engineering documents

Здесь участвуют как минимум два факта:

User A → Engineering
Document D → Engineering

И правило связывает их:

same organizational context
→ READ

Это уже существенно отличается от:

User A → READ

Право существует не само по себе.

Оно возникает из отношения пользователя к определённой части организационной структуры.

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

Пусть сотрудник:

User A

одновременно:

member of Engineering
member of Team A
manager of Project P
owner of Document D
reviewer of Document E

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

Нельзя автоматически объединить их в одно:

User A → Employee

потому что такая запись потеряет информацию о контексте.

Например:

manager of Project P

не означает:

manager of every project

А:

member of Engineering

не означает:

member of every team in Engineering

Отношение имеет собственную область действия.

37.4 Роль становится отношением, а не просто свойством пользователя

В классической модели можно записать:

User A → Manager

Но для корпоративной системы часто точнее:

User A
   ↓
Manager
   ↓
Project P

или:

User A
   ↓
Manager
   ↓
Department D

В первом случае роль действует внутри проекта.

Во втором — внутри подразделения.

Поэтому сама роль недостаточна.

Нужно знать:

кто
какая роль
в каком отношении
к какой области

Это один из самых важных переходов от простой RBAC-модели к более общей модели отношений.

37.5 Проект может быть самостоятельным контекстом

Корпоративный проект часто пересекает организационную структуру.

Например:

Project P
 ├── Engineering
 ├── Design
 └── Sales

В него входят сотрудники из разных подразделений.

Получается:

User A → Engineering
User B → Design
User C → Sales

и одновременно:

User A → Project P
User B → Project P
User C → Project P

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

Появляется ещё одно измерение:

Organization
+
Project

Это и есть пример контекста с несколькими независимыми отношениями.

37.6 Один объект может иметь несколько оснований доступа

Пусть документ:

Document D

одновременно:

owned by User A

и:

published in Project P

и:

belongs to Engineering

Пользователь User B может получить доступ через проект.

User A — как владелец.

Другой пользователь — через организационную роль.

Получается:

Document D
   ├── ownership
   ├── project publication
   └── organizational relation

И эффективное разрешение может иметь несколько оснований.

Это ровно тот случай, когда нельзя сказать:

"у документа есть одно право доступа"

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

37.7 Иерархия организации не означает автоматического наследования всех прав

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

Engineering
   ↓
Team A

Если пользователь является членом Engineering, это ещё не означает автоматически, что он имеет все права Team A.

И наоборот.

Иерархия показывает отношение:

Team A
   ↓
part of
   ↓
Engineering

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

Например:

Engineering member
→ READ all Engineering documents

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

Но:

Engineering member
→ MODIFY every Team A document

не следует из самой иерархии.

Поэтому:

иерархия организации создаёт отношения, но не определяет автоматически семантику разрешений.

37.8 Делегирование показывает временную природу контекста

Корпоративные системы часто содержат временные отношения.

Например:

Manager A
   ↓
delegates approval
   ↓
Manager B

сроком:

01.09 → 15.09

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

В один день:

Can(B, APPROVE, Document)?
→ YES

в другой:

→ NO

Хотя сам объект не изменился.

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

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

37.9 Корпоративный доступ часто имеет несколько независимых границ

Один и тот же пользователь может одновременно находиться внутри:

Company
Department
Team
Project
Object

Но эти границы не обязательно означают одно и то же.

Например:

Company

может определять общую изоляцию данных.

Department

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

Project

может определять рабочую область.

Object

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

Получается:

Company
   +
Department
   +
Project
   +
Object relation

Это не четыре разных пользователя.

Это четыре независимых измерения контекста.

37.10 Публикация особенно важна для корпоративных документов

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

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

created

но оставаться:

draft

для автора.

Затем его публикуют:

Document
   ↓
published to Project P

Теперь другие участники проекта могут получить к нему доступ.

Публикация здесь не является permission.

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

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

User relation to Project
+
Document publication
+
Permission

37.11 Группы дают ещё один уровень отношений

В организации могут существовать группы:

Engineering
   ├── Backend
   ├── Frontend
   └── QA

Пользователь может быть членом Backend.

Некоторые права могут распространяться на всю Engineering.

Другие — только на Backend.

Тогда недостаточно знать:

User A ∈ Backend

Нужно понимать, как отношение:

Backend
   ↓
Engineering

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

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

В другом — ничего не менять.

В третьем — ограничивать доступ.

Сама иерархия не отвечает на эти вопросы.

37.12 Массовые запросы делают физическое enforcement особенно важным

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

GET /documents

Список может содержать тысячи записей.

Проверять каждый документ отдельным запросом к authorization service было бы дорого.

Поэтому корпоративная система часто выигрывает от предварительно построенных security facts:

User
 ↓
effective relations
 ↓
effective permissions
 ↓
object scopes

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

Здесь хорошо проявляется вся архитектура книги:

Relationships
      ↓
Context
      ↓
Effective permission
      ↓
Authorization
      ↓
Data enforcement

37.13 Корпоративная система хорошо показывает разницу между субъектом и организационной структурой

Важно не превратить организацию в одного большого субъекта.

Если:

User A ∈ Engineering

это не означает:

User A = Engineering

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

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

User A
 ├── Engineering
 ├── Project P
 ├── Team A
 └── Review Board

Каждая связь может иметь собственную семантику.

Именно это делает модель отношений более выразительной, чем простое присвоение набора ролей пользователю.

37.14 Что происходит при изменении организационной структуры

Предположим, пользователь переводится:

Engineering
   ↓
Sales

Объекты при этом не изменяются.

Роли объектов тоже не обязательно изменяются.

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

То есть:

Organization change
      ↓
Relationship change
      ↓
Security model change
      ↓
Effective permissions change
      ↓
Future access changes

Это тот же механизм, который мы рассматривали ранее.

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

37.15 Корпоративная модель может быть проще или сложнее

Важно не считать корпоративную систему автоматически сложной.

Если требования таковы:

Company
+
Role
+
Permission

простая RBAC-модель может быть вполне достаточной.

Если появляются:

Department
+
Project
+
Group
+
Publication
+
Delegation
+
Object ownership

возникает потребность в более общей модели отношений.

Следовательно, предметная область определяет необходимую глубину модели.

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

37.16 Корпоративный пример показывает общий принцип

Корпоративная система хорошо демонстрирует весь путь:

User
  ↓
relationships
  ↓
organizational context
  ↓
project/object relations
  ↓
access grounds
  ↓
effective permission
  ↓
authorization
  ↓
data enforcement

При этом ни один отдельный элемент не является всей моделью.

Не является ею:

Role

Не является:

Group

Не является:

Project

Не является:

Publication

И даже:

Permission

не является готовым решением.

Решение возникает из их отношения друг к другу в конкретном контексте.

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

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

User → Role → Permission

остаётся полезной, но перестаёт быть полной.

Пользователь одновременно участвует в нескольких отношениях.

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

Группа и подразделение создают организационные отношения.

Проект формирует отдельную рабочую область.

Публикация определяет, с какой областью связан объект.

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

Делегирование добавляет временное отношение.

А изменение любого из этих фактов может изменить будущий результат проверки.

Получается:

Corporate access
=
Subjects
+
Relationships
+
Areas
+
Objects
+
Rules
+
Context

Но это не специальная модель именно для корпоративных систем.

Те же принципы проявляются в других предметных областях — только сами объекты и отношения будут другими.

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

В поиске по знаниям — документ, фрагмент, коллекция или источник.

В SaaS — ресурс конкретного клиента и его пользователей.

В B2B — отношения между организациями.

Модель остаётся той же:

Object
   ↓
Relationships
   ↓
Context
   ↓
Access

Меняется предметная семантика этих отношений.

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