Roles & permissions: definir o acesso necessário

Separe papéis de permissões, configure o escopo correto e valide ações permitidas e negadas com uma identidade de laboratório.

Entender o modelo de acesso

Roles & permissions separa papéis atribuíveis do catálogo de permissões. Uma permissão descreve uma operação autorizada; um papel reúne permissões para uma responsabilidade. Escopo, tenant e papel ativo limitam onde essa responsabilidade se aplica. Uma associação secundária com mais poderes não significa que esse seja o contexto ativo da sessão.

Liste as tarefas antes de criar um papel. Por exemplo, consultar usuários e auditoria não exige administrar infraestrutura. A exibição de um botão não comprova autorização, e abrir a tela não permite editar todos os papéis ou atribuí-los a qualquer identidade.

Consultar papéis e o catálogo

Abra Roles & permissions → Roles.
Pesquise, filtre e abra View details no papel. Revise chave, rótulo, escopo, descrição e atribuições.
Selecione Permissions e consulte a capacidade necessária. Diferencie leitura e gerenciamento.
Use Columns e Export CSV quando disponíveis e necessários à revisão autorizada.
Confira a atribuição em Users; uma permissão listada no catálogo não está automaticamente concedida à conta atual.

Campos do papel

Campo	Como preencher
Key	Chave estável para a responsabilidade. O formulário valida formato e comprimento; não é uma senha.
Label	Nome legível, como Operador de laboratório.
Scope / Tenant	Selecione o escopo oferecido e o workspace autorizado antes de atribuir capacidades.
Description	Explique as tarefas e a finalidade, sem informações pessoais ou segredos.
Permissions	Selecione apenas as capacidades necessárias no catálogo disponível.

Criar ou editar um papel de tenant

Selecione New role ou Edit role em um papel editável.
Preencha Key e Label com uma convenção consistente, por exemplo operador_laboratorio.
Confirme Scope e Tenant; escreva uma descrição da responsabilidade.
Escolha o menor conjunto de permissões que atende às tarefas documentadas.
Envie e reabra o papel para conferir o conjunto persistido.
Em Users, atribua-o a uma identidade sintética autorizada e valide uma operação permitida e outra que deva ser negada. Confirme o papel ativo durante o teste.

Uma mudança em um papel atribuído a várias contas é compartilhada. Revise o impacto sobre os usuários antes de salvar e mantenha uma matriz de tarefa, permissão e resultado esperado. Papéis de sistema ou imutáveis podem ser consultados sem ações de edição ou exclusão. Não duplique um papel apenas para contornar uma restrição.

Excluir um papel com revisão das atribuições

Delete role aplica-se somente a um papel editável e elegível. Um papel com atribuições não pode ser excluído por essa ação. Inspecione as identidades afetadas, faça a reatribuição autorizada e atualize a contagem antes de confirmar. Não presuma que a exclusão substituirá automaticamente o papel de cada usuário.

Exemplo e recuperação

O laboratório precisa consultar Users e Audit, sem criar workers. Crie um papel de leitura para essas tarefas e use uma conta que tenha apenas o acesso necessário. Confira as consultas dentro do tenant e a indisponibilidade ou negação de gerenciamento em Cloud workers. Uma conta de plataforma não representa esse teste de menor privilégio, pois seus poderes podem ocultar uma configuração incompleta.

Se o formulário rejeitar a chave, ajuste o formato informado. Se o tenant não aparecer, confira o escopo delegado. Em uma negativa de salvamento, revise a sessão e o papel ativo do administrador. Se a exclusão estiver bloqueada, confira atribuições e imutabilidade. Para recuperar um erro de acesso, utilize uma via administrativa autorizada e registre a correção; não compartilhe credenciais.

Consulte também: Users, Tenants, Audit.

Papéis integrados e acesso efetivo

Papel	Responsabilidade
Platform `Administrator`	Responsabilidade administrativa de plataforma, sujeita à identidade e ao contexto de sessão válidos.
Tenant Owner / Tenant `Administrator`	Administração do tenant no escopo concedido. Propriedade, cobrança e plataforma mantêm responsabilidades distintas.
Billing `Administrator`	Consulta e gerenciamento de cobrança no contexto autorizado.
Security `Administrator`	Consulta de identidade, auditoria, conectividade e runtime e gerenciamento da política de notificações; não edita projetos ETL.
ETL Developer	Projeto e configuração de recursos ETL; não implica administração do tenant.
ETL Operator	Operação de `Workflows` e `Monitor` com as capacidades permitidas de execução e término.
ETL Viewer	Leitura dos módulos ETL; não altera o negócio, executa ou encerra `Workflows`.
Public Trial / Public	Papéis de onboarding com direitos e restrições de ciclo de vida distintos; não equivalem a administrador.

Confira o catálogo atual e o papel efetivo da sessão; os nomes descrevem responsabilidades e não substituem verificações de permissão, tenant e contrato. Papéis personalizados permanecem vinculados ao seu tenant. A isenção de quota DovaAI do administrador mestre único não se estende a todos os administradores: exige identidade persistida ativa, tenant de plataforma ativo, associação e papel selecionado válidos. A disponibilidade do provedor continua necessária.