Grunnleggende databasesikkerhet for små aktører: slik unngår du de vanligste tabbene

Mange små bedrifter, organisasjoner og frilansere har i dag en database et sted i bakgrunnen, ofte knyttet til et nettsted eller en enkel fagsystem-løsning. Likevel er databasesikkerhet for mange et litt mystisk tema som overlates til “noen andre”.

I praksis er det ofte her de mest sensitive dataene ligger: kundelister, ordre, innlogginger, logger og personopplysninger. Derfor lønner det seg å forstå noen grunnprinsipper, selv om du aldri skal bli databaseekspert.

Hva er en database, og hvorfor er den ekstra sårbar?

En database er et system som lagrer og organiserer data, for eksempel MySQL, MariaDB eller PostgreSQL. De fleste publiseringsløsninger, nettbutikker og interne fagsystemer bruker en slik database i bakgrunnen til alt fra innhold til brukerkontoer.

Sårbarheten oppstår fordi databasen ofte ligger på samme server som nettstedet, er koblet til internett, og inneholder data som kan være verdifulle for andre. Hvis noen først får tilgang, kan de hente ut mye på kort tid.

Derfor handler databasesikkerhet om å gjøre det vanskelig å komme inn, begrense hva som er tilgjengelig hvis noen først kommer inn, og ha en plan hvis noe går galt.

Start med det viktigste: tilgang og passord

For mange små løsninger bruker én og samme databasebruker til “alt”, gjerne med et passord som ble satt for mange år siden. Dette er praktisk, men gir unødvendig høy risiko hvis noen får tak i tilgangsdetaljene.

Noen grunnregler er ekstra nyttige:

• Egne brukere per system: Gi for eksempel nettbutikken sin egen databasebruker, og fagverktøyet en annen.
• Sterke og unike passord: Ikke gjenbruk databasepassord andre steder, og bruk lange, tilfeldige passord som lagres i en passordadministrator.
• Endre standardnavn: Unngå brukernavn som “root” eller “admin” der det er mulig, og ikke bruk selve databasenavnet som brukernavn.

Hvis du bruker en driftspartner eller webhotell, kan du ofte administrere databasebrukere i kontrollpanelet. Be eventuelt leverandøren om hjelp til å rydde opp i gamle brukere og tilganger.

Gi færrest mulig rettigheter: prinsippet om minste privilegium

Mange databasesystemer har en standardbruker med “full kontroll” på alt. Det er praktisk i oppsettfasen, men gir unødig stor skade hvis innloggingsdetaljene lekker. En angriper kan da endre eller slette alt i én operasjon.

Prøv heller å tenke: “Hva trenger dette systemet egentlig å gjøre?”

• Et publiseringssystem trenger typisk å lese og skrive i bestemte tabeller, men sjelden administrere andre databaser.
• Et rapporteringsverktøy kan ofte nøye seg med lesetilgang.
• Tekniske testbrukere kan begrenses til helt spesifikke tabeller.

Dette kalles prinsippet om minste privilegium. Jo mindre en bruker kan gjøre, desto mindre alvorlig blir det hvis passordet på avveie.

Begrens hvor databasen er synlig fra

Databasen bør ikke være direkte tilgjengelig fra “hele internett” hvis det kan unngås. For mange små oppsett er det nok at kun serveren som kjører nettstedet eller systemet får koble seg til databasen.

Noen praktiske grep du kan diskutere med leverandøren eller utvikleren din:

• Kun lokal tilgang: Databasen aksepterer bare tilkoblinger fra samme server (localhost).
• IP-begrensning: Hvis du må koble deg til eksternt, begrens til spesifikke IP-adresser, for eksempel kontoret eller en VPN-løsning.
• Lukk unødvendige porter: Databaseporter som ikke trengs fra utsiden, bør stenges i brannmuren.

Poenget er å redusere antall “dører” inn til databasen. Selv om passordet er sterkt, er det lurt å ha færrest mulig innganger der noen kan prøve seg.

Unngå klassikeren: usikre spørringer og SQL injection

Hvis du selv utvikler løsninger, eller bestiller utvikling, er måten applikasjonen snakker med databasen på minst like viktig som innstillingene i selve databasen. En av de vanligste feilene er usikre spørringer, ofte omtalt som SQL injection.

Det oppstår når brukerinndata (for eksempel et søkefelt, skjema eller URL) blandes direkte inn i en databasespørring uten rensing eller parametre. Da kan en angriper snike inn ekstra kommandoer i stedet for bare tekst.

For å redusere denne risikoen bør du:

• Bruke rammeverk og biblioteker som håndterer parametere riktig.
• Unngå å sette sammen SQL-strenger manuelt med brukerinput.
• Ha kodegjennomgang på funksjoner som lager eller endrer data i databasen.

Hvis du kjøper utviklingstjenester, kan du rett og slett stille spørsmålet: “Hvordan sikrer dere dere mot SQL injection i denne løsningen?” Det alene gir ofte en nyttig diskusjon.

Kryptering av sensitive data

Ikke all data trenger å behandles likt. En uskyldig produktbeskrivelse er én ting, mens personnumre, helseopplysninger eller andre sensitive felt krever mer omtanke. Selv i små systemer kan kryptering være aktuelt.

Noen enkle prinsipper:

• Passord skal ikke lagres i klartekst: De skal lagres som sikre “hash-verdier” som ikke kan leses direkte.
• Særlig sensitive feltkan vurderes kryptert, slik at de ikke kan leses rett ut ved et innbrudd.
• Krypteringsnøklermå lagres trygt, ikke rett ved siden av databasen uten ekstra beskyttelse.

Tekniske detaljer rundt kryptering bør håndteres av fagpersoner, men det er nyttig som eier å være klar over at det finnes flere nivåer av vern, og at ikke alt bør ligge “åpent” i databasen.

Sikkerhetskopi og gjenoppretting uten panikk

Selv med gode tiltak kan feil og uhell skje. Da er det avgjørende å ha oppdatert sikkerhetskopi av databasen og en realistisk plan for å bruke den. En backup som ingen vet hvor ligger, eller hvordan gjenopprettes, hjelper lite under press.

Noen konkrete spørsmål du bør kunne svare på:

• Hvor ofte tas det sikkerhetskopi av databasen?
• Hvor lenge lagres gamle kopier?
• Hvor lagres de, og er de beskyttet mot uautorisert innsyn?
• Hvem kan gjenopprette, og hvor lang tid vil det typisk ta?

Det er lurt å teste en gjenoppretting med jevne mellomrom, for eksempel på en separat testserver. Da slipper du å finne ut av alt for første gang akkurat når tidsfristene er strammest.

En enkel rutine du faktisk kan følge

Databasesikkerhet trenger ikke være et engangsprosjekt. Det viktigste er å få på plass en kort, konkret rutine du kan leve med over tid, selv om du ikke jobber med dette til daglig.

En enkel årshjul-aktig sjekkliste kan for eksempel være:

• En gang i året: gå gjennom databasebrukere, slett de som ikke brukes, og juster rettigheter der de er for brede.
• To ganger i året: sjekk at sikkerhetskopier lages som planlagt, og test minst én gjenoppretting.
• Ved nye prosjekter: still krav om sikre spørringer, minst mulig rettigheter og oppdatert dokumentasjon på databasen.

Med noen få bevisste valg kan du redusere risikoen betraktelig, uten å drukne i tekniske detaljer. Databasen er ofte hjertet i de digitale løsningene dine, og fortjener litt mer oppmerksomhet enn bare “den greia utvikleren satt opp en gang”.