Database Beveiliging: SQL Security en Access Control

Uitgebreide beveiligingsmaatregelen voor databases

Een robuuste databasebeveiligingsstrategie begint bij sterke en centraal beheerde authenticatie. Voor overheidsorganisaties betekent dit dat databases zo veel mogelijk worden gekoppeld aan Entra ID, zodat afzonderlijke SQL‑accounts met losse wachtwoorden worden vervangen door centrale identiteiten en beheerde groepen. Databasebeheerders en andere hoogbevoegde gebruikers maken standaard gebruik van phishing‑resistente multi‑factor authenticatie, bijvoorbeeld met FIDO2‑sleutels of Windows Hello for Business. Serviceaccounts voor applicaties worden waar mogelijk ingericht als managed identities, zodat er geen vaste inloggegevens meer in configuratiebestanden of code worden opgeslagen. Voor verbindingen tussen applicaties en databases wordt bij voorkeur certificaat‑gebaseerde authenticatie ingezet, waarmee zowel de server als de client betrouwbaar kan worden gevalideerd.

Na betrouwbare authenticatie volgt fijnmazige autorisatie volgens het least‑privilege‑principe. Toegang wordt vormgegeven met role‑based access control: gebruikers en applicaties krijgen uitsluitend de rechten die noodzakelijk zijn voor hun taak. In SQL Server en Azure SQL wordt gewerkt met standaardrollen zoals db_datareader voor uitsluitend lezen, db_datawriter voor schrijfbevoegdheden en db_ddladmin voor schema‑wijzigingen, aangevuld met maatwerkrollen voor specifieke applicaties of processen. Row‑level security zorgt ervoor dat gebruikers alleen de rijen zien die voor hun organisatieonderdeel of case relevant zijn, terwijl column‑level permissions of view‑gebaseerde toegang gebruikt worden om gevoelige velden, zoals burgerservicenummers of medische gegevens, af te schermen. Zo kan één centrale database meerdere organisatieonderdelen bedienen, zonder dat er onnodige inzage in elkaars data ontstaat.

Bescherming tegen SQL‑injectie is een essentieel onderdeel van databasebeveiliging, zeker in omgevingen waar webapplicaties of API’s direct of indirect queries uitvoeren. Ontwikkelteams gebruiken consequent geparametriseerde queries en prepared statements, zodat gebruikersinvoer nooit direct als onderdeel van een SQL‑statement wordt samengevoegd. In plaats van dynamische query‑strings te bouwen, worden parameters apart doorgegeven en door de database‑engine veilig verwerkt. Aan de applicatiekant wordt invoer gevalideerd op formaat, lengte en toegestane tekens, en worden gevaarlijke patronen geblokkeerd. Waar mogelijk wordt data‑toegang gecapsuleerd in stored procedures of in een ORM‑laag, waardoor directe ad‑hoc queries tot een minimum worden beperkt en het aanvalsoppervlak kleiner wordt.

Versleuteling vormt de tweede verdedigingslinie tegen datalekken. Transparent Data Encryption (TDE) wordt ingezet om databasebestanden en back‑ups automatisch op schijf te versleutelen, zodat bij diefstal van servers, schijven of back‑upmedia geen bruikbare gegevens beschikbaar komen. Voor bijzonder gevoelige kolommen, zoals BSN, financiële gegevens of classificaties, kan Always Encrypted worden toegepast. Hierbij blijven de encryptiesleutels aan de clientzijde en ziet de database alleen versleutelde waarden, wat het risico bij een compromis van de database‑server aanzienlijk verkleint. Alle communicatie tussen applicaties, beheertools en databases verloopt via TLS met actuele protocollen en sterke cipher suites, zodat afluisteren op het netwerk geen inzicht in data oplevert. Voor enkele zeer gevoelige attributen kan aanvullend veldniveau‑encryptie in de applicatielaag worden toegepast.

Continu inzicht in wat er in de database gebeurt, is cruciaal om misbruik en aanvallen tijdig te detecteren. Database Activity Monitoring legt query‑patronen vast, bouwt een normbeeld op van regulier gebruik en signaleert afwijkingen, zoals massale exports buiten kantooruren of ongebruikelijke queries door een beheeraccount. Toegang tot gevoelige tabellen met persoonsgegevens wordt expliciet gelogd, zodat kan worden aangetoond wie welke gegevens wanneer heeft ingezien. Wijzigingen in rechten en rollen, pogingen tot privilege‑escalatie en mislukte inlogpogingen worden centraal geregistreerd en doorgestuurd naar een SIEM‑platform, waar correlatie met andere beveiligingssignalen plaatsvindt. Zo kunnen verdachte handelingen in de datalaag worden gekoppeld aan gebeurtenissen op werkplekken, applicaties of netwerkcomponenten.

Omdat veel organisaties slechts beperkt zicht hebben op welke gevoelige gegevens precies in welke databases staan, is geautomatiseerde data discovery en classificatie noodzakelijk. Met hulpmiddelen voor Data Discovery & Classification worden tabellen en kolommen gescand op patronen zoals burgerservicenummers, IBAN‑nummers of andere persoonsgegevens. De gevonden data‑elementen worden voorzien van gevoeligheidslabels, bijvoorbeeld ‘vertrouwelijk’ of ‘zeer vertrouwelijk’, die gebruikt worden om aanvullende maatregelen af te dwingen. Denk aan strengere toegangscontroles, verplichte encryptie of aangescherpte logging voor specifieke tabellen. Op die manier sluit de technische inrichting van de database beter aan bij de informatieclassificatie uit het bedrijfsbeleid.

Een vaak onderschat risico is het gebruik van productiedata in ontwikkel‑ en testomgevingen. Om realistische testscenario’s mogelijk te maken zonder echte persoonsgegevens te verspreiden, wordt Dynamic Data Masking of een vergelijkbare vorm van datamasking toegepast. Hierbij worden gevoelige waarden in kopieën van de database onomkeerbaar vermomd, terwijl de statistische eigenschappen van de data behouden blijven. Ontwikkelaars en testers werken zo met representatieve gegevens, maar zien geen herleidbare informatie over echte burgers of medewerkers. Dit verkleint het risico op datalekken via minder goed beveiligde testomgevingen aanzienlijk.

Tot slot moeten back‑ups en de onderliggende infrastructuur even zorgvuldig worden beveiligd als de productieomgeving. Back‑upbestanden worden standaard versleuteld en opgeslagen op locaties met strikte toegangscontrole, waarbij alleen een kleine groep beheerders toegang heeft tot de sleutelmaterialen en de back‑upopslag. Er wordt gewerkt met gescheiden beheeraccounts voor productie‑ en back‑uptaken, zodat een compromis van een productieserver niet automatisch toegang geeft tot alle historische data. Back‑ups worden bovendien regelmatig getest door herstelacties uit te voeren in een geïsoleerde omgeving, zodat de organisatie zeker weet dat databases binnen de afgesproken termijnen volledig en betrouwbaar kunnen worden teruggezet. Netwerkmaatregelen, zoals firewalls, netwerksegmentatie en private endpoints voor cloud‑databases, beperken de toegang tot uitsluitend applicaties en beheersystemen die deze echt nodig hebben en sluiten rechtstreekse internettoegang uit.