Runtime e modelo de segurança de plugins do EmDash CMS
Entenda como o EmDash separa execução confiável e em sandbox de plugins, e por que Dynamic Workers importa para limites de segurança.
Por que este modelo existe
A maioria dos ecossistemas de plugins de CMS falha no mesmo limite: extensões rodam com privilégio demais.
O EmDash trata disso separando modos de execução de plugin e tornando explícitos os limites de capacidade.
Duas classes de execução
Plugins confiáveis
- carregados como parte do runtime da sua aplicação
- adequados para código que você possui ou em que confia totalmente
- operacionalmente simples, mas a segurança depende da sua disciplina de revisão
Plugins em sandbox
- executados em ambientes worker isolados
- desenhados para lógica de extensão não confiável ou semi-confiável
- restritos por capacidades explícitas, limites de runtime e regras de rede
A postura de segurança depende menos da intenção do plugin e mais de garantias de isolamento de runtime.
Dynamic Workers na arquitetura
Dynamic Workers é o primitivo de isolamento usado para execução em sandbox na Cloudflare.
Sem ele, o modo sandbox não está disponível, e você deve operar apenas com suposições de plugin confiável.
Em termos práticos:
- Plano gratuito: CMS core funciona, modo sandbox de plugin não
- Plano pago com Dynamic Workers: modelo sandbox fica disponível
Modelo de capacidade: menor privilégio por padrão
Um plugin deve declarar só o que precisa:
- ler conteúdo
- escrever em domínios específicos de conteúdo
- chamar endpoints de rede de saída
- disparar hooks de fluxo de trabalho selecionados
Se uma capacidade não for concedida, a operação deve falhar de forma determinística. Isso é requisito de design, não cortesia de melhor esforço.
// Exemplo: manter o escopo de capacidade explícito
export default definePlugin({
id: "notify-on-publish",
capabilities: ["read:content", "email:send"]
});Trilhos de runtime que importam
Segurança e confiabilidade dependem de limites rígidos:
- limites de CPU e tempo de parede impedem handlers descontrolados
- tetos de memória restringem abuso e vazamentos acidentais
- políticas de rede bloqueiam tentativas arbitrárias de exfiltração
Esses controles convertem falhas de plugin em incidentes limitados em vez de indisponibilidade da plataforma.
Modelo de ameaça em uma página
Assuma que qualquer plugin de terceiros pode conter:
- comportamento malicioso
- dependências desatualizadas
- bugs de lógica sob timing de evento incomum
O runtime de plugin deve então garantir:
- contenção do raio de explosão
- operações privilegiadas negadas por padrão
- resultados de execução auditáveis
Confiança deve ser conquistada por política, não concedida pela instalação.
Modo operacional no plano gratuito
Se você roda sem suporte a sandbox:
- mantenha o conjunto de plugins mínimo
- prefira plugins de primeira parte ou revisados internamente
- faça revisão de dependências e permissões nos gates de release
- isole integrações arriscadas em serviços externos quando possível
É um modelo viável para muitas equipes, mas exige disciplina de governança mais forte.
Critérios de decisão: quando exigir modo sandbox
Trate o modo sandbox como obrigatório quando:
- você instala plugins de autores externos em escala
- compliance exige evidência de isolamento mais forte
- o risco de negócio de comprometimento de plugin é material
Trate o modo sandbox como opcional quando:
- a superfície de plugin é pequena e totalmente auditada
- a equipe controla o pipeline de release ponta a ponta
Checklist prático de governança
Antes de habilitar qualquer plugin em produção:
- documente dono e propósito do plugin
- revise capacidades exigidas e endpoints de saída
- defina dono de rollback e procedimento de rollback
- valide comportamento em staging com injeção de falhas
Segurança de plugin não é decisão de arquitetura única. É processo operacional sustentado por limites de runtime.