Itsenäisen GitLab-toiminnanohjausjärjestelmämme asennus

Yrityksemme palveluihin kuuluu jatkuvuuden varmistaminen. Miten se mahtaa toteutua omalla kohdallamme? Yrityksen aivot on toiminnanohjausjärjestelmä, jolla oikeastaan hallitaan kaikkea liiketoimintaan liittyvää, kuten vaikkapa tämän kirjoituksen julkaisua.

Hyvien aiempien kokemusten perusteella olemme päätyneet GitLab-tuotteeseen. Emme gitlab.com-palveluun vaan kyseisen avoimen lähdekoodin ohjelmiston asentamiseen omaan yksityiseen verkkoomme.

Tietoturvan takaamiseksi meillä on oma suljettu LDAP-hakemistopalvelu ja varmenneinfrastruktuuri. Kaikkien palvelujen kontit muodostetaan GitLab-säännöstöjen avulla suljetuissa gitlab-runner-konteissa eristetyssä ympäristössä. Saamme järjestelmästä tarkan tilannekuvan keskitettyyn lokipalveluumme. Samalta pohjalta toimii myös asiakkaillemme tarjoamamme GitLab-palvelu.

GitLab ei ole meille pelkästään näppärä web-käyttöliittymä git-versiohallintajärjestelmään. Liiketoiminnan suunnittelu, hallinnointi, vakioidut toimintatavat, asiakasprojektit ja koko infrastruktuurin lähdekoodi ovat samassa järjestelmässä. Sen avulla suunnitellaan, katselmoidaan ja testataan kaikki muutokset ennen tuotantoon viemistä. Jatkuvan integroinnin ja toimituksen järjestelmä pitää esimerkiksi VPN-yhdyskäytävämme ja nimipalvelimemme ajan tasalla, olipa kyse omista muutoksistamme, tietoturvapäivityksistä tai varmenteiden hallinnoimisesta tai uusimisesta.

Tietoturvan parantamiseksi yksityiset varmenteemme ovat voimassa vain muutamia vuorokausia. Jos jokin varmenteemme vaarantuisi voimassaoloaikanaan, se voidaan välittömästi peruuttaa CRL- ja OCSP-pohjaisesta sulkupalvelustamme.

Julkisten varmenteidemme voimassaoloajan määrää niiden varmentaja Let’s Encrypt. Julkistenkin varmenteiden voimassaoloaika lyhenee vähitellen kuukausista viikkoihin. Lyhyt voimassaoloaika käytännössä vaatii uusimisen automatisoimista.

Jos olisimme osoitteen example.com verkkotunnusvälittäjä ja asiakkaamme haluaisi perustaa palvelun https://download.example.com, päivittäisimme nimipalvelintamme ja hankkisimme kyseiselle nimelle julkisen tai yksityisen varmenteen tekemällä muutokset GitLabissa.

Kontitettuja palveluja

Tietoturvan ja hallittavuuden vuoksi olemme koostaneet palveluista kontteja, jotka ovat yhteydessä toisiinsa tarkoin rajattujen TCP/IP-porttien välityksellä. Konttien ansiosta palvelut on helppo pitää ajan tasalla ja tarvittaessa monistaa tai siirtää palvelimesta toiseen. GitLabin säännöstöillä ja aikatauluilla määrätään, miten, missä ja milloin kontit uusitaan, testataan ja siirretään tuotantoon.

Omien palvelukonttiemme pohjana on jokin luotettu ajantasainen perusjärjestelmä, usein alpine:latest, joka muokataan tehtävään sopivaksi versionhallintaan tallennettujen sääntöjen mukaisesti.

Perusajatus on, että GitLab muodostaa konttien koko sisällön säännöllisesti uusiksi versiohallintajärjestelmän ohjaamana ja testaa niiden toiminnan ennen tuotantoympäristöön siirtämistä. Jos esimerkiksi verkkosivustomme palvelin joutuisi hyökkäyksen kohteeksi, hyökkääjä voisi ehkä tilapäisesti muokata sisältöä. Viimeistään seuraava automaattipäivitys korjaisi tilanteen ja saattaisi samalla asentaa tietoturvapäivityksen, jossa hyökkäyksen mahdollistanut tietoturva-aukko on korjattu.

GitLab-palvelumme ydin koostuu GitLabin Docker-kuvista ja Postgres-kuvasta rakennetuista konteista. Ympärillä on paljon muutakin, kuten LDAP-pohjainen käyttäjähakemisto ja sähköpostipalvelu.

Konttien siivous

Usein uusittaviin palvelukontteihin perustuva toimintatapamme varjopuoli on tallennustilan kulutus. Vaikka kontit yleensä voidaan tarvittaessa muodostaa uudelleen melko nopeasti, meillä on varmistettu konttivarasto. Siten meidän on mahdollista palauttaa eri palvelut sellaisessakin poikkeustilanteessa, että käyttöjärjestelmäjakeluja ei pystytä lataamaan.

Tilan säästämiseksi olemme toteuttaneet monivaiheisen siivouspalvelun, joka säilyttää kaikki tuotannossa kulloinkin tarvittavat kontit, samoin kaikki aktiivisessa kehityksessä olevat kontit. Poistaminen ei saa perustua pelkästään viimeisimpään muutokseen, sillä eri konttien uusimisaikataulu vaihtelee, ja joskus uusiminen ei muuta sisältöä lainkaan, jos sekä perusta että omat lisäyksemme pysyvät muuttumattomina uusimiskertojen välillä.

Toipumistavoitteet ja riskitaso

Minkä tahansa palvelun varmistamisessa keskeistä on rajata häiriön vaikutukset: miltä ajalta tietoja saa kadota eli toipumispistetavoite (recovery point objective, RPO) ja toipumisaikatavoite (recovery time objective, RTO).

Lähes kaikki yrityksemme tieto sähköpostilaatikoita ja turvallisesti säilytettyjä salaisia avaimia lukuun ottamatta on GitLab-järjestelmässä. Siksi sen toiminnan varmistaminen on elintärkeää.

Toiminnanohjausjärjestelmämme vikaantuminen ei suoraan vaikuta tuotettuihin palveluihin, joita ajetaan kerroksittaisen tietoturva-arkkitehtuurimme mukaisesti täysin erillisissä ympäristöissä. Ainoastaan, jos jokin palvelu sattuisi vikaantumaan samanaikaisesti toiminnanohjausjärjestelmän kanssa, näkyvän palvelun palautuminen voisi kestää odotettua pidempään.

Toipumisaikatavoitteemme on siis melko väljä, ehkä muutama työpäivä. Sen verran voisi pahimmassa tapauksessa kulua aikaa toiminnanohjausjärjestelmän asentamiseen uuteen paikkaan ja laitteeseen esimerkiksi tulipalon jäljiltä.

Toipumispistetavoiteemme on viimeisin täysi varmuuskopio eli tällä hetkellä yksi viikko. Muutaman viime päivän tietoja saatetaan menettää, mutta tärkeimmät niistäkin ovat käsin palautettavissa järjestelmän lähettämien sähköpostiviestien sekä työntekijöiden henkilökohtaisilla laitteilla olevien git-tietovarastojen perusteella.

Minkä tahansa järjestelmän riskitasoa ja toipumisaikaa voi huomattavasti kaventaa toteuttamalla korkean saatavuuden palvelun, jolloin yksittäisen laitteen vikaantuessa voidaan nopeasti siirtyä käyttämään toista. Ajantasainen kahdentaminen maantieteellisesti hajautettujen järjestelmien välillä on kuitenkin hankala toteuttaa ja testata.

Varmistetut tilannevedokset häiriötilanteista toipumiseen

Toimintavarmuuden vuoksi emme käytä lisäysvarmistusta vaan täyttä varmistusta ja tietokannan sisällön loogista varmistusta. Vaikka GitLab-järjestelmän pysyvä tila on hajautettu löyhästi kytkettyihin osiin, nykyään on mahdollista muodostaa konsistentti tilannevedos järjestelmää pysäyttämättä.

Tietokannan loogisen varmistuksen palauttaminen voi kestää pidempään kuin fyysisen tallennusmuodon, jossa indeksit olisivat valmiiksi rakennettuina. Loogista muotoa käytettäessä varmistettava tietomäärä on pienempi ja mahdollinen tietokannan sisäinen korruptio korjautuu palautuksen yhteydessä. Looginen muoto on varmempi toimimaan myös järjestelmän päivityksen jälkeen, vaikka fyysinen tallennusmuoto muuttuisi.

Varmistusten on hyvä olla ajan tasalla ennen järjestelmän päivittämistä. Jos pian päivityksen jälkeen ilmenee ongelmia, järjestelmä voidaan palauttaa päivitystä edeltävään versioon ja tietosisältöön. Tallennusmuotohan voi muuttua päivityksen yhteydessä ja siten estää suoran paluun vanhaan ohjelmistoversioon. Etenkin suuria päivityksiä on parasta koekäyttää erillisessä testiympäristössä ennen tuotantoympäristön muuttamista.

Rajoitamme varmistusten tarvitsemaa tallennustilaa. Ennen varmistusta siivoamme kontit, mikä estää GitLab-säännöstöjen ajamisen hetkeksi. Sovellamme varmistettujen tilannevedosten säilyttämiseen sukupolviperiaatetta (isoisä-isä-poika): Säilytämme muutaman viimeisimmän varmistuksen kokonaan. Paria kuukautta vanhemmista varmistuksista säilytämme yhden kuukaudelta ja paria vuotta vanhemmista kuukausivarmistuksista yhden vuotta kohden.

Perustelemme varmistusten karsintakäytäntöämme sillä, että tietojen poistaminen on harvinaista ja yleensä säilytyskäytäntöjen ohjaamaa. Varmistettujen tilannevedosten välillä järjestelmään yleensä vain lisätään kirjauksia. Yleensä, kun jotakin versiohallinnan piirissä olevaa sisältöä muutetaan tai poistetaan, uusi sisältö lisätään omaan muutoskokoelmaansa ja koko vanha muutoshistoria säilyy git-tietovarastossa. Ainoastaan koko tietovaraston poistaminen olisi lopullista – ja hyvin harvinaista.

Palautusten testaaminen

Varmistetun tilannevedoksen palautusta on harjoiteltava säännöllisesti eikä vasta vahingon tapahduttua. Muuten voi käydä kaksinkertainen vahinko eli joudutaan toteamaan, että viimeisin käyttökelpoinen varmuuskopio on erittäin vanha.

Koska tietomme on salattu paitsi siirron aikana myös levossa, palautukseen liittyy myös salausavainten hallinta. Avaimet säilytetään tietenkin erillään salatuista tilannevedoksista, koska muuten salaus on hyödytön.

GitLab-säännöstön ohjaamaan säännölliseen varmistukseen kuuluu tietysti myös palautuksen tarkistaminen omassa rajatussa konttiympäristössään. Palautuksen epäonnistumisesta tulee hälytys.

Harjoittelemme säännöllisesti ja diarisoidusti etävarmistuksen palauttamista.

Yhteenveto

Säännellyssä ympäristössä toimiva yritys tarvitsee tietoturvan, tietosuojan ja liiketoiminnan jatkuvuuden takaamiseksi vakioituja toimintatapoja tukevan toiminnanohjausjärjestelmän, johon rakennettu automaatio takaa luotettavan palvelutason. Nykyään kaikki tämä on mahdollista koostaa yksittäisistä toimittajista riippumattomasti hyödyntämällä avoimen lähdekoodin ohjelmistoja.