Глава 34. Где RLS подходит, а где нет

34.1. Два разных вопроса

К этому моменту можно сформулировать важное различие.

Первый вопрос:

Как определить, имеет ли субъект право действовать над объектом?

Второй:

Как физически ограничить данные после того, как такое право определено?

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

Для второго — разные механизмы enforcement.

RLS относится прежде всего ко второму вопросу.

34.2. Relationship-Based Access Control

Один из важных классов моделей — ReBAC (Relationship-Based Access Control, управление доступом на основе отношений).

В ReBAC отношения между субъектами, объектами и другими сущностями становятся частью основания доступа.

Упрощённо:

User
  ↓ member
Group
  ↓ has access
Project
  ↓ contains
Object

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

Именно эту проблему мы рассматривали в предыдущих главах.

34.3. Zanzibar

Одним из наиболее известных опубликованных примеров relationship-based подхода является Zanzibar — архитектура системы авторизации, опубликованная Google.

Её важность для рассматриваемой темы не в конкретном API или формате хранения.

Важен сам архитектурный принцип:

authorization
    ↓
relationships
    ↓
objects
    ↓
permissions

То есть авторизация рассматривается как вычисление на модели отношений.

Это очень близко к центральной идее книги:

Object
   ↓
Relationships
   ↓
Context
   ↓
Effective permission

Но это не означает, что описываемая здесь модель является реализацией Zanzibar.

34.4. OpenFGA, SpiceDB и Ory Keto

На практике существуют системы, реализующие близкий класс relationship-based подходов, например:

• OpenFGA;

• SpiceDB;

• Ory Keto.

Они предлагают отдельные механизмы моделирования отношений и вычисления авторизации.

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

Но архитектурная идея пересекается:

Relationships
       ↓
Authorization decision

Это полезно сравнивать с другими архитектурами не на уровне названий продуктов, а на уровне ответственности.

34.5. Где находится наша модель

Рассмотренная в книге модель также исходит из отношений:

Subject
Object
Relationship
Area
Context
Rule
Effective permission

Но из этого ещё не следует конкретный продукт или конкретный authorization engine.

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

• отдельным authorization service;

• библиотекой;

• SQL-проекциями;

• частью приложения;

• комбинацией этих механизмов.

Поэтому модель и реализация должны оставаться различимыми.

34.6. Где здесь PostgreSQL RLS

Теперь можно поставить RLS в эту картину.

Relationship model
        ↓
Authorization
        ↓
Effective permission
        ↓
RLS
        ↓
Physical rows

RLS находится ниже модели отношений.

Он не отвечает на вопрос:

Почему пользователь связан с объектом?

Он отвечает:

Какие строки должен пропустить текущий SQL-запрос?

Поэтому:

ReBAC ≠ RLS

И:

RLS ≠ authorization model

34.7. Почему эти подходы могут использоваться вместе

Нет необходимости выбирать между:

ReBAC

и:

RLS

как между взаимоисключающими технологиями.

Они могут находиться на разных уровнях:

Relationship-based model
        ↓
Security projections
        ↓
Object authorization
        ↓
RLS

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

34.8. Guardian как конкретный пример

Guardian реализует не «Zanzibar внутри PostgreSQL».

Его архитектура другая.

В ней security state заранее материализуется в проекциях:

effective_user_group
effective_user_permission
object_scope

После этого объектная авторизация сопоставляет:

effective_user_permission
        +
object_scope

а физические данные дополнительно защищаются RLS.

Поэтому Guardian интересен здесь не как реализация какого-либо одного промышленного стандарта.

Он является примером другой точки сборки тех же архитектурных идей:

Relations
   ↓
Projections
   ↓
Authorization
   ↓
Database enforcement

34.9. Когда RLS особенно естественен

RLS хорошо подходит, когда граница безопасности совпадает с физическими строками.

Например:

company_id
tenant_id
owner_id
object_id

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

Особенно полезен RLS для массовых запросов:

SELECT ...
FROM objects

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

34.10. Когда RLS недостаточен

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

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

Такое правило относится к authorization model.

Попытка целиком перенести его в RLS смешивает:

Business semantics
Authorization
Data enforcement

и усложняет каждую из них.

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

Промышленные relationship-based системы показывают, что сложный доступ действительно можно моделировать через отношения.

RLS показывает другую сторону задачи: даже правильно вычисленное разрешение должно быть применено к физическим данным.

Поэтому полезно разделять:

Relationship model
        ↓
Authorization
        ↓
Data enforcement

Zanzibar, OpenFGA, SpiceDB и Ory Keto относятся прежде всего к первому и второму уровням.

PostgreSQL RLS — к третьему.

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