Su empleado se fue. Nosotros gestionamos la tienda — y no pudimos demostrar que el acceso se fuera también.

El hallazgo que detuvo la revisión en seco

Creamos y mantenemos tiendas PrestaShop para otras empresas. Las tiendas no son nuestras — las gestionamos en nombre de nuestros clientes, lo que significa que mantener seguro su Back Office es responsabilidad nuestra. Ese es el trabajo. Y por eso la historia que voy a contar cayó sobre nosotros, no sobre otra persona.

Hace no mucho, un empleado de una de las empresas cuya tienda cuidamos se fue. Nada dramático, nada en la salida que merezca una historia por sí solo. Pero esa persona tenía accesos repartidos por la operación que gestionamos para su empresa — incluida una cuenta de PrestaShop Back Office — y su marcha activó lo que debería haber sido una revisión rutinaria de accesos en la tienda, el correo y el hosting. Como responsables de esa tienda, nos tocaba hacer esa revisión.

Encontró el desorden habitual que esperas de una operación que creció más rápido que sus procesos. Pero un hallazgo lo detuvo todo en seco — y no fue el login del Back Office por el que todos suelen preocuparse primero. Fue el buzón:

El buzón del empleado que se había ido — su bandeja personal y los buzones compartidos de rol que había usado — seguía activo. Su contraseña nunca se había rotado. Y se seguía iniciando sesión en él cada día.

Esta es la parte que debería preocuparte más que el hallazgo en sí: como todo el equipo del cliente trabajaba desde una única conexión compartida de oficina, y como algunas credenciales se compartían entre personas, era imposible saber si esos logins diarios eran de la persona que se había ido o de un compañero actual haciendo el trabajo antiguo desde el buzón antiguo. Ambas explicaciones encajaban perfectamente con los logs. Una línea de log registra que una credencial se usó desde una dirección — y una dirección IP identifica una conexión, no una persona. Semanas después de que alguien dejara de trabajar para la empresa, nosotros — la agencia responsable de la seguridad de esa tienda — no podíamos demostrar que su acceso se hubiera detenido con él.

De eso trata este post. No de una brecha — no encontramos pruebas de ninguna, y para ser precisos sobre lo que los logs mostraban realmente: se usaron las credenciales todavía activas del buzón del antiguo empleado; quién las tenía en la mano es exactamente lo que nadie pudo establecer. Algo más silencioso y, diría, más común que una brecha: una tienda cuyos responsables no podían responder a la pregunta “¿quién puede entrar en algo de esto ahora mismo?” — y, cuando intentamos reconstruir la respuesta desde los logs, descubrimos que los logs tampoco podían decírnoslo. Y si eso es cierto para un buzón, la misma arquitectura te deja igual de ciego sobre el Back Office — que es hacia donde apunta el resto de este post.

Si gestionas — o gestionas para otra persona — una tienda PrestaShop en la que más de una persona toca el Back Office, este post es la checklist que me habría gustado tener a mano antes de necesitarla.

Por qué falló el análisis forense — y por qué el tuyo también fallaría

Cuando apareció el hallazgo “sigue activo, sigue iniciando sesión”, el siguiente paso obvio era el análisis forense: sacar los logs, atribuir cada login, confirmar que no hubiera pasado nada indebido. Hicimos ese trabajo. Falló en gran parte, y merece la pena explicar cómo falló, porque no es algo específico de este cliente — es el estado por defecto de un stack de hosting típico de pequeña empresa, y vemos la misma forma en las tiendas que gestionamos.

Los logs no llegaban lo bastante atrás. El servidor de correo solo conservaba logs detallados de login durante unas cuatro semanas. Todo lo anterior simplemente había desaparecido. Si la pregunta es “¿se ha usado mal esta cuenta desde que la persona se fue hace meses?”, una ventana de cuatro semanas no puede responderla — y ninguna habilidad cambia eso.

El webmail ocultaba la fuente real. Los logins a través del cliente webmail alojado pasaban por proxy en el propio servidor, así que el log de correo registraba la dirección local del servidor como origen de la sesión — no la IP real de la persona. Toda una clase de acceso era, por arquitectura, prácticamente anónima.

Las IP compartidas destruyeron la atribución. Todos en la oficina del cliente salían por una única conexión de banda ancha. Un login desde la IP de la oficina podía ser de cualquiera de una docena de personas — incluida, potencialmente, alguien que ya no trabajaba allí pero seguía teniendo la contraseña y, digamos, un motivo para pasar, o un dispositivo que todavía sincronizaba automáticamente. NAT, VPNs y redes compartidas producen el mismo efecto: la IP te dice de dónde vino una conexión, nunca quién estaba detrás.

Las credenciales compartidas la destruyeron por segunda vez. Varios buzones de rol y el propio acceso al hosting usaban contraseñas conocidas por varias personas. Cuando cinco personas conocen una contraseña, una línea de log demuestra que se usó una contraseña — nunca quién la usó.

El acceso preexistente era invisible. La limitación más importante de todas: los logs registran eventos, no conocimiento. Si alguien copió una contraseña, exportó un buzón o apuntó una clave API mientras tenía acceso legítimo, ningún log lo mostrará jamás. La revisión podía concluir honestamente “no encontramos pruebas de abuso” — y tuvimos que añadir de inmediato la salvedad que cualquier persona de seguridad conoce: la ausencia de pruebas no es prueba de ausencia.

Junto, esta es la lección real, y la tesis de todo este post:

No puedes investigar lo que nunca preveniste. Para cuando estás haciendo análisis forense, ya has perdido la versión de esta historia en la que obtienes una respuesta limpia. La prevención no solo es más barata que el análisis forense — en un stack típico de merchant, es la única de las dos que realmente funciona.

Nuestra propia casa tampoco estaba limpia

Estaría escribiendo un post deshonesto si lo planteara como “un cliente tenía mala higiene y nosotros, la agencia diligente, lo miramos con desaprobación desde la banda”. La misma revisión auditó accesos que incluían nuestras propias cuentas de agencia en esa tienda — y encontró dos cosas de las que no estoy orgulloso.

Una de mis propias contraseñas llevaba unos cinco años sin cambiarse. Era larga, era única, nunca — hasta donde cualquier log podía mostrar — se había usado indebidamente. Nada de eso es el punto. Cinco años son cinco años de antiguos colaboradores, dispositivos viejos, perfiles de navegador olvidados y brechas de terceros acumulándose contra un secreto estático. Como personas pagadas para cuidar esta tienda, sabíamos que debía hacerse mejor. Aun así, era cierto.

Mi “VPN” empeoraba las cosas, no las mejoraba. Durante años usé un servicio VPN gratuito que rota sus servidores de salida por centros de datos aleatorios. En seguridad aportaba poco. En análisis forense era un desastre al revés: mis propios logins legítimos en la tienda aparecían en los logs como ráfagas desde IPs desconocidas de centros de datos en varios países — exactamente la huella de una toma de cuenta. Durante la revisión quemamos horas reales demostrando que el patrón más alarmante de todo el historial de logs era yo, el propio administrador de la tienda, navegando por la ruleta de nodos de salida de una VPN gratuita. Una herramienta que había adoptado en nombre de la seguridad generó el ruido que casi enterró la señal.

Incluyo esto porque es la forma honesta de este problema, y porque sostener Back Offices de clientes significa someternos a la misma lista. La higiene de credenciales no falla porque la gente sea descuidada o tonta. Falla porque nada en la operación diaria obliga a tratar el asunto. La tienda funciona. El correo llega. La contraseña de 2021 todavía te deja entrar. Cada día en que nada sale mal es un día en que la deuda se acumula de forma invisible — hasta que una salida, una auditoría o un incidente te obliga a mirar.

El ciclo de vida de las credenciales tiene dos mitades. Todo el mundo hace una.

Cuando alguien entra — un empleado, un freelance, una agencia, un socio de negocio — el acceso se crea en horas. Tiene que ser así, o no puede trabajar. Hay una persona motivada (el recién llegado), un responsable motivado (que necesita que sea productivo) y un modo de fallo inmediato y visible si no ocurre.

Cuando la relación termina, la revocación no tiene nada de eso. Nadie queda bloqueado porque la cuenta de alguien que se fue siga existiendo. No hay mensaje de error, queja ni ticket. El resultado por defecto de no hacer nada es que todo sigue funcionando — y ese es precisamente el problema. El onboarding se autoimpone; el offboarding solo ocurre si lo has convertido en un proceso deliberado y escrito. Y se aplica por igual a cualquier tipo de salida: el empleado que dimite, el contractor cuyo proyecto termina, la agencia de la que un cliente se marcha. Hay una segunda trampa aquí que nos golpeó directamente: cuando una tienda la gestiona una agencia pero la atiende el propio equipo del cliente, el offboarding puede caer en el hueco entre ambos — el cliente asume que su empleado saliente es “problema de nuestro proveedor”, la agencia nunca se entera de que la persona se fue. El acceso no sabe de quién se suponía que era el problema. Alguien tiene que hacerse dueño de él explícitamente, por escrito, en ambos lados.

Y en una operación e-commerce, “acceso” nunca es una sola cuenta. Es una expansión: el PrestaShop Back Office, buzones, buzones compartidos de rol, SSH y FTP, el panel de control del hosting, acceso a base de datos, claves webservice API, el dashboard del proveedor de pago, la plataforma de envíos, analytics, marketplaces, el gestor de contraseñas, documentos compartidos. Si omites cualquiera de ellos, la salida no está completa — simplemente has dejado de mirar.

La checklist de offboarding que la mayoría de tiendas no tiene

Este es el artefacto que hay que robar de este post. Imprímelo, adáptalo y adjúntalo a tu proceso de salida — seas el merchant o la agencia que gestiona la tienda, el objetivo es que el último día de alguien estés ejecutando una lista, no intentando recordar todo el stack bajo presión.

Dos notas de proceso importan tanto como la lista: se ejecuta el último día, no “en un par de semanas” — la revisión que provocó este post encontró la brecha precisamente porque la revocación se trató como una tarea eventual. Y alguien es responsable por nombre — y cuando una tienda la gestiona una agencia, ese “alguien” y el traspaso entre cliente y agencia tienen que estar fijados antes de que nadie se vaya, no improvisados después. Una checklist que nadie posee es una sugerencia.

Una decisión deliberada en la fila 1 merece repetirse: desactiva, no elimines. Una cuenta desactivada no puede iniciar sesión, pero conserva su identidad y sus referencias existentes — así, cualquier registro que sí la mencione sigue resolviendo a una persona conocida en lugar de a un enlace colgante. Eliminar parece más limpio y deja huérfanos exactamente los enlaces que quizá necesites entender más tarde.

Hardening: para que una contraseña filtrada nunca sea suficiente

El offboarding es control de daños para un sistema en el que contraseña equivale a acceso. La solución más profunda es hacer que un Back Office sobreviva incluso cuando una credencial se filtra — porque tarde o temprano una se filtrará. Estos son los seis cambios que ahora impulsamos en cada tienda que gestionamos, en el orden en que yo los haría:

1. Eliminar cuentas compartidas — una persona, una cuenta. Esta es la base sobre la que se sostiene todo lo demás. El sistema de empleados de PrestaShop (Parámetros avanzados → Equipo) existe precisamente para que nunca compartas un login: dale a cada persona su propia cuenta con un perfil que coincida con su trabajo real, y reserva SuperAdmin para una o dos personas que de verdad lo necesiten. La recompensa es exactamente lo que esta tienda no tenía cuando heredamos su historia: cuando cada cuenta corresponde a un humano, puedes atribuir acciones y puedes revocar a una persona sin resetear a todos.

2. Revocar por completo, no solo la contraseña obvia. La checklist de arriba es el punto: una salida significa ejecutar las doce filas, no desactivar el login del Back Office y darlo por hecho. El hallazgo que abrió este post no fue una cuenta Back Office — fue un buzón. El acceso que olvidas siempre es el acceso que importa.

3. Poner el Back Office detrás de un muro IP — en el borde del servidor, no solo en la aplicación. Renombrar el directorio admin es oscuridad, no control; una URL filtrada lo deshace. Lo que realmente cambia las matemáticas es una allowlist: el Back Office responde solo a direcciones de salida conocidas de oficina y VPN, y a nadie más en internet. Y la respuesta honesta de ingeniería es que el mejor lugar para aplicarlo está completamente delante de PrestaShop — una regla a nivel de servidor (nginx allow/deny, Apache Require ip), una política de Cloudflare Access o regla WAF en la ruta admin, o una VPN que sea la única ruta de red hacia el Back Office. Aplicado ahí, el bloqueo ocurre antes de que corra una sola línea de PHP, así que ni siquiera una vulnerabilidad de aplicación puede hablar para saltárselo. Una allowlist dentro de la aplicación queda entonces como una segunda capa valiosa — defense in depth, y a menudo la única capa disponible en hosting compartido restrictivo donde no controlamos el borde. Nuestro módulo mprsecurityrevolution ofrece esa capa como firewall IP — reglas de bloqueo, reglas whitelist, bloqueo por país — y aplica la misma lógica de allowlist directamente a los logins de empleados con una puerta trusted-admin-IP en el Back Office. De cualquier forma, el efecto es el mismo: una contraseña admin filtrada o sin rotar — el fallo exacto de esta historia — ya no basta por sí sola. Un atacante necesita la credencial y una posición en tu red.

4. Añadir un segundo factor a los logins admin — PrestaShop no lo hará por ti. Este dato sorprende a muchos merchants: PrestaShop core — 1.7, 8 y 9 por igual — no trae autenticación de dos factores nativa para el Back Office. PrestaShop 8 y 9 endurecieron el acceso admin de otras formas (una política de contraseñas configurable y mejor gestión de sesiones), pero un segundo factor nunca llegó al core. Si quieres 2FA en logins de empleados, tiene que venir de un módulo o de una capa delante de la tienda (un portal SSO o algo como Cloudflare Access). Merece la pena: una app TOTP en el teléfono de cada admin cuesta segundos por login y elimina toda la categoría “alguien, en algún sitio, todavía conoce una contraseña antigua” como forma suficiente de entrar. mprsecurityrevolution añade autenticación de dos factores TOTP a los logins de empleados PrestaShop para que el Back Office la tenga sin infraestructura personalizada. Pero ten claro qué compra la 2FA: reduce drásticamente el riesgo password-only — no hace offboarding de nadie. Un empleado que se fue, cuya cuenta sigue activa y cuyo teléfono sigue registrado, pasa directamente por la 2FA. Complementa la checklist; no puede reemplazarla.

5. Rotar por calendario y en cada salida — y usar una VPN real. La rotación no va de paranoia; va de limitar la antigüedad de cualquier secreto que un antiguo colaborador, un portátil viejo o un tercero comprometido pueda seguir teniendo. Rota credenciales críticas por calendario (panel de hosting, base de datos, dashboards de pago como mínimo), y rota todo lo que tocó una persona que se va en su último día — son las filas 3, 5, 6 y 9 de la checklist. Y si tú o el equipo de tu cliente usáis VPN para entrar en algo, usa una de verdad con direcciones de salida fijas y conocidas — WireGuard autoalojado o un proveedor empresarial reputado. Mi VPN gratuita de salidas rotativas no solo añadía una seguridad insignificante; envenenó activamente los logs que luego necesitaba. Una VPN con IP de salida estable hace lo contrario: hace que el acceso legítimo sea más atribuible y da a tu allowlist IP una dirección limpia en la que confiar.

6. Registrar acciones admin — porque solo puedes investigar lo que has registrado. Los callejones sin salida forenses de antes no fueron mala suerte; eran la postura de logging por defecto de un stack estándar. Y una salvedad merece decirse claramente: el logging integrado de PrestaShop no es un audit trail completo. La página Logs del core (Parámetros avanzados → Logs) registra errores y un subconjunto de eventos, pero muchas acciones relevantes para seguridad — logins y sus fuentes, cambios de permisos, ediciones de configuración — no dejan una traza duradera y revisable, y la retención es lo que tu rutina de mantenimiento deje por casualidad. Decide ahora qué preguntas necesitarías responder tras un incidente — quién entró en el Back Office y desde dónde, quién creó o desactivó un empleado, quién cambió permisos, quién tocó configuración relevante para seguridad — y asegúrate de que algo registre esas respuestas de forma duradera hoy, con más de cuatro semanas de retención. Por eso el activity y audit logging es uno de los pilares de la protección admin de mprsecurityrevolution, junto con su gestión de sesiones (un único lugar para ver cada sesión Back Office activa y terminar las que no deberían existir — el problema de “sigue conectado desde un dispositivo antiguo” — en PS 1.7, 8 y 9 por igual; las versiones antiguas no tienen ningún control así, y en PS 9 se sitúa junto a la gestión de sesiones propia del core como una consola única para detectar y cerrar sesiones), monitorización de integridad de archivos y comprobaciones de seguridad email. Cuando llegue la pregunta incómoda — y si gestionas tiendas para otros, llegará — “registramos quién hizo qué en el Back Office” es la diferencia entre una respuesta y encogerse de hombros.

Por dónde empezar si este post te ha incomodado

Empieza por la verdad, no por las herramientas. Nuestro scanner gratuito y open-source, mprsecurityscan, audita una tienda desde dentro — archivos expuestos, hardening ausente, valores por defecto arriesgados — y te da hallazgos con pasos manuales de corrección. Solo detecta y es gratuito, porque el primer paso es saber dónde estás realmente. Luego trabaja la checklist de arriba contra todos los que alguna vez tuvieron acceso — cada empleado, contractor, agencia y socio actual y antiguo — y deja que los resultados te digan cuál de los seis pasos de hardening necesitas primero. Cuando quieres que los controles admin se hagan cumplir en vez de depender de la memoria, para eso está mprsecurityrevolution: el firewall IP, la gestión de sesiones, activity y audit logging, monitorización de integridad de archivos y seguridad email que incluye hoy, más autenticación de dos factores y la puerta de login trusted-admin-IP para el Back Office. Ningún módulo hace automático el offboarding ni vuelve imposible el riesgo interno — nada lo hace — pero mueve los controles críticos de “alguien se acordó” a “el sistema lo exige”. Ese es el estándar que nos imponemos en cada tienda que gestionamos, y el que querríamos en la nuestra.

El final silencioso

La revisión que empezó todo terminó sin drama: la cuenta del empleado que se fue fue desactivada — desactivada, no eliminada, para que su identidad y referencias sigan intactas en lugar de quedar huérfanas — las contraseñas se rotaron, y la checklist ahora existe, tiene un responsable y está escrita en la forma en que transferimos accesos con ese cliente.

No se encontró ninguna brecha. Pero “no se encontró ninguna brecha” y “no hubo ninguna brecha” son frases distintas, y el hueco entre ellas es permanente — esa tienda simplemente nunca lo sabrá con certeza, porque los logs que podrían haberlo dicho nunca se conservaron, y el acceso que debería haber terminado con el empleo lo sobrevivió en silencio.

Ese no saber permanente e irresoluble es el verdadero coste de gestionar mal el ciclo de vida de las credenciales. No lo pagas el día que alguien se va. Lo pagas meses después, en una revisión o en un incidente, cuando cada pregunta vuelve como “no podemos saberlo”. Y si eres quien tiene encomendada la tienda de otra persona, es su negocio quien lo paga — por eso lo tratamos como algo nuestro que debe hacerse bien.

La mejor respuesta ante incidentes es el login que nunca ocurrió. Revoca como si hablaras en serio.