Uma auditoria de permissões responde duas perguntas: quem consegue executar uma ação administrativa e por qual caminho recebeu esse poder? Em um servidor com LuckPerms, a resposta pode envolver grupos, herança, permissões diretas, contextos e também OP. Conferir apenas o nome do cargo não mostra tudo que a conta consegue fazer.

Este roteiro é voltado a uma equipe que já possui cargos configurados. Para instalar o plugin e criar os primeiros grupos, use o tutorial básico de LuckPerms. A auditoria trabalha com o estado real da comunidade e evita remover permissões em massa sem conhecer as ações que dependem delas.

Liste as capacidades que precisam de controle

Comece pelas ações, não pelos cargos. Liste punições, edição de regiões, acesso a inventários, alteração de economia, execução de comandos como outro usuário e administração das próprias permissões. Inclua também poderes externos ao jogo: console, arquivos, backups, banco de dados e painel de hospedagem.

Para cada ação, registre quem precisa executá-la e em qual contexto. Um atendente pode precisar consultar uma situação sem modificar o saldo. Um moderador pode precisar aplicar uma punição sem conceder cargos. Um desenvolvedor pode precisar de acesso temporário ao teste, sem acesso contínuo à produção.

Essa lista vira uma matriz simples de expectativas. Ela permite reconhecer excessos sem depender de uma convenção de nomes como “admin” ou “staff”. Dois cargos com nomes diferentes podem herdar o mesmo conjunto de poderes, enquanto um único cargo pode ter limitações distintas em mundos separados.

Preserve o estado antes de editar

Faça um backup dos dados de permissões e registre os grupos e usuários envolvidos. Se LuckPerms utiliza um banco externo, inclua esse armazenamento na cópia. Não presuma que copiar a pasta do plugin capture dados que estão em outro serviço. Confira se o método de recuperação escolhido realmente restaura a configuração usada.

Realize a revisão em uma instância isolada quando houver muitas alterações. A cópia precisa consultar um banco separado. Caso contrário, uma edição feita “só para testar” modifica as permissões dos jogadores no servidor público.

Defina quem pode aplicar mudanças durante a auditoria. Se várias pessoas ajustam os mesmos cargos enquanto você registra resultados, a comparação deixa de representar um estado consistente. Combine uma janela curta para revisão ou anote cada mudança paralela que não puder esperar.

Separe OP, grupos e permissões diretas

Revise a lista de operadores do servidor e confirme por que cada conta está nela. OP pode alterar o resultado de testes de comandos, dependendo do comportamento do plugin e de suas permissões padrão. Use contas de teste sem OP para avaliar o que os grupos realmente concedem.

No console, sem a barra inicial, consulte o vínculo de uma conta com seus grupos:

lp user NomeDoJogador parent info

Substitua o nome pela conta que está sendo revisada. Compare os grupos apresentados com os cargos esperados. Investigue vínculos antigos de desenvolvedores, benefícios temporários que não foram removidos e grupos que alguém adicionou durante uma correção de emergência.

Revise também as permissões aplicadas diretamente ao usuário. Remover um grupo pode não retirar um poder que foi concedido à conta por outro caminho. Uma auditoria completa precisa observar os nós efetivos e sua origem, não apenas a aparência do cargo no chat.

Cheque permissões específicas e sua origem

Escolha o nó documentado pelo plugin responsável pela ação. Não adivinhe a permissão pelo nome do comando. Plugins diferentes podem implementar funções semelhantes com nós distintos, ou exigir mais de uma permissão para completar um fluxo.

Para verificar um nó conhecido, use:

lp user NomeDoJogador permission check permissao.do.plugin

O texto permissao.do.plugin é um marcador: substitua-o pelo nó real obtido na documentação do componente. Registre o resultado e compare com a ação esperada. Se o comando depende de contexto, repita a verificação na situação em que o jogador o utiliza, em vez de presumir um resultado global.

Procure concessões amplas, como curingas administrativos, e heranças que atravessam funções distintas. Um cargo VIP não precisa herdar um grupo de moderação para ganhar um benefício cosmético. Quando um nó amplo existir, identifique primeiro quais funções dependem dele antes de removê-lo.

Teste o comportamento no jogo

Entre com uma conta sem OP vinculada somente aos grupos esperados para o teste. Execute ações permitidas e ações que devem ser recusadas. Use alvos de teste: uma região descartável, uma conta preparada e dados que possam ser restaurados. Não teste uma punição ou uma alteração econômica em um jogador real sem necessidade.

Registre comando, contexto, resultado e mensagem apresentada. Se a checagem de permissão retornar verdadeiro mas a ação falhar, investigue requisitos adicionais do plugin. Se retornar falso e a ação funcionar, confira OP, outra integração, permissões padrão e se o nó consultado é realmente o utilizado pela função.

Repita tarefas importantes após reconectar e após um reinício planejado da instância de teste. Isso ajuda a encontrar alterações que pareciam funcionar apenas no estado carregado ou em uma sessão antiga. O critério de sucesso é o comportamento consistente da conta no ambiente definido.

Remova excessos com uma alteração rastreável

Ao retirar um vínculo de grupo, remova o vínculo específico em vez de substituir todos os cargos da conta. Para um usuário que não deve continuar no grupo VIP, o exemplo é:

lp user NomeDoJogador parent remove vip

Esse comando não garante que um poder desapareceu, pois a conta pode recebê-lo de outro grupo ou de um nó direto. Repita a checagem e o teste de comportamento após a mudança. Registre também quais benefícios legítimos precisam continuar funcionando.

Para conjuntos maiores, o editor web pode ajudar a visualizar os dados. Confira usuários, grupos e contextos antes de salvar e aplicar o comando fornecido pela sessão. Mantenha a URL da sessão privada e restrinja quem pode executar o comando de aplicação no servidor.

Revise os acessos fora do LuckPerms

A permissão dentro do jogo é somente uma camada. Uma pessoa sem poder de moderação pode continuar alterando qualquer coisa se possui console ou acesso aos arquivos. Revise contas do painel, chaves, credenciais de banco e integrações administrativas com a mesma lista de responsabilidades.

Prefira acessos individuais para saber quem executou uma ação e para revogar somente a conta envolvida. Documente como retirar o acesso de um membro que saiu da equipe. Se uma credencial foi compartilhada entre várias pessoas, trocar apenas o cargo no LuckPerms não encerra o acesso ao ambiente.

Conclua com uma matriz de permissões verificadas

Guarde a expectativa de cada função, os nós relevantes, os testes realizados e as exceções aprovadas. Identifique permissões temporárias com responsável e data para revisão. Não invente uma frequência universal: revise quando houver entrada ou saída da equipe, mudança de plugin e alterações importantes na estrutura de cargos.

A auditoria terminou quando a equipe consegue explicar de onde vem um poder, demonstrar que as contas adequadas o possuem e comprovar que as demais são recusadas. A matriz registrada permite repetir esse teste depois de uma atualização sem reconstruir toda a investigação do zero.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.