Permisos de CMS para un equipo editorial en crecimiento

Los permisos editoriales de un CMS deben corresponder a responsabilidades de publicación, no a la jerarquía ni a la comodidad. Dé a cada persona el acceso que necesita y pruebe tanto lo permitido como lo prohibido. Un equipo en crecimiento requiere límites claros entre redacción, publicación, revisión de traducciones y administración del sistema.

Defina acciones antes de escoger nombres de roles

Empiece con verbos: crear, editar, publicar, retirar, subir archivos, aprobar traducciones, modificar navegación, instalar extensiones y administrar usuarios. Distinga entre editar borradores propios y cambiar contenido publicado por otra persona. Incluya exportaciones y operaciones masivas, que suelen quedar fuera de la inducción.

Los roles predeterminados de WordPress muestran por qué hay que revisar las etiquetas: un Editor puede gestionar publicaciones ajenas, mientras que un Colaborador no puede publicar las propias. Otros CMS distribuyen las responsabilidades de otra forma. Un rol llamado “editor” no es una especificación universal.

Construya una matriz con flujos reales y después relaciónela con las capacidades de la plataforma. Esta podría ser una propuesta inicial:

Responsabilidad	Acceso habitual	Aprobación separada
Colaborador	Borradores propios	Publicación
Editor de sección	Contenido asignado y revisión	Navegación global
Revisor de idioma	Borradores traducidos	Publicación de la traducción
Responsable de publicación	Contenido público aprobado	Configuración del CMS
Administrador	Configuración del sistema	Las decisiones editoriales conservan su responsable

Es una propuesta de diseño, no una afirmación de que todos los CMS permitan restringir por sección o idioma de forma nativa. Verifique esos límites antes de elegir extensiones o prometer el proceso al equipo.

Pruebe las restricciones con cuentas reales de ensayo

Cree cuentas de prueba para cada rol. Intente abrir directamente un borrador de otra sección, modificar una dirección, llamar una API disponible y enviar una acción de publicación no autorizada. Ocultar un botón no establece una restricción de acceso.

La guía de autorización de OWASP recomienda privilegios mínimos, denegar por defecto y verificar permisos en cada solicitud. Aplique ese criterio a las funciones editoriales propias, además de la interfaz del CMS.

Considere una publicación bilingüe hipotética. Un redactor independiente necesita corregir un borrador en inglés, pero no debe cambiar su versión publicada en español. Un rol genérico de editor podría permitir ambas acciones. El equipo comprueba si puede restringir por idioma. Si no puede, el redactor entrega cambios mediante un borrador restringido y un responsable aplica las correcciones aprobadas.

Ese procedimiento resulta menos cómodo que editar directamente, pero deja clara la limitación. No prometa una separación que el sistema no puede hacer cumplir.

Incorpore los cambios de acceso a la operación editorial

Utilice cuentas individuales, no una contraseña compartida por la redacción. Registre responsable, propósito y vencimiento de los accesos temporales. Separe la administración técnica de las tareas habituales, con un procedimiento de intervención excepcional.

Cuando alguien cambia de puesto o sale del equipo, revise sesiones, tokens de API, servicios conectados y publicaciones programadas a su nombre. Eliminar la cuenta visible no completa la revisión. Compruebe otra vez los permisos cuando un plugin modifique el proceso editorial.

En equipos entre Costa Rica y Estados Unidos, designe una persona suplente disponible durante las horas de publicación. El diseño de acceso falla en la práctica si la única persona autorizada está de vacaciones o fuera de horario.

Pruebe una acción prohibida por cada rol actual y registre el resultado. Si el CMS no permite expresar los límites requeridos, lleve la matriz a una revisión de software a medida con 5e Labs antes de ampliar los accesos.