Un buen CMS es invisible. Un CMS inadecuado puede dar con tus huesos en la calle si se produce un problema en un ámbito extremadamente sensible. Esto es lo que ha pasado en Reino Unido tal y como comenta Denis Haman en un artículo para Glide Publishing Platform. Allí se ha producido un error por parte de la Office for Budget Responsibility (OBR), que divulgó el informe presupuestario oficial una hora antes del discurso del Ministro de Hacienda. El error no ha sido humano, sino estructural y tiene mucho que ver con el CMS.
Cambia de CMS gratis con expertos
Cambia a un nuevo CMS más rápido y seguro, con inteligencia artificial (IA) integrada e incluso consigue ahorro. ¡Es posible!
No es la primera vez que Haman reclama soluciones de terceros específicamente diseñadas y optimizadas para grandes audiencias y necesidades muy específicas (como la suya propia) en vez de soluciones sencillas de código libre. El caso que nos ocupa hoy, relacionado con la OBR, le carga un poco más de razón.
Noticias relacionadas: Glide Publishing Platform
Tras el incidente, que ha derivado en la dimisión del presidente de la OBR, se ha realizado una investigación independiente que determinó que la versión del CMS estaba actualizada, el hosting era moderno y el mantenimiento era competente. Pero aún así se produjo el incidente. Simplemente el sistema no estaba preparado para manejar documentos críticos, para impedir que se publiquen antes de tiempo, ni para proteger ni aislar los accesos ni el contenido.
El problema, que ha derivado en gran pérdida de confianza y daños reputacionales hacia la OBR, simplemente se debió a que el CMS usado, generalista y de código libre, aunque estaba perfectamente gestionado, no está pensado ni preparado para manejar información sensible.
Las “plataformas baratas y simples” pueden parecer adecuadas hasta que falla un proceso crítico, siempre según Haman: la publicación empresarial exige una arquitectura con controles de acceso, separación de entornos, auditoría, control de tiempos de publicación y mínima dependencia de extensiones externas.
Por tanto, recomienda que organizaciones con requisitos de alta confianza adopten plataformas especializadas, diseñadas para publicación segura y controlada, en lugar de tratar de convertir CMS de propósito general en entornos aptos para información crítica. Como muestra este caso, ni siquiera cuando todo se hace bien, estamos seguros si el CMS no está perfectamente pensado y preparado para la situación específica que maneja.
Actualización 8 de diciembre: Según la publicación The Repository, la culpa de la filtración se debe a un plugin y no a WordPress en sí. Se trata de Download Monitor, plugin que no divulgaba el acceso al contenido, pero sí permitió a periodistas adivinar la url basándose en la url del año anterior.
De hecho, se trata de un fallo bastante común en los CMS y yo mismo, Jorge Mediavilla, el que os escribe, se encontró con él en con anterioridad en un CMS español que publicaba los documentos (PDF, etc) en producción incluso cuando los publicabas en el site de test.
Por tanto, el probema fue debido a un plugin mal configurado y una url previsible y no tanto a WordPress en sí. El personal, que había subido siempre así el archivo, creía que el archivo era privado hasta su publicación programada cuando esto en realidad no era así. El plugin por defecto publica el contenido y confía en que el servidor restringa el contenido hasta la hora indicada, pero eso no estaba configurado así.
Por tanto, no fue un fallo específico de WordPress, sino una mala configuración de un plugin y un flujo de trabajo no suficientemente estudiado que derivó en desastre debido a la clásica combinación de plugin más url prededible más configuración del servidor deficiente.
Para este tipo de usos, con información crítica y muy sensible, lo mejor es contar con la gama alta, que no es otra que WordPress VIP.
Deja una respuesta