Dedizierter Server vs. Managed Shared Hosting: Wer hat die Kontrolle über deine Sicherheitskonfiguration?

Beim verwalteten Shared Hosting kümmert sich der Hosting-Anbieter um die Serverkonfiguration.

Sie entscheiden, welche TLS-Versionen unterstützt werden, wie Sicherheits-Header angewendet werden, wann Software gepatcht wird und was du ändern darfst. Auf einem dedizierten Server bist du das. Dieser Unterschied spielt keine große Rolle, wenn alles reibungslos läuft. Er ist jedoch von großer Bedeutung, wenn ein Sicherheitsaudit, eine Risikoprüfung des Anbieters oder ein SecurityScorecard-Bericht bestimmte Probleme aufzeigt, die du in deiner aktuellen Umgebung nicht beheben kannst. Die ehrliche Antwort auf diese Frage lautet: Es hängt davon ab, wem der Server gehört.

In diesem Artikel wird genau erklärt, welche Entscheidungen zur Sicherheitskonfiguration auf Serverebene getroffen werden, warum verwaltete Hosting-Umgebungen deinen Zugriff darauf einschränken und was sich tatsächlich ändert, wenn du auf einen dedizierten Server mit Root-Zugriff umsteigst.

Was bedeutet „Managed“ in Bezug auf die Sicherheit?

Managed Hosting ist ein Kompromiss, kein Nachteil. Der Anbieter kümmert sich um die Infrastruktur, damit du dich ganz auf deine Website konzentrieren kannst. Dazu gehören die Serverkonfiguration, Software-Updates, die Wartung der Hardware und ja, auch die Sicherheitskonfiguration. Das Ergebnis ist ein schnellerer Weg zu einer betriebsbereiten Website mit weniger technischem Aufwand.

Der Nachteil dabei ist, dass „verwaltet“ auch bedeutet, dass „die Konfiguration von jemand anderem vorgenommen wird“. Der Webserver, das Betriebssystem, die Firewall, der TLS-Stack – diese Komponenten werden nach den Standards des Anbieters konfiguriert, nicht nach deinen. Diese Standards werden einmal festgelegt, flächendeckend in einer gemeinsam genutzten Umgebung für viele Kunden angewendet und nach dem Zeitplan des Anbieters aktualisiert.

Das funktioniert für die allermeisten Hosting-Anforderungen gut. Für Unternehmen, die bestimmte Sicherheitsstandards erfüllen, die Anforderungen der Unternehmensbeschaffung einhalten oder Beanstandungen in einem externen Sicherheitsrating beheben müssen, stellt dies jedoch eine Grenze dar, die sich nur schwer umgehen lässt, ohne die Hosting-Umgebung zu ändern.

Welche Sicherheitsentscheidungen werden auf Serverebene getroffen?

Es gibt einige Sicherheitseinstellungen, die völlig außerhalb deines Anwendungscodes und außerhalb deines Content-Management-Systems liegen. Sie werden in der Webserver-Software – Apache, cPanel, Nginx oder LiteSpeed – sowie in der Betriebssystemkonfiguration festgelegt. Das WordPress , cPanel und sogar der FTP-Zugang haben keinen Einfluss darauf.

TLS-Protokollversionen. Ob dein Server Verbindungen über TLS 1.0, 1.1, 1.2 oder 1.3 akzeptiert, wird in der SSL-Konfigurationsdatei des Webservers festgelegt. TLS 1.0 und 1.1 wurden 2021 von der IETF aufgrund bekannter kryptografischer Schwachstellen als veraltet eingestuft. Ob sie auf deiner Website weiterhin aktiviert sind, hängt ganz davon ab, was der Server so konfiguriert ist, dass er akzeptiert.

Verschlüsselungssuiten. Welche Verschlüsselungsalgorithmen dein Server während des TLS-Handshakes anbietet, ist eine separate, damit verbundene Konfiguration. Schwache Verschlüsselungssuiten – also solche, die RC4, 3DES oder Schlüsselgrößen im Exportstandard verwenden – werden auf Plattformen zur Sicherheitsbewertung als eigene Befunde angezeigt, selbst wenn du die TLS-Versionen aktualisiert hast. Um sie zu entfernen, musst du dieselbe Konfiguration auf Serverebene bearbeiten.

HTTP-Sicherheitsheader. Header wie HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), X-Content-Type-Options und X-Frame-Options werden vom Webserver mit jeder HTTP-Antwort gesendet. Um sie zuverlässig hinzuzufügen, ist entweder eine Anweisung in der Virtual-Host-Konfiguration des Webservers oder eine .htaccess-Regel auf Apache-Servern erforderlich. Der Webserver sendet sie, noch bevor die Anwendungsschicht die Anfrage überhaupt verarbeitet.

Zertifikatskonfiguration. Der Signaturalgorithmus, die Unterstützung für Zertifikatssperrlisten (OCSP-Stapling) und die Bereitstellungsoptionen für ein TLS-Zertifikat werden festgelegt, wenn das Zertifikat auf dem Server installiert und konfiguriert wird. Ein Anwendungs-Plugin kann diese Einstellungen nachträglich nicht mehr ändern.

Häufigkeit von Software-Updates. Welche Version von PHP, OpenSSL und dem Linux-Kernel auf dem Server läuft, hängt davon ab, wer für die Paketaktualisierungen zuständig ist. Wie schnell eine kritische CVE behoben wird – im Vergleich dazu, wie schnell sie bei einem Scan auftaucht – hängt vom Zeitplan und den Befugnissen dieser Person ab.

Welche Sicherheitseinstellungen verwaltet Managed Hosting in deinem Auftrag?

WordPress integrieren Sicherheitsmaßnahmen nahtlos in ihr Modell. WP Engine bietet zum Beispiel eine verwaltete Firewall, die gängige Angriffe abwehrt, automatische Plugin-Updates sowie eine Rund-um-die-Uhr-Überwachung mit schneller Reaktion auf Bedrohungen und Malware. Diese Schutzmaßnahmen sind echt und für viele Websites völlig ausreichend.

Die Einschränkung besteht darin, dass die Sicherheitsentscheidungen vom Anbieter getroffen werden müssen, nicht vom Kunden.

WP Engine verwaltet bestimmte Einstellungen streng, um die Serverleistung zu gewährleisten oder aus Sicherheitsgründen. In der Dokumentation ihrer Plattform ist eine Reihe von Konfigurationen aufgeführt, die Kunden nicht eigenständig ändern können. Für einige davon muss eine Supportanfrage gestellt werden, wobei kein Zeitrahmen garantiert wird. So können beispielsweise Revisions in WordPress nicht in den Dateien wp-config.php oder php.ini aktiviert werden, da diese Einstellungen auf Serverebene überschrieben werden.

Was TLS betrifft, hat WP Engine TLS 1.0 und 1.1 plattformweit als veraltet eingestuft, und Kunden haben keine Möglichkeit, die Umstellung aufzuschieben oder eine Version unterhalb von TLS 1.2 zu wählen. Das entspricht bewährten Sicherheitspraktiken und behebt diese konkreten Probleme. Das Gegenteil trifft aber auch zu: Kunden können die TLS-Standardeinstellungen der Plattform nicht überschreiten, keine spezifischen Verschlüsselungssuiten auswählen und keine Entscheidungen zur Zertifikatsbereitstellung treffen, die von den Vorgaben der Plattform abweichen.

Bei HTTP-Sicherheits-Headers ist besondere Vorsicht geboten. Das Hinzufügen von Sicherheits-Headers innerhalb von WordPress über ein Plugin oder einen benutzerdefinierten Eintrag in der functions.php – ist zwar möglich, erfolgt jedoch auf Anwendungsebene. Ein Sicherheitsscanner, der auf Netzwerkebene überprüft, was der Server sendet, erkennt diese Header möglicherweise nicht auf dieselbe Weise wie Header, die in der Webserver-Konfiguration festgelegt wurden. HTTP-Sicherheits-Headers funktionieren am besten, wenn sie auf Webserver-Ebene gesetzt werden, also auf deinem Hosting-Account. Auf einer verwalteten Plattform liegt es in der Entscheidung des Anbieters, ob diese Header auf Serverebene gesetzt werden oder wie die CDN-Ebene zwischen dem Kunden und dem Ursprungsserver damit umgeht. Im Advanced Network von WP Engine wird der Datenverkehr Cloudflare DNS-Ebene über Cloudflare geleitet. Welche Header Cloudflare während der Übertragung Cloudflare , entfernt oder ändert, hängt davon ab, wie WP Engine diese Integration konfiguriert hat, und nicht davon, was du in eine .htaccess-Datei einträgst.

Warum ist es so schwierig, die Content-Security-Richtlinie bei Managed Hosting anzupassen?

Die Content Security Policy ist der Header, dessen Fehlen bei externen Sicherheitsaudits am häufigsten beanstandet wird. Die CSP teilt dem Browser genau mit, welche Quellen für Skripte, Styles, Bilder und andere Assets auf deinen Seiten geladen werden dürfen. Eine fehlende CSP ist ein häufiger Befund bei SecurityScorecard, SecurityHeaders.io und den meisten PCI-Compliance-Scans.

Die korrekte Implementierung von CSP erfordert zwei Dinge: eine definierte Richtlinie, die auf die spezifischen Ressourcenabhängigkeiten deiner Website zugeschnitten ist, und die zuverlässige Übermittlung dieses Richtlinien-Headers mit jeder Antwort. Der zweite Punkt ist in verwalteten Umgebungen das Problem.

Auf einem Apache-Server kannst du eine CSP direkt in deine .htaccess-Datei einfügen, wodurch die Richtlinie siteweit gilt und sicherer ist als die Verwendung von Meta-Tags. Auf einem Nginx fügst du sie in den Serverblock der Virtual-Host-Konfiguration ein. Beide Methoden setzen voraus, dass du die Serverkonfigurationsdateien bearbeiten und neu laden kannst. Auf einer verwalteten WordPress gehören diese Dateien dem Anbieter.

Plugins können CSP-Header über PHPs header() Funktion, doch dies birgt mehrere Fehlerquellen: Caching-Ebenen können von PHP generierte Header unterdrücken oder überschreiben, CDN-Edge-Knoten leiten sie möglicherweise nicht konsistent weiter, und jede Änderung der CDN-Konfiguration durch den Anbieter kann die Bereitstellung unbemerkt unterbrechen. In Umgebungen, in denen du über cPanel, FTP oder SSH keinen Zugriff auf die Server-Rohdateien hast, ist der Einsatz eines Plugins erforderlich, was mit einem höheren Implementierungsrisiko verbunden ist.

Das Ergebnis ist eine Situation, in der du die Arbeit zur Implementierung eines CSP erledigen, in deinem Browser überprüfen kannst, ob es „funktioniert“, ein Support-Ticket zur Konfiguration auf Serverebene einreichen kannst und der Header dennoch bei einem automatisierten Scan nicht immer angezeigt wird.

Wie verändert ein dedizierter Server deine Möglichkeiten zur Sicherheitskonfiguration?

Root-Zugriff bedeutet, dass du die Konfiguration selbst verwaltest. Jede der oben beschriebenen Sicherheitsentscheidungen wird zu einer Konfigurationsdatei, die du bearbeiten, neu laden und überprüfen kannst.

Um TLS 1.0 und 1.1 auf einem Apache-Server zu deaktivieren, musst du eine Zeile in die SSL-Konfiguration einfügen und den Dienst neu starten. Das Hinzufügen von Einschränkungen für Verschlüsselungssuiten – also das Entfernen von RC4, 3DES und Export-Verschlüsselungen – erfordert etwa fünf zusätzliche Zeilen. Diese Änderungen werden sofort wirksam und können mit Tools wie openssl s_client oder Qualys SSL Labs vorher und nachher.

Um HSTS zu jeder Antwort hinzuzufügen, reicht eine einzige Anweisung im Virtual-Host-Block:

Setze im Header immer „Strict-Transport-Security“ mit den Werten „max-age=31536000; includeSubDomains“

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CSP wird auf dieselbe Weise konfiguriert und auf jede Antwort vom Ursprungsserver angewendet, ohne über ein Anwendungs-Plugin weitergeleitet zu werden. X-Content-Type-Options, X-Frame-Options und Referrer-Policy sind drei zusätzliche Zeilen.

Die Zertifikatskonfiguration – OCSP-Stapling zur Unterstützung von Sperrungen, Auswahl eines Signaturalgorithmus, Festlegen von Bereitstellungsoptionen – wird bei der Bereitstellung vorgenommen und kann jederzeit aktualisiert werden, ohne dass du dich an einen Anbieter wenden musst.

Du bestimmst selbst, wie oft du Updates installierst – mit einer wichtigen Einschränkung: Auf einem nicht verwalteten Server liegt die Verantwortung dafür auch bei dir. Bei den verwalteten dedizierten Servern InMotion Hostingkümmert sich InMotion um die Software und Infrastruktur auf Serverebene, während die Kunden Root-Zugriff behalten, um ihre eigenen Änderungen an der Sicherheitskonfiguration vorzunehmen.

Dedizierter Server vs. Managed Shared Hosting: Welche Sicherheitseinstellungen kannst du selbst steuern?

Lass uns vergleichen, was die einzelnen Umgebungen bieten.

Die rechte Spalte bedeutet nicht „keine Unterstützung“. Es bedeutet, dass die Entscheidungen bei dir liegen, wobei dir bei Bedarf fachkundige Hilfe zur Verfügung steht.

Deckt die Sicherheitszertifizierung deines Anbieters deine spezifischen Anforderungen ab?

Das ist die Nuance, die in Vergleichsartikeln oft untergeht. Verwaltete Plattformen wie WP Engine verfügen über seriöse und fundierte Sicherheitsmaßnahmen. WP Engine ist nach SOC 2 Typ II und ISO 27001:2022 zertifiziert und beschränkt den Schreibzugriff auf Festplatten auf Prozessebene, um die Umgebung gegen das Einschleusen von Malware über anfällige Themes oder Plugins abzusichern.

Diese Zertifizierungen spiegeln die Sicherheitslage des Anbieters wider. Sie belegen, wie der Anbieter die gemeinsam genutzte Infrastruktur schützt. Was sie jedoch nicht berücksichtigen, ist die Frage, ob die externe Angriffsfläche deines Unternehmens – also die mit deinem Unternehmen verbundenen IP-Adressen, Domainnamen und Server – den spezifischen Anforderungen deiner Kunden, Prüfer oder Sicherheitsbewertungsplattformen an die Sicherheitskonfiguration entspricht.

Ein Unternehmenskunde, der ein Programm zur Lieferantenrisikobewertung nutzt, prüft dein SecurityScorecard-Rating und nicht den SOC-2-Bericht deines Anbieters. Ein PCI-QSA, der deine Umgebung bewertet, überprüft die TLS-Konfiguration auf dem Server, über den Karteninhaberdaten übertragen werden, und nicht die allgemeine Compliance-Zertifizierung des Hosts. Das sind die Konfigurationen, die du im Griff haben musst.

Wer braucht eigentlich aus Sicherheitsgründen einen dedizierten Server?

Das gilt nicht für jede Website. Managed Shared Hosting ist für Websites geeignet und sicher genug, die keinen externen Sicherheitsprüfungen unterliegen und keine sensiblen Daten im Rahmen von Compliance-Vorgaben verarbeiten.

Ein dedizierter Server ist sinnvoll, wenn:

• Deine SecurityScorecard oder ein ähnliches Sicherheitsbewertungstool zeigt Konfigurationsprobleme an, deren Behebung Zugriff auf Serverebene erfordert
• Ein Unternehmenskunde oder ein Beschaffungsteam verlangt Nachweise über deine konkreten Sicherheitskonfigurationen – nicht nur die Zertifizierung eines Anbieters
• Du arbeitest daran, die PCI-DSS-Konformität zu erreichen, und musst die TLS-Konfiguration, die Netzwerksegmentierung und den Patch-Zeitplan auf dem Server, der Transaktionen verarbeitet, kontrollieren
• In deinem Unternehmen wurde ein Penetrationstest oder eine Sicherheitsüberprüfung durchgeführt, bei der Probleme auf Serverebene festgestellt wurden
• Du verwaltest mehrere Kundenstandorte und bist für die Sicherheit jedes einzelnen Standorts verantwortlich

Agenturen, die für die Sicherheit der Standorte ihrer Kunden haften – sei es vertraglich oder einfach nur aus Reputationsgründen –, stellen regelmäßig fest, dass in gemeinsam genutzten, verwalteten Umgebungen Sicherheitsentscheidungen genau dann außerhalb ihrer Kontrolle liegen, wenn diese Entscheidungen am wichtigsten sind.

„Beim Managed Shared Hosting bestimmt der Hosting-Anbieter die Serverkonfiguration. Auf einem dedizierten Server mit den Professional Services des SysAdmin-Teams von InMotion Solutions entscheidest du das.“ – Parag Parikh, Manager bei InMotion Solutions

Was solltest du klären, bevor du auf einen dedizierten Server umsteigst?

Der Umstieg auf einen dedizierten Server ist eine wichtige Infrastrukturentscheidung. Bevor du diesen Schritt wagst, solltest du dir über ein paar Dinge im Klaren sein:

Welche konkreten Befunde müssen behoben werden? Nicht alle Befunde von SecurityScorecard erfordern einen eigenen Server. Einige lassen sich durch CDN-Konfiguration, DNS-Aktualisierungen oder den Wechsel des SSL-Anbieters beheben. Finde heraus, welche Befunde konkret Zugriff auf die Serverkonfiguration erfordern.

Wer kümmert sich um die Serverkonfiguration? Root-Zugriff bringt Verantwortung mit sich. Wenn du keine internen Systemadministratoren hast, solltest du die Kosten für Managed Support oder professionelle Dienstleistungen einkalkulieren.

Was sehen deine Compliance-Anforderungen konkret vor? PCI DSS, SOC 2 und HIPAA haben jeweils spezifische Geltungsbereichsdefinitionen. Vergewissere dich, dass die von dir benötigte Änderung der Serverkonfiguration in den Geltungsbereich fällt und die Audit-Anforderungen erfüllt.

Die dedizierten Server InMotion Hostingbieten vollen Root-Zugriff und cPanel sowie Support für die verwaltete Infrastruktur durch das InMotion-Team. Das „Premier Care“-Paket umfasst zusätzlich den Monarx-Malware-Schutz, 500 GB Backup-Speicherplatz und monatliche Beratungsstunden mit InMotion Solutions – dem hauseigenen Systemadministrationsteam, das dir bei der Sicherheitsoptimierung, der TLS-Konfiguration und der compliance-orientierten Serverkonfiguration zur Seite steht. Entdecke die Dedicated-Server-Pakete oder kontaktiere unser Team, um deine spezifischen Sicherheitsanforderungen zu besprechen.

Alle VPS- oder dedizierten Server können mit unserer Unterstützung für Kunden, die mit uns und ihrer PCI-Zertifizierungsstelle zusammenarbeiten, PCI-DSS-konform gemacht werden.