DevSecOps: kuidas integreerida küberturvalisus arendusprotsessi esimesest hetkest alates?

DevOps lähenemine on juba aastaid aidanud nii tarkvaraarendust, e-poodide tegemist kui ka digitaliseerimist muuta kiiremaks ja efektiivsemaks, nüüd on protsessiga liitumas ka küberturvalisus, mis oli varem mitmete arendusprotsesside juures pigem järelmõtteks, märkis Eesti IT-firma Uptime tehnoloogiajuht Raimo Seero – DevSecOps aitab turvalisusteemad arendusprotsessiga liita juba elutsükli esimesest hetkest.

“Enne DevOps mudelile liikumist istusid arendajad ühes toas, äripool teises toas ning administraatorid, kes pidid süsteemi veel aastaid käimas hoidma, kolmandas toas,” lausus Seero. “DevOps tõi need grupid ühe laua taha kokku, avas uksed agiilsele arendusele, pidevale testimisele ja oluliselt efektiivsemale protsessile.”

Seejuures jäid aga turvateemad tihti sellest ringist eemale ning neile pöörati tähelepanu hiljem, testimisfaasis või siis, kui etapp oli valmis saanud ja vaja kliendile üle anda. “DevSecOps lähenemine aitab seda olukorda muuta, olles ühteaegu nii metoodika, kui ka laiem mõtteviis ja arendusprintsiip,” lausus Seero.

DevSecOps tehnilises vaates

Seero selgitas, et tehnilises vaates hõlmab DevSecOps oluliselt suuremal hulgal automaatikat kui tavapärane arendusprotsess. Sellest lähtuvalt kasutatakse tööriistasid ja tarkvara, mis suudavad potentsiaalseid turvanõrkuseid avastada juba arenduste esimestes etappides.

“Pidev testimine on agiilse arenduse osaks igal juhul, kuid turvalisuse seiskohast lisatakse uuemate lähenemistega tööprotsesse teste ja tööriistu, mille eesmärk on juhtida tähelepanu võimalikele turvanõrkustele. Näiteks suudavad mitmed tööriistad koodi lugedes leida üles levinud nõrkused ning arendajat sellest teavitada, hoides seega ära olukorrad, kus juba niigi vigase lähenemise peale ehitatakse midagi järgmist,” sõnas Seero.

Selle kõrval on olulisel kohal ka tiimi omavaheline koostöö, kus teineteise koodile vaadatakse peale ning üritatakse sealt muude vigade kõrvalt leida üles ka turvanõrkused. “Code review on üks parimaid viise koodist probleemkohad üles leida. Kui keskenduda selle protsessi käigus ka turvanõrkuste tuvastamisele, mitte ei anta arendustsükli lõpus tervet repositooriumi ühe testija kätte algusest-lõpuni läbi lugeda, saavad ka nõrkused kiiremalt ja täpsemalt tuvastatud,” märkis ta.

Siiski ei tähenda see seda, et turvanõrkuseid tavapärase DevOps arendusmudeli juures ei leita, pigem on küsimus mõtteviisis.

DevSecOps mõtteviisina

Seero selgitas, et turvanõrkuseid võib leida tarkvaraarenduse igas etapis, seda iga arendusmudeli abil ja iga metodoloogia kasutamise puhul. DevSecOps tõstab selle aga lihtsalt nimekirjas asjadest, millele mõeldakse, ettepoole.

“DevSecOpsi puhul algab turvanõrkuste leidmine juba eelanalüüsi faasis. Analüütikud, it-projektijuhid, arhitektid, disainerid, arendajad ning kõik muud osapooled kaaluvad potentsiaalseid turvariske iga tegevuse juures ning hindavad, kas ja kuidas see võiks lõpptoodet mõjutada,” ütles ta. “See tähendab, et ideaalses maailmas on kõik põhimõttelised turvanõrkused lahendatud juba enne, kui üldse päriselt programmeerima hakataksegi. Või kui seda ei saa teha, siis teavad arendajad juba eos, et neil tuleb neid riske tähele panna ja need maandada.”

Turvalisusele mõtlemine ulatub aga reaalse toote arendamisest kaugemalegi, viies DevSecOpsi puhtast arendusfilosoofiast laiema mõtteviisini. “DevSecOps arenduskeskkonnas töötades on oluline, et inimestele turvalisus ka päriselt korda läheks. Seega on näiteks oluline see, et kõik seotud osapooled on küberturvalisuse maailmas toimuvaga alaliselt kursis hoiaks, teaks mis riskid esinevad, mis vigu teised teinud on ja kust võivad ohud tekkida,” ütles Seero.

“Niisamuti on tarkvarakeskuse vaatest oluline tagada, et nende inimesed saaks kasutada parimaid saadaolevaid tööriistasid, kõige tänepäevasemaid lähenemisi ja ehitada taristu, mis aitab security first lähenemist juurutada,” lisas ta.

Tänapäevases maailmas vältimatu

Küberturvalisus on erilise tähelepanu alla tulnud viimaste aastate jooksul, kui on kõigile selgeks saanud, et see ei ole valdkond, millelt oleks võimalik kokku hoida. See aga ei tähenda, et turvalisusele suurema kaalu panemine arendusprotsessi märgatavalt kallimaks muudaks.

“On selge, et iga täiendav töötund millegi tegemiseks tähendab ühte vähemat tundi millegi muu tegemiseks, või lisarida arve peal. Kui vaadata aga laiemat pilti, siis sarnaselt agiilsele tarkvaraarendusele tervikuna aitab see lõppkokkvõttes tervet protsessi efektiivsemaks muuta,” sõnas Seero.

Ta märkis, et DevSecOpsi moto on “Software, Safer, Sooner”, mis aitab lähenemise efektiivsust üsnagi hästi ilmestada.

“Kuna turvalisusele pööratakse tähelepanu terve arendusprotsessi vältel, siis on viidud minimaalsele tasemele risk, et kriitiline turvaviga avastatakse protsessi lõpusirgel. See tähendab ühtlasi ka seda, et on pea välistatud olukorrad, kus juba lõppstaadiumis etappi tuleb hakata suurel määral muutma, et likvideerida mõni turvanõrkus, ütles Seero.

“Ideaalses maailmas ei satuks ka tavalise DevOps lähenemise juures tootesse ühtegi turvaviga, kuid lõpuks on alati mängus inimfaktor. DevSecOps üritab seda riski maandada, mis tähendab lõppkokkuvõttes seda, et klient saab turvalisema toote, mis aitab pikemas perspektiivis ka arendusele kuluvat aega kokku hoida,” lisas ta.

Seega soovitab Seero igal arendusmeeskonnal, kes on seni lähtunud standardsest DevOps lähenemisest, migreeruda DevSecOps mentaliteedi poole. “Kaotada on siin vähe, võita aga palju,” ütles ta.

Liitu Uptime’i tiimiga DevOps insenerina!

Liitu uudiskirjaga