EmDash CMS – Plugin-Laufzeit und Sicherheitsmodell
Wie EmDash vertrauenswürdige und sandboxed Plugin-Ausführung trennt und warum Dynamic Workers für Sicherheitsgrenzen wichtig ist.
Warum dieses Modell existiert
Die meisten CMS-Plugin-Ökosysteme scheitern an derselben Grenze: Erweiterungen laufen mit zu vielen Rechten.
EmDash adressiert das, indem es Ausführungsmodi trennt und Fähigkeitsgrenzen explizit macht.
Zwei Ausführungsklassen
Vertrauenswürdige Plugins
- werden als Teil Ihrer Anwendungslaufzeit geladen
- geeignet für Code, den Sie besitzen oder dem Sie voll vertrauen
- operativ einfach, Sicherheit hängt aber von Ihrer Review-Disziplin ab
Sandboxed Plugins
- laufen in isolierten Worker-Umgebungen
- für nicht vertrauenswürdige oder teilweise vertrauenswürdige Erweiterungslogik
- eingeschränkt durch explizite Capabilities, Laufzeitlimits und Netzwerkregeln
Die Sicherheitslage hängt weniger von Plugin-Absicht als von Isolationsgarantien der Laufzeit ab.
Dynamic Workers in der Architektur
Dynamic Workers ist das Isolationsprimitiv für sandboxed Ausführung auf Cloudflare.
Ohne es ist der Sandbox-Modus nicht verfügbar; Sie sollten nur mit Annahmen vertrauenswürdiger Plugins arbeiten.
Praktisch:
- Free-Tarif: CMS-Kern funktioniert, sandboxed Plugin-Modus nicht
- Paid-Tarif mit Dynamic Workers: Sandbox-Modell wird verfügbar
Capability-Modell: standardmäßig minimal nötige Rechte
Ein Plugin sollte nur deklarieren, was es braucht:
- Inhalte lesen
- bestimmte Content-Domains schreiben
- ausgehende Netzwerk-Endpunkte aufrufen
- ausgewählte Workflow-Hooks auslösen
Wird eine Capability nicht gewährt, soll die Operation deterministisch fehlschlagen. Das ist eine Designanforderung, kein „best effort“.
// Beispiel: Capability-Umfang explizit halten
export default definePlugin({
id: "notify-on-publish",
capabilities: ["read:content", "email:send"]
});Laufzeit-Leitplanken, die zählen
Sicherheit und Zuverlässigkeit hängen an harten Grenzen:
- CPU- und Wall-Time-Limits verhindern unkontrollierte Handler
- Speicher-Obergrenzen begrenzen Missbrauch und versehentliche Lecks
- Netzwerkrichtlinien blockieren willkürliche Exfiltration
Diese Steuerungen verwandeln Plugin-Fehler in begrenzte Vorfälle statt Plattform-Ausfälle.
Bedrohungsmodell auf einer Seite
Gehen Sie davon aus, dass jedes Drittanbieter-Plugin enthalten kann:
- schädliches Verhalten
- veraltete Abhängigkeiten
- Logikfehler bei ungewöhnlichem Ereignis-Timing
Die Plugin-Laufzeit sollte daher garantieren:
- Eindämmung des Auswirkungsradius
- standardmäßig verweigerte privilegierte Operationen
- nachvollziehbare Ausführungsergebnisse
Vertrauen soll durch Policy verdient werden, nicht durch Installation gewährt.
Betriebsmodell im Free-Tarif
Ohne Sandbox-Unterstützung:
- Plugin-Set minimal halten
- First-Party- oder intern geprüfte Plugins bevorzugen
- Abhängigkeits- und Berechtigungs-Review an Release-Gates
- riskante Integrationen wo möglich in externe Services auslagern
Das ist für viele Teams tragfähig, erfordert aber strengere Governance.
Entscheidungskriterien: wann Sandbox-Modus Pflicht ist
Sandbox-Modus als verpflichtend behandeln, wenn:
- Sie Plugins externer Autoren in großem Umfang installieren
- Compliance stärkere Isolationsnachweise verlangt
- Geschäftsrisiko durch Plugin-Kompromittierung relevant ist
Sandbox-Modus als optional behandeln, wenn:
- Plugin-Oberfläche klein und voll geprüft ist
- das Team die Release-Pipeline Ende-zu-Ende kontrolliert
Praktische Governance-Checkliste
Bevor ein Plugin in Produktion aktiviert wird:
- Plugin-Eigentümer und Zweck dokumentieren
- benötigte Capabilities und ausgehende Endpunkte prüfen
- Rollback-Verantwortlichen und Rollback-Verfahren festlegen
- Verhalten in Staging mit Fehler-Injektion validieren
Plugin-Sicherheit ist keine einmalige Architekturentscheidung, sondern ein operativer Prozess mit Laufzeitgrenzen.