Per-Site CageFS: nieuwe beveiligingsarchitectuur voor shared hosting

CageFS per site scheidt afzonderlijke websites binnen een shared hosting-account strikt van elkaar en beperkt zo het risico op zijdelingse verspreiding na een inbraak. Ik licht de nieuwe beveiligingsarchitectuur toe, laat praktische toepassingsscenario’s zien en leg uit hoe je hiermee meerdere projecten veilig binnen één account kunt beheren.

Centrale punten

• Website-isolatie: Extra scheiding binnen één account vermindert zijdelingse risico’s.
• CloudLinux: Uitbreiding van het CageFS-concept op domeinniveau.
• WordPress: Meerdere instanties veilig naast elkaar laten draaien.
• Bronnen: Limieten voor CPU/RAM/I/O vormen een aanvulling op de scheiding van de bestandsweergaven.
• Praktijk: Activering per domein en een duidelijke strategie voor rechten en paden.

Wat „Per-Site CageFS“ concreet doet

De uitbreiding isoleert afzonderlijke Domeinen binnen een bestaande gebruikers-CageFS, zodat elke website alleen zijn eigen bestanden en processen kan zien. Zo voorkom ik dat een gehackt project toegang krijgt tot configuratiebestanden, uploads of sleutels van andere sites binnen hetzelfde account. Volgens CloudLinux Blog (bèta-aankondiging): Per-Site CageFS vergroot de isolatie tussen websites binnen hetzelfde gebruikersaccount en vermindert zo het risico op zijdelingse bewegingen. Voor mij ligt het voordeel voor de hand: ik kan bureauaccounts, multisite-opstellingen en testomgevingen netjes van elkaar scheiden, zonder de hostingstructuur te verstoren. Deze achtergrondinformatie geeft een snel overzicht van het principe van CageFS: CageFS-bestandssysteem, waarop de isolatie per locatie is gebaseerd.

Waarom accountisolatie alleen niet voldoende is

Eén account bundelt vaak meerdere Projecten – bijvoorbeeld twee winkels, drie blogs en een staging-omgeving. Als een exploit een kwetsbare plug-in aanvalt, kan een aanvaller zonder extra segmentatie in aangrenzende mappen gluren en daar verdere payloads plaatsen. Precies hier zorgt Per-Site CageFS ervoor dat het zicht op het bestandssysteem en de processen zodanig wordt beperkt dat elke website als in een eigen Gevangenis werkt. Vooral bij afzonderlijke WordPress-instanties met een gemeenschappelijke PHP-gebruiker ontstaat anders een risico op escalaties, dat ik met domeinisolatie wegneem. Dit beperkt de gevolgschade, vereenvoudigt forensisch onderzoek en maakt het sneller mogelijk om herstelwerkzaamheden te plannen.

Zo werkt website-isolatie technisch gezien

CloudLinux creëert via CageFS een virtuele, per gebruiker bestandssysteem; de per-site-laag breidt dit uit tot domeingrenzen. Elk geactiveerd domein krijgt een afzonderlijk zichtgebied binnen de gebruikers-CageFS, inclusief beperkende paden, eigen tijdelijke mappen en afgeschermde scriptuitvoering. Hierdoor verdwijnen vreemde wp-config.php-bestanden, uploadmappen of sleutelbestanden uit het zicht van de aangevallen website. Cronjobs, PHP en eventueel SSH-opdrachten hebben toegang tot dezelfde systeembibliotheken, maar zien alleen de toegewezen Deelverzamelingen van het bestandssysteem. Volgens de documentatie kan deze scheiding per domein worden ingeschakeld, wat mij zeer gedetailleerde controle biedt over live-, staging- en testomgevingen.

Vergelijking: accountisolatie, CageFS per site en containers

Om een weloverwogen keuze te maken, vergelijk ik drie gangbare Modellen op basis van isolatiediepte, inspanning en compatibiliteit. Accountisolatie zorgt voor scheiding tussen klanten, maar laat interne grenzen open. Per-Site CageFS dicht deze leemte op het niveau van het bestandssysteem en de processen. Containers creëren strikte grenzen, maar vergen vaak meer onderhoud en aanpassingen. Een gedegen overzicht van procesisolatie biedt dit Vergelijking tussen Chroot, CageFS en Jails.

Benadering	Scheiding tussen accounts	Scheiding tussen websites binnen het account	Compatibiliteit (PHP/CGI/SSH/Cron)	Bedrijfskosten
Accountisolatie (klassiek)	Hoog	Laag	Zeer goed	Laag
CageFS per site	Hoog	Gemiddeld tot hoog	Zeer goed	Laag tot gemiddeld
Containers per locatie	Zeer hoog	Zeer hoog	Goed tot zeer goed	Gemiddeld tot hoog

In shared-hosting-omgevingen biedt Per-Site CageFS een krachtige combinatie van gedetailleerde Scheiding en weinig aanpassingen, omdat scripts doorgaans ongewijzigd blijven draaien. Hiermee pak ik het meest voorkomende kwetsbare punt aan: meerdere onafhankelijke websites onder één gebruikersaccount.

Praktijk: meerdere WordPress-instanties veilig beheren

Ik scheid elke WordPress-instantie waarbij Domeinisolatie en stel ik per site eigen PHP-FPM-pools in, zodat logs, opcache en limieten duidelijk toewijsbaar blijven. Daarnaast definieer ik voor elke site eigen SALTs/KEYS in het wp-config.php-bestand en voorkom ik via bestandsrechten en open_basedir-equivalenten elke vorm van kruisverwijzing. Uploads sla ik strikt op binnen de betreffende documentroot en verbied ik globale gedeelde uploadmappen. Tijdens deployments houd ik tijdelijke paden binnen de site en verwijder ik build-artefacten onmiddellijk, zodat er geen onnodige kwetsbaarheden overblijven. Voor Composer- of NPM-caches gebruik ik site-lokale Lijsten, zodat er geen neveneffecten ontstaan.

Prestaties en resourcebeheer in samenspel

Per-Site CageFS heeft betrekking op de bestandsweergave; de Prestaties Ik zorg voor bescherming door limieten in te stellen voor CPU, RAM, I/O en processen op account- of poolniveau. Zo voorkom ik dat een site door defecte plug-ins te veel belasting veroorzaakt en het hele account vertraagt. In veel opstellingen zit dit verwerkt in LVE- of soortgelijke quota’s, die ik per pool of account nauwkeurig afstel. Ik koppel dit aan het afremmen van verzoeken in de webserver of WAF, zodat pieken in het verkeer op een geordende manier worden afgehandeld. Deze combinatie van isolatie en quota’s verhoogt de betrouwbaarheid van de diensten en de voorspelbaarheid Belastingverdeling.

Beveiligingsketen: Wat Per-Site CageFS niet vervangt

De afscherming verhindert dat je er doorheen kunt kijken, maar ik houd updates, Verharding van PHP en strenge wachtwoorden worden consequent gehandhaafd. Ook MFA voor beheerdersaanmeldingen, minimale bestandsrechten en uploadfilters blijven verplicht. Een WAF, rate-limits en continue logboekregistratie dekken aanvullende paden die niet worden gecontroleerd door louter bestandsseparatie. Daarnaast controleer ik regelmatig cronjobs en integratietokens, die aanvallers vaak over het hoofd zien. Meer informatie over de wisselwerking tussen scheiding van klanten en beveiligingsversterking vindt u in deze handleiding over Beveiliging van shared hosting, die deze denkrichting onderstreept.

Opzet en veelvoorkomende valkuilen

Ik activeer de domeinisolatie gericht per website en test vervolgens de SSH-, Cron- en PHP-toegang onder reële omstandigheden. Absolute paden in implementatiescripten of plug-ins kunnen problemen veroorzaken, daarom gebruik ik relatieve paden of variabelen. Ik vermijd symlinks tussen projecten, omdat ze het scheidingsprincipe ondermijnen; benodigde bibliotheken voeg ik liever per site toe aan de repository. Voor back-ups definieer ik afzonderlijke archieven en sla ik logbestanden per domein op, zodat herstel en forensisch onderzoek overzichtelijk blijven. Wat betreft rechten heeft 640 voor bestanden en 750 voor mappen zich bewezen, plus Eigenaar afgestemd op de betreffende PHP-pool.

Kosten-batenafweging voor bureaus en freelancers

Ik weeg de winst aan veiligheid af tegen de administratieve tijd en de potentiële uitvalkosten die een incident zou veroorzaken, en kom uit op Euro-basis. Slechts een paar uur incidentrespons kost vaak al aanzienlijk meer dan een kleine maandelijkse meerprijs voor betere isolatie. Voor bureaurekeningen met meerdere klantprojecten vermindert de segmentatie het aansprakelijkheids- en reputatierisico merkbaar. Ook verlopen back-up- en herstelprocessen overzichtelijker, omdat ik afzonderlijke sites doelgericht kan herstellen. Al met al zorgt CageFS per site voor een betrouwbaardere Operationeel beheer met voorspelbare processen.

Checklist: Wanneer CageFS per site verplicht wordt

Ik schakel domeinisolatie in zodra er meerdere Installaties in één account draaien en verschillende updatecycli hebben. Ook belangrijk: afzonderlijke projectteams of externe beheerdersaccounts, die het risico op onbedoelde ingrepen vergroten. Grote uploadvolumes, bestandsconverters of beeldverwerking rechtvaardigen de scheiding bovendien, omdat hier vaak kwetsbare punten ontstaan. Verschillende compliance-eisen (bijv. klanten, markten, gegevensbescherming) pleiten eveneens voor fijnere segmenten. Wie staging, testen en live parallel uitvoert, profiteert van duidelijk gescheiden foutdomeinen en een heldere Forensisch.

Voorwaarden en compatibiliteit in de praktijk

Voordat ik Per-Site CageFS in productie neem, controleer ik de runtime-omgeving: de gebruikte PHP-handler (bijvoorbeeld PHP-FPM, lsapi), de actieve webserver, de beschikbare panel-integratie en de manier waarop cronjobs en SSH-sessies worden beheerd. In typische shared-omgevingen blijven applicaties zonder wijzigingen in de code gewoon draaien. Ik zorg ervoor dat er per domein een eigen documentroot bestaat, dat de paden eenduidig zijn (bijv. /home/user/sites/project-a/public) en dat er per site een eigen PHP-FPM-pool wordt gebruikt. Voor cronjobs gebruik ik per domein eigen crontabs of – waar het paneel dit bundelt – duidelijke prefixen en logpaden, zodat taken binnen hun Gevangenissen werken.

Databases, caches en sessies duidelijk van elkaar scheiden

De bestandsweergave is slechts een onderdeel. Ik trek deze scheiding door tot aan de database en de caches. Per website maak ik een eigen database aan en een eigen databasegebruiker met minimale rechten. Voor object- of paginacaches (bijv. Redis, Memcached) gebruik ik per site afzonderlijke instanties of op zijn minst sleutelprefixen en speciale databases/namespaces. PHP-sessies worden opgeslagen in site-specifieke paden; ik stel de `session.save_path` per FPM-pool afzonderlijk in. Als ik een centrale wachtrij of een zoekbackend gebruik, scheid ik indexen en onderwerpen per site. Dit principe van „scheiding tot aan de laatste mijl“ voorkomt dat incidenten zich via nevenstelsels verspreiden.

CI/CD en implementaties in isolatie

In build-pipelines maak ik isolatie de norm: per site is er een eigen deploy-taak die alleen toegang heeft tot de sitemap. Ik pak artefacten uit binnen de domeinroot, voer daarna owner/group-correcties uit en maak uitsluitend de betreffende caches ongeldig. WP-CLI-commando’s worden uitgevoerd in de betreffende CageFS-context, zodat ze geen invloed hebben op andere projecten. Omgevingsvariabelen houd ik per site gescheiden; geheimen blijven in de eigen configuratiebestanden van de site of in de Secret Store van het paneel. Voor zero-downtime maak ik gebruik van atomic symlink-switches binnen de domeingrenzen (bijv. current/releases), maar let erop dat symlinks niet naar aangrenzende projecten verwijzen. Controles na de implementatie (status, 404/500-scan, rechtencontrole) zijn per site verplicht.

Monitoring, logboekregistratie en forensisch onderzoek

Ik houd mijn logbestanden consequent gescheiden: access- en error-logs per domein, aparte PHP- en cron-logs inclusief rotatie en bewaartermijnen. Als er zich een incident voordoet, kan ik zo de tijdlijn van een afzonderlijke site reconstrueren zonder het hele account te hoeven doorzoeken. Daarnaast maak ik gebruik van bestandsintegriteitscontroles (checksums van kernmappen), gedistribueerde auditlogs voor beheerdersacties en eenvoudige canary-bestanden die manipulaties in een vroeg stadium signaleren. Voor waarschuwingen volstaan vaak al drempelwaarden: plotselinge pieken in 500-fouten, ongebruikelijke uploadgroottes, sterk toenemend inode-gebruik of buitensporig veel gestarte PHP-workers. Deze signalen koppel ik aan duidelijke runbooks: de site blokkeren, back-ups controleren, artefacten veiligstellen, herstart in een geïsoleerde omgeving.

Speciale gevallen in WordPress: Multisite, MU-plugins en uploadstromen

Bij WordPress Multisite weeg ik de voor- en nadelen af: een Multisite-installatie heeft minder baat bij Per-Site CageFS, aangezien meerdere sites bewust één codebasis en structuur delen. Als ik strengere afbakening nodig heb (onafhankelijke teams, gescheiden caches, duidelijke forensische analyse), zet ik liever afzonderlijke instanties op en isoleer ik deze. MU-plugins, drop-ins of globale Must-Use-bibliotheken verspreid ik alleen binnen de site en vermijd ik gedeelde mappen. Mediaworkflows (CDN, beeldoptimalisatie, converters) draaien binnen de domein-jail; uploads van de ene site naar mappen van een andere sluit ik uit. Als een team asset-pijplijnen wil delen, repliceer ik deze per site of verpak ik ze als een pakket dat in de betreffende repository wordt geïntegreerd.

Migratietraject: van een monolithisch naar een gesegmenteerd account

Veel accounts beginnen met een grote public_html-map en groeien in de loop van de tijd. Ik ga in vijf stappen te werk: 1) Inventariseren: welke sites, domeinen, cronjobs, databases, geheimen? 2) Padindeling vastleggen: per site een eigen root, temp, logs, back-ups. 3) PHP-FPM-pools per domein definiëren en limieten instellen. 4) Bestanden verplaatsen, rechten aanpassen, absolute paden en includes opschonen. 5) CageFS per site activeren, tests onder belasting uitvoeren, monitoring inschakelen. Ondertussen houd ik een rollback-strategie achter de hand (snapshots, afzonderlijke back-ups). Na de cutover controleer ik of tools zoals WP-CLI, Composer, beeldverwerkingsprocessen en cronjobs binnen de juiste scope draaien en pas ik indien nodig padvariabelen aan.

Foutmeldingen en probleemoplossing

• 403/404 na activering: Meestal verwijzen rewrite-regels of includes naar paden buiten de domeinroot. Ik pas de paden aan naar relatieve varianten of gebruik variabelen.
• Composer/NPM loopt vast: globale caches zijn niet zichtbaar. Ik stel site-specifieke cachemappen in en pas de HOME/TMP-variabelen aan tijdens de implementatie.
• WP-CLI kan wp-config.php niet vinden: wordt niet in de hoofdmap van het domein uitgevoerd. Ik stel de werkdirectory correct in of geef het pad expliciet op.
• Cronjobs stil: Cron-gebruikers of paden zijn niet per domein opgeslagen. Ik controleer env-variabelen, binaire paden en logbestemmingen binnen de site-jail.
• Uploads mislukken: session.save_path of tmp_dir verwijst naar de verkeerde map. Ik wijs per FPM-pool site-specifieke tijdelijke paden toe.
• Gedeelde bibliotheek ontbreekt: de symbolische link naar het naburige project is geblokkeerd. Ik repliceer de bibliotheek naar elke site of neem deze als pakket op in de implementatie.

Governance en toegangsmodel

Zelfs als alles technisch gescheiden is, blijft de kwestie van de toegangsrechten bestaan. Ik wijs per site specifieke SSH-/SFTP-toegangsrechten toe of beperk de toegang tot het beheerderspaneel tot het betreffende domein. Ontwikkelaars- en bureauteams krijgen alleen de sleutels en rechten die ze echt nodig hebben. Voor noodgevallen heb ik een ‘break-glass’-procedure paraat (tijdelijk uitgebreide rechten, volledige logboekregistratie, achteraf intrekken). In audits documenteer ik per site: paden, pools, limieten, verantwoordelijken, RBAC-toewijzingen en back-ups. Zo blijft de segmentatie niet alleen technisch, maar ook organisatorisch robuust.

Kort samengevat

Per-Site CageFS vult de bestaande gebruikersscheiding aan met een website-niveau en vermindert daarmee effectief het risico op laterale bewegingen. Ik beschouw dit als een praktische stap, omdat veel accounts meerdere onafhankelijke projecten omvatten. De combinatie van gescheiden bestandsweergaven en limieten voor bronnen zorgt voor orde in prestaties, beveiliging en beheer. Wie meerdere WordPress- of webshop-instanties host, bespaart tijd bij het opsporen van fouten, het maken van back-ups en het herstellen na incidenten. Met duidelijke rechten, updates, MFA en logboekregistratie ontstaat een robuust Veiligheidsketting, waardoor shared hosting aanzienlijk robuuster wordt.