Trumpai: sutartis su IT paslaugų teikėju saugumo neturėtų minėti tik prabėgomis, o reglamentuoti konkrečiai: kas kuriuos komponentus atnaujina, per kokį terminą ir su kokiu įrodymu, kaip informuojama apie kritines spragas, kas dalyvauja incidento metu, kaip saugomi žurnalai ir valdomos prieigos bei kas vyksta išeinant. Šis puslapis pateikia bendrus nurodymus ir nėra teisinė konsultacija; sutartis tikrina advokatas.
Klausimas, kurį iškėlė PHP2Shell: kas atsakingas?
2026 m. spalio 21 d. 16 val. Vokietijos laiku PHP projektas paskelbė pataisas. BSI (Vokietijos federalinė informacijos saugumo tarnyba) rekomendavo atnaujinti nedelsiant arba, kur tai neįmanoma, laikinai atjungti žiniatinklio serverius nuo tinklo. Daugelyje įmonių po to prasidėjo ne darbas, o atsakomybės paieška. Agentūra nukreipė į talpinimo teikėją, talpinimo teikėjas į sutartį, o sutartyje buvo parašyta „priežiūra pagal sąnaudas“.
Tokie sutarčių trūkumai nėra pavienis atvejis. Daug sutarčių su agentūromis ir paslaugų teikėjais sudaryta, kai kalbėta apie svetainės sukūrimą, o ne apie jos saugų eksploatavimą daugelį metų. Kritinė PHP vykdymo aplinkos spraga, nepaveikianti nei CMS, nei programos kodo, tada lengvai nukrinta tarp visų kėdžių.
Ką IT paslaugų teikėjo sutartis turėtų nustatyti dėl saugumo
Toliau pateikta apžvalga nurodo punktus, kurie praktikoje pasirodė svarbūs. Ji nepakeičia teisinės patikros, bet padeda atpažinti esamos sutarties spragas.
| Reguliuojamas punktas | Ką reikėtų užfiksuoti | Ryšys su PHP2Shell |
|---|---|---|
| Paslaugų apimtis | kurie sluoksniai prižiūrimi: operacinė sistema, PHP vykdymo aplinka, žiniatinklio serveris, CMS, papildiniai, savas kodas | PHP vykdymo aplinkos sąraše dažnai trūko |
| Atnaujinimų terminai | pakopomis pagal sunkumą, su išimties taisykle ypatingoms situacijoms | kritinė spraga su CVSS v4.0 9,2 |
| Paleidimas iš naujo ir įrodymas | atnaujinimai laikomi atliktais tik paleidus iš naujo visus procesus, su raštišku įrodymu | vien nauji failai spragos neuždaro |
| Informavimas | aktyvus pranešimas apie kritines spragas, su įvertinimu ir planu | daugelis klientų patys turėjo klausti |
| Dalyvavimas incidentų metu | pagalba analizei, išsaugojimui, atkūrimui, kontaktinis asmuo | pėdsakų paieška po pataisos |
| Žurnalai | rūšis, saugojimas, perdavimas pareikalavus | specializuota spauda patarė saugoti žurnalus nuo spalio 20 d. |
| Prieigos | asmeninės paskyros, dviejų veiksnių autentifikavimas, visų prieigų sąrašas | kas iš tikrųjų turėjo prieigą? |
| Subrangovai | kas dar dalyvauja, informavimas keičiantis | talpinimo teikėjo talpinimo teikėjas |
| Programinės įrangos gyvavimo pabaiga | įspėjimas laiku prieš palaikymo pabaigą, migracijos planas | PHP 8.2 baigiasi 2026 m. gruodžio 31 d. |
| Išėjimas | duomenų, dokumentacijos ir prieigų perdavimas, teisių panaikinimas | pasikeitimas po incidento |
Terminai ir įrodymai: svarbiausi punktai
Terminai yra esmė. Formuluotė kaip „nedelsiant“ ištikus nelaimei nepadeda. Susitarkite dėl terminų atskirai pagal sunkumą ir nustatykite, pagal ką matuojamas sunkumas, pavyzdžiui, pagal gamintojo ar BSI įvertinimą. Išskirtinėms situacijoms turėtų galioti ypatingų atvejų taisyklė: kas pasiekiamas, kas sprendžia, ar sistema laikinai atjungiama nuo tinklo, ir kaip apmokestinamos papildomos sąnaudos.
Taip pat svarbus įrodymas. Su PHP2Shell rodomas versijos numeris dažnai sakė mažai, nes distribucijos ir talpinimo teikėjai pataisas diegia kaip atgalinį perkėlimą (backport). Patikimas įrodymas nurodo paketo būseną, įdiegimo momentą ir visų PHP procesų paleidimą iš naujo. Kokie duomenys tiksliai svarbūs, aprašo Kaip paklausti talpinimo teikėjo apie pataisų būseną. Šiuos duomenis įtraukite į sutartį kaip privalomą turinį.
Paprašykite paslaugų teikėjo pateikti užduočių matricą prie sutarties: viena eilutė kiekvienam komponentui, vienas stulpelis kiekvienai užduočiai, kiekvienoje langelyje vardas. Spragos tada krenta į akis nedelsiant, gerokai prieš kitą pranešimą.
Prieigos, subrangovai ir išėjimas
Paslaugų teikėjams reikia prieigų, o būtent jos dažnai yra atakos kelias. Nustatykite, kad kiekvienas asmuo gauna savo paskyrą, kad dviejų veiksnių autentifikavimas privalomas, kur technika leidžia, ir kad bet kada galite pareikalauti aktualaus visų prieigų sąrašo. Iš paslaugų teikėjo pasitraukę darbuotojai turi būti laiku pašalinti iš visų sistemų.
Jei paslaugų teikėjas pats dirba su partneriais, pavyzdžiui, duomenų centru ar specializuota forenzikos komanda, turėtumėte tai žinoti. Jei vienas iš šių partnerių tvarko asmens duomenis, atsiranda duomenų apsaugos teisinės pareigos. Daugiau apie tai straipsnyje Užsakomasis duomenų tvarkymas, kai paslaugų teikėjai prieina prie serverių.
Išėjimas sudarant sutartį pamirštamas dažniausiai. Užfiksuokite, kad pasibaigus sutarčiai duomenys, konfigūracija, dokumentacija ir prisijungimo duomenys perduodami pilnai, visos paslaugų teikėjo prieigos panaikinamos ir tai patvirtinama raštu. Būtent po incidento tvarkingas pasikeitimas kitaip sunkus.
Esamų sutarčių patikra: kaip elgtis
Visų sutarčių iš naujo derėtis nereikia. Pradžiai pakanka pragmatiškos eigos:
- Surinkti visas sutartis su agentūromis, talpinimo ir IT paslaugų teikėjais, liečiančias svetaines ar serverius.
- Kiekvieną sutartį sulyginti su aukščiau pateikta lentele ir pažymėti atviras vietas.
- Svarbiausias spragas raštu aptarti su paslaugų teikėju, pradedant paslaugų apimtimi, terminais ir įrodymu.
- Rezultatus užfiksuoti kaip papildomą susitarimą ir leisti jį teisiškai patikrinti.
- Užduočių matricą perkelti į avarinių veiksmų planą.
Vadovybei šis žingsnis taip pat yra rūpestingumo klausimas. Kas aiškiai reglamentuoja atsakomybes ir dokumentuoja sprendimus, stovi geriau, jei vėliau būtų užduodami klausimai. Pagrindus pateikia Vadovybės atsakomybė už IT saugumo spragas. Tipinį užduočių pasidalijimą prižiūrimuose serveriuose aprašo Valdomas serveris: išsiaiškinti atsakomybę.
Kaip PHP SOS padeda konkrečiai?
- Skaitome jūsų esamas sutartis ir paslaugų aprašymus techniniu požiūriu ir pažymime, kokių komponentų ir užduočių trūksta.
- Parengiame visoms svetainėms ir serveriams užduočių matricą, kurią galite suderinti su savo paslaugų teikėjais.
- Suformuluojame techninius reikalavimus terminams, įrodymams ir pranešimo keliams, kuriuos jūsų advokatas gali perkelti į sutartį.
- Kur niekas neatsakingas, užduotis perimame patys per saugumo priežiūros sutartį su aiškiai aprašyta apimtimi.
Išvada: gera sutartis saugumo spragos neužkerta, bet neleidžia ištikus nelaimei prarasti laiko klausimui, kas atsakingas. Šis puslapis yra bendra informacija ir nėra teisinė konsultacija.
Dažni klausimai
Ar IT paslaugų teikėjas privalo įdiegti saugumo atnaujinimus be užsakymo?
Tai priklauso nuo sutarties. Be aiškaus sutarimo dažnai ginčytina, ar atnaujinimai priklauso įsipareigotai paslaugai. Todėl sutartyje turėtų būti aiškiai nurodyta, kas kuriuos komponentus atnaujina ir per kokį terminą. Teisinį vertinimą konkrečiu atveju atlieka advokatas.
Ar papildomai reikia duomenų tvarkymo sutarties (AVV)?
Jei paslaugų teikėjas užsakymu tvarko asmens duomenis arba gali prie jų prieiti, paprastai reikalinga duomenų tvarkymo sutartis pagal BDAR 28 straipsnį. Ji nepakeičia paslaugų sutarties, o ją papildo. Tai išsiaiškinkite su savo duomenų apsaugos pareigūnu.
Kokie saugumo atnaujinimų terminai įprasti?
Fiksuotų reikšmių nėra. Prasminga pakopinė skalė pagal sunkumą, pavyzdžiui, atskiri terminai kritinėms, didelėms ir kitoms spragoms. Svarbu, kad terminai būtų užrašyti ir turėtų išimties taisyklę ypatingoms situacijoms kaip PHP2Shell.
Kas nutinka su prieigomis, kai sutartis baigiasi?
Tai turėtų reglamentuoti sutartis: duomenų grąžinimas ar ištrynimas, prisijungimo duomenų ir dokumentacijos perdavimas, visų paslaugų teikėjo prieigų panaikinimas ir apie tai patvirtinimas.