7 typische security fouten in Azure die je moet voorkomen

1. Het Shared Responsibility Model niet begrijpen

Een veelgemaakte fout bij cloudgebruik is denken dat de provider álles regelt qua security. In werkelijkheid werkt Microsoft Azure met een shared responsibility model:

• Microsoft zorgt voor de beveiliging van de onderliggende infrastructuur (servers, netwerk).
• Jij bent verantwoordelijk voor je data, apps en de configuratie van Azure services.

Best practices

• Documenteer duidelijk wie binnen jouw organisatie verantwoordelijk is voor welke beveiligingstaken.
• Zet identity & access management (IAM) goed op.
• Monitor en log actief.
• Beveilig je data.

2. Onbeschermde publieke endpoints

Onbeveiligde publieke endpoints naar websites, management poorten, externe toegang tot servers of iets dergelijks stellen je bloot aan het openbare internet. Elke public IP is een risico.

Vraag je af: moet dit echt?

Best practices

IaaS:

• Gebruik ACLs en NSGs om toegang te beperken.
• Schakel Just-in-Time toegang in binnen Microsoft Defender for Cloud in voor tijdelijk beheer.
• Overweeg VPN of appliances uit de VM-gallery.
• Gebruik Azure Bastion voor RDP/management.

PaaS:

• Compute:
  • Firewalls, IP-filters
  • Service endpoints (geen toegang buiten Azure)
  • Private endpoints voor extra veiligheid
• Data:
  • Network access lists voor storage
  • IP-ranges voor toegestane toegang
  • VNet en VPN
  • SAS-tokens (tijdelijk, IP-filtering optioneel)
• Management:
  • Conditional Access (MFA, IP-restricties) voor portals

Zelfs als een blob of file publiek is, geven SAS-tokens extra controle. Dit is lichter dan overal Private Link afdwingen, maar wel veel veiliger.

3. Iedereen de Owner-rol geven

Een andere fout: iedereen Owner maken in Azure. Dit komt vaak voor bij nieuwe projecten en organisaties.

Probleem: Owners mogen álles – toegang beheren, resources aanmaken of verwijderen, anderen uitnodigen. Op subscription-niveau kan één Owner alles slopen of delen. Dat is een groot risico.

Best practices

Wat je beter kunt doen: 

• Scheid taken. Contributor beheert resources, User Access Admin beheert rollen. Niemand heeft zo alle macht.
• Ken rollen toe op resource group niveau, niet op subscriptie niveau. Check regelmatig je RBAC-rollen.

Door rollen slim te verdelen en governance toe te passen, beperk je risico’s. Gebruik Management Groups en policies om dit goed in te regelen.

4. Data niet encrypten (at rest)

Data-encryptie is een van de effectiefste maatregelen om je data te beschermen. Zelfs als data wordt buitgemaakt, blijft het zonder sleutel onleesbaar.

Best practices

Gebruik oplossingen zoals Azure Disk Encryption en Azure Key Vault.

5. Open Network Security Groups (NSGs)

Network Security Groups (NSGs) regelen inkomend en uitgaand verkeer naar Azure-resources. Ze zijn krachtig, maar fouten in de configuratie komen vaak voor en maken je omgeving kwetsbaar.

Veelvoorkomende fouten zijn:

• Alles openlaten: inbound “Any” of outbound zonder beperkingen
• Te brede permissies gebruiken
• Geen segmentatie tussen subnets of workloads
• NSGs niet overal consequent toepassen
• Alleen vertrouwen op NSGs zonder extra lagen zoals firewalls

Gevolg: Aanvallers kunnen je VMs en services targeten, zeker als managementpoorten openstaan.

Best practices

• Open alleen strikt noodzakelijke poorten en blokkeer de rest
• Controleer en verscherp je NSG-regels regelmatig
• Beperk toegang tot vertrouwde IP-ranges of via VPN
• Gebruik Just-in-Time (JIT) voor RDP/SSH, nooit permanent openlaten
• Combineer NSGs met Azure Firewall of Web Application Firewall (WAF)

Door het principe van ‘least privilege’ te volgen en regels strak te houden, verklein je je aanvalsvlak aanzienlijk.

6. Onveilige Storage Accounts

Azure Storage is schaalbaar en veilig, maar een verkeerde configuratie kan je data blootstellen. Een klassiek voorbeeld is een storage account dat publiek toegankelijk is, met risico op datalekken of verlies.

Andere fouten zijn:

• Shared keys gebruiken i.p.v. RBAC
• Geen restricties op netwerk of IP-ranges
• Standaardinstellingen gebruiken zonder aanpassing

Best practices

Zo beveilig je storage accounts:

• Schakel public access altijd uit (tenzij echt nodig)
• Gebruik Azure RBAC met managed identities i.p.v. account keys
• Beperk toegang met network rules, private endpoints en service endpoints
• Zet logging en monitoring aan
• Gebruik customer-managed keys (CMK) voor gevoelige workloads
• Gebruik SAS-tokens met verloopdatum en IP-restricties voor extern delen

7. Geen monitoring en logging

Een van de meest gemaakte fouten in Azure-projecten is het ontbreken van audit logging. Niet dat logs beperkt zijn of te weinig detail geven – vaak zijn ze er gewoon helemaal niet.

Zonder goede monitoring en logging kun je afwijkende activiteiten niet zien of incidenten niet goed onderzoeken. Niet alle Azure-diensten loggen standaard, en vaak is de retentie kort (bijvoorbeeld 90 dagen voor Azure Activity Logs). Azure Monitor geeft soms metrics (zoals bij Key Vault), maar niet altijd detail in de activiteiten.

Best practices

Om gaten te dichten kun je automatische alerts instellen:

• Zet Microsoft Defender aan per service (bijv. Key Vault, Storage Account). Dit geeft je automatische of custom alerts.

Voorbeeld (Storage Account):

• Alert bij toegang vanaf een ongebruikelijke locatie
• Alert bij mogelijke data-exfiltratie
• Alert bij opvallend gebruikersgedrag

Zelfs zonder Sentinel of een volledig SOC-team zijn dit waardevolle meldingen. Consequente monitoring in Azure geeft je sneller zicht op mogelijke dreigingen en de kans om direct te reageren.