Perfis e permissões dos funcionários no back office do PrestaShop

Abra a lista de funcionários do seu back office e conte quantos são superadministradores. Em muitas lojas a resposta é «todos»: o dono, o da logística, a pessoa do apoio ao cliente, a agência que fez o tema há anos e uma conta chamada «loja» cuja palavra-passe meia equipa conhece. Funciona até ao dia em que alguém se engana, sai de má maneira ou lhe roubam a palavra-passe.

Como o PrestaShop organiza os acessos

Os acessos gerem-se em Parâmetros avançados → Equipa, com três peças:

• Funcionários: cada pessoa com o seu e-mail, a sua palavra-passe e um perfil atribuído.
• Perfis: grupos de permissões. O PrestaShop traz alguns de origem (SuperAdmin, Logística, Tradutor, Vendedor) e pode criar os seus.
• Permissões: para cada perfil, o que pode ver, adicionar, editar e eliminar em cada secção do menu, e que módulos pode configurar.

O perfil SuperAdmin não pode ser restringido: tem acesso a tudo, incluindo os funcionários, a configuração dos métodos de pagamento, a instalação de módulos e o webservice. Por isso é o perfil que deve ser atribuído com mais cuidado.

O princípio do mínimo necessário

Cada pessoa deveria ter apenas as permissões de que precisa para o seu trabalho diário. Não é desconfiança: é limitar o que pode correr mal com uma palavra-passe roubada ou um clique errado. Um ponto de partida razoável:

Os superadministradores deveriam ser dois no máximo: o responsável da loja e quem a mantém tecnicamente. Se a sua agência precisa de entrar de vez em quando, dê-lhe uma conta própria que ativa quando for preciso e desativa no fim.

Porque não partilhar contas

A conta partilhada é cómoda e tem três problemas sérios:

1. Não sabe quem fez o quê. Se um preço aparece errado ou uma encomenda muda de estado, o histórico diz «loja», não uma pessoa.
2. Não pode desativar um sem incomodar todos. Quando alguém sai, ou muda a palavra-passe e avisa os restantes, ou deixa-a como está. Quase sempre fica como está.
3. A palavra-passe circula. Acaba numa mensagem de WhatsApp, num post-it ou no gestor de palavras-passe de um portátil pessoal.

Uma conta por pessoa, sempre, mesmo que sejam duas pessoas e uma delas entre uma vez por mês.

Quando alguém sai da empresa

Este é o momento mais descuidado. Uma lista de passos que cabe numa nota:

1. Desative a conta no próprio dia, não a elimine. Desativada não consegue entrar, e conserva o seu rasto em encomendas, mensagens e históricos.
2. Verifique que outros acessos tinha: FTP, painel do alojamento, e-mail da loja, contas de gateways de pagamento, Google, redes sociais, fornecedores. O back office é apenas um deles.
3. Altere as palavras-passe que conhecia, mesmo que tenham sido partilhadas «só por um momento».
4. Reveja as chaves de webservice que tenha criado. Uma chave de API não depende da conta do funcionário e continua a funcionar mesmo que o desative.
5. Reveja os módulos que tenha instalado nas últimas semanas.

Contas de que ninguém se lembra

Além das saídas, reveja a lista completa de poucos em poucos meses:

• Funcionários que não entram há muito tempo.
• E-mails de domínios que não são o seu nem o da sua agência atual.
• Contas de teste criadas durante uma instalação ou uma migração.
• Mais superadministradores do que se lembra de ter criado.

Um caso habitual

Uma loja de equipamento desportivo muda de agência. A agência anterior tinha duas contas de superadministrador, uma delas criada para um estagiário que esteve lá um verão. Ninguém as desativa porque «já não entram». Meses depois, uma dessas palavras-passe aparece numa fuga de outro serviço onde tinha sido reutilizada, e alguém entra no back office com ela. Não foi precisa nenhuma vulnerabilidade: bastou uma conta que já não tinha dono.

Uma conta esquecida com palavra-passe fraca é uma porta que ninguém vigia. E se aparecem superadministradores que ninguém criou, não é um descuido: é o rasto típico de uma injeção de SQL num módulo, e deve ser tratado como um incidente.

Palavras-passe e acesso

• Palavras-passe longas e únicas para cada funcionário, guardadas num gestor de palavras-passe.
• Pasta do back office com nome próprio, e não a predefinida da instalação.
• HTTPS em todo o back office, sem exceções.
• Autenticação de dois fatores se a sua versão ou um módulo o permitir, começando pelos superadministradores.
• PrestaShop e módulos em dia: as permissões não servem de nada se uma falha num módulo permitir criar um administrador sem passar pelo formulário.

Apoio ao cliente sem dar mais permissões

Uma razão frequente para distribuir superadministradores é que o apoio ao cliente «precisa de ver o que o cliente vê». A saída habitual é pedir a palavra-passe ao cliente ou criar contas de teste, e as duas são más ideias. É melhor ter uma forma controlada de entrar como o cliente, limitada aos perfis que escolher e com cada acesso registado.

Como resolver no PrestaShop

O RKR Security Alert guarda uma fotografia dos funcionários e das contas de webservice e avisa-o por Telegram de cada criação, alteração ou eliminação, destacando as contas de superadministrador e as promoções a esse perfil, mesmo que sejam feitas por SQL direto. Também avisa quando um funcionário entra no back office a partir de um IP novo para ele e assinala na sua auditoria as contas de administrador inativas. O RKR Acceso maestro resolve o apoio ao cliente: permite entrar na conta de um cliente a partir da ficha dele, da encomenda ou das listagens, com uma ligação de utilização única, apenas para os perfis de funcionário que escolher (por predefinição, só SuperAdmin) e com um registo de que funcionário entrou em que cliente, quando e a partir de que IP.