Organização, workspace e os 5 papéis

Selo de estado: Preview (teto atual do produto) · Curso ACD-100 — Fundamentos Ingestia · Aula 3 de 10 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai distinguir org→workspace e owner/admin/member/viewer/org_admin — e dizer, para cada pessoa da sua empresa, qual é o papel mínimo que ela precisa para fazer o que faz, sem privilégio sobrando.

Vídeo#

Identificador no manifesto: acd-100-03-conta-organizacao-workspace · duração-alvo 6 min · tela do produto: /settings.

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

Conteúdo#

Três camadas de acesso

• Conta (usuário): sua identidade de login — Google, e-mail/senha ou SSO corporativo (em Preview). Uma pessoa pode participar de vários workspaces com a mesma conta.
• Organização: camada puramente administrativa que agrupa N workspaces. Serve para agências, BPOs e grupos multi-CNPJ. A organização NÃO concede acesso a dados: quem administra a estrutura da organização (org_admin) não enxerga automaticamente os dados de nenhum workspace.
• Workspace: a unidade de isolamento real. Cada workspace tem seu próprio datalake (dataset BigQuery dedicado), suas pessoas, seu plano e sua cobrança. Acesso a dados sempre exige participação (membership) no workspace específico.

Quem cria a conta e conclui o onboarding vira dono (owner) do workspace. MFA é obrigatório para toda conta — não é opcional, e não é por membro.

Os 5 papéis

São 4 papéis de workspace, com herança acumulada, mais 1 papel de organização, ortogonal:

owner é estrutural: 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.

Fail-closed em toda borda

• Papel ausente ou inválido → member (default legado). Valor desconhecido ou tentativa de owner via configuração → viewer.
• Ação desconhecida → negada.
• org_admin só habilita ações org.* — nunca dados de workspace.
• O RBAC é checado antes da verificação de conta em dia: papel sem capacidade recebe 403 sem nem consultar a cobrança.

Papel × permissão fina

O papel diz o que a pessoa pode fazer na plataforma. As 7 permissões finas refinam o que ela pode operar sobre os dados: executar pipeline (runPipeline), executar queries (runQuery), inserir, atualizar e deletar dados, exportar (exportData) e ver dados PII (viewPII). Um membro novo entra com todas desligadas (menor privilégio) e status Convidado.

Convidar uma pessoa não emite senha: a plataforma gera um link de ativação de uso único, com validade; a pessoa define a própria senha ao aceitar. Link perdido se resolve reenviando o convite.

Como aparece no produto

Em Administração → Configurações (/settings), a seção Usuários & permissões é onde você convida pessoas (nome, e-mail, papel admin/membro/leitor e permissões finas), define atributos para RLS (ex.: filial) e ativa/desativa membros (Convidado, Ativo, Desativado). Só o owner atribui papéis.

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

Exemplo: a Comércio Aurora

• Maria é owner: faz tudo, inclusive faturar, excluir o workspace e atribuir papéis.
• João é admin: roda pipeline, gere fontes e pessoas — mas não fatura. No Grupo Aurora, João também é org_admin, para administrar a estrutura da organização. Isso não faz ele ver as vendas de Aurora Varejo; para isso ele precisa ser membro do workspace.
• Ana é member: interage com filtros, faz drill e exporta. Se Ana precisar rodar uma consulta no datalake (data.query.run) ou usar IA, o papel mínimo é admin.
• Gerentes de loja são viewer: só consomem painéis e relatórios.

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

Erros comuns

• Dar admin para quem só precisa exportar. member já exporta. Admin roda queries, refresh e IA — ações que custam dinheiro.
• Esperar que o org_admin veja dados. Comportamento esperado: a organização é estrutural. Solução: virar membro do workspace-alvo.
• Procurar "exigir MFA de um membro". A marca existe no cadastro, mas não tem efeito — o MFA já é obrigatório para todo acesso logado, e a marca não dispensa ninguém.
• Papel "sumiu" e virou viewer. Configuração inválida ou tentativa de owner: corrija para admin/member/viewer.

Faça você mesmo#

No workspace de treino Aurora Varejo:

1. Abra Administração → Configurações (/settings). Se o item não aparece no menu, anote: você não é dono nem admin deste workspace — e isso já responde ao exercício.
2. Em Usuários & permissões, localize o seu e-mail. Anote o seu papel e quais das 7 permissões finas estão marcadas.
3. Para Maria, João, Ana e um gerente de loja, escreva o papel mínimo que cada um precisa, usando a matriz papel × capacidade.
4. Identifique na matriz quem pode member.manage e quem pode role.assign. Explique a diferença em uma frase.
5. Abra o cadastro de um membro e localize os atributos para RLS (ex.: filial). Não altere nada.
6. Responda por escrito: se João for org_admin do Grupo Aurora, ele vê as vendas de Aurora Varejo? Cite a frase da doc que justifica.

Você terminou quando sabe o seu papel e suas permissões finas, atribuiu o papel mínimo às quatro pessoas do exemplo e consegue explicar, com a doc na mão, por que a organização não dá acesso a dados.

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#

• primeiros-passos/conta-organizacao-workspace
• administracao/papeis-rbac
• administracao/usuarios-grupos-permissoes

Capacidades ensinadas#

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