EmDash CMS – Modelo de tiempo de ejecución y seguridad de plugins
Cómo EmDash separa la ejecución de plugins de confianza y en sandbox, y por qué Dynamic Workers importa para los límites de seguridad.
Por qué existe este modelo
La mayoría de los ecosistemas de plugins de CMS fallan en el mismo límite: las extensiones se ejecutan con demasiados privilegios.
EmDash lo aborda separando modos de ejecución de plugins y haciendo explícitos los límites de capacidad.
Dos clases de ejecución
Plugins de confianza
- se cargan como parte del tiempo de ejecución de tu aplicación
- adecuados para código que posees o en el que confías plenamente
- simples operativamente, pero la seguridad depende de tu disciplina de revisión
Plugins en sandbox
- se ejecutan en entornos worker aislados
- pensados para lógica de extensión no confiable o semiconfiable
- limitados por capacidades explícitas, límites de tiempo de ejecución y reglas de red
La postura de seguridad depende menos de la intención del plugin y más de las garantías de aislamiento del tiempo de ejecución.
Dynamic Workers en la arquitectura
Dynamic Workers es el primitivo de aislamiento usado para ejecución en sandbox en Cloudflare.
Sin él, el modo sandbox no está disponible y deberías operar solo con supuestos de plugins de confianza.
En la práctica:
- plan Free: el núcleo CMS funciona, el modo sandbox de plugins no
- plan de pago con Dynamic Workers: el modelo sandbox está disponible
Modelo de capacidades: mínimo privilegio por defecto
Un plugin solo debe declarar lo que necesita:
- leer contenido
- escribir dominios de contenido concretos
- llamar a endpoints de red salientes
- disparar hooks de flujo de trabajo seleccionados
Si no se concede una capacidad, la operación debe fallar de forma determinista. Es un requisito de diseño, no una cortesía opcional.
// Ejemplo: mantén explícito el alcance de capacidades
export default definePlugin({
id: "notify-on-publish",
capabilities: ["read:content", "email:send"]
});Barreras de tiempo de ejecución que importan
Tanto la seguridad como la fiabilidad dependen de límites duros:
- límites de CPU y tiempo real evitan manejadores desbocados
- techos de memoria limitan abusos y fugas accidentales
- políticas de red bloquean intentos de exfiltración arbitraria
Estos controles convierten fallos de plugins en incidentes acotados en lugar de caídas de plataforma.
Modelo de amenaza en una página
Asume que cualquier plugin de terceros puede contener:
- comportamiento malicioso
- dependencias obsoletas
- errores de lógica con sincronización de eventos poco común
Por tanto el tiempo de ejecución de plugins debería garantizar:
- contención del radio de explosión
- operaciones privilegiadas denegadas por defecto
- resultados de ejecución auditables
La confianza se gana por política, no se otorga por instalación.
Modelo operativo en plan Free
Si ejecutas sin soporte de sandbox:
- mantén el conjunto de plugins mínimo
- prefiere plugins de primera parte o revisados internamente
- revisa dependencias y permisos en las puertas de release
- aísla integraciones arriesgadas en servicios externos cuando sea posible
Es un modelo viable para muchos equipos, pero exige más disciplina de gobernanza.
Criterios de decisión: cuándo exigir modo sandbox
Trata el modo sandbox como obligatorio cuando:
- instalas plugins de autores externos a escala
- el cumplimiento exige pruebas de aislamiento más fuertes
- el riesgo empresarial por compromiso de plugin es material
Trátalo como opcional cuando:
- la superficie de plugins es pequeña y está auditada por completo
- el equipo controla el pipeline de release de extremo a extremo
Lista de comprobación práctica de gobernanza
Antes de habilitar cualquier plugin en producción:
- documenta propósito y responsable del plugin
- revisa capacidades requeridas y endpoints salientes
- define responsable y procedimiento de rollback
- valida el comportamiento en staging con inyección de fallos
La seguridad de plugins no es una decisión de arquitectura única. Es un proceso operativo respaldado por límites de tiempo de ejecución.