Kodulehe turvalisus

Enamik kodulehti ei satu ründe alla seetõttu, et keegi on valinud just nende omaniku sihtmärgiks. Rünnakud on automaatsed ja otsivad vananenud tarkvara, nõrku paroole ja unustatud lisamooduleid. Seepärast annavad kõige suurema kaitse mõned korralikult tehtud põhitegevused, mitte keerukad turvalahendused.

Kõige olulisem on see:

1. Hoia kodulehe tarkvara, teemad ja pistikprogrammid ajakohased ning kustuta need, mida sa ei kasuta.
2. Võta administraatorikontodel kasutusele tugev parool ja kaheastmeline autentimine ning piira sisselogimiskatseid.
3. Kasuta HTTPS-i ja jälgi, et sertifikaat uueneks automaatselt.
4. Tee varukoopiaid kolme koopia reegli järgi ja proovi vähemalt kord, kas need taastuvad.
5. Kaitse domeeni: lülita registripidaja kontol sisse kaheastmeline autentimine ja kaalu .ee-domeenile registrilukku.

Mida ründajad ära kasutavad

Kui leht on tehtud WordPressiga, siis kõige sagedamini on nõrgaks lüliks pistikprogrammid. Patchstacki raporti „State of WordPress Security in 2026“ järgi leiti 2025. aastal WordPressi keskkonnas 11 334 uut haavatavust. Neist 91% oli pistikprogrammides ja 9% teemades. WordPressi tuumas oli neid kokku vaid kuus ja need olid madala prioriteediga.

Praktiline järeldus: WordPress ise on tavaliselt turvaline, aga iga lisatud pistikprogramm suurendab ründepinda.

Parandust oodata ei jõua. Sama raporti andmetel hakati umbes pooli suure mõjuga haavatavusi ära kasutama 24 tunni jooksul pärast avalikustamist. Enim ärakasutatud haavatavuste puhul oli ärakasutamise alguseni kulunud aja mediaan viis tundi. Lisaks ei olnud 46%-l haavatavustest avalikustamise hetkel arendajalt parandust olemas.

Eestis on Riigi Infosüsteemi Amet (RIA) hoiatanud veebilehtede näotustamise eest. Näotustamisel kasutatakse ära lehe nõrkust, näiteks vananenud tarkvara, murtakse lehele sisse ja kuvatakse teade eduka häkkimise kohta. RIA rõhutab, et ohvriks võib sattuda mis tahes veebileht, mitte ainult suur organisatsioon.

Uuendused ja lisamoodulid

Uuenda kolme asja: platvormi tuuma (näiteks WordPressi), teemat ja pistikprogramme. WordPress paigaldab väiksemad turvauuendused enamasti ise, aga pistikprogrammide ja teemade automaatne uuendamine tuleb ise sisse lülitada.

WordPressi dokumentatsiooni järgi saab alates versioonist 5.5 automaatsed uuendused sisse lülitada iga pistikprogrammi ja teema kohta eraldi:

• pistikprogrammid: Pistikprogrammid → Paigaldatud pistikprogrammid ja link „Enable auto-updates“ (sõltuvalt liidese keelest võib nimetus olla tõlgitud);
• teemad: Välimus → Teemad, ava teema ja vali automaatne uuendamine.

Vaikimisi kontrollib WordPress pistikprogrammide ja teemade uuendusi kaks korda päevas.

Teine pool tööst on kustutamine. WordPress.org soovitab kasutamata teemad eemaldada. Pistikprogrammi puhul deaktiveeri see ja vali seejärel „Kustuta“, et see päriselt eemaldada.

Kui automaatne uuendamine ei sobi: e-poes või lehel, kus on keeruline kohandatud kood, võib uuendus midagi katki teha. Sel juhul tee enne uuendamist varukoopia ja katseta uuendust testkeskkonnas. Uuendust ei tasu siiski mitmeks kuuks edasi lükata, sest ründajad hakkavad haavatavusi ära kasutama juba esimeste tundide jooksul.

Kui oled kodulehe teinud kodulehe loomise keskkonnas, mis on teenusena kasutatav, hoolitseb platvormi tarkvara uuendamise eest tavaliselt teenusepakkuja. Sinu enda ülesandeks jääb kontode kaitsmine ja varukoopiate tegemine. Lehe ehitamise valikutest annab ülevaate artikkel kodulehe tegemisest.

Paroolid ja sisselogimine

Sisselogimisleht on ründajatele lihtne sihtmärk: parooli proovitakse arvata automaatselt. WordPressi arendajadokumentatsioon soovitab paroolide automaatse äraarvamise (brute force) rünnakute vastu kolme asja:

• lülita kõigil administraatorikontodel sisse kaheastmeline autentimine (WordPressi tuum seda ei sisalda, seega vajad pistikprogrammi või identiteediteenust);
• piira sisselogimiskatseid veebiserveri või võrguteenuse (WAF või CDN) tasemel, vajadusel turvapistikprogrammiga;
• lisa sisselogimislehele CAPTCHA.

OWASP-i autentimisjuhend nimetab mitmefaktorilist autentimist parimaks kaitseks paroolirünnakute vastu ja viitab Microsofti analüüsile, mille järgi see oleks peatanud 99,9% kontode kompromiteerimistest.

RIA soovitab veebilehe haldajatele lisaks tugevatele paroolidele ja kaheastmelisele autentimisele kontrollida, kellel on administraatoriõigused. Lähtu põhimõttest, et igaühel on vaid need õigused, mida ta töö jaoks vajab. Kui sisu lisab ainult toimetaja, pole talle administraatorikontot vaja. Endise töötaja või veebiagentuuri konto tuleb sulgeda.

HTTPS ja sertifikaat

HTTPS krüpteerib andmed külastaja brauseri ja serveri vahel. See on vajalik igal lehel, kuid eriti seal, kus on sisselogimine, kontaktivorm või e-pood. Sertifikaadi saab tavaliselt veebimajutajalt, kuid enne valiku tegemist küsi, kas selle uuendamine käib automaatselt.

Oluline muutus on sertifikaatide eluea lühenemine. CA/Browser Forumi nõuete järgi on avalike TLS-sertifikaatide maksimaalne kehtivus:

Alates	Maksimaalne kehtivus
15. märtsist 2026	200 päeva
15. märtsist 2027	100 päeva
15. märtsist 2029	47 päeva

Let’s Encrypt väljastab praegu tasuta sertifikaate 90 päevaks ja soovitab uuendada iga 60 päeva järel. Nende teatel muutub vaikimisi kehtivus 10. veebruarist 2027 64 päevaks ja hiljem 45 päevaks.

Mida see tähendab praktikas? Käsitsi uuendamine muutub peagi ebareaalseks. Kontrolli, et sinu majutaja või ACME-klient (näiteks Certbot) uuendaks sertifikaati automaatselt. Ära looda meeldetuletustele: Let’s Encrypt lõpetas aegumisteavituste e-kirjade saatmise 4. juunil 2025. Aegunud sertifikaadiga lehel näitab brauser külastajale hoiatust ja enamik inimesi lahkub.

Turvapäised

Turvapäised on HTTP-vastuse osad, mis annavad brauserile juhiseid. Neid saab seadistada veebiserveris. Kolm tähtsamat:

• Strict-Transport-Security (HSTS) käsib brauseril kasutada lehte ainult HTTPS-iga. OWASP-i näide on max-age=63072000; includeSubDomains; preload, st kaks aastat. OWASP hoiatab, et vea või sertifikaadiprobleemi korral võivad päris külastajad lehele pääsemise kaotada, seega lülita HSTS sisse alles siis, kui HTTPS töötab kõigil alamdomeenidel.
• X-Content-Type-Options: nosniff keelab brauseril faili tüüpi ise ära arvata (MDN-i kirjelduse järgi).
• Content-Security-Policy (CSP) määrab, milliseid ressursse leht tohib laadida, ja aitab kaitsta saidiülese skriptimise (XSS) eest. OWASP märgib, et CSP seadistamine ja hooldamine on keeruline, seega on mõistlik see usaldada arendajale või alustada ainult aruandlusrežiimis.

Kui sa pole kindel, alusta nosniff-päisest ja HSTS-ist. CSP-ga võib halvasti seadistatud reegel katki teha näiteks analüütikaskripti või kontaktivormi.

Varukoopiad

Varukoopia aitab lehe taastada pärast rünnakut, viga või ebaõnnestunud uuendust. USA küberturvalisuse asutus CISA soovitab 3-2-1-reeglit:

• 3 koopiat olulistest failidest;
• 2 erinevat tüüpi andmekandjat (näiteks serveri ketas ja pilv);
• 1 koopia asukohast eraldi.

Veebilehe puhul on koopiasse vaja nii faile (teemad, pildid, pistikprogrammid) kui ka andmebaasi, kus asuvad sisu ja seaded. Kui majutaja teeb varukoopiaid samas serveris, on see alles üks koopia samas kohas. Lisa kindlasti väline koopia.

CISA soovitab varunduse toimimist ka katsetada. Tee seda näiteks pärast suuremat uuendust: taasta koopia testkeskkonda ja vaata, kas leht avaneb.

Domeeni kaitse

Isegi turvaline leht on kasutu, kui keegi saab domeeni üle võtta või DNS-i andmeid muuta. Eesti Interneti Sihtasutus (EIS) soovitab registripidaja või DNS-i haldamise kontole seadistada kaheastmelise autentimise.

Kaks .ee-domeeni jaoks olulist vahendit:

• Registrilukk. Domeeni omanik saab oma andmed e-ID abil lukustada, nii et registripidaja saab ainult registreeringut pikendada. Väljastpoolt algatatud muudatused, sh omaniku, registripidaja, nimeserverite või DNSSEC-võtmete muutmine, on blokeeritud, kuni omanik luku avab. See sobib eriti äriliselt olulistele domeenidele.
• DNSSEC. See on .ee-tsoonis saadaval alates 2014. aasta jaanuarist ja aitab tagada, et külastaja jõuab õigele IP-aadressile. Kõik EIS-i akrediteeritud registripidajad peavad võimaldama DNSSEC-võtmete lisamist. Mõni pakub täisteenust, mida EIS-i registripidajate loendis märgib roheline võtmeikoon.

Domeeni kaitse kohta loe lähemalt artiklist kuidas kaitsta domeeni. Kui domeen on alles registreerimata, vaata enne domeeninime registreerimise juhendit.

Häkkimise korral

1. Isoleeri leht. Pane see hooldusrežiimi või võta ajutiselt maha ning vaheta kõikide kontode paroolid (haldus, majutus, andmebaas, e-post).
2. Salvesta tõendid. RIA soovitab säilitada logid, seadistused ja vähemalt viimase rünnakueelse varukoopia.
3. Selgita ulatus. Vaata, milliseid faile ja kontosid on muudetud, ning eemalda haavatavuse põhjus (tavaliselt vananenud pistikprogramm). Pelgalt lehe taastamine ei aita, kui auk jääb alles.
4. Teavita vajalikke asutusi. Küberintsidendist teavitamise kohustus on riigiasutustel ja küberturvalisuse seaduses nimetatud teenuseosutajatel, kes peavad teavitama CERT-EE-d 24 tunni jooksul. CERT-EE ootab siiski teateid kõigi küberintsidentide kohta. Teate saab saata e-kirjaga cert@cert.ee.
5. Kontrolli isikuandmeid. Kui lehelt võisid lekkida isikuandmed (näiteks kontaktivormi päringud või e-poe kliendid), tuleb teavitada Andmekaitse Inspektsiooni (AKI) põhjendamatu viivituseta ja võimaluse korral 72 tunni jooksul pärast rikkumisest teadasaamist. Teavitamata võib jätta vaid siis, kui rikkumine tõenäoliselt ei ohusta inimeste õigusi. Seda otsust peab suutma põhjendada ning dokumenteerida. Kui info ei ole 72 tunni jooksul täielik, võib esitada esmase teate ja täiendada seda hiljem. Teate saab esitada AKI e-keskkonnas või e-kirjaga info@aki.ee.

Tõsise rünnaku korral kaasa veebiarendaja või majutaja tugi, et põhjus tõesti leitaks. E-poe omanikule on kasulik ka artikkel veebipoe turvalisusest.