Uma pessoa precisa de publicar notícias, outra de consultar encomendas e um fornecedor externo de corrigir uma falha. Dar acesso de administrador a todos parece resolver o problema, mas permite também executar tarefas que nada têm que ver com essas responsabilidades.
No WordPress, a escolha deve começar por três perguntas: o que é necessário fazer, sobre que conteúdos e durante quanto tempo? As respostas determinam se basta um perfil predefinido ou se são necessárias permissões mais específicas.
Como funcionam os perfis e as permissões
O WordPress organiza os acessos através de perfis de utilizador (roles) e permissões (capabilities). Um perfil reúne capacidades concretas, como editar artigos (edit_posts), publicá-los (publish_posts) ou gerir definições do website (manage_options).
É esta combinação de permissões — e não apenas o nome do perfil ou os menus visíveis — que determina as ações autorizadas. O WordPress e os plugins podem acrescentar ou modificar capacidades, pelo que a configuração real deve ser verificada antes de assumir o que uma conta consegue fazer.
Os perfis predefinidos do WordPress
Numa instalação WordPress individual existem cinco perfis principais:
| Perfil | O que permite, por defeito | Utilização habitual |
|---|---|---|
| Administrator (Administrador) | Gerir conteúdos, utilizadores, plugins, temas e definições do website. | Responsável pela administração técnica ou geral. |
| Editor | Criar, publicar, editar e eliminar artigos e páginas, incluindo os de outros utilizadores. | Equipa responsável pelos conteúdos. |
| Author (Autor) | Publicar e gerir os próprios artigos e carregar ficheiros multimédia. | Autor que publica com autonomia. |
| Contributor (Colaborador) | Escrever e editar os próprios artigos, sem os publicar nem carregar ficheiros, por defeito. | Colaborador cujos textos são sujeitos a aprovação. |
| Subscriber (Subscritor) | Iniciar sessão e gerir o próprio perfil, sem permissões editoriais. | Conta com necessidades básicas de autenticação. |
O perfil Editor, por exemplo, é adequado a uma equipa editorial, mas permite alterar conteúdos de outros autores. Se alguém só deve publicar os seus próprios artigos, Author pode ser mais apropriado. E um Subscriber não ganha automaticamente acesso a documentos privados apenas por iniciar sessão.
Exceção importante: numa rede WordPress Multisite existe o Super Admin, responsável pela administração da rede. Um Administrator de um website da rede não dispõe das mesmas permissões de instalação e gestão de plugins e temas que teria numa instalação individual.
O princípio do menor privilégio, sem bloquear o trabalho
O princípio do menor privilégio consiste em atribuir a cada pessoa apenas o acesso necessário para desempenhar as suas funções. Quem atualiza textos e imagens não precisa, por esse motivo, de gerir plugins, alterar configurações ou criar administradores. Estas permissões adicionais aumentam o impacto de um erro ou de uma conta comprometida.
A restrição também deve ser proporcional. Se alguém tem a responsabilidade de publicar artigos diariamente, obrigá-lo a solicitar aprovação para cada publicação pode prejudicar o trabalho sem acrescentar uma proteção relevante. O perfil deve corresponder à autonomia que a função exige.
Existem situações em que o Administrator é legítimo: o responsável pelo website pode precisar de controlo administrativo e uma agência ou programador pode necessitar dele para determinadas intervenções. No caso de fornecedores, convém avaliar se esse acesso deve ser temporário e revê-lo quando o trabalho termina.
Cada pessoa deve utilizar a sua própria conta, em vez de partilhar credenciais. Isso permite retirar acessos individualmente e relacionar alterações com utilizadores concretos, caso exista um registo de atividade configurado. As contas com permissões elevadas devem ter palavras-passe únicas e autenticação de dois fatores, sempre que possível.
Clientes e áreas reservadas: ter conta não significa poder administrar
A palavra «cliente» pode referir-se ao proprietário de um website, a alguém que consulta uma área reservada ou a um comprador de uma loja online. São situações diferentes e não devem conduzir automaticamente ao mesmo perfil.
Num portal de clientes, a pessoa pode precisar apenas de consultar documentos, acompanhar pedidos ou atualizar os seus dados. Essas funções podem ser apresentadas numa área reservada do próprio website, sem acesso ao painel wp-admin.
Há ainda uma distinção essencial entre ter permissão para consultar documentos e poder consultar um documento específico. Imagine duas empresas com contas do mesmo perfil: ambas podem utilizar a área de documentos, mas cada uma só deve conseguir aceder aos seus ficheiros. Essa separação exige regras de autorização associadas ao utilizador e a cada registo, não apenas um perfil comum.
O mesmo cuidado aplica-se aos downloads: ocultar uma página ou um botão não protege, por si só, um ficheiro que continue disponível através de um endereço público direto. A proteção tem de abranger o acesso efetivo aos dados e ficheiros.
WooCommerce: Customer e Shop Manager
O WooCommerce acrescenta dois perfis relevantes:
Customer (Cliente) destina-se a compradores com conta na loja. Permite gerir os próprios dados e consultar encomendas na área «A minha conta», sem conceder poderes de administração da loja.
Shop Manager (Gestor de loja) permite gerir produtos, encomendas, reembolsos, cupões, clientes, relatórios e configurações do WooCommerce. Inclui também capacidades editoriais gerais do WordPress, como editar artigos e páginas. É, portanto, um perfil com permissões consideráveis, embora não equivalha a Administrator.
Numa loja com várias pessoas, estas diferenças importam. Quem faz atendimento e só precisa de consultar encomendas ou atualizar estados poderá necessitar de um perfil mais limitado. Quem gere a operação comercial poderá precisar de Shop Manager. Atribuir esse perfil a todos por conveniência expõe funcionalidades e informação desnecessárias a algumas funções.
Quando faz sentido criar um perfil personalizado
Os perfis de origem resolvem muitos casos. A personalização justifica-se quando existe uma responsabilidade que não corresponde a nenhum deles.
Imagine um Gestor de Projetos que deve criar, editar e publicar projetos, carregar imagens, mas não alterar páginas do website nem gerir utilizadores. É possível configurar um perfil específico, desde que o tipo de conteúdo «Projetos» tenha permissões próprias corretamente definidas. Criar esse tipo de conteúdo, por si só, não garante a separação.
A personalização exige manutenção: documentar as permissões, rever alterações introduzidas por plugins e testar as tarefas necessárias. Ferramentas como Elementor, WooCommerce, plataformas de formação ou plugins de formulários podem verificar capacidades adicionais. Nos websites com temas de blocos, o acesso ao Editor do site e às funções de modelos, estilos e navegação também depende de permissões específicas.
Esconder um menu não é retirar uma permissão. A apresentação do painel pode ser simplificada, mas a autorização deve ser verificada quando a ação é executada, incluindo em pedidos diretos e interfaces de programação (API). No desenvolvimento WordPress, verificações como current_user_can() permitem confirmar capacidades, incluindo sobre conteúdos específicos.
Como definir, testar e rever os acessos
Antes de configurar perfis, uma pequena matriz de responsabilidades ajuda a evitar decisões baseadas apenas em cargos ou nomes de utilizadores.
| Função | Necessidade real | Ponto de partida a avaliar |
|---|---|---|
| Marketing | Editar e publicar artigos e páginas. | Editor, se puder gerir conteúdos de terceiros. |
| Gestão da loja | Gerir catálogo, encomendas e configurações. | Shop Manager, se precisar de todo esse âmbito. |
| Atendimento | Consultar encomendas e atualizar estados. | Perfil com permissões específicas. |
| Cliente de portal | Consultar apenas os seus pedidos e documentos. | Conta limitada e regras por utilizador/registo. |
| Administração técnica | Gerir plugins, utilizadores e definições. | Administrator, quando necessário. |
A matriz é um ponto de partida, não uma atribuição automática. A implementação deve seguir quatro passos:
- Definir as tarefas concretas: o que cada pessoa pode consultar, editar, publicar, configurar ou eliminar, e sobre que conteúdos.
- Escolher o perfil menos abrangente que permita trabalhar: ajustar capacidades ou criar um perfil próprio apenas quando existir uma necessidade real.
- Testar com contas desse perfil: verificar o painel de administração, a área reservada, formulários, carregamentos, downloads e ações diretas. Nos conteúdos privados, testar também se um utilizador consegue aceder indevidamente aos dados de outro.
- Rever o acesso ao longo do tempo: atualizar permissões quando alguém muda de função, retirar acessos de fornecedores após as intervenções e desativar contas que deixaram de ser necessárias. Fazer revisões periódicas, sobretudo depois de instalar funcionalidades novas.
Um teste realizado apenas com uma conta Administrator não demonstra que os restantes perfis funcionam corretamente. O comportamento deve ser validado com as permissões efetivas de quem vai utilizar o website.
Conclusão
A escolha entre Administrator, Editor, Customer ou um perfil personalizado depende da responsabilidade de cada utilizador e dos limites concretos do seu trabalho. Os perfis predefinidos são um bom ponto de partida; em lojas online, portais e equipas com funções separadas, podem ser necessárias regras adicionais.
Uma boa configuração permite realizar as tarefas autorizadas sem expor funções ou informações desnecessárias. A segurança depende dessas permissões e da sua aplicação efetiva, não apenas de mostrar menos opções no painel.
