Verstaspäiväkirja on jatkuva sarja siitä, miten työkalut oikeasti syntyvät, omissa ja asiakkaiden projekteissa, ideasta erehdyksen kautta iteraatioon. Tämä on osa 4, sarjan päätös. Aiemmat: osa 1, osa 2 ja osa 3.

Sarjan kolme ensimmäistä osaa olettivat, että joku on tehnyt päätöksiä: ostanut laskentaa, ostanut hallitun pilven, hallinnut identiteetit. Iso osa pieniä yrityksiä ei ole tehnyt mitään näistä, ei siksi, että olisi huolimaton, vaan siksi, että organisoitu tietoturva maksaa ja yritys on kasvanut orgaanisesti, yksi työkalu kerrallaan. Tämä osa on niille.

Pk-yrityksen todellinen tietoturvatilanne

Rehellinen kuva näyttää usein tältä: kuluttaja- ja yritystilien sekamelska, ei laitehallintaa, ei kertakirjautumista, jaettuja salasanoja, ja data hajallaan kolmen palveluntarjoajan pilvissä. Gmail markkinointiin, koska se perustettiin ensin. Outlook laskutukseen, koska kirjanpitäjä halusi sen. Proton siihen, minkä piti pysyä yksityisenä. Kukaan ei omista kokonaiskuvaa siitä, missä yrityksen tieto oikeastaan on.

Tämä ei ole moraalinen vika. Se on kasvun sivutuote, ja täsmälleen sama ilmiö toistuu isommissakin taloissa. Mutta se tarkoittaa, että kaksi peruskysymystä, „missä meidän data on” ja „kuka siihen pääsee”, jäävät ilman vastausta. Ja juuri vastaamattomuus on riski, ei mikään yksittäinen palvelu. Et voi suojata sitä, mitä et tiedä omistavasi.

Python liimana: API:t, ei uusia järjestelmiä

Ratkaisun ei tarvitse olla iso alusta, jonka käyttöönotto vie puoli vuotta. Usein järkevin liike on kirjoittaa pieniä Python-skriptejä palveluntarjoajien rajapintoja vasten ja tehdä täsmälleen ne asiat, jotka merkitsevät. Gmaililla on rajapintansa, Microsoftilla Graph (sama kuin osassa 3), Protonilla Bridge ja IMAP. Kolme pilveä, yksi ohut koodikerros niiden yli.

Miksi juuri Python? Koska sille on valmiit kirjastot lähes jokaiselle näistä rajapinnoista, koodi on luettavaa myös sen kirjoittaneen ollessa lomalla, ja pienen skriptin voi ajaa vaikka kerran yössä ilman raskasta infrastruktuuria. Rajapinnat käyttävät nykyään pääosin OAuth-tunnistautumista, eli skripti saa rajatun, peruutettavissa olevan pääsyn, ei kenenkään salasanaa. Se on tärkeä turvaominaisuus, ei tekninen sivuseikka.

Idea on sama kuin osassa 1: kokoa hajallaan oleva tieto yhteen hallittuun, paikalliseen paikkaan. Nyt lähteinä ovat vain sähköpostit ja pilvitallennus useasta palvelusta yhden dokumenttikansion sijaan.

Pienelle yritykselle sata riviä omaa Python-koodia voi tehdä enemmän kuin kallis alusta, jota kukaan ei ehdi ottaa käyttöön.

Mitä sillä koodilla oikeasti tekee

Viisi konkreettista esimerkkiä, kaikki yleisiä kuvioita, eivät asiakaskohtaisia toteutuksia.

Inventaario. Skripti, joka käy läpi kolme postilaatikkoa ja pilvikansiot ja listaa, mitä dataa missäkin on: liitteet, jakolinkit, vanhat tiedostot, kuka omistaa mitäkin. Usein se on ensimmäinen kerta, kun joku näkee kokonaiskuvan yhdellä silmäyksellä, ja lähes aina se paljastaa yllätyksiä.

Riskijaot esiin. Skripti, joka etsii ulkoisesti jaetut tiedostot ja liian avoimet linkit. Yleisin vuotoreitti pk-yrityksessä ei ole hakkeri vaan unohtunut „kaikki, joilla on linkki” -jako vuoden takaa, joka on edelleen auki koko internetille.

Paikallinen varmuuskopio. Skripti, joka vetää datan kolmesta palvelusta yöllä salattuun paikalliseen varmuuskopioon. Jos yksi tili menetetään, jäädytetään tai joutuu lunnasohjelman lukkoon, tieto ei katoa mukana. Pilvi ei ole varmuuskopio, se on jonkun toisen kone.

Siivous ja säilytys. Skripti, joka tunnistaa vanhentuneen tai päällekkäisen datan ja ehdottaa poistoa. Vähemmän dataa tarkoittaa pienempää hyökkäyspintaa ja helpompaa GDPR-hallintaa: tietoa, jota ei ole, ei voi vuotaa.

Haettava tietovarasto. Ja lopulta: syötä tuo koottu ja siivottu data osan 1 paikalliseen RAG:iin, ja pk-yritys saa saman „kysy dataltasi” -kyvyn ilman, että luovuttaa dataansa yhdellekään isolle toimittajalle. Ympyrä sulkeutuu.

Rajat ja rehellisyys

Tässä pitää olla suora: tämä on liimaa, ei tietoturvaohjelmaa. Python-skriptit eivät korvaa monivaiheista tunnistautumista, kunnollisia varmuuskopioita tai sitä, että joku on nimetysti vastuussa. Ne kaventavat kuilua ja tekevät näkyväksi sen, mitä ei ennen nähnyt, mutta perusasiat on silti tehtävä. Skripti, joka kertoo missä data on, ei suojaa dataa; se kertoo mitä on suojattava.

Skriptit myös vaativat ylläpitoa: rajapinnat muuttuvat, tunnukset vanhenevat, jokin hajoaa aina huonoimpaan aikaan. Pieni koodi on halpaa rakentaa mutta ei ilmaista pitää yllä, ja jos sen kirjoittanut lähtee, jonkun muun on ymmärrettävä sitä. Se on rehellinen hinta, ja se kannattaa sanoa ääneen ennen kuin aloittaa, ei sen jälkeen.

Miten tästä pääsee alkuun

Ei kaikkea kerralla. Aloita inventaariosta, pelkkä tieto siitä, missä data on ja mikä on avointa, on jo iso askel ja usein silmiä avaava. Sen jälkeen tärkeysjärjestys on lähes aina sama: sulje riskialttiit jaot, varmista varmuuskopiot, laita MFA päälle kaikkialle minne saa. Vasta kun perusta on kunnossa, kannattaa rakentaa haettavaa tietovarastoa. Järjestys ei ole makuasia, on turha rakentaa hienoa hakua datalle, joka vuotaa auki olevasta linkistä.

Mihin tämä sarja päätyi

Aloitimme paikallisesta, data pysyy kotona (osa 1). Kun teho ei riitä, sitä voi ostaa, mutta vastuu jää ja siirtyy sopimukseen (osa 2). Kun data on jo pilvessä, raja siirtyy identiteettiin ja pääsynhallintaan (osa 3). Ja kun mitään näistä ei ole ostettu, pieni koodi kuroo kuilun umpeen (osa 4).

Läpi koko sarjan kulkee yksi ajatus: data-suvereniteetti ei ole rahakysymys eikä kokoluokan etuoikeus. Se on päätös, ja se on saavutettavissa jokaisella budjetilla. Tärkeintä on tietää, missä oma tieto on ja kuka siihen pääsee. Kaikki muu rakentuu sen päälle.

Verstaspäiväkirja jatkuu, seuraavaksi asiakasprojektien pariin.