Lyhyesti: Jos haluatte vaihtaa hosting-yritystä tietoturvatapauksen jälkeen, varmistakaa ensin todisteet ja selvittäkää tapaus, siirtäkää sitten vain tarkistettua dataa uudelleen pystytettyyn järjestelmään ja päättäkää vanha sopimus vasta sen jälkeen. Uuden toimittajan valitsette tietoturvakriteerien mukaan: todennettavat korjauskäytännöt, asiakkaiden erottelu, pääsy lokeihin, varmuuskopiot ja selkeät yhteyshenkilöt. Hosting-yrityksen vaihto on järkevää, kun luottamus tai suorituskyky puuttuu, mutta se ei korvaa siivousta.
Kun luottamus on mennyt
PHP2Shellin jälkeen monet yritykset kokevat hosting-yrityksensä ensimmäistä kertaa paineen alla. Jotkut saivat nopeasti selkeän vastauksen korjaustilasta. Toiset odottivat vastausta päiväkausia, saivat vain yleisluontoisia kaavoja tai huomasivat, että heidän verkkosivustonsa toimi vanhentuneella PHP-versiolla. Jos tähän vielä lisätään tietoturvatapaus, halu vaihtaa toimittajaa on ymmärrettävä.
Hosting-yrityksen vaihto ei kuitenkaan kuulu tapauksen hoitamiseen vaan sen jälkeiseen uudelleenjärjestelyyn. Jos sen tekee väärässä järjestyksessä, pahimmassa tapauksessa vie hyökkääjän mukanaan ja menettää samalla jäljet, jotka kertovat, mitä tapahtui.
Vaihdon oikea järjestys
- Varmistakaa jäljet, kun ne vielä ovat olemassa. Vanhan järjestelmän lokit, tiedostot ja tietokanta kuuluvat varmuuskopioon, ennen kuin mitään poistetaan tai irtisanotaan. Kysykää vanhalta hosting-yritykseltä nimenomaisesti pääsy- ja virhelokeja 20. lokakuuta 2026 alkaen sekä niiden säilytysaikaa. Miten toimia, kuvaa artikkeli Todisteiden varmistaminen ennen uudelleenasennusta.
- Rajatkaa tapaus. Mitkä järjestelmät ovat vaarantuneet, mitä tunnuksia on käytetty, mitä tietoja oli saavutettavissa? Tästä riippuvat ilmoitusvelvollisuudet ja se, mitä saatte viedä mukanne.
- Tarkistakaa ilmoitusvelvollisuudet. Jos henkilötiedot voivat olla vaarantuneet, mahdollisen GDPR-ilmoituksen määräaika alkaa tapauksen havaitsemisesta, ei muutosta. Taustatietoja löytyy sivulta GDPR-ilmoitusvelvollisuus: 72 tuntia.
- Pystyttäkää uusi järjestelmä puhtaasti. Tuettu PHP-versio, ajantasaiset paketit ja koventettu konfiguraatio ennen kuin ensimmäistäkään tiedostoa siirretään.
- Siirtäkää vain tarkistettu. Koodi puhtaasta lähteestä, tietokanta ja media tarkistuksen jälkeen.
- Vaihtakaa kaikki tunnukset. Tietokanta, ylläpitäjätilit, SSH, FTP ja API-avaimet, myös asetustiedostoihin tallennetut.
- Siirtykää uuteen ja tarkkailkaa. DNS-muutos, sen jälkeen jonkin aikaa tiiviimpi seuranta.
- Päättäkää vanha sopimus. Vasta kun lokit ja varmuuskopiot on turvattu ja uusi toiminta on vakaata.
Älkää irtisanoko vanhaa sopimusta, ennen kuin lokit ja varmuuskopiot ovat hallussanne. Sopimuksen päättyessä toimittaja voi poistaa tietoja, joita tarvitsette vakuutusyhtiölle, viranomaisille tai oman selvityksenne tekemiseen.
Mitä ei kannata viedä mukana
Olisi mukavaa kopioida koko verkkohakemisto tai palvelimen kuva sellaisenaan. Juuri se on tapauksen jälkeen riskialtista. Web shellit naamioituvat harmittomiksi tiedostoiksi, takaovet piilevät asetustiedostoissa, kuten .htaccess tai .user.ini, ja lisätty koodi voi olla tietokannan sisällössä.
Siirtäkää sovelluskoodi siksi puhtaasta lähteestä, esimerkiksi valmistajan paketista oikeassa versiossa tai versionhallinnasta. Median otatte mukaan ilman suoritettavia tiedostoja ja tietokannan sen jälkeen, kun siitä on etsitty epäilyttävää sisältöä ja uusia ylläpitäjätilejä. Vanhalta järjestelmältä löydetty auttaa tässä tarkistuksessa.
Ajatelkaa myös kaikkea, mitä vanhalla toimittajalla on verkkosivuston rinnalla. Sähköpostilaatikot, DNS-merkinnät, varmenteet ja uudelleenohjaukset unohtuvat siirrossa helposti. Lyhentäkää DNS-merkintöjen voimassaoloaikaa muutama päivä ennen vaihtoa, jotta muutos tavoittaa kävijät nopeasti. Jos sähköpostit muuttavat mukana, suunnitelkaa postilaatikoiden vaihto erikseen, sillä myös niissä tunnukset voivat olla vaarantuneet tapauksen jälkeen.
Uuden hosting-yrityksen valinta tietoturvan perusteella
Hinta ja tallennustila ovat jokaisessa tarjouksessa. Ratkaisevat tietoturvakysymykset joudutte yleensä esittämään itse. Seuraava luettelo auttaa vertailussa:
| Kriteeri | Kysymys toimittajalle | Miksi sillä on väliä |
|---|---|---|
| Korjauskäytäntö | Miten ja missä puitteissa PHP-tietoturvapäivitykset asennetaan ja palvelut käynnistetään uudelleen? | PHP2Shell osoitti, kuinka tärkeä todennettavissa oleva käytäntö on |
| Todiste | Saanko pyynnöstä kirjallisen vahvistuksen korjaustilasta? | Perusta omalle dokumentaatiollenne |
| PHP-versiot | Mitä haaroja tarjotaan ja kuinka kauan vielä? | Vanhat haarat ilman päivityksiä ovat pysyvä riski |
| Erottelu | Toimiiko jokainen verkkosivusto omalla käyttäjällä ja omalla PHP-prosessilla? | Rajoittaa vahinkoa, jos naapuriin hyökätään |
| Lokit | Onko minulla pääsy pääsy- ja virhelokeihin, kuinka kauan niitä säilytetään? | Ilman lokeja ei ole selvitystä |
| Varmuuskopiot | Kuinka usein, kuinka kauan, verkkopalvelimesta erillään ja palautustestillä? | Palautus tapauksen jälkeen |
| Hätäyhteys | Miten tavoitan tapauksessa asiantuntevan henkilön? | Aika on hätätilanteessa niukin tekijä |
| Henkilötietojen käsittely | Onko GDPR:n mukainen sopimus ja luettelo alihankkijoista? | Pakollinen, kun käsitellään henkilötietoja |
Pohjan korjaustilan kysymiseen tarjoaa opas Hosting-yrityksen PHP-korjaustilan kysyminen. Se sopii myös toimittajien vertailuun ennen sopimuksen tekoa.
Onko toinen toimintamalli parempi vastaus?
Joskus ongelma ei ole niinkään hosting-yrityksessä kuin toimintamallissa. Jos ylläpidätte omaa palvelinta ilman säännöllistä huoltoa, hyvin hoidettu hallinnoitu tarjous sopii usein paremmin. Toisaalta oman IT-osaston yritys voi saada enemmän kontrollia korjausten ajoitukseen, kun hallinnoi itse. Punninnan kuvaa artikkeli Hallinnoitu hosting vai oma palvelin?.
Mallista riippumatta pätee: kirjatkaa vastuunjako kirjallisesti. Kuka asentaa PHP-päivitykset, kuka käynnistää uudelleen, kuka tarkistaa sovelluksen, kuka ottaa kehen yhteyttä hätätilanteessa? PHP2Shellissä monet viiveet syntyivät juuri tässä, koska kumpikin osapuoli luuli toisen hoitavan asian.
Miten PHP SOS auttaa konkreettisesti?
- Varmistamme vanhan järjestelmän lokit ja tiedot ja selvitämme, mitä tapauksessa tapahtui.
- Rakennamme uuden järjestelmän koventaen ja siirrämme vain tarkistettua sisältöä puhtaista lähteistä.
- Tarkistamme uusien toimittajien tarjoukset tietoturvakriteerien mukaan ja esitämme oikeat kysymykset.
- Käynnissä olevassa tapauksessa työskentelemme Incident Response -palvelumme puitteissa, kunnes tapaus on käsitelty loppuun ja dokumentoitu.
Usein kysytyt kysymykset
Pitäisikö hosting-yritys vaihtaa heti murron jälkeen?
Ei heti. Ensin on varmistettava jäljet, rajattava tapaus ja selvitettävä syy. Hätäinen siirto voi viedä haittakoodin mukanaan ja tuhota todisteita vanhalla toimittajalla.
Oliko hosting-yritys syypää, jos verkkosivustooni hyökättiin PHP2Shellin kautta?
Se riippuu sopimuksesta ja ajankohdasta. Jaetussa hostingissa PHP-päivityksistä vastaa yleensä hosting-yritys, omilla palvelimilla ylläpitäjä. Korjaukset julkaistiin 21. lokakuuta 2026; sen, asennettiinko ne ja milloin, voi selvittää vain todisteilla. Vastuukysymyksissä käyttäkää lakimiehen apua.
Mitä tietoja saan viedä uudelle hosting-yritykselle?
Vain tarkistettua sisältöä: tietokanta sen jälkeen, kun siitä on etsitty lisättyä koodia, mediatiedostot ilman suoritettavia tiedostoja ja koodi puhtaasta lähteestä, kuten valmistajan paketista tai versionhallinnasta. Älkää siirtäkö tarkistamatta kokonaisia palvelinkuvia tai verkkohakemistoja vaarantuneesta järjestelmästä.
Pitääkö tietosuoja ottaa huomioon tapauksen jälkeen?
Jos henkilötiedot voivat olla vaarantuneet, GDPR:n mukainen ilmoitusvelvollisuus voi olla voimassa, yleensä 72 tunnin kuluessa. Uudelta hosting-yritykseltä tarvitsette lisäksi henkilötietojen käsittelysopimuksen. Selvittäkää asia tietosuojavastaavanne kanssa; tämä ei ole oikeudellista neuvontaa.