NoSQL Databaser og Sikkerhed: En Sammenligning med Traditionelle SQL Databaser

De seneste årtiers eksplosive vækst i datamængder, distribuerede systemer og cloud-arkitekturer har ændret det teknologiske landskab fundamentalt. Mens traditionelle relationelle databaser (RDBMS) med SQL i årtier har domineret datahåndtering, er NoSQL-databaser i dag essentielle komponenter i alt fra sociale medier og realtidsanalyse til IoT-platforme og e-handel. Men den øgede popularitet medfører også øget opmærksomhed fra angribere – og NoSQL-databaser bringer en helt særlig sikkerhedsprofil med sig, som enhver IT-sikkerhedsprofessionel bør kende.

Denne artikel giver et dybtgående indblik i NoSQL-databasers sikkerhedsmæssige karakteristika og sammenligner dem systematisk med de kendte trusler og kontroller i traditionelle SQL-databasemiljøer.

1. Hvad er NoSQL? En teknisk kontekstualisering

NoSQL (“Not Only SQL”) er en bred betegnelse for databasemanagementsystemer, der afviger fra den klassiske relationelle model. I stedet for faste tabeller med foruddefinerede skemaer, tilbyder NoSQL-databaser fleksible datamodeller optimeret til specifikke use cases og skaleringsscenarier.

De fire primære datamodeller

Til forskel fra SQL-databaser tilbyder de fleste NoSQL-systemer horisontal skalering (sharding på tværs af mange noder) og fleksible skemaer, men oftest på bekostning af strenge ACID-garantier (Atomicity, Consistency, Isolation, Durability). De fleste NoSQL-systemer følger i stedet BASE-modellen: Basically Available, Soft state, Eventually consistent.

2. Sikkerhedsmodellen i traditionelle SQL-databaser

For at lave en fair sammenligning er det nødvendigt at forstå det solide sikkerhedsfundament, som årtiers brug af SQL-databaser har bygget op.

Stærke sider ved SQL-databasesikkerhed

Moden sikkerhedsarkitektur: SQL-databaser som PostgreSQL, MySQL og Microsoft SQL Server er bygget op med et velkendt og modent adgangskontrolsystem. Rollehierarkier, GRANT/REVOKE-kommandoer og row-level security giver granulær kontrol over, hvem der må se og manipulere hvilke data.

Strenge ACID-transaktioner: SQL-databasers transaktionsmodel sikrer dataintegritet selv under uventede fejl og samtidige skrivninger. Dette er kritisk i sikkerhedsmæssig kontekst, da inkonsistente data kan udnyttes af angribere.

Strikt skema: Det relationelle schemas faste struktur fungerer som en implicit validering. Data, der ikke passer til tabellens datatype og constraints, afvises automatisk af databasen.

Årtiers erfaring med hærdning: Der eksisterer velafprøvede guides, CIS Benchmarks, og best practices til hærdning af alle større SQL-platforme.

Kendte svagheder i SQL-miljøer

• SQL Injection (SQLi): Den klassiske og stadig hyppigt forekommende angrebsvektor, hvor ondsindet SQL-kode injiceres via brugerinput.
• Overprivilegierede konti: Applikationer der kører som root eller db_admin giver angribere fuld adgang ved kompromittering.
• Eksponerede porte: MySQL (3306) og MSSQL (1433) der vender mod internettet er hyppige mål for automatiserede angrebsscannere.

3. NoSQL’s særlige sikkerhedsudfordringer

NoSQL-databaser introducerer en anderledes sikkerhedsprofil – delvist som følge af deres arkitektur, og delvist som følge af den historiske udviklingskontekst, de opstod i.

3.1 Designet til intern brug – ikke til eksponering

Mange af de tidlige NoSQL-databaser (herunder tidlige versioner af MongoDB og Redis) blev skabt med en implicit antagelse om, at de kun kørte i beskyttede interne netværk. Autentificering var i mange tilfælde slået fra som standard.

Da udviklere begyndte at sætte disse databaser op i cloud-miljøer uden bagvedliggende firewalls, opstod en epidemi af åbent eksponerede databaser. Et berømt eksempel er “Shodan-epidemien” fra 2017, hvor sikkerhedsforskere ved hjælp af søgemaskinen Shodan.io identificerede over 200.000 åbent tilgængelige MongoDB-instanser på det åbne internet – mange uden adgangskode.

3.2 Manglende standardisering på tværs af platforme

SQL har én veldefineret standard (ANSI SQL), hvilket muliggør konsistent sikkerhedsdokumentation og tooling. NoSQL-verdenen er fragmenteret: hver platform har sin egen autentificeringsmekanisme, sit eget rettighedssystem og sin egen konfigurationssyntaks.

• MongoDB bruger SCRAM-autentificering og rollebaseret adgangskontrol (RBAC).
• Redis brugte historisk et simpelt passwordsystem (AUTH), men understøtter fra version 6 ACL-baseret adgangskontrol.
• Cassandra bruger username/password-kombinationer med konfigurerbar CQL-baseret autorisation.
• Neo4j bruger native brugerstyring med roles og privileges.

Denne heterogenitet øger risikoen for fejlkonfigurationer, særligt når teams skifter mellem platforme.

3.3 Fleksible skemaer som dobbeltægs sværd

Det fleksible skema i dokumentdatabaser som MongoDB er en af de primære tiltrækningskræfter for udviklere. Men fra et sikkerhedsperspektiv er fraværet af strenge datatyper og constraints potentielt farligt:

• Manglende implicit validering: Felter kan indeholde uventede datatyper (f.eks. et array i stedet for en streng), hvilket kan udnyttes til type-forvirring i applikationslaget.
• Inkonsistente data på tværs af dokumenter: Ældre dokumenter i en samling kan have en anden struktur end nyere, hvilket gør det sværere at skrive robuste queries og validere output.

3.4 Eventual Consistency og sikkerhedsimplikationer

I distribuerede NoSQL-systemer er data ofte replikeret på tværs af noder, men konsistensen er eventuel snarere end øjeblikkelig. Dette kan have sikkerhedsmæssige konsekvenser:

• Race conditions: Et rettighedstjek der foretages på én node, kan baseres på forældet data fra en anden.
• Inkonsistente adgangskontrolopsætninger: Opsætning af rettigheder på tværs af et cluster er mere kompleks og fejlbehæftet.
• Transaktionsintegritet: Selvom nyere NoSQL-systemer understøtter multi-dokument transaktioner (MongoDB fra v4.0), er de stadig ikke universelt tilgængelige eller aktive som standard.

4. NoSQL Injection: Den nye angrebsvektor

Ligesom SQL-databaser er sårbare overfor SQL Injection, er NoSQL-databaser sårbare overfor NoSQL Injection – en angrebsvektor der er mindre velkendt, men mindst lige så farlig.

Angrebet: Operator-injektion i MongoDB

MongoDB accepterer forespørgsler som JSON-objekter. Mange webapplikationer konstruerer disse forespørgsler ved at indsætte brugerinput direkte i JSON-strukturen. Overvej dette usikre Node.js-eksempel til et login-endpoint:

// USIKKERT – direkte indsættelse af brugerinput
const user = await db.collection('users').findOne({
    username: req.body.username,
    password: req.body.password
});

En angriber kan i stedet for et normalt password sende følgende JSON-payload:

{
    "username": "admin",
    "password": { "$ne": null }
}

MongoDB-operatoren $ne betyder “not equal”. Forespørgslen oversættes til: “Find en bruger der hedder ‘admin’, og hvis password ikke er null” – dvs. en bruger der overhovedet har et password. Da de fleste brugere har et password, returneres admin-kontoen, og angriberen logges ind uden at kende adgangskoden.

Andre farlige operatorer, der kan misbruges på lignende måde, inkluderer $gt (greater than), $lt (less than), $regex og $where.

JavaScript-injektion via $where

$where-operatoren i MongoDB lader udviklere skrive JavaScript-udtryk som filterbetingelse. Dette er ekstremt farligt:

// FARLIG forespørgsel – aldrig brug $where med brugerinput
db.collection('users').find({ $where: `this.username == '${userInput}'` });

En angriber kan injicere ' || sleep(5000) || ' og dermed forårsage serverside JavaScript-eksekvering, Denial of Service eller informationseksfiltrering via tidsbaserede angreb – nøjagtigt som Time-Based Blind SQL Injection i SQL-verdenen.

HTTP Parameter Pollution i REST-API’er

Mange webapplikationer eksponerer NoSQL-databaser via REST API’er. Her kan angribere udnytte, at visse frameworks fortolker gentagne query-parametre som arrays:

GET /api/users?username=admin&password[$ne]=x

Afhængigt af backend-frameworket kan dette resultere i MongoDB-forespørgslen {username: "admin", password: {$ne: "x"}} – endnu en operator-injektion via URL.

5. Systematisk sammenligning: SQL vs. NoSQL sikkerhed

6. Best Practices: Sådan sikrer du NoSQL-databaser

De gode nyheder er, at de fleste NoSQL-sikkerhedsudfordringer kan håndteres effektivt med kendte sikkerhedsprincipper, tilpasset den specifikke platforms egenskaber.

6.1 Aktiver altid autentificering fra dag ét

Aldrig deploy en NoSQL-instans uden autentificering, selvom det “kun er til test”. Brug stærke, unikke adgangskoder og – for MongoDB, Redis 6+ og Cassandra – de fulde RBAC/ACL-mekanismer til at tildele mindste-rettigheder.

# MongoDB: Opret dedikeret applikationsbruger med minimale rettigheder
use myAppDatabase
db.createUser({
    user: "appUser",
    pwd: passwordPrompt(),
    roles: [{ role: "readWrite", db: "myAppDatabase" }]
})

6.2 Valider og sanitér input – og undgå operator-injektion

Den primære forsvar mod NoSQL Injection er at aldrig direkte indsætte uvalideret brugerinput i databaseforespørgsler. Brug et ODM (Object Document Mapper) som Mongoose til MongoDB, der tvinger et skema og håndterer typecasting automatisk:

// Mongoose validerer automatisk datatyper – et array her ville forårsage en fejl
const userSchema = new mongoose.Schema({
    username: { type: String, required: true },
    password: { type: String, required: true }
});

Validér eksplicit, at felter som username og password er strenge, ikke objekter:

// Eksplicit typetjek før databaseopslag
if (typeof req.body.username !== 'string' || typeof req.body.password !== 'string') {
    return res.status(400).json({ error: 'Ugyldigt input' });
}

6.3 Deaktiver farlige operatorer og funktioner

Deaktiver $where-operatoren i MongoDB og andre JavaScript-eksekveringsfaciliteter, medmindre de er absolutt nødvendige. I mongod.conf:

security:
    javascriptEnabled: false

6.4 Netværkssegmentering og firewall-regler

NoSQL-databaser bør aldrig eksponeres direkte mod internettet. Placer dem i et privat netværkssegment, og begræns adgang via firewall-regler til kun de servere/services, der har behov:

# Eksempel: iptables-regel der kun tillader MongoDB-adgang fra applikationsserveren
iptables -A INPUT -p tcp --dport 27017 -s 10.0.1.5 -j ACCEPT
iptables -A INPUT -p tcp --dport 27017 -j DROP

Cloud-baserede deployments bør konfigurere Security Groups eller VPC-regler tilsvarende.

6.5 Kryptering af data – at rest og in-transit

• At rest: Brug disk-niveau kryptering (LUKS på Linux, BitLocker på Windows) eller platforms-native kryptering.
• In-transit: Sørg for TLS er aktivt og konfigureret med gyldige certifikater. For MongoDB, konfigurér net.tls.mode: requireTLS i mongod.conf.
• Felt-niveau kryptering: MongoDB Enterprise og Atlas understøtter Client-Side Field Level Encryption (CSFLE), der krypterer følsomme felter i applikationslaget, så selv databaseadministratorer ikke kan se klartekstdata.

6.6 Logning, monitorering og anomalidetektion

Aktiver native audit-logs og integrer dem i dit SIEM-system (Splunk, Elastic Stack, etc.). Opsæt alarmer for:

• Uventede administrative operationer (dropDatabase, createUser)
• Bulkeksport af store datamængder
• Login-forsøg fra ukendte IP-adresser
• Forespørgsler der bruger uventede operatorer ($where, $regex på følsomme felter)

7. Virkelige hændelser: Når NoSQL-sikkerhed fejler

MongoDB Ransomware-bølgen (2017)

Sikkerhedsforskere identificerede i januar 2017 en systematisk kampagne, hvor angribere scannede internettet for usikrede MongoDB-instanser (typisk med Shodan), slettede hele databaser og efterlod et løsesumskrav. Angrebet ramte mere end 27.000 instanser inden for blot få dage. Årsagen var næsten altid den samme: MongoDB deployed med standardkonfiguration og ingen autentificering, direkte eksponeret mod internettet.

Redis Kodeeksekvering via uautoriseret adgang

Redis er designet som en in-memory cache og har historisk haft minimal autentificering. Forskere demonstrerede, at en angriber med netværksadgang til en eksponeret Redis-instans kan bruge CONFIG SET dir og CONFIG SET dbfilename til at skrive filer til serveren – herunder SSH-autoriserede nøgler eller cron-jobs – og dermed opnå fuld serveradgang. Denne angrebsteknik er dokumenteret i adskillige CVE’er og kendte exploit-kits.

8. Konklusion

NoSQL-databaser er kraftfulde, skalerbare og essentielle i moderne systemarkitekturer – men de medfører en sikkerhedsprofil, der adskiller sig markant fra traditionelle SQL-databaser. Den fragmenterede standardisering, historisk svage standardkonfigurationer og nye angrebsvektorer som operator-injektion kræver, at sikkerhedsprofessionelle og udviklere aktivt forholder sig til de specifikke risici.

Den gode nyhed er, at de grundlæggende principper er de samme: aktivér autentificering, brug mindste-rettighedsprincippet, valider al input, kryptér data, netværkssegmentér og monitorér. Udfordringen ligger i at tilpasse disse principper til den konkrete NoSQL-platform og i at have den nødvendige bevidsthed om, at NoSQL ikke automatisk er et sikrere alternativ til SQL – det er blot anderledes, og kræver sin egen viden og hærdning.

Kilder

• OWASP: Testing for NoSQL Injection - OWASPs officielle testguide til NoSQL Injection i web security testing.
• OWASP: NoSQL Injection Cheat Sheet - Praktisk guide til forebyggelse af injektionsangreb, herunder NoSQL-varianter.
• MongoDB Security Checklist - Officiel MongoDB-dokumentation med komplet sikkerhedstjekliste til produktionsdeployments.
• CIS Benchmark for MongoDB - Center for Internet Security’s hærdningsguide til MongoDB med konkrete konfigurationsanbefalinger.
• Redis Security Documentation - Redis’ officielle dokumentation om autentificering, ACL og netværkssikkerhed.
• NIST SP 800-209: Security Guidelines for Storage Infrastructure - NIST-rammeværk der dækker sikring af datasystemer, herunder databaseinfrastruktur.
• CVE-2022-0543: Redis Sandbox Escape - Konkret eksempel på kritisk Redis-sårbarhed med fjernkodeeksekvering via Lua-sandkasse.
• Shodan Research: Open MongoDB Instances (2017) - Søgeplatform der dokumenterede omfanget af åbent eksponerede NoSQL-databaser.