RLS против выделенной базы данных для каждого проекта

Наиболее документированный шаблон для мультитенантного Postgres состоит из трех строк: одна база, столбец tenant_id в каждой таблице, политика RLS , которая сравнивает этот столбец со значением, извлеченным из JWT. Это экономично — пул подключений, диаграмма, один экземпляр для запуска — и хорошо работает, когда арендаторов много, они небольшие и имеют низкую индивидуальную долю.

Компромисс реален: граница между двумя клиентами становится выражением SQL , вычисляемым таблица за таблицей. Забытая политика для новой таблицы, соединение, запущенное с ролью суперпользователя, запущенный в реальном времени сценарий отладки — каждый из этих инцидентов, каким бы тривиальным он ни был в работе, может незаметно раскрыть строки всех арендаторов одновременно. Граница безопасности и техническая граница (основа) — это одно и то же.

После недавней консолидации поставщика услуг (отмеченной в коде как «Задача 12») активный проект Postgres в Aurabase подпадает ровно под две архитектуры — старые модели с базой, фактически используемой несколькими проектами, были удалены из пути обеспечения.

pub enum ProjectInstanceKind {
    /// Кластер CNPG, посвященный ТОЛЬКО ЭТОМУ проекту (уровень компании).
    FullyDedicated,

    /// База данных по кластеру CNPG проектной ОРГАНИЗАЦИИ —
    /// совместно с ДРУГИМИ проектами ТОЙ ЖЕ организации,
    /// никогда со сторонней организацией.
    SharedClusterDedicated,
}

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

fn should_provision_dedicated(engine: &str, db_url_encrypted: &Option<String>, plan: &str) -> bool {
    matches!(engine, "postgres" | "postgresql")
        && plan == "enterprise"
        && !non_empty(db_url_encrypted)
}

// must_route_to_fleet(): любой уровень, не относящийся к компании (бесплатный/профессиональный/командный)
// маршрут к кластеру CNPG ВАШЕЙ СОБСТВЕННОЙ организации, а не к одному
// из другого — см. миграцию 073, объединение на 2 архитектуры.

В обеих архитектурах база или кластер никогда не размещают две разные организации, поэтому вопрос не в том, «изолированы ли ваши данные», а в том, «имеет ли ваш проект вычислительные ресурсы CloudNativePG только для себя или он использует их совместно с другими проектами в той же организации».

Такое объединение двух архитектур произошло недавно: ранее код содержал два дополнительных пути — «общий мастер», где несколько проектов сосуществовали в одной базе данных, изолированных только диаграммой, и вариант postgrest_dedicated_shared_db. Специальная миграция удалила их и ужесточила ограничение таблицы projects только до двух оставшихся значений именно потому, что модель общей схемы была источником описанной ниже ошибки.

Отдельная база данных Postgres — это граница на уровне соединения, а не граница на уровне строк. Роль приложения, подключенная к базе данных проекта А, просто не может запрашивать таблицы проекта Б — у нее нет открытой для нее сессии. Это свойство сохраняется, даже если политика RLS написана плохо, отсутствует в таблице или обойдена высокой ролью: в худшем случае политика RLS остается ограниченной одной базой данных.

Этот депозит также несет в себе следы реальной ошибки, которая иллюстрирует противоположный риск. В соответствии со старой моделью общей схемы (которая была отменена) provision_postgres_schema по ошибке предоставил GRANT ALL ... TO PUBLIC права на каждую схему проекта - PUBLIC применил к все роли в базе данных без условий членства, вход для входа, изолированный для каждого проекта, мог читать и писать в схеме другого. Корректирующая миграция (066) удалила эти права из существующего.

Патч от 23 августа 2026 года идет в том же направлении: REVOKE ALL ON SCHEMA public, безоговорочно размещенный поставщиком услуг, был поставлен в зависимость от топологии, поскольку он обеспечивал реальную изоляцию только в старой модели общей базы данных — на двух текущих архитектурах он без всякой пользы блокировал импорт дампов SQL, которые явно ссылаются на public.<table>.

Ничто из вышеперечисленного не делает АРБ бесполезным — он просто меняет этажи. Попав в вашей базы данных проекта, Aurabase предоставляет именно то соглашение PostgREST, которое используется в Supabase: три функции SQL, которые считывают утверждения JWT, установленные шлюзом в request.jwt.claims.

create function auth.uid() returns uuid
    language sql stable security definer
    set search_path to 'pg_catalog', 'pg_temp'
    as $$
    select nullif(nullif(current_setting('request.jwt.claims', true), '')::json->>'sub', '')::uuid
$$;

Эти помощники используются в реальных политиках самой Aurabase, а не только в вашей документации. Вот политика, защищающая storage_objectsв том виде, в котором она размещена в репозитории (переформатирована на несколько строк для чтения):

alter table storage_objects enable row level security;

create policy storage_objects_select on storage_objects
  for select using (
    (owner_id = auth.uid())
    or (
      exists (
        select 1 from storage_buckets b
        where (b.name = storage_objects.bucket_name and b.public)
      )
    )
  );

В вашей собственной схеме project_<uuid>, которая содержит таблицы вашего приложения, Aurabase намеренно не размещает никаких политик от вашего имени — код документирует это как «модель Supabase»: RLS ваших таблиц остается под вашей ответственностью, с теми же функциями и тем же синтаксисом.

Postgres изначально предлагает атрибут роли , BYPASSRLS, который игнорирует все политики. Aurabase добровольно использует его в двух семействах ролей: aura_service_role (роль сервера, никогда не отображаемая на стороне браузера) и роль администрирования, специфичная для каждого проекта, используемая во время операций DDL, таких как ALTER SCHEMA ... OWNER TO.

create role aura_service_role nologin bypassrls;
-- Роль сервера: никогда не отображается на стороне браузера, никогда не является членом
-- роли из другого проекта.

Роль, обслуживающая ваши запросы anon/authenticated — tenant_<uuid> — не имеет никакого BYPASSRLS: RLS к ней применяется нормально, без исключений. В качестве бонуса системные диаграммы, специфичные для каждого проекта (_auth, _storage, _platform), получают активированный RLS без политики — поэтому по умолчанию полный отказ для любой роли без обхода, глубокая защита на случай, если путь приложения однажды по ошибке получит к нему доступ.

Эта роль сервера является частью более широкого подхода — предопределенных ролей, настраиваемого RBAC, журналов аудита — подробно описанного на странице Безопасность и RBAC.

На уровне SharedClusterDedicatedнесколько проектов одной организации сосуществуют в одном кластере CNPG. Физическая база данных уже отделяет проекты друг от друга, но роли PostgreSQL — они — являются глобальными объектами для кластера, а не для базы данных. Поэтому Aurabase добавляет уровень: отдельный логин PostgreSQL для каждого проекта.

pub fn project_authenticator_role(project_id: &str) -> String {
    format!("project_{}_authenticator", project_id.replace('-', '_'))
}

// Активен по умолчанию (F013_PER_PROJECT_AUTHENTICATOR), деактивируемый
// явно как аварийный выход.

Каждый проект подключается со своей собственной учетной записью, являясь членом только своих собственных ролей tenant_<uuid> / tenant_<uuid>_admin, а не ролей другого проекта в том же кластере. База данных уже изолирует данные; Этот вход для каждого проекта также изолирует удостоверение, которое с ним связано, так что инцидент в проекте не дает его входу какого-либо членства, которое можно было бы наследовать другому.

Выбор Aurabase — не универсальное правило — это компромисс для конкретного случая: изоляции клиентов друг от друга, потенциально с разными требованиями комплаенса, на платформе, которую они не контролируют. Если вы строите свой собственный SaaS, перед вами возникает тот же вопрос, но в другом масштабе.

• RLS с tenant_id в общей базе — актуально, когда у вас много арендаторов с низкой долей по отдельности, а стоимость базы на одного арендатора будет непропорциональной. Протестируйте каждую политику с помощью pg_proveна каждой таблице без исключения.
• Выделенная база или диаграмма — актуальна, когда у арендатора есть собственная проблема с соблюдением требований (здравоохранение, HR, государственный сектор), объем, который оправдывает изоляцию производительности, или если стоимость утечки между двумя конкретными клиентами будет непропорциональна стоимости дополнительной инфраструктуры.

Уровень цен Aurabase применяет тот же арбитраж к своим клиентам: общая база по умолчанию для организации, выделенный кластер, когда это оправдано сложностью проекта. Для шаблонов RLS внутри вашей собственной базы данных — владение, мультитенантность по организации, иерархия ролей — в руководстве RLS в рабочей среде подробно описаны три случая с тестами pgTAP. А если автоматически сгенерированный API на вашей диаграмме интересует вас за пределами REST, сравнение pg_graphql с Hasura и PostGraphile охватывает другую половину поверхности Postgres, предоставляемой Aurabase.