Lühidalt: Leping IT-teenusepakkujaga ei tohiks turvalisust mainida ainult möödaminnes, vaid seda konkreetselt reguleerima: kes millist komponenti uuendab, millise tähtaja ja millise tõendiga, kuidas kriitilistest aukudest teavitatakse, kes intsidendi korral kaasa aitab, kuidas logisid säilitatakse ja ligipääse hallatakse ning mis juhtub väljumisel. See leht annab üldisi vihjeid ja ei ole õigusnõustamine; lepinguid kontrollib advokaat.
Küsimus, mille PHP2Shell esitas: kes vastutab?
- oktoobril 2026 kell 16 Saksamaa aja järgi avaldas PHP projekt paigad. BSI (Saksamaa föderaalne infoturbeamet) soovitas kohest uuendust või, kus see ei olnud võimalik, veebiserverid ajutiselt võrgust eemaldada. Paljudes ettevõtetes ei alanud pärast seda töö, vaid vastutaja otsimine. Agentuur viitas hostingupakkujale, hostingupakkuja lepingule ja lepingus oli „hooldus tööaja järgi“.
Sellised lüngad lepingus ei ole üksikjuhtum. Paljud agentuuride ja teenusepakkujatega sõlmitud lepingud tehti ajal, kui oli küsimus veebisaidi ehitamises, mitte selle turvalises käitamises aastate vältel. Kriitiline auk PHP käitusajas, mis ei puuduta ei CMS-i ega rakenduse koodi, kukub siis kergesti kõigi toolide vahele.
Mida IT-teenusepakkuja leping turvalisuse kohta reguleerima peaks
Järgmine ülevaade nimetab punkte, mis on praktikas osutunud oluliseks. See ei asenda juriidilist kontrolli, kuid aitab olemasolevas lepingus lünki ära tunda.
| Reguleerimispunkt | Mida tuleks fikseerida | Seos PHP2Shelliga |
|---|---|---|
| Teenuse maht | Millised kihid on hoolduse all: operatsioonisüsteem, PHP käitusaeg, veebiserver, CMS, pistikprogrammid, oma kood | PHP käitusaeg puudus loetelust sageli |
| Uuenduste tähtajad | astmestatud raskusastme järgi, erandireegliga hädaolukordadeks | kriitiline auk CVSS v4.0 9,2 |
| Taaskäivitus ja tõend | Uuendused loetakse tehtuks alles kõigi protsesside taaskäivitamise järel, kirjaliku tõendiga | ainult uued failid ei sulge auku |
| Teavitamine | aktiivne teavitus kriitiliste aukude korral, hinnangu ja plaaniga | paljud kliendid pidid ise järele küsima |
| Kaasabi intsidentide korral | Tugi analüüsil, kindlustamisel, taastamisel, kontaktisikud | jälgede otsimine pärast paika |
| Logid | liik, säilitamine, väljaandmine nõudmisel | erialaajakirjandus soovitas logisid alates 20. oktoobrist kindlustada |
| Ligipääsud | isiklikud kontod, kaheastmeline sisselogimine, kõigi ligipääsude nimekiri | kellel tegelikult ligipääs oli? |
| Allhankijad | kes veel osaleb, teavitus vahetuse korral | hostingupakkuja hostingupakkuja |
| Tarkvara eluea lõpp | vihje õigeaegselt enne toe lõppu, migratsiooniplaan | PHP 8.2 lõpeb 31. detsembril 2026 |
| Väljumine | andmete, dokumentatsiooni ja ligipääsude väljaandmine, õiguste äravõtmine | vahetus pärast intsidenti |
Tähtajad ja tõendid: punktid, mis kõige rohkem loevad
Tähtajad on tuum. Sõnastus nagu „viivitamatult“ ei aita hädaolukorras edasi. Leppige tähtajad kokku eraldi raskusastme kaupa ja määrake, mille järgi raskusastet mõõdetakse, näiteks tootja või BSI hinnangu järgi. Erakorraliste olukordade jaoks peaks kehtima hädaolukorra reegel: kes on kättesaadav, kes otsustab, kas süsteem ajutiselt võrgust eemaldatakse, ja kuidas lisatöö arveldatakse.
Sama oluline on tõend. PHP2Shelli puhul ütles kuvatav versiooninumber sageli vähe, sest distributsioonid ja hostingupakkujad paigaldavad parandusi tagasiportimisena. Töökindel tõend nimetab paketi seisu, paigaldamise ajahetke ja kõigi PHP protsesside taaskäivitamise. Millised andmed täpselt loevad, kirjeldab Kuidas küsida hostingupakkujalt paikamisseisu. Võtke need andmed lepingusse kohustusliku sisuna.
Laske teenusepakkujal anda lepingu juurde ülesannete maatriks: üks rida komponendi kohta, üks veerg ülesande kohta, igas lahtris nimi. Lüngad torkavad siis kohe silma, kaua enne järgmist teadet.
Ligipääsud, allhankijad ja väljumine
Teenusepakkujad vajavad ligipääse ja just need on sage ründetee. Reguleerige, et iga isik saab oma konto, et kaheastmeline sisselogimine on kohustuslik, kus tehnika seda lubab, ja et saate igal ajal nõuda kõigi ligipääsude ajakohast nimekirja. Teenusepakkuja lahkunud töötajad tuleb õigeaegselt kõigist süsteemidest eemaldada.
Kui teenusepakkuja töötab ise partneritega, näiteks andmekeskuse või spetsialiseeritud kriminalistikameeskonnaga, peaksite seda teadma. Kui üks neist partneritest töötleb isikuandmeid, lisanduvad andmekaitseõiguslikud kohustused. Rohkem artiklis Volitatud töötlemine, kui teenusepakkujad serveritele ligi pääsevad.
Väljumine unustatakse lepingu sõlmimisel kõige sagedamini. Fikseerige, et lepingu lõppedes antakse andmed, konfiguratsioon, dokumentatsioon ja ligipääsuandmed täielikult üle, teenusepakkuja kõik ligipääsud võetakse ära ja sellest antakse kirjalik kinnitus. Eriti pärast intsidenti on korrapärane vahetus muidu raske.
Olemasolevate lepingute kontroll: nii toimite
Te ei pea kõiki lepinguid uuesti läbi rääkima. Alustuseks piisab pragmaatilisest kulgemisest:
- Koguge kokku kõik lepingud agentuuride, hostingupakkujate ja IT-teenusepakkujatega, mis puudutavad veebisaite või servereid.
- Võrrelge iga lepingut ülaltoodud tabeliga ja märkige avatud punktid.
- Võtke olulisemad lüngad kirjalikult teenusepakkujaga üles, alustades teenuse mahust, tähtaegadest ja tõendist.
- Fikseerige tulemused täiendava kokkuleppena ja laske juriidiliselt kontrollida.
- Võtke ülesannete maatriks üle hädaolukorra plaani.
Juhtkonna jaoks on see samm ka hoolsuse küsimus. Kes reguleerib vastutused selgelt ja dokumenteerib otsused, on paremas seisus, kui hiljem küsimusi esitatakse. Tausta pakub Juhtkonna vastutus IT-turvaaukude korral. Hallatavate serverite tüüpilise tööjaotuse kirjeldab Managed Server: vastutuse selgitamine.
Kuidas PHP SOS konkreetselt aitab?
- Me loeme teie olemasolevaid lepinguid ja teenusekirjeldusi tehnilisest vaatenurgast ning märgime, millised komponendid ja ülesanded puuduvad.
- Me koostame ülesannete maatriksi kõigi veebisaitide ja serverite jaoks, mida saate oma teenusepakkujatega kooskõlastada.
- Me sõnastame tähtaegade, tõendite ja teavitusteede tehnilised nõuded, mida teie advokaat saab lepingusse üle võtta.
- Kus keegi ei vastuta, võtame ülesanded ise enda peale turvahoolduslepingu kaudu selgelt kirjeldatud mahuga.
Kokkuvõte: Hea leping ei hoia ära turvaauku, kuid hoiab ära, et hädaolukorras kaotataks aega vastutaja küsimusele. See leht on üldine teave ja ei ole õigusnõustamine.
Korduma kippuvad küsimused
Kas IT-teenusepakkuja peab turvauuendused paigaldama ilma tellimuseta?
See sõltub lepingust. Ilma selge reguleerimiseta on sageli vaidlustatav, kas uuendused kuuluvad võlgnetava teenuse hulka. Seetõttu peaks leping selgesõnaliselt fikseerima, kes millist komponenti uuendab ja millise tähtajaga. Õigusliku hinnangu eest üksikjuhul vastutab advokaat.
Kas vajan lisaks töötlemislepingut?
Kui teenusepakkuja töötleb tellimuse alusel isikuandmeid või pääseb neile ligi, on tavaliselt vaja IKÜM art 28 kohast volitatud töötleja lepingut. See ei asenda teenuselepingut, vaid täiendab seda. Selgitage seda oma andmekaitsespetsialistiga.
Millised tähtajad turvauuenduste jaoks on tavalised?
Kindlaid väärtusi ei ole. Mõistlik on astmestus raskusastme järgi, näiteks eraldi tähtajad kriitiliste, kõrgete ja ülejäänud aukude jaoks. Oluline on, et tähtajad on kirjalikult olemas ja sisaldavad erandi reeglit hädaolukordade jaoks, nagu PHP2Shell.
Mis juhtub ligipääsudega, kui leping lõpeb?
Seda peaks leping reguleerima: andmete tagastamine või kustutamine, ligipääsuandmete ja dokumentatsiooni väljaandmine, teenusepakkuja kõigi ligipääsude äravõtmine ja sellekohane kinnitus.