Databaseserveren er det sted, hvor ERP-systemet, lønsystemet og fagsystemerne gemmer deres data. Den er ikke nødvendigvis synlig for brugerne, men den kan være målet for den, der bryder ind. Om databaserne er godt beskyttet, afhænger mindre af selve databaseproduktet og mere af tre ting, som driften styrer: hvem der kan nå serveren over nettet, hvilke konti der kan logge på, og hvor brede rettigheder kontiene har.
En test af databaseservere er derfor ikke en test af programmerne, der bruger dem. Fejl i et fagsystems kode hører til en webtest eller til leverandøren. Her er det driftens del, der er i fokus.
Hvem ejer hvad i databasen
Ansvaret for en databaseserver kan være delt, og det gør fund svære at placere.
- Serveren og styresystemet · drives af IT-afdelingen eller driftsleverandøren.
- Databaseprogrammet · installeres og opdateres typisk af driften, men nogle gange af systemets leverandør.
- Databaserne og deres konti · kan være oprettet af leverandøren af det fagsystem, der bruger dem.
- Dataene · ejes af den afdeling, der bruger systemet.
Skriv fordelingen ned, før testen begynder. Ellers lander fundene hos IT, selv om det kun er leverandøren, der kan rette dem. → Roller og rettigheder i forretningssystemer
Hvad testen afprøver
En intern test ser på databaseserverne som en del af nettet og stiller spørgsmål, som kan besvares uden at ændre i dataene.
- Netadgang · om databaserne kan nås fra brugernes net, eller kun fra de applikationsservere, der skal bruge dem.
- Login · om der findes konti med svage eller standardadgangskoder, og om der logges på med fælles konti.
- Programmernes konti · om det enkelte fagsystem har sin egen konto, og om den har flere rettigheder, end systemet behøver.
- Gemte loginoplysninger · om adgangskoder til databaserne ligger i filer, scripts eller opsætning, som andre kan læse. → Adgangskoder i scripts og konfigurationsfiler
- Funktioner, der ikke bruges · om databaseprogrammet har slået ting til, som giver adgang videre til selve serveren.
- Opdateringsstatus · om databaseprogrammet og styresystemet har kendte svagheder.
Microsoft anbefaler i sin vejledning til SQL Server kun at slå de funktioner til, som miljøet kræver, så der er færre at angribe. Det samme gælder andre databaseprodukter.
Det, IT skal have klar
- Oversigt over databaseservere · hvilke systemer der bruger dem, og hvem der ejer dataene.
- Aftal grænsen for data · testen skal kunne vise adgang uden at hente eller ændre persondata eller forretningsdata. Aftal, hvordan følsomme data dokumenteres. → Testeren fandt følsomme data
- Afklar leverandørernes vilkår · nogle fagsystemer må ikke berøres uden leverandørens accept.
- Kend de skrøbelige systemer · en ældre database, der kører lønnen, skal ikke belastes midt i en lønkørsel. → Skrøbelige systemer
- Sørg for backup · der skal være en frisk kopi af databaserne, før testen begynder.
Fundene og deres betydning
Fund om databaser kan falde i to grupper. Den første er adgangen udefra: databasen kan nås fra for mange steder, eller den har konti, som er lette at bruge. Den anden er rettighederne indefra: programmets konto er administrator i databasen, eller den samme konto bruges af flere systemer, så adgang til ét giver adgang til alle.
Den anden gruppe er let at undervurdere. Har et fagsystem fulde rettigheder i sin database, kan en svaghed i systemet blive til fuld kontrol over dataene og nogle gange over selve serveren. OWASP anbefaler derfor, at hvert program får sin egen konto med de mindst nødvendige rettigheder, og at programmets konto ikke er ejer af databasen.
Et fund om gemte adgangskoder kan vægtes højt, fordi det kan give adgang uden at skulle bryde noget. Det er også et af de fund, der kan rettes hurtigst.
Databaser, der ikke står i jeres serverrum
En del af databaserne kører måske ikke længere på jeres egne servere. Nogle ligger som tjeneste i Azure eller AWS, andre står hos fagsystemets leverandør, som også driver dem. Spørgsmålene er de samme, men svarene findes andre steder.
For en database som tjeneste i cloud er netadgangen og rettighederne en del af jeres egen opsætning af abonnementet, og de kan indgå i en test af cloudmiljøet. Selve platformen under tjenesten er udbyderens ansvar. For en database, som leverandøren driver, kan testen typisk kun vise, hvad der kan nås fra jeres side. Leverandørens interne opsætning er en sag for jeres leverandøraftale.
Notér i oversigten, hvor hver database står, og hvem der driver den. Så er det tydeligt, hvilke fund I selv kan rette, og hvilke der skal sendes videre. → Lagerkonti og databaser i Azure
Sådan retter I
Rettelserne følger nogle få principper, som kan bruges på tværs af produkter.
- Begræns vejen ind · databaserne kan kun nås fra de servere og administrationsmaskiner, der har brug for det. → Segmentering i dybden
- En konto pr. program · med de rettigheder, programmet faktisk bruger.
- Grupper frem for enkeltkonti · Microsoft anbefaler at give adgang via grupper i Active Directory, så adgang fjernes, når medarbejdere skifter rolle eller stopper.
- Adskil administratorrollen · databaseadministratorer har ikke automatisk alle rettigheder på serveren, og omvendt.
- Fjern gemte adgangskoder · og skift dem, der har ligget frit.
- Beskyt backup af databaserne · så den ikke kan slettes med den samme administratorkonto som resten.
Rettelser af programmets konti skal måske aftales med leverandøren, fordi systemet kan holde op med at virke, hvis rettighederne strammes uden afprøvning. Tag dem i et testmiljø, hvis I har et, eller i et planlagt vindue med en vej tilbage. → Rettelser uden at stoppe driften
Det skal I lade være med
- At lade testen hente rigtige data for at bevise et fund. Påvist adgang er tilstrækkeligt.
- At give leverandørens konto fulde rettigheder, fordi det er nemmest. Det gør hver svaghed i systemet større.
- At bruge den samme konto til flere systemer. Så rækker ét fund til dem alle.
- At glemme de små databaser. Den lokale database bag et værktøj kan rumme lige så følsomme data som ERP-systemet.
- At stramme rettigheder uden at afprøve. Et stoppet fagsystem er også en hændelse.
Hvad kan og ikke kan konkluderes
Testen viser, hvilke databaseservere den kunne nå, og hvilken adgang den kunne påvise med de konti og fra de udgangspunkter, den havde. Den siger ikke noget om fejl i de programmer, der bruger databaserne, og den vurderer ikke, om dataene er korrekte eller fuldstændige. Er en database udeladt efter aftale, gælder resultatet ikke for den.
Tjekliste til databaseserverne
- ☐ Er ejerskabet af server, databaseprogram, konti og data skrevet ned?
- ☐ Kan databaserne kun nås fra de servere, der skal bruge dem?
- ☐ Har hvert program sin egen konto med begrænsede rettigheder?
- ☐ Er gemte adgangskoder fundet, fjernet og skiftet?
- ☐ Er det aftalt, at testen ikke henter eller ændrer data?
- ☐ Er backup af databaserne beskyttet mod sletning?
Kilder
- OWASP Database Security Cheat Sheet: adskillelse af databaser på nettet, en konto pr. program med mindst mulige rettigheder, programmets konto ikke som ejer, loginoplysninger uden for kildekode og beskyttelse af backup.
- Microsoft Learn: SQL Server security best practices: mindst mulige rettigheder via grupper og roller, adskillelse af administratoropgaver, kun nødvendige funktioner slået til og backup, der er beskyttet mod en fælles administratorkonto.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Servere som testområde · Tjenestekonti
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
