Perfiles y permisos de empleados en el back-office de PrestaShop

Abre la lista de empleados de tu back-office y cuenta cuántos son superadministradores. En muchas tiendas la respuesta es «todos»: el dueño, el de logística, la persona de atención al cliente, la agencia que hizo el tema hace años y una cuenta llamada «tienda» cuya contraseña conoce medio equipo. Funciona hasta el día en que alguien se equivoca, se va de malas maneras o le roban la contraseña.

Cómo organiza PrestaShop los accesos

Los accesos se gestionan en Parámetros avanzados → Equipo, con tres piezas:

• Empleados: cada persona con su correo, su contraseña y un perfil asignado.
• Perfiles: grupos de permisos. PrestaShop trae algunos de serie (SuperAdmin, Logística, Traductor, Vendedor) y puedes crear los tuyos.
• Permisos: para cada perfil, qué puede ver, añadir, editar y borrar en cada sección del menú, y qué módulos puede configurar.

El perfil SuperAdmin no se puede restringir: tiene acceso a todo, incluidos los empleados, la configuración de los métodos de pago, la instalación de módulos y el webservice. Por eso es el perfil que hay que repartir con más cuidado.

El principio del mínimo necesario

Cada persona debería tener solo los permisos que necesita para su trabajo diario. No es desconfianza: es limitar lo que puede salir mal con una contraseña robada o un clic equivocado. Un punto de partida razonable:

Los superadministradores deberían ser dos como mucho: el responsable de la tienda y quien la mantiene técnicamente. Si tu agencia necesita entrar de vez en cuando, dale una cuenta propia que actives cuando la necesite y desactives al terminar.

Por qué no compartir cuentas

La cuenta compartida es cómoda y tiene tres problemas serios:

1. No sabes quién hizo qué. Si un precio aparece mal o un pedido cambia de estado, el historial dice «tienda», no una persona.
2. No puedes dar de baja a uno sin molestar a todos. Cuando alguien se va, o cambias la contraseña y avisas al resto, o la dejas como está. Casi siempre se deja como está.
3. La contraseña circula. Acaba en un mensaje de WhatsApp, en un pósit o en el gestor de contraseñas de un portátil personal.

Una cuenta por persona, siempre, aunque sean dos personas y una de ellas entre una vez al mes.

Cuando alguien deja la empresa

Este es el momento que más se descuida. Una lista de pasos que cabe en una nota:

1. Desactiva la cuenta el mismo día, no la borres. Desactivada no puede entrar, y conservas su rastro en pedidos, mensajes e historiales.
2. Revisa qué otros accesos tenía: FTP, panel del hosting, correo de la tienda, cuentas de pasarelas de pago, Google, redes sociales, proveedores. El back-office es solo uno.
3. Cambia las contraseñas que conocía aunque fueran compartidas «solo un momento».
4. Revisa las claves de webservice que hubiera creado. Una clave de API no depende de la cuenta del empleado y sigue funcionando aunque lo desactives.
5. Revisa los módulos que hubiera instalado en sus últimas semanas.

Cuentas que nadie recuerda

Además de las bajas, revisa cada pocos meses la lista entera:

• Empleados que no han entrado en mucho tiempo.
• Correos de dominios que no son el tuyo ni el de tu agencia actual.
• Cuentas de prueba creadas durante una instalación o una migración.
• Más superadministradores de los que recuerdas haber creado.

Un caso habitual

Una tienda de equipamiento deportivo cambia de agencia. La agencia anterior tenía dos cuentas de superadministrador, una de ellas creada para un becario que estuvo un verano. Nadie las desactiva porque «ya no entran». Meses después, una de esas contraseñas aparece en una filtración de otro servicio donde se había reutilizado, y alguien entra al back-office con ella. No hizo falta ninguna vulnerabilidad: bastó una cuenta que ya no tenía dueño.

Una cuenta olvidada con contraseña débil es una puerta que nadie vigila. Y si aparecen superadministradores que nadie dio de alta, no es un despiste: es el rastro típico de una inyección SQL en un módulo, y hay que tratarlo como un incidente.

Contraseñas y acceso

• Contraseñas largas y únicas para cada empleado, guardadas en un gestor de contraseñas.
• Carpeta del back-office con nombre propio, no la de la instalación por defecto.
• HTTPS en todo el back-office, sin excepciones.
• Doble factor si tu versión o un módulo lo permite, empezando por los superadministradores.
• PrestaShop y módulos al día: los permisos no sirven de nada si un fallo en un módulo permite crear un administrador sin pasar por el formulario.

Soporte al cliente sin dar más permisos

Una razón frecuente para repartir superadministradores es que atención al cliente «necesita ver lo que ve el cliente». La salida habitual es pedirle la contraseña al cliente o crear cuentas de prueba, y las dos son malas ideas. Es mejor tener una forma controlada de entrar como el cliente, limitada a los perfiles que tú elijas y con cada acceso registrado.

Cómo resolverlo en PrestaShop

RKR Security Alert guarda una foto de los empleados y las cuentas de webservice y te avisa por Telegram de cada alta, cambio o baja, resaltando las cuentas de superadministrador y los ascensos a ese perfil, aunque se hagan por SQL directo. También avisa cuando un empleado entra al back-office desde una IP nueva para él y señala en su auditoría las cuentas de administrador inactivas. RKR Acceso maestro resuelve el soporte: permite entrar en la cuenta de un cliente desde su ficha, su pedido o los listados, con un enlace de un solo uso, solo para los perfiles de empleado que elijas (por defecto, solo SuperAdmin) y con un registro de qué empleado entró en qué cliente, cuándo y desde qué IP.