Usuários, grupos e permissões

Selo de estado: GA-candidato · Atualizado em 2026-09-17. Fonte de estado: matriz de estados do produto (RBAC + grupos + service principals). Limite atual do produto atual do produto = Preview.

Aqui você convida pessoas, define o que cada uma pode operar sobre os dados e gerencia acessos não-humanos (service principals / chaves de API).

Conceitos#

• Usuário (Member): pessoa com acesso ao workspace. Tem um papel (RBAC) e um conjunto de permissões finas.
• Grupos / service principals: identidades para automação (integrações, API). Um service principal é uma identidade não-humana com escopos definidos.
• Papel vs. permissão fina: o papel (RBAC) diz o que a pessoa pode fazer na plataforma; as permissões finas refinam o que pode operar sobre os dados.

As 7 permissões finas do membro#

Por padrão, um membro novo entra com todas as permissões desligadas (menor privilégio) e status Convidado.

Disponibilidade#

• Planos: todos. O número de criadores e visualizadores é limitado pelo plano (ver Planos).
• Estado: GA-candidato (RBAC e service principals fail-closed provados por testes).

Permissões (para administrar pessoas)#

• Gerir membros exige papel admin/owner (ação RBAC member.manage).
• Gerir chaves de API/service principals exige admin/owner (apikey.manage).
• Atribuir papéis é exclusivo do owner (role.assign).

Configuração (passo a passo)#

1. Vá em Configurações → Usuários & permissões.
2. Convidar pessoa: informe nome e e-mail, escolha o papel (admin/membro/leitor) e marque as permissões finas. A plataforma emite um link de ativação — copie-o da tela ou deixe que ele seja enviado por e-mail, quando a entrega estiver configurada no ambiente.
3. Atributos para RLS (opcional): defina atributos como filial para segurança por linha — ver RLS.
4. Ativar/desativar: um membro pode estar Convidado, Ativo ou Desativado.

Não existe senha provisória. A plataforma nunca envia senha por e-mail e nunca mostra senha na tela. Quem foi convidado define a própria senha ao abrir o link — ou, se já tem conta no ingestia.io, entra com a identidade que já usa. A senha de quem já existe não é alterada pelo convite.

Como funciona o convite (o que a pessoa convidada vê)#

O link de ativação vale 24 horas e serve uma única vez. Ao abri-lo:

O workspace e o papel vêm do convite, resolvidos no servidor. Nada disso é escolhido no formulário do navegador.

Quando o link não vale mais, a tela diz o motivo e o que fazer — e nunca revela de qual workspace era o convite nem se aquele e-mail existe:

Reenviar, cancelar e remover#

• Reenviar convite emite um link novo e invalida o anterior na hora.
• Cancelar convite derruba o link pendente sem remover a pessoa da lista.
• Desativar ou remover o membro também derruba o convite pendente. O acesso ao workspace deixa de ser resolvido já na sessão aberta — a checagem é feita a cada requisição, contra o banco.

Selo "Convite a reemitir"

Uma pessoa convidada antes da correção do ciclo de convite recebeu uma senha provisória que não autenticava em lugar nenhum. Essas linhas aparecem na lista com o selo Convite a reemitir. O conserto é um clique: Reenviar convite emite um link que funciona.

Validação#

• O novo membro aparece na lista como Convidado, com o papel e o resumo das permissões, e com Convite pendente, válido até ….
• O link de ativação é exibido para o administrador copiar — e some assim que é usado.
• Depois do aceite, o status vira Ativo e a pessoa entra no workspace com o papel concedido.
• Tentativas de ação sem permissão são negadas (fail-closed) e podem ser auditadas.

Exemplo#

Na Comércio Aurora, Maria (owner) convida:

• joao@example.com como admin (gere fontes, dashboards e pessoas);
• ana@example.com como member com runQuery e exportData ligados, mas viewPII desligado (Ana analisa vendas sem ver dados sensíveis);
• gerentes de loja como viewer (só visualizam dashboards).

Custo#

• Gerir usuários e permissões: R$ 0.
• Licenças adicionais têm custo comercial (criador adicional; pacotes de visualizadores) — ver Planos.

Segurança#

• Menor privilégio por padrão (tudo desligado no cadastro).
• Nenhuma senha é criada, exibida ou enviada pelo convite. O link de ativação é guardado só como resumo criptográfico (o valor existe dentro do link, uma vez), expira em 24 horas, vale uma única vez e é invalidado por reenvio, cancelamento, desativação ou remoção do membro.
• Aceitar um convite nunca sobrescreve a senha de uma conta que já existe.
• MFA disponível por membro, e exigido no aceite de quem já usa MFA.
• Chaves de API expõem apenas campos seguros (nunca o hash/valor cru) na UI.
• Permissão Ver PII (viewPII) separa quem enxerga dados sensíveis.

Limites#

• owner é estrutural (dono do workspace) — nunca é concedido a um membro via JSON de permissões (fail-closed rebaixa para viewer se alguém tentar).
• Homologação de provisionamento automático via IdP (SCIM) é Preview.

Troubleshooting#

Próximos passos: Papéis (RBAC) e Segurança por linha (RLS).

Estado & evidência: RBAC org/workspace + service principals = GA-candidato. Fonte: matriz de estados do produto.