RLS estática e ABAC por atributo (fail-closed)

Selo de estado: Preview (teto atual do produto) · Curso ACD-240 — Administração, segurança e governança · Aula 4 de 10 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai configurar RLS por filiais.uf via atributo — e provar que o recorte vale no visual, no export, no envio agendado e na IA, não só na tela.

Vídeo#

Identificador no manifesto: acd-240-04-rls-abac · duração-alvo 9 min · tela do produto: /settings.

Roteiro de gravação (6 capítulos):

#	Minutagem-alvo	Capítulo	Tela do produto
1	0:00–0:50	Abertura: RBAC diz o que a pessoa FAZ; RLS diz quais linhas ela vê. O mesmo painel, pessoas diferentes.	`/settings` → Acesso
2	0:50–2:30	RLS estática `{column, values}` × ABAC `{column, memberAttribute}`: por que um grant serve 200 pessoas e o outro não.	`/settings` → Acesso
3	2:30–4:20	Definir o atributo `uf` no perfil do membro; tetos por membro (20 atributos, chave 60, valor 200, 50 valores).	`/settings` → Acesso
4	4:20–6:10	Criar o grant no painel e publicar; a RLS entra na leitura segura — não num filtro de widget.	`/dashboards`
5	6:10–7:50	Provar nos quatro lugares: visual, export, envio agendado e pergunta de IA. Ana vê só `uf = 'SP'`.	`/dashboards`
6	7:50–9:00	Fail-closed (sem atributo = zero linhas), erros comuns e o "faça você mesmo".	`/settings` → Acesso

Conteúdo#

Duas formas, uma recomendada

Segurança por linha (RLS) existe para que duas pessoas abram o mesmo painel e vejam linhas diferentes, sem ninguém manter dois painéis. O produto oferece duas formas:

RLS estática — {column, values}: o grant fixa os valores permitidos. Simples, mas exige um grant por pessoa; não escala além de poucas dezenas.
RLS por atributo do membro, ou ABAC — {column, memberAttribute}: o grant não diz "quem vê o quê", diz de onde vem o valor permitido — e o valor mora no atributo do membro. Um grant {column: "uf", memberAttribute: "uf"} serve 200 vendedores, cada um vendo a própria UF, porque o produto resolve o valor no momento da leitura.

A recomendação é ABAC em qualquer operação com mais de um punhado de pessoas. A estática fica para exceções nomeadas.

Como isso aparece no produto

O atributo é definido em Administração → Configurações → Acesso (/settings), no perfil de cada membro: uf = "SP" para um, uf = "RJ" para outro. Não é coluna nova no seu banco — vive dentro do cadastro do membro, em atributos. Os tetos por membro existem para o perfil não virar uma lista infinita de permissões: até 20 atributos, chave de até 60 caracteres, valor de até 200, e até 50 valores por atributo (multi-valor vira cláusula IN).

O grant fica no painel, na tela de compartilhamento/segurança do dashboard: você aponta a coluna do modelo (uf, vinda de filiais.uf) e o atributo que fornece o valor (uf). Publicado, isso passa a valer em toda leitura segura do painel — e aí está o ponto da aula: a RLS vive na fonte única de leitura segura, não num filtro de widget.

A regra de ouro é fail-closed

Membro sem o atributo, com o atributo vazio, ou identidade sem membro → nenhuma linha passa (denyAll). Nunca "sem filtro". Os valores são saneados (allowlist de tipos, caixa normalizada) e os tetos aplicados — descartar só estreita o acesso, nunca amplia.

RLS atravessa quatro saídas, não só a tela

É isto que separa segurança de cosmética:

Visual / painel: cada pessoa lê a sua visão segura.
Exportação (XLSX/CSV/PDF): lê o snapshot com a RLS do solicitante; o PDF sob demanda usa um token efêmero que carrega a RLS da sessão.
Envio agendado (e-mail/WhatsApp): aplica RLS por destinatário — o filtro da assinatura soma com a RLS, nunca amplia.
IA: o Q&A e os insights leem a mesma visão segura da tela — a IA nunca vê mais do que quem perguntou vê.

Exemplo: Ana vê só `uf = 'SP'`

No modelo de "Vendas por filial" da Aurora Varejo, Maria cria um grant {column: "uf", memberAttribute: "uf"} e define, em Acesso, o atributo uf = "SP" no perfil de Ana. Resultado: Ana abre o painel e vê só SP; um colega com uf = "RJ" vê só RJ; quem tem visão completa continua vendo SP/RJ/MG. Quando Ana exporta o XLSX em modo detalhe, o arquivo traz só SP. Quando a assinatura semanal sai por e-mail para Ana, o anexo traz só SP. E se Ana perguntar à IA "qual foi o faturamento do Rio de Janeiro no mês?", a resposta não traz o número do RJ — não porque a IA se recuse, mas porque ela literalmente não tem acesso àquelas linhas. Um quarto membro, criado sem o atributo uf, vê zero linhas.

Ação	viewer	member	admin	owner	org_admin
Ler o painel sob RLS (vê só o próprio recorte)	✓	✓	✓	✓	—
Exportar sob RLS (com `exportData`)	—	✓	✓	✓	—
Definir atributo do membro (`member.manage`)	—	—	✓	✓	—
Criar/alterar o grant no painel (gestão de painéis)	—	—	✓	✓	—
`role.assign` (quem pode ser admin)	—	—	—	✓	—

Erros comuns

RLS só no visual. Alguém filtra manualmente um gráfico para "mostrar só SP" e não cria o grant. O filtro é cosmético: no primeiro export, na primeira assinatura e na primeira pergunta de IA o dado completo volta, porque nenhuma dessas saídas lê filtro de widget — só a RLS registrada.
Interpretar zero linhas como defeito. Membro novo sem atributo preenchido deve ver zero. É o fail-closed trabalhando; preencha o atributo.
Confundir RLS com viewPII. RLS filtra linhas; esconder colunas sensíveis é permissão fina e grupo de acesso — ortogonal, assunto da aula 3.
Usar RLS estática para 200 pessoas. Vira 200 grants para manter à mão; use memberAttribute.
Errar a chave do atributo. A chave é normalizada, mas um typo é um typo: confira o nome exato.

Estado do produto

A lógica de RLS/ABAC (rowFilter v3) é fail-closed e coberta por testes determinísticos, já exercitada com isolamento por organização em banco real. O teto público é Preview porque o isolamento entre clientes "provado em produção" — a prova de IAM cross-tenant em nuvem — é a peça pendente; o desenho é fail-closed, a certificação é que não ocorreu. Atenção ao plano: RLS está disponível a partir do Growth (Starter não inclui), e governança de PII/policy tags a partir do Business. Configurar e aplicar RLS custa R$ 0 — é filtro na leitura, sem custo além da própria consulta.

Faça você mesmo#

No workspace de treino Aurora Varejo (abra /settings no console):

Em Acesso, abra o perfil de ana@example.com e defina o atributo uf = "SP". Em outro membro de teste, defina uf = "RJ".
Crie um terceiro membro de teste sem nenhum atributo uf. Ele é o seu controle de fail-closed.
No painel "Vendas por filial" (ou equivalente com a coluna uf vinda de filiais.uf), crie o grant {column: "uf", memberAttribute: "uf"} e publique.
Entre como Ana e confirme que o painel traz só SP. Entre como o membro uf = "RJ" e confirme que traz só RJ.
Como Ana, exporte o XLSX em modo detalhe e confirme que o arquivo também traz só SP.
Como Ana, pergunte à IA (se habilitada no seu treino) pelo faturamento do RJ e confirme que a resposta não revela o número do RJ.
Entre como o membro sem atributo e confirme que ele vê zero linhas — não "tudo".
Anote onde você veria o registro dessas leituras e dessa configuração: a trilha de auditoria.

Você terminou quando tiver provado, com as próprias telas, que Ana só vê uf = 'SP' em três saídas diferentes (painel, export e IA) e que o membro sem atributo vê zero linhas.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

Capacidades ensinadas#

C11.3 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".