3. Compute Resources


Compute Resources


1. Scope

Dit onderwerp richt zich op de evaluatie, optimalisatie en verbetering van de beveiliging van alle Azure Compute Resources. Het doel is om kwetsbaarheden en beveiligingslekken te identificeren die kunnen leiden tot dataverlies, verstoring van services of ongeautoriseerde toegang. Zowel infrastructuur- als toepassingslagen komen uitgebreid aan bod, met als doel de compute-omgeving in lijn te brengen met internationale best practices en de standaarden van Microsoft Azure.

1.1 Virtuele Machines

Virtuele machines vormen de kern van veel traditionele workloads en hybride applicaties. Binnen Azure is het daarom cruciaal om een gedegen beveiligings- en beheerstrategie te hanteren:

Netwerktoegang

  • Valideren van RDP- en SSH-configuraties: We onderzoeken of RDP- en SSH-poorten voldoende zijn afgeschermd door Network Security Groups (NSG's) en de optionele inzet van Azure Bastion om directe blootstelling aan het internet te vermijden.

  • Just-in-time (JIT) toegang: In plaats van permanent open poorten te hebben, beperken JIT-mechanismen de blootstelling van VMs aan de buitenwereld. Dit reduceert het risicoprofiel aanzienlijk.

Patchmanagement

  • Beoordelen van geautomatiseerde patching: Via Azure Update Management of derde partijen is het mogelijk om systematisch patches te installeren. We controleren of deze cycli regelmatig plaatsvinden en of er een duidelijk rollbackproces is voor het geval patches problemen veroorzaken.

  • Scannen op bekende kwetsbaarheden: Een grondige inventarisatie van geïnstalleerde softwarepakketten voorkomt dat verouderde of ongepatchte onderdelen een ingang vormen voor aanvallers.

Beveiligingsconfiguraties

  • Identificeren van zwakke wachtwoorden en ongewenste protocollen: We checken of standaard- of zwakke inloggegevens zijn blijven bestaan (bijvoorbeeld bij een net gemigreerde VM), en of er onveilige diensten (FTP, Telnet, SMBv1) onnodig actief zijn.

  • Gebruik van Secure Boot en vTPM: Met deze opties is het mogelijk om de VM-omgeving cryptografisch te verifiëren en meegeleverde bootloaders te valideren, waardoor de kans op rootkits en boot-level malware drastisch afneemt.

Logging en monitoring

  • Implementatie via Azure Monitor en Log Analytics: We analyseren of diagnostische logs correct worden opgeslagen, of er voldoende retentie is, en of er adequaat wordt omgegaan met waarschuwingen en alerts.

  • Detectie van afwijkend gedrag: Door logverzamelingen te correleren en te analyseren in bijvoorbeeld Azure Sentinel, kunnen afwijkende patronen (zoals brute-force inlogpogingen) tijdig worden opgemerkt.


1.2 Azure Kubernetes Service (AKS)

In moderne, containergebaseerde omgevingen is het essentieel om niet alleen containers te beveiligen, maar ook de onderliggende orchestrator (Kubernetes) en alle randcomponenten. Azure Kubernetes Service (AKS) biedt een beheerde Kubernetes-omgeving, maar de beveiligingsverantwoordelijkheid blijft grotendeels bij de gebruiker.

Containerbeveiliging

  • Veilige containerimages en image scanning: We valideren of er gebruik wordt gemaakt van vertrouwde container registries (zoals Azure Container Registry) en of er tools (bijv. ACR Tasks of derde-partyscanners) zijn ingeschakeld om kwetsbaarheden in images te detecteren.

  • Resource quotas en beperkingen: Een gebrekkige configuratie op het gebied van CPU- en geheugengebruik kan leiden tot DoS-aanvallen of resource starvation binnen het cluster.

Clusterbeheer

  • Beveiliging van control plane: De Kubernetes API-server en de etcd-database vormen het hart van de clusterconfiguratie. Inzichten in toegangslogs en encryptie-in-transit voor etsd-data zijn hier van belang.

  • CIS Kubernetes Benchmarks: Met behulp van benchmarktools (bijvoorbeeld kube-bench) worden configuratieproblemen en afwijkingen ten opzichte van best practices inzichtelijk gemaakt.

RBAC

  • Least privilege-rollen: We controleren of Kubernetes Roles en ClusterRoles in combinatie met RoleBindings en ClusterRoleBindings op een minimaal noodzakelijke wijze zijn toegekend.

  • Serviceaccounts en secrets: Het juist beheren en roteren van secrets (bijvoorbeeld via Kubernetes Secrets of Key Vault) is essentieel om credential exposure te voorkomen.

Netwerken

  • Netwerkpolicies: Door expliciete netwerkpolicies in te zetten, wordt verkeer tussen pods en namespaces strikt gereguleerd. Dit helpt laterale bewegingen van aanvallers aanzienlijk te beperken.

  • Private endpoints en interne services: Het vermijden van publiekelijk toegankelijke services is sterk aan te raden. We inspecteren of private links correct zijn geconfigureerd en of pods niet onnodig aan het internet hangen.


1.3 App Services en Function Apps

Serverloze en platformgebaseerde oplossingen (PaaS) bieden ontwikkelaars een flexibele manier om applicaties uit te rollen zonder zich zorgen te hoeven maken over de onderliggende infrastructuur. Desalniettemin zijn er nog steeds belangrijke beveiligingsmaatregelen die in acht moeten worden genomen.

Configuratiebeheer

  • HTTPS-only en TLS 1.2+: We controleren of onbeveiligde HTTP-toegang is uitgeschakeld en of verouderde TLS-versies (1.0/1.1) niet langer worden geaccepteerd.

  • Deployment slots en webconfiguraties: Een verkeerde configuratie kan leiden tot blootstelling van gevoelige instellingen (bijv. connection strings, API-keys).

Code- en runtime-integriteit

  • Analyse op injectieaanvallen: De code wordt gecontroleerd op SQL-injectie, XSS, command injection en andere veelvoorkomende kwetsbaarheden.

  • Dependencybeheer: Door middel van tooling zoals GitHub Dependabot of scans in Azure Pipelines wordt bekeken of third-party bibliotheken up-to-date en veilig zijn.

Identity en toegangsbeheer

  • Managed Identities: Deze ingebouwde Azure-functionaliteit vervangt gevoelige inloggegevens voor externe services door beveiligde tokens, wat het beheer van secrets en credentials vermindert.

  • Serverloze beveiligingsopties: Voor Function Apps is het belangrijk te controleren op IP-restricties, rate limiting en eventueel extra authenticatie- en autorisatielagen (bijv. OAuth2).


1.4 Virtual Machine Scale Sets (VMSS)

Virtual Machine Scale Sets stellen organisaties in staat om automatisch een set identieke VM-instances te draaien en dynamisch op te schalen op basis van vraag. De beveiliging van deze omgevingen vereist specifieke aandacht.

Auto-scaling instellingen

  • Validatie van schaalregels: Als de schaalmechanismen niet goed zijn ingesteld, kunnen malafide acties (bijv. DDoS-aanvallen) ertoe leiden dat de omgeving ongecontroleerd opschaalt. Daarnaast is het zaak om security-oplossingen (bijv. NSG's) automatisch mee te laten schalen.

  • Resource templates: We verifiëren of alleen geautoriseerde golden images en configuraties gebruikt worden, en of er geen onnodige variatie is in de VM-instances.

Netwerk- en endpointbeveiliging

  • NSG’s en firewallregels: Elke VM in de schaalset moet dezelfde beveiligings- en netwerkpolicies hanteren om geen “zwakke schakel” te introduceren.

  • Diagnostische configuraties en telemetrie: Een adequaat log- en monitoringbeleid moet worden geïmplementeerd om snel aanvallen of misconfiguraties te detecteren en te kunnen verhelpen.


1.5 Azure Batch Services

Voor grootschalige parallelle workloads (bijvoorbeeld transcoderen van video, wetenschappelijke berekeningen) biedt Azure Batch Services een schaalbaar platform. De focus ligt hier voornamelijk op veilige verwerking van data en toegangscontrole.

Toegangsbeheer

  • Azure AD-integratie: We controleren of Batch Services worden benaderd met geverifieerde identiteiten en of rollen correct zijn toegewezen via RBAC, zodat alleen bevoegde gebruikers jobs kunnen starten of stoppen.

  • Beveiliging van batch pools: Sommige Batch-taken kunnen extra privileges vereisen, maar het is essentieel om te waarborgen dat deze privileges niet breder zijn dan noodzakelijk.

Dataverwerking

  • Encryptie tijdens overdracht en opslag: Bij de verwerking van gevoelige gegevens (medisch, financieel) dient TLS 1.2 of hoger en sterke versleuteling (bijv. AES-256) te worden gegarandeerd.

  • Gegevenslogging en compliance: We onderzoeken of de logs voldoende detailniveau hebben om incidenten te traceren en of deze in overeenstemming zijn met relevante compliance-eisen (bijv. GDPR).


2. Rules of Engagement

Deze sectie beschrijft de spelregels en randvoorwaarden waaronder de penetratietesten en beveiligingsaudits op de compute resources plaatsvinden. Het naleven van deze regels zorgt voor een veilige en gecontroleerde testomgeving, die de risico’s voor de productie-infrastructuur minimaliseert.

  1. Beperking tot testomgevingen

  • Niet-productie: Vooraf wordt overeenstemming bereikt of tests uitsluitend plaatsvinden in gesandboxte, niet-kritieke omgevingen. Indien live-omgevingen toch vereist zijn, wordt een strikte impactanalyse uitgevoerd.

  1. Impactbeperking

  • Voorzichtigheid bij destructieve tests: Scans en simulaties worden zodanig uitgevoerd dat de beschikbaarheid en integriteit van workloads niet onnodig in gevaar komen.

  • Rolgebaseerde restricties: Testers ontvangen uitsluitend de minimale rechten die noodzakelijk zijn voor het uitvoeren van de afgesproken testscenario’s.

  1. Rapportage van kritieke bevindingen

  • Onmiddellijke melding: Indien er een kritieke kwetsbaarheid of een imminent risico wordt ontdekt, wordt dit direct gemeld bij de verantwoordelijken. Zo kan direct actie worden ondernomen om misbruik te voorkomen.

  1. Testtijdvensters

  • Afstemming met operationele teams: Om operationele verstoringen te beperken, worden de testtijdstippen vooraf afgestemd en vastgelegd, meestal in daluren of onderhoudsvensters.


3. Teststrategie

De teststrategie is gericht op het actief en passief onderzoeken van potentiële zwaktes binnen elke laag van de compute-omgeving. Hierbij wordt gebruikgemaakt van een combinatie van geautomatiseerde scans, handmatige penetratietesten en configuratie-audits om een zo volledig mogelijk beeld te krijgen van de beveiligingsstatus.

3.1 Virtuele Machines: Kernbeveiliging

Netwerkpenetratietests

  • Scannen op open poorten: Tools als Nmap of Nessus worden ingezet om te controleren op ongeautoriseerde open poorten en zwakke protocollen.

  • Brute force-aanvallen: Waar toegestaan, worden SSH- en RDP-aanmeldingen getest met dictionary- en password-spraying-technieken.

Privilege-escalatie

  • Lokale configuraties: We analyseren of misconfiguraties in besturingssystemen en applicaties kunnen leiden tot verticale (binnen één VM) of horizontale (naar andere VMs) escalatie.

  • Sudo- en service-misbruik: Onderzoek naar onveilige sudo-configuraties, setuid-binaire bestanden en diensten die met te hoge privileges draaien.

Hardening controles

  • CIS Benchmarks: We toetsen Windows- en Linux-VMs aan de CIS-hardeningrichtlijnen, waarbij controlelijsten helpen om snel aan te geven waar het systeem afwijkt van aanbevolen best practices.


3.2 Azure Kubernetes Service (AKS)

Security Context

  • Geen root containers: Containers draaien idealiter niet als root; we onderzoeken of er deployment-manifests zijn die dit toch vereisen en of capabilities correct zijn ingesteld.

  • Pod Security Standards: Nagaan of baseline, restricted of privileged profielen juist worden gehanteerd in het cluster.

Logging en monitoring

  • Containerlogs en auditlogs: We analyseren of kubectl-auditlogging aanstaat en of containerlogs centraal worden opgeslagen (bijv. via Azure Monitor for containers).

  • Verdachte activiteiten: Patroonherkenning op ongewone commando’s, niet-standaard netwerkscans en snelle opeenvolgende aan-/afmeldingen.

Simuleren van aanvallen

  • Container breakout-tests: We proberen containerisolatie te doorbreken via bekende kwetsbaarheden of misconfiguraties.

  • Netwerkintercepties: Door ARP-spoofing of DNS-manipulatie binnen het cluster te testen, controleren we de effectiviteit van netwerkpolicies en segmentatie.


3.3 App Services en Function Apps

Code-analyse

  • Static en dynamic application security testing: Met geautomatiseerde en handmatige methoden wordt code onder de loep genomen om kwetsbaarheden en logische fouten te identificeren.

  • Secrets en configuratiebestanden: We controleren of gevoelige waarden (zoals API-sleutels) onbedoeld in plaintext in configbestanden of code zijn opgenomen.

Beveiliging van API’s

  • OWASP API Security Top 10: We voeren gerichte tests uit om veelvoorkomende API-kwetsbaarheden (API1:2019 - Broken Object Level Authorization, API2:2019 - Broken User Authentication, etc.) te ontdekken.

  • API-key management: We onderzoeken of keys regelmatig worden geroteerd en of er rate limiting is ingeschakeld om misbruik te voorkomen.

Monitoring

  • Application Insights: De configuratie van Application Insights wordt beoordeeld om na te gaan of er voldoende gegevens worden verzameld en of alerts adequaat zijn ingesteld.

  • Web Application Firewall (WAF): Indien er gebruik wordt gemaakt van Azure Front Door of Application Gateway, analyseren we of de WAF-polici correct zijn geconfigureerd en actueel zijn.


3.4 Virtual Machine Scale Sets (VMSS) en Batch Services

Schaalbaarheidstests

  • Load- en stresstests: We simuleren piekbelasting om te beoordelen in hoeverre VMSS en Batch Services veilig schalen en of hierbij geen nieuwe aanvalsvectoren (bijv. open management-interfaces) worden geopend.

  • Kosten en resourcegebruik: Overmatige opschaling kan niet alleen tot beveiligingsrisico’s leiden, maar ook onverwachte kosten veroorzaken. Deze tests hebben tevens als doel onnodige uitgaven te identificeren.

Incidentrespons

  • Herstelscenario’s: We bekijken of logging en alerting processen voldoende tijdig alarmeren om snel in te kunnen grijpen bij misbruik, en of er back-upmechanismen (bijv. snapshot bij VMSS) paraat staan.

  • Foutafhandeling: Als een Batch-job of VM-instantie faalt, moet de omgeving niet onveilig raken door tijdelijke configuratiewijzigingen of noodprocedures.

Batch data-beveiliging

  • Behandeling van hooggevoelige data: Door de aard van Batch Services worden er soms zeer grote hoeveelheden gevoelige data geüpload en verwerkt. We controleren op secure transfer, encryptie-at-rest en restricties op data-exfiltratie.

  • Multi-tenant overwegingen: Wanneer meerdere teams of klanten de Batch-omgeving delen, is de isolatie van data en rekenkracht een belangrijk aandachtspunt om onbedoelde ‘kijkjes over de schutting’ te vermijden.


Conclusie

Een grondige beoordeling van Azure Compute Resources vraagt om een multidisciplinaire aanpak, waarin zowel de infrastructuur als de applicatielaag onder de loep wordt genomen. Door te focussen op hardening, patchmanagement, toegangsbeperkingen en continue monitoring kunnen organisaties de kans op beveiligingsincidenten substantieel verkleinen. Bovendien biedt een doordacht test- en evaluatietraject inzicht in onderliggende processen, waardoor niet alleen technische, maar ook organisatorische verbeteringen kunnen worden doorgevoerd.

Met deze uitgebreide benadering kunnen organisaties hun omgevingen optimaliseren voor robuuste security en hoge beschikbaarheid, en tegelijkertijd voldoen aan de steeds strengere compliance- en regelgevingseisen.

Last updated