Beveiligingsscanning van Infrastructure as Code

Tools voor Infrastructure as Code (IaC), zoals Terraform, AWS CloudFormation, Ansible en Helm, maken het mogelijk om infrastructuur te definiëren in configuratiebestanden die onder versiebeheer staan. Dit biedt enorme voordelen — herhaalbaarheid, controleerbaarheid en automatisering — maar ook een kritiek beveiligingsrisico: verkeerde configuraties in IaC-bestanden produceren op grote schaal onveilige infrastructuur. Eén verkeerd geconfigureerde Terraform-module die in 50 omgevingen wordt geïmplementeerd, creëert gelijktijdig 50 kwetsbare systemen. Scannen van IaC op beveiliging pakt dit aan door configuratiebestanden te controleren voordat ze worden toegepast, waardoor beveiliging naar voren wordt verschoven in de ontwikkelworkflow.

Beveiligingsscantools zoeken naar de meest voorkomende verkeerde IaC-configuraties in echte cloudomgevingen: S3-buckets met ingeschakelde openbare toegang of zonder versleuteling van opgeslagen gegevens; beveiligingsgroepen met inkomende regels met 0.0.0.0/0 op gevoelige poorten (22, 3389, 1433); databases zonder versleuteling of met openbare toegankelijkheid; IAM-beleidsregels met jokertekens voor resources of acties, zoals *; CloudTrail uitgeschakeld in een regio; KMS-sleutels zonder sleutelrotatie; en load balancers met HTTP-luisteraars in plaats van HTTPS. Deze bevindingen komen sterk overeen met de controles van beveiligingsbenchmarks voor clouds, zoals CIS AWS Foundations.

Checkov (van Bridgecrew/Prisma Cloud) is een populaire opensource-tool voor statische analyse van IaC die Terraform, CloudFormation, Kubernetes-manifesten, Helm-grafieken en Dockerfiles ondersteunt. De tool wordt geleverd met meer dan 1.000 ingebouwde beleidsregels die zijn gekoppeld aan CIS-benchmarks, GDPR, SOC 2 en HIPAA. Met checkov -d . scan je alle IaC-bestanden in de huidige map en genereer je een rapport met kleurcodering van geslaagde, mislukte en overgeslagen controles, inclusief resourcepaden en advies voor herstel. Checkov kan worden geïntegreerd in CI/CD-pijplijnen om implementaties te blokkeren wanneer kritieke controles mislukken.

tfsec (nu onderdeel van de IaC-scanmogelijkheid van Trivy) is een speciaal ontwikkelde beveiligingsscanner voor Terraform die de HCL-syntaxis diepgaand begrijpt, zodat waarden in modules en variabelebestanden kunnen worden gevolgd. In tegenstelling tot eenvoudigere scanners kan tfsec verkeerde configuraties detecteren waarbij het probleem meerdere bestanden omvat — bijvoorbeeld een regel voor een beveiligingsgroep die op zichzelf veilig lijkt, maar is gekoppeld aan een resource in een ander bestand. tfsec genereert bevindingen met ernstniveaus (CRITICAL, HIGH, MEDIUM, LOW), CWE-ID's en directe koppelingen naar documentatie over herstel, zodat ontwikkelaars er direct mee aan de slag kunnen.

Een van de meest kritieke beveiligingsproblemen in IaC zijn hardgecodeerde geheimen in configuratiebestanden — wachtwoorden, API-sleutels, TLS-privésleutels en verbindingsreeksen voor databases die naar Git zijn vastgelegd. Omdat IaC-opslagplaatsen vaak worden gedeeld tussen teams en in de geschiedenis van versiebeheer worden opgeslagen, is een geheim dat zelfs maar één keer is vastgelegd feitelijk permanent gecompromitteerd (de Git-geschiedenis is onveranderlijk). Tools zoals Checkov, detect-secrets, git-secrets en TruffleHog zoeken naar patronen van geheimen. De oplossing is het gebruik van invoervariabelen die verwijzen naar omgevingsvariabelen of geheimenopslagplaatsen; hardgecodeerde waarden gebruik je nooit.

Frameworks voor beleid als code (PaC) stellen beveiligingsteams in staat om aangepaste regels in code te schrijven en deze consistent af te dwingen. Met Open Policy Agent (OPA) en Conftest kun je Rego-beleidsregels schrijven die alle gestructureerde gegevens valideren — Terraform-plannen, Kubernetes-manifesten en Helm-waarden — in CI/CD-pijplijnen. HashiCorp Sentinel is ingebouwd in Terraform Enterprise en Cloud, zodat beleidsregels zoals 'alle S3-buckets moeten versleuteling ingeschakeld hebben' tijdens het plannen kunnen worden afgedwongen. Elke apply die het beleid zou overtreden, wordt dan geblokkeerd. Met deze tools kun je beveiligingsvereisten vastleggen in code en samen met de infrastructuur waarop ze van toepassing zijn onder versiebeheer plaatsen.

Er is sprake van configuratieafwijking wanneer de werkelijke toestand van geïmplementeerde infrastructuur afwijkt van de IaC-definitie — vaak doordat iemand handmatig een wijziging heeft aangebracht via de cloudconsole. Een regel voor een beveiligingsgroep die handmatig is toegevoegd om een ontwikkelaar 'tijdelijk' toegang te geven, wordt zo een permanent beveiligingslek. Tools voor detectie van afwijkingen vergelijken voortdurend de gewenste toestand (IaC-bestanden) met de werkelijke geïmplementeerde toestand en waarschuwen bij afwijkingen. AWS Config, de detectie van afwijkingen in Terraform Cloud en CSPM-tools (Prisma Cloud, Wiz) bieden deze mogelijkheid. Verkeerde beveiligingsconfiguraties die via consolewijzigingen zijn geïntroduceerd, worden onderschept voordat aanvallers ze ontdekken.

Onveranderlijke infrastructuur betekent dat servers en configuraties nooit ter plaatse worden gewijzigd. In plaats daarvan creëren wijzigingen nieuwe resources (nieuwe AMI's, nieuwe containerimages) en vervangen ze de oude. In combinatie met GitOps (waarbij alle infrastructuurwijzigingen via een Git-pullrequest moeten verlopen, wat IaC-scans en goedkeuringsprocessen activeert) elimineert dit configuratieafwijkingen vanaf het ontwerp: als iets niet handmatig kan worden gewijzigd, kan het ook niet afwijken. Tools zoals ArgoCD voor Kubernetes en Atlantis voor Terraform implementeren GitOps-processen waarbij elke afwijking automatisch herstel of een waarschuwing activeert.

Beveiligingsscans van IaC worden soms verward met SAST (statische beveiligingstests voor toepassingen), maar ze richten zich op verschillende artefacten. SAST analyseert broncode van toepassingen (Python, Java, JavaScript) op kwetsbaarheden zoals SQL-injectie of bufferoverflows. IaC-scans analyseren configuratiebestanden van infrastructuur op verkeerde configuraties in cloudbeveiliging — er komt geen toepassingscode aan te pas. Een volledige DevSecOps-pijplijn bevat beide: SAST voor toepassingscode en IaC-scans voor infrastructuurbestanden. Beide worden in CI/CD uitgevoerd voordat er iets wordt geïmplementeerd. Sommige geïntegreerde platforms (Snyk IaC, Prisma Cloud) combineren scans van toepassingen en infrastructuur in één tool.

Effectieve beveiligingsscans van IaC moeten geautomatiseerd en verplicht zijn — niet optioneel. Een gebruikelijke CI/CD-integratie werkt als volgt: voer bij elke pullrequest Checkov en tfsec uit; laat de pijplijn mislukken als er bevindingen met de ernst CRITICAL zijn; plaats bevindingen als opmerkingen bij de pullrequest zodat ontwikkelaars ze kunnen zien; houd een lijst bij van onderdrukte bevindingen met gedocumenteerde rechtvaardigingen; en voer elke nacht een scan uit op geïmplementeerde resources om afwijkingen te detecteren. Hooks vóór het vastleggen met tools zoals pre-commit en Checkov kunnen problemen al onderscheppen voordat code de pijplijn bereikt. Beheer van fout-positieven is belangrijk: ontwikkelaars die te veel irrelevante bevindingen zien, gaan ze uiteindelijk negeren.

Het statusbestand van Terraform (terraform.tfstate) bevat de volledige inventaris van alle beheerde resources en vaak ook gevoelige uitvoerwaarden, zoals databasewachtwoorden, TLS-privésleutels en ID's van IAM-toegangssleutels, in platte tekst. Statusbestanden mogen nooit naar Git worden vastgelegd. Gebruik in plaats daarvan een externe backend (AWS S3 met vergrendeling via DynamoDB, Terraform Cloud of door GitLab beheerde status) met versleuteling aan de serverzijde ingeschakeld. Toegang tot de statusbackend moet strikt worden beheerd via IAM — iedereen die het statusbestand kan lezen, kan alle infrastructuurdetails inventariseren en mogelijk ingebedde geheimen achterhalen.

In deze les heb je geleerd dat verkeerde configuraties in IaC, zoals openbare S3-buckets, opengestelde beveiligingsgroepen en hardgecodeerde geheimen, vóór implementatie automatisch worden gedetecteerd door tools zoals Checkov en tfsec; dat frameworks voor beleid als code (OPA/Conftest, HashiCorp Sentinel) aangepaste beveiligingsvereisten van de organisatie kunnen afdwingen als geautomatiseerde poorten in de pijplijn; en dat Terraform-statusbestanden moeten worden opgeslagen in versleutelde externe backends met strikte toegangscontroles, omdat ze gevoelige resourcedetails kunnen bevatten. Hierna verkennen we de levenscyclus van APT's en hoe geavanceerde dreigingen zich binnen netwerken handhaven.