Kort gezegd: Bij een managed server neemt de aanbieder een deel van de beveiliging over, doorgaans besturingssysteem, PHP-pakketten en standaarddiensten. Toepassing, plug-ins, toegangen en de verantwoordelijkheid vanuit de gegevensbescherming blijven meestal bij u. Na PHP2Shell moet u beide schriftelijk vastleggen: wat heeft de aanbieder gedaan, en wat ligt nog bij u?
Wat „managed” betekent en wat niet
De term is niet beschermd. De ene aanbieder verstaat eronder misschien alleen het doorvoeren van updates van het besturingssysteem, een andere verzorgt ook webserver, PHP, database en back-ups. Sommige abonnementen bevatten bewaking rond de klok, andere alleen een contactpersoon tijdens kantooruren.
Juist bij een situatie als PHP2Shell blijkt hoe nauwkeurig de dienstbeschrijving is. De twee kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 zitten in PHP zelf. Of uw aanbieder PHP als onderdeel van zijn platform onderhoudt of dat PHP als „uw software” geldt, staat in het contract. Ga er niet van uit dat er wel iemand voor zorgt.
Managed server beveiliging: typische taakverdeling
De volgende tabel toont een gangbare verdeling. Ze vervangt niet de blik in uw contract, maar helpt de juiste vragen te stellen.
| Onderdeel | Meestal bij de aanbieder | Meestal bij u |
|---|---|---|
| Hardware, netwerk, virtualisatie | ja | nee |
| Updates van het besturingssysteem | ja | nee |
| PHP-pakketten uit het platform | vaak | als zelf geïnstalleerd |
| Herstart van PHP-FPM en webserver | vaak | bij eigen diensten |
| Serverbrede PHP-configuratie | vaak | bij speciale wensen |
| CMS, webwinkel, plug-ins, eigen code | nee | ja |
| Beheerdersaccounts van de toepassing | nee | ja |
| Back-ups | vaak | controle van het herstel |
| Beoordeling en melding van datalekken | nee | ja |
| Bewaking op aanvallen | afhankelijk van abonnement | afhankelijk van abonnement |
Onduidelijke velden vormen het eigenlijke risico. Waar u „afhankelijk van abonnement” of „vaak” zou moeten invullen, ontbreekt een regeling.
Welke vragen u nu moet stellen
Stuur uw aanbieder een korte, zakelijke vraag. Vraag om een antwoord in tekstvorm, zodat u het later kunt voorleggen. Deze punten horen erin:
- Welke PHP-versies draaien op onze server, en zijn ze beveiligd tegen CVE-2026-109618 en CVE-2026-109619?
- Sinds wanneer geldt dat, en zijn daarna alle PHP-processen en de webserver herstart?
- Is de correctie als backport doorgevoerd? Zo ja, welke pakketversie bewijst dat?
- Waren er aanwijzingen voor aanvalspogingen of opvallende processen op onze server?
- Worden de logs van de webserver vanaf 20-10-2026 bewaard, en hoe krijgen wij ze?
Een uitgewerkt sjabloon vindt u onder Hostingprovider naar de patchstatus vragen. Het versienummer in het klantmenu is geen bewijs: bij backports blijft het vaak ongewijzigd, bijvoorbeeld bij 8.2.34.
Ook als de aanbieder PHP heeft gepatcht, moet uw toepassing nog worden gecontroleerd. Een patch verwijdert geen schadelijke software die vóór de update is ingebracht en bewijst niet dat er niets is gebeurd.
Wat bij u blijft
Uw deel omvat vooral de toepassing. Controleer CMS, webwinkel en plug-ins op actuele versies, verwijder extensies die niet meer worden gebruikt en controleer de lijst met beheerders. Let op nieuwe bestanden in uploadmappen, vreemde doorverwijzingen en ongebruikelijke geplande taken in de toepassing.
Daar komt de juridische kant bij. Komen bij een incident persoonsgegevens in verkeerde handen, dan is in de regel uw bedrijf als verwerkingsverantwoordelijke meldplichtig, niet de aanbieder. Die moet u als verwerker onverwijld informeren. De hoofdlijnen legt Meldplicht AVG: 72 uur uit. Dit is algemene informatie, geen juridisch advies; het individuele geval beoordelen functionarissen voor gegevensbescherming of advocaten.
Een ander punt wordt vaak over het hoofd gezien: software die u of uw bureau zelf op de managed server hebt geïnstalleerd, bijvoorbeeld een extra PHP-versie uit een externe bron, een container of een hulpprogramma, valt meestal niet onder het onderhoud van de aanbieder. Vraag daarom ook of de aanbieder weet wat er naast de standaarduitrusting draait. En zoek uit wie bij vermoeden het onderzoek overneemt. Veel aanbieders herstellen het platform, maar onderzoeken niet of en welke gegevens getroffen waren. Precies dat antwoord hebt u echter nodig voor de beoordeling van mogelijke meldplichten.
Contracten voor de toekomst verbeteren
Gebruik de situatie om de taakverdeling vast te leggen. Zinvol zijn regelingen over beveiligingsupdates inclusief herstart, over informatie bij kritieke kwetsbaarheden, over bewaring en verstrekking van logs en over ondersteuning bij incidenten. Vraag ook of de aanbieder u actief op de hoogte stelt of dat u zelf moet navragen.
Een eigen server zonder beheer is het alternatief, maar verschuift het volledige werk naar u. Wat dat betekent, beschrijft Rootserver en vServer zelf beveiligen.
Hoe helpt PHP SOS concreet?
- Wij lezen uw dienstbeschrijving en stellen een taakmatrix op die hiaten zichtbaar maakt.
- Wij formuleren de technische vragen aan uw aanbieder en beoordelen de antwoorden.
- Wij controleren het toepassingsdeel dat bij u ligt op sporen en verouderde onderdelen.
- Wat de aanbieder niet dekt, nemen we op verzoek over via een beveiligingsonderhoudscontract of vullen we aan met security monitoring.
Veelgestelde vragen
Is bij een managed server automatisch alles beveiligd?
Nee. Managed betekent dat de aanbieder bepaalde, contractueel vastgelegde taken overneemt, meestal besturingssysteem en standaarddiensten. Toepassing, plug-ins, toegangen en eigen software blijven vaak bij u.
Waar staat waarvoor mijn aanbieder verantwoordelijk is?
In de dienstbeschrijving en de contractvoorwaarden, vaak ook in een document over de taakverdeling. Bij persoonsgegevens komt de verwerkersovereenkomst erbij. Ontbreekt een duidelijke regeling voor beveiligingsupdates, vraag er dan schriftelijk naar.
Moet ik ondanks een managed server zelf iets doen vanwege PHP2Shell?
Ja. Vraag een bevestiging op dat alle PHP-versies zijn gepatcht en de processen zijn herstart. Controleer bovendien uw toepassing op sporen en zoek uit of er een meldplicht bestaat.
Wie meldt een datalek als de hostingprovider getroffen was?
Meldplichtig tegenover de toezichthouder is in de regel de verwerkingsverantwoordelijke, dus uw bedrijf. De hostingprovider moet u als verwerker onverwijld informeren. Laat het individuele geval beoordelen door uw functionaris voor gegevensbescherming.