EmDash CMS 插件运行时与安全模型
理解 EmDash 如何区分可信与沙箱化插件执行，以及 Dynamic Workers 对安全边界为何重要。
为何需要这套模型
多数 CMS 插件生态在同一道坎上失败：扩展运行权限过大。
EmDash 通过区分插件执行模式、显式划定能力边界来应对。
两类执行
可信插件
- 作为应用运行时的一部分加载
- 适用于你自有或完全信任的代码
- 运维简单，但安全取决于你的评审纪律
沙箱化插件
- 在隔离的 Worker 环境中执行
- 面向不可信或半可信的扩展逻辑
- 受显式能力、运行时限制与网络规则约束
安全姿态更少依赖「插件意图」，更多依赖运行时隔离保证。
架构中的 Dynamic Workers
Dynamic Workers 是 Cloudflare 上用于沙箱化执行的隔离原语。
没有它，沙箱模式不可用，你应仅在可信插件假设下运行。
实务上：
- 免费套餐：核心 CMS 可用，沙箱化插件模式不可用
- 开通 Dynamic Workers 的付费套餐：沙箱模型可用
能力模型：默认最小权限
插件应只声明所需：
- 读取内容
- 写入特定内容域
- 调用出站网络端点
- 触发选定工作流钩子
若未授予某能力，操作应确定性失败。这是设计要求，而非尽力而为的礼貌。
// 示例：保持能力范围显式
export default definePlugin({
id: "notify-on-publish",
capabilities: ["read:content", "email:send"]
});重要的运行时护栏
安全与可靠性都依赖硬限制：
- CPU 与墙钟时间上限，防止失控处理器
- 内存上限，约束滥用与意外泄漏
- 网络策略，阻断任意外泄尝试
这些控制把插件故障限制为有界事件，而非整站宕机。
一页纸威胁模型
假设任何第三方插件都可能包含：
- 恶意行为
- 陈旧依赖
- 罕见事件时序下的逻辑缺陷
因此插件运行时应保证：
- 爆炸半径可控
- 特权操作默认拒绝
- 执行结果可审计
信任应由策略赢得，而非安装即授予。
无沙箱支持时的运营模式
若在无沙箱支持下运行：
- 保持插件集合尽量小
- 优先使用第一方或内部已评审插件
- 在发布门禁做依赖与权限评审
- 在可能时将高风险集成放到外部服务
对许多团队这是可行模型，但需要更强的治理纪律。
决策标准：何时必须要求沙箱模式
在以下情况将沙箱模式视为必需：
- 大规模安装外部作者的插件
- 合规需要更强的隔离证据
- 插件被攻破带来的业务风险显著
在以下情况可视为可选：
- 插件面很小且已全面审计
- 团队端到端掌控发布流水线
实用治理清单
在生产环境启用任何插件前：
- 记录插件负责人与用途
- 评审所需能力与出站端点
- 指定回滚负责人与回滚流程
- 在预发环境用故障注入验证行为
插件安全不是一次性架构决策，而是由运行时边界支撑的运营流程。