Per-Site CageFS: Ny sikkerhedsarkitektur til delt hosting

CageFS pr. websted adskiller de enkelte hjemmesider inden for en shared hosting-konto fuldstændigt fra hinanden og begrænser dermed risikoen for sideværts spredning efter et indbrud. Jeg gennemgår den nye sikkerhedsarkitektur, viser praktiske anvendelsesscenarier og forklarer, hvordan du sikkert kan administrere flere projekter på én konto.

Centrale punkter

• Webstedsisolering: Yderligere opdeling inden for en konto mindsker sideeffekter.
• CloudLinux: Udvidelse af CageFS-konceptet til domæneniveau.
• WordPress: Kør flere instanser sikkert side om side.
• Ressourcer: Begrænsninger for CPU/RAM/I/O supplerer opdelingen af filvisningen.
• Øvelse: Aktivering pr. domæne og en klar strategi for rettigheder og stier.

Hvad „Per-Site CageFS“ konkret kan

Udvidelsen isolerer enkelte Domæner inden for et eksisterende bruger-CageFS, så hvert websted kun kan se sine egne filer og processer. På den måde forhindrer jeg, at et kompromitteret projekt får adgang til konfigurationsfiler, uploads eller nøgler fra andre websteder på samme konto. Ifølge CloudLinux Blog (beta-meddelelse): Per-Site CageFS udvider isoleringen mellem hjemmesider inden for samme brugerkonto og mindsker dermed risikoen for sideværts spredning. For mig er fordelen helt åbenbar: Jeg kan opdele agenturkonti, multisite-opsætninger og testmiljøer på en overskuelig måde uden at ødelægge hostingstrukturen. Denne baggrundsartikel giver et hurtigt overblik over princippet bag CageFS: CageFS-filsystemet, som isoleringen pr. websted bygger på.

Hvorfor kontoisolering alene ikke er nok

En konto samler ofte flere Projekter – for eksempel to webshops, tre blogs og et staging-miljø. Hvis et exploit angriber et sårbart plugin, kan en angriber uden yderligere segmentering få adgang til tilstødende mapper og placere yderligere payloads der. Det er netop her, at Per-Site CageFS afskærmer adgangen til filsystemet og processerne, så hvert websted fungerer som i sin egen Fængsel fungerer. Især ved separate WordPress-instanser med en fælles PHP-bruger opstår der ellers en risiko for eskaleringer, som jeg afværger ved hjælp af domæneisolering. Det mindsker følgeskader, forenkler fejlfinding og gør det nemmere at planlægge genoprettelser hurtigere.

Sådan fungerer webstedsisolering rent teknisk

CloudLinux indkapsler via CageFS et virtuelt, brugerbaseret filsystem; Per-Site-laget udvider dette til at omfatte domænegrænser. Hvert aktiveret domæne får et separat synsfelt inden for brugerens CageFS, herunder restriktive stier, egne midlertidige mapper og isoleret scriptudførelse. Dermed forsvinder fremmede wp-config.php-filer, upload-mapper eller nøglefiler fra det angrebne websteds synsfelt. Cronjobs, PHP og eventuelt SSH-kommandoer har adgang til de samme systembiblioteker, men ser kun de tildelte Delmængder i filsystemet. Ifølge dokumentationen kan adskillelsen aktiveres for hvert domæne, hvilket giver mig mulighed for meget detaljeret styring af live-, staging- og testinstanser.

Sammenligning: Kontoisolering, CageFS pr. websted og containere

For at træffe et velovervejet valg sammenligner jeg tre almindelige Modeller efter isolationsdybde, arbejdsomfang og kompatibilitet. Kontoisolering sikrer adskillelse mellem kunder, men lader interne grænser mellem sider stå åbne. Per-Site CageFS lukker dette hul set fra filsystem- og procesperspektivet. Containere skaber faste grænser, men kræver ofte mere vedligeholdelse og tilpasninger. En grundig klassificering af procesisolering leveres af denne Sammenligning af Chroot, CageFS og Jails.

Fremgangsmåde	Adskillelse mellem konti	Adskillelse mellem hjemmesider i kontoen	Kompatibilitet (PHP/CGI/SSH/Cron)	Driftsomkostninger
Kontoisolering (klassisk)	Høj	Lav	Meget god	Lav
CageFS pr. websted	Høj	Middel til høj	Meget god	Lav til middel
Containere pr. anlæg	Meget høj	Meget høj	God til meget god	Middel til høj

I shared hosting-miljøer tilbyder Per-Site CageFS en stærk kombination af fin Adskillelse og med minimal omstilling, da scripts som regel kører uændret. Dermed sikrer jeg mod det mest almindelige sikkerhedshul: flere uafhængige hjemmesider under én enkelt brugerkonto.

Praksis: Sikker drift af flere WordPress-instanser

Jeg adskiller hver WordPress-instans, hvor Domæneisolering og opretter separate PHP-FPM-puljer for hvert websted, så logfiler, opcache og begrænsninger forbliver tydeligt tildelt. Desuden definerer jeg separate SALT’er/NØGLER for hvert websted i wp-config.php og forhindrer enhver krydsadgang via filrettigheder og open_basedir-ækvivalenter. Uploads gemmer jeg strengt inden for den respektive dokumentrod og forbyder globale, delte upload-mapper. Under implementeringer holder jeg midlertidige stier internt på webstedet og rydder build-artefakter med det samme, så der ikke forbliver unødvendige angrebsflader. Til Composer- eller NPM-caches bruger jeg webstedslokale Lister, så der ikke opstår krydseffekter.

Ydeevne og ressourcestyring i samspil

Per-Site CageFS vedrører filvisningen; den Ydelse Jeg sikrer mig ved hjælp af begrænsninger for CPU, RAM, I/O og processer på konto- eller pool-niveau. På den måde forhindrer jeg, at et websted skaber for stor belastning på grund af fejlbehæftede plugins og dermed bremser hele kontoen. I mange opsætninger indgår dette i LVE- eller lignende kvoter, som jeg finjusterer pr. pool eller konto. Jeg kombinerer dette med begrænsning af anmodninger i webserveren eller WAF, så trafikspidser forløber ordentligt. Denne kombination af isolering og kvoter øger tjenestens sikkerhed og forudsigelighed Fordeling af belastning.

Beskyttelseskæde: Hvad Per-Site CageFS ikke erstatter

Isoleringen forhindrer indblik, men jeg holder opdateringerne, Hærdning af PHP og strenge adgangskoder gennemføres fortsat konsekvent. Også MFA til administrator-login, minimale filrettigheder og upload-filtre er fortsat obligatoriske. En WAF, hastighedsbegrænsninger og kontinuerlig logning dækker yderligere angrebsveje, som ren adskillelse af filvisning ikke kontrollerer. Jeg tjekker desuden regelmæssigt cron-jobs og integrationstokens, som angribere ofte glemmer at finde. Du kan læse mere om samspillet mellem klientadskillelse og hærdning i denne vejledning til Sikkerhed ved delt hosting, som understreger denne tankegang.

Opsætning og typiske udfordringer

Jeg aktiverer domæneisolering målrettet for hvert enkelt Websted og tester derefter SSH-, Cron- og PHP-adgang under reelle forhold. Absolutte stier i deploymentskripter eller plugins kan forårsage problemer, derfor foretrækker jeg relative stier eller variabler. Jeg undgår symlinks mellem projekter, fordi de udhuler adskillelsesprincippet; jeg trækker hellere de nødvendige biblioteker ind i repoen for hvert enkelt websted. Til sikkerhedskopier definerer jeg separate arkiver og sikkerhedskopierede logfiler for hvert domæne, så gendannelse og forensisk analyse forbliver overskuelige. Hvad angår rettigheder, har 640 for filer og 750 for mapper vist sig at fungere godt, plus Ejere der passer til den pågældende PHP-pool.

Kost-nytte-analyse for bureauer og freelancere

Jeg afvejer sikkerhedsgevinsten mod den administrative tid og de potentielle omkostninger ved driftsstop, som en tværgående hændelse ville medføre, mod Euro-Grundlag. Selv få timers incident-response koster ofte betydeligt mere end et lille månedligt tillæg for bedre isolering. For agenturkonti med flere kundeprojekter reducerer segmenteringen mærkbart risikoen for erstatningsansvar og omdømmetab. Også backup- og gendannelsesprocesser forløber mere overskueligt, fordi jeg målrettet kan gendanne enkelte websteder. Samlet set sikrer CageFS pr. websted en mere pålidelig Operationel ledelse med forudsigelige processer.

Tjekliste: Hvornår CageFS pr. anlæg bliver obligatorisk

Jeg aktiverer domæneisolering, så snart der er flere Installationer kører på én konto og har forskellige opdateringscyklusser. Ligeledes vigtigt: separate projektteams eller eksterne administratoradgange, som øger risikoen for utilsigtede indgreb. Store upload-mængder, filkonvertere eller billedbehandling er yderligere argumenter for adskillelsen, da der ofte opstår sårbare punkter her. Forskellige compliance-krav (f.eks. kunder, markeder, databeskyttelse) taler ligeledes for finere segmentering. Den, der kører staging, test og live parallelt, drager fordel af klart adskilte fejldomæner og en tydelig Retsmedicin.

Forudsætninger og kompatibilitet i praksis

Inden jeg tager Per-Site CageFS i brug, tjekker jeg kørselsmiljøet: den anvendte PHP-handler (f.eks. PHP-FPM, lsapi), den aktive webserver, tilgængelig panelintegration samt den måde, hvorpå cron-jobs og SSH-sessioner administreres. I typiske delte miljøer kører applikationerne videre uden ændringer i koden. Jeg sikrer mig, at der findes en separat dokumentrod pr. domæne, at stierne er entydige (f.eks. /home/user/sites/projekt-a/public), og at der anvendes en dedikeret PHP-FPM-pool pr. site. Til cron-jobs bruger jeg separate crontabs pr. domæne eller – hvor kontrolpanelet samler dem – klare præfikser og logstier, så jobbene forbliver inden for deres Fængsler arbejde.

Sørg for en klar adskillelse mellem databaser, cacher og sessioner

Filvisningen er kun en del af det. Jeg trækker adskillelsen helt ned til databasen og cacherne. For hvert websted opretter jeg en separat database og en separat databasebruger med minimale rettigheder. Til objekt- eller side-caches (f.eks. Redis, Memcached) bruger jeg separate instanser for hvert websted eller i det mindste nøglepræfikser og dedikerede databaser/navneområder. PHP-sessioner placeres i webstedsspecifikke stier; jeg indstiller session.save_path separat for hver FPM-pool. Hvis jeg bruger en central kø eller et søgebackend, adskiller jeg indekser og emner for hvert websted. Dette princip om „adskillelse helt ned til sidste led“ forhindrer, at hændelser spreder sig til andre systemer.

CI/CD og implementeringer under isolation

I build-pipelines gør jeg isolering til standard: Der findes et separat deploy-job for hvert websted, som kun har adgang til webstedets mappe. Jeg udpakker artefakterne inden for domænets rodmappe, udfører derefter owner/group-rettelser og ugyldiggør udelukkende de berørte cacher. WP-CLI-kommandoer kører i den respektive CageFS-kontekst, så de ikke påvirker andre projekter. Miljøvariabler holdes adskilt for hvert websted, og hemmeligheder forbliver i webstedets egne konfigurationsfiler eller i panelets hemmelighedsopbevaringssted. For at undgå nedetid bruger jeg atomare symlink-skift inden for domænegrænserne (f.eks. current/releases), men sørger for, at symlinks ikke peger på naboprojekter. Kontroller efter implementering (tilstand, 404/500-scanning, rettighedskontrol) er obligatoriske for hvert websted.

Overvågning, logning og forensisk analyse

Jeg adskiller logfilerne konsekvent: adgangs- og fejllogfiler for hvert domæne, separate PHP- og Cron-logfiler med rotation og opbevaringsperiode. I tilfælde af en hændelse kan jeg på den måde rekonstruere tidslinjen for et enkelt websted uden at skulle gennemgå hele kontoen. Derudover benytter jeg filintegritetskontroller (kontrolsummer fra kernekataloger), distribuerede audit-logfiler for administratorhandlinger og enkle Canary-filer, der tidligt afslører manipulationer. Til alarmer er tærskelværdier ofte tilstrækkelige: pludselige stigninger i 500-fejl, usædvanlige upload-størrelser, kraftigt stigende inode-belægning eller overdreven opstart af PHP-workere. Disse signaler knytter jeg til klare runbooks: Spærre webstedet, kontrollere backups, sikre artefakter, genstarte i et isoleret omfang.

Særlige tilfælde i WordPress: Multisite, MU-plugins og upload-processer

Når det gælder WordPress Multisite, afvejer jeg det: En Multisite-installation drager mindre fordel af CageFS pr. site, da flere sites bevidst deler en fælles kodebase og struktur. Hvis jeg har brug for strengere afgrænsninger (uafhængige teams, adskilte caches, klar sporbarhed), foretrækker jeg at oprette individuelle instanser og isolere dem. MU-plugins, drop-ins eller globale Must-Use-biblioteker distribuerer jeg kun internt på hvert site og undgår delte mapper. Medie-workflows (CDN, billedoptimering, konvertere) kører inden for domæne-jailen; jeg udelukker uploads fra et site til mapper på et andet. Hvis et team ønsker at dele asset-pipelines, replikerer jeg disse for hvert websted eller indkapsler dem som et pakke, der integreres i det pågældende repo.

Migrationsforløb: Fra monolit til segmenteret konto

Mange konti starter med en stor public_html-mappe og vokser med tiden. Jeg går frem i fem trin: 1) Gennemgang: Hvilke hjemmesider, domæner, cron-jobs, databaser og hemmelige nøgler? 2) Fastlægge sti-struktur: Hver hjemmeside skal have sin egen rodmappe, temp-mappe, logfiler og sikkerhedskopier. 3) Definere PHP-FPM-puljer pr. domæne og indstille grænser. 4) Flytte filer, justere rettigheder, rydde op i absolutte stier og includes. 5) Aktivere CageFS pr. hjemmeside, køre belastningstests, aktivere overvågning. I mellemtiden har jeg en rollback-strategi klar (snapshots, separate sikkerhedskopier). Efter overgangen kontrollerer jeg, om værktøjer som WP-CLI, Composer, billedbehandlingsprocesser og cron-jobs kører inden for det korrekte omfang, og justerer om nødvendigt sti-variablerne.

Fejlbilleder og fejlfinding

• 403/404 efter aktivering: Oftest henviser rewrite-regler eller includes til stier uden for domænets rodmappe. Jeg ændrer stierne til relative varianter eller bruger variabler.
• Composer/NPM går ned: Globale cacher er ikke synlige. Jeg opretter cache-mapper på webstedet og tilpasser HOME/TMP-variablerne i deploy-processen.
• WP-CLI kan ikke finde wp-config.php: Kørselen foregår ikke i domænets rodmappe. Jeg skal indstille arbejdsmappen korrekt eller angive stien eksplicit.
• Cron-jobs er stoppet: Cron-brugere eller stier er ikke angivet pr. domæne. Jeg kontrollerer miljøvariabler, binære stier og logmål inden for site-jail.
• Uploads mislykkes: session.save_path eller tmp_dir peger på den forkerte mappe. Jeg tildeler webstedsspecifikke midlertidige stier for hver FPM-pool.
• Delt bibliotek mangler: Symlink til et tilstødende projekt er blokeret. Jeg replikerer biblioteket til hvert websted eller integrerer det som en pakke i implementeringen.

Styring og adgangsmodel

Selv om alt er adskilt rent teknisk, er der stadig spørgsmålet om adgang. Jeg tildeler dedikerede SSH-/SFTP-adgange for hvert websted eller begrænser paneladgangen til det pågældende domæne. Udvikler- og agenturteams får kun de nøgler og rettigheder, de virkelig har brug for. Til nødsituationer har jeg en »break-glass«-procedure klar (midlertidigt udvidede rettigheder, fuldstændig logning, efterfølgende tilbagekaldelse). I revisioner dokumenterer jeg for hvert websted: stier, puljer, grænser, ansvarlige, RBAC-tildelinger og sikkerhedskopier. På den måde forbliver segmenteringen ikke kun teknisk, men også organisatorisk robust.

Kort opsummeret

Per-Site CageFS udvider den eksisterende brugeradskillelse med en Websted-niveau og mindsker dermed effektivt risikoen for laterale bevægelser. Jeg anser dette for at være et praktisk skridt, da mange konti omfatter flere uafhængige projekter. Kombinationen af adskillelse af filvisninger og ressourcebegrænsninger skaber orden i ydeevne, sikkerhed og drift. Hvis man hoster flere WordPress- eller webshop-instanser, sparer man tid ved fejlfinding, sikkerhedskopiering og genopstart efter hændelser. Med klare rettigheder, opdateringer, MFA og logning skabes en bæredygtig Sikkerhedskæde, hvilket gør shared hosting betydeligt mere robust.