Om sites van klanten op schaal te beheren, moet je nadenken over de beveiliging van de infrastructuur op een manier die verder gaat dan alleen het installeren van beveiligingsplugins of het afdwingen van sterke wachtwoorden.
Wanneer je tientallen of honderden WordPress sites host, wordt de hostingarchitectuur een beveiligingsoverweging die je hele portfolio kan beschermen óf in gevaar kan brengen.
Traditionele gedeelde hosting houdt de kosten laag, maar het betekent ook dat sites hetzelfde bestandssysteem, dezelfde procesruimte en dezelfde netwerkstack delen. Als dus één site op een gedeelde server wordt aangetast, kan de malware zich verspreiden naar andere sites.
De verborgen beveiligingsrisico’s van gedeelde hostingomgevingen
Elke site op een gedeelde hostingserver gebruikt een deel van de CPU, RAM en opslagruimte van de server. Dit is logisch voor hostingproviders vanuit kostenoogpunt en houdt de prijzen voor klanten toegankelijk.
Vanuit beveiligingsperspectief zijn er echter kwetsbaarheden die toenemen met het aantal sites dat je beheert. Het kernprobleem draait om het delen van resources. Bestandspermissies en gebruikersisolatie kunnen enige bescherming bieden, maar dit zijn controles op softwareniveau die kunnen worden misbruikt. Per slot van rekening blijven phishing-aanvallen, malware en ransomware de grootste bedreigingen voor elke site.
Inzicht in ‘laterale verspreiding’ en ‘kruisbesmetting’ kan helpen om de risico’s te verduidelijken:
- Laterale verspreiding verwijst naar malware die zich verplaatst van één aangetast systeem naar andere systemen binnen hetzelfde netwerk of dezelfde omgeving.
- Er is sprake van kruisbesmetting wanneer een beveiligingsprobleem op één site zich verspreidt naar andere sites die dezelfde infrastructuur delen.
Als je portfolio’s van klanten beheert, kan het aantrekkelijk zijn om geld te besparen door gebruik te maken van gedeelde hosting. Een verouderde plugin of een zwak wachtwoord van één klant kan echter een bedreiging vormen voor je hele hostinginstallatie.
Als je de tijd meerekent die je kwijt bent aan het controleren op bedreigingen en het herstellen van beveiligingsincidenten op meerdere sites, daalt de waarde.
Hoe malware zich verspreidt tussen sites op gedeelde servers
De precieze aard van cross-site besmetting hangt af van hoe de hostingprovider gebruikersscheiding en bestandsrechten implementeert. Toch blijft het fundamentele probleem consistent voor de meeste gedeelde hostingsetups: deze omgevingen creëren aanvalskwetsbaarheden waar gecompromitteerde accounts toegang kunnen krijgen tot bestanden van andere gebruikers via verkeerd geconfigureerde machtigingen of kwetsbare scripts.
De routes voor cross-site infectie zijn onder andere:
- PHP-scripts lezen bestanden van andere gebruikersmappen wanneer machtigingen verkeerd zijn geconfigureerd.
- Gedeelde tijdelijke mappen zorgen ervoor dat malware zich tussen sites kan verspreiden.
- Kwetsbaarheden op serverniveau zorgen ervoor dat processen van de ene site andere kunnen beïnvloeden.
- Gecompromitteerde gebruikersaccounts krijgen toegang tot naburige mappen via gedeelde resourcepools.
Kinsta-klant Bookswarm ontdekte dit probleem tijdens het beheren van honderden clientsites op een gedeeld hostingplatform. Ze ontdekten dat de gemengde serveropstelling beveiligingsproblemen veroorzaakte naast eventuele compromissen met individuele sites. De architectuur betekende dat “een aanval op de ene een aanval op de andere was”
Dit creëert ook een operationele last omdat je voortdurend toezicht moet houden om compromissen op te sporen voordat ze zich verspreiden. Als één site tekenen van infectie vertoont, moet je elke andere site op dezelfde server controleren. Incident response wordt een portfolio-brede oefening in plaats van een geïsoleerde fix.
Het probleem van vervuiling door blokkeerlijsten
Gedeelde IP-adressen creëren een andere vorm van risico bij traditionele gedeelde hosting. Als meerdere sites hetzelfde IP-adres delen, delen ze ook dezelfde reputatie in de ogen van e-mailproviders, zoekmachines en beveiligingsdiensten.
Omdat één compromis ertoe kan leiden dat het hele IP-adres op een blokkeerlijst komt te staan, heeft elke site op dat IP adres te maken met verschillende problemen:
- De bezorgbaarheid van e-mail daalt in je hele portfolio wanneer één gecompromitteerde site spamfilters zoals Spamhaus activeert.
- Zoekmachines markeren het gedeelde IP als verdacht, wat een negatieve invloed heeft op de rankings van alle geassocieerde sites.
- Beveiligingsdiensten en firewalls blokkeren verzoeken vanaf het IP, waardoor de functionaliteit voor sites die niets te maken hebben met de oorspronkelijke aantasting wordt onderbroken.
- Sites van klanten verliezen vertrouwensindicatoren wanneer beveiligingstools het gedeelde IP associëren met kwaadaardige activiteiten.
Het herstelproces van een IP op een blokkeerlijst vereist een gecoördineerde inspanning met je hostingprovider. Je moet vaststellen welke site het probleem heeft veroorzaakt, deze opschonen en vervolgens verzoeken om verwijdering van verschillende blacklists. Tijdens dit proces blijven alle sites op het gedeelde IP de gevolgen ondervinden.
Ondertussen moet je je klanten uitleggen waarom hun e-mail niet meer werkte of waarom hun site werd gemarkeerd, ook al volgden ze optimale WordPress beveiligingspraktijken. De hoofdoorzaak is terug te voeren op infrastructurele beslissingen waar individuele site-eigenaren geen controle over hebben. Al dit doorlopende onderhoud neemt tijd weg van het werk van klanten en ontwikkelingsprojecten.
Isolatie op containerniveau voor WordPress hosting
Site-isolatie pakt veel van de fundamentele problemen van gedeelde hosting aan. Zo draait Kinsta elke site in zijn eigen geïsoleerde container met eigen resources. Dit betekent dat elke WordPress site zijn eigen container krijgt die alles bevat wat nodig is om te draaien: Linux, NGINX, PHP en MySQL.
De isolatie gebeurt op het niveau van het besturingssysteem door middel van twee kernmechanismen:
- Namespaces geven elke container zijn eigen kijk op systeemresources. Een proces dat in de ene container draait, kan geen processen in een andere container zien of ermee communiceren.
- Controlegroepen (‘cgroups’) dwingen resourcebeperkingen af en zorgen ervoor dat elke container toegang heeft tot zijn eigen toewijzing van CPU en RAM.
Bovendien kunnen PHP threads voor je WordPress site geen processen van andere sites zien of ermee communiceren. Deze scheiding op kernelniveau voorkomt scenario’s waarbij het gecompromitteerde proces van de ene site toegang probeert te krijgen tot bronnen van andere sites.
Netwerkstacks werken ook onafhankelijk binnen elke container. Elke site heeft zijn eigen netwerkinterface en IP afhandeling. Deze isolatie strekt zich uit over de hele stack en elimineert het
“noisy neighbor” probleem waar je bij gedeelde hosting wel te maken mee heb.
Als een site een verkeerspiek ervaart of resource-intensieve operaties uitvoert, heeft dit alleen invloed op de container van die site. De dedicated resourcetoewijzing betekent dat andere sites blijven werken met hun volledige toewijzing, ongeacht wat er elders in de infrastructuur gebeurt.
Hoe containerisolatie laterale verspreiding van malware voorkomt
Wanneer een site wordt aangetast in een gecontaineriseerde omgeving, blijft de malware beperkt tot die container. Deze scheiding voorkomt dat gecompromitteerde processen toegang krijgen tot andere containers via verschillende mechanismen:
- Bestandssystemen blijven geïsoleerd, zodat malware zich niet kan verspreiden door gebruik te maken van gedeelde mappen of tijdelijke bestanden.
- Proces-namespaces voorkomen dat kwaadaardige code processen in andere containers kan scannen of ermee kan interageren.
- Netwerkisolatie beperkt het vermogen van gecompromitteerde sites om naburige sites te scannen of aan te vallen.
- Geheugenruimtes blijven volledig gescheiden, waardoor bufferoverloopaanvallen de containergrenzen niet kunnen overschrijden.
Als de site wordt gehost op Kinsta, kunnen onze monitoringsystemen de gecompromitteerde container onmiddellijk detecteren en reageren terwijl andere sites in je portfolio blijven werken.
Echte isolatie versus marketingclaims controleren
Niet alle hostingproviders implementeren containerisolatie op dezelfde manier. Sommige gebruiken de term “geïsoleerd” om zachte limieten op resourcegebruik aan te geven, terwijl er nog steeds meerdere sites in gedeelde omgevingen draaien. Begrijpen wat echte isolatie op containerniveau is, helpt je bij het evalueren van je hostingopties en het vermijden van de beveiligingsrisico’s die gepaard gaan met misleidende marketing.
Echte container-isolatie betekent dat elke site in zijn eigen besturingssysteem-namespace draait met eigen resources die niet toegankelijk zijn voor andere sites. Als je op zoek bent naar een nieuwe hostingprovider, zijn er een paar aandachtspunten:
- Krijgt elke site zijn eigen container met toegewezen CPU en RAM waar andere sites geen toegang toe hebben?
- Zijn bestandssystemen volledig gescheiden op kernelniveau met behulp van namespaces in plaats van alleen permissies op gebruikersniveau?
- Wat gebeurt er met andere sites als één container wordt gecompromitteerd of een verkeerspiek ervaart?
- Welke containerisatietechnologie gebruikt de host (LXC, LXD, Docker) en hoe wordt isolatie afgedwongen?
- Kan de host technische documentatie leveren over zijn isolatiemechanismen en architectuur?
Het verschil tussen zachte limieten en harde isolatie is van belang voor zowel de beveiliging als de prestaties. Zachte limieten beperken misschien hoeveel CPU een site kan gebruiken, maar ze werken binnen een gedeelde omgeving waar de processen van een site nog steeds kunnen communiceren met anderen. Harde isolatie met specifieke resources betekent dat elke site in een volledig gescheiden omgeving werkt waar naburige sites geen toegang hebben tot hun bronnen of beïnvloed kunnen worden door hun activiteiten.
Technische verificatiemethoden
Op zoek gaan naar technische specificaties die de containerisatietechnologie in detail beschrijven, kan je helpen te begrijpen in welke mate een host kennis heeft van de onderliggende architectuur. Aanbieders die LXC, LXD, Docker of vergelijkbare technologieën gebruiken, moeten bijvoorbeeld de specifieke isolatiemechanismen kunnen beschrijven die ze implementeren.
Compliance certificeringen zoals SOC 2 Type II en ISO 27001 geven aan dat beveiligingsprocedures zijn gecontroleerd door onafhankelijke partijen. Deze certificeringen vereisen gedocumenteerde beveiligingscontroles en regelmatige tests, wat meer zekerheid biedt dan alleen marketingclaims. Kinsta onderhoudt beide certificeringen en ondergaat regelmatig audits om te controleren of isolatiemechanismen werken zoals geadverteerd.
Als je de host in een gratis proefperiode, kun je meteen een paar verschillende manieren controleren hoe de isolatie werkt, zoals het monitoren van het resourceverbruik van meerdere sites op dezelfde server, of kijken wat er gebeurt tijdens CPU intensieve bewerkingen voor een individuele site.
Met Kinsta is dit soort praktische validatie mogelijk tijdens je eerste maand zonder kosten.
Begrijpen wat site-isolatie betekent voor je hostingstrategie
Overstappen van gedeelde hosting naar een geïsoleerde containerarchitectuur kan de fundamentele beveiligingshouding van je hele WordPress portfolio ten goede veranderen, en zelfs de manier waarop je infrastructuurbeheer op schaal benadert.
Bij meerdere klantensites op gedeelde hosting is het bijna zeker dat ten minste één site met een beveiligingsincident te maken krijgt. De echte vraag wordt of dat incident beperkt blijft tot een enkele site of dat het problemen veroorzaakt in je hele portfolio.
Voor instanties en teams die veel WordPress sites beheren, is hosting uiteindelijk een risicobeslissing op portfolioniveau. Als je op zoek bent naar een infrastructuur die speciaal is ontworpen voor het beheren van sites op schaal, dan biedt Kinsta oplossingen op maat voor bureaus en WordPress omgevingen met grote volumes.
