Lyhyesti: Verkkopalvelinten IT-hätäsuunnitelma määrittää etukäteen, kuka hätätilanteessa päättää, ketä tavoitetaan, mitkä järjestelmät voivat olla vaarassa ja mitkä vaiheet etenevät missä järjestyksessä. Joka haluaa laatia IT-hätäsuunnitelman, ei tarvitse paksua käsikirjaa vaan muutaman ajantasaisen sivun, jotka ovat tavoitettavissa myös ilman toimivaa IT-järjestelmää. PHP2Shellin tilanne on hyvä syy tehdä se nyt.
Miksi hätäsuunnitelma säästää aikaa ja vahinkoa
Hätätilanteessa ensimmäiset tunnit kuluvat usein etsimiseen: kenellä on pääsy hosting-yritykseen? Missä varmuuskopiot ovat? Kuka päättää, menevätkö verkkokauppa offline-tilaan? Kenelle on tiedotettava? Hätäsuunnitelma vastaa näihin kysymyksiin etukäteen, rauhassa.
PHP2Shell on osoittanut, kuinka lyhyt aika voi olla. 20.10.2026 php.net ilmoitti korjauksista, 21.10. klo 16 Saksan aikaa ne julkaistiin, ja BSI suositteli välitöntä päivitystä tai tilapäistä sammutusta. Suunnitelman omaavat yritykset tiesivät, kenelle soittaa ja mitkä palvelimet tarkistaa. Toisten piti ensin selvittää, missä PHP ylipäätään pyörii.
IT-hätäsuunnitelman laatiminen: rakennuspalikat
Käytännöllinen suunnitelma verkkopalvelimille sisältää nämä osat:
1. Roolit ja päätökset. Kuka johtaa hätätilanteessa, kuka sijaistaa, kuka saa sammuttaa järjestelmiä, kuka puhuu ulospäin? Kirjaa nimet ja sijaisuudet.
2. Yhteystietoluettelo. Sisäiset yhteyshenkilöt, hosting-yritys, toimisto, IT-palveluntarjoaja, tietosuojavastaava, oikeudellinen neuvonta, kyberturvavakuutus vakuutusnumeroineen, toimivaltainen tietosuojan valvontaviranomainen, osavaltiosi Zentrale Ansprechstelle Cybercrime. Tämän luettelon on oltava tulostettuna.
3. Järjestelmäluettelo. Jokainen verkkosivusto, verkkokauppa ja portaali palvelimineen, hosting-yrityksineen, toimintatapoineen, PHP-versioineen, sovelluksineen, vastuuhenkilöineen ja käsiteltävien tietojen lajeineen.
4. Päätössäännöt. Millä ehdoilla otamme järjestelmän pois verkosta? Kuka saa päättää siitä? Mikä pätee öisin ja viikonloppuisin?
5. Toimintaohjeet. Lyhyet vaihejärjestykset tyypillisiin tapauksiin: kriittinen haavoittuvuus tiedossa, epäily murrosta, verkkosivusto turmeltu, tietoja vuotanut, kiristys.
6. Ilmoitustiet. Kuka tarkistaa ilmoitusvelvollisuuden GDPR:n 33 artiklan mukaan, mahdollisuuksien mukaan 72 tunnin kuluessa tiedon saamisesta? Kuka ilmoittaa NIS2-velvoitteen tapauksessa BSI:lle? Kuka tiedottaa vakuutusyhtiölle?
7. Palautus. Missä varmuuskopiot ovat, kuka voi palauttaa ne, kuinka kauan se kestää, milloin se on viimeksi testattu?
Esimerkki: toimintakulku ”kriittinen PHP-haavoittuvuus”
Näin toimintakulku voi näyttää, kuten PHP2Shellin kohdalla tarvittiin:
| Vaihe | Kuka | Tulos |
|---|---|---|
| Arvioi ilmoitus (php.net, BSI) | IT-vastuuhenkilöt | koskeneet järjestelmät luettelon mukaan |
| Asenna päivitys, käynnistä kaikki workerit uudelleen | Ylläpitäjä tai palveluntarjoaja | Todiste pakettitilalla ja prosessiajalla |
| Missä päivitys ei onnistu: väliaikaiset toimenpiteet tai pois verkosta | Johto päättää | dokumentoitu päätös |
| Turvaa lokit, tarkista jäljet | Ylläpitäjä tai forensiikka | Löydös tai ei löydöstä |
| Löydön tapauksessa: käynnistä poikkeamakulku | Hätäjohto | tarkista ilmoitustiet |
Tärkeää tässä: korjaus sulkee haavoittuvuuden, mutta ei poista aiemmin asennettua haittaohjelmaa. Siksi jälkien etsintä kuuluu kiinteästi kulkuun.
Määritä, kuinka kauan verkkopalvelimen lokeja säilytetään ja missä ne sijaitsevat palvelimen ulkopuolella. PHP2Shellin kohdalla ammattilehdistö suositteli säilyttämään lokit 20.10.2026 alkaen. Joka säilyttää lokeja vain muutaman päivän, ei voi toteuttaa tällaisia suosituksia.
Ennakointi, joka tekee suunnitelman tehokkaaksi
Suunnitelma on yhtä hyvä kuin sen taustalla olevat edellytykset. Tarkista, onko varmuuskopiot 3-2-1-säännön mukaan olemassa ja testattu, katso Varmuuskopiot 3-2-1-säännön mukaan. Sovi hosting-yrityksen ja toimiston kanssa kirjallisesti, kuka hoitaa mitä kriittisten haavoittuvuuksien kohdalla. Pidä hätätilanteen pääsytunnukset turvassa mutta tavoitettavissa, esimerkiksi suojatussa salasanaholvissa hätäpääsyllä.
Valmistele lisäksi tekstipohjat: sisäinen tiedote, asiakastiedote, ilmoitus staattisella huoltosivulla. Ohjeita on sivulla Kriisiviestintä hyökkäyksen jälkeen.
Harjoittele ja pidä ajan tasalla
Suunnitelmassa, jota ei ole koskaan harjoiteltu, on lähes aina aukkoja. Käy kerran vuodessa läpi yksi skenaario, esimerkiksi ”kriittinen PHP-haavoittuvuus perjantai-iltapäivänä”, ja kirjaa, missä takkuaa. Alkuun riittää yksinkertainen testi: pystyykö toinen henkilö ilman ensimmäisen apua tavoittamaan hosting-yrityksen, palauttamaan varmuuskopion ja asettamaan verkkosivuston huoltotilaan? Jos ei, suunnitelmasta puuttuu jotakin, yleensä pääsy, puhelinnumero tai kuvaus. Juuri tällaisia aukkoja harjoitusten on tarkoitus tuoda esiin, ennen kuin tilanne on tosissaan. Päivitä suunnitelma jokaisen harjoituksen ja jokaisen olennaisen muutoksen jälkeen. Menetelmälliseksi kehykseksi sopivat BSI:n IT-Grundschutz ja BSI-standardi 200-4 toiminnan jatkuvuuden hallinnasta (Business Continuity Management).
Oikeudellisia kysymyksiä, esimerkiksi ilmoitusvelvollisuuksista, suunnitelma ei ratkaise tyhjentävästi. Se huolehtii siitä, että oikeat henkilöt otetaan mukaan ajoissa. Tämä sivu on yleistä tietoa eikä oikeudellista neuvontaa.
Miten PHP SOS auttaa konkreettisesti?
- Laadimme kanssanne verkkopalvelimienne järjestelmäluettelon toimintatapoineen ja PHP-versioineen.
- Kirjoitamme tekniset toimintaohjeet tyypillisiin skenaarioihin ja sovimme ne hosting-yrityksen ja toimiston kanssa.
- Toteutamme harjoituksen ja viemme havainnot suunnitelmaan.
- Hätätilanteessa hoidamme teknisen puolen poikkeamien hallinnalla, halutessanne turvattuna tietoturvahuoltosopimuksella.
Usein kysytyt kysymykset
Kuinka laaja IT-hätäsuunnitelman pitää olla?
Mahdollisimman lyhyt, mutta riittävän yksityiskohtainen. Verkkopalvelimille riittää usein muutama sivu, joilla on yhteystiedot, järjestelmäluettelo, päätössäännöt ja toimintaohjeet. Laajuutta tärkeämpää on, että suunnitelma on ajan tasalla ja löytyy hätätilanteessa.
Missä säilytän hätäsuunnitelmaa?
Vähintään yhdessä paikassa, joka on tavoitettavissa myös ilman toimivaa IT-järjestelmää, esimerkiksi tulostettuna tai erillisellä laitteella. Suunnitelma, joka on vain vaarantuneella palvelimella tai lukitussa yritysverkossa, ei auta hätätilanteessa.
Kuinka usein suunnitelma tulisi tarkistaa?
Vähintään kerran vuodessa ja jokaisen olennaisen muutoksen jälkeen, esimerkiksi hosting-yrityksen vaihdon tai uuden ohjelmiston käyttöönoton yhteydessä. Järkevää on lyhyt harjoitus, jossa käydään läpi yksi skenaario.
Onko BSI:llä pohjia?
BSI (Saksan liittovaltion tietoturvavirasto) käsittelee häiriöiden hallintaa IT-Grundschutzin puitteissa ja BSI-standardissa 200-4 toiminnan jatkuvuuden hallinnasta (Business Continuity Management). Ne sopivat kehykseksi; verkkopalvelimille kannattaa tehdä tiivis, käytännönläheinen versio.