Azure SQL Database: Vulnerability Assessment Inschakelen Voor Security Scanning

Databasemisconfiguraties blijven vaak jarenlang onopgemerkt omdat er geen systematische beveiligingsscanning plaatsvindt, wat aanzienlijke beveiligingsrisico's creëert. Veelvoorkomende problemen die zonder geautomatiseerde scanning onontdekt blijven zijn excessief permissieve gebruikersrechten waarbij normale gebruikers sysadmin of db_owner privileges hebben, zwakke wachtwoordbeleid waarbij wachtwoorden nooit verlopen of geen complexiteitseisen hebben, ontbrekende versleuteling waarbij Transparent Data Encryption (TDE) niet is ingeschakeld op databases met gevoelige data, publieke eindpunten die onnodig ingeschakeld blijven waardoor databases vanaf internet bereikbaar zijn, verouderde databasecompatibiliteitsniveaus die bekende beveiligingskwetsbaarheden bevatten, en onveilige opgeslagen procedures die kwetsbaar zijn voor SQL-injectie door dynamische SQL zonder parameter validatie. Deze misconfiguraties vormen een cumulatief beveiligingsrisico dat het aanvalsoppervlak vergroot en complianceschendingen oplevert. Vulnerability Assessment scant meer dan 100 beveiligingscontroles die deze problemen identificeren: gebruikersmachtigingen worden geanalyseerd op excessieve toekenningen zoals onnodige sysadmin-rechten, wachtwoordbeleid wordt gecontroleerd op verloopinstellingen en complexiteitsvereisten, versleutelingsstatus wordt geverifieerd om databases zonder TDE te identificeren, netwerkblootstelling wordt geaudit door publieke toegangsconfiguraties te controleren, gegevensclassificatie wordt geëvalueerd om gevoelige gegevens zonder juiste tagging te vinden, en SQL-injectiekwetsbaarheden in opgeslagen procedures worden gedetecteerd via codeanalyse. Deze uitgebreide scanning is essentieel voor compliance met PCI-DSS v4.0 Requirement 11.2 dat kwartaalgewijze kwetsbaarheidsscans vereist, ISO 27001 controle A.12.6.1 voor beheer van technische kwetsbaarheden, en NIS2 Artikel 21 voor kwetsbaarheidsbeheer-verplichtingen.

Implementatie

Deze maatregel implementeert SQL Vulnerability Assessment die automatisch werkt als onderdeel van Microsoft Defender for SQL (zie defender-for-sql-enabled.json voor activering). Vulnerability Assessment voert wekelijks automatische beveiligingsscans uit zonder handmatige interventie, waarbij meer dan 100 verschillende beveiligingscontroles worden uitgevoerd per database. Elke scan genereert een gedetailleerd rapport met ernstclassificaties (Hoog/Medium/Laag) voor elke bevinding, waarbij hoog-ernstige problemen zoals publieke internettoegang of ontbrekende versleuteling prioriteit krijgen. Baselinevergelijking functionaliteit maakt het mogelijk om een goedgekeurde beveiligingsbaseline in te stellen en vervolgens trends te volgen om te zien of de beveiligingspostuur verbetert of verslechtert over tijd. Voor elk geïdentificeerd probleem worden concrete herstelscripts in T-SQL meegeleverd die direct kunnen worden uitgevoerd om de kwetsbaarheid te verhelpen, wat aanzienlijk sneller is dan handmatig herstelprocedures ontwikkelen. Compliancerapportage wordt automatisch gegenereerd die kan worden gebruikt voor audits. Scanresultaten worden opgeslagen in een Azure Storage Account voor historische tracking en trendanalyse. Het dashboard in Defender for Cloud toont huidige kwetsbaarheden met hun ernst, trends over tijd om te zien of herstelinspanningen effectief zijn, top risico's die onmiddellijke aandacht vereisen, en herstelvoortgang om bij te houden hoeveel bevindingen zijn opgelost. De kosten zijn volledig inclusief in Defender for SQL pricing (ongeveer 5% van database compute costs) zonder extra kosten. Wekelijkse geautomatiseerde scans zorgen voor continue zichtbaarheid in de beveiligingspostuur, en kwartaalgewijze reviews met DBA-teams zorgen voor systematische remediëring van bevindingen. Deze scanning is een must-have voor alle productiedatabases en verplicht voor PCI-DSS compliance.

Vereisten

Voor de implementatie van SQL Vulnerability Assessment op Azure SQL Databases zijn verschillende technische en organisatorische vereisten van toepassing. Deze vereisten zorgen ervoor dat de kwetsbaarheidsscanning succesvol kan worden geïmplementeerd en beheerd, en dat organisaties kunnen voldoen aan hun beveiligings- en compliance-verplichtingen. Het begrijpen van deze vereisten is essentieel voordat met de implementatie wordt begonnen, omdat ontbrekende vereisten kunnen leiden tot vertragingen of implementatieproblemen. De primaire technische vereiste is dat Microsoft Defender voor SQL moet zijn ingeschakeld op abonnementsniveau. Vulnerability Assessment is geen standalone service maar werkt automatisch als onderdeel van Microsoft Defender for SQL. Dit betekent dat organisaties eerst Defender for SQL moeten activeren voordat Vulnerability Assessment kan worden gebruikt. Defender for SQL biedt naast Vulnerability Assessment ook andere beveiligingsfuncties zoals Advanced Threat Protection, SQL Database Auditing en Security Recommendations. De activering van Defender for SQL gebeurt via de Azure Portal onder Microsoft Defender for Cloud, waar de SQL-servers kunnen worden geselecteerd voor bescherming. De kosten voor Defender for SQL bedragen ongeveer 5% van de database compute costs, wat betekent dat een database van €300 per maand ongeveer €15 per maand kost voor Defender for SQL inclusief Vulnerability Assessment. Een tweede kritieke vereiste is de aanwezigheid van een Azure Storage Account voor het opslaan van scanresultaten. Vulnerability Assessment vereist een Storage Account omdat de Azure Portal UI de scanresultaten niet kan tonen zonder deze opslag. Het Storage Account moet zich in dezelfde Azure-regio bevinden als de SQL-servers om lage latency te garanderen en om te voldoen aan data residency-vereisten. Het Storage Account kan een Standard tier zijn met LRS (Locally Redundant Storage) redundantie, omdat scanresultaten niet mission-critical zijn en geen hoge beschikbaarheid vereisen. Binnen het Storage Account moet een container worden aangemaakt specifiek voor Vulnerability Assessment resultaten, typisch genaamd 'vulnerability-assessment'. De toegangscontrole moet worden geconfigureerd zodat alleen het beveiligingsteam de resultaten kan lezen, via RBAC-rollen zoals 'Storage Blob Data Reader'. SQL Auditing moet zijn ingeschakeld op de SQL-servers om volledige zichtbaarheid te krijgen in database-activiteiten en om compliance-vereisten te vervullen. Vulnerability Assessment werkt wel zonder SQL Auditing, maar voor een complete beveiligingspostuur is auditing essentieel. SQL Auditing logt alle database-activiteiten inclusief queries, login-pogingen en wijzigingen aan database-objecten, wat waardevol is voor forensische analyse na beveiligingsincidenten. De auditlogs worden opgeslagen in een Azure Storage Account of Log Analytics Workspace, afhankelijk van de configuratie. Voor organisaties met compliance-vereisten zoals PCI-DSS of ISO 27001 is SQL Auditing vaak verplicht naast Vulnerability Assessment. E-mailconfiguratie voor scanrapportage is essentieel om beveiligingsteams en databasebeheerders op de hoogte te houden van nieuwe kwetsbaarheden. Vulnerability Assessment kan worden geconfigureerd om automatisch e-mailnotificaties te versturen naar opgegeven e-mailadressen wanneer een scan is voltooid of wanneer nieuwe hoog-ernstige bevindingen worden gedetecteerd. Deze e-mailnotificaties bevatten een samenvatting van de scanresultaten, een lijst van nieuwe bevindingen sinds de vorige scan, en directe links naar het volledige rapport in de Azure Portal. Organisaties moeten een lijst van e-mailadressen opstellen van personen die betrokken zijn bij databasebeveiliging, zoals beveiligingsteams, databasebeheerders en compliance-officers. Het is aanbevolen om een gedeeld e-mailadres te gebruiken voor het beveiligingsteam in plaats van individuele adressen, om ervoor te zorgen dat notificaties niet worden gemist wanneer teamleden met verlof zijn. Databasebeheerders (DBA's) moeten toegang hebben tot de SQL-servers en databases om remediëring uit te voeren voor geïdentificeerde kwetsbaarheden. Vulnerability Assessment genereert T-SQL-scripts voor elke bevinding die direct kunnen worden uitgevoerd om de kwetsbaarheid te verhelpen, maar deze scripts moeten worden uitgevoerd door personen met de juiste database-machtigingen. DBA's moeten minimaal db_owner-rechten hebben op de databases waar remediëring moet plaatsvinden, of sysadmin-rechten op de SQL-server voor server-level configuratiewijzigingen. Het is belangrijk om het principe van least privilege toe te passen en alleen de minimaal benodigde rechten te verlenen. Voor productieomgevingen moeten alle remediëringsacties worden uitgevoerd via een change management-proces waarbij wijzigingen eerst worden getest in een testomgeving voordat ze worden toegepast op productie.

Implementatie

⚠️ **BELANGRIJKE OPMERKING**: Vulnerability Assessment is NIET standalone maar automatisch inbegrepen bij Microsoft Defender for SQL. Volg eerst defender-for-sql-enabled.json om Defender te activeren op abonnementsniveau. Het implementeren van SQL Vulnerability Assessment voor Azure SQL Databases vereist een gestructureerde aanpak die begint met de configuratie van een Azure Storage Account voor het opslaan van scanresultaten, gevolgd door de configuratie van Vulnerability Assessment op SQL-serverniveau, het uitvoeren van de eerste scan en het reviewen van resultaten, en eindigt met het opzetten van een continu verbeteringsproces voor remediëring. Het is belangrijk om te begrijpen dat Vulnerability Assessment server-level is en niet per database wordt geconfigureerd, wat betekent dat alle databases op een SQL-server automatisch worden gescand wanneer Vulnerability Assessment is ingeschakeld. De implementatie kan worden uitgevoerd zonder downtime, waardoor organisaties Vulnerability Assessment kunnen implementeren in productieomgevingen zonder service-onderbrekingen. **FASE 1: Azure Storage Account Configureren voor Vulnerability Assessment Resultaten (Duur: 15 minuten)** De eerste fase van de implementatie richt zich op het opzetten van een Azure Storage Account dat wordt gebruikt voor het opslaan van Vulnerability Assessment scanresultaten. Vulnerability Assessment vereist een Storage Account omdat de Azure Portal UI de scanresultaten niet kan tonen zonder deze opslag. Deze vereiste is technisch van aard en kan niet worden omzeild. Organisaties moeten een dedicated Storage Account aanmaken specifiek voor Vulnerability Assessment resultaten, of een bestaand Storage Account gebruiken als dit al beschikbaar is. Het aanmaken van een nieuw Storage Account gebeurt via de Azure Portal onder Storage Accounts, waar de optie 'Create' wordt geselecteerd. Bij het configureren van het Storage Account moet een duidelijke naam worden gekozen die het doel aangeeft, zoals 'stvasqlresultsprod' voor productieomgevingen. De regio moet dezelfde zijn als waar de SQL-servers zich bevinden om lage latency te garanderen en om te voldoen aan data residency-vereisten die kunnen gelden voor gevoelige gegevens. De performance tier kan Standard zijn omdat scanresultaten niet mission-critical zijn en geen hoge I/O-prestaties vereisen. De redundantieoptie kan LRS (Locally Redundant Storage) zijn, wat voldoende is voor scanresultaten die niet kritiek zijn voor bedrijfscontinuïteit. Binnen het Storage Account moet een container worden aangemaakt specifiek voor Vulnerability Assessment resultaten, typisch genaamd 'vulnerability-assessment'. De publieke toegang moet worden ingesteld op Private (blob) om te voorkomen dat scanresultaten publiek toegankelijk zijn. De toegangscontrole moet worden geconfigureerd zodat alleen het beveiligingsteam de resultaten kan lezen, via RBAC-rollen zoals 'Storage Blob Data Reader' die wordt toegewezen aan beveiligingsteamleden. Voor governance-doeleinden moet het Storage Account worden getagd met labels zoals Purpose=SQLVulnerabilityAssessment en DataClassification=Internal om duidelijk te maken wat het doel is van het Storage Account. **FASE 2: Vulnerability Assessment Configureren op SQL Server (Duur: 15 minuten)** De tweede fase van de implementatie omvat het daadwerkelijk configureren van Vulnerability Assessment op SQL-serverniveau. Het is belangrijk om te benadrukken dat Vulnerability Assessment server-level is en niet per database wordt geconfigureerd, wat betekent dat alle databases op een SQL-server automatisch worden gescand wanneer Vulnerability Assessment is ingeschakeld. De configuratie gebeurt via de Azure Portal door te navigeren naar de SQL Server (niet de individuele database), vervolgens Security te selecteren in het navigatiemenu, en dan Microsoft Defender for Cloud. Onder de sectie 'Vulnerability Assessment settings' moet de optie 'Configure' worden geselecteerd. Als deze optie grijs is, betekent dit dat Microsoft Defender for SQL niet is ingeschakeld en moet eerst worden geactiveerd voordat Vulnerability Assessment kan worden geconfigureerd. Bij het configureren van de Storage Account-instellingen moet het abonnement worden geselecteerd waarin het Storage Account zich bevindt, het Storage Account uit Fase 1 moet worden geselecteerd, en het containerpad moet worden ingesteld op 'vulnerability-assessment' (dit wordt meestal automatisch ingevuld). Voor periodieke terugkerende scans moet de optie 'Enable' worden ingesteld op 'ON', wat wordt aanbevolen omdat dit wekelijkse automatische scans mogelijk maakt zonder handmatige interventie. De scantrigger kan worden ingesteld op wekelijks op zondag 00:00 UTC (standaard), maar kan worden gewijzigd naar een andere dag of tijd indien gewenst. Voor e-mailnotificatie-instellingen moet onder 'Send scan reports to' de e-mailadressen worden toegevoegd van het beveiligingsteam en databasebeheerders, zoals security-team@company.com en dba-team@company.com. De optie 'Also send email notification to admins and subscription owners' kan worden ingeschakeld indien gewenst om ervoor te zorgen dat abonnementsbeheerders ook op de hoogte worden gehouden. Na het opslaan van de configuratie is Vulnerability Assessment nu geconfigureerd en start de eerste scan op het volgende geplande tijdstip, of kan on-demand worden getriggerd via de 'Scan' knop. **FASE 3: Eerste Vulnerability Scan Uitvoeren en Resultaten Reviewen (Duur: 1-2 uur)** De derde fase van de implementatie bestaat uit het uitvoeren van de eerste Vulnerability Assessment scan en het reviewen van de resultaten. Deze fase is cruciaal omdat het de eerste inzicht geeft in de beveiligingspostuur van de databases en helpt bij het identificeren van kwetsbaarheden die onmiddellijke aandacht vereisen. De eerste scan kan on-demand worden getriggerd via de Azure Portal door te navigeren naar SQL Server → Microsoft Defender for Cloud → Vulnerability Assessment en vervolgens op de 'Scan' knop te klikken. De scan duurt 10-30 minuten afhankelijk van de databasegrootte en het aantal databases op de server. Tijdens de scan worden meer dan 100 verschillende beveiligingscontroles uitgevoerd per database, waarbij wordt gecontroleerd op problemen zoals excessieve gebruikersmachtigingen, zwakke wachtwoordbeleid, ontbrekende versleuteling, publieke eindpunten, firewallregels en compliance-hiaten. Na voltooiing van de scan kunnen de resultaten worden bekeken door te klikken op 'View scan results'. De resultaten tonen meer dan 100 beveiligingscontroles verdeeld over verschillende categorieën: Machtigingen (excessieve toekenningen, verweesde gebruikers), Authenticatie (zwakke wachtwoorden, SQL-authenticatie versus Azure AD), Versleuteling (TDE-status, SSL-afdwinging), Configuratie (publieke eindpunten, firewallregels), en Compliance (PCI-DSS, ISO 27001 mappings). Het is essentieel om hoog-ernstige bevindingen eerst te prioriteren, omdat deze de grootste beveiligingsrisico's vormen. Vulnerability Assessment markeert kritieke problemen zoals TDE uitgeschakeld (onmiddellijke remediëring vereist), publiek eindpunt zonder firewall (kritieke blootstelling), sysadmin toegekend aan niet-beheerders (privilege escalation risico), en SQL-authenticatie met zwakke wachtwoorden. Voor elke bevinding moet de gedetailleerde beschrijving worden gelezen om te begrijpen waarom dit een risico is, de getroffen database-objecten moeten worden gereviewd (welke gebruikers/tabellen/procedures), het meegeleverde herstel T-SQL-script moet worden gecontroleerd, en de bedrijfsimpact van de fix moet worden beoordeeld (zal remediëring iets breken?). Na review van de eerste scan moet een baseline worden ingesteld door te klikken op 'Set as baseline', wat de huidige staat de baseline maakt voor toekomstige vergelijkingen. Volgende scans tonen delta's (nieuwe kwetsbaarheden, opgeloste problemen) ten opzichte van deze baseline, wat helpt bij het volgen van verbeteringen in de beveiligingspostuur over tijd. **FASE 4: Kwetsbaarheidsremediëring en Continue Verbetering (Duur: 2-4 uur per scan, doorlopend)** De vierde fase van de implementatie omvat het opzetten van een continu verbeteringsproces voor remediëring van geïdentificeerde kwetsbaarheden. Deze fase is essentieel omdat het niet voldoende is om alleen kwetsbaarheden te identificeren - ze moeten ook worden opgelost om de beveiligingspostuur daadwerkelijk te verbeteren. Voor hoog-ernstige bevindingen moet remediëring onmiddellijk worden uitgevoerd (binnen 48 uur) omdat deze de grootste beveiligingsrisico's vormen. Vulnerability Assessment genereert T-SQL-scripts voor elke bevinding die direct kunnen worden uitgevoerd om de kwetsbaarheid te verhelpen. Het proces omvat het kopiëren van het script uit het Vulnerability Assessment resultaatpaneel, het reviewen van het script op correctheid (verifiëren dat er geen impact is op bedrijfslogica), het uitvoeren in SSMS of Azure Data Studio in een TEST-omgeving eerst, en het deployen naar productie na validatie. Voor medium-ernstige bevindingen moet remediëring worden gepland binnen 30 dagen, waarbij prioriteit wordt gegeven op basis van compliance-impact (PCI-DSS bevindingen eerst). Voor laag-ernstige bevindingen kunnen deze worden toegevoegd aan de technische schuld backlog voor uiteindelijke opruiming. Het volgen van remediëringsvoortgang is essentieel om te zien of de beveiligingspostuur verbetert. Het Vulnerability Assessment dashboard toont trends over tijd: totaal aantal kwetsbaarheden (moet afnemen), aantal hoog-ernstige kwetsbaarheden (doel: nul), en remediëringspercentage (percentage opgelost per week). Een wekelijkse scanreviewproces moet worden opgezet waarbij elke maandag de nieuwe scanresultaten worden gereviewd (via e-mailnotificatie), nieuwe kwetsbaarheden sinds de vorige scan worden geïdentificeerd (regressiedetectie), eerder gerepareerde problemen worden geverifieerd dat ze opgelost blijven, en het managementdashboard wordt bijgewerkt met beveiligingsmetrieken. Kwartaalgewijze managementrapportage moet worden gepresenteerd aan het management met beveiligingspostuurtrends: totaal aantal kwetsbaarheden trend (afnemend is goed), hoog-ernstige eliminatiesnelheid, compliance-scoreverbeteringen, en investering nodig voor complexe remediëringen.

⏱️ **Totale Implementatietijd**: 1-2 uur (Storage Account 15 min, VA config 15 min, eerste scan 30 min, results review 1 uur). Doorlopend: 4 uur/maand voor weekly reviews en remediation.

💰 **Kosten**: VA included in Defender for SQL (5 procent DB costs, bijvoorbeeld €15/maand voor €300/maand database). Storage voor results < €1/maand. Totaal: geen extra costs bovenop Defender.

Monitoring en Controle

Gebruik PowerShell-script sql-vulnerability-assessment-enabled.ps1 (functie Invoke-Monitoring) – Controleren.

Het continu monitoren van SQL Vulnerability Assessment compliance is essentieel voor het waarborgen van databasebeveiliging en het voldoen aan regelgevingsvereisten. Een proactieve monitoringstrategie voorkomt dat kwetsbaarheden onopgemerkt blijven en zorgt ervoor dat nieuwe databases automatisch worden gescand. Deze monitoringaanpak omvat meerdere lagen van controle, van geautomatiseerde e-mailnotificaties tot periodieke handmatige verificaties, en vormt de basis voor een robuuste beveiligingspostuur. Wekelijkse Vulnerability Assessment scanrapporten via e-mail vormen de eerste verdedigingslinie voor monitoring. Vulnerability Assessment is geconfigureerd om automatisch e-mailnotificaties te versturen naar opgegeven e-mailadressen wanneer een scan is voltooid of wanneer nieuwe hoog-ernstige bevindingen worden gedetecteerd. Deze e-mailnotificaties bevatten een samenvatting van de scanresultaten, een lijst van nieuwe bevindingen sinds de vorige scan, en directe links naar het volledige rapport in de Azure Portal. Organisaties moeten ervoor zorgen dat deze e-mailnotificaties worden ontvangen door alle relevante stakeholders, inclusief beveiligingsteams, databasebeheerders en compliance-officers. Het is aanbevolen om een gedeeld e-mailadres te gebruiken voor het beveiligingsteam in plaats van individuele adressen, om ervoor te zorgen dat notificaties niet worden gemist wanneer teamleden met verlof zijn. De e-mailnotificaties moeten regelmatig worden gereviewd om te identificeren welke kwetsbaarheden onmiddellijke aandacht vereisen en welke kunnen worden gepland voor toekomstige remediëring. Microsoft Defender voor Cloud biedt een centraal dashboard voor het monitoren van SQL-kwetsbaarheidsbevindingen. Dit dashboard toont alle huidige kwetsbaarheden met hun ernstclassificatie, trends over tijd om te zien of de beveiligingspostuur verbetert of verslechtert, top risico's die onmiddellijke aandacht vereisen, en remediëringsvoortgang om bij te houden hoeveel bevindingen zijn opgelost. Het dashboard kan worden geopend via Defender voor Cloud → SQL vulnerability findings, waar organisaties een overzicht krijgen van alle geïdentificeerde kwetsbaarheden gesorteerd op ernst. Het dashboard toont ook trends over tijd, wat helpt bij het identificeren van patronen en het meten van de effectiviteit van remediëringsinspanningen. Organisaties moeten dit dashboard regelmatig reviewen, bij voorkeur wekelijks, om ervoor te zorgen dat nieuwe kwetsbaarheden snel worden geïdentificeerd en aangepakt. Het volgen van remediëringsvoortgang is essentieel om te zien of de beveiligingspostuur daadwerkelijk verbetert. Organisaties moeten een proces opzetten waarbij hoog-ernstige bevindingen binnen 30 dagen worden opgelost, en medium-ernstige bevindingen binnen 90 dagen. Dit proces moet worden gedocumenteerd en gevolgd via het Vulnerability Assessment dashboard of een extern tracking-systeem zoals Azure DevOps of Jira. Het is belangrijk om niet alleen te focussen op het oplossen van nieuwe kwetsbaarheden, maar ook om te verifiëren dat eerder opgeloste problemen opgelost blijven. Regressiedetectie is cruciaal omdat configuratiewijzigingen of nieuwe deployments kunnen leiden tot het terugkeren van eerder opgeloste kwetsbaarheden. Het monitoren van trends is essentieel om te zien of het aantal kwetsbaarheden afneemt over tijd. Het Vulnerability Assessment dashboard toont trends over tijd voor verschillende metrieken, zoals totaal aantal kwetsbaarheden, aantal hoog-ernstige kwetsbaarheden, en remediëringspercentage. Organisaties moeten deze trends regelmatig reviewen om te identificeren of de beveiligingspostuur verbetert of verslechtert. Als het aantal kwetsbaarheden toeneemt, kan dit wijzen op problemen met het change management-proces of nieuwe deployments die niet voldoen aan beveiligingsstandaarden. Als het aantal kwetsbaarheden afneemt, is dit een positief teken dat remediëringsinspanningen effectief zijn. Deze trends moeten worden gepresenteerd aan het management tijdens kwartaalgewijze reviews om te demonstreren dat de beveiligingspostuur verbetert en om investering te rechtvaardigen voor complexe remediëringen. Kwartaalgewijze reviews met het DBA-team zijn essentieel voor het waarborgen van continue verbetering en het identificeren van systemische problemen. Tijdens deze reviews moeten alle scanresultaten worden besproken, nieuwe kwetsbaarheden worden geïdentificeerd, remediëringsvoortgang worden geëvalueerd, en actieplannen worden ontwikkeld voor toekomstige verbeteringen. Deze reviews moeten ook worden gebruikt om te identificeren of er systemische problemen zijn die leiden tot herhaalde kwetsbaarheden, zoals een gebrek aan change management-processen of onvoldoende training voor ontwikkelaars. De reviews moeten worden gedocumenteerd en de actie-items moeten worden gevolgd om ervoor te zorgen dat geïdentificeerde problemen worden opgelost.

Compliance en Auditing

SQL Vulnerability Assessment voor Azure SQL Database is een fundamentele vereiste voor naleving van vrijwel alle moderne cybersecurity- en privacyregelgeving. Deze kwetsbaarheidsscanning vormt de basis voor databasebeveiliging en is expliciet of impliciet vereist door internationale standaarden, Europese regelgeving en Nederlandse overheidsrichtlijnen. Organisaties die Azure SQL Databases gebruiken voor het verwerken van gevoelige gegevens, persoonsgegevens of financiële informatie, moeten Vulnerability Assessment implementeren om te voldoen aan hun compliance-verplichtingen. De CIS Azure Foundations Benchmark bevat verschillende controles die betrekking hebben op SQL-beveiliging en kwetsbaarheidsscanning. Hoewel er geen specifieke controle is die expliciet Vulnerability Assessment vereist, zijn er meerdere controles die betrekking hebben op SQL-beveiligingsconfiguraties die door Vulnerability Assessment worden gecontroleerd. Deze controles omvatten verificatie van versleuteling, firewallregels, authenticatie-instellingen en gebruikersmachtigingen. Organisaties die de CIS Benchmark volgen, moeten kunnen aantonen dat zij regelmatig kwetsbaarheidsscans uitvoeren op hun SQL-databases en dat geïdentificeerde kwetsbaarheden worden opgelost. De CIS Benchmark wordt wereldwijd erkend als een best practice framework voor cloudbeveiliging, en naleving van deze controles is vaak een vereiste voor cloud security certificeringen. ISO 27001:2022 controle A.12.6.1 verplicht organisaties om technische kwetsbaarheden te beheren door regelmatig te scannen op kwetsbaarheden en deze te verhelpen. Deze controle vereist dat organisaties een proces hebben voor het identificeren, evalueren en verhelpen van technische kwetsbaarheden in informatiesystemen. SQL Vulnerability Assessment is een directe implementatie van deze controle voor Azure SQL Databases, omdat het automatisch scans uitvoert op meer dan 100 verschillende beveiligingscontroles en concrete herstelrichtlijnen biedt voor geïdentificeerde kwetsbaarheden. Tijdens ISO 27001 certificering en surveillance audits moeten organisaties kunnen aantonen dat zij regelmatig kwetsbaarheidsscans uitvoeren op hun databases, dat geïdentificeerde kwetsbaarheden worden geëvalueerd en geprioriteerd, en dat hoog-ernstige kwetsbaarheden binnen redelijke termijnen worden verholpen. De audit zal verifiëren dat het kwetsbaarheidsbeheerproces is gedocumenteerd, dat scans regelmatig worden uitgevoerd (bij voorkeur wekelijks of maandelijks), en dat remediëringsvoortgang wordt gevolgd en gerapporteerd. De NIS2-richtlijn, die in Nederland is geïmplementeerd via de Wet cybersecurity, vereist in Artikel 21 dat essentiële en belangrijke entiteiten passende maatregelen nemen voor cybersecurity risicobeheer, waaronder kwetsbaarheidsbeheer. Organisaties die onder de NIS2-richtlijn vallen, zoals energiebedrijven, financiële instellingen, gezondheidszorgorganisaties en digitale dienstverleners, moeten kunnen aantonen dat zij adequate technische maatregelen hebben geïmplementeerd om kwetsbaarheden te identificeren en te verhelpen. SQL Vulnerability Assessment vormt een essentiële component van deze maatregelen voor alle databases die gevoelige operationele gegevens bevatten. De Autoriteit Persoonsgegevens en andere toezichthouders kunnen tijdens inspecties verifiëren dat kwetsbaarheidsscanning correct is geïmplementeerd, en niet-naleving kan leiden tot aanzienlijke boetes en reputatieschade. De Algemene Verordening Gegevensbescherming (AVG), ook bekend als GDPR, vereist in Artikel 32 dat organisaties passende technische en organisatorische maatregelen nemen om persoonsgegevens te beveiligen. Beveiligingsassessments, inclusief kwetsbaarheidsscanning, worden expliciet genoemd als voorbeelden van passende technische maatregelen. Voor Azure SQL Databases die persoonsgegevens bevatten, is Vulnerability Assessment daarom niet alleen een best practice, maar een wettelijke vereiste. Organisaties die persoonsgegevens verwerken zonder adequate beveiligingsassessments, schenden de AVG en kunnen worden geconfronteerd met boetes tot €20 miljoen of 4% van de wereldwijde jaaromzet, afhankelijk van wat hoger is. Bovendien kunnen betrokkenen schadevergoeding eisen bij datalekken waarbij onvoldoende beveiligingsmaatregelen hebben geleid tot compromittering van persoonsgegevens. Vulnerability Assessment-implementatie moet worden gedocumenteerd in het verwerkingsregister en kan worden gecontroleerd tijdens AVG-audits door de Autoriteit Persoonsgegevens. PCI-DSS v4.0 Requirement 11.2 verplicht organisaties die creditcardgegevens verwerken om kwartaalgewijze kwetsbaarheidsscans uit te voeren op alle systemen die cardholder data opslaan, verwerken of verzenden. Voor Azure SQL Databases die creditcardnummers, vervaldatums of andere cardholder data bevatten, is Vulnerability Assessment een absolute vereiste voor PCI-DSS compliance. Zonder regelmatige kwetsbaarheidsscanning kunnen organisaties hun PCI-DSS certificering verliezen, wat betekent dat zij geen creditcardtransacties meer kunnen verwerken. PCI-DSS audits verifiëren niet alleen dat kwetsbaarheidsscanning is ingeschakeld, maar ook dat scans regelmatig worden uitgevoerd (minimaal kwartaalgewijs, bij voorkeur wekelijks), dat geïdentificeerde kwetsbaarheden worden geëvalueerd en geprioriteerd, en dat hoog-ernstige kwetsbaarheden binnen redelijke termijnen worden verholpen. Vulnerability Assessment voldoet aan deze vereisten door automatisch wekelijkse scans uit te voeren en concrete herstelrichtlijnen te bieden voor geïdentificeerde kwetsbaarheden. De BIO Baseline Informatiebeveiliging Overheid Thema 12.06.01 vereist dat Nederlandse overheidsorganisaties technische kwetsbaarheden beheren door regelmatig te scannen op kwetsbaarheden en deze te verhelpen. Overheidsorganisaties die Azure SQL Databases gebruiken voor het verwerken van overheidsinformatie, moeten Vulnerability Assessment implementeren om te voldoen aan deze BIO-vereiste. De BIO-richtlijnen worden gebruikt als basis voor informatiebeveiliging in de Nederlandse publieke sector, en naleving is verplicht voor alle overheidsorganisaties. Tijdens BIO-audits wordt gecontroleerd of kwetsbaarheidsbeheer correct is geïmplementeerd en of dit voldoet aan de vereisten voor de classificatie van de verwerkte informatie. Voor informatie met een hoog classificatieniveau, zoals vertrouwelijk of zeer vertrouwelijk, zijn aanvullende maatregelen zoals frequentere scans of strengere remediëringstermijnen vaak vereist. Naast deze specifieke compliance-vereisten, vormt Vulnerability Assessment ook een best practice volgens andere belangrijke frameworks zoals het NIST Cybersecurity Framework, waar kwetsbaarheidsbeheer wordt aanbevolen als een fundamentele beveiligingscontrole, en de OWASP Top 10, die onvoldoende beveiligingsconfiguraties als een kritiek beveiligingsrisico identificeert. Organisaties die werken met internationale partners of klanten moeten vaak kunnen aantonen dat zij voldoen aan deze breed erkende beveiligingsstandaarden. Voor compliance-audits en certificeringen is het essentieel dat organisaties gedocumenteerd bewijs kunnen leveren van Vulnerability Assessment-implementatie. Dit bewijs omvat screenshots van de Azure Portal die de Vulnerability Assessment-status tonen, PowerShell-script output die de scanstatus verifieert, compliance-rapporten die regelmatig worden gegenereerd, en documentatie van de scanconfiguratie inclusief scanfrequentie en e-mailnotificatie-instellingen. Deze documentatie moet worden bewaard voor een periode die overeenkomt met de compliancevereisten, typisch minimaal zeven jaar voor financiële en overheidsorganisaties. Automatische compliance-rapportage via Microsoft Defender voor Cloud kan helpen bij het genereren en onderhouden van deze auditdocumentatie.

Remediatie

Gebruik PowerShell-script sql-vulnerability-assessment-enabled.ps1 (functie Invoke-Remediation) – Herstellen.

Remediatie van geïdentificeerde kwetsbaarheden in Azure SQL Databases is een kritiek proces dat systematisch moet worden uitgevoerd zodra kwetsbaarheden worden gedetecteerd door Vulnerability Assessment. Het verhelpen van kwetsbaarheden vereist zorgvuldige planning en coördinatie tussen beveiligingsteams en databasebeheerders om ervoor te zorgen dat remediëring succesvol wordt voltooid zonder negatieve impact op bedrijfsprocessen. Het remediatieproces omvat meerdere stappen, van identificatie en prioritering tot daadwerkelijke remediëring en verificatie. De eerste stap in het remediatieproces is de identificatie van alle kwetsbaarheden die aandacht vereisen. Vulnerability Assessment genereert automatisch een lijst van alle geïdentificeerde kwetsbaarheden met hun ernstclassificatie (Hoog/Medium/Laag), gedetailleerde beschrijvingen, en concrete herstel T-SQL-scripts. Deze lijst moet worden geprioriteerd op basis van ernst en bedrijfsimpact: hoog-ernstige kwetsbaarheden zoals TDE uitgeschakeld, publieke eindpunten zonder firewall, of sysadmin-rechten toegekend aan niet-beheerders hebben de hoogste prioriteit en moeten onmiddellijk worden aangepakt (binnen 48 uur). Medium-ernstige kwetsbaarheden zoals zwakke wachtwoordbeleid of ontbrekende SSL-afdwinging moeten binnen 30 dagen worden opgelost, waarbij prioriteit wordt gegeven op basis van compliance-impact (PCI-DSS bevindingen eerst). Laag-ernstige kwetsbaarheden kunnen worden toegevoegd aan de technische schuld backlog voor uiteindelijke opruiming. Voordat remediëring wordt uitgevoerd voor een productiedatabase, is het essentieel om een volledige backup te maken en te verifiëren dat deze backup succesvol is. Hoewel de meeste Vulnerability Assessment herstelscripts veilig zijn en geen downtime veroorzaken, is een recente backup een belangrijke veiligheidsmaatregel. Deze backup moet worden opgeslagen op een veilige locatie en moet kunnen worden gebruikt voor herstel indien er onverwachte problemen optreden tijdens het remediatieproces. Bovendien moet de databaseprestatie worden gemonitord vóór remediëring om een baseline te hebben waartegen post-implementatie prestaties kunnen worden vergeleken. Het daadwerkelijk uitvoeren van remediëring gebeurt via de T-SQL-scripts die door Vulnerability Assessment worden gegenereerd. Deze scripts zijn specifiek ontworpen voor elke kwetsbaarheid en bevatten de exacte commando's die nodig zijn om de kwetsbaarheid te verhelpen. Het proces omvat het kopiëren van het script uit het Vulnerability Assessment resultaatpaneel, het reviewen van het script op correctheid (verifiëren dat er geen impact is op bedrijfslogica), het uitvoeren in SQL Server Management Studio (SSMS) of Azure Data Studio in een TEST-omgeving eerst, en het deployen naar productie na validatie. Het is belangrijk om te benadrukken dat alle remediëringsacties moeten worden uitgevoerd via een change management-proces waarbij wijzigingen eerst worden getest in een testomgeving voordat ze worden toegepast op productie. Dit voorkomt dat remediëring onbedoelde negatieve gevolgen heeft voor bedrijfsprocessen. Na remediëring moet de kwetsbaarheidsstatus worden geverifieerd om te bevestigen dat remediëring succesvol is voltooid. Dit gebeurt door een nieuwe Vulnerability Assessment scan uit te voeren en te verifiëren dat de eerder geïdentificeerde kwetsbaarheid niet meer wordt gedetecteerd. Als de kwetsbaarheid nog steeds wordt gedetecteerd, moet het remediatieproces worden herhaald of moet worden onderzocht waarom de remediëring niet effectief was. Deze verificatie is belangrijk voor compliance-doeleinden en moet worden gedocumenteerd als auditbewijs. Voor organisaties met meerdere databases die moeten worden gerepareerd, kan het remediatieproces worden geautomatiseerd via PowerShell-scripts die alle geïdentificeerde kwetsbaarheden doorlopen en automatisch de bijbehorende T-SQL-scripts uitvoeren. Deze scripts kunnen worden uitgevoerd via Azure Automation runbooks of Azure Functions, waardoor het proces kan worden geautomatiseerd zonder handmatige interventie. Automatisering is vooral waardevol voor organisaties met honderden of duizenden databases, waarbij handmatige remediatie onpraktisch zou zijn. Het is echter belangrijk om automatisering zorgvuldig te testen in een niet-productieomgeving voordat deze wordt toegepast op productiedatabases. Na succesvolle remediatie moeten alle databases worden toegevoegd aan de continue monitoringstrategie om te voorkomen dat kwetsbaarheden in de toekomst terugkeren. Azure Policy kan worden geconfigureerd om automatisch te detecteren wanneer nieuwe kwetsbaarheden worden geïdentificeerd en onmiddellijk waarschuwingen te genereren. Bovendien moeten periodieke verificaties worden uitgevoerd om te bevestigen dat eerder opgeloste kwetsbaarheden opgelost blijven. Het remediatieproces zelf moet worden gedocumenteerd, inclusief de datum waarop remediëring is uitgevoerd, de gebruikte methode, en eventuele opgetreden problemen of observaties. Deze documentatie is essentieel voor compliance-audits en moet worden bewaard voor de vereiste retentieperiode.

Compliance & Frameworks

• CIS M365: Control SQL Security (L2) - kwetsbaarheidsbeoordeling voor Azure SQL Databases
• BIO: 12.06.01 - BIO Baseline Informatiebeveiliging Overheid - Thema 12: control van technische kwetsbaarheden - Vulnerability scanning
• ISO 27001:2022: A.12.6.1 - Management of technical vulnerabilities - Regular scanning
• NIS2: Artikel - kwetsbaarheidsbeoordeling en management

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

SQL Vulnerability Assessment is een automated security scanning tool die wekelijks 100+ database security checks uitvoert om misconfigurations, excessive permissions, missing security controls en compliance gaps te identificeren met actionable remediation guidance. VA scant voor: Excessive user permissions (database users met sysadmin of db_owner zonder business need), Weak password policies (accounts zonder complexity requirements, expired passwords, default credentials), Missing encryption (TDE disabled, unencrypted connections, backup encryption gaps), Overly permissive firewall rules (wildcard IP ranges, unnecessary Azure services access), SQL injection vulnerability indicators (dynamic SQL, insufficient input validation), Outdated database compatibility levels, Insufficient auditing configuration, Public endpoint exposure zonder Private Endpoints. VA is onderdeel van Microsoft Defender for SQL en wordt automatisch enabled bij Defender activering. Wekelijkse scans runnen automatic (geconfigureerde schedule) met results opgeslagen in Azure Storage Account en email notifications naar security teams. Scan results classificeren findings naar severity (High/Medium/Low) met: Detailed descriptions van de vulnerability, Business impact assessment, T-SQL remediation scripts die direct kunnen worden uitgevoerd voor fixes, Compliance mapping naar PCI-DSS, ISO 27001, CIS benchmarks. Baseline functionaliteit tracked improvements over tijd waarbij eerste scan establishes baseline en volgende scans tonen security posture trends (are vulnerabilities decreasing?). Deze maatregel is verplicht voor ALLE productie Azure SQL Databases, mandatory voor PCI-DSS 11.2 quarterly scanning requirements, vereist voor ISO 27001 A.12.6.1, essential voor continuous security improvement, en included in Defender for SQL costs (geen extra charges). Implementatie: VA enabled automatisch bij Defender for SQL, configure Storage Account voor scan results, set email recipients, run eerste scan (30 min), review results en remediate high-severity findings (2-4 uur). Kosten: included in Defender for SQL pricing (5 procent DB costs), Storage Account voor results minimaal (< €1/maand). Doorlopende effort: 0.1 FTE (4 uur/maand) voor weekly scan review en remediation. Return on investment komt van: proactive vulnerability detection voordat exploitation, compliance audit success PCI-DSS/ISO 27001, reduced breach risk via misconfiguration fixes, en executive visibility in database security posture trends.

• Implementatietijd: 2 uur
• FTE required: 0.02 FTE