Lyhyesti: Staattinen verkkosivusto koostuu valmiista HTML-, CSS- ja kuvatiedostoista, jotka verkkopalvelin vain toimittaa. Koska palvelimella ei toimi PHP:tä eikä tietokantaa, aukot kuten PHP2Shell, SQL-injektio tai sisään tuodut web shellit poistuvat riskeinä pitkälti. Staattisen verkkosivuston tietoturvassa merkitsevät sen sijaan muut asiat: suojatut käyttöoikeudet hostingiin, verkkotunnukseen ja koontityökaluihin, ylläpidetyt riippuvuudet ja huolella valitut ulkoiset palvelut. Se sopii erityisesti verkkosivustoille, joita muutetaan harvoin ja jotka eivät tarvitse asiakastilejä.
Miksi kysymys esitetään juuri nyt
PHP2Shell on osoittanut monelle yritykselle, kuinka paljon yhden komponentin varassa on. Kymmenen sivun yrityssivusto, jota päivitetään kerran neljänneksessä, toimi samalla PHP:llä kuin suuri verkkokauppa ja oli siksi alttiina samalle kriittiselle aukolle. Mediaraporttien mukaan jopa viranomaiset ja kunnat ovat ottaneet verkkosivustoja varotoimena pois verkosta.
Silloin on luonnollista kysyä: tarvitsemmeko verkkosivustollemme ylipäätään PHP:tä palvelimella? Monille pienille ja keskisuurille yrityksille rehellinen vastaus on: toimitukseen usein ei. PHP tuottaa sivun uudelleen jokaisella kutsulla, vaikka sisältö ei ole muuttunut viikkoihin. Miten se teknisesti etenee, kuvaa sivu Miten PHP tuottaa verkkosivun. Mitä itse aukko tarkoittaa, selittää sivu Mitä PHP2Shell on?.
Miten staattinen verkkosivusto toimii
Staattisessa verkkosivustossa sivua ei tuoteta vierailun aikana vaan etukäteen. Staattisten sivujen generaattori, esimerkiksi Hugo, Jekyll tai Eleventy, ottaa tekstit, kuvat ja pohjat ja rakentaa niistä valmiita tiedostoja. Nämä tiedostot ladataan yksinkertaiselle verkkopalvelimelle tai sisällönjakeluverkkoon (CDN), eli hajautettuun toimitusverkkoon.
Sisällöntuottajille voi olla edessä muokkaustyökalu, joka ottaa muutokset vastaan ja käynnistää uudelleenrakennuksen. Osin siihen käytetään niin sanottua headless-CMS:ää, joka vain hallinnoi sisältöjä eikä itse tarvitse olla julkisesti tavoitettavissa. Kävijä ei näe siitä mitään; hän saa vain valmiit tiedostot.
Staattinen verkkosivusto ja tietoturva vertailussa
| Kriteeri | Dynaaminen PHP-CMS | Staattinen verkkosivusto |
|---|---|---|
| Ohjelmalogiikka julkisella palvelimella | Kyllä, jokaisella kutsulla | Ei |
| Riski PHP-tulkin aukoista | Kyllä, kuten PHP2Shellissä | Poistuu toimituspalvelimelta |
| Tietokanta julkisesti liitettynä | Kyllä | Ei |
| Tyypilliset sisäänkäynnit | Lisäosat, ylläpitäjän kirjautuminen, lataukset, palvelin | Hosting-, verkkotunnus- ja koontijärjestelmän käyttöoikeudet, ulkoiset palvelut |
| Lomakkeet, haku, asiakastili | Sisäänrakennettuja | Vain ulkoisten palvelujen tai erillisten toimintojen kautta |
| Sisällöntuottajien ylläpitovaiva | Pieni, tuttu käyttöliittymä | Riippuu toimitustyökalusta |
| Huolto | CMS:n, lisäosien ja PHP:n säännölliset päivitykset | Koontityökalujen ja riippuvuuksien päivitykset |
| Soveltuvuus | Verkkokaupat, portaalit, monta sisällöntuottajaa, usein muuttuva sisältö | Yrityssivut, laskeutumissivut, dokumentaatio |
Taulukko osoittaa: hyökkäyspinta-ala siirtyy, se ei katoa. Julkisesti tavoitettavan PHP-palvelimen sijaan teidän on suojattava hosting-tili, verkkotunnus, koontiputki ja tarvittaessa toimitustyökalu.
Mitkä riskit staattisilla verkkosivustoilla jäävät
Ensimmäiseksi käyttöoikeudet. Joka ottaa haltuunsa hosting-tilin, verkkotunnuksen käyttöoikeuden tai koodivaraston, voi muuttaa verkkosivustoa ilman PHP:tä. Kaksivaiheinen tunnistautuminen ja henkilökohtaiset tilit ovat siksi pakollisia.
Toiseksi riippuvuudet. Generaattorit ja pohjat tuovat usein mukanaan monta pakettia, esimerkiksi npm:stä. Ne on pidettävä ajan tasalla, koska vaarantunut riippuvuus voi koonnin aikana kirjoittaa haittakoodia valmiisiin tiedostoihin. Miten sen järjestätte, kuvaa sivu Riippuvuuksien pitäminen ajan tasalla.
Kolmanneksi ulkoiset palvelut. Lomakepalvelut, hakutoiminnot, analytiikkatyökalut ja sisäänrakennetut komentosarjat toimivat kävijöiden selaimessa tai vieraissa palvelimissa. Jokainen näistä palveluista on luottamussuhde, myös tietosuojan kannalta.
Neljänneksi selainpuoli. Myös staattisen sivun pitäisi asettaa tietoturvaotsakkeet, esimerkiksi Content-Security-Policy, joka määrittää, mitä komentosarjoja saa ladata. Perusteet löytyvät sivulta Verkkosivustojen tietoturvaotsakkeet.
Tarkistakaa ennen siirtymää, mitä toimintoja verkkosivustonne todella käyttää. Usein niitä on vähemmän kuin luulisi: sivuja, kuvia, yhteydenottolomake. Silloin tie staattiseen verkkosivustoon on lyhyempi kuin aluksi näyttää.
Kenelle siirtyminen kannattaa ja kenelle ei
Hyvin sopii staattinen verkkosivusto laajuudeltaan hallittaville yrityssivuille, kampanjoiden laskeutumissivuille, tuotedokumentaatioille ja urasivuille. Siirtyminen kannattaa erityisesti, jos nykyinen verkkosivusto toimii vanhalla PHP-versiolla ja päivitys olisi muutenkin edessä.
Vähemmän se sopii verkkokaupoille, asiakasportaaleille, varausjärjestelmille ja verkkosivustoille, joilla on paljon päivittäin julkaisevia sisällöntuottajia. Siellä dynaaminen järjestelmä pysyy järkevänä. Sekamalli voi auttaa: verkkokauppa pysyy dynaamisena ja se kovennetaan hyvin, oppaat ja yrityssivut toimitetaan staattisina.
Usein aliarvioitu etu näkyy hätätilanteessa. Koska valmiit tiedostot voidaan milloin tahansa rakentaa uudelleen pohjista ja sisällöistä, manipuloitu verkkosivusto voidaan palauttaa nopeasti tunnettuun, puhtaaseen tilaan. Edellytyksenä on, että sisällöt ja pohjat ovat suojatussa varastossa, muutokset kirjataan jäljitettävästi eikä kukaan muokkaa tiedostoja suoraan palvelimella.
Tietoturvapalveluntarjoajaa ette siirtymään välttämättä tarvitse; sen voi hoitaa toimisto tai kehittäjä. Jos aiempi verkkosivusto oli vaarantunut, sisällöt pitäisi kuitenkin tarkistaa ennen käyttöönottoa. Sitä käsittelee sivu Vaihdetaanko CMS hakkeroinnin jälkeen?.
Miten PHP SOS auttaa konkreettisesti?
- Tarkistamme, mitä toimintoja verkkosivustonne todella tarvitsee, ja kerromme avoimesti, sopiiko staattinen ratkaisu.
- Turvaamme siirtymässä hosting-, verkkotunnus- ja koontijärjestelmän käyttöoikeudet kaksivaiheisella tunnistautumisella ja henkilökohtaisilla tileillä.
- Tarkistamme ulkoiset palvelut ja asetamme tietoturvaotsakkeet, jotta uusi verkkosivusto on hyvin suojattu myös selaimessa.
- Pysyville PHP-järjestelmille hoidamme päivitykset ja valvonnan tietoturvahuoltosopimuksella.
Yhteenveto
Staattinen verkkosivusto ei ole yleislääke, mutta monille yrityssivuille yksinkertaisin tapa päästä eroon kokonaisesta riskien luokasta. Missä PHP:tä ei ole, PHP2Shell ei voi tehdä mitään. Saavutettu turvallisuus kestää kuitenkin vain, jos käyttöoikeuksia, riippuvuuksia ja ulkoisia palveluja kohdellaan yhtä vakavasti kuin ennen palvelinta.
Usein kysytyt kysymykset
Voiko staattisen verkkosivuston silti hakkeroida?
Kyllä. Palvelinpuolen ohjelmalogiikka poistuu ja sen mukana suuri hyökkäysten luokka. Hyökättävissä pysyvät kuitenkin hosting-, verkkotunnus- ja koontijärjestelmän käyttöoikeudet, sisäänrakennetut ulkoiset palvelut ja työkalut, joilla sivusto tuotetaan.
Voiko staattisella verkkosivustolla olla yhteydenottolomakkeita?
Kyllä, ulkoisen lomakepalvelun tai pienen, erikseen ylläpidetyn toiminnon kautta. Silloin tietojen käsittely on kyseisellä palvelulla. Selvittäkää tietosuoja ja henkilötietojen käsittelysopimus ennen sen liittämistä.
Voivatko sisällöntuottajat ylläpitää staattista verkkosivustoa itse?
Sopivalla toimitustyökalulla kyllä. Monet ratkaisut tarjoavat muokkausnäkymän, josta sivusto rakennetaan sen jälkeen uudelleen. Tiimeille, jotka muuttavat päivittäin paljon sisältöä, perinteinen CMS on kuitenkin usein kätevämpi.
Kannattaako verkkokaupan siirtyä staattiseen?
Yleensä ei kokonaan. Ostoskori, asiakastili ja maksu tarvitsevat palvelinpuolen logiikkaa. Mahdollista on toimittaa osia, kuten oppaat tai yrityssivut, staattisina ja ylläpitää verkkokauppaa erikseen.