Sicherheitsarchitektur — Whitepaper¶
Leitprinzip: nicht „sicher", sondern beweisbar sicher. Wir behaupten keine Schutzschicht, die nicht real, aktiv und überprüfbar ist. Ehrlichkeit über Marketing.
Dieses Dokument beschreibt, wie enconf Kunden auf einem geteilten Server voneinander isoliert, wie wir diese Isolation nachweisbar machen, und — genauso wichtig — wo die physikalischen Grenzen liegen.
Die eine harte Wahrheit¶
100 % Isolation auf einem geteilten Kernel ist physikalisch unmöglich. Das gilt für jedes Single-Server-Hosting-Panel (Plesk, cPanel, DirectAdmin, CloudPanel …), nicht nur für enconf. Ein lokales Kernel-Privesc-CVE, ein MariaDB-CVE oder ein PHP-Binary-CVE trifft prinzipiell alle Tenants derselben Instanz. Echte harte Isolation gibt es nur mit eigenen VMs oder Containern pro Kunde.
„Keiner kommt an die Basics" heißt für uns deshalb ehrlich:
- Defense in Depth — jede Schicht muss einzeln überwunden werden.
- Nachweisbarkeit — jede Schicht ist verifiziert aktiv und dem Kunden sichtbar.
- Zeitnahe Patches — die unteilbaren Basics (Kernel, MariaDB, PHP, Postfix/Dovecot) werden schnellstmöglich aktualisiert.
Genau Punkt 2 ist unser Anspruch: beweisbar sicher statt behauptet sicher.
Defense in Depth — die aktiven Schichten¶
Jede Zeile entspricht einem realen, im System verifizierbaren Mechanismus. Sie werden bei Updates über eine idempotente Migration auch auf bestehende Sites nachgezogen.
Prozess- & Dateisystem-Isolation¶
| Schicht | Was sie leistet |
|---|---|
| Eigener Linux-User pro Website | Eigene UID/GID; Standard-Unix-DAC. Fremde Sites können die Dateien nicht lesen. |
Webroot 0710 user:www-data |
Owner voll, Nginx darf traversieren, alle anderen 0 — kein cd von außen. |
| PHP-FPM-Pool pro Website | PHP läuft mit der Identität der Site, kein geteilter www-data. |
open_basedir |
PHP ist auf Home + eigenes /tmp + System-PHP eingesperrt. |
disable_functions |
exec, system, shell_exec, proc_open, popen, alle pcntl_* u. a. gesperrt. |
| FFI deaktiviert | ffi.enable=0 — schließt den FFI::cdef→libc-Umweg um disable_functions. |
Per-User /tmp/<user> 0700 |
Eigener Pfad für Sessions/Uploads — kein Cross-Tenant-Leak über shared /tmp. |
| AppArmor-Profil pro Kunde | Eigenes Profil je PHP-FPM; pro Server zwischen Complain- und Enforce-Modus umschaltbar, mit automatischem Rückfall bei False-Positive-Häufung. |
| systemd-Slice pro Kunde | MemoryMax / CPUQuota / TasksMax / IO — greift für neue und bestehende Sites. |
Datenbank & Secrets¶
| Schicht | Was sie leistet |
|---|---|
| MariaDB/PostgreSQL-Grants pro Kunde | GRANT … ON kunden_db.* strikt — kein globales Recht, keine Cross-DB-Queries. |
Panel-Secrets 0600 root:root |
JWT_SECRET, DB_PASSWORD, AGENT_TOKEN sind für Kunden-PHP nicht lesbar. |
Netzwerk & Mail¶
| Schicht | Was sie leistet |
|---|---|
| nftables SMTP-Egress-Block | Nur root/Postfix dürfen auf Port 25 nach außen — kein Direkt-zu-MX-Spam aus Kunden-Prozessen. |
| GeoIP-Filter mit Lock-out-Schutz | Länder-Sperren inkl. Allowlist für Admin-/Controller-IP. |
| fail2ban | Brute-Force-Schutz für SSH, FTP, Mail und Panel-Login. |
Nginx Upload-.php-Block |
.php in Upload-Verzeichnissen wird nicht ausgeführt — schließt das häufigste WordPress-Hack-Pattern. |
Kernel-Härtung¶
kernel.kptr_restrict, kernel.dmesg_restrict, yama.ptrace_scope,
unprivileged_bpf_disabled, bpf_jit_harden, perf_event_paranoid sind gesetzt.
User-Namespaces bleiben bewusst aktiv, da rootless Container/gVisor sie benötigen.
Nachweisbarkeit — der entscheidende Unterschied¶
Sicherheit, die man nicht sehen kann, ist für Kunden nicht von Marketing zu unterscheiden. Deshalb macht enconf die Isolation sichtbar und laufend geprüft:
- Pro-Kunde-Sicherheits-Score: Jeder Kunde sieht in seinem Dashboard einen
Isolations-Score, der pro Website anzeigt, welche Schutzschichten (eigener PHP-Prozess,
open_basedir,disable_functions, FFI aus, abgeschottetes Verzeichnis, AppArmor, Ressourcen-Limits …) wirklich aktiv sind — jede Zeile live vom Server zurückgelesen, nicht behauptet. - Security Advisor (Admin): serverweite Audit-Checkliste, SBOM (CycloneDX), Live-CVE-Feed und ein Nachweise-&-Export-Abschnitt für Kunden, die selbst Hersteller sind.
- Zentrales SIEM-Log-Forwarding: sicherheitsrelevante Logs werden flottenweit über TLS an einen Collector weitergegeben.
Supply-Chain & Patch-Disziplin¶
- SBOM + Live-CVE-Feed (OSV/Debian-Security-Tracker) melden verwundbare Komponenten proaktiv.
- Signiertes APT-Repository (GPG-signierte Release-Metadaten) für authentische Updates.
- Reproduzierbare Builds + Prüfsummen: die Pakete werden deterministisch gebaut
(
-trimpath, fixe Zeitstempel), sodass ein Nachbau aus dem Quellcode byte-identische Artefakte ergibt; pro Release wird eineSHA256SUMS-Liste veröffentlicht. Wer will, verifiziert die Installation unabhängig — nicht „vertrau uns", sondern nachrechnen. - Vendor-Repos gepinnt mit Key-Self-Heal.
- Automatische OS-Security-Updates (
unattended-upgrades). - Sicherheits-Nachweise & Export unterstützen Kunden, die selbst Hersteller eines Produkts mit digitalen Elementen sind, bei ihren Lieferketten-Nachweisen nach dem EU Cyber Resilience Act (Incident-Register, SBOM, CVE-Abgleich, Export) — es ist ein Werkzeug, keine Zertifizierung, und für die meisten Kunden nicht einschlägig (siehe Security Advisor).
Was wir bewusst NICHT tun¶
- Keine On-Server-WAF. Eine WAF gehört vorgelagert an den Edge/Reverse-Proxy, nicht auf den Hosting-Server. On-Server-WAFs sind in der Praxis fragil und erzeugen Scheinsicherheit. WAF-Schutz erfolgt ausschließlich upstream.
- Keine behauptete Isolation ohne Verifikation. Jede Zeile des Sicherheits-Scores muss einem realen, geprüften Mechanismus entsprechen.
Grenzen — ehrlich benannt¶
Diese Punkte sind architektonisch nicht durch Panel-Schichten behebbar und betreffen jedes Single-Kernel-System gleichermaßen:
- Kernel — alle Kunden teilen einen Kernel. Ein lokales Privesc-CVE betrifft alle.
- MariaDB-/PostgreSQL-Prozess — eine Instanz pro Server.
- PHP-Binary — alle Pools derselben Version teilen denselben Code.
- Postfix/Dovecot/PowerDNS — je eine Instanz für alle Domains.
Die Gegenmaßnahme ist dieselbe wie bei jedem seriösen Anbieter: zeitnahe Updates der unteilbaren Basics. Wer echte Kernel-Isolation braucht, fährt Kunden in eigenen VMs oder Containern — enconf bietet dafür optional rootless Container-Isolation (gVisor) als stärkere Stufe für untrusted Workloads.
Dieses Whitepaper wird mit dem Sicherheits-Modell gepflegt. Stand: siehe Changelog.