Soovitusi turvakriitilise tarkvarateenuse arendamiseks

Tarkvarateenuse loomisel peame me lisaks kasutajatele, kelle jaoks süsteemi disainime, pöörama sama suurt tähelepanu neile, kelle huvides on meie loodud süsteemi saboteerida, andmeid varastada või seda mõnel muul viisil kahjustada. Viimaste vastu soovitame teenuse ülesehitamise alguses läbi käia olulisemad teemad, mida teenuse loomisel nii tegija kui tellijana jälgida.

Turvalise tarkvaraarenduse ja testimine lähenemisviisid

Aluseks on mõistlik võtta OWASP TOP10 riskid, ja OWASP cheat-sheet seeria. See annab üldiselt hea ülevaate, kuidas vältida enam-levinud vigu tarkvara ja platvormide arenduses ning kuidas tüüp-probleeme turvaliselt lahendada. Kui tulevasele arendajale on sellised teemad uued, tasuks otsida kogenumat partnerit.

Selged kasutajate autentimise reeglid

Kasutajakontode turvalise loomise kohta saab samuti abi OWASP lehelt. Näiteks, kuidas hoida ja salvestada kasutajate paroole jne. Mitmeastmeliseks tuvastamiseks 2FA saab kasutada Messentete, Twilio Authy ja Google. Võimalusi on palju ning teenuse loojal on võimalus otsustada, milline viis tema teenusele kõige paremini sobida võiks.

Lisaks soovitame kasutaja loomisel teha sisestatud parooli kontroll ning mitte lubada liiga nõrka ja/või levinud parooli. Mõistlik on kasutajale selgitada, miks valitud parool on halb (näiteks “Top100 used passwords”). Isegi kui kasutaja arvab, et “Password1” on piisavalt turvaline, süüdistavad kasutajad enda konto ülevõtmisel ikkagi pigem platvormi ja teenusepakkujat kui ise enda valitud parooli nõrkust.

Sissetungivate rünnete vastu testimine

Lisaks sisemiselt kasutatud võtetele tasub platvormi valmides tellida ka sõltumatud turvatestimised, mis tõenäoliselt on odavam kui hiljem reaalselt kasutuses oleval süsteemil ükshaaval turvaauke lappida (hinnad suurusjärgus alates 10 000 – 15 000 € + VAT). Selliste penetration testide tegijad on spetsialiseerunud simuleerima ründajat ning see aitab meil leida üles vead, mis arenduses kasvõi näiteks tehnoloogiliste valikute tõttu katmata jäävad. Firmadest teevad selliseid teste näiteks Eestis Clarified Security, välismaal on F-Secure, Nixu, Accenture ja paljud teised.

Võtmehaldus ja krüptograafia

Krüptograafia ise-enesest ei ole midagi liiga keerulist, kui kasutada parimaid soovitusi ja standardeid ning hoiduda ise jalgratast leiutamast. Siiski tuleb arvestada, et krüptograafia asendab suure andmete kaitsmise probleemi väiksema – võtmete kaitsmise probleemiga. Seega tasub enne korralikult läbi mõelda ja analüüsida, kuidas krüptovõtmete haldamise loogika üles ehitada.

Kindlasti tuleks minimeerida inimsuhtlust ja kõik, mis võimalik automaatselt toimida panna. Kindlasti kõik võtmed ja ka krüpteeritud ärikriitilised andmed varundada füüsiliselt teise asukohta. Aeg-ajalt tasub ka testida, kas need varukoopiad veel töötavad. Master-võtmed ja ka varukoopia võtmed võiks olla jagatud pooleks kahe inimese vahel ja omakorda dubleeritud. Näiteks nii, et võtme esimest poolt teab kaks inimest ja teist poolt veel omakorda kaks. See vähendab kaht riski, kus pahatahtlik arendaja otsustab andmetega jalga lasta, ning samuti olukorda kus ühelt inimeselt kaotsi läinud andmetega ei saa veel mitte midagi teha, sest master võtme teist poolt teab teine isik.

Nii Azure kui AWS pakuvad võtmete hoidmiseks ka eraldi teenust, lisaks on olemas kolmandaid pakkujaid, näiteks Hashicorp Vault.

Monitooring ja aktiivne turvalisus

Kõigi kasutatud komponentide turvaaukude uudiseid tuleks jooksvalt jälgida. Kohe kui midagi uut ja kriitilist avastatakse, peaks suutma selle ka ära uuendada. Tasub juba ette arvestada, et see on lisatöö nii turvavigade jälgimise osas kui ka enda teenuse skaneerimise ja uuendamise osas. Märksõnadeks on: CVE List, kasutatud tarkvarakomponentide enda turvalistid ja -teavitused. Näiteks rünnatakse valitud platvorme eriti aktiivselt just mõne nädala jooksul pärast leitud turvavea avalikustamist. Põhjus selleks on väga loogiline: komponendi turvauuendus võib küll olemas olla, kuid teenusepakkujad ei ole veel jõudnud enda süsteemi ära uuendada. Tarkvarateenuste haldajatele on igasugune uuendamine seotud omakorda riskidega, sest uuendused võivad põhjustada omakorda stabiilsuse probleeme või isegi esile tuua uusi turvanõrkusi.

Pettuste analüütika ja kasutajakäitumise jälgimine

Veatundlike, näiteks finantsteenuste puhul tasub analüüsida kasutajate käitumist ning esimesel võimalusel ehitada ka fraud-detection mootor, mis hindab tehingute riskitõenäosusi. Lihtsustatud näide: Kui kasutaja A teeb enda tehinguid reeglina väikestes summades Soomes ja Eestis ning järsku üritab Hispaaniast 10 000 € väärtuses tehingut teha, on mõistlik tehing automaatselt pidurdada ning saata manuaalsesse kontrolli, kus konto omaniku käest tehingu õigsuse kohta lisakinnitus saadakse. Selliste kontrollmehhanismide välja- ja sissetöötamine on muidugi suur töö ning esimestes versioonides praktiliselt teostamatu, sest kasutajakäitumiste mustrid alles tekivad. Lisaks tuleb käitumisandmeid pidevalt analüüsida ja reegleid jooksvalt uuendada. Eesmärk on leida kesktee, kus süsteemi kuritarvitajate ründed püütakse kinni, ning süsteem ise jääb tavakasutajale piisavalt mugavaks.

Täiesti turvalist süsteemi on praktiliselt võimatu lõplikult valmis ehitada. Tehnoloogia uuenemisega uuenevad kasutajate nõuded tehnoloogiale. Igal uuendusel on oma kasutusele võtmise hind, ROI ja kaasnev tehniline risk. Seega tuleb selliste otsuste juures läbi kaaluda, milline on loodava või kasutatava teenuse mõistlik riski ja tootluse suhe – pole mõtet ehitada rasket aardekindlust, kui vajame mobiilset telki ja ka vastupidi.

Leave a Reply

Your email address will not be published. Required fields are marked *