Lyhyesti: IT-palveluntarjoajan sopimuksessa tietoturva ei saisi olla vain sivuhuomautus vaan sen pitäisi sopia konkreettisesti: kuka päivittää mitkä komponentit, missä määräajassa ja millä todisteella, miten kriittisistä aukoista tiedotetaan, kuka osallistuu tapahtumaan, miten lokit säilytetään ja tunnukset hallitaan ja mitä tapahtuu poistuttaessa. Tämä sivu antaa yleisiä ohjeita eikä ole oikeudellista neuvontaa; sopimukset tarkistuttaa lakimiehellä.
Kysymys, jonka PHP2Shell esitti: kuka on vastuussa?
21.10.2026 kello 16 Saksan aikaa PHP-projekti julkaisi korjaukset. BSI (Saksan liittovaltion tietoturvavirasto) suositteli välitöntä päivitystä tai, missä se ei ollut mahdollista, verkkopalvelinten tilapäistä irrottamista verkosta. Monessa yrityksessä sen jälkeen ei alkanut työ vaan vastuuhenkilön etsintä. Toimisto viittasi hosting-palveluntarjoajaan, hosting-palveluntarjoaja sopimukseen, ja sopimuksessa luki ”huolto työmäärän mukaan”.
Tällaiset aukot sopimuksissa eivät ole yksittäistapaus. Monet toimistojen ja palveluntarjoajien sopimukset tehtiin, kun kyse oli verkkosivuston rakentamisesta, ei sen turvallisesta käytöstä vuosien ajan. PHP-ajoympäristön kriittinen aukko, joka ei koske CMS:ää eikä sovelluskoodia, putoaa silloin helposti kaikkien tuolien väliin.
Mitä IT-palveluntarjoajan sopimuksen tulisi sopia tietoturvasta
Seuraava yleiskatsaus nimeää kohdat, jotka ovat käytännössä osoittautuneet tärkeiksi. Se ei korvaa oikeudellista tarkistusta, mutta auttaa tunnistamaan aukot olemassa olevassa sopimuksessa.
| Sovittava kohta | Mitä tulisi kirjata | Yhteys PHP2Shelliin |
|---|---|---|
| Palvelun laajuus | Mitä kerroksia huolletaan: käyttöjärjestelmä, PHP-ajoympäristö, verkkopalvelin, CMS, laajennukset, oma koodi | PHP-ajoympäristö puuttui usein luettelosta |
| Päivitysmääräajat | porrastettu vakavuuden mukaan, poikkeussäännöllä hätätilanteisiin | kriittinen aukko, CVSS v4.0 9,2 |
| Uudelleenkäynnistys ja todiste | päivitykset katsotaan tehdyiksi vasta kaikkien prosessien uudelleenkäynnistyksen jälkeen, kirjallisella todisteella | uudet tiedostot yksin eivät sulje aukkoa |
| Tiedotus | aktiivinen ilmoitus kriittisistä aukoista arvion ja suunnitelman kanssa | monet asiakkaat joutuivat kysymään itse |
| Osallistuminen tapahtumiin | tuki analyysissä, varmistuksessa, palautuksessa, yhteyshenkilö | jälkien etsintä korjauksen jälkeen |
| Lokit | laji, säilytys, luovutus pyynnöstä | ammattilehdistö neuvoi varmistamaan lokit 20.10. alkaen |
| Tunnukset | henkilökohtaiset tilit, kaksivaiheinen tunnistautuminen, luettelo kaikista tunnuksista | kenellä oikeastaan oli pääsy? |
| Alihankkijat | ketkä muut ovat mukana, tiedotus vaihtuessa | hosting-palveluntarjoajan hosting-palveluntarjoaja |
| Ohjelmiston elinkaaren loppu | ilmoitus hyvissä ajoin ennen tuen päättymistä, migraatiosuunnitelma | PHP 8.2 päättyy 31.12.2026 |
| Poistuminen | tietojen, dokumentaation ja tunnusten luovutus, oikeuksien poisto | vaihto tapahtuman jälkeen |
Määräajat ja todisteet: tärkeimmät kohdat
Määräajat ovat ydin. Muotoilu kuten ”viipymättä” ei auta hätätilanteessa. Sopikaa määräajat erikseen vakavuuden mukaan ja määritelkää, mistä vakavuus mitataan, esimerkiksi valmistajan tai BSI:n luokituksesta. Poikkeuksellisia tilanteita varten tulisi olla hätäsääntö: kuka on tavoitettavissa, kuka päättää, irrotetaanko järjestelmä tilapäisesti verkosta, ja miten lisätyö laskutetaan.
Yhtä tärkeä on todiste. PHP2Shellin kohdalla näytetty versionumero kertoi usein vähän, koska jakelut ja hosting-palveluntarjoajat asentavat korjaukset backportina. Kestävä todiste nimeää paketin tilan, asennuksen ajankohdan ja kaikkien PHP-prosessien uudelleenkäynnistyksen. Mitkä tiedot tarkalleen ratkaisevat, kuvaa Näin kysytte hosting-palveluntarjoajaltanne korjaustilaa. Ottakaa nämä tiedot sopimukseen pakolliseksi sisällöksi.
Pyytäkää palveluntarjoajalta sopimukseen vastuumatriisi: yksi rivi komponenttia kohden, yksi sarake tehtävää kohden, jokaisessa solussa nimi. Aukot huomataan silloin heti, kauan ennen seuraavaa ilmoitusta.
Tunnukset, alihankkijat ja poistuminen
Palveluntarjoajat tarvitsevat tunnuksia, ja juuri ne ovat yleinen hyökkäystie. Sopikaa, että jokainen henkilö saa oman tilin, että kaksivaiheinen tunnistautuminen on pakollinen, missä tekniikka sen sallii, ja että voitte milloin tahansa pyytää ajantasaisen luettelon kaikista tunnuksista. Palveluntarjoajan eronneet työntekijät on poistettava kaikista järjestelmistä viipymättä.
Jos palveluntarjoaja työskentelee itse kumppaneiden kanssa, esimerkiksi konesalin tai erikoistuneen forensiikkatiimin kanssa, teidän kannattaa tietää se. Jos jokin näistä kumppaneista käsittelee henkilötietoja, tulee lisäksi tietosuojaoikeudellisia velvoitteita. Lisää aiheesta kirjoituksessa Henkilötietojen käsittely, kun palveluntarjoajat pääsevät palvelimelle.
Poistuminen unohdetaan useimmin sopimusta tehtäessä. Kirjatkaa, että sopimuksen päättyessä tiedot, konfiguraatio, dokumentaatio ja tunnukset luovutetaan kokonaan, palveluntarjoajan kaikki tunnukset poistetaan ja tämä vahvistetaan kirjallisesti. Juuri tapahtuman jälkeen hallittu vaihto on muuten vaikeaa.
Olemassa olevien sopimusten tarkistus: näin etenette
Teidän ei tarvitse neuvotella kaikkia sopimuksia uudelleen. Pragmaattinen kulku riittää alkuun:
- Keratkaa kaikki toimistojen, hosting-palveluntarjoajien ja IT-palveluntarjoajien sopimukset, jotka koskevat verkkosivustoja tai palvelimia.
- Verratkaa jokaista sopimusta yllä olevaan taulukkoon ja merkitkää avoimet kohdat.
- Ottakaa tärkeimmät aukot kirjallisesti puheeksi palveluntarjoajan kanssa, aloittaen palvelun laajuudesta, määräajoista ja todisteesta.
- Kirjatkaa tulokset täydennyssopimukseksi ja tarkistuttakaa se oikeudellisesti.
- Ottakaa vastuumatriisi mukaan varautumissuunnitelmaan.
Johdolle tämä vaihe on myös huolellisuuden kysymys. Joka sopii vastuut selkeästi ja dokumentoi päätökset, on paremmassa asemassa, jos myöhemmin esitetään kysymyksiä. Taustaa tarjoaa Johdon vastuu IT-turvallisuusaukoista. Tyypillisen työnjaon hoidetuilla palvelimilla kuvaa Managed Server: vastuun selvittäminen.
Miten PHP SOS auttaa konkreettisesti?
- Luemme olemassa olevat sopimuksenne ja palvelukuvauksenne teknisestä näkökulmasta ja merkitsemme, mitkä komponentit ja tehtävät puuttuvat.
- Laadimme vastuumatriisin kaikille verkkosivustoille ja palvelimille, jonka voitte sopia palveluntarjoajienne kanssa.
- Muotoilemme määräaikoja, todisteita ja ilmoitusreittejä koskevat tekniset vaatimukset, jotka lakimiehenne voi ottaa sopimukseen.
- Missä kukaan ei ole vastuussa, otamme tehtävät itse hoitaaksemme security-huoltosopimuksella, jonka laajuus on kuvattu selkeästi.
Yhteenveto: Hyvä sopimus ei estä tietoturva-aukkoa, mutta se estää, ettei hätätilanteessa hukata aikaa vastuukysymykseen. Tämä sivu on yleistä tietoa eikä oikeudellista neuvontaa.
Usein kysytyt kysymykset
Onko IT-palveluntarjoajan asennettava tietoturvapäivitykset ilman toimeksiantoa?
Se riippuu sopimuksesta. Ilman selkeää sääntöä on usein kiistanalaista, kuuluvatko päivitykset velvoitettuun suoritukseen. Sopimuksessa tulisi siksi nimenomaisesti todeta, kuka päivittää mitkä komponentit ja missä määräajassa. Oikeudellisen arvion yksittäistapauksessa tekee lakimies.
Tarvitsenko lisäksi käsittelijäsopimuksen (AVV)?
Jos palveluntarjoaja käsittelee henkilötietoja toimeksiannosta tai voi päästä niihin käsiksi, tarvitaan yleensä GDPR:n 28 artiklan mukainen henkilötietojen käsittelyä koskeva sopimus. Se ei korvaa palvelusopimusta vaan täydentää sitä. Selvittäkää asia tietosuojavastaavanne kanssa.
Mitkä määräajat tietoturvapäivityksille ovat yleisiä?
Kiinteitä arvoja ei ole. Järkevää on porrastus vakavuuden mukaan, esimerkiksi erilliset määräajat kriittisille, korkeille ja muille aukoille. Tärkeää on, että määräajat ovat kirjallisia ja että niihin sisältyy poikkeussääntö hätätilanteille kuten PHP2Shell.
Mitä tunnuksille tapahtuu, kun sopimus päättyy?
Se tulisi sopia sopimuksessa: tietojen palautus tai poisto, tunnusten ja dokumentaation luovutus, kaikkien palveluntarjoajan tunnusten poisto ja vahvistus siitä.