Lühidalt: Staatiline veebisait koosneb valmis HTML-, CSS- ja pildifailidest, mida veebiserver ainult väljastab. Kuna serveris ei tööta PHP-d ega andmebaasi, kaovad riskina suures osas ära turvaaugud nagu PHP2Shell, SQL-süstimine või sisse toodud veebishellid. Staatilise veebisaidi turvalisuse jaoks loevad selle asemel muud asjad: kaitstud ligipääsud majutusele, domeenile ja ehitusvahenditele, hooldatud sõltuvused ning hoolikalt valitud kolmanda poole teenused. See sobib eelkõige veebisaitidele, mida muudetakse harva ja mis ei vaja kliendikontosid.
Miks seda küsimust just praegu esitatakse
PHP2Shell on paljudele ettevõtetele näidanud, kui palju sõltub ühest ainsast komponendist. Kümne lehega ettevõtte veebisait, mida uuendatakse kord kvartalis, töötas samal PHP-l nagu suur e-pood ja oli seega sama kriitilise turvaaugu all. Meediaaruannete kohaselt lülitasid isegi ametiasutused ja omavalitsused veebisaite ennetavalt välja.
Siit tuleb küsimus: kas me üldse vajame oma veebisaidi jaoks serveris PHP-d? Paljude väikeste ja keskmise suurusega ettevõtete puhul on aus vastus: väljastamiseks sageli mitte. PHP loob iga päringu korral lehe uuesti, kuigi sisu ei ole nädalaid muutunud. Kuidas see tehniliselt kulgeb, kirjeldab artikkel Kuidas PHP veebilehte loob. Mida turvaauk ise tähendab, selgitab Mis on PHP2Shell?.
Kuidas staatiline veebisait toimib
Staatilise veebisaidi puhul ei looda lehte külastuse ajal, vaid enne. Staatiliste lehtede generaator, näiteks Hugo, Jekyll või Eleventy, võtab tekstid, pildid ja mallid ning ehitab neist valmis failid. Need failid laaditakse lihtsale veebiserverile või sisuedastusvõrku (Content Delivery Network), see tähendab hajutatud väljastusvõrku.
Toimetajate jaoks võib selle ette paigutada muutmisvahend, mis võtab muudatused vastu ja käivitab uuesti ehitamise. Osaliselt kasutatakse selleks nn Headless-CMS-i, mis haldab ainult sisu ega pea ise avalikult ligipääsetav olema. Külastaja sellest midagi ei näe; ta saab ainult valmis failid.
Staatiline veebisait ja turvalisus võrdluses
| Kriteerium | Dünaamiline PHP-põhine CMS | Staatiline veebisait |
|---|---|---|
| Programmiloogika avalikul serveril | Jah, iga päringu korral | Ei |
| Risk PHP interpretaatori turvaaukudest | Jah, nagu PHP2Shelli puhul | Väljastusserveril ära jääb |
| Andmebaas avalikult ühendatud | Jah | Ei |
| Tüüpilised sissepääsuväravad | Pistikprogrammid, administraatori sisselogimine, üleslaadimised, server | Ligipääsud majutusele, domeenile, ehitussüsteemile, kolmanda poole teenused |
| Vormid, otsing, kliendikonto | Sisseehitatud | Ainult väliste teenuste või eraldi funktsioonide kaudu |
| Hoolduse vaev toimetajatele | Väike, harjumuspärane liides | Sõltub toimetamisvahendist |
| Hooldus | CMS-i, pistikprogrammide ja PHP korrapärased uuendused | Ehitusvahendite ja sõltuvuste uuendused |
| Sobivus | Poed, portaalid, palju toimetajaid, sagedased muudatused | Ettevõtte veebisaidid, maandumislehed, dokumentatsioon |
Tabel näitab: ründepind nihkub, see ei kao. Avalikult ligipääsetava PHP serveri asemel peate kaitsma majutaja konto, domeeni, ehitusliini ja vajaduse korral toimetamisvahendi.
Millised riskid staatiliste veebisaitide juures jäävad
Esiteks ligipääsud. Kes võtab üle majutuskonto, domeeniligipääsu või koodihoidla, saab veebisaiti muuta, täiesti ilma PHP-ta. Kaheastmeline sisselogimine ja isiklikud kontod on seetõttu kohustuslikud.
Teiseks sõltuvused. Generaatorid ja mallid toovad sageli kaasa palju pakette, näiteks npm-ist. Need tuleb hoida ajakohasena, sest kompromiteeritud sõltuvus võib ehitamisel kirjutada kahjuliku koodi valmis failidesse. Kuidas seda korraldada, kirjeldab artikkel Sõltuvuste ajakohasena hoidmine.
Kolmandaks kolmanda poole teenused. Vormiteenused, otsingufunktsioonid, analüüsivahendid ja integreeritud skriptid töötavad külastajate brauseris või võõrastel serveritel. Iga selline teenus on usaldussuhe, ka andmekaitseõiguslikult.
Neljandaks brauseripool. Ka staatiline leht peaks seadma turvapäised, näiteks Content-Security-Policy, mis määrab, milliseid skripte tohib laadida. Alused leiate artiklist Turvapäised veebisaitidele.
Kontrollige enne ülemineku, milliseid funktsioone teie veebisait tegelikult kasutab. Sageli on neid vähem, kui arvatakse: lehed, pildid, kontaktivorm. Siis on tee staatilise veebisaidini lühem, kui esialgu paistab.
Kellele üleminek tasub ja kellele mitte
Hästi sobib staatiline veebisait ülevaadatava mahuga ettevõtte lehtedele, kampaaniate maandumislehtedele, tootedokumentatsioonile ja karjäärilehtedele. Üleminek tasub eriti siis, kui senine veebisait töötab vanal PHP versioonil ja uuendus oleks niikuinii ees.
Vähem sobib see e-poodidele, klientide portaalidele, broneerimissüsteemidele ja veebisaitidele, kus palju toimetajaid avaldab iga päev. Siin jääb dünaamiline süsteem mõistlikuks. Aidata võib vahevorm: pood jääb dünaamiliseks ja karastatakse hästi, nõuanded ja ettevõtte lehed väljastatakse staatiliselt.
Sageli alahinnatud eelis ilmneb hädaolukorras. Kuna valmis faile saab alati mallidest ja sisust uuesti ehitada, saab manipuleeritud veebisaiti kiiresti tagasi seada teadaolevale puhtale seisule. Eeldus on, et sisu ja mallid asuvad kaitstud hoidlas, muudatused protokollitakse jälgitavalt ja keegi ei muuda faile serveris otse.
Turbeteenuse pakkujat üleminekuks tingimata ei vaja; selle saab teha agentuur või arendaja. Kui senine veebisait oli kompromiteeritud, tuleks sisu enne ülevõtmist siiski kontrollida. Sellele lähemalt artiklis CMS-i vahetus pärast häkkimist?.
Kuidas PHP SOS konkreetselt aitab?
- Kontrollime, milliseid funktsioone teie veebisait tegelikult vajab, ja ütleme avameelselt, kas staatiline lahendus sobib.
- Kindlustame ülemineku korral ligipääsud majutusele, domeenile ja ehitussüsteemile kaheastmelise sisselogimise ja isiklike kontodega.
- Kontrollime kolmanda poole teenuseid ja seame turvapäised, et uus veebisait oleks ka brauseris hästi kaitstud.
- Jäävate PHP süsteemide jaoks võtame uuendused ja jälgimise enda peale turvahoolduslepingus.
Kokkuvõte
Staatiline veebisait ei ole imerohi, kuid paljude ettevõtte lehtede jaoks on see lihtsaim viis vabaneda tervest riskiklassist. Kus PHP-d ei tööta, ei saa PHP2Shell midagi korda saata. Saavutatud turvalisus peab aga ainult siis, kui ligipääsusid, sõltuvusi ja kolmanda poole teenuseid võetakse sama tõsiselt nagu varem serverit.
Korduma kippuvad küsimused
Kas staatilist veebisaiti saab ikkagi häkkida?
Jah. Serveripoolne programmiloogika jääb ära ja sellega suur klass rünnakuid. Ründatavaks jäävad aga ligipääsud majutusele, domeenile ja ehitussüsteemile, integreeritud kolmanda poole teenused ning tööriistad, millega leht luuakse.
Kas staatilisel veebisaidil võivad olla kontaktivormid?
Jah, välise vormiteenuse või väikese eraldi käitatava funktsiooni kaudu. Siis on andmete töötlemine selle teenuse käes. Selgitage andmekaitse ja andmetöötlus enne selle integreerimist.
Kas toimetajad saavad staatilist veebisaiti ise hooldada?
Sobiva toimetamisvahendiga jah. Paljud lahendused pakuvad muutmisliidest, millest leht seejärel uuesti luuakse. Meeskondadele, kes muudavad iga päev palju sisu, on klassikaline CMS siiski sageli mugavam.
Kas üleminek tasub end e-poe puhul ära?
Enamasti mitte täielikult. Ostukorv, kliendikonto ja maksmine vajavad serveripoolset loogikat. Võimalik on väljastada osi nagu nõuandeid või ettevõtte lehti staatiliselt ja käitada poodi eraldi.