Infrastructure as Code Security: continuous security

Met Infrastructure as Code schrijf je alle configuraties voor de infrastructuur uit in code. De technologie maakt het mogelijk om infrastructuur te beheren en faciliteren door middel van code. Het idee erachter: een betrouwbare, consistente manier om infrastructuur te bouwen en deployen, ook in dynamische omgevingen zoals Kubernetes. De infrastructuur is makkelijk omkeerbaar en herleidbaar als er zich problemen voordoen. Alle configuraties staan in YAML files, in plaats van in de software zelf. Het scheelt tijd en vermindert de kans op fouten die de productie-omgeving kunnen verstoren of de veiligheid schaden. De technologie sluit naadloos aan bij DevOps-werkwijzes, zoals versiecontrole, geautomatiseerd testen en CI/CD pipelines. Voor Infrastructure as Code zijn meerdere tools beschikbaar, zoals HashiCorp Terraform en Pulumi.

• IaC vergroot de betrouwbaarheid van een infrastructuur, zeker als deze omvangrijk is. Bij een complexe of uitgebreide infrastructuur vormen misconfiguraties of services in de verkeerde volgorde faciliteren, een risico. IaC automatiseert de infrastructuur en zorgt – mits goed gecodeerd – voor de juiste volgorde en configuraties.
• Infrastructuur wordt gestandaardiseerd, waarbij de gewenste staat in code staat voor perfecte schaalbaarheid en herhaalbaarheid. Versiecontrole in Git geeft direct de versiegeschiedenis weer van de infrastructuur, net als dat het met applicatie code doet.
• De automatische aanpak levert snelheid en tijdwinst op in vergelijking met handmatig aanpassen van configuraties. Ook een nieuwe infrastructuur is sneller opgezet en experimenten zijn eenvoudiger uit te voeren, zonder dat het veel tijd of resources vraagt.
• Efficiëntie door de mogelijkheden van continous deployments uit te breiden door management van resources zelf.

Net als bij elk ander nieuw proces, komen er bij Infrastructure as Code uitdagingen kijken. Omdat het relatief nieuw is, is het een uitdaging om het in bestaande infrastructuur te hangen. In die overgangsfase kan het onduidelijk zijn hoe en waar resources staan en op welke manier security wordt geïntegreerd. Daarnaast zal de Infrastructure as Code een single source of truth moeten worden. Zijn er wijzigingen handmatig of los van IaC gemaakt, dan kan er verschil in komen in de infrastructuur in omgevingen versus de gecodeerde configuraties. Deze ‘drift’ kan leiden tot misconfiguraties en vormt daarmee risico’s voor de veiligheid van de onderliggende infrastructuur.

Het zijn precies die misconfiguraties die de grootste oorzaak van datalekken in de cloud zijn. Zodra ze bekend zijn, levert het extra werk op om misconfiguraties in de productie-omgeving aan te pakken, te onderzoeken en een fix te implementeren. Deze uitdaging is aan te gaan door security eerder in het traject aan te pakken, een shift left.

Kwetsbaarheden en misconfiguraties fixen vóórdat het naar productie gaat, scheelt een hoop werk (en kopzorgen). Maar security kan nóg een stap eerder in het traject, al bij het opzetten van cloud infrastructuur. Infrastructure as Code Security geeft je de mogelijkheid om security policies in de configuratie van de infrastructuur te zetten.

Je beveiligt je cloud infrastructuur en app configuraties door bestanden en deployments te scannen tegen een vaste set van (beleids)eisen en security best practices. Best practices gaan dan bijvoorbeeld over het principe van zo min mogelijk rechten, netwerk segmentatie van resources en dependencies, en encrypte van data in gebruik en opgeslagen data. Security-as-code opnemen draagt bij aan minimalisatie van menselijke security fouten in configuraties. Het is een nauwe samenwerking tussen DevOps en Security team(s).

Onder meer Terraform biedt de mogelijkheid om met TFsec naar situaties in de code te kijken die bekend staan als potentieel risico (bijvoorbeeld check van wachtwoorden en toegangsrechten) en naar standaard situaties (bijvoorbeeld scannen van images op kwetsbaarheden).

💡 Lees ook Terraform: de tool voor de gewenste infrastructuur als code

Hoe kun je de uitdaging van Infrastructure as Code Security aangaan? Automatiseer en neem security mee in elk deel van het traject, van zowel IDE scanning tot de uiteindelijke deployment.

Engineers en developers zijn al jaren gewend aan test automation voor websites en applicaties, van unit testing tot scannen op afhankelijkheden. Voor cloud security kan hetzelfde! Het is meer dan een fulltime job om elke individuele security best practice voor je infrastructuur te weten en het dan ook in de architectuur toe te passen.

Geautomatiseerd scannen voegt zekerheden toe zonder dat het meer tijd of middelen kost. Maar: zonder praktisch uitvoerbare feedback leidt automation juist tot meer werk en frictie tussen development, operations en security. Stel automation samen zo in dat het tot werkbare feedback leidt waar developer en (security) engineers mee aan de slag kunnen.

• IDE scanning

Het ideaal van security eerder in het traject: zo snel mogelijk alerts en feedback krijgen over mogelijke issues. Waar is dat beter dan op het moment van programmeren zelf? Met IDE scanning is het mogelijk om al in de Integrated Development Environment mogelijke issues aan te wijzen, zonder van context te hoeven switchen.

• CI/CD pipelines

Vervolgens komt security testing weer kijken bij de Continuous Integration / Continuous Delivery (CI / CD) pipelines, vóór deployments. Hier is het mogelijk om misconfiguraties in core resources, variabelen en afhankelijke modules te spotten. Daarnaast is het mogelijk om security in geautomatiseerde pipelines te zetten, waardoor dat minder werk en meer scanning oplevert. Je bepaalt er precies welke checks moeten worden uitgevoerd en op welke manier feedback terug moet komen.

• Pull/merge request checks

Als derde stap is het mogelijk om via je versiecontrole-systeem (zoals GitLab) security checks voor gebruikte infrastructuur in te bouwen. Tip: blokkeer een merge met de master branche als een check faalt, zodat een misconfiguratie daar niet belandt.

Komen er dan ook bij de daadwerkelijke deployment via een CI/CD pipeline geen issues naar voren, dan is het tijd voor security in runtime.

• Security in runtime

Alle checks en security testen kunnen dan nog zoveel eruit halen, helemaal waterdicht wordt het niet. Security checks in runtime op de infrastructuur blijven nodig. Handmatige aanpassingen kunnen nog steeds voorkomen, met ‘drift’ als gevolg.

In deze blog hebben we laten zien welke uitdaging security vormt voor infrastructure as code en op welke manier je security mee kunt nemen. Wil je meer weten of wil je security-as-code met een ervaren partner oppakken? Engineers van True denken graag met je mee. Neem contact met ons op voor meer informatie.