DevOps-putken tietoturvan varmistaminen

Mikään ei ole täysin turvallista, ja kestää pitkään, ennen kuin tekoäly tai automaatio pääsee edes lähelle ihmisen luontaista älykkyyttä ja nokkeluutta. Automaatio on kuitenkin erittäin hyvä ja nopea testaamaan tunnettuja tekijöitä sekä kokeilemaan väsymättä eri ovia, kunnes löytää lukitsemattoman.

7.11.2018 Göteborg, Ruotsi – Vanhan sanonnan mukaan bugin korjaaminen maksaa 100 dollaria testauksessa, 200 dollaria myöhemmin ja 5 000 dollaria, kun se on päätynyt tuotantoon. Kyse on yhä samasta bugista, mutta myöhemmin sen vaikutus on suurempi ja useampi ihminen osallistuu sen palauttamiseen putken alkuun. Tietoturvabugeissa pahinta on, että vakavimmat niistä voivat vuotaa luottamuksellisia tietoja, tuhota maineesi ja liiketoimintasi sekä johtaa rikosoikeudelliseen vastuuseen.

Meillä on hyviä käytäntöjä eri tilanteisiin: työkalujen ja teknologiapinon arviointiin, sovelluksen toimitusketjun suojaamiseen, resurssien tunnistamiseen, suunnittelupatentteihin ja niin edelleen. Käytännöt ulottuvat putken alun JUnit-testeistä ja komponenttianalyysistä jatkuviin haavoittuvuusskannauksiin, tunkeutumisen havaitsemiseen ja tietoturvapoikkeamien käsittelyharjoituksiin. Ne pitäisi ottaa käyttöön, eikä jättää pelkiksi manuaalisiksi vimpaimiksi, jotka vilkkuvat kuin Las Vegasin joulukuuset eikä kukaan välitä niistä. Tarvitaan myös laatupoortteja. Huonoa buildia ei pitäisi päästää putken loppuun asti millään perusteella.

Käytössämme on jo monenlaisia työkaluja. Jos automatisoitua tietoturvatestausta ei ole vielä käytössä, kannattaa selvittää, mitä tällä aikakaudella on meneillään. Ohjelmistojen laadun parantuessa ja ihmisten tietoisuuden kasvaessa yhä useammat hyökkäykset tapahtuvat sivukanavan kautta sen sijaan, että joku kolkuttaisi etuovelle. Sisäpiiriuhkaa ei valitettavasti pidä koskaan aliarvioida, olipa kyse tahallisesta toiminnasta tai ei. Siksi esimerkiksi niin monet syvimmät salaisuutemme sisältävät mobiililaitteet katoavat joka päivä. Ja kun testaat asioita, testaa realistisesti: mikään menetelmä ei ole liian raju, sillä pahiksia ei kiinnosta, oliko jokin rajauksen ulkopuolella tai tarkoitettu seuraavaan sprinttiin. Salaisuuksia sisältävien levossa olevien tietojen salauksen ottaminen käyttöön on kuin ostaisi palovakuutuksen vasta, kun talo on jo palanut maan tasalle.

Lyhyesti: kun työkalut ovat jo käytössä, noudatetaanko parhaita käytäntöjä ja hyödynnetäänkö niitä pieniä mutta merkityksellisiä ominaisuuksia todella? Meillä kaikilla on esimerkiksi jonkinlainen versionhallinta. Käytätkö sen kanssa monivaiheista tunnistautumista? Oletko miettinyt branch protectionia, allekirjoitettuja commiteja, omistajien määrän pitämistä pienenä, passiivisten tilien automaattista tarkistamista, projekti-kohtaista tiliä koskevan käytännön käyttöä (rajoittaa vaarantumisen vaikutuksia) sekä roolien ja vastuiden eriyttämistä? Näin nämä mainiot kolmannen osapuolen työkalut eivät saa aivan liikaa käyttöoikeuksia. Voisit myös lisätä kaikki kolmannet osapuolet sallittujen listalle.

Huomioitavaa on paljon. Kun toimitusketjun arviointiin lisätään vielä yksi kerros, on tarkistettava pakettien, Dockerfilejen ja monien muiden asioiden allekirjoitukset ja sertifikaatit niiden eheyden varmistamiseksi. Vaatimustenmukaisuuden perustason mittaaminen tarkoittaa myös sitä, että toimituksesta karsitaan vanhentuneet algoritmit ja salausmenetelmät pelkkien konfiguraatioiden ja riippuvuuksien tarkistamisen lisäksi. Kyse on lopulta hyvin yksinkertaisista asioista: älä tee loistavaa ohjelmistoa ja pilaa sitä tuomalla siihen roskaa, konfiguroimalla se huonosti tai unohtamalla pitää uusimmat bugi- ja haavoittuvuuskorjaukset ajan tasalla. Muuten panostuksesi hyvään ohjelmistoon menee osittain hukkaan. Hoida ensin nämä melko helpot asiat. Automaatiolla poistat toistuvaa työtä ja parannat tuottavuutta merkittävästi. Et halua olla seuraava Equifax. Pidä silti aina varautumissuunnitelmat valmiina: kyse ei ole siitä, joudutko hyökkäyksen kohteeksi, vaan siitä, milloin se tapahtuu. Suunnittele ja rakenna arkkitehtuurisi kuin pahin olisi jo tapahtunut.

Monet näistä asioista voidaan automatisoida. Putkessa orkestroinnin ja vastaavien käytäntöjen tavoitteena on aina sekä ennakoiva toiminta että hyvän tietoturvatason ylläpitäminen. Jos aloitat alusta, tunnista salaisuudet, jotka tulisi tallentaa palveluntarjoajille tai holveihin tuhansien kilometrien päähän koodistasi, ja automatisoi sovellusten ja niiden alustojen pitäminen ajan tasalla. Vähimpien oikeuksien periaatteen ja zero trust -arkkitehtuurin soveltaminen suunnittelussa ja toteutuksessa tuo myös paljon hyötyjä. Vähimmät oikeudet varmistavat ensin ilmeisimmän, mutta auttavat myös tilanteiden mennessä pieleen lukitsemaan oikeat asiat tulipalon sytyttyä – vaikka se olisi hyvin vaikeaa ja aiheuttaisi todennäköisesti myös sivuvaikutuksia.

Zero trust on ajatuksena ollut olemassa pitkään, mutta se on edelleen pätevä lähtökohta modernin arkkitehtuurin suunnitteluun. Ennen oli turvallinen LAN ja suuri, paha WAN sen ulkopuolella, joten ihmiset luottivat – typerästi – palomuurin takana toimiviin asioihin automaattisesti. Monet asiat elämässä ovat harhaa, osa myönteistä ja osa kielteistä. LAN-liikenteeseen luottaminen on kielteistä harhaa. Samaa puolustavaa periaatetta tulisi soveltaa ohjelmistosuunnitteluun. Ajattele puolustavasti äläkä oleta mitään. Oleta aina zero trust ja todenna sekä auditoi poikkeuksetta. Yksi yleinen virhe on, ettei kaikkea kerätä talteen. Se, mitä et näe, ei ole olemassa. Sitä vähemmän voit analysoida, korreloida tai korjata sitä.

On myös tärkeää, ettei ohjelmistokehityksessä keksitä pyörää uudelleen. Tarvitsitpa OAuth-komponentin tai API gatewayn, valmiita ja laadukkaita ratkaisuja on saatavilla. Rajallisia resursseja ei kannata käyttää niiden rakentamiseen uudelleen, sillä kykysi kehittää, korjata ja ylläpitää niitä koko elinkaaren ajan on todennäköisesti huomattavasti pienempi kuin esimerkiksi Googlella. Noudata siis parhaita käytäntöjä, jotta pääset hyvään alkuun. Keskitä lokitus, suojaa lokit yhtä hyvin kuin datasi ja skannaa liikennettä aktiivisesti haitallisten toimijoiden, haittaohjelmien ja tilastollisten poikkeamien epäilyttävien tunnisteiden varalta. Muista, että ulosmenevä liikenne on yhtä tärkeää kuin sisääntuleva liikenne. Hyvää JUnit-testiä kirjoitettaessa positiivinen testi on yhtä tärkeä kuin negatiivinenkin – muuten olet kattanut vain kolikon toisen puolen. Ole luova.

Asioiden paljous ei saa tuntua ylivoimaiselta: niitä vaikuttaa olevan paljon, mutta ne tiivistyvät lopulta varsin suoraviivaisiin asioihin. Muista myös, että jonkin framework xyz:n vaatimustenmukaisuus ei tarkoita tietoturvaa – pahantahtoiset toimijat eivät välitä standardeista tai sertifikaateista. Pyri automatisoimaan tietoturvatestit ja -kontrollit, jotta voit keskittyä tärkeämpiin asioihin ja nukkua yösi hieman levollisemmin.