Matriz papel × capacidade (fail-closed)

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

Objetivo#

Ao final desta aula você vai atribuir papel mínimo por tarefa — lendo a matriz papel × ação em vez de chutar, e sabendo o que o sistema faz quando a configuração está errada.

Vídeo#

Identificador no manifesto: acd-240-02-rbac-5-papeis · duração-alvo 7 min · tela do produto: /settings.

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

Conteúdo#

Papel diz o que a pessoa FAZ

RBAC (controle de acesso baseado em papéis) responde a uma pergunta só: o que esta pessoa pode fazer na plataforma? São 4 papéis de workspace, com herança acumulada, mais 1 papel de organização, ortogonal:

owner é estrutural: é o dono do workspace, e um membro comum nunca vira owner por configuração. As três ações exclusivas do dono são billing.manage, workspace.delete e role.assign. O admin pode gerir pessoas (member.manage), mas não atribui papéis nem fatura.

A matriz que você vai usar

A leitura prática é de baixo para cima: antes de elevar alguém, procure a ação na matriz. Quem só precisa baixar um XLSX não precisa de admin — member já exporta. Quem precisa rodar refresh manual ou perguntar à IA precisa de admin, porque essas são as ações que gastam.

Como isso aparece no produto

Em Administração → Configurações (/settings), a seção Acesso reúne "quem participa do workspace, com qual papel, e o que cada papel consegue fazer". Além da lista de pessoas, há um resumo de acesso efetivo: você escolhe uma pessoa e o produto mostra o que aquele papel consegue — lendo a mesma matriz que o servidor usa para decidir. Não é um texto paralelo mantido à mão; é a função de verificação exposta na tela.

O próprio menu já é um sinal do seu papel: datalake, conexões, pipelines, governança, linhagem, auditoria e toda a Administração são área do dono. Quem decide é o servidor — menu, favoritos e busca só mostram o que o seu papel autoriza. Se Configurações não aparece para você, isso já é a resposta.

Exemplo: seis tarefas da Aurora, seis papéis mínimos

Na Comércio Aurora: Maria é owner (fatura, exclui o workspace, atribui papéis). João é admin (roda pipeline, gere fontes e pessoas, mas não fatura) e também org_admin no Grupo Aurora — o que não o faz ver as vendas. Ana é member: filtra, faz drill e exporta; se precisar rodar consulta no datalake (data.query.run) ou usar IA, o papel mínimo passa a ser admin. Gerentes de loja são viewer.

Agora o mapeamento tarefa → papel mínimo: "baixar o XLSX do mês" → member. "Disparar refresh manual do painel" → admin. "Convidar um analista novo" → admin (member.manage). "Promover esse analista a admin" → owner (role.assign). "Trocar o plano / pagar a fatura" → owner (billing.manage). "Criar e vincular um workspace novo na organização" → org_admin.

E se o gerente de Campinas só puder ver a própria filial? Papel não resolve isso. Restrição por linha é RLS/ABAC: RBAC define o que a pessoa faz; RLS define quais linhas ela vê.

Erros comuns

• Dar admin para quem só lê ou só exporta. É o erro mais caro do curso: admin habilita query, refresh e IA — consumo de crédito. viewer consome painel; member exporta.
• Esperar que admin fature ou promova gente. billing.manage e role.assign são só do owner; a tela não "esconde por bug".
• Tentar virar owner por configuração de permissões. O resultado é o oposto do esperado: o fail-closed rebaixa para viewer.
• Achar que o org_admin é um super-admin. Ele só habilita org.*; dados exigem membership no workspace.
• Confundir 403 de papel com 402 de cobrança. São camadas diferentes: a de papel vem primeiro e nem olha a assinatura.

Estado do produto

A matriz de RBAC é pura, determinística e coberta por testes, incluindo os casos de borda fail-closed e o escopo dos service principals. São 5 papéis fixos — papéis 100% customizados não fazem parte do produto. O teto público é Preview: a prova de isolamento entre clientes em nuvem real ainda é pendente, e a exposição da API externa (/api/v1, que usa o mesmo RBAC) está fora de GA. RBAC não consome recurso de nuvem: R$ 0.

Faça você mesmo#

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

1. Abra Administração → Configurações → Acesso. Se o item não aparece no menu, anote: você não é dono nem admin deste workspace — e isso já é parte da resposta.
2. Localize o seu e-mail na lista e anote o seu papel.
3. Use o resumo de acesso efetivo para uma pessoa member e outra admin; anote duas ações que mudam entre os dois.
4. Monte a tabela de 6 tarefas → papel mínimo: baixar XLSX · disparar refresh manual · convidar analista · promover analista a admin · trocar o plano · criar e vincular workspace na organização.
5. Para cada linha, anote a ação RBAC correspondente (ex.: exportação, refresh.trigger, member.manage, role.assign, billing.manage, org.workspace.manage).
6. Responda por escrito: qual a diferença entre member.manage e role.assign, e por que uma é de admin e a outra só do owner?
7. Explique em uma frase o que o sistema faz quando o papel configurado é um valor desconhecido — e por que isso é o comportamento desejado.

Você terminou quando tiver as 6 tarefas mapeadas para o papel mínimo com a ação RBAC ao lado, e conseguir explicar, sem olhar a doc, as duas regras de fail-closed (papel desconhecido → viewer; ação desconhecida → negada).

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#

• administracao/papeis-rbac
• administracao/usuarios-grupos-permissoes
• administracao/suspensao

Capacidades ensinadas#

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