Digital självständighet: Så byggdes vårt GitLab-ERP-system

Affärskontinuitetshantering är ett av våra affärsområden. Hur praktiserar vi det själva? Företagets hjärna är ett företagsresursplaneringssystem (enterprise resource planning system, ERP-system) som egentigen hanterar allt runt om affärsverksamheten, även publiceringen av detta blogginlägg.

På grund av tidigare erfarenheter valde vi GitLab. Därmed menar vi inte tjänsten gitlab.com utan inrättningen av det fria programmet i vårt privata nätverk.

För datasäkerhets skull förfoger vi över en privat LDAP-katalogtjänst och en privat certifikatauktoritet som utfärdar digitala certifikater. Samtliga containrar av våra tjänster utfärdas med hjälp av kontinuerlig integration och leverans i så kallade GitLab-pipelines som utförs i stängda gitlab-runner-containrar i en isolerad omgivning. Tack vare vår centrala logganläggning har vi alltid en översikt på det distribuerade systemet. På liknande sätt fungerar också vår GitLab-tjänst som vi erbjuder till våra kunder.

För oss är GitLab inte bara en praktisk web-gränssnitt till versionhanteringssystemet git. Affärsplanering, ledning, standardförfarande, kundprojekt och källkoden av hela infrastrukturen hanteras i systemet. Det låter oss planera, granska och testa alla ändringar innan de tas i bruk i produktion. Systemet av kontinuerlig integration och kontinuerlig leverans (CI/CD) håller bl.a. vår VPN-router och namnservrar uppdaterade vare sig någonting förändrades av oss, några säkerhetsuppdateringar publicerades eller några certifikat förnyades.

För förbättrad säkerhet begränsar vi giltighetstiden för våra privata certifikat till några dagar. Skulle ett certifikat komprometteras under dess giltighetsperiod, kan det snabbt ogiltigförklaras via vår återkallelsetjänst som stöder CRL och OCSP.

Giltighetstiden för våra offentliga certifikat bestäms av deras utfärdare, Let’s Encrypt. Även offentliga certifikatens giltighetsperioder kommer gradvis att förkortas från månader till veckor. En kort giltighetsperiod kräver i princip automatisk förnyelse.

Om vi vore ansvariga för domännamnet example.com och vår kund skulle vilja grunda en tjänst https://download.example.com, så skulle vi uppdatera våra namnservrar och ha ett offentligt eller privat certifikat utfärdas för namnet, genom att göra förändringarna i GitLab.

Tjänster i containrar

För att säkerställa datasäkerhet och hanterbarhet har vi sammanställt tjänster i containrar som kommunicerar med varandra via noggrant definierade TCP/IP-portar. Containrarna gör det lätt att förvara tjänsterna uppdaterade och för att duplicera eller flytta dem mellan servrar. GitLab-pipelines och tidtabeller styr hur, när och var containrarna kommer att uppdateras, testas och levereras i produktion.

Våra servicecontainrar bygger på en pålitlig och uppdaterad basbild, ofta alpine:latest, som vi anpassar till uppgiften på grund av regler som upprätthålls under versionskontroll.

Grundidén är att GitLab regelbundet bygger om hela innehållet i varje container enligt anvisningar i versionshanteringssystemet och kör funktionstester på dem innan de levereras till en produktionsmiljö. Till exempel, om ett angrepp mot vår webbserver lyckas, kan angriparen tillfälligt ändra innehållet. En automatisk uppdatering (eller en manuellt applicerad) skulle åtgärda situationen. Möjligtvis införs samtidigt en uppdatering som skulle stänga säkerhetshålet som möjliggjorde attacken.

Kärnan i vår GitLab-tjänst består av containrar byggda på GitLabs Docker-bilder och en Postgres-bild. Andra tjänster runt omkring inkluderar en LDAP-katalogtjänst och en e-post-server.

Städning av containrar

En nackdel med vår arbetsmetod innebär att vi ofta bygger om tjänstcontainrar är den enorma lagringskonsumtionen. Även om containrarna kan normalt byggas upp ganska snabbt igen, säkerhetskopierar vi vår containerförråd. Detta gör att vi kan återställa olika tjänster även när en försämrad internetanslutning skulle förhindra att vi laddar ner några containerbilder.

För att spara utrymme har vi utvecklat en förskjuten saneringstjänst som förvarar alla containrar som för närvarande behövs i produktion, såsom samt containrar som är under aktiv utveckling. Borttagningen måste inte bara bero på det senaste ändringsdatumet, eftersom olika containrar förnyas mellan olika intervall. Dessutom kan innehållet förbli oförändrad under lång tid, ifall varken basbilden eller våra justeringar har ändrats sedan den senaste uppdateringen.

Återhämtningsmål och risknivå

Det finns två aspekter för att återställa en tjänst efter en störning. Återställningspunktsmålet (recovery point objective RPO) definierar det maximalt acceptabla intervall under vilket data går förlorad. Återställningstidsmålet (recovery time objective*, RTO) är tiden från avbrottet till att tjänsten återställs.

Nästan all vår företagsdata utom e-postmappar och säkert lagrade privata nycklar lagras i GitLab-tjänsten. Således är det avgörande att säkerställa dess tillgänglighet.

Ett fel i vårt ERP-system påverkar inte direkt tjänsterna i produktion, som körs i helt andra miljöer i enlighet med vår flerlagriga datasäkerhetsarkitektur. Endast om en produktionstjänst råkade störas samtidigt som ERP-system, kan det ta lite längre tid att återställa den observerbara tjänsten.

Vårt återhämtningstidsmål är ganska slappt, kanske några arbetsdagar. Det skulle vara den värsta tiden som behövs för att sätta upp ERP-systemet i en ny dator på en annan plats, till exempel vid brand.

Vårt återställningspunktsmål är den sista fullständiga säkerhetskopian, vilken för närvarande skapas en gång i veckan. Vi kan förlora några arbetsdagar av data. De mest viktiga av dem kan återställas manuellt baserat på mejl som skickas av systemet samt på git-förråd som finns på personliga datorer.

Risknivån och återhämtningstiden för ett system kan minskas avsevärt genom att implementera en högtillgänglig tjänst så att vid ett fel kan man snabbt byta till en annan server. Det är dock svårt att implementera och testa realtidsreplikering mellan geografiskt distribuerade system.

Säkerhetskopierade ögonblicksbilder för katastrofåterställning

För maximal operativ tillförlitlighet undviker vi inkrementell säkerhetskopiering. Våra fullständiga säkerhetskopior utgör en logisk backup av databasens innehåll. Även om det persistenta tillståndet i GitLab är uppdelat i löst kopplade komponenter, är det möjligt att skapa en konsekvent snapshot utan att stänga ner systemet.

Att återställa en logisk ögonblicksbild av en databas kan vara mer tidskrävande än att återställa en fysisk kopia, vilket skulle innehålla färdiga indexdatastrukturer. Med den logiska formen är datavolymen mindre och en möjlig intern korruption av databasen kommer att tas bort vid inspelningen. Den logiska formen är också mer pålitlig vid systemuppgraderingar som kan förändra lagringsformatet.

Det är bra att starta en systemuppdatering direkt efter att en säkerhetskopia har skapats. På så sätt, om problem skulle uppstå, kan systemet rullas tillbaka till det gamla innehållet och mjukvaruversionen. En uppdatering skulle kunna göra involvera vissa ändringar av lagringsformatet som förhindrar en återgång till en tidigare version. Särskilt stora uppdateringar bör testas noggrant i en separat iscensättningsmiljö innan de tas i produktion.

Vi begränsar det utrymme som tas upp av backuper. Innan säkerhetskopieringsproceduren initieras, städer vi containrarna, vilket kommer att blockera körningen av GitLab-pipelines för en kort tid. Dessutom implementerar vi säkerhetskopieringsrotationen farfar-far-son (Grandfather-Father-Son, GFS): Några senaste säkerhetskopior sparas alltid. Av säkerhetskopior som är äldre än ett par månader, behåller vi en per månad i upp till ett par år. Av äldre säkerhetskopior behåller vi en per år.

Vår motivering för denna beskärning av gamla säkerhetskopior är att det är ovanligt händelse för att radera data, vanligtvis krävt av datalagringspolicyn. Mellan två säkerhetskopior läggs vanligtvis bara poster till. Om något innehåll som är under versionskontroll ändras eller raderas, kommer det nya innehållet att läggas till i en egen ändringsuppsättning och hela ändringshistoriken kommer att finnas tillgänglig i git-arkivet. Endast borttagningen av ett git-arkiv skulle vara slutgiltigt – och extremt sällsynt.

Pröva återställningen

Ett försök att återställa systemet från en säkerhetskopia måste göras regelbundet, innan en katastrof inträffar. Annars kan vi få reda på det på det hårda sättet att den senaste användbara säkerhetskopian är mycket gammal.

Eftersom vår data är krypterad inte bara under överföring utan även i vila, innebär återställningen hantering av krypteringsnycklar. Nycklarna hålls förstås separata från krypterade ögonblicksbilder, eftersom lagring av dem tillsammans skulle göra krypteringen värdelös.

Vi för register över regelbundna övningar av katastrofåterställning från en fjärrbackup.

Slutsats

Ett företag som verkar inom ett reglerat affärsområde måste garantera sin datasäkerhet, dataintegritet och affärskontinuitet. Servicenivåmålet kommer att uppnås via ett ERP-system som stödjer standardförfarande och automatiserade processer. Idag är det möjligt att uppnå allt detta på ett leverantörsoberoende sätt med hjälp av öppen källkod.