Глава 33. Цена сложной модели доступа

33.1. Сложная модель не бывает бесплатной

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

Появляются:

relations
hierarchies
publications
delegations
scopes
projections
synchronization
rebuilds

Поэтому нельзя рассматривать сложную authorization model только как способ получить более точный результат.

Она меняет архитектуру всей системы.

33.2. Проекции переносят стоимость

Если система вычисляет всё во время запроса:

Request
   ↓
Graph traversal
   ↓
Decision

стоимость возникает при чтении.

Если система строит проекции заранее:

Change
   ↓
Projection update

стоимость переносится на изменение.

Получается:

Runtime read
    ← cheaper

Data change
    ← more expensive

Это не устранение стоимости.

Это изменение её места.

33.3. Появляется дополнительное хранилище

Каждая производная проекция требует:

• места;

• индексов;

• обновления;

• очистки;

• восстановления;

• мониторинга.

Поэтому нужно спрашивать:

Действительно ли эта проекция сокращает необходимую стоимость системы?

Если проверка выполняется один раз в сутки, сложная materialized security model может не иметь смысла.

Если проверка выполняется миллионы раз в секунду, ситуация будет другой.

33.4. Меняется стоимость изменения

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

User A → Group G

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

Поэтому стоимость операции:

UPDATE one relation

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

Её реальная цена определяется радиусом влияния.

33.5. Сложность появляется и в тестировании

Нужно проверять не только:

User can read Object

но и:

why?

и:

what happens after revoke?

и:

what happens after intermediate relation changes?

и:

what happens after rebuild?

Чем больше путей к одному праву, тем больше комбинаций для проверки.

33.6. Сложность появляется при восстановлении

Проекция должна быть:

rebuildable

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

Поэтому при проектировании нужно учитывать не только:

How is permission computed?

но и:

How is permission reconstructed?

33.7. Распределённая система увеличивает цену

Если security model пересекает сервисные границы, добавляются:

replication
ordering
lag
failure recovery
version compatibility

Теперь изменение отношения должно не только изменить локальную проекцию.

Оно должно добраться до других владельцев производного состояния.

33.8. Когда сложность оправдана

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

Subjects
+
Objects
+
Relationships
+
Areas
+
Hierarchies
+
Publication
+
Delegation
+
Mass data access

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

33.9. Когда можно остаться проще

Если система имеет:

few users
few objects
one organization
simple roles
no hierarchy
no delegation

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

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

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

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

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

Storage
Computation
Synchronization
Testing
Recovery
Observability

Поэтому правильный вопрос не:

Какая модель доступа самая мощная?

а:

Какая модель точно описывает отношения предметной области при приемлемой эксплуатационной стоимости?

Авторизация является частью архитектуры системы.

И её сложность должна быть соразмерна сложности самого мира, который система моделирует.