RLS/ABAC no painel; atravessa export, envio e IA

Selo de estado: Preview (teto atual do produto) · Curso ACD-340 — Publicação, distribuição, RLS e BI-as-code · Aula 3 de 8 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai provar que viewer SP não vê RJ no export nem no Q&A.

Vídeo#

Identificador no manifesto: acd-340-03-rls-no-dashboard · duração-alvo 9 min · tela do produto: /dashboards.

Roteiro (capítulos):

1. 00:00–01:00 — O problema: mesmo painel, pessoas diferentes, linhas diferentes.
2. 01:00–02:30 — RLS estática × ABAC: por que {column, memberAttribute} escala e {column, values} não.
3. 02:30–04:00 — Atributo do membro em Usuários & permissões; o grant no painel (/dashboards/[id]/compartilhar).
4. 04:00–06:00 — Provando com dois perfis: SP vê SP, RJ vê RJ, e o teste do fail-closed.
5. 06:00–08:00 — RLS atravessando export (XLSX) e a pergunta de IA sobre o RJ que não aparece.
6. 08:00–09:00 — Erros comuns e encerramento.

Conteúdo#

Segurança por linha (RLS) resolve um problema específico: duas pessoas abrem o mesmo dashboard e precisam ver linhas diferentes, sem que ninguém precise manter dois painéis. O ingestia.bi oferece duas formas. A RLS estática ({column, values}) fixa valores permitidos direto no grant — simples, mas exige um grant por pessoa, o que não escala além de poucas dezenas de usuários. A RLS por atributo do membro, ou ABAC ({column, memberAttribute}), é a recomendada: o grant não diz "quem vê o quê", diz de onde vem o valor — e o valor mora no perfil de cada pessoa. Um único grant {column: "uf", memberAttribute: "uf"} serve 200 vendedores, cada um vendo só a própria UF, porque o produto resolve o valor no momento da leitura.

Como aparece no produto. O atributo entra em Usuários & permissões, no perfil de cada membro (por exemplo, uf = "SP") — não é uma coluna nova no seu banco, vive dentro do cadastro do membro. O grant em si fica na tela de segurança do painel, dentro de Compartilhar (/dashboards/[id]/compartilhar): você aponta a coluna do modelo (uf) e o atributo que fornece o valor (uf). A partir da publicação, essa regra passa a valer em toda leitura segura do painel — não só num visual isolado, mas no painel inteiro, no export e no envio de relatórios.

Exemplo Aurora. No modelo de "Vendas por filial" da Aurora Varejo, maria cria o grant {column: "uf", memberAttribute: "uf"}. O atributo uf = "SP" fica no perfil de um vendedor de São Paulo; o de outro vendedor traz uf = "RJ". Quando o vendedor de SP abre o painel, ele vê só as linhas de SP — nunca as de RJ, mesmo que o painel mostre, para quem tem visão completa, as três UFs (SP/RJ/MG) usadas nos exemplos de exportação. Se esse mesmo vendedor exporta o XLSX em modo detalhe, o arquivo que ele baixa também traz só SP — o export lê o snapshot com a RLS do solicitante, então a visão segura é a mesma em qualquer saída. E se ele perguntar à IA "qual foi o faturamento do Rio de Janeiro no mês?", a resposta não traz o número do RJ: o Q&A lê a mesma visão segura da tela, então a IA literalmente não tem acesso às linhas do RJ para responder — ela nunca vê mais do que quem perguntou vê.

A regra de ouro é fail-closed. Um membro sem o atributo uf, com o atributo vazio, ou acessando sem sessão nenhuma, não vê "tudo" por padrão de segurança — vê zero linhas. É intencional: o design presume que a ausência de uma regra de acesso é motivo para negar, nunca para liberar. Multi-valor funciona do mesmo jeito (um atributo regiao = ["Sul", "Sudeste"] vira uma cláusula IN com o mesmo teto do filtro), e há tetos por membro — até 20 atributos, chave de até 60 caracteres, valor de até 200, até 50 valores por atributo — pensados para não transformar o perfil numa lista infinita de permissões.

Erros comuns. O mais perigoso é configurar RLS só no visual: alguém filtra manualmente um gráfico para mostrar "só SP" na tela, mas não cria o grant de verdade no painel — o filtro visual é cosmético, e no primeiro export, na primeira assinatura por e-mail ou na primeira pergunta de IA, o dado completo volta a aparecer, porque nenhuma dessas saídas lê um filtro de widget, só a RLS registrada no painel. O segundo erro é o oposto do fail-closed: alguém cria um membro novo, esquece de preencher o atributo uf, e entra em pânico achando que o painel "quebrou" quando na verdade o sistema está fazendo exatamente o que deveria — negando tudo até o atributo existir. O terceiro é confundir RLS com a permissão viewPII: RLS filtra linhas; esconder colunas sensíveis (CPF, e-mail) é outra configuração, ortogonal a esta.

Estado do produto. A lógica de RLS/ABAC (rowFilter v3) é GA-candidato — fail-closed, coberta por testes determinísticos, e já comprovada com dados reais num banco de produção isolado por organização. O que falta é o isolamento entre clientes certificado em nuvem real (prova de IAM cross-tenant em produção) — por isso a maturidade pública ainda é Preview, sem SLA. O desenho é fail-closed; a certificação formal é a peça pendente, não a lógica.

Faça você mesmo#

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

1. Em Usuários & permissões, defina o atributo uf = "SP" num membro de teste e uf = "RJ" em outro.
2. No painel "Vendas por filial" (ou equivalente, com uma coluna uf), crie o grant {column: "uf", memberAttribute: "uf"} em Compartilhar.
3. Publique e entre como o membro uf = "SP" — confirme que só aparecem linhas de SP.
4. Entre como o membro uf = "RJ" — confirme que só aparecem linhas de RJ.
5. Como o membro uf = "SP", exporte o XLSX em modo detalhe e confirme que o arquivo também só traz SP.
6. Como o mesmo membro, pergunte à IA (se habilitada no seu treino) pelo faturamento do RJ e confirme que a resposta não revela o número do RJ.
7. Crie um terceiro membro sem o atributo uf e confirme que ele vê zero linhas — não "tudo".

Você terminou quando tiver provado, com as próprias telas, que o vendedor de SP nunca vê RJ em três lugares diferentes: no painel, no export e na pergunta de IA.

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#

• bi/tutorial-configurar-rls
• administracao/seguranca-por-linha-rls

Capacidades ensinadas#

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