Databasesårbarheder: Sikring af Applikationens Hjerte

Databasen er ofte selve fundamentet i moderne softwareapplikationer. Det er her, alle dine “kronjuveler” – fra brugeroplysninger og adgangskoder til finansielle transaktioner og personfølsom data – gemmes. Dette gør også databasen til et primært mål for angribere. For en softwareudvikler eller IT-sikkerhedsprofessionel er det derfor helt essentielt at forstå, hvordan man sikrer sin database by design.

De mest udbredte sårbarheder i databaser

For at kunne forsvare os, skal vi først kende angrebsmetoderne.

1. SQL Injection (SQLi)

Selvom det er en af de ældste sårbarheder, er den stadig ekstremt udbredt. SQLi opstår, når bruger-input indsættes direkte i SQL-forespørgsler uden korrekt validering eller escaping. Dette lader en angriber “tale” direkte til databasen og potentielt læse, ændre eller slette alt indhold.

2. Svag autentificering og adgangskontrol

Alt for mange databaser kører med standard-adgangskoder eller uden adgangskoder overhovedet (f.eks. fejlkonfigurerede MongoDB- eller Redis-instanser på det åbne internet). Desuden ses ofte konti med alt for høje rettigheder til de opgaver, de skal løse.

3. Manglende kryptering

Hvis data gemmes i klartekst (at rest), eller hvis forbindelsen mellem applikationen og databasen er ukrypteret (in-transit), kan en angriber, der får adgang til serveren eller netværket, læse alt indholdet uden besvær.

4. Utilstrækkelig logning og auditering

Hvis din database ikke logger, hvem der tilgår hvilke data og hvornår, har du ingen chance for at opdage et igangværende angreb eller foretage en effektiv forensics-undersøgelse efter et databrud.

Best Practices: Sådan sikrer du din database

Her er de vigtigste skridt, du som softwareudvikler skal tage for at følge moderne sikkerhedsstandarder.

1. Brug Prepared Statements (Parameterized Queries)

Dette er den absolutte guldstandard for at forhindre SQL Injection. Ved at adskille selve SQL-kommandoen fra de data, brugeren sender ind, kan databasen aldrig forveksle bruger-input med en kommando.

  • Forkert: SELECT * FROM users WHERE id = ' + userInput + '
  • Rigtigt: SELECT * FROM users WHERE id = ? (hvor ? udfyldes af din database-driver bagefter).

2. Mindste rettighedsprincip (Principle of Least Privilege)

Din applikations database-bruger bør ALDRIG være root eller db_admin. Opret en dedikeret bruger til applikationen, der kun har de rettigheder, den absolut har brug for (f.eks. kun SELECT, INSERT og UPDATE på specifikke tabeller). Den skal ikke kunne slette tabeller eller tilgå systemindstillinger.

3. Forsvarslinjer gennem segmentering

Databasen bør aldrig være direkte tilgængelig fra internettet. Placer den i et lukket netværkssegment (f.eks. i et privat subnet i skyen), hvor kun din web- eller applikationsserver må tale med den. Brug en firewall eller Security Groups til at begrænse adgangen til kun de nødvendige porte.

4. Kryptering overalt

  • Data at Rest: Brug TDE (Transparent Data Encryption) eller krypter følsomme kolonner manuelt, før de gemmes.
  • Data in Transit: Sørg for, at din database-driver altid bruger TLS/SSL til at kryptere forbindelsen mellem applikationen og databasen.

5. Patching og vedligeholdelse

Database-motorer (som MySQL, PostgreSQL, MSSQL eller Oracle) har ligesom alt andet software sårbarheder. Sørg for altid at holde dem opdateret med de nyeste sikkerhedsopdateringer.

Konklusion

At sikre en database handler om mere end blot at skrive sikker kode; det er en kombination af tekniske værktøjer, korrekt netværksarkitektur og en stærk sikkerhedskultur. Som udvikler er dit vigtigste værktøj Prepared Statements og en sund skepsis overfor alt bruger-input.

Kilder

> Quiz: Test din viden

1. Hvad er guldstandarden til beskyttelse mod SQL Injection?

2. Hvad opstår SQL Injection af?

3. Nævn én hyppig årsag til databasebrud ud over SQL Injection.

4. Hvad gør en Prepared Statement?