Nädal 14: Andmeturveː tehnoloogia, koolitus ja reeglid

Selle nädala teemaks on andmeturve ning valisin riskiks veidi kitsama teema: patchimata infrastruktuur. Selle all mõtlen just seda olukorda, kus serverid, konteinerid, paketeeritud tarkvarad, veebilehed jms töötavad vanade versioonidega, mille kohta on juba teada turvanõrkused. Ehk ründaja ei pea alati midagi väga uut leiutama vaid piisab sellest, et leitakse vana versioon, millele on avalik exploit olemas.

DevOps vaatest on see eriti oluline teema, sest tänapäeva süsteem koosneb väga paljudest erinevatest mikroteenustest. Seal on operatsioonisüsteem, konteineri base image, andmebaas, veebiserver, CI/CD tööriistad, npm või pip paketid, Terraformi moodulid, Helm chartid ja veel hulk sõltuvusi. Kui nendest kasvõi üks jääb pikalt uuendamata, võib sellest saada sissepääs kogu süsteemi saades kätte mingid secretid.

Tehnoloogia

Tehnoloogia poolelt peaks esimene samm olema nähtavus. Ei saa parandada seda, mille olemasolust ei teata. Selleks võiks igal rakendusel olla komponentide ja versioonide nimekiri ehk SBOM. Seal peaks olema näha, milliseid teeke, konteineri imageid ja teenuseid kasutatakse. Kui mõnes komponendis leitakse kriitiline haavatavus, siis peab olema võimalik kiiresti aru saada, milliseid süsteeme see puudutab.

Teine oluline asi on automaatne kontroll. CI/CD protsessi võiks lisada sõltuvuste skaneerimise, konteinerite imageite kontrolli ja infrastruktuuri konfiguratsiooni kontrolli. Näiteks kui pull request lisab vana või haavatava paketi, võiks pipeline selle kohe välja tuua. Sama kehtib konteinerite kohta, kus base image võib olla vana isegi siis, kui rakenduse kood on täiesti uus.

Lisaks peaks uuendamine olema võimalikult automatiseeritud. Dependabot ja sarnased tööriistad saavad teha automaatselt pull requeste, kui mõne teegi uus versioon on saadaval. See ei tähenda, et kõik peaks automaatselt production keskkonda minema, aga vähemalt on parem ülevaade olemas.

Koolitus

Koolituse mõttes ei peaks seda teemat nägema ainult DevOpis Opsi osa, ka arendaja peab aru saama, et sõltuvuse lisamine tähendab vastutust. Kui projekti lisatakse mingi teek, siis see ei ole lihtsalt üks rida package.json või requirements.txt failis vaid tekib ülevaade tervele rakendusele.

DevOps tiim peab oskama lugeda skannerite tulemusi ja eristada päriselt kriitilisi probleeme mürast. Kui tööriist toodab iga päev sadu hoiatusi, mida keegi ei vaata, siis ei ole sellest kasu. Koolituse eesmärk peaks olema, et tiim oskaks hinnata, mis vajab kohe parandamist, mis kannatab planeeritud hooldusaknasse ja kus on vaja ajutist leevendust.

Isiklikult olen osalenud sellisel koolitusel, kuskil 2025 aasta lõpu poolel Münhenis 4-päevasel DevOpsConil. Konverentsil viisid läbi enda ala eksperdid praktilisi koolitusi ja minul sai ülevaade turvalisuse poolelt palju paremaks.

Reeglid

Reeglite poolelt peaks organisatsioonis olema kokku lepitud, kui kiiresti tuleb eri tasemega haavatavused parandada. Näiteks kriitiline internetist ligipääsetav haavatavus ei saa oodata mitu kuud backlogis. Samuti peaks olema reegel, et igal teenusel on omanik ja igal komponendil on elutsükkel.

Minu arvates on oluline ka see, et vanadele süsteemidele määratakse end of support ja end of life kuupäevad. Kui neid ei ole, siis jäävad vanad teenused väga lihtsalt aastateks tööle, sest "keegi veel kasutab" või "parem mitte puutuda"

Kokkuvõttes on patchimata infrastruktuur maailmas väga praktiline risk. Seda ei lahenda ainult tulemüür või üks turvaskänner. Vaja on nähtavust komponentide üle, automaatseid kontrolle CI/CD protsessis, regulaarset uuendamist ja selgeid reegleid, kes mille eest vastutab. Mitnicki valemi järgi peavad tehnoloogia, koolitus ja reeglid töötama koos, sest kui üks neist puudub, jäävad vanad haavatavad versioonid varem või hiljem kuskile süsteemi alles.