Infrastructure As Code Beveiliging Voor Azure Omgevingen

Zonder adequate beveiliging in Infrastructure as Code workflows ontstaan aanzienlijke risico's die kunnen leiden tot compromittering van Azure-omgevingen, datalekken en niet-naleving van wettelijke vereisten. Een van de grootste risico's betreft de aanwezigheid van gevoelige informatie zoals wachtwoorden, API-keys, connection strings en certificaten in IaC-bestanden. Wanneer deze bestanden worden opgeslagen in versiebeheersystemen zoals Git zonder adequate beveiliging, kunnen kwaadwillenden toegang krijgen tot deze credentials en deze gebruiken om Azure-resources te compromitteren. Daarnaast kunnen IaC-bestanden misconfiguraties bevatten die beveiligingslekken introduceren, zoals storage accounts die publiek toegankelijk zijn, netwerken zonder firewallregels, of resources zonder encryptie. Zonder geautomatiseerde security scanning worden deze problemen pas ontdekt nadat de infrastructuur is geïmplementeerd, wat betekent dat kwetsbare configuraties al in productie staan voordat zij worden gecorrigeerd. Een ander kritiek risico betreft supply chain security: wanneer IaC-modules of templates worden geïmporteerd van externe bronnen zonder verificatie, kunnen kwaadwillenden kwaadaardige code injecteren die automatisch wordt uitgevoerd tijdens deployment. Voor Nederlandse overheidsorganisaties die moeten voldoen aan NIS2, BIO en ISO 27001 is dit onacceptabel: deze frameworks vereisen dat organisaties kunnen aantonen dat zij passende maatregelen hebben getroffen om supply chain-risico's te beheersen en dat gevoelige informatie adequaat wordt beschermd. Een goed geïmplementeerd IaC-beveiligingsraamwerk levert het bewijs dat organisaties proactief hebben geïnvesteerd in beveiliging die aansluit bij moderne DevOps-werkwijzen en cloud-first benaderingen.

Implementatie

Dit artikel beschrijft een concrete implementatie van Infrastructure as Code beveiliging voor Azure-omgevingen, specifiek toegespitst op de context van Nederlandse overheidsorganisaties. Het raamwerk is gebaseerd op zes fundamentele pijlers: secret management en credential protection, code security scanning en static analysis, supply chain security en dependency management, infrastructure drift detection en compliance monitoring, least privilege access control voor IaC deployments, en audit logging en change tracking. De eerste pijler betreft secret management waarbij gevoelige informatie zoals wachtwoorden, API-keys en connection strings worden opgeslagen in Azure Key Vault in plaats van in IaC-bestanden, en waarbij IaC-code verwijst naar Key Vault-secrets via secure references. De tweede pijler richt zich op code security scanning met tools zoals Checkov, Terrascan, Semgrep en Azure Policy voor IaC die IaC-bestanden analyseren op misconfiguraties, kwetsbaarheden en niet-naleving van beveiligingsstandaarden voordat zij worden geïmplementeerd. De derde pijler adresseert supply chain security met dependency scanning voor externe modules, signature verification voor geïmporteerde templates, en whitelisting van goedgekeurde IaC-modules en providers. De vierde pijler betreft infrastructure drift detection waarbij geautomatiseerde tools continu monitoren of de daadwerkelijke Azure-infrastructuur nog overeenkomt met de gedefinieerde IaC-code, en waarbij afwijkingen worden gedetecteerd en gerapporteerd. De vijfde pijler richt zich op least privilege access control waarbij service principals en managed identities worden gebruikt voor IaC deployments met minimale benodigde rechten, en waarbij role-based access control wordt toegepast om te voorkomen dat onbevoegde gebruikers wijzigingen kunnen doorvoeren. De zesde pijler betreft audit logging en change tracking waarbij alle IaC-implementaties worden gelogd, versiebeheerd en gekoppeld aan specifieke gebruikers of service principals, zodat wijzigingen traceerbaar zijn voor compliance en security incident response. Het artikel beschrijft voor elke pijler concrete implementatiestappen, best practices, Azure-native services en tools die kunnen worden ingezet, en hoe de pijlers onderling samenwerken om een robuuste IaC-beveiligingspostuur te creëren. Daarnaast wordt uitgelegd hoe dit raamwerk aansluit bij NIS2-verplichtingen rond supply chain security, BIO-normen voor risicomanagement en Microsoft's IaC security best practices.

Vereisten

Een succesvolle implementatie van Infrastructure as Code beveiliging in Azure vereist een grondige voorbereiding op zowel technisch als organisatorisch vlak. De eerste vereiste is een volledige inventarisatie van alle IaC-artefacten die worden gebruikt voor het beheren van Azure-infrastructuur. Dit omvat niet alleen de primaire IaC-bestanden zoals Terraform-configuraties, Bicep-modules en ARM-templates, maar ook alle ondersteunende bestanden zoals CI/CD-pipeline-configuraties, scripts die worden gebruikt tijdens deployment, externe modules die worden geïmporteerd, en configuratiebestanden voor IaC-tools. Zonder een compleet overzicht is het onmogelijk om te bepalen welke beveiligingscontroles waar moeten worden toegepast en welke risico's er bestaan. Deze inventarisatie moet niet alleen technische details bevatten – zoals welke IaC-tools worden gebruikt, waar IaC-bestanden worden opgeslagen, welke externe dependencies worden gebruikt, welke secrets worden gebruikt en waar deze worden opgeslagen – maar ook functionele context: welke workloads worden beheerd via IaC, welke data wordt verwerkt en wat is de classificatie daarvan, welke compliance-vereisten gelden per workload, en wie heeft toegang tot IaC-repositories en deployment-pipelines. Deze informatie vormt de basis voor het bepalen van de prioritering en de intensiteit van beveiligingscontroles per IaC-artefact. Een tweede cruciale vereiste is het hebben van een duidelijk IaC-beveiligingsbeleid en risicokader dat specifiek is uitgewerkt voor Infrastructure as Code workflows. Dit beleid moet definiëren welke beveiligingscontroles verplicht zijn voor welke typen IaC-artefacten, welke secrets management-aanpak wordt gebruikt, welke security scanning-tools worden ingezet, welke externe modules zijn toegestaan en welke niet, wat de acceptabele restrisico's zijn na implementatie, en hoe risicobeslissingen worden genomen op basis van security scan-resultaten. Binnen Nederlandse overheidsorganisaties moet dit beleid expliciet aansluiten bij het BIO-raamwerk, NIS2-verplichtingen rond supply chain security en AVG-vereisten voor data protection. Het beleid moet schriftelijk zijn vastgelegd, door het bestuur zijn goedgekeurd en regelmatig worden herzien op basis van veranderende dreigingen en nieuwe IaC-technologieën. Zonder een dergelijk kader bestaat het risico dat beveiligingscontroles ad hoc worden geïmplementeerd zonder duidelijke samenhang of dat bepaalde aspecten worden overgeslagen omdat de noodzaak niet duidelijk is. Technisch gezien vereist IaC-beveiliging de beschikbaarheid van de juiste Azure-services en tools. Voor secret management zijn Azure Key Vault, Azure Managed Identities en service principals nodig voor het veilig opslaan en gebruiken van credentials tijdens IaC deployments. Voor code security scanning zijn tools zoals Checkov, Terrascan, Semgrep, Azure Policy voor IaC en GitHub Advanced Security nodig voor het analyseren van IaC-bestanden op misconfiguraties en kwetsbaarheden. Voor supply chain security zijn dependency scanning tools, signature verification mechanisms en module whitelisting nodig voor het beveiligen van externe dependencies. Voor infrastructure drift detection zijn tools zoals Azure Policy, Terraform Cloud of Azure Resource Graph nodig voor het monitoren van afwijkingen tussen IaC-code en daadwerkelijke infrastructuur. Voor access control zijn Azure RBAC, Azure AD Conditional Access en CI/CD pipeline permissions nodig voor het beheren van wie IaC kan wijzigen en implementeren. Voor audit logging zijn Azure Monitor, Log Analytics en Azure Activity Log nodig voor het loggen van alle IaC-implementaties en wijzigingen. Organisaties moeten ervoor zorgen dat zij over de benodigde licenties en tools beschikken voordat zij beginnen met de implementatie, anders kunnen zij niet alle beveiligingspijlers volledig inrichten. Daarnaast is er een duidelijke rol- en verantwoordelijkheidsverdeling nodig tussen verschillende teams en functies. De CISO of security officer is verantwoordelijk voor het opstellen van het IaC-beveiligingsbeleid en het toezicht op de implementatie, maar individuele teams blijven verantwoordelijk voor de concrete implementatie van beveiligingscontroles binnen hun eigen IaC-artefacten. Cloud architects zijn verantwoordelijk voor het ontwerpen van de IaC-beveiligingsarchitectuur en het zorgen dat pijlers onderling goed samenwerken. Security engineers zijn verantwoordelijk voor de technische implementatie en configuratie van beveiligingsservices en scanning-tools. DevOps engineers zijn verantwoordelijk voor het integreren van beveiliging in CI/CD-pipelines en het zorgen dat IaC-bestanden voldoen aan beveiligingsstandaarden voordat zij worden geïmplementeerd. Platform engineers zijn verantwoordelijk voor het beheer en monitoring van de onderliggende IaC-infrastructuur en tools. Operations teams zijn verantwoordelijk voor het dagelijks beheer en monitoring van IaC-beveiligingscontroles. Zonder deze duidelijke verdeling ontstaat verwarring over wie verantwoordelijk is voor welke aspecten, wat kan leiden tot gaten in de beveiliging of overlappende inspanningen. Tot slot vereist IaC-beveiliging een volwassen proces voor continue monitoring, evaluatie en verbetering. IaC-beveiligingscontroles zijn niet statisch maar moeten regelmatig worden geëvalueerd op effectiviteit, bijgewerkt op basis van nieuwe dreigingen en IaC-technologieën, en getest om te verifiëren dat zij nog steeds functioneren zoals bedoeld. Dit vereist vaste planningsmomenten in de governancekalender, waarin beveiligingscontroles worden gereviewd, nieuwe bedreigingen worden geëvalueerd en verbetermaatregelen worden geïdentificeerd. Daarnaast moeten er processen zijn voor het reageren op security incidents waarbij wordt geanalyseerd welke beveiligingscontroles hebben gefaald en hoe deze kunnen worden verbeterd. Alleen met een dergelijk continu verbeterproces blijft een IaC-beveiligingsimplementatie effectief in de tijd.

Implementatie

Gebruik PowerShell-script infrastructure-as-code-security.ps1 (functie Invoke-Implementation) – Valideert en implementeert Infrastructure as Code beveiligingscontroles.

De implementatie van Infrastructure as Code beveiliging in Azure begint met het opstellen van een gedetailleerd implementatieplan dat alle zes beveiligingspijlers omvat en prioriteert op basis van risico en kritiekheid van workloads. Het plan moet per pijler beschrijven welke Azure-services en tools worden ingezet, welke configuraties worden toegepast, welke IaC-artefacten worden beschermd en in welke volgorde de implementatie plaatsvindt. In de praktijk wordt vaak begonnen met de fundamenten – secret management en code security scanning – omdat deze pijlers de basis vormen voor alle andere beveiligingscontroles. Vervolgens worden supply chain security en infrastructure drift detection geïmplementeerd, gevolgd door access control en audit logging om alle pijlers te kunnen bewaken. De eerste pijler – secret management en credential protection – wordt geïmplementeerd door alle gevoelige informatie zoals wachtwoorden, API-keys, connection strings en certificaten te verplaatsen van IaC-bestanden naar Azure Key Vault. Voor Terraform-configuraties worden secrets opgeslagen in Key Vault en worden Key Vault data sources gebruikt om secrets op te halen tijdens deployment. Voor Bicep-modules worden Key Vault references gebruikt om secrets te injecteren zonder deze in code op te slaan. Voor ARM-templates worden Key Vault-linked templates gebruikt voor het veilig doorgeven van secrets. Daarnaast worden managed identities en service principals geconfigureerd voor IaC deployments zodat deployments kunnen authenticeren bij Azure zonder hardcoded credentials. Azure Key Vault access policies worden geconfigureerd met least privilege-principes zodat alleen geautoriseerde service principals en gebruikers toegang hebben tot secrets. Key Vault soft delete en purge protection worden ingeschakeld om te voorkomen dat secrets per ongeluk worden verwijderd. Deze pijler vormt de eerste verdedigingslinie tegen credential exposure en is essentieel omdat gecompromitteerde credentials kunnen worden gebruikt om Azure-resources te compromitteren. De tweede pijler – code security scanning en static analysis – wordt geïmplementeerd door security scanning-tools te integreren in CI/CD-pipelines zodat IaC-bestanden automatisch worden geanalyseerd voordat zij worden geïmplementeerd. Checkov wordt geconfigureerd om Terraform-, CloudFormation- en Kubernetes-configuraties te scannen op misconfiguraties en kwetsbaarheden. Terrascan wordt geconfigureerd om Terraform-configuraties te analyseren op security best practices. Semgrep wordt geconfigureerd om IaC-code te scannen op kwetsbare patronen en hardcoded secrets. Azure Policy voor IaC wordt geconfigureerd om IaC-bestanden te valideren tegen beveiligingsstandaarden voordat zij worden geïmplementeerd. GitHub Advanced Security wordt geconfigureerd om IaC-repositories te scannen op secrets, dependencies en kwetsbaarheden. Deze tools worden geïntegreerd in pull request-workflows zodat security scans automatisch worden uitgevoerd wanneer IaC-code wordt gewijzigd, en zodat pull requests worden geblokkeerd wanneer kritieke beveiligingsproblemen worden gedetecteerd. Security scan-resultaten worden geïntegreerd in dashboards en rapportages zodat security teams en bestuurders inzicht hebben in de beveiligingsstatus van IaC-artefacten. De derde pijler – supply chain security en dependency management – wordt geïmplementeerd door externe IaC-modules en dependencies te scannen op kwetsbaarheden en kwaadaardige code. Terraform-modules worden geanalyseerd met dependency scanning tools om te detecteren of geïmporteerde modules bekende kwetsbaarheden bevatten. Module signatures worden geverifieerd om te verifiëren dat geïmporteerde modules daadwerkelijk afkomstig zijn van vertrouwde bronnen en niet zijn gewijzigd. Een whitelist wordt opgesteld van goedgekeurde IaC-modules en providers die mogen worden gebruikt, en CI/CD-pipelines worden geconfigureerd om te blokkeren wanneer niet-goedgekeurde modules worden geïmporteerd. Private module registries worden opgezet voor het hosten van interne IaC-modules zodat organisaties niet afhankelijk zijn van externe bronnen voor kritieke infrastructurele componenten. Deze pijler voorkomt dat kwaadaardige code wordt geïmporteerd via externe dependencies en beschermt tegen supply chain-aanvallen. De vierde pijler – infrastructure drift detection en compliance monitoring – wordt geïmplementeerd door geautomatiseerde tools te configureren die continu monitoren of de daadwerkelijke Azure-infrastructuur nog overeenkomt met de gedefinieerde IaC-code. Terraform Cloud of Terraform Enterprise worden geconfigureerd om infrastructure drift te detecteren en te rapporteren wanneer resources handmatig worden gewijzigd buiten de IaC-workflow om. Azure Policy wordt geconfigureerd om te monitoren of resources voldoen aan beveiligingsstandaarden die zijn gedefinieerd in IaC-code. Azure Resource Graph wordt gebruikt om queries uit te voeren die detecteren wanneer resources zijn gewijzigd zonder dat deze wijzigingen zijn terug te vinden in IaC-code. Wanneer drift wordt gedetecteerd, worden alerts gegenereerd en worden automatische remediation-acties uitgevoerd om de infrastructuur terug te brengen naar de gewenste staat zoals gedefinieerd in IaC-code. Deze pijler zorgt ervoor dat infrastructurele wijzigingen traceerbaar zijn en dat beveiligingsconfiguraties consistent blijven. De vijfde pijler – least privilege access control voor IaC deployments – wordt geïmplementeerd door service principals en managed identities te configureren met minimale benodigde rechten voor IaC deployments. Azure RBAC wordt geconfigureerd zodat service principals alleen de specifieke rechten hebben die nodig zijn voor het implementeren van resources zoals gedefinieerd in IaC-code, en niet meer. Azure AD Conditional Access wordt geconfigureerd om te vereisen dat gebruikers die IaC-code wijzigen multi-factor authenticatie gebruiken en voldoen aan device compliance-vereisten. CI/CD-pipeline permissions worden geconfigureerd zodat alleen geautoriseerde gebruikers en service principals IaC-implementaties kunnen triggeren. Pull request-approval-workflows worden geconfigureerd zodat wijzigingen aan kritieke IaC-artefacten moeten worden goedgekeurd door meerdere reviewers voordat zij worden geïmplementeerd. Deze pijler voorkomt dat onbevoegde gebruikers wijzigingen kunnen doorvoeren aan Azure-infrastructuur via IaC. De zesde pijler – audit logging en change tracking – wordt geïmplementeerd door alle IaC-implementaties te loggen en te koppelen aan specifieke gebruikers of service principals. Azure Activity Log wordt geconfigureerd om alle resource-implementaties te loggen die worden uitgevoerd via IaC. Log Analytics wordt geconfigureerd om IaC-implementatie-logs op te slaan en te analyseren voor security events. Git-repositories worden geconfigureerd met branch protection rules en commit signing om te verifiëren dat IaC-code-wijzigingen daadwerkelijk afkomstig zijn van geautoriseerde gebruikers. CI/CD-pipeline logs worden geconfigureerd om alle IaC-implementaties te loggen inclusief wie de implementatie heeft getriggerd, welke wijzigingen zijn doorgevoerd en wanneer de implementatie heeft plaatsgevonden. Deze logs worden bewaard voor compliance-doeleinden en worden gebruikt voor security incident response wanneer wordt onderzocht hoe een beveiligingsincident heeft kunnen plaatsvinden.

Monitoring

Gebruik PowerShell-script infrastructure-as-code-security.ps1 (functie Invoke-Monitoring) – Monitort de status van alle Infrastructure as Code beveiligingscontroles.

Effectieve monitoring van Infrastructure as Code beveiliging in Azure is essentieel om te waarborgen dat alle pijlers correct blijven functioneren en dat bedreigingen tijdig worden gedetecteerd. Monitoring richt zich niet alleen op individuele pijlers, maar vooral ook op de samenhang tussen pijlers en de algehele beveiligingspostuur van IaC-artefacten. In de praktijk betekent dit dat de organisatie een beperkt aantal kernindicatoren definieert – Key Infrastructure as Code Security Indicators (KIaCSI's) – die periodiek worden gemeten en gerapporteerd aan CISO, CIO en bestuur. Voor elke pijler worden specifieke metrics gedefinieerd die aangeven of de pijler effectief functioneert. Voor de secret management-pijler worden metrics gemeten zoals het percentage IaC-bestanden zonder hardcoded secrets, het aantal secrets dat is opgeslagen in Key Vault, het aantal Key Vault access policies met least privilege, het percentage deployments met managed identities, en het aantal gedetecteerde secret exposures in code repositories. Voor de code security scanning-pijler worden metrics gemeten zoals het percentage IaC-bestanden dat is gescand voordat implementatie, het aantal gedetecteerde security issues per severity level, het percentage security issues dat is opgelost binnen acceptabele tijd, het aantal geblokkeerde deployments vanwege security issues, en de gemiddelde tijd tot remediatie van security issues. Voor de supply chain security-pijler worden metrics gemeten zoals het percentage externe modules dat is gescand op kwetsbaarheden, het aantal gedetecteerde kwetsbare dependencies, het percentage modules met signature verification, het aantal gebruikte modules van de whitelist versus niet-whitelisted modules, en het aantal supply chain security incidents. Voor de infrastructure drift detection-pijler worden metrics gemeten zoals het aantal gedetecteerde infrastructure drift-events, het percentage drift-events dat is gecorrigeerd, de gemiddelde tijd tot detectie van drift, het aantal automatische remediation-acties, en het percentage resources dat overeenkomt met IaC-code. Voor de access control-pijler worden metrics gemeten zoals het percentage service principals met least privilege-rechten, het aantal gebruikers met IaC-wijzigingsrechten, het percentage IaC-implementaties met multi-factor authenticatie, het aantal geblokkeerde onbevoegde toegangspogingen, en het percentage pull requests met vereiste approvals. Voor de audit logging-pijler worden metrics gemeten zoals het percentage IaC-implementaties dat is gelogd, het aantal security events dat is gecorreleerd, de gemiddelde tijd tot detectie van security incidents, het percentage logs dat is bewaard voor compliance, en het aantal security incidenten waarbij audit logs zijn gebruikt voor forensics. Een belangrijk onderdeel van monitoring is het creëren van geïntegreerde dashboards die de status van alle IaC-beveiligingspijlers samenbrengen in één overzichtelijk beeld. In plaats van afzonderlijke dashboards per pijler, wordt informatie samengebracht in een centraal IaC security dashboard dat laat zien hoe de verschillende pijlers samenwerken en waar potentiële zwaktes bestaan. Dit dashboard moet niet alleen technische details tonen, maar vooral ook risico-indicatoren die begrijpelijk zijn voor bestuurders en niet-technische stakeholders. Binnen Nederlandse overheidsorganisaties sluit dit aan bij de behoefte aan overzichtelijke rapportages die voldoen aan NIS2- en BIO-verplichtingen voor security reporting. De monitoringfunctie moet ook concrete drempelwaarden en escalatiepaden definiëren. Voor elke KIaCSI wordt vastgelegd bij welke waarde het risiconiveau verandert – bijvoorbeeld van 'aanvaardbaar' naar 'zorgelijk' of 'onacceptabel' – en welke acties dan vereist zijn. Dit kan variëren van het verplicht opstellen van een verbeterplan binnen een maand, via het tijdelijk blokkeren van nieuwe IaC-implementaties die niet voldoen aan beveiligingsstandaarden, tot het escaleren naar de CISO of het bestuurlijke crisisteam bij zeer ernstige afwijkingen. Deze drempelwaarden worden afgestemd op de bestaande risicobereidheid van de organisatie en op wettelijke vereisten vanuit NIS2 en BIO. Tot slot vereist monitoring een nauwe koppeling tussen de dagelijkse operationele securityprocessen – zoals security scanning, secret detection, dependency scanning en incident response – en de meerjarige beveiligingssturing. Operationele teams leveren signalen over concrete incidenten, near misses en ontdekt misbruik van IaC-beveiligingscontroles. Deze signalen moeten systematisch worden geanalyseerd om te bepalen of zij duiden op structurele tekortkomingen in IaC-beveiligingscontroles of de configuratie daarvan. Wanneer bijvoorbeeld meerdere incidenten wijzen op onvoldoende secret management of zwakke code security scanning, moet dit leiden tot een herziening van de relevante beveiligingspijlers en verbetermaatregelen. Het PowerShell-script dat bij dit artikel hoort, kan dienen als technisch hulpmiddel om op vaste momenten kernstatistieken uit Azure op te halen – zoals het percentage IaC-bestanden zonder hardcoded secrets, security scan coverage, infrastructure drift-events en access control compliance – en die als bijlage toe te voegen aan periodieke security rapportages. Zo ontstaat een gesloten feedbacklus tussen monitoring, analyse en bijsturing.

Compliance en Auditing

Infrastructure as Code beveiliging is niet alleen een best practice voor moderne DevOps-werkwijzen, maar een expliciete eis vanuit verschillende nationale en internationale kaders die gelden voor Nederlandse overheidsorganisaties en andere vitale of belangrijke entiteiten. De NIS2-richtlijn verlangt dat organisaties passende technische en organisatorische maatregelen treffen voor risicobeheersing en beveiliging, waarbij wordt benadrukt dat beveiliging moet worden toegepast op basis van risicoanalyse en niet op basis van verondersteld vertrouwen. In de context van Infrastructure as Code betekent dit concreet dat organisaties moeten kunnen aantonen dat zij passende maatregelen hebben getroffen om supply chain-risico's te beheersen, gevoelige informatie te beschermen en infrastructurele wijzigingen traceerbaar te maken. Het hier beschreven IaC-beveiligingsraamwerk levert precies dat aantoonbare spoor: van secret management via code security scanning tot supply chain security en audit logging. Het BIO-raamwerk benadrukt in meerdere thema's – met name thema 5 (Toegangsbeheer), thema 6 (Cryptografie), thema 7 (Logging en monitoring) en thema 12 (Beveiligingsmaatregelen) – dat overheidsorganisaties structureel moeten bepalen welke beveiligingsmaatregelen nodig zijn en hoe deze worden geïmplementeerd en gemonitord op basis van risicoanalyse. In moderne omgevingen worden veel infrastructurele wijzigingen doorgevoerd via Infrastructure as Code, en zonder een specifiek uitgewerkt IaC-beveiligingskader is het vrijwel onmogelijk om aan te tonen dat de BIO-eisen voor risicogebaseerde beveiliging daadwerkelijk zijn ingevuld voor deze workflow. Door IaC-beveiliging te integreren in hetzelfde beveiligingskader en dezelfde governancecyclus als andere IT-diensten, kan de organisatie aan auditors laten zien dat IaC niet als losstaand eiland wordt behandeld, maar als integraal onderdeel van de beveiligingsarchitectuur. Ook de AVG speelt een rol in Infrastructure as Code beveiliging, met name waar het gaat om verwerking van persoonsgegevens in Azure-resources die worden beheerd via IaC. Artikel 32 verplicht organisaties tot het nemen van passende technische en organisatorische maatregelen op basis van een risicoanalyse, waarbij wordt benadrukt dat maatregelen moeten worden gelaagd om verschillende typen bedreigingen te adresseren. In de context van IaC betekent dit onder meer dat men moet beoordelen welke risico's er zijn voor verlies, ongeautoriseerde toegang of onbeschikbaarheid van persoonsgegevens door IaC-specifieke dreigingen zoals secret exposure, misconfiguraties of supply chain-aanvallen, en welke beveiligingsmaatregelen hiervoor zijn gekozen (zoals secret management, code security scanning, supply chain security en access control). Deze keuzes en de onderbouwing ervan moeten worden gedocumenteerd, zodat bij een datalek of audit kan worden aangetoond dat de organisatie weloverwogen en proportionele maatregelen heeft getroffen op basis van risicoanalyse. Auditors – zowel interne auditdiensten als externe toezichthouders – verwachten steeds vaker dat organisaties een consistente methode hanteren voor beveiligingsarchitectuur over alle technologieën heen, inclusief Infrastructure as Code. Het beschreven IaC-beveiligingsraamwerk biedt hiervoor een duidelijke kapstok. Voor auditdoeleinden is het essentieel dat de organisatie kan laten zien dat: er een formeel vastgesteld IaC-beveiligingsbeleid is dat ook voor Azure geldt; alle zes beveiligingspijlers zijn geïmplementeerd en gemonitord; de resultaten zijn vastgelegd in beveiligingsdocumentatie met toegewezen eigenaarschap; en dat uitgevoerde maatregelen en resterende risico's traceerbaar zijn naar concrete besluiten en acties. Het gebruik van gestandaardiseerde formats, centrale opslag van configuraties en systematische koppeling met compliance-dashboards is hierbij onmisbaar. Het PowerShell-script uit dit artikel kan aanvullend worden gebruikt als bron van objectief bewijsmateriaal over de technische inrichting van de Azure-tenant, bijvoorbeeld om te onderbouwen dat er daadwerkelijk IaC-beveiligingscontroles zijn geïmplementeerd en dat deze correct functioneren.

Remediatie

Gebruik PowerShell-script infrastructure-as-code-security.ps1 (functie Invoke-Remediation) – Identificeert en herstelt ontbrekende of zwakke Infrastructure as Code beveiligingscontroles.

Wanneer uit audits, incidenten of periodieke assessments blijkt dat Infrastructure as Code beveiliging onvoldoende is geïmplementeerd of dat bepaalde pijlers zwak zijn, is een gestructureerd remediatieproces noodzakelijk om het beveiligingsniveau snel en gecontroleerd te verhogen. De eerste stap in dit proces is het uitvoeren van een gap-analyse ten opzichte van het gewenste IaC-beveiligingsraamwerk: welke pijlers zijn al aanwezig en correct geconfigureerd, welke pijlers zijn gedeeltelijk geïmplementeerd maar hebben tekortkomingen, en welke pijlers ontbreken volledig? Deze gap-analyse wordt idealiter uitgevoerd door een multidisciplinair team bestaande uit CISO, cloud architect, security engineers, DevOps engineers en vertegenwoordigers uit de business. Het resultaat is een overzicht van concrete tekortkomingen per beveiligingspijler, geprioriteerd op basis van risico en compliance-impact. Vervolgens wordt per tekortkoming een gerichte remediatiestrategie bepaald. Ontbreekt bijvoorbeeld de secret management-pijler volledig, dan is de remediatie het inrichten van een project waarin alle hardcoded secrets worden geïdentificeerd, verplaatst naar Azure Key Vault, en IaC-code wordt bijgewerkt om Key Vault-references te gebruiken. Is de code security scanning-pijler gedeeltelijk aanwezig maar ontbreekt integratie in CI/CD-pipelines, dan ligt de nadruk op het configureren van security scanning-tools in pipelines en het blokkeren van deployments wanneer kritieke security issues worden gedetecteerd. In situaties waarin meerdere pijlers zwak zijn – wat zeker bij versneld gecreëerde IaC-omgevingen vaak voorkomt – moet een gefaseerde aanpak worden gevolgd waarbij eerst de fundamenten (secret management en code security scanning) worden versterkt, gevolgd door supply chain security en infrastructure drift detection, en tot slot access control en audit logging. Een belangrijk remediatiepad betreft het herstellen van ontbrekende of zwakke secret management. Wanneer de eerste pijler onvoldoende is geïmplementeerd, kunnen IaC-bestanden hardcoded secrets bevatten die worden blootgesteld in versiebeheersystemen, wat kan leiden tot credential compromise en volledige compromittering van Azure-omgevingen. Remediatie betekent in dit geval het uitvoeren van een volledige audit van alle IaC-artefacten om hardcoded secrets te identificeren, het migreren van alle secrets naar Azure Key Vault, het bijwerken van IaC-code om Key Vault-references te gebruiken, en het opstellen van procedures om te voorkomen dat nieuwe secrets in code worden opgeslagen. Zonder adequate secret management blijven organisaties kwetsbaar voor credential exposure en kunnen zij niet aantonen dat gevoelige informatie adequaat wordt beschermd. Technisch gezien kan remediatie ook bestaan uit het herstructureren van IaC-workflows om beveiligingscontroles beter te kunnen afdwingen. Denk aan het centraliseren van secret management via een gedeelde Key Vault, het implementeren van mandatory security scanning in alle CI/CD-pipelines, of het opzetten van een private module registry voor het hosten van interne IaC-modules. Deze stappen moeten altijd worden uitgevoerd op basis van een gedetailleerd migratieplan, inclusief impactanalyse, fallbackscenario's en communicatie met betrokken teams. IaC-beveiliging betekent in dit verband dat herstructurering niet alleen wordt bekeken vanuit technische optimalisatie, maar vooral vanuit de vraag: vergroot dit de beveiliging op basis van secret management, code security scanning, supply chain security, infrastructure drift detection, access control en audit logging? Tot slot moet elke remediatie-inspanning worden afgesloten met een expliciete evaluatie en bijstelling van het IaC-beveiligingsraamwerk. De lessen uit incidenten en audits – bijvoorbeeld een succesvolle aanval die meerdere pijlers heeft doorbroken of onvoldoende detectie van secret exposures – moeten structureel worden verwerkt in de beveiligingsarchitectuur, configuraties en procedures. Het is raadzaam om na afronding van een remediatieprogramma een integrale security assessment te laten uitvoeren door een interne auditdienst of een onafhankelijke derde, zodat kan worden vastgesteld of het nieuwe niveau van IaC-beveiliging daadwerkelijk in lijn is met NIS2, BIO en de verwachtingen van het bestuur. De uitkomsten hiervan worden vastgelegd in beveiligingsdocumentatie en vormen het nieuwe vertrekpunt voor de reguliere cyclus van monitoring en verbetering.

Compliance & Frameworks

• BIO: 5.01.01, 6.01.01, 7.01.01, 12.01.01 - Risicogebaseerde beveiliging met Infrastructure as Code beveiligingscontroles voor Azure-omgevingen
• ISO 27001:2022: A.9.1.1, A.9.2.1, A.12.1.1, A.12.2.1, A.14.2.1 - Access control, network security, operations security, information security management en secure development met Infrastructure as Code principes
• NIS2: Artikel - Passende technische en organisatorische maatregelen voor risicobeheersing en beveiliging op basis van risicoanalyse voor Infrastructure as Code workflows, inclusief supply chain security

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

Implementeer Infrastructure as Code beveiliging met zes pijlers: secret management, code security scanning, supply chain security, infrastructure drift detection, access control en audit logging. Essentieel voor NIS2 en BIO compliance. Implementatie: 180 uur.

• Implementatietijd: 180 uur
• FTE required: 1 FTE