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 i Samostalno osiguranje root poslužitelja i vServera. 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
- 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.
- Treba li Vašoj aplikaciji posebna konfiguracija, vlastite usluge ili stari softver? Ako da, upravljani hosting često dolazi do granica.
- 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.
- Koje podatke obrađujete? Kod osjetljivih podataka vrijede dokazi i pristup logovima. Razjasnite daje li Vaš pružatelj logove u kritičnom trenutku.
- 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 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.
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.
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.
- 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.