Kort gezegd: Of managed hosting of een rootserver veiliger is, wordt minder door de techniek bepaald dan door de vraag wie updates betrouwbaar installeert. Bij managed hosting doet de aanbieder dat in de afgesproken omvang, bij de eigen rootserver uw team of een dienstverlener. Voor bedrijven zonder serverkennis is managed hosting meestal de veiligere keuze. Wie controle nodig heeft en een beherend team heeft, kan met een eigen server even veilig rijden.
Wat PHP2Shell over bedrijfsmodellen heeft onthuld
De situatie in oktober 2026 was een praktijktest. Op 21 oktober om 16.00 uur Duitse tijd verschenen de patches, het BSI (Duitse federale dienst voor informatiebeveiliging) adviseerde de directe update. Wie een managed abonnement had, moest vooral één ding doen: bij de aanbieder navragen en zich patchstatus en herstart laten bevestigen. Wie een eigen server beheerde, moest zelf handelen, vaak 's avonds of in het weekend.
Beide hadden valkuilen. Bij managed klanten kon het paneel een oud versienummer blijven tonen, bijvoorbeeld 8.2.34, hoewel een backport was geïnstalleerd; zonder bevestiging van de aanbieder bleef de stand dan onduidelijk. Beheerders van eigen servers stonden voor de vraag of ze de juiste pakketten hadden en alle PHP-processen waren herstart. De basisverantwoordelijkheden beschrijven Managed server: verantwoordelijkheid vastleggen en Rootserver en vServer zelf beveiligen. Hier gaat het om de keuze tussen beide.
Managed hosting of rootserver: de vergelijking
| Criterium | Managed hosting | Eigen rootserver of vServer |
|---|---|---|
| Wie patcht PHP en het besturingssysteem? | De aanbieder, in de afgesproken omvang | U of uw dienstverlener |
| Snelheid bij kritieke lekken | Afhankelijk van de processen van de aanbieder | Afhankelijk van uw beschikbaarheid |
| Controle over configuratie | Beperkt, vaak alleen via paneel of op verzoek | Volledig |
| Overbruggende maatregelen op serverniveau | Alleen via de aanbieder mogelijk | Zelf uit te voeren |
| Bewijs van de patchstatus | Bevestiging van de aanbieder nodig | Zelf te controleren via de pakket-changelog |
| Benodigde vakkennis in huis | Laag voor de server, toepassing blijft bij u | Hoog, duurzaam |
| Bijzondere eisen, oude software | Vaak niet mogelijk | Mogelijk, maar eigen risico |
| Sporenonderzoek na incidenten | Logs en toegang alleen in overleg | Volledige toegang, maar eigen expertise nodig |
| Afhankelijkheid | Van de aanbieder en zijn contract | Van uw team en zijn bereikbaarheid |
De tabel laat zien: beide modellen verschuiven verantwoordelijkheid, geen van beide neemt haar weg. Bij managed hosting verlegt u het serveronderhoud, maar behoudt u de plicht na te vragen en uw toepassing te beveiligen. Bij de eigen server behoudt u alles, inclusief de weekenden.
Vijf vragen bij de keuze van het bedrijfsmodel
- Is er in huis een persoon met serverkennis die ook bij ziekte of vakantie wordt vervangen? Zo nee, dan is een eigen server zonder externe begeleiding riskant.
- Heeft uw toepassing speciale configuraties, eigen diensten of oude software nodig? Zo ja, dan stuit managed hosting vaak op grenzen.
- Hoe kritiek is de website voor omzet of bedrijfsvoering? Hoe kritieker, hoe belangrijker duidelijke toezeggingen over updates en bereikbaarheid zijn, in welk model ook.
- Welke gegevens verwerkt u? Bij gevoelige gegevens tellen bewijs en logtoegang. Stel vast of uw aanbieder in een noodgeval logs verstrekt.
- Hoeveel websites beheert u? Veel vergelijkbare sites zijn op een eigen, goed beheerde server efficiënt te bundelen. Afzonderlijke sites zijn bij managed hosting vaak beter af.
De mengvormen die zich bewijzen
Tussen de twee polen zijn er modellen die in de praktijk vaak het best werken. De meest voorkomende is de eigen server met externe begeleiding: u behoudt de controle over configuratie en gegevens, een dienstverlener neemt volgens vaste afspraken updates, bewaking en noodreactie over.
Een tweede variant is managed hosting met aanvullende beveiligingscontrole. De aanbieder onderhoudt de server, een onafhankelijke dienstverlener controleert regelmatig toepassing, plug-ins en sporen die buiten de managed omvang vallen. Voor eenvoudige websites blijft ten slotte shared hosting een verstandige oplossing, als de hoster betrouwbaar patcht en de website geen bijzondere eisen heeft.
Belangrijk in alle modellen: geautomatiseerde beveiligingsupdates voor het besturingssysteem, regelmatig geteste back-ups en tweefactorauthenticatie voor alle toegangen zijn basisvoorwaarden die los van het model gelden. Wie op een eigen server automatische updates inricht, moet toch controleren dat PHP-processen daarna worden herstart; waarom dat beslissend is, legt Na de update: PHP-FPM en alle workers herstarten uit.
Geen enkel bedrijfsmodel neemt u de verantwoordelijkheid voor uw toepassing en uw gegevens af. Ook bij managed hosting moeten CMS, plug-ins en beheerdersaccounts worden onderhouden en datalekken door u worden beoordeeld.
Wanneer een wissel zinvol is en wanneer niet
Een wissel loont als PHP2Shell een structurele zwakte heeft laten zien: uw team kon de eigen server niet tijdig patchen, of uw managed aanbieder reageerde niet op vragen en leverde geen bewijs. Waar u bij een wissel van aanbieder op moet letten, beschrijft Van hoster wisselen na een beveiligingsincident.
Geen goede reden voor een wissel is daarentegen een afzonderlijke gebeurtenis die met betere afspraken oplosbaar was. Vaak volstaat het het bestaande contract aan te vullen met regels over beveiligingsupdates, herstarts en informatie bij kritieke lekken.
Bedenk ook het tijdstip. Een verhuizing midden in een acute situatie bindt precies de krachten die op dat moment voor patches en sporenonderzoek nodig zijn. Beter is het eerst de huidige server te beveiligen en de wissel daarna rustig te plannen, met een schone wederopbouw in plaats van een kopie van het oude systeem.
Hoe helpt PHP SOS concreet?
- Wij vergelijken uw huidige model met uw werkelijke eisen en laten zien waar verantwoordelijkheid onduidelijk is.
- Wij toetsen dienstomschrijvingen van managed aanbieders op de punten die in een noodgeval tellen.
- Voor eigen servers nemen wij updates, verharding en bewaking over in het kader van een beveiligingsonderhoudscontract.
- Bij een wissel begeleiden wij de verhuizing, zodat geen oude toegangen of ongecontroleerde gegevens meeverhuizen.
Conclusie
Managed hosting is de veiligere keuze voor bedrijven zonder serverkennis, de eigen server de flexibelere voor teams met vakkennis en bereidheid. Mengvormen waarin duidelijk is geregeld wie patcht, wie herstart en wie in een noodgeval reageert, scoren vaak het best.
Veelgestelde vragen
Is managed hosting in principe veiliger dan een rootserver?
Niet in principe. Managed hosting is veiliger als de aanbieder updates betrouwbaar installeert en u zelf weinig serverkennis hebt. Een goed beheerde eigen server kan even veilig zijn, maar vraagt duurzaam tijd en vakkennis.
Wie is bij een rootserver verantwoordelijk voor PHP-updates?
In de regel u zelf. De exploitant van het rekencentrum zorgt meestal alleen voor hardware, netwerk en virtualisatie. Besturingssysteem, PHP, webserver en toepassing liggen bij u of uw dienstverlener.
Kan ik bij managed hosting eigen PHP-instellingen configureren?
Vaak maar beperkt. Veel aanbieders staan wijzigingen toe via een paneel of op verzoek. Voor overbruggende maatregelen zoals bij PHP2Shell moeten sommige instellingen serverbreed worden gezet; dat kan dan alleen via de aanbieder.
Wat met shared hosting?
Shared hosting is de eenvoudigste vorm van beheerde hosting. De aanbieder onderhoudt het systeem voor veel klanten tegelijk. U hebt nauwelijks invloed op PHP-versie en configuratie, maar hoeft zich er ook nauwelijks mee bezig te houden.
Loont een wissel van bedrijfsmodel na PHP2Shell?
Alleen als de situatie een echte zwakte heeft laten zien, bijvoorbeeld dat niemand de eigen server tijdig kon patchen. Een wissel op gevoel lost zelden het eigenlijke probleem op.