Runtime et modèle de sécurité des plugins EmDash CMS
Comprendre comment EmDash sépare l’exécution des plugins de confiance et en bac à sable, et pourquoi Dynamic Workers compte pour les frontières de sécurité.
Pourquoi ce modèle existe
La plupart des écosystèmes de plugins CMS échouent à la même frontière : les extensions s’exécutent avec trop de privilèges.
EmDash y répond en séparant les modes d’exécution des plugins et en rendant les frontières de capacité explicites.
Deux classes d’exécution
Plugins de confiance
- chargés dans le runtime de votre application
- adaptés au code que vous possédez ou en qui vous avez entièrement confiance
- opérationnellement simples, mais la sécurité dépend de votre discipline de revue
Plugins en bac à sable
- exécutés dans des environnements workers isolés
- conçus pour une logique d’extension non fiable ou semi-fiable
- contraints par des capacités explicites, des limites runtime et des règles réseau
La posture de sécurité dépend moins de l’intention du plugin que des garanties d’isolation runtime.
Dynamic Workers dans l’architecture
Dynamic Workers est la primitive d’isolation utilisée pour l’exécution en bac à sable sur Cloudflare.
Sans lui, le mode bac à sable n’est pas disponible, et vous ne devez opérer qu’avec des hypothèses de plugins de confiance.
En pratique :
- Plan gratuit : le CMS principal fonctionne, le mode plugin en bac à sable non
- Plan payant avec Dynamic Workers : le modèle bac à sable devient disponible
Modèle de capacités : moindre privilège par défaut
Un plugin ne doit déclarer que ce dont il a besoin :
- lire le contenu
- écrire dans des domaines de contenu spécifiques
- appeler des points de terminaison réseau sortants
- déclencher des hooks de workflow sélectionnés
Si une capacité n’est pas accordée, l’opération doit échouer de façon déterministe. C’est une exigence de conception, pas une courtoisie au mieux.
// Exemple : garder le périmètre des capacités explicite
export default definePlugin({
id: "notify-on-publish",
capabilities: ["read:content", "email:send"]
});Garde-fous runtime qui comptent
La sécurité et la fiabilité reposent toutes deux sur des limites strictes :
- limites CPU et temps réel pour éviter les handlers incontrôlables
- plafonds mémoire pour limiter les abus et les fuites accidentelles
- politiques réseau pour bloquer les tentatives d’exfiltration arbitraires
Ces contrôles transforment les défaillances des plugins en incidents bornés plutôt qu’en pannes plateforme.
Modèle de menace en une page
Supposez que tout plugin tiers peut contenir :
- un comportement malveillant
- des dépendances obsolètes
- des bugs de logique sous des timings d’événements rares
Le runtime des plugins doit donc garantir :
- la limitation de la zone d’impact
- le refus par défaut des opérations privilégiées
- des résultats d’exécution auditable
La confiance doit être méritée par la politique, pas accordée à l’installation.
Mode d’exploitation sur plan gratuit
Si vous tournez sans support du bac à sable :
- gardez l’ensemble des plugins minimal
- privilégiez les plugins internes ou revus en interne
- faites la revue des dépendances et des permissions aux jalons de release
- isolez les intégrations risquées dans des services externes quand c’est possible
C’est un modèle viable pour beaucoup d’équipes, mais il exige une discipline de gouvernance plus forte.
Critères de décision : quand exiger le mode bac à sable
Traitez le mode bac à sable comme obligatoire lorsque :
- vous installez des plugins d’auteurs externes à grande échelle
- la conformité exige des preuves d’isolation plus fortes
- le risque métier d’une compromission par plugin est matériel
Traitez-le comme optionnel lorsque :
- la surface des plugins est petite et entièrement auditée
- l’équipe maîtrise de bout en bout la chaîne de release
Liste de contrôle de gouvernance pratique
Avant d’activer un plugin en production :
- documenter le propriétaire et l’objectif du plugin
- revoir les capacités requises et les points de terminaison sortants
- désigner le responsable du rollback et la procédure de rollback
- valider le comportement en préproduction avec injection de défaillances
La sécurité des plugins n’est pas une décision d’architecture ponctuelle. C’est un processus opérationnel soutenu par des frontières runtime.