RLS rispetto a un database dedicato per progetto

Il modello più documentato per Postgres multi-tenant è costituito da tre righe: una singola base, una colonna tenant_id su ciascuna tabella, una policy RLS che confronta questa colonna con un valore estratto dal JWT. È economico (un pool di connessioni, un diagramma, una singola istanza da eseguire) e funziona bene quando gli inquilini sono numerosi, piccoli e con una bassa partecipazione individuale.

Il compromesso è reale: il confine tra due client diventa un'espressione SQL , valutata tabella per tabella. Una policy dimenticata su una nuova tabella, una connessione in esecuzione con un ruolo di superutente, uno script di debug lanciato in tempo reale: ognuno di questi incidenti, per quanto banale nel funzionamento, può esporre silenziosamente le linee di tutti gli inquilini allo stesso tempo. Il confine di sicurezza e il confine tecnico (la base) sono quindi esattamente la stessa cosa.

Da un recente consolidamento del provisioner (contrassegnato nel codice come "Task 12"), un progetto Postgres attivo presso Aurabase rientra esattamente in due architetture: i vecchi modelli con una base effettivamente condivisa tra diversi progetti sono stati rimossi dal percorso di provisioning.

pub enum ProjectInstanceKind {
    /// Cluster CNPG dedicato SOLO a QUESTO progetto (a livello aziendale).
    FullyDedicated,

    /// Database sul cluster CNPG del progetto ORGANIZZAZIONE —
    /// condiviso con ALTRI progetti della STESSA organizzazione,
    /// mai con un'organizzazione di terze parti.
    SharedClusterDedicated,
}

Il livello di progetto decide quale dei due si applica ed è il codice che decide, non una casella selezionata in una dashboard:

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)
}

// dovrebbe_route_to_fleet(): qualsiasi livello non aziendale (gratuito/pro/team)
// percorso verso il cluster CNPG della TUA PROPRIA organizzazione, mai quello unico
// da un altro: vedere migrazione 073, consolidamento su 2 architetture.

Su entrambe le architetture, la base o il cluster non ospita mai due organizzazioni diverse, quindi la domanda non è "i tuoi dati sono isolati" ma "il tuo progetto ha il calcolo CloudNativePG tutto per sé o lo condivide con altri progetti nella stessa organizzazione".

Questo consolidamento di due architetture è recente: il codice in precedenza prevedeva due percorsi aggiuntivi: un “master condiviso” in cui più progetti coesistevano nello stesso database, isolati solo dal diagramma, e una variante postgrest_dedicated_shared_db. Una migrazione dedicata li ha rimossi e ha stretto il vincolo della tabella projects ai soli due valori rimanenti, proprio perché il modello a schema condiviso era all'origine del bug descritto di seguito.

Un database Postgres separato è un limite a livello di connessione, non a livello di riga. Un ruolo dell'applicazione connesso al database del progetto A semplicemente non può interrogare le tabelle del progetto B: non ha una sessione aperta. Questa proprietà vale anche se una policy RLS è scritta male, manca da una tabella o bypassata da un ruolo elevato: il caso peggiore rimane confinato all'interno di un singolo database.

Questo deposito porta anche la traccia di un vero e proprio bug che illustra il rischio opposto. Nel vecchio modello di schema condiviso (da allora ritirato), provision_postgres_schema concedeva erroneamente a GRANT ALL ... TO PUBLIC i diritti su ogni schema di progetto: PUBLIC applicando a tutti i ruoli nel database senza condizioni di appartenenza, un accesso isolato per progetto poteva leggere e scrivere nello schema di un altro. Una migrazione correttiva (066) ha rimosso questi diritti da quello esistente.

Una patch del 23 agosto 2026 va nella stessa direzione: un REVOKE ALL ON SCHEMA public inserito incondizionatamente dal provisioner è stato condizionato alla topologia, perché forniva solo un reale isolamento sul vecchio modello di database condiviso; sulle due architetture attuali, bloccava senza alcun beneficio l'importazione di dump SQL che fanno riferimento esplicitamente a public.<table>.

Niente di quanto sopra rende l’EPIRB inutile: cambia solo piano. Una volta in il database del tuo progetto, Aurabase espone esattamente la convenzione PostgREST ripresa da Supabase: tre funzioni SQL che leggono le attestazioni JWT impostate dal gateway in 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
$$;

Questi aiutanti vengono utilizzati nelle politiche effettive di Aurabase stessa, non solo documentati per le tue. Ecco la policy che protegge storage_objects, così come è inserita nel repository (riformattata su più righe per la lettura):

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)
      )
    )
  );

Nel tuo schema project_<uuid>, quello che contiene le tue tabelle applicative, Aurabase non inserisce deliberatamente alcuna policy per tuo conto: il codice lo documenta come un “modello Supabase”: la RLS delle tue tabelle rimane di tua responsabilità, con le stesse funzioni, la stessa sintassi.

Postgres offre nativamente un attributo di ruolo , BYPASSRLS, che ignora tutte le policy. Aurabase lo utilizza volontariamente su due famiglie di ruoli: aura_service_role (il ruolo server, mai esposto lato browser) e il ruolo di amministrazione specifico per ciascun progetto, utilizzato durante le operazioni DDL come ALTER SCHEMA ... OWNER TO.

create role aura_service_role nologin bypassrls;
-- Ruolo del server: mai esposto lato browser, mai membro
-- ruoli da un altro progetto.

Il ruolo che serve le tue richieste anon/authenticated — tenant_<uuid> — non ha alcun BYPASSRLS: la RLS si applica normalmente, senza eccezioni. Come bonus, i diagrammi di sistema specifici di ciascun progetto (_auth, _storage, _platform) ricevono un RLS attivato senza policy — quindi un rifiuto totale per impostazione predefinita per qualsiasi ruolo di non bypass, una difesa approfondita nel caso in cui un percorso applicativo vi acceda un giorno per errore.

Questo ruolo del server fa parte di un approccio più ampio: ruoli predefiniti, RBAC personalizzato, log di controllo, dettagliato nella pagina Sicurezza e RBAC.

Al livello SharedClusterDedicated, diversi progetti della stessa organizzazione coesistono su un unico cluster CNPG. Il database fisico separa già i progetti gli uni dagli altri, ma i ruoli PostgreSQL – loro – sono oggetti globali per il cluster, non per il database. Aurabase aggiunge quindi un livello: un login PostgreSQL separato per progetto.

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

// Attivo per impostazione predefinita (F013_PER_PROJECT_AUTHENTICATOR), disattivabile
// esplicitamente come fuga di emergenza.

Ogni progetto si connette con il proprio login, membro solo dei propri ruoli tenant_<uuid> / tenant_<uuid>_admin, mai quelli di un altro progetto nello stesso cluster. Il database già isola i dati; Questo login per progetto isola anche l'identità che si connette ad esso, in modo che un incidente su un progetto non conferisca al suo login alcuna appartenenza da ereditare a un altro.

La scelta di Aurabase non è una regola universale: è un compromesso per un caso specifico: isolare i clienti gli uni dagli altri, potenzialmente con requisiti di conformità diversi, su una piattaforma che non controllano. Se stai costruendo il tuo SaaS, ti si pone la stessa domanda, su scala diversa.

• RLS con tenant_id in una base condivisa — rilevante quando i tuoi inquilini sono numerosi, individualmente con una posta bassa e il costo di una base per inquilino sarebbe sproporzionato. Testa ogni policy con pg_prove, su ogni tabella, senza eccezioni.
• Base o diagramma dedicato — rilevante ogni volta che un inquilino ha un proprio problema di conformità (salute, risorse umane, settore pubblico), un volume che giustifica l'isolamento delle prestazioni o il costo di una perdita tra due clienti specifici sarebbe sproporzionato rispetto al costo dell'infrastruttura aggiuntiva.

Il livello di prezzo di Aurabase applica lo stesso arbitrato ai propri clienti: base condivisa dall'organizzazione per impostazione predefinita, cluster dedicato quando la sfida del progetto lo giustifica. Per i modelli RLS all'interno del tuo database (proprietà, multi-tenant per organizzazione, gerarchia dei ruoli) la guida RLS in produzione descrive in dettaglio i tre casi con test pgTAP. E se l'API generata automaticamente sul tuo diagramma ti interessa oltre REST, il confronto su pg_graphql rispetto a Hasura e PostGraphile copre l'altra metà della superficie Postgres esposta da Aurabase.