Selo de estado:
GA-candidato· Atualizado em 2026-09-06. Fonte de estado: matriz de estados do produto (RBAC organizacional/workspace, fail-closed). Limite atual do produto = Preview.
O controle de acesso baseado em papéis (RBAC) define o que cada pessoa pode fazer. São 4 papéis de workspace (com herança acumulada) mais 1 papel de organização, ortogonal.
Os 5 papéis#
Workspace (herança acumulada owner ⊇ admin ⊇ member ⊇ viewer):
| Papel | Perfil | Resumo |
|---|---|---|
viewer | Consome | vê dashboards e relatórios |
member | Analista básico | tudo do viewer + interage (filtros/drill) e exporta |
admin | Operador | tudo do member + roda queries/refresh/IA, gere conteúdo, fontes, pessoas e chaves |
owner | Dono | tudo do admin + faturamento, exclusão do workspace e atribuição de papéis |
Organização (dimensão separada):
| Papel | Perfil | Resumo |
|---|---|---|
org_admin | Administra a estrutura | gere workspaces/membros/config da org — sem acesso a dados |
owneré estrutural (o dono do workspace). Um membro comum nunca viraownerpor configuração — a borda é fail-closed.
Matriz papel × capacidade#
| Ação (RBAC) | viewer | member | admin | owner | org_admin |
|---|---|---|---|---|---|
| visualização de painéis / consulta de relatórios | ✓ | ✓ | ✓ | ✓ | — |
| interação com os dados (filtros/drill) | — | ✓ | ✓ | ✓ | — |
| exportação de dados | — | ✓ | ✓ | ✓ | — |
data.query.run | — | — | ✓ | ✓ | — |
refresh.trigger | — | — | ✓ | ✓ | — |
| recursos de IA | — | — | ✓ | ✓ | — |
| gestão de painéis / gestão de relatórios | — | — | ✓ | ✓ | — |
source.manage | — | — | ✓ | ✓ | — |
member.manage | — | — | ✓ | ✓ | — |
apikey.manage | — | — | ✓ | ✓ | — |
workspace.settings | — | — | ✓ | ✓ | — |
billing.manage | — | — | — | ✓ | — |
workspace.delete | — | — | — | ✓ | — |
role.assign | — | — | — | ✓ | — |
org.workspace.manage | — | — | — | — | ✓ |
org.member.manage | — | — | — | — | ✓ |
org.settings | — | — | — | — | ✓ |
Disponibilidade#
- Planos: todos. RBAC é núcleo de segurança.
- Estado:
GA-candidato(matriz pura, determinística, coberta por testes).
Permissões#
- Só o owner pode atribuir papéis (
role.assign). - admin pode gerir pessoas (
member.manage), mas não faturamento nem exclusão do workspace.
Configuração#
- Papel do membro vem de
permissionsJson.role(admin/member/viewer). - Papel ausente/inválido →
member(default legado); valor desconhecido ou tentativa deownervia JSON →viewer(fail-closed). - Papel
org_adminé atribuído no contexto da organização.
Validação (fail-closed)#
- Papel desconhecido/garbage → tratado como
viewer(menor privilégio). - Ação desconhecida → negada (não pertence a nenhum conjunto).
org_adminsó habilita açõesorg.*— nunca dados de workspace.
Exemplo#
Na Comércio Aurora: Maria é owner (faz tudo, inclusive faturar). João é
admin (roda pipeline, gere fontes e pessoas, mas não fatura). Ana é member
(interage e exporta). Gerentes são viewer. No Grupo Aurora, João também é
org_admin para administrar a estrutura da organização — sem por isso ver os dados
de vendas.
Custo#
- RBAC não consome recursos de nuvem: R$ 0.
Segurança#
- Fail-closed em toda borda; menor privilégio como default.
- RBAC é uma checagem antes da verificação de conta em dia: papel sem capacidade → 403 sem nem consultar a central de cobrança.
org_adminisolado de dados (a org é estrutural).
Limites#
- 5 papéis fixos (4 de workspace + 1 de org). Papéis 100% custom não fazem parte atuais.
- Para restrição por linha (ex.: só a própria filial), RBAC não basta — use RLS/ABAC.
Troubleshooting#
| Sintoma | Causa provável | O que fazer |
|---|---|---|
| Membro não fatura | só owner tem billing.manage | ação exclusiva do dono |
| "Ação não permitida para o papel" | papel abaixo do exigido | eleve o papel (owner atribui) |
org_admin sem ver dados | comportamento esperado | vire membro do workspace-alvo |
| Papel "sumiu" para viewer | JSON inválido / tentativa de owner | corrija o papel para admin/member/viewer |
Próximos passos: Segurança por linha (RLS).
Estado & evidência: RBAC fail-closed = GA-candidato. Fonte:
matriz de estados do produto.