Multi-workspace e portfólio: quando separar

Selo de estado: Preview (teto atual do produto) · Curso ACD-260 — Arquitetura de solução · Aula 4 de 8 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai decidir entre um workspace por cliente e um workspace com RLS — e vai saber qual das duas opções nunca substitui a outra.

Vídeo#

Identificador: acd-260-04-multi-workspace-e-portfolio · Duração-alvo: 7 min · Tela: /portfolio.

Roteiro (capítulos):

1. 0:00–1:00 — Organização × workspace (/portfolio) — estrutura administrativa acima, isolamento real embaixo.
2. 1:00–2:20 — O critério que decide — controlador do dado, faturamento, auditoria, volume e time.
3. 2:20–3:40 — RLS/ABAC: o recorte dentro de um workspace (/settings) — um grant por atributo servindo 200 pessoas.
4. 3:40–5:00 — Por que RLS não separa clientes — o que fail-closed cobre e o que não cobre.
5. 5:00–6:00 — O custo de separar (/billing) — N workspaces, N planos, N franquias, nada compartilhado.
6. 6:00–7:00 — O mapa de portfólio do Grupo Aurora (/portfolio) — a decisão escrita.

Conteúdo#

Duas camadas que fazem coisas diferentes

A organização agrupa N workspaces e é puramente estrutural: ela administra quais workspaces existem e quem os administra, e nunca concede acesso aos dados de nenhum deles. O papel org_admin cria e vincula workspaces, gere membros da org e ajusta configurações — e não vê dado de workspace algum sem ser membro dele. A verificação é fail-closed: contexto de organização ausente ⇒ negado; organização divergente do recurso ⇒ negado.

O workspace é a unidade de isolamento real: datalake dedicado (<prefix>_bronze / _silver / _gold, landing própria), pessoas, plano e cobrança. O prefix deriva do workspace e é saneado; um cliente nunca cruza dataset ou bucket de outro.

Essa separação é o que sustenta o portfólio multi-CNPJ de agências, BPOs e grupos — e é também o que impede o atalho preguiçoso de usar a organização como "pasta com acesso".

O critério de decisão

A pergunta não é "quantos clientes eu tenho", é "quem responde pelo dado":

A regra que resume: controladores diferentes ⇒ workspaces diferentes, sem exceção. Se dois conjuntos de dados pertencem a duas empresas distintas, eles não compartilham dataset — e isso não é uma preferência de organização, é a fronteira que a exclusão de dados, o DSAR e a auditoria assumem.

RLS/ABAC: o recorte dentro de um workspace

Dentro de um workspace, o recorte por pessoa é segurança por linha. Há duas formas:

• RLS estática ({column, values}) — o grant fixa os valores. Simples, mas é um grant por pessoa: não escala além de poucas dezenas.
• RLS por atributo / ABAC ({column, memberAttribute}) — 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.

A regra de ouro é fail-closed: membro sem o atributo, atributo vazio ou identidade sem membro ⇒ nenhuma linha passa. Nunca "sem filtro". E RLS filtra linhas — para esconder colunas sensíveis existe a permissão fina de ver dados PII e a governança de PII (a partir do Business). No plano, RLS começa no Growth: desenhar recorte por pessoa num workspace Starter é desenhar o que o plano não entrega.

Por que RLS não separa clientes

A tentação é óbvia: um workspace, uma coluna cliente, um grant por atributo — e pronto, "isolamento". Não é. A diferença:

RLS é excelente para o que ela é: recorte dentro da mesma controladora. Ela não é um substituto para a fronteira física. E vale a honestidade que o desenho exige numa proposta: o isolamento é fail-closed por desenho e coberto por testes, mas "provado em produção" ainda é pendente — falta a validação de IAM em nuvem real. Diga isso ao cliente; não prometa certificação que não existe.

O custo de separar

Separar tem preço, e ele precisa estar na proposta:

• N workspaces = N planos = N franquias mensais. Não há plano guarda-chuva para o portfólio hoje.
• A organização não compartilha datasets. Uma dimensão comum (calendário, tabela de produtos de um grupo) precisa ser ingerida em cada workspace que a usa.
• Cada workspace tem as próprias conexões e credenciais — e o próprio ciclo de rotação.
• Criar e gerir a organização e os vínculos custa R$ 0 e é auditado (organization.attach / organization.detach); desvincular não apaga o workspace nem seus dados.

A decisão do Grupo Aurora

O Grupo Aurora é uma organização com dois CNPJs — Aurora Varejo e Aurora Atacado — e uma agência parceira que atende os dois. Desenho que se defende:

• Dois workspaces, um por CNPJ: faturamentos diferentes, contratos diferentes, auditoria separada. O Grupo Aurora é a organização que os agrupa.
• João é org_admin: cria e vincula workspaces e gere quem os administra — e não vê as vendas de nenhum dos dois. Para ver, teria de ser membro.
• Maria é membro só de Aurora Varejo: ao listar a organização na visão "somente com acesso", ela recebe apenas Aurora Varejo.
• Dentro de Aurora Varejo, os seis gerentes de filial usam um grant ABAC {column: "filial", memberAttribute: "filial"} — um painel, seis recortes, nenhuma duplicação.
• O que é recusado: juntar Varejo e Atacado num workspace só "para economizar um plano". A economia é real e a resposta ainda é não — são controladores distintos, e a fronteira de exclusão, auditoria e cobrança passa por ali. A frase: "dá para fazer, e eu não faço: no dia em que o Atacado pedir exclusão de dados, eu teria de recortar dentro do dado do Varejo."

Erros comuns de desenho

• Usar a organização como permissão. Ela é estrutural; acesso a dado exige membership.
• Separar por filial. Filial é RLS, não workspace — seis workspaces é seis vezes tudo.
• Juntar clientes e confiar na RLS. Um grant errado vira vazamento entre clientes.
• Esquecer que nada é compartilhado. A dimensão comum é ingerida N vezes.
• Desenhar RLS no Starter. RLS começa no Growth.
• Prometer isolamento "certificado em produção". Hoje é fail-closed por desenho, com a prova em nuvem pendente.

Faça você mesmo#

O produto desta aula é um artefato de decisão: um mapa de portfólio de uma página. Use /portfolio para ver a estrutura atual; o resto é escrito.

1. Liste as empresas/CNPJs do seu caso, uma por linha, com quem é o controlador do dado de cada uma.
2. Para cada linha, preencha os seis critérios da tabela (controlador, faturamento, LGPD, auditoria, time, volume) com uma palavra.
3. Decida workspace ou recorte por RLS em cada linha e escreva a justificativa em uma frase.
4. Desenhe a organização: quais workspaces ela agrupa e quem é org_admin — com o lembrete escrito de que ele não vê dados.
5. Para cada workspace, escreva o plano necessário (lembrando que RLS começa no Growth) e o que será ingerido em duplicidade por não haver compartilhamento.
6. Escreva os grants de RLS que cada workspace precisa, no formato {column, memberAttribute}, e o que acontece com quem não tem o atributo.
7. Escreva a recusa: o pedido de juntar que você devolve, com a razão e o risco que ela evita.

Você terminou quando: o mapa mostra, para cada CNPJ, um destino (workspace próprio ou recorte), o plano necessário, o custo duplicado assumido e uma frase que explica por que a RLS não está fazendo o trabalho da fronteira.

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/organizacao-e-workspaces
• administracao/seguranca-por-linha-rls
• administracao/planos
• administracao/governanca-lgpd

Capacidades ensinadas#

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