Segurança por linha (RLS / ABAC)

Selo de estado: GA-candidato (lógica testada) · isolamento entre clientes "provado em produção" = pendente (claim #13) · Atualizado em 2026-09-06. Fonte de estado: matriz de estados do produto (ABAC/RLS por atributos, rowFilter v3). Limite atual do produto = Preview.

A segurança por linha (RLS) faz duas pessoas abrirem o mesmo dashboard e verem linhas diferentes. A ingestia.io oferece duas formas: RLS estática e RLS por atributo do membro (ABAC).

Conceitos#

• 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 / ABAC ({column, memberAttribute}, rowFilter v3): o grant diz de onde vem o valor permitido, e o valor mora no atributo do membro. Um grant {column: "filial", memberAttribute: "filial"} serve 200 vendedores, cada um vendo a sua filial.

Disponibilidade#

• Planos: Segurança por linha (RLS) a partir do Growth (Starter não inclui RLS). Governança de PII/policy tags a partir do Business.
• Estado: GA-candidato na lógica (fail-closed, coberto por testes); a prova de isolamento entre clientes em nuvem (IAM real) ainda é pendente (claim #13).

Permissões#

• Configurar RLS e atributos de membro exige papel admin/owner (ações member.manage / gestão de painéis).
• A permissão fina Ver dados PII (viewPII) controla exibição de colunas sensíveis — ortogonal à RLS de linhas.

Configuração (passo a passo)#

1. Defina os atributos do membro (ex.: filial = "Campinas") no perfil, em Usuários & permissões. Os atributos vivem dentro do permissionsJson do membro, em atributos — sem coluna nova no banco.
2. Crie o grant de RLS no dashboard/modelo:
   • estática: {column: "filial", values: ["Campinas"]}; ou
   • por atributo: {column: "filial", memberAttribute: "filial"}.
3. Publique. A aplicação da RLS acontece na leitura segura do dashboard e no envio de relatórios.

Tetos por membro: até 20 atributos, chave até 60 caracteres, valor até 200 caracteres, até 50 valores por atributo (multi-valor vira cláusula IN).

Validação (regra de ouro: FAIL-CLOSED)#

• Membro sem o atributo, atributo vazio, ou identidade sem membro → nenhuma linha passa (denyAll). Nunca "sem filtro".
• Multi-valor (ex.: regiao = ["Sul", "Sudeste"]) vira IN com o mesmo teto do rowFilter.
• Confirme abrindo o dashboard como cada perfil: cada um vê só o seu recorte.

Exemplo#

Na Comércio Aurora, o dashboard "Vendas por filial" tem um grant por atributo {column: "filial", memberAttribute: "filial"}:

• o gerente de Campinas (filial = "Campinas") vê só Campinas;
• a gerente de Sorocaba (filial = "Sorocaba") vê só Sorocaba;
• um analista sem o atributo filial vê zero linhas (fail-closed).

A mesma regra vale no envio de relatórios (assinatura filtra por destinatário).

Custo#

• Configurar/aplicar RLS: R$ 0 (é filtro na leitura; sem custo extra além da própria consulta).

Segurança#

• Fail-closed em todos os buracos (ausente/anônimo/externo → denyAll).
• Valores são saneados (allowlist de tipos; caixa normalizada) e os tetos aplicados — descartar só estreita o acesso, nunca amplia.
• RLS é aplicada na fonte única de leitura segura do dashboard e respeitada pela IA.

Limites#

• RLS estática não escala (um grant por pessoa) — prefira ABAC para muitos usuários.
• Isolamento entre clientes "provado em produção" é pendente (validação IAM em nuvem, claim #13). O desenho é fail-closed; a certificação de nuvem não ocorreu hoje.
• RLS filtra linhas; para esconder colunas sensíveis, use viewPII e a governança de PII.

Troubleshooting#

Próximos passos: Planos e Consumo e quotas.

Estado & evidência: ABAC/RLS por atributos = GA-candidato na lógica; isolamento em produção = pendente (claim #13). Fonte: matriz de estados do produto.