Na kratko: Pogodba s ponudnikom IT naj varnosti ne omenja le mimogrede, ampak jo uredi konkretno: kdo posodablja katere komponente, v kakšnem roku in s kakšnim dokazilom, kako se obvešča o kritičnih ranljivostih, kdo sodeluje ob incidentu, kako se hranijo dnevniki in upravljajo dostopi ter kaj se zgodi ob izstopu. Ta stran daje splošne napotke in ni pravno svetovanje; pogodbe pregleda odvetnik.
Vprašanje, ki ga je postavil PHP2Shell: kdo je pristojen?
-
- 2026 ob 16. uri po nemškem času je projekt PHP objavil popravke. BSI (nemški zvezni urad za informacijsko varnost) je priporočil takojšnjo posodobitev ali, kjer to ni bilo mogoče, začasno odklop spletnih strežnikov z omrežja. V mnogih podjetjih se potem ni začelo delo, ampak iskanje pristojnosti. Agencija je kazala na ponudnika gostovanja, ponudnik gostovanja na pogodbo, v pogodbi pa je pisalo „vzdrževanje po porabi“.
Take vrzeli v pogodbi niso osamljen primer. Mnoge pogodbe z agencijami in ponudniki so bile sklenjene, ko je šlo za izgradnjo spletne strani, ne za njeno varno delovanje skozi leta. Kritična ranljivost v izvajalnem okolju PHP, ki ne zadeva niti CMS niti aplikacijske kode, potem zlahka pade med vse stole.
Kaj naj pogodba s ponudnikom IT uredi glede varnosti
Naslednji pregled navaja točke, ki so se v praksi izkazale za pomembne. Pravnega pregleda ne nadomešča, pomaga pa prepoznati vrzeli v obstoječi pogodbi.
| Točka ureditve | Kaj naj bo zapisano | Povezava s PHP2Shell |
|---|---|---|
| Obseg storitev | Katere plasti se vzdržujejo: operacijski sistem, izvajalno okolje PHP, spletni strežnik, CMS, vtičniki, lastna koda | Izvajalno okolje PHP je v naštevanju pogosto manjkalo |
| Roki za posodobitve | razvrščeni po resnosti, s pravilom o izjemi za nujne primere | kritična ranljivost s CVSS v4.0 9,2 |
| Ponovni zagon in dokazilo | Posodobitve veljajo za opravljene šele po ponovnem zagonu vseh procesov, s pisnim dokazilom | same nove datoteke ranljivosti ne zaprejo |
| Obveščanje | aktivno obvestilo ob kritičnih ranljivostih, z oceno in načrtom | mnogi odjemalci so morali povpraševati sami |
| Sodelovanje ob incidentih | podpora pri analizi, zavarovanju, obnovi, kontaktna oseba | iskanje sledi po popravku |
| Dnevniki | vrsta, hramba, izročitev na zahtevo | strokovni tisk je svetoval zavarovati dnevnike od 20. 10. |
| Dostopi | osebni računi, dvofaktorska prijava, seznam vseh dostopov | kdo je sploh imel dostop? |
| Podizvajalci | kdo je še udeležen, obvestilo ob menjavi | ponudnik gostovanja ponudnika gostovanja |
| Konec življenjske dobe programske opreme | pravočasno opozorilo pred koncem podpore, načrt migracije | PHP 8.2 se konča 31. 12. 2026 |
| Izstop | izročitev podatkov, dokumentacije in dostopov, odvzem pravic | menjava po incidentu |
Roki in dokazila: točke, ki štejejo največ
Roki so jedro. Formulacija, kot je „takoj ko je mogoče“, v skrajnem primeru ne pomaga. Roke dogovorite ločeno po resnosti in določite, po čem se resnost meri, na primer po oceni proizvajalca ali urada BSI. Za izredne razmere naj velja pravilo za nujne primere: kdo je dosegljiv, kdo odloča, ali se sistem začasno odklopi z omrežja, in kako se obračuna dodatni trud.
Enako pomembno je dokazilo. Pri PHP2Shell je prikazana številka različice pogosto povedala malo, ker distribucije in ponudniki gostovanja popravke vgradijo kot backport. Zanesljivo dokazilo navaja stanje paketa, čas namestitve in ponovni zagon vseh procesov PHP. Katere navedbe natančno štejejo, opisuje Kako ponudnika gostovanja vprašate po stanju popravkov. Te navedbe vključite v pogodbo kot obvezno vsebino.
Naj vam ponudnik k pogodbi priskrbi matriko nalog: ena vrstica na komponento, en stolpec na nalogo, v vsaki celici ime. Vrzeli se potem takoj opazijo, dolgo preden pride naslednje obvestilo.
Dostopi, podizvajalci in izstop
Ponudniki potrebujejo dostope in prav ti so pogosta pot napada. Uredite, da vsaka oseba dobi lasten račun, da je dvofaktorska prijava obvezna, kjer tehnika to dopušča, in da lahko kadarkoli zahtevate aktualen seznam vseh dostopov. Odhajajoče sodelavce ponudnika je treba pravočasno odstraniti iz vseh sistemov.
Če ponudnik sam dela s partnerji, na primer s podatkovnim centrom ali specializirano forenzično ekipo, naj bi to vedeli. Če eden od teh partnerjev obdeluje osebne podatke, pridejo zraven obveznosti s področja varstva podatkov. Več o tem v prispevku Obdelava po naročilu, kadar ponudniki dostopajo do strežnikov.
Izstop se ob sklenitvi pogodbe najpogosteje pozabi. Zapišite, da se ob koncu pogodbe podatki, konfiguracija, dokumentacija in dostopni podatki v celoti izročijo, da se ponudniku odvzamejo vsi dostopi in da se to pisno potrdi. Ravno po incidentu je brez tega urejena menjava težka.
Pregled obstoječih pogodb: kako ravnati
Vseh pogodb vam ni treba na novo pogajati. Za začetek zadošča pragmatičen potek:
- Zberite vse pogodbe z agencijami, ponudniki gostovanja in ponudniki IT, ki zadevajo spletne strani ali strežnike.
- Vsako pogodbo primerjajte z zgornjo tabelo in označite odprte točke.
- Najpomembnejše vrzeli pisno naslovite na ponudnika, začenši z obsegom storitev, roki in dokazilom.
- Rezultate zapišite kot dopolnilni dogovor in jih dajte pravno preveriti.
- Matriko nalog prenesite v načrt za nujne primere.
Za vodstvo je ta korak tudi vprašanje skrbnosti. Kdor jasno uredi pristojnosti in dokumentira odločitve, stoji bolje, če se pozneje zastavijo vprašanja. Ozadje ponuja Odgovornost vodstva ob varnostnih vrzelih IT. Tipično delitev nalog pri upravljanih strežnikih opisuje Upravljani strežnik: pojasnite odgovornost.
Kako konkretno pomaga PHP SOS?
- Vaše obstoječe pogodbe in opise storitev preberemo s tehničnega vidika in označimo, katere komponente in naloge manjkajo.
- Pripravimo matriko nalog za vse spletne strani in strežnike, ki jo lahko uskladite s ponudniki.
- Tehnične zahteve glede rokov, dokazil in poti obveščanja oblikujemo tako, da jih vaš odvetnik lahko prenese v pogodbo.
- Kjer nihče ni pristojen, naloge prevzamemo sami prek vzdrževalne pogodbe za varnost z jasno opisanim obsegom.
Sklep: Dobra pogodba ne prepreči varnostne vrzeli, prepreči pa, da bi se v skrajnem primeru izgubljal čas z vprašanjem pristojnosti. Ta stran je splošna informacija in ni pravno svetovanje.
Pogosta vprašanja
Ali mora ponudnik IT nameščati varnostne posodobitve brez naročila?
To je odvisno od pogodbe. Brez jasne ureditve je pogosto sporno, ali posodobitve sodijo med dolgovano storitev. Zato naj pogodba izrecno določi, kdo posodablja katere komponente in v kakšnem roku. Za pravno presojo v posameznem primeru je pristojen odvetnik.
Ali poleg tega potrebujem še pogodbo o obdelavi (AVV)?
Če ponudnik po naročilu obdeluje osebne podatke ali lahko dostopa do njih, je praviloma potrebna pogodba o obdelavi po 28. členu GDPR. Ne nadomešča pogodbe o storitvah, ampak jo dopolnjuje. To razjasnite s pooblaščencem za varstvo podatkov.
Kateri roki za varnostne posodobitve so običajni?
Stalnih vrednosti ni. Smiselna je razvrstitev po resnosti, na primer ločeni roki za kritične, visoke in preostale ranljivosti. Pomembno je, da so roki napisani in vsebujejo pravilo o izjemi za nujne primere, kot je PHP2Shell.
Kaj se zgodi z dostopi, ko pogodba preneha?
To naj uredi pogodba: vračilo ali izbris podatkov, izročitev dostopnih podatkov in dokumentacije, odvzem vseh dostopov ponudnika in potrditev o tem.