Org → N workspaces; portfólio multi-CNPJ

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

Objetivo#

Ao final desta aula você vai estruturar org/workspaces para 3 CNPJs — e explicar, com a doc na mão, por que a organização administra a estrutura sem nunca dar acesso aos dados.

Vídeo#

Identificador no manifesto: acd-240-01-org-workspaces-portfolio · duração-alvo 6 min · tela do produto: /portfolio.

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

#	Minutagem-alvo	Capítulo	Tela do produto
1	0:00–0:30	Abertura: título + selo `Preview`. A pergunta da aula: "tenho 3 CNPJs — é um workspace ou três?"	`/overview`
2	0:30–1:45	Conta → Organização → Workspace. A frase-chave: a organização NÃO concede acesso a dados. Mostrar o prefixo de dataset do workspace.	`/overview`
3	1:45–3:00	Vincular workspaces à org, atribuir `org_admin` e a auditoria do vínculo (`organization.attach` / `organization.detach`).	`/settings` → Acesso
4	3:00–4:30	Portfólio multi-CNPJ: visão administrativa da org × visão "somente com acesso" — a prova do anti-acesso cruzado. Estado da superfície.	`/portfolio`
5	4:30–6:00	Exemplo Aurora com 3 CNPJs, erros comuns e o "faça você mesmo".	`/settings` → Workspace

Conteúdo#

Três camadas — e só uma delas dá acesso a dados

A ingestia.io separa identidade, estrutura e isolamento em camadas que não se misturam:

Conta (usuário): a identidade de login (Google, e-mail/senha ou SSO, este em Preview). A mesma pessoa pode participar de vários workspaces com a mesma conta.
Organização: camada puramente estrutural que agrupa N workspaces. Serve para agências, BPOs e grupos multi-CNPJ. Ela administra quais workspaces existem e quem os administra — e nunca concede acesso aos dados de nenhum deles.
Workspace: a unidade de isolamento real. Cada workspace tem o próprio datalake (datasets {prefixo}_bronze/_silver/_gold), as próprias pessoas, o próprio plano e a própria cobrança. Acesso a dado sempre exige participação (membership) naquele workspace específico.

A pergunta "um workspace ou três?" tem resposta estrutural: se os CNPJs têm dados que não devem se misturar, planos diferentes ou cobranças separadas, são workspaces diferentes — e a organização é o guarda-chuva que os administra juntos.

O que a organização não é

Ela não é atalho para dados, não compartilha datasets entre workspaces e não substitui papel nem RLS. Quem administra a estrutura (org_admin) só habilita ações org.*.

Como isso aparece no produto

A estrutura do workspace vive em Administração → Configurações (/settings), na seção Workspace — é ali que ficam o ambiente do cliente, os dados do workspace, a nuvem própria e a exclusão da conta. As pessoas e os papéis ficam na seção Acesso; org_admin é atribuído no contexto da organização. Vincular e desvincular um workspace da org apenas associa: não move e não apaga dado — desvincular só solta o vínculo, e as duas operações entram na trilha de auditoria como organization.attach e organization.detach.

A prova prática do isolamento está na diferença entre duas listas: a visão administrativa da org lista todos os workspaces vinculados; a visão "somente com acesso" lista apenas aqueles em que a pessoa é owner ou membro ativo/convidado. É a mesma organização, duas respostas — e é isso que comprova o anti-acesso cruzado.

A superfície de portfólio (/portfolio) é o lugar previsto para a leitura consolidada (saúde, custo e conteúdo dos workspaces da org) e para a curadoria de apps e audiências sobre dashboards já publicados. Duas regras dela importam desde já: a organização não amplia o alcance de ninguém — mesmo o dono da org só enxerga no portfólio os workspaces em que tem acesso — e publicar para uma audiência é distribuição, então passa pelo gate de workspace ativo, como qualquer export.

Exemplo: o Grupo Aurora com 3 CNPJs

O Grupo Aurora (organização) reúne Aurora Varejo, Aurora Atacado e Aurora Serviços — três CNPJs, três workspaces, três datalakes. João é org_admin: cria e vincula os workspaces, define quem os administra e acompanha a estrutura — e não vê as vendas de nenhum dos três. Maria é membro só de Aurora Varejo: quando lista a organização, recebe apenas Aurora Varejo, embora a org tenha três. Para que João analise os números do Varejo não existe atalho pela organização: ele precisa ser adicionado como membro daquele workspace.

Ação	viewer	member	admin	owner	org_admin
Ver dashboards do workspace	✓	✓	✓	✓	—
`workspace.settings` (configurar o workspace)	—	—	✓	✓	—
`billing.manage` · `workspace.delete` · `role.assign`	—	—	—	✓	—
`org.workspace.manage` (criar/vincular workspace)	—	—	—	—	✓
`org.member.manage` · `org.settings`	—	—	—	—	✓

Erros comuns

Juntar 3 CNPJs num workspace só para "economizar" e depois descobrir que não há como separar cobrança, plano ou dataset — a separação é estrutural, não um filtro de tela.
Dar admin para quem só lê o painel consolidado: viewer já consome dashboards e relatórios; admin roda query, refresh e IA, ações que custam dinheiro.
Esperar que o org_admin veja dados. É comportamento esperado, não defeito; a solução é membership no workspace-alvo.
Confundir organização com RLS. Recorte por linha (só a própria filial, só a própria UF) é RLS/ABAC, configurada por atributo do membro — nada a ver com a camada de organização.

Estado do produto

O modelo Organization → N Workspaces e o portfólio multi-CNPJ são determinísticos e cobertos por testes, com verificação de organização fail-closed: contexto de organização ausente → negado; organização divergente do recurso alvo → negado. O teto público continua Preview porque o isolamento entre clientes "provado em produção" (validação de IAM em nuvem real) é a peça pendente — o desenho é fail-closed; a certificação de nuvem é que não ocorreu. E, no console de hoje, não há tela dedicada em /portfolio: as ações de leitura de portfólio e de curadoria de apps/audiências existem e são escopadas por RBAC de organização, mas a estrutura do dia a dia você administra por /settings. Criar e gerir organização e vínculos custa R$ 0 — não consome BigQuery.

Faça você mesmo#

No workspace de treino Aurora Varejo (abra /settings no console; /portfolio ainda não tem tela dedicada):

Em Administração → Configurações → Workspace, anote o nome do workspace e o prefixo de dataset (aurora → aurora_bronze/_silver/_gold). Esse prefixo é a fronteira de isolamento.
Desenhe a estrutura dos 3 CNPJs: uma organização (Grupo Aurora) e três workspaces (Aurora Varejo, Aurora Atacado, Aurora Serviços). Anote, para cada um, quem é owner.
Liste quem precisa de org_admin (administra a estrutura) e quem precisa de membership por workspace (vê dados). Ninguém deve aparecer nas duas colunas sem motivo escrito.
Em Acesso, localize o seu papel e confirme se você consegue (ou não) workspace.settings. Não altere nada.
Responda por escrito: João é org_admin do Grupo Aurora — ele vê as vendas de Aurora Varejo? Cite a frase da doc de organização e workspaces que justifica.
Explique, em uma frase, a diferença entre a visão administrativa da org e a visão "somente com acesso" — e por que ela é a prova do anti-acesso cruzado.
Anote onde você conferiria que um vínculo aconteceu: a trilha de auditoria, nos eventos organization.attach / organization.detach.

Você terminou quando tiver no papel a estrutura dos 3 CNPJs com owner definido por workspace, a separação entre org_admin e membership, e a explicação — citando a doc — de 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#

Capacidades ensinadas#

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