Глава 38. PLM

PLM (Product Lifecycle Management, управление жизненным циклом изделия) хорошо показывает, что контекст доступа может определяться не только организационной структурой.

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

User → Department → Project → Document

В PLM к этой цепочке добавляется сама структура изделия.

Изделие состоит из составных частей.

Документы относятся к изделиям или их компонентам.

Версии существуют в определённых состояниях.

Одни объекты являются исходными для других.

Спецификации связывают изделия, узлы, детали и материалы.

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

в каком подразделении работает пользователь?

Он становится вопросом:

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

38.1 В PLM объект имеет собственную структуру отношений

Рассмотрим простое изделие:

Product
 ├── Assembly A
 │    ├── Part A1
 │    └── Part A2
 └── Assembly B
      ├── Part B1
      └── Part B2

Каждый элемент этой структуры является самостоятельным объектом.

При этом между объектами существуют отношения:

Product → contains → Assembly A
Assembly A → contains → Part A1
Assembly A → contains → Part A2

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

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

Но они могут участвовать в формировании контекста доступа.

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

Получается уже знакомая нам конструкция:

Subject
   ↓
relationship
   ↓
Object

но сам Object теперь также находится внутри множества отношений.

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

Пусть пользователь имеет право работать с изделием P.

У него есть:

User A → Engineer → Project P

А:

Product P
   ↓
Assembly A
   ↓
Part A1

Возникает вопрос:

Can(User A, READ, Part A1)?

Одного отношения:

User A → Project P

может быть недостаточно.

Нужно ещё определить, как правила системы трактуют связь:

Part A1
   ↓
belongs to
   ↓
Product P

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

Тогда путь может выглядеть так:

User
 ↓
Project relation
 ↓
Product
 ↓
Assembly
 ↓
Part

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

Как и раньше, путь становится основанием доступа только тогда, когда это предусмотрено правилами модели.

38.3 Спецификация изделия — это не просто папка с файлами

В PLM особенно важно не сводить структуру изделия к физическому размещению документов.

Например, изделие может иметь спецификацию:

Product P
 ├── Assembly A × 1
 ├── Part B × 4
 └── Part C × 2

Эта структура описывает состав изделия.

Она не обязательно означает:

"все эти объекты находятся в одной папке"

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

Например:

Product P1
   ↓
Part X

Product P2
   ↓
Part X

Теперь у Part X есть как минимум два предметных отношения.

Доступ к нему нельзя корректно определить только по его физическому расположению.

Именно здесь особенно хорошо видно различие между:

Object

и:

Object placement

Физическое размещение — лишь один из возможных фактов.

38.4 Версия и состояние изменяют контекст

Инженерный объект обычно существует не только как идентичность.

У него есть жизненный цикл.

Например:

Part X
 ├── Revision 1 — Draft
 ├── Revision 2 — Review
 └── Revision 3 — Released

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

Например:

Draft
→ MODIFY

Review
→ READ
→ APPROVE

Released
→ READ

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

Но сама структура показывает важную вещь:

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

Поэтому:

Can(User, UPDATE, Part X)

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

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

Can(User, UPDATE, Part X, Revision 2, Review)?

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

38.5 Один инженерный объект может иметь несколько независимых оснований доступа

Предположим, инженер A работает над проектом P1.

Деталь X используется одновременно:

Product P1
Product P2

При этом:

User A → Engineer → P1

и:

User A → Reviewer → P2

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

Одно из них может давать право изменения.

Другое — только чтения или согласования.

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

User A has access

Нужно определить:

какое отношение действует
в какой области
для какого действия

Например:

User A
   ├── Engineer → P1 → MODIFY → X
   └── Reviewer → P2 → APPROVE → X

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

Это тот же принцип, который мы рассматривали в общей модели, но в PLM он становится особенно наглядным.

38.6 Документ, изделие и спецификация не обязаны иметь одинаковую модель доступа

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

Product
Part
Assembly
Drawing
Specification
Requirement
Change
Revision

У них могут быть разные отношения и разные правила.

Например, право на изменение детали не обязательно означает право на изменение чертежа этой детали.

Связь:

Drawing → describes → Part

не означает:

permission(Drawing) = permission(Part)

А связь:

Specification → describes → Product

не превращает спецификацию в часть самого изделия.

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

предметное отношение

и:

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

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

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

Структура:

Product
 └── Assembly
      └── Part

выглядит как естественная иерархия.

Но из неё не следует универсальное правило:

permission(Product)
→ permission(Assembly)
→ permission(Part)

Иногда такое наследование действительно является частью модели.

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

Иногда разные ветви изделия имеют разные ограничения.

Например:

Product P
 ├── Public Assembly
 │    └── Part A
 │
 └── Restricted Assembly
      └── Part B

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

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

Она является исходным фактом.

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

38.8 Жизненный цикл добавляет ещё одно измерение

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

Например:

Part X
   ↓
used in
   ↓
Product P

остаётся тем же отношением.

Но сама деталь проходит состояния:

Draft
   ↓
Review
   ↓
Approved
   ↓
Released

В результате один и тот же пользователь может получить разные результаты:

READ    → YES
UPDATE  → NO
APPROVE → YES

а после выпуска:

READ    → YES
UPDATE  → NO
APPROVE → NO

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

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

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

38.9 Изменение структуры изделия может иметь большой радиус влияния

Предположим, деталь X удаляется из спецификации:

Product P
   ↓
Assembly A
   ↓
Part X

Само изменение выглядит локальным.

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

Structure change
      ↓
Relationship change
      ↓
Security context changes
      ↓
Effective permissions change
      ↓
Future access decisions change

То же самое происходит при:

• изменении владельца;

• изменении проекта;

• публикации документа;

• изменении состояния;

• отзыве доступа;

• изменении состава изделия.

Поэтому в сложной PLM-системе изменение предметной модели может одновременно быть изменением модели безопасности.

38.10 150%-ная структура особенно хорошо показывает различие объекта и контекста

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

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

Такая структура может быть существенно шире конкретного экземпляра исполнения.

Это ещё один пример того, почему нельзя считать:

"находится внутри структуры"

синонимом:

"имеет одинаковый доступ"

Структура описывает предметную область.

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

Один и тот же инженерный объект может участвовать в нескольких спецификациях и сценариях.

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

38.11 В PLM объект может быть доступен через несколько независимых путей

Рассмотрим:

User A
 ├── Engineer → Project P1
 ├── Reviewer → Change C1
 └── Owner → Document D

и:

Document D
 ├── describes → Part X
 ├── belongs to → Product P1
 └── related to → Change C1

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

Для другого — несколько.

Например:

READ Document D

может быть разрешён через участие в проекте.

А:

APPROVE Change C1

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

Поэтому контекст не должен представлять собой весь граф PLM.

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

Это тот же принцип, который мы сформулировали раньше:

Context(Subject, Action, Object)

а не:

Context = complete state of PLM

38.12 Физические данные в PLM также требуют отдельного enforcement

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

Один Part может иметь:

identity
revision
attributes
documents
specification links
lifecycle state
change history

Физически эти данные могут находиться в разных таблицах или даже в разных хранилищах.

Поэтому:

ALLOW(Part X)

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

ALLOW(all physical data related to Part X)

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

Особенно это важно для массовых операций:

получить все доступные детали
получить все документы проекта
получить спецификацию изделия
получить историю изменений

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

Физический путь к данным тоже должен быть ограничен.

Это возвращает нас к различию между:

Authorization

и:

Data enforcement

которое мы рассматривали ранее.

38.13 Что PLM добавляет к общей модели

Корпоративная система показала:

User
→ Organization
→ Project
→ Object

PLM добавляет ещё один слой:

User
   ↓
Organizational relations
   ↓
Project relations
   ↓
Product structure
   ↓
Object relations
   ↓
Lifecycle state
   ↓
Access decision

Но это не новая модель доступа.

Это тот же принцип, применённый к другой предметной области.

В PLM особенно хорошо видны три важных различия.

Первое:

предметная структура ≠ модель доступа

Второе:

отношение между объектами ≠ разрешение

Третье:

иерархия ≠ автоматическое наследование прав

Эти различия позволяют не превращать всю структуру изделия в огромную ACL.

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

PLM показывает ещё одну важную сторону контекста.

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

В PLM в него могут дополнительно входить отношения между самими объектами:

User
  ↓
Project
  ↓
Product
  ↓
Assembly
  ↓
Part

а также:

Part
  ↓
Revision
  ↓
Lifecycle state

При этом ни один из этих элементов сам по себе не является готовым разрешением.

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

Спецификация не является правом.

Проект не является правом.

Состояние объекта не является правом.

Даже роль пользователя не является готовым решением.

Они становятся частью решения только в рамках определённых правил.

Поэтому для PLM можно записать ту же общую конструкцию:

Subject
   +
Object
   +
Relationships
   +
Areas
   +
State
   +
Rules
   ↓
Context
   ↓
Effective permission
   ↓
Access decision

Главное здесь не сама структура изделия.

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

Именно поэтому в сложной системе безопасности нельзя полностью отделить вопрос «что это за объект?» от вопроса «в каком отношении он находится с другими объектами?».

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