Isolamento SaaS multi-tenant con Postgres RLS e autenticazione workspace

I controlli applicativi e le policy del database risolvono guasti diversi

Spesso gli sviluppatori trattano l'autorizzazione a livello applicativo e la Row-Level Security di Postgres come alternative che si escludono a vicenda. Nella pratica intercettano bug diversi: i controlli lato server applicano la gerarchia dei ruoli, le verifiche dei diritti e i log di audit prima dell'esecuzione della logica di business, mentre RLS garantisce che una clausola WHERE workspace_id = ... dimenticata non possa mai esporre le righe di tutti i tenant.

Che tu usi Supabase o Postgres self-hosted con Drizzle, ogni tabella di proprietà di un tenant dovrebbe avere una chiave esterna non nulla workspace_id. L'articolo sui confini del workspace spiega perché tale ambito deve sempre essere derivato sul server.

• I controlli applicativi convalidano la freschezza della sessione, i ruoli dei membri (owner, admin, member) e i diritti sulle funzionalità.
• Le policy RLS del database fungono da barriera invalicabile quando vengono utilizzate query dirette dal client o helper SQL grezzi.
• Entrambi i livelli dipendono da un'unica fonte di verità: la tabella di join workspace_members.

Verifica l'appartenenza in tempo reale invece di fidarti di cookie obsoleti

Memorizzare un currentWorkspaceId in un cookie del browser o in un header del client è comodo per la navigazione, ma un cookie è una preferenza, non un permesso. Se un amministratore rimuove un collaboratore da un workspace, il browser di quell'utente conserva ancora il vecchio cookie.

Unire la sessione attiva con workspace_members a ogni richiesta risolve il problema. Quando la riga di appartenenza non esiste più, rifiuta immediatamente la richiesta invece di attendere la scadenza di un JWT o di un cookie di sessione. L'articolo sull'autenticazione oltre il modulo di login mostra come l'identità confluisce in questo controllo.

export async function requireWorkspaceViewer(requestedWorkspaceId?: string) {
  const session = await requireAuthenticatedSession();
  const membership = await db.query.workspaceMembers.findFirst({
    where: and(
      eq(workspaceMembers.userId, session.user.id),
      requestedWorkspaceId
        ? eq(workspaceMembers.workspaceId, requestedWorkspaceId)
        : undefined,
    ),
    with: { workspace: true },
  });

  if (!membership) throw new ForbiddenError("Not a member of this workspace");
  return { user: session.user, workspace: membership.workspace, role: membership.role };
}

Scrivi policy di Row-Level Security veloci e indicizzate

Le policy RLS ingenue che chiamano auth.uid() direttamente su ogni riga costringono Postgres a rivalutare la funzione per ogni tupla. Racchiudere (select auth.uid()) in una subquery scalare consente al query planner di memorizzare il valore nella cache come initPlan, e un indice composto su (workspace_id, user_id) mantiene le ricerche di appartenenza sotto il millisecondo.

Puoi generare policy SELECT, INSERT, UPDATE e DELETE pronte per l'esecuzione per tabelle multi-tenant usando il generatore gratuito di policy RLS per Supabase senza scrivere SQL ripetitivo a mano.

CREATE INDEX IF NOT EXISTS idx_workspace_members_lookup
  ON workspace_members (workspace_id, user_id);

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

CREATE POLICY "workspace_members_manage_documents"
ON documents FOR ALL TO authenticated
USING (
  workspace_id IN (
    SELECT wm.workspace_id FROM workspace_members wm
    WHERE wm.user_id = (SELECT auth.uid())
  )
)
WITH CHECK (
  workspace_id IN (
    SELECT wm.workspace_id FROM workspace_members wm
    WHERE wm.user_id = (SELECT auth.uid())
      AND wm.role IN ('owner', 'admin', 'member')
  )
);

• Supabase RLS Policy Generator (Free Tool)supastack.dev

Domande frequenti su RLS e autenticazione workspace

I team che configurano Postgres multi-tenant incontrano gli stessi casi limite legati a ruoli di servizio, job in background e prestazioni.

• Drizzle ORM o Prisma aggirano RLS? — Sì, se il tuo server si connette con il superuser postgres o con la chiave service_role di Supabase. Ecco perché le server action e le route API devono chiamare requireWorkspaceViewer() e filtrare ogni query per workspaceId.
• Perché racchiudere (select auth.uid()) tra parentesi nelle policy RLS? — Indica all'ottimizzatore di Postgres di valutare auth.uid() una sola volta per istruzione invece che una volta per riga scansionata, evitando rallentamenti da sequential scan su tabelle grandi.
• Come devono accedere i job in background ai dati del tenant? — Passa il workspaceId verificato nel payload del job dalla route server autenticata e limita letture e scritture del worker a quel workspaceId.
• Come verifico che l'isolamento dei tenant regga davvero? — Scrivi test negativi automatizzati in cui l'Utente A richiede o modifica l'ID di un record dell'Utente B attraverso route web, mobile e API, e verifica che restituiscano 403 / 404 con zero righe modificate.