Ukratko: Ugovor s IT pružateljem ne bi smio sigurnost spominjati usput, nego je konkretno urediti: tko koje komponente ažurira, u kojem roku i s kojim dokazom, kako se obavještava o kritičnim ranjivostima, tko sudjeluje u incidentu, kako se čuvaju zapisnici i upravlja pristupima te što se događa pri izlasku. Ova stranica daje opće napomene i nije pravni savjet; ugovore provjerava odvjetnik.
Pitanje koje je postavio PHP2Shell: tko je nadležan?
Dana 21. 10. 2026. u 16 sati po njemačkom vremenu PHP projekt objavio je zakrpe. BSI (njemački Savezni ured za informacijsku sigurnost) preporučio je trenutačni update ili, gdje to nije bilo moguće, privremeno odspajanje web-poslužitelja s mreže. U mnogim tvrtkama nakon toga nije počeo posao, nego potraga za nadležnošću. Agencija je upućivala na hostera, hoster na ugovor, a u ugovoru je stajalo „održavanje po utrošku“.
Takve rupe u ugovoru nisu pojedinačan slučaj. Mnogi ugovori s agencijama i pružateljima sklopljeni su kad je riječ bila o izradi web-stranice, a ne o njezinu sigurnom radu tijekom godina. Kritična ranjivost u PHP okruženju izvođenja, koja ne pogađa ni CMS ni aplikacijski kod, tada lako pada između svih stolica.
Što ugovor s IT pružateljem treba urediti o sigurnosti
Sljedeći pregled navodi točke koje su se u praksi pokazale važnima. Ne zamjenjuje pravnu provjeru, ali pomaže prepoznati rupe u postojećem ugovoru.
| Točka uređenja | Što bi trebalo biti utvrđeno | Veza s PHP2Shellom |
|---|---|---|
| Opseg usluge | Koji se slojevi održavaju: operacijski sustav, PHP okruženje, web-poslužitelj, CMS, dodaci, vlastiti kod | PHP okruženje često je nedostajalo u nabrajanju |
| Rokovi za updatee | razvrstano prema težini, s pravilom iznimke za hitne slučajeve | kritična ranjivost s CVSS v4.0 9,2 |
| Ponovno pokretanje i dokaz | Updatei vrijede kao obavljeni tek nakon ponovnog pokretanja svih procesa, uz pisani dokaz | same nove datoteke ne zatvaraju ranjivost |
| Obavještavanje | aktivna obavijest o kritičnim ranjivostima, s procjenom i planom | mnogi su kupci morali sami pitati |
| Sudjelovanje u incidentima | potpora pri analizi, osiguravanju, oporavku, kontakt osoba | potraga za tragovima nakon zakrpe |
| Zapisnici | vrsta, čuvanje, predaja na zahtjev | stručni mediji savjetovali su osigurati zapisnike od 20. 10. |
| Pristupi | osobni računi, dvofaktorska prijava, popis svih pristupa | tko je zapravo imao pristup? |
| Podizvršitelji | tko je još uključen, obavijest pri promjeni | hoster hostera |
| Kraj životnog vijeka softvera | pravodobna napomena prije kraja podrške, plan migracije | PHP 8.2 završava 31. 12. 2026. |
| Izlazak | predaja podataka, dokumentacije i pristupa, oduzimanje prava | promjena nakon incidenta |
Rokovi i dokazi: točke koje najviše vrijede
Rokovi su srž. Formulacija poput „pravodobno“ u najgorem slučaju ne pomaže. Dogovorite rokove odvojeno prema težini i utvrdite prema čemu se težina mjeri, primjerice prema razvrstavanju proizvođača ili BSI-ja. Za izvanredne situacije trebalo bi vrijediti pravilo za hitne slučajeve: tko je dostupan, tko odlučuje ide li sustav privremeno s mreže i kako se obračunava dodatni rad.
Jednako je važan dokaz. Kod PHP2Shella prikazani broj verzije često je govorio malo, jer distribucije i hosteri ispravke primjenjuju kao backport. Pouzdan dokaz navodi stanje paketa, trenutak instalacije i ponovno pokretanje svih PHP procesa. Koji podaci točno vrijede, opisuje Kako pitati hostera za stanje zakrpe. Ove podatke uvrstite u ugovor kao obvezan sadržaj.
Neka Vam pružatelj uz ugovor da matricu zadataka: jedan redak po komponenti, jedan stupac po zadatku, u svakoj ćeliji ime. Rupe se tada odmah uoče, mnogo prije sljedeće obavijesti.
Pristupi, podizvršitelji i izlazak
Pružatelji trebaju pristupe, a upravo su oni čest put napada. Uredite da svaka osoba dobiva vlastiti račun, da je dvofaktorska prijava obvezna gdje tehnika to dopušta i da u svakom trenutku možete zatražiti aktualan popis svih pristupa. Zaposlenici pružatelja koji su otišli moraju se pravodobno ukloniti iz svih sustava.
Ako pružatelj sam radi s partnerima, primjerice podatkovnim centrom ili specijaliziranim forenzičkim timom, trebali biste to znati. Ako neki od tih partnera obrađuje osobne podatke, dodaju se obveze iz zaštite podataka. Više o tome u članku Obrada podataka u ime voditelja kad pružatelji pristupaju poslužitelju.
Izlazak se pri sklapanju ugovora najčešće zaboravlja. Utvrdite da se pri završetku ugovora podaci, konfiguracija, dokumentacija i pristupni podaci predaju u cijelosti, da se svi pristupi pružatelja oduzimaju i da se to pisano potvrđuje. Upravo je nakon incidenta uredna promjena inače teška.
Provjeriti postojeće ugovore: ovako postupite
Ne morate sve ugovore ponovno pregovarati. Za početak je dovoljan pragmatičan tijek:
- Prikupiti sve ugovore s agencijama, hosterima i IT pružateljima koji se tiču web-stranica ili poslužitelja.
- Svaki ugovor usporediti s gornjom tablicom i označiti otvorene točke.
- Najvažnije rupe pisano postaviti pružatelju, počevši s opsegom usluge, rokovima i dokazom.
- Rezultate zabilježiti kao dodatni sporazum i dati ga pravno provjeriti.
- Matricu zadataka preuzeti u plan za hitne slučajeve.
Za upravu je ovaj korak i pitanje pažnje dobrog gospodarenja. Tko jasno uredi nadležnosti i dokumentira odluke, bolje stoji ako se kasnije postave pitanja. Pozadinu nudi Odgovornost uprave kod sigurnosnih ranjivosti IT-a. Tipičnu podjelu zadataka kod održavanih poslužitelja opisuje Managed Server: razjasniti odgovornost.
Kako PHP SOS konkretno pomaže?
- Čitamo Vaše postojeće ugovore i opise usluga s tehničkog gledišta i označavamo koje komponente i zadaci nedostaju.
- Izrađujemo matricu zadataka za sve web-stranice i poslužitelje koju možete uskladiti sa svojim pružateljima.
- Formuliramo tehničke zahtjeve za rokove, dokaze i putove obavijesti koje Vaš odvjetnik može preuzeti u ugovor.
- Gdje nitko nije nadležan, zadatke preuzimamo sami preko ugovora o sigurnosnom održavanju s jasno opisanim opsegom.
Zaključak: Dobar ugovor ne sprječava sigurnosnu ranjivost, ali sprječava da se u najgorem slučaju gubi vrijeme na pitanje nadležnosti. Ova je stranica opća informacija i nije pravni savjet.
Česta pitanja
Mora li IT pružatelj primijeniti sigurnosne updatee bez naloga?
To ovisi o ugovoru. Bez jasnog uređenja često je sporno spadaju li updatei u dugovanu uslugu. Zato ugovor treba izričito utvrditi tko koje komponente ažurira i u kojem roku. Za pravnu procjenu u pojedinačnom slučaju nadležan je odvjetnik.
Trebam li dodatno ugovor o obradi podataka (AVV)?
Ako pružatelj u ime voditelja obrađuje osobne podatke ili im može pristupiti, u pravilu je potreban ugovor o obradi podataka prema čl. 28. GDPR-a. On ne zamjenjuje ugovor o usluzi, nego ga nadopunjuje. To razjasnite sa svojim službenikom za zaštitu podataka.
Koji su rokovi za sigurnosne updatee uobičajeni?
Čvrstih vrijednosti nema. Smisleno je razvrstavanje prema težini, primjerice zasebni rokovi za kritične, visoke i ostale ranjivosti. Važno je da rokovi stoje u pisanom obliku i da sadrže pravilo iznimke za hitne slučajeve poput PHP2Shella.
Što se događa s pristupima kad ugovor završi?
To bi trebao urediti ugovor: povrat ili brisanje podataka, predaja pristupnih podataka i dokumentacije, oduzimanje svih pristupa pružatelja i potvrda o tome.