Глава 36. Границы модели

36.1. Модель доступа не равна всей безопасности

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

Subject
Object
Relationship
Scope
Context
Rule
Effective permission
Projection
RLS

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

Может ли всё это стать единой моделью безопасности системы?

Нет.

Модель доступа решает конкретный класс задач.

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

36.2. Что относится к модели доступа

Если правило отвечает на вопрос:

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

оно относится к access model.

Например:

User A
   ↓
member of Group G
   ↓
Group G has access to Project P
   ↓
Object X published in Project P

Если эти факты определяют:

Can(User A, READ, Object X)?

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

36.3. Что находится за её пределами

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

Например:

name
language
avatar

могут вообще не влиять на authorization.

То же самое относится к многим техническим свойствам объекта.

Следовательно:

System state ≠ Access context

Контекст выбирает только релевантные факты.

36.4. Аутентификация находится раньше

Сначала нужно установить:

Кто выполняет запрос?

Это задача аутентификации (authentication, проверка подлинности субъекта).

Затем:

Что этот субъект может сделать?

Это задача авторизации.

Поэтому:

Authentication
      ↓
Subject
      ↓
Authorization

Нельзя заменить одно другим.

Установленный user_id ещё не является разрешением.

36.5. Бизнес-правило не всегда является правилом доступа

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

Order cannot be closed after shipment.

Это ограничение бизнес-состояния.

Оно может применяться даже к пользователю, который имеет:

CLOSE

Следовательно:

Permission

и:

Business invariant

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

Упрощённо:

Authorization
     +
Business validity
     ↓
Operation allowed

36.6. RLS находится ещё ниже

RLS также не является всей моделью.

Он отвечает за физическое применение ограничений к данным.

Получается несколько уровней:

Authentication
      ↓
Authorization model
      ↓
Business rules
      ↓
Data enforcement

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

Но ответственность уровней должна оставаться различимой.

36.7. Контекст — не снимок всей системы

Контекст также имеет границы.

Если в системе существуют:

10 million users
1 million objects
100 million relationships

это не означает, что контекст конкретного запроса содержит всё это состояние.

Для:

Can(User A, READ, Object X)?

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

Поэтому:

Context(S, A, O)

зависит от конкретного запроса.

36.8. Не вся связь является связью безопасности

Объект может иметь десятки отношений:

created by
modified by
linked to
located in
referenced by
owned by
published in

Но только часть из них может участвовать в авторизации.

Например:

Object X references Object Y

не означает автоматически:

User who can read X can read Y

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

36.9. Не вся техническая система является субъектом

Сервис может выполнять SQL.

База данных может выполнять функцию.

Фоновый worker может запускать операцию.

Но техническая возможность выполнить запрос ещё не означает, что каждый компонент является самостоятельным бизнес-субъектом.

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

Who is acting?

и:

Who is trusted to perform enforcement?

36.10. Почему границы важны

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

Если слишком широкая, она начинает описывать:

everything about everything

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

Поэтому хороший критерий прост:

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

Если не влияет — нет причины включать его только ради полноты.

36.11. Минимальное ядро модели

После всех рассмотренных расширений можно вернуть модель к нескольким элементам:

Subject
Action
Object
Relationships
Areas
Context
Access grounds
Rules
Effective permissions

Вокруг них уже могут существовать:

Projections
RLS
Audit
Encryption
Replication
Caching
Business invariants

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

36.12. Граница между моделью и реализацией

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

Например:

Relationship model

может использовать:

authorization service
database projections
application code

или их комбинацию.

А физическое применение может использовать:

RLS
views
procedures
repository filters

Следовательно:

Conceptual model ≠ Implementation mechanism

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

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

Модель доступа имеет чёткую границу.

Она начинается там, где возникает вопрос:

Can(Subject, Action, Object, Context)?

и заканчивается там, где начинаются другие задачи:

Authentication
Business integrity
Encryption
Audit
Retention
Backup
Operational trust

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

Именно поэтому архитектура безопасности становится устойчивой тогда, когда разные вопросы имеют разные уровни ответственности.

36.14. Перед следующей частью

К этому моменту можно собрать весь путь в одну цепочку:

Object
   ↓
Relationships
   ↓
Relevant facts
   ↓
Context
   ↓
Access grounds
   ↓
Rules
   ↓
Effective permission
   ↓
Object authorization
   ↓
Data enforcement
   ↓
Physical data

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

Если эта модель применима к корпоративным системам, PLM, поиску знаний, SaaS и межсервисному доступу, то насколько универсален сам принцип?

Именно это будет предметом следующей части.