# Upravljani hosting ili vlastiti poslužitelj? Usporedba sigurnosti > Upravljani hosting ili root poslužitelj? Usporedba sigurnosti: tko zakrpava, tko je odgovoran i koji model odgovara Vašem timu i Vašim podacima. Izvor: https://phpsos.de/hr/blog/managed-oder-eigener-server/ Stanje: 25.10.2026 Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6 **Ukratko:** Je li upravljani hosting ili root poslužitelj sigurniji, odlučuje manje tehnika, a više pitanje tko pouzdano instalira ažuriranja. Kod upravljanog hostinga to u dogovorenom opsegu preuzima pružatelj, kod vlastitog root poslužitelja Vaš tim ili pružatelj usluga. Za tvrtke bez stručnosti za poslužitelje upravljani je hosting najčešće sigurniji izbor. Tko treba kontrolu i ima tim koji ga održava, s vlastitim poslužiteljem može biti jednako siguran. ## Što je PHP2Shell otkrio o modelima rada Situacija u listopadu 2026. bila je praktičan test. Dana 21. 10. u 16 sati njemačkog vremena pojavile su se zakrpe, BSI (njemački Savezni ured za informacijsku sigurnost) preporučio je trenutačno ažuriranje. Tko je imao upravljani paket, morao je ponajprije jedno: raspitati se kod pružatelja i dati si potvrditi stanje zakrpe i ponovno pokretanje. Tko je vodio vlastiti poslužitelj, morao je djelovati sam, često navečer ili vikendom. Oboje je imalo zamke. Kod klijenata upravljanog hostinga panel je i dalje mogao prikazivati staru verziju, primjerice 8.2.34, iako je backport bio instaliran; bez potvrde pružatelja stanje je ostajalo nejasno. Operateri vlastitih poslužitelja suočili su se s pitanjem imaju li prave pakete i jesu li svi PHP procesi ponovno pokrenuti. Temeljne odgovornosti opisuju [Upravljani poslužitelj: razjasniti odgovornost](https://phpsos.de/hr/server/managed-server/) i [Samostalno osiguranje root poslužitelja i vServera](https://phpsos.de/hr/server/root-server-vserver/). Ovdje je riječ o odluci između jednog i drugog. ## Upravljani hosting ili root poslužitelj: usporedba | Kriterij | Upravljani hosting | Vlastiti root poslužitelj ili vServer | |---|---|---| | Tko zakrpava PHP i operacijski sustav? | Pružatelj, u dogovorenom opsegu | Vi ili Vaš pružatelj usluga | | Brzina kod kritičnih ranjivosti | Ovisi o procesima pružatelja | Ovisi o Vašoj dostupnosti | | Kontrola nad konfiguracijom | Ograničena, često samo putem panela ili na upit | Potpuna | | Prijelazne mjere na razini poslužitelja | Moguće samo preko pružatelja | Mogu se provesti sami | | Dokaz stanja zakrpe | Potrebna potvrda pružatelja | Može se sam provjeriti putem changelogu paketa | | Potrebno stručno znanje u kući | Malo za poslužitelj, aplikacija ostaje kod Vas | Veliko, trajno | | Posebni zahtjevi, stari softver | Često nije moguće | Moguće, ali vlastiti rizik | | Traženje tragova nakon incidenata | Logovi i pristup samo uz dogovor | Pun pristup, ali potrebna vlastita stručnost | | Ovisnost | O pružatelju i njegovu ugovoru | O Vašem timu i njegovoj dostupnosti | Tablica pokazuje: oba modela premještaju odgovornost, nijedan je ne uklanja. Kod upravljanog hostinga prebacujete održavanje poslužitelja, ali zadržavate obvezu da se raspitate i osigurate svoju aplikaciju. Kod vlastitog poslužitelja zadržavate sve, uključujući vikende. ## Pet pitanja za izbor modela rada 1. **Postoji li u kući osoba sa stručnošću za poslužitelje koja ima zamjenu i kod bolesti ili godišnjeg odmora?** Ako ne, vlastiti poslužitelj bez vanjskog održavanja je rizičan. 2. **Treba li Vašoj aplikaciji posebna konfiguracija, vlastite usluge ili stari softver?** Ako da, upravljani hosting često dolazi do granica. 3. **Koliko je web-stranica kritična za prihod ili poslovanje?** Što kritičnija, to su važnija jasna jamstva o ažuriranjima i dostupnosti, u kojem god modelu. 4. **Koje podatke obrađujete?** Kod osjetljivih podataka vrijede dokazi i pristup logovima. Razjasnite daje li Vaš pružatelj logove u kritičnom trenutku. 5. **Koliko web-stranica vodite?** Mnogo sličnih stranica može se učinkovito objediniti na vlastitom, dobro održavanom poslužitelju. Pojedinačne su stranice u upravljanom hostingu često bolje zbrinute. ## Mješoviti oblici koji se pokazuju dobrima Između dva pola postoje modeli koji u praksi često najbolje funkcioniraju. Najčešći je vlastiti poslužitelj s vanjskim održavanjem: zadržavate kontrolu nad konfiguracijom i podacima, a pružatelj usluga preuzima ažuriranja, nadzor i odgovor na hitne slučajeve prema čvrstim dogovorima. Druga je varijanta upravljani hosting uz dodatnu sigurnosnu provjeru. Pružatelj održava poslužitelj, a neovisan pružatelj usluga redovito provjerava aplikaciju, dodatke i tragove koji su izvan upravljanog opsega. Za jednostavne web-stranice naposljetku [zajednički hosting](https://phpsos.de/hr/server/shared-hosting/) ostaje razumno rješenje ako pružatelj hostinga pouzdano zakrpava, a web-stranica nema posebnih zahtjeva. Važno je u svim modelima: automatska sigurnosna ažuriranja operacijskog sustava, redovito provjeravane sigurnosne kopije i dvofaktorska prijava za sve pristupe temelji su koji vrijede neovisno o modelu. Tko na vlastitom poslužitelju postavi automatska ažuriranja, ipak mora provjeriti da se PHP procesi nakon toga ponovno pokreću; zašto je to odlučujuće, objašnjava [Nakon ažuriranja: ponovno pokretanje PHP-FPM-a i svih workera](https://phpsos.de/hr/php2shell/php-fpm-neustart/). > **Važno:** > Nijedan model rada ne skida s Vas odgovornost za Vašu aplikaciju i Vaše podatke. I kod upravljanog hostinga CMS, dodaci i administratorski računi moraju se održavati, a povrede podataka procjenjujete Vi. ## Kada je promjena smislena, a kada nije Promjena se isplati ako je PHP2Shell pokazao strukturnu slabost: Vaš tim nije mogao pravodobno zakrpati vlastiti poslužitelj ili Vaš upravljani pružatelj nije reagirao na upite i nije isporučio dokaz. Na što paziti pri promjeni pružatelja, opisuje [Promjena pružatelja hostinga nakon sigurnosnog incidenta](https://phpsos.de/hr/blog/hoster-wechseln-nach-vorfall/). Nije dobar razlog za promjenu, naprotiv, pojedinačan događaj koji bi se mogao riješiti boljim dogovorom. Često je dovoljno postojeći ugovor dopuniti odredbama o sigurnosnim ažuriranjima, ponovnim pokretanjima i obavješćivanju kod kritičnih ranjivosti. Razmislite i o trenutku. Selidba usred akutne situacije veže upravo snage koje trebaju za zakrpe i traženje tragova. Bolje je najprije osigurati aktualni poslužitelj, a promjenu zatim mirno planirati, s urednom ponovnom izgradnjom umjesto kopije starog sustava. ## Kako PHP SOS konkretno pomaže? - Uspoređujemo Vaš aktualni model s Vašim stvarnim zahtjevima i pokazujemo gdje je odgovornost neriješena. - Provjeravamo opise usluga upravljanih pružatelja na točke koje vrijede u kritičnom trenutku. - Za vlastite poslužitelje preuzimamo ažuriranja, ojačavanje i nadzor u okviru [ugovora o sigurnosnom održavanju](https://phpsos.de/hr/leistungen/security-wartungsvertrag/). - Kod promjene pratimo selidbu da se ne prenesu stari pristupi ili neprovjereni podaci. ## Zaključak Upravljani hosting sigurniji je izbor za tvrtke bez stručnosti za poslužitelje, a vlastiti poslužitelj fleksibilniji za timove sa stručnim znanjem i spremnošću. Najbolje često prolaze mješoviti oblici u kojima je jasno uređeno tko zakrpava, tko ponovno pokreće i tko reagira u kritičnom trenutku. ## Česta pitanja **Je li upravljani hosting načelno sigurniji od root poslužitelja?** Ne načelno. Upravljani hosting je sigurniji ako pružatelj pouzdano instalira ažuriranja, a Vi sami imate malo znanja o poslužiteljima. Dobro održavan vlastiti poslužitelj može biti jednako siguran, ali trajno traži vrijeme i stručno znanje. **Tko je kod root poslužitelja nadležan za PHP ažuriranja?** U pravilu Vi sami. Operater podatkovnog centra najčešće brine samo o hardveru, mreži i virtualizaciji. Operacijski sustav, PHP, web-poslužitelj i aplikacija su kod Vas ili Vašeg pružatelja usluga. **Mogu li kod upravljanog hostinga postaviti vlastite PHP postavke?** Često samo ograničeno. Mnogi pružatelji dopuštaju izmjene putem panela ili na upit. Za prijelazne mjere poput onih kod PHP2Shella neke se postavke moraju postaviti na razini cijelog poslužitelja; to tada ide samo preko pružatelja. **Što je sa zajedničkim hostingom?** Zajednički hosting je najjednostavniji oblik upravljanog hostinga. Pružatelj održava sustav za mnogo klijenata istodobno. Gotovo da nemate utjecaja na verziju PHP-a i konfiguraciju, ali se njome ni ne morate baviti. **Isplati li se promjena modela rada nakon PHP2Shella?** Samo ako je situacija pokazala stvarnu slabost, primjerice da nitko nije mogao pravodobno zakrpati vlastiti poslužitelj. Promjena iz osjećaja rijetko rješava stvarni problem. ## Izvori - [php.net: sigurnosne objave](https://www.php.net/) - [PHP: podržane verzije](https://www.php.net/supported-versions.php) - [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks) - [BSI](https://www.bsi.bund.de/)