5 pågående hot mot din databas - och vad du behöver göra

Dina databaser är utsatta för potentiella säkerhetshot varje dag.

Här tittar vi på fem ofta förbisedda hot du borde prioritera och minimera – och hur.

1. Företagsdata går förlorade trots din backup

Drabbas ditt företag av en ransomeware-attack så kan dina verksamhetskritiska och känsliga data vara borta för alltid. Om till exempel hela faktureringsunderlaget försvann skulle kassan sina fortare än kvickt.

Det är väsentligt att du har en backup - en kopia av databasen vid en viss tidpunkt - för att kunna återställa din databasmiljö vid behov.

I princip tar alla backup på sin data men i många fall tyvärr alldeles för sällan eller på ett felaktigt sätt. Det är inte ovanligt att man lever i tron att backuperna fungerar utan att de egentligen testats fullt ut. Dessutom är de inte alltid gjorda på ett korrekt sätt utifrån de krav man har – vilket många inte är medvetna om. Gamla system löper extra stor risk för att det uppstår olika typer av problem som kan härledas just till backuper.

Men regelbundna backuper räcker inte långt i vår osäkra tid. Du behöver också kunna göra fungerande restore och recovery utifrån de krav som ställs.

En restore innebär att databasen återställs exakt som den var vid senaste backup-tillfället. En recovery går ett steg längre: databasen återställs på ett sådant sätt att du får tillbaka förändringar som skett efter den senaste backupen togs eller till en viss tidpunkt. På så sätt kan du komma tillbaka till de senaste transaktionerna i databasen eller, om det krävs, till dina data precis före incidenten. Det är inte minst viktigt vid en ransomeware-attack.

Har du har en process för alla tre stegen? Har ni i så fall testat att den funkar?

Om svaret är nej är du inte ensam. Många vet inte vad de ska göra om olyckan är framme, vilket inte sällan beror på bristande databaskompetens eller rutiner.  

Det är avgörande att du skapar processer och rutiner för backup, restore och recover – och testar dem så att du vet att de fungerar. Rutinerna behöver ta hänsyn till olika tänkbara möjligheter och scenarios. Om något inträffar behöver du snabbt kunna analysera och förstå vad som hänt, vilken data och vilka transaktioner som behöver återställas och hur långt tillbaka i tiden.

Om ni aldrig har genomfört en brandövning kan det bli riktigt jobbigt när eldsvådan är ett faktum.

Det här gäller framför allt on prem-databaser. Men lita inte på molnleverantörernas backup heller i alla lägen; det är inte säkert att de kan göra en recovery så att den möter dina krav på systemet. Du behöver fortfarande rutiner som ni själva har testat, övat och verifierat.  

2. En hotaktör utnyttjar dina känsliga data

Om dina känsliga data läcker vill du inte att någon ska kunna utnyttja dem till cyberattacker, utpressning eller att vinna konkurrensfördelar. Detta kan undvikas om illasinnade aktörer inte kan förstå och använda dem. Därför borde all känslig information vara krypterad om viktiga data hamnar på villovägar.

Men så ser det tyvärr sällan ut, med undantag för samhällskritisk verksamhet som försvar och sjukvård. Det är framför allt on-premdatabaser som innehåller okrypterade data. Orsaken är ofta att man vill undvika merkostnaden för kryptering, och till viss del också nedsatt performance.  

Molntjänster brukar däremot inkludera kryptering.

Generellt sett är krypterade data väldigt säkra. Så gör en analys av dina databaser och sätt en strategi för vilka data som behöver krypteras. Se sen till alla känsliga data är krypterade. Det är investering i god nattsömn.

3. Säkerhetsluckor uppstår i gammal programvara

Hur håller du databaserna säkra över tiden? Om din databaslösning inte lever upp till de säkerhetsnivåer som krävs har dina system snart ingen support. Och vad värre är: de blir ett lätt byte för attacker och gör det lättare för hackarna att utnyttja dina sårbarheter.

Life Cycle Management för databaser handlar om att införa uppgraderingar med nya features, men patchar spelar också en viktig roll. Dessa ”programrättningar” inom en viss version kommer tätare än uppgraderingar och görs för att täppa till säkerhetshål eller rätta till buggar.

De olika databasleverantörerna släpper säkerhetspatchar ett antal gånger per år. Problemet är att många företag aldrig installerar dem, eller bara installerar dem någon gång per år - ofta beroende på kompetensbrist, resursbrist eller att de finner det svårt att hitta lämpliga tidpunkter för patchning. Det sistnämnda kan handla om verksamhetskritiska system som kräver tillgängliga data dygnet runt. Men det finns lösningar som kan hjälpa dig att minimera nertiden vid patchning eller uppgradering.

Du gör klokt i att planera in minst två servicefönster per år för att lägga in säkerhetspatchar.

4. Allvarliga säkerhetsintrång upptäcks inte

Det gäller också att upptäcka och agera på hot innan de blir ett problem. Därför behöver din databasanvändning kontinuerligt loggas och övervakas. Det räcker sällan med det som loggas i dina appar och system som sällan spårar transaktioner i databaser.

Då kan det krävas så kallade ”database audit trails” - granskningsloggar - som bland annat övervakar inloggningar till databasen, vilka data som används, vem som använder dem och hur de används.

Förutom rätt databaskompetens behöver du för detta ha verktyg som skannar igenom loggarna för varje databas och presenterar det i ett användargränssnitt.

När någon loggar in någonstans och gör saker behöver spåren övervakas steg för steg. När ett avvikande eller onormalt beteende upptäcks ska systemet larma, till exempel om någon försöker manipulera dina data på ett inkorrekt sätt.

Men det kan vara svårt att genomföra i praktiken på grund av den stora mängden data som genereras. Därför är det viktigt att du är ytterst selektiv med vad som loggas i dina system och databaser, så att din audit trail blir hanterbar.

5. Gamla lösenord och databasaccess

Slutligen utgör ofta accessen till databaser och hanteringen av lösenord en risk. Det är mycket viktigt att se över tillgången till databaser, servrar och andra komponenter som databaserna använder, exempelvis SAN och NAS. Tyvärr ser jag ofta lösenord till admin-konton och applikationskonton som är enkla att knäcka. Många av dem ändras aldrig och en hel del är kända av obehöriga.

Fråga dig själv: finns det lösenord skrivna i klartext i diverse filer, script eller program? Har ni integrationer mellan system och databaser och accessen däremellan med olika användare och konton?

Summa summarum: för att hålla dina databaser säkra bör du alltså vara förberedd på att vid behov kunna göra backup, restore och recovery på ett korrekt sätt som uppfyller dina krav.

Se till att kryptera känsliga data, hålla programvaran aktuell, se över access och lösenord och överväg att införa audit trails.

Lycka till!

Andreas Andersson,
Senior Oracle DBA, itm8 Sverige