Microsofti blogi

Microsofti spetsialist Janno Tomingas: need on õppetunnid, mida pilve kolimine meile andis

Janno Tomingas jagas hiljuti IT-spetsialistidele mõeldud seminaril Microsofti kogemusi pilveplatvormile kolimise ohukohtade kohta. (c) Foto: erakogu
Janno Tomingas jagas hiljuti IT-spetsialistidele mõeldud seminaril Microsofti kogemusi pilveplatvormile kolimise ohukohtade kohta.Foto: erakogu

Mida me enne tegime valesti ja mida nüüd paremini? See on küsimus, mille Microsofti Tallinnas asuva arendusosakonna 11-inimeselise tiimi eest vastutav Janno Tomingas oma suuremahulise kõneteenuse Azuri pilveplatvormile üleviimise näitel huvilistele lahti seletas. Ülesastumine toimus mainekal seminaril Nordic DevOps Days, kuhu olid digivaldkonna tipptegijaid kuulama ja ise osalema saabunud paljud tehnoloogiavaldkonna spetsialistid.

Pilveplatvormile kolimine on omaette väljakutse, kus ettevõtted õpivad tihti katse-eksituse kaudu. Parem on aga õppida teiste õppetundidest, mida Tomingas nõustus lahkelt ka lugejatega jagama.

Kontrolli, kes on faili autor

Kuidas veenduda, et kood või programm, mille me käima paneme, on tõesti sinu ettevõtte töötajate kirjutatud? See on midagi, mille peale isegi programmeerijad tihti ei mõtle. Tomingas polnud enda sõnul, vaatamata oma IT-kogemusele, enne pilveplatvormile kolimist üldse kursis, kuidas seda tegema peaks.

Kui programmi kirjutamise protsess pole turvatud, kasutavad kurikaelad vahel petumanöövrit ja vahetavad olemasoleva faili enda pahavara vastu välja. Vaatad küll programmi tehtud muudatused üle, aga teatud kontrollide puudumisel on võimalik mõni fail või selle sisu enne käivitamist välja vahetada. Kui kood on juba pakendatud, siis tihti jääb nii, et paketti keegi hiljem käsitsi üle ei kontrolli. Tulemuseks võib olla süsteemi ebasobiv käitumine või kasutajate andmete leke.

Väljaspool ettevõtet kirjutatud teekide kasutamisel tuleb veenduda, et neid turvaprobleemide parandamiseks ka edaspidi tihti ja aegsasti uuendatakse.

Microsoftis vaatavad nii masinad kui inimesed üle kõik kasutusse minevad failid ja koodiread. Kui pärast kontrolli on tehtud kasvõi pisimaid muudatusi, peab kontrolli uuesti läbima. Üksinda, ilma et keegi teine pole faili üle vaadanud, ühtegi faili käivitada ei saagi.

Uuenda süsteemi regulaarselt

Süsteeme tuleb turvanõrkuste likvideerimiseks pidevalt uuendada. Näiteks võib tuua Windows Remote Desktopi, mida on kasutanud paljud, kes kodus töötavad. Kuna süsteemis on ajalooliselt olnud mitmeid suuri turvavigu, siis juhul, kui Windowsi pole mitu aastat uuendatud ja süsteem on internetis vabalt ligipääsetav, pääseb ka pahalane sinna päris hästi.

Paraku osalt on turvaaugud informaatika kui keeruka valdkonna eripära. IT-s on puhtmatemaatiliselt võimalikke eksimiskohti niivõrd palju, et toodet võib küll lõpmatuseni lihvida, aga lõplikult vigu välistada ei saa.

Muuda süsteem võimalikult ligipääsmatuks

Omaette küsimus on süsteemile ligipääsu piiramine. Pilveplatvormidel on erinevalt serveripõhistest süsteemidest, mida kaitsevad harilikult automaatselt tulemüürid, palju asju vaikimisi avatud. Seetõttu tuleb seal üldjuhul ligipääs võõrastele ise kinni keerata.

Jätkates eeltoodud Windows Remote Desktopi näitega: kui väljastpoolt ettevõtet pole võimalik pääseda arvutisse, mis on juba lahti, või tuleb ligipääs igal kasutuskorral eraldi anda ning seejärel eemaldada, siis on arvuti lõpuks igati kaitstud.

Kaitse sisselogimise protseduure

Kuidas seda teha? Janno Tomingas ütleb, et näiteks Microsoftis on paroolide aeg läbi – ettevõttes pole see sisselogimise lahendus kasutusel juba aastaid. See on ebamugav, sest kogu aeg salasõna vahetada on tülikas.

Kui aga siiski paroole kasutada, tuleks minimaalselt nõuda sisselogimise kinnitamist ka mõne muu füüsilise seadmega.

Paroolide alternatiive ja lisavõimalusi on erinevaid, alates mainitud mitmetasandilisest autentimisest kuni veidi ID-kaardi lahendusega sarnaneva YubiKey seadmeni välja. Windowsil endalgi on turvalahendused, nagu Windows Hello.

Automatiseeri kõik mis võimalik

Tominga meeskonna hoole all olevas süsteemis on palju tegevusi automatiseeritud ega vaja käsitsi sekkumist.

Kui muuta automaatseks kõik mis võimalik, siis polegi vaja kellelegi ligipääsu anda. Nii kaob ka võimalus, et töötaja asemel hakkab seal midagi torkima hoopis ettevõtteväline pahalane.

Korista enda järel ära süsteemid, mida enam ei kasutata

Lõpuks on oluline, kuidas teenused pärast pilve kolimist käigust maha võetakse. Tominga tiimil läks serveris olnud süsteemist lõpliku loobumiseni kuid. Kuna vana süsteemi kasutus langes ajapikku oluliselt, kuid kustutamine venis, ei pööratud selle süsteemi korrashoidmisele ega turvalisusele mingist hetkest enam piisavalt tähelepanu. Selliste olukordade vältimiseks peab olema selge arusaam kõikidest vajalikest kustutustoimingutest ning kindel plaan, kuidas toimingud aegsasti läbi viia.

Sellest võib omakorda tekkida turvarisk. Kui aga ettevalmistused vana süsteemi mahavõtmiseks on korralikult tehtud, siis võid olla kindel, et asi saab tehtud ühe ropsuga: midagi ei jää kuhugi vedelema, kõik vanad asjad ja ligipääsud saavad kustutatud ning maha võetud. Ja kui prügi maha ei jää, siis ei saa seda ka sinu vastu ära kasutada.

Mis on DigiPRO ja kes seda teevad? Loe siit

Populaarsed lood mujal Geeniuses

Telli Geeniuse kõige hinnalisemad lood oma postkasti

Saadame sulle igal argipäeval ülevaate DigiPRO ja Ärigeeniuse olulisematest lugudest.