O que é Segurança em Nível de Linha (RLS)?

Segurança em nível de linha é um mecanismo de banco de dados que filtra quais linhas cada usuário pode ver ou alterar, aplicado por políticas em toda consulta. O modelo mental é uma cláusula WHERE invisível e obrigatória: a condição que você teria de lembrar em toda consulta vira uma propriedade da própria tabela — aplicada pelo engine, em todo caminho de acesso, incluindo os que o código da sua aplicação nunca vê.

Principais pontos

RLS em dez linhas de SQL

CREATE TABLE invoices (
  tenant_id uuid NOT NULL,
  total     numeric(10,2)
);

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;   -- daqui em diante: negar por padrão

CREATE POLICY tenant_isolation ON invoices
  USING      (tenant_id = current_setting('app.tenant')::uuid)   -- o que você pode ler
  WITH CHECK (tenant_id = current_setting('app.tenant')::uuid);  -- o que você pode escrever

-- Toda consulta agora se comporta como se terminasse com WHERE tenant_id = <o seu>.
-- Uma consulta que esquece o filtro retorna nada — não tudo.

A mesma garantia existe em bancos de documentos como controle de acesso na própria linha — cada objeto carrega sua ACL, e a plataforma a aplica em toda requisição:

// JavaScript / Node.js — Back4app JS SDK
// Row-level security as data: this row is readable by its owner, period
const note = new Parse.Object('Note');
note.set('text', 'Q3 salary planning');
note.setACL(new Parse.ACL(Parse.User.current())); // owner-only, on the row itself
await note.save();

// Later, any query by any user — the row exists only for its owner
const notes = await new Parse.Query('Note').find(); // others never see it

// Flutter / Dart — Back4app Flutter SDK
// Row-level security as data: this row is readable by its owner, period
final user = await ParseUser.currentUser() as ParseUser;
final acl = ParseACL(owner: user); // owner-only, on the row itself

final note = ParseObject('Note')
  ..set('text', 'Q3 salary planning')
  ..setACL(acl);
await note.save(); // other users' queries never return this row

// iOS / Swift — Back4app Swift SDK
// Row-level security as data: this row is readable by its owner, period
var note = Note()
note.text = "Q3 salary planning"
note.ACL = try ParseACL.defaultACL() // owner-only, on the row itself
note.save { result in
  if case .success = result {
    print("saved — other users' queries never return this row")
  }
}

// Android / Kotlin — Back4app Android SDK
// Row-level security as data: this row is readable by its owner, period
val note = ParseObject("Note").apply {
  put("text", "Q3 salary planning")
  acl = ParseACL(ParseUser.getCurrentUser()) // owner-only, on the row itself
}
note.saveInBackground { e ->
  if (e == null) Log.d("Notes", "saved — invisible to every other user")
}

O que o engine faz com uma consulta

USING vs. WITH CHECK, permissivas vs. restritivas

Duas regras de composição que valem memorizar da referência do PostgreSQL: omitir WITH CHECK reaproveita o USING para escritas, e pelo menos uma política permissiva precisa passar antes de as restritivas serem sequer consultadas — só restritivas significa que ninguém entra.

Onde o RLS é suportado

A última linha é a que interessa a este glossário: em bancos de documentos a fronteira em nível de linha tipicamente é dado na própria linha (ACLs) em vez de um predicado no engine — mesma garantia, mecanismo diferente, detalhado no artigo de engenharia do Back4app.

As pegadinhas, finalmente em um só lugar

• Surpresas do negar por padrão. Habilitar o RLS sem nenhuma política bloqueia todo mundo, exceto o dono — metade das histórias de “o RLS derrubou a produção” é isso.
• A matriz de bypass. Superusuários, roles com BYPASSRLS e donos de tabela pulam as políticas — defina FORCE ROW LEVEL SECURITY se o dono também é o usuário da aplicação, e audite quem tem o quê.
• Views avaliam como o dono delas por padrão — uma view sobre uma tabela com RLS pode contorná-lo silenciosamente, a menos que criada com direitos do invocador (security_invoker no PostgreSQL).
• Constraints vazam existência. Uma violação de unicidade ou de chave estrangeira pode revelar que uma linha invisível existe — o canal encoberto documentado; trate unicidade sobre valores protegidos de acordo.
• Erros podem vazar valores. Expressões forjadas que falham em dados específicos (uma divisão por zero quando um valor oculto casa) exfiltram por mensagens de erro — a classe de side-channel que a documentação do SQL Server descreve.
• Dumps e pools têm modos. Ferramentas de backup podem precisar do row security desligado para exportar tudo; poolers em modo transação precisam de contexto com escopo de transação (SET LOCAL), ou tenants sangram entre requisições.

Performance: políticas são código no hot path

Três regras cobrem a maior parte da experiência de campo: indexe toda coluna que uma política referencia (o predicado roda antes dos filtros da sua própria consulta — sem índice, é um scan); mantenha os predicados livres de joins, empurrando lookups para funções ou verificações de role; e faça funções por requisição serem avaliadas uma vez por consulta, não uma vez por linha, envolvendo-as em uma subquery escalar. Bem medido, o RLS custa um dígito percentual; mal medido, é a lentidão misteriosa em toda tabela que você protegeu.

Casos de uso comuns

• SaaS multi-tenant. O caso canônico — isolamento de tenant aplicado abaixo da aplicação, onde um filtro esquecido não consegue virar violação.
• Dados por usuário. Mensagens, documentos, prontuários: usuários veem as próprias linhas, ponto final.
• Fronteiras departamentais e regionais. Vendas vê a sua região; auditores veem tudo, somente leitura — camadas de política em ação.
• Regimes de compliance. Controle de acesso demonstrável na camada de dados, que é onde os auditores gostam.
• Acesso analítico compartilhado. Analistas consultam réplicas de produção diretamente, vendo apenas o que a role permite — seguro porque o banco aplica, não o dashboard.

Você deveria aplicar em nível de linha? Matriz de decisão

A síntese honesta das duas colunas: mantenha o escopo na aplicação pela legibilidade — e aplique no banco mesmo assim. Defesa em profundidade é o ponto inteiro.

Limitações e trade-offs

• Políticas são invisíveis por design — o que torna depurar o “cadê minhas linhas?” uma habilidade genuína; logue o contexto de sessão primeiro.
• Autorização complexa ultrapassa predicados. Regras que precisam de estado de workflow ou de lógica entre entidades pertencem às camadas de autorização da aplicação, com o RLS como retaguarda.
• A superfície operacional é real. A matriz de bypass, os modos de dump e o contexto de pooling são conhecimento operacional contínuo, não configuração única.
• Avaliação por linha é um imposto — pequeno quando bem projetado, ilimitado quando não.
• Protege linhas, não colunas. Esconder campos é segurança em nível de coluna; combine as duas para efeito em nível de célula.

Segurança em nível de linha no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Seu modelo em nível de linha é o mecanismo de ACL-como-dado das abas acima: todo objeto carrega sua lista de acesso, papéis expressam tenants e times, e a plataforma aplica os dois em toda requisição — SDKs, REST, GraphQL e o dashboard incluídos, com as permissões em nível de classe como a camada restritiva por cima. É a garantia da cláusula WHERE obrigatória, entregue em um banco de documentos, com a lista de pegadinhas acima absorvida pela plataforma em vez de atribuída a você.