# Managed hosting eller egen server? Sikkerhedssammenligningen

> Managed hosting eller root-server? Sikkerhedssammenligningen: hvem patcher, hvem er ansvarlig, og hvilken model der passer til jeres team og jeres data.

Kilde: https://phpsos.de/da/blog/managed-oder-eigener-server/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** Om managed hosting eller root-server er sikrest, afgøres mindre af teknikken end af spørgsmålet om, hvem der pålideligt indspiller opdateringer. Ved managed hosting overtager udbyderen det i det aftalte omfang, ved egen root-server jeres team eller en leverandør. For virksomheder uden serverkompetence er managed hosting som regel det sikreste valg. Den, der har brug for kontrol og har et team til at passe den, kan køre lige så sikkert med en egen server.

## Hvad PHP2Shell afslørede om driftsmodeller

Situationen i oktober 2026 var en praksistest. Den 21.10. kl. 16 tysk tid udkom rettelserne, BSI (det tyske forbundsagentur for informationssikkerhed) anbefalede en øjeblikkelig opdatering. Den, der havde et managed-abonnement, skulle først og fremmest gøre én ting: spørge hos udbyderen og få patch-status og genstart bekræftet. Den, der drev en egen server, måtte selv handle, ofte om aftenen eller i weekenden.

Begge dele havde faldgruber. Hos managed-kunder kunne panelet fortsat vise et gammelt versionsnummer, f.eks. 8.2.34, selv om en backport var indspillet; uden udbyderens bekræftelse forblev statussen så uklar. Driftsansvarlige for egne servere stod over for spørgsmålet, om de havde de rigtige pakker, og om alle PHP-processer var genstartet. De grundlæggende ansvarsområder beskriver [Managed server: Afklar ansvaret](https://phpsos.de/da/server/managed-server/) og [Sikr root-servere og vServere selv](https://phpsos.de/da/server/root-server-vserver/). Her handler det om valget mellem de to.

## Managed hosting eller root-server: sammenligningen

| Kriterium | Managed hosting | Egen root-server eller vServer |
|---|---|---|
| Hvem patcher PHP og styresystem? | Udbyderen, i det aftalte omfang | I eller jeres leverandør |
| Hastighed ved kritiske sårbarheder | Afhænger af udbyderens processer | Afhænger af jeres tilgængelighed |
| Kontrol over konfigurationen | Begrænset, ofte kun via panel eller forespørgsel | Fuldstændig |
| Midlertidige foranstaltninger på serverniveau | Kun mulige via udbyderen | Kan gennemføres selv |
| Dokumentation af patch-status | Udbyderens bekræftelse nødvendig | Selv kontrollerbar via pakkens changelog |
| Nødvendig fagviden i huset | Lav for serveren, applikationen forbliver hos jer | Høj, vedvarende |
| Særlige krav, gammel software | Ofte ikke muligt | Muligt, men egen risiko |
| Sporsøgning efter hændelser | Logs og adgang kun efter aftale | Fuld adgang, men egen ekspertise nødvendig |
| Afhængighed | Af udbyderen og dennes kontrakt | Af jeres team og dets tilgængelighed |

Tabellen viser: Begge modeller flytter ansvar, ingen fjerner det. Ved managed hosting lægger I serverpasningen ud, men beholder pligten til at spørge og sikre jeres applikation. Ved egen server beholder I alt, inklusive weekenderne.

## Fem spørgsmål til valget af driftsmodel

1. **Er der i huset en person med serverkompetence, som også har en stedfortræder ved sygdom eller ferie?** Hvis nej, er en egen server uden ekstern betjening risikabel.
2. **Kræver jeres applikation særlige konfigurationer, egne tjenester eller gammel software?** Hvis ja, støder managed hosting ofte på grænser.
3. **Hvor kritisk er websitet for omsætning eller drift?** Jo mere kritisk, desto vigtigere er klare tilsagn om opdateringer og tilgængelighed, uanset model.
4. **Hvilke data behandler I?** Ved følsomme data tæller dokumentation og logadgang. Afklar, om jeres udbyder udleverer logs i en nødsituation.
5. **Hvor mange websites driver I?** Mange lignende sider kan effektivt samles på en egen, godt betjent server. Enkelte sider er ofte bedre hjemme i managed hosting.

## De blandingsformer, der har vist sig at fungere

Mellem de to poler findes modeller, som i praksis ofte fungerer bedst. Den hyppigste er egen server med ekstern betjening: I beholder kontrollen over konfiguration og data, en leverandør overtager opdateringer, overvågning og nødreaktion efter faste aftaler.

En anden variant er managed hosting med supplerende sikkerhedskontrol. Udbyderen passer serveren, en uafhængig leverandør kontrollerer regelmæssigt applikation, plugins og spor, der ligger uden for managed-omfanget. For enkle websites forbliver [shared hosting](https://phpsos.de/da/server/shared-hosting/) endelig en fornuftig løsning, hvis hostingudbyderen patcher pålideligt, og websitet ikke har særlige krav.

Vigtigt i alle modeller: Automatiserede sikkerhedsopdateringer til styresystemet, regelmæssigt kontrollerede backups og totrinslogin til alle adgange er grundlag, der gælder uafhængigt af modellen. Den, der opsætter automatiske opdateringer på en egen server, skal alligevel kontrollere, at PHP-processer genstartes bagefter; hvorfor det er afgørende, forklarer [Efter opdateringen: Genstart PHP-FPM og alle workers](https://phpsos.de/da/php2shell/php-fpm-neustart/).

> **Vigtigt:**
> Ingen driftsmodel fritager jer for ansvaret for jeres applikation og jeres data. Også ved managed hosting skal CMS, plugins og admin-konti vedligeholdes, og databrud skal vurderes af jer.

## Hvornår et skifte er fornuftigt, og hvornår ikke

Et skifte kan betale sig, hvis PHP2Shell har vist en strukturel svaghed: Jeres team kunne ikke patche den egne server rettidigt, eller jeres managed-udbyder reagerede ikke på forespørgsler og leverede ingen dokumentation. Hvad I bør være opmærksomme på ved et udbyderskifte, beskriver [Skift hostingudbyder efter en sikkerhedshændelse](https://phpsos.de/da/blog/hoster-wechseln-nach-vorfall/).

Ikke en god grund til et skifte er derimod en enkelt begivenhed, der kunne løses med bedre aftaler. Ofte er det nok at supplere den eksisterende kontrakt med regler om sikkerhedsopdateringer, genstarter og information ved kritiske sårbarheder.

Tænk også på tidspunktet. En flytning midt i en akut situation binder netop de kræfter, der lige nu er brug for til patches og sporsøgning. Bedre er det først at sikre den nuværende server og derefter planlægge skiftet i ro og mag, med ren genopbygning i stedet for en kopi af det gamle system.

## Hvordan hjælper PHP SOS konkret?

- Vi sammenligner jeres nuværende model med jeres faktiske krav og viser, hvor ansvaret er uafklaret.
- Vi gennemgår managed-udbyderes ydelsesbeskrivelser for de punkter, der tæller i en nødsituation.
- Til egne servere overtager vi opdateringer, hærdning og overvågning inden for rammerne af en [sikkerhedsvedligeholdelsesaftale](https://phpsos.de/da/leistungen/security-wartungsvertrag/).
- Ved et skifte ledsager vi flytningen, så ingen gamle adgange eller ukontrollerede data følger med.

## Konklusion

Managed hosting er det sikreste valg for virksomheder uden serverkompetence, den egne server det mest fleksible for teams med fagviden og vilje. Bedst klarer blandingsformer sig ofte, hvor det er klart reguleret, hvem der patcher, hvem der genstarter, og hvem der reagerer i en nødsituation.


## Ofte stillede spørgsmål

**Er managed hosting generelt sikrere end en root-server?**  
Ikke generelt. Managed hosting er sikrere, hvis udbyderen indspiller opdateringer pålideligt, og I selv har lidt serverviden. En godt betjent egen server kan være lige så sikker, men kræver vedvarende tid og fagviden.

**Hvem er ansvarlig for PHP-opdateringer ved en root-server?**  
Som regel jer selv. Datacenteroperatøren tager sig som regel kun af hardware, net og virtualisering. Styresystem, PHP, webserver og applikation ligger hos jer eller jeres leverandør.

**Kan jeg ved managed hosting sætte egne PHP-indstillinger?**  
Ofte kun i begrænset omfang. Mange udbydere tillader ændringer via et panel eller på forespørgsel. Til midlertidige foranstaltninger som ved PHP2Shell skal nogle indstillinger sættes serverdækkende; det kan så kun ske via udbyderen.

**Hvad med shared hosting?**  
Shared hosting er den enkleste form for administreret hosting. Udbyderen vedligeholder systemet for mange kunder på én gang. I har næppe indflydelse på PHP-version og konfiguration, men behøver heller næppe tage jer af det.

**Kan det betale sig at skifte driftsmodel efter PHP2Shell?**  
Kun hvis situationen har vist en reel svaghed, f.eks. at ingen kunne patche den egne server rettidigt. Et skifte ud fra mavefornemmelsen løser sjældent det egentlige problem.

## Kilder

- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [PHP: Understøttede versioner](https://www.php.net/supported-versions.php)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)
- [BSI](https://www.bsi.bund.de/)