Küberrünnak võib tabada meid kõiki – kuidas ennast kaitsta? II osa
Möödunud nädala blogis tegime sissejuhatuse küberrünnakute musta maailma. Käesolevas artiklis uurime Trinidad Wisemani arendustiimilt, kas turvalisuse seisukohalt on vahet, millist sisuhaldusplatvormi ma kasutan ja kes on vastutav turvajuhtumi eest. Samuti anname rea soovitusi, kuidas ennetada kübersissetunge oma veebi ja arvutisüsteemi.
Milline sisuhaldusplatvorm on kõige turvalisem?
Kui võrrelda Eestis kasutatavaid populaarsemaid sisuhaldustarkvarasid, loetakse Drupalit veidi turvalisemaks kui Wordpressi. Loe meie varasemast blogipostitusest ka uusima Drupal 9 versiooni kohta.
Probleemid tekivad mõlema platvormi puhul pahatihti kolmanda osapoole loodud pluginatega. Tihtipeale on neil ainult üks arendaja, kes tegeleb pluginaga oma põhitöö kõrvalt, mis tähendab, et turvateste eriti ei tehta ning üldiste turvaaukude parandamisega tegeletakse alles siis, kui oma vitsad on juba kätte saadud.
Sisuhaldusplatvormi valik oleneb sellest, mis otstarbeks platvormi kasutatakse – näiteks blogipidajatele ei ole turvalisuse eest hoolitsemine tõenäoliselt nii oluline kui veebipoe omanikele, kellel on mängus kliendiandmed ja rahavood.
Soovitame kõigepealt läbi mõelda oma vajadused ning seejärel hinnata, kas platvorm vastab sinu nõudmistele (nt kas sinu sooviks on blogipidamine või ärikriitilise iseteeninduse loomine).
Turvalisuse kaalutlustel soovitame kindlasti vaadata suuremate ja enimkasutatavate sisuhaldusplatvormide poole. Nende puhul on tagatud usaldus ja tagasiside laia kasutajaskonna poolt – nt probleemide tekkimise korral saab abi küsida erinevtest foorumitest ja teemagruppidest (nt Slacki kanal, stackoverflow).
Soovi korral on võimalik kasutada ka väiksemaid ja vähem tuntud lahendusi või ise platvorm ehitada, kuid sel juhul peab veenduma, et turvaaugud saaksid kaetud. Võimalik on tellida mitmesuguseid turvaauditeid ning otsustada nende sagedus.
Meie kogemusele toetudes on suurim probleem üksi jäetud klient, kes peab ise tagama selle, et turvaauke ei leiduks. Kuna sisuhaldustarkvara on tänapäeval väga lihtne püsti panna, eksisteerib palju saite ja e-poode, mille puhul klient ei ole isegi teadlik, et tarkvara tuleb vahepeal uuendada. Tihtipeale ei ole lisatud isegi HTTPS tuge.
Kes vastutab selle eest, kui minu lehel toimub turvaintsident?
Vastutus määratakse vea tekkimise põhjal – on selleks arendajapoolne koodi lohakus või turvauuenduste tegematajätmine, serveri majutaja hooletus või halduri poolne tegemata töö (nt installitakse peale kolmanda osapoole moodulid arendajatega läbi rääkimata).
Sageli võib olla olukord segasem. Näiteks kui veeb on tehtud kunagi ammu, kasutades kolmanda osapoole liidestust, kuid teenuseosutaja, kes seda varem pakkus, sellega enam ei tegele.
Seetõttu on koodid aastaid uuendamata ning häkkerid kasutavad neid nõrkusi ära. Keda sellisel juhul süüdistada või vastutusele võtta?
Arendajate kohustus on kliendile alati soovitada ja pakkuda parimaid turvauuenduste lahendusi. Kui klient neid ei soovi või tal ei ole võimalik nende eest tasuda, siis turvariskid paratamatult suurenevad.
Enamasti on kliendil vastutust keeruline kellelegi panna. Aitab pigem ennetustöö ning vajadusel ka kindlustus.
Kuidas suurendada turvalisust ning kaitsta oma veebi küberrünnaku eest?
Olulised on igakuised turvauuendused ja mitmesugused ennetustegevused - nt automaatne monitooring, mida teostavad eraldi teenusepakkujad ning mis pakub suuremat kaitset (nt GTMetrix, Pingdom, ka AppDynamics, kelle litsentse müüme Trinidad Wisemanis).
Lisa turvalisuse tagamiseks võib kasutada platvormi spetsiifilisi pluginaid, kuid oluline on ka nende juurde märkida, millal neid viimati uuendati ning kui palju on sellel aktiivseid installe.
Pelgalt igakuised automaatsed uuendused nagu Windowsi või mobiiltelefoni puhul, ei pruugi anda parimaid tulemusi. Miks?
Tehnoloogiline areng on tänapäeval väga kiire, mistõttu küberkurjategijad on tihti paar sammu ees ning tuvastavad juba vigu, millest toote- ja süsteemiomanikud veel teadlikud ei ole.
Selgitame natuke lähemalt: sisuhaldusplatvormi tuumast ning pluginatest võib mõelda kui täiesti eraldiseisvatest süsteemi osadest ehk kummagi arendajal ei ole võimalik kuidagi arvestada sinu veebilehele tehtud arendustöödega.
Sellest tulenevalt võivad eraldiseisvate osade arendajad sisse viia muudatusi, mis ei sobitu enam sinu veebilehe ülejäänud koodibaasiga ning osad funktsioonid võivad peale uuendusi lakata töötamast.
Seetõttu on lisaks väga oluline manuaalne seire arendajate poolt ning suuremate veebilehtede puhul soovitame kindlasti palgata hoolduspartneri, kes pärast uuendusi kontrollib üle lehe funktsionaalsused ning taastab vajadusel uuendatud koodibaasis eelnevalt olemasolevad funktsionaalsused.
Kuidas juba eos ennetada sissetungimisi?
Turvalisuse tagamine nõuab aega ja ressurssi. Sageli läheb nii, et kõigepealt saadakse kätte valus õppetund ja seejärel asutakse turvalisusega tegelema. Kuidas seda kõike ennetada?
"Veebimaailmas käib mugavuse, kulu ja turvalisuse vahel pidev võitlus, kuid igaühel tuleb leida enda jaoks sobiv tasakaal ning alustada tuleks inimeste enda veebikäitumisest."
Kõige suurem viga, mida täna tehakse, on seotud kasutajate enda paroolidega – tavaliselt pannakse midagi lihtsat, et oleks kerge meeles hoida ja sedasama parooli kasutatakse igal pool.
Kontrolli üle, kas sinu parool(id) on möödunud aastal enimkasutatud paroolide nimekirjas või kas leiad oma e-maili aadressi kompromiteeritud andmete nimistust.
Kui nii, siis on sinu parool liikvele läinud ja soovitame selle esimesel võimalusel ära vahetada ning kindlasti kasutada turvalisuse tagamiseks erinevates keskkondades erinevaid paroole. Miks see nii oluline on?
Kui sinu parool peaks kuskilt lekkima, saab sama parooli ja e-mailiga lihtsasti sisse tungida ning kurja teha kõigis selle inimese poolt kasutatavates keskkondades.
Süsteemid nõuavad aeg-ajalt paroolivahetust. Kui süsteem ei salvesta vanu paroole ega kontrolli vastavust uutega, sisestab kasutaja sageli mugavusest uue sarnase parooli - nt vahetatab vaid 2 numbrit - mida on samuti väga lihtne ära arvata.
Paroolide meelespidamiseks kasuta paroolihaldurit, mis on väga mugav ja turvaline ning mida saab laadida nii arvutisse, iPhone nutitelefoni kui Androidi. Soovitame nt LastPass, Keeper, BitWarden, 1Password.
Valikut aitab langetada review`de (äppide võrdluste) lugemine. Märkmetesse (notes) ei ole mõistlik oma paroole salvestada - kui oled iPhone kasutaja ja sinu iCloud kontole saadakse volitamata juurdepääs, on olemas ligipääs sinu märkmetele ja seega ka paroolidele.
Enne lingi avamist veebilehtedel, e-mailides ja mujal, tuleks kriitiliselt hinnata, millega on tegemist ja kas on mõistlik sellel klikkida.
Oma veebi kaitseks soovitame kinni keerata kõik funktsionaalsused, mida ei kasutata. Infoveebis, mis ei nõua kasutajate poolseid tegevusi, lülita välja kommenteerimise ja registreerimise funktsioonid.
Avastades kasutaja, keda tegelikult ei eksisteeri, soovitame rakendada IP piirangut, ning üle vaadata kasutaja tehtud tegevused (logid).
Oluline on regulaarselt kontrollida ja skannida oma veebis toimuvaid tegevusi. Selleks tuleb tagada, et kõigist tegevustest jääks kindlasti ka jälg maha (nt kes millal sisse logis, kes kasutajatest kuskil midagi muutis jne).
Mõistlik on piirata erinevate tasemete kasutajaõigusi ning jooksvalt üle kontrollida kõik aktiivsed kasutajad ning erinevate kasutajate õigused. Sageli läheb nii, et luuakse kasutaja, kellele määratakse kõige kõrgemad õigused ning seejärel temaga rohkem ei tegeleta.
Sageli kipub ununema töölt lahkumise korral selle kasutaja deaktiveerimine süsteemides. See punkt võiks kindlasti kirja saada ettevõtte protseduurireeglitesse.
Mille järgi pluginat valida? Mooduli viimane väljalase peaks olema enamasti pool aastat kuni aasta tagasi ning ideaalis võiks sellel olla 100 000+ kasutajat WordPressi puhul (nt Drupali puhul võib vähem olla). Samuti on oluline lugeda kasutajate hinnanguid (kas esineb palju probleeme jne).
Lõpetuseks toome kõige eelneva põhjal kontrollnimekirja turvajuhtumite ennetuseks.
