Глава 32. Репликация модели безопасности

32.1. Когда одной системы уже недостаточно

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

Например:

Service A
    ↓
owns object

Service B
    ↓
searches object

Service C
    ↓
builds report

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

Как сервис B должен узнать, какие пользователи имеют доступ к объектам сервиса A?

Простой ответ:

Каждый запрос отправлять обратно в сервис A.

Но тогда доступ к данным становится зависимым от удалённого вызова.

32.2. Локальная модель доступа

Более устойчивый вариант — иметь локальное представление необходимой части security model:

Central source facts
       ↓
Security change
       ↓
Service B projection
       ↓
Local authorization

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

Это важное ограничение.

Не нужно реплицировать весь граф отношений во все сервисы.

32.3. Данные и модель безопасности — разные вещи

В распределённой системе могут отдельно распространяться:

Domain data

и:

Security facts

Например, сервис может получить информацию:

User A can access Project P

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

И наоборот, сервис может владеть проектом, но не хранить все организационные отношения компании.

Поэтому репликация security model — самостоятельная архитектурная задача.

32.4. Что именно реплицировать

Есть принципиальная разница между:

Security facts

и:

Final ALLOW/DENY

Например, можно передать:

User A
Role = Reviewer
Scope = Project P

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

Так правила остаются частью локальной модели.

Передача готового:

ALLOW(User A, READ, Object X)

сильнее связывает сервисы.

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

32.5. Локальная проекция должна быть ограниченной

Сервису не обязательно знать:

все пользователи;
все группы;
все проекты;
все объекты;
все роли.

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

Например:

Service A
    ↓
Objects A1..An

Security projection
    ↓
only facts relevant to A1..An

Так уменьшаются:

• объём данных;

• стоимость обновления;

• радиус ошибки;

• зависимость между сервисами.

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

После изменения отношения может существовать состояние:

Source model = new
Local projection = old

Поэтому распределённая authorization model требует явного ответа на вопрос:

Что происходит в этот промежуток времени?

Особенно важен отзыв.

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

Поэтому допустимая задержка — не просто технический параметр.

Это часть security semantics.

32.7. Порядок и повторная обработка

Изменения могут:

• прийти повторно;

• прийти не по порядку;

• потеряться;

• быть обработаны частично.

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

idempotence

и возможность обнаружить пропуск.

При этом сама security model не должна зависеть от конкретного транспорта сообщений.

Транспорт — инфраструктурный механизм.

Модель отношений и разрешений — самостоятельный слой.

32.8. Снимок и последующие изменения

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

Snapshot
    +
Incremental changes

Например:

Security snapshot at T0
        ↓
changes T1
changes T2
changes T3

Если локальная проекция потеряна, её можно восстановить из снимка и изменений.

Но и здесь остаётся важным наличие исходной модели или возможности полного rebuild.

32.9. Локальное применение важнее удалённого решения

Запрос к данным желательно обслуживать локально:

Request
   ↓
Local security projection
   ↓
Local authorization
   ↓
Local data

а не:

Request
   ↓
Remote authorization service
   ↓
Remote response
   ↓
Local data

Второй вариант создаёт дополнительную зависимость от сети, задержки и доступности другого сервиса.

Это не делает централизованную авторизацию невозможной.

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

32.10. B2B добавляет ещё одну границу

В межорганизационном доступе появляется отношение:

Company A
    ↓ grants
Company B

Но оно само по себе не означает:

Company B can read everything from Company A

Остаются:

• конкретный объект;

• конкретная область;

• конкретное действие;

• уровень разрешения;

• локальные ограничения.

Поэтому B2B-отношение является одним из оснований доступа, а не универсальным разрешением.

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

В распределённой системе security model может иметь:

Central source facts
       ↓
Security changes
       ↓
Local security projection
       ↓
Local authorization
       ↓
Local data enforcement

Главный принцип:

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

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