Эпилог

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

User → Role → Permission

В конце эта цепочка никуда не исчезла.

Она просто оказалась частью большей модели.

Object
   ↓
Relationships
   ↓
Relevant facts
   ↓
Context
   ↓
Rules
   ↓
Effective permission
   ↓
Authorization
   ↓
Data enforcement

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

Она была неполной.

Для простой системы этого различия может быть достаточно.

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

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

Любая модель начинается не с разрешения.

Сначала существует что-то, над чем вообще можно совершить действие.

Документ.

Проект.

Заказ.

Изделие.

Запись.

Файл.

Знание.

Сервисный ресурс.

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

И только после этого возникает вопрос:

Кто и что может с ним сделать?

Вокруг объекта существуют отношения

Объект никогда не существует изолированно.

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

Находиться в проекте.

Быть частью группы.

Быть опубликованным в области.

Иметь состояние.

Быть связанным с другими объектами.

Эти отношения существуют независимо от того, проверяет ли их система прямо сейчас.

Некоторые из них имеют значение для безопасности.

Некоторые — нет.

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

Нужно определить релевантные.

Из отношений возникает контекст

Контекст не является ещё одной сущностью, которую обязательно нужно сохранить в таблице.

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

Для одного запроса важен проект.

Для другого — владелец.

Для третьего — состояние объекта.

Для четвёртого — делегирование.

Контекст зависит от:

Subject
Action
Object

Поэтому один и тот же объект не имеет единственного контекста доступа.

Контекст возникает заново для конкретного вопроса.

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

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

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

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

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

Пользователь может иметь роль, но только в определённой области.

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

Отношение говорит, что связь существует.

Правило говорит, что эта связь означает.

Разрешение становится производным фактом

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

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

Оно является результатом вычисления:

Context
   ↓
Rules
   ↓
Effective permission

Это различие важно не только теоретически.

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

Его можно индексировать.

Его можно реплицировать.

Его можно перестраивать.

Но источником истины остаются исходные факты и правила.

Доступ становится частью архитектуры данных

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

Data model

с одной стороны и:

Security

с другой.

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

Если изменение отношения меняет доступ, изменение отношения становится одновременно изменением security model.

Если разрешение материализуется в проекции, эта проекция становится частью инфраструктуры данных.

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

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

Но границы всё равно существуют

Это не означает, что вся система должна превратиться в одну большую security model.

Аутентификация остаётся отдельной задачей.

Бизнес-инварианты остаются отдельной задачей.

Шифрование, аудит, резервное копирование и эксплуатационное доверие имеют собственные уровни ответственности.

Даже контекст не является снимком всей системы.

Хорошая модель не стремится описать всё.

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

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

В итоге путь книги можно свести к четырём предложениям.

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

Отношения формируют контекст.

Контекст определяет доступ.

Доступ становится частью архитектуры данных.

Это не алгоритм конкретной системы.

Это способ смотреть на архитектуру.

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

Нужно спросить:

Какие отношения могут существовать вокруг него?

Когда появляется новое отношение, нужно спросить:

Меняет ли оно контекст доступа?

Когда появляется новое правило, нужно спросить:

Как оно изменяет эффективное разрешение?

Когда появляется новая таблица, нужно спросить:

Как логический объект связан с физическими данными?

И когда меняется отношение, нужно помнить:

Возможно, изменилось не только состояние предметной области. Изменилась сама модель безопасности.

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

Эта книга начинается с другого навыка.

Увидеть то, что связывает созданные объекты.

Потому что система начинается не там, где появляются данные.

Она начинается там, где между ними появляются отношения.

И именно в этих отношениях часто находится настоящий контекст происходящего.