IaC-scannen: een fantastische, over het hoofd geziene leermogelijkheid

Alles wat u leest over infrastructuur als code (IaC) is gericht op hoe het werkt of waarom u er zeker van wilt zijn dat het daadwerkelijk wordt gebouwd zoals u dat wilt.

Dit zijn kritieke gebieden. Maar denken we wel voldoende na over hoe we deze aanpak in onze organisatie inzetten?

As Melinda Merken Uit een bedrijfsrapport van ESG blijkt dat “83% van de organisaties een toename van misconfiguraties van IaC-sjablonen ervoer” naarmate ze de technologie bleven adopteren.

We weten uit werk van de Cloud Security Alliance (“Belangrijkste bedreigingen voor cloud computing: flagrante elf“) en anderen blijven verkeerde configuraties een groot risico in de cloud.

IaC wordt ondersteund verminderen
misconfiguraties door het creëren van infrastructuur te systematiseren en een niveau van nauwkeurigheid en proces toe te voegen dat ervoor zorgt dat teams bouwen wat ze willen en alleen wat ze willen. Als ~83% van de teams dat niet ziet, is er een dieper probleem aan de hand.

Bij kleinere teams, een team waarin de Dev- en Ops-delen van de DevOps-filosofie samenkomen, is dat logisch. Dankzij IaC kunnen deze kleine teams dezelfde taal (code) gebruiken om alles wat ze doen te beschrijven.

Dit is de reden waarom we abstracties op een nog hoger niveau zien dan tools als Terraform of AWS CloudFormation in de AWS CDK en projecten zoals cdk8s. Deze abstracties op hoog niveau zijn comfortabeler voor ontwikkelaars.

Een ops/SRE/platformperspectief van een cloudservice zal heel anders zijn dan het ontwikkelaarsperspectief van dezelfde service. Een ontwikkelaar kijkt naar een wachtrijservice en duikt in de interface ervan: een eenvoudig eindpunt om toe te voegen en een om te lezen? Verkocht. Dat is een gemakkelijke integratie.

Dit operationele perspectief is erop gericht de randen op te zoeken. Wanneer bereikt deze wachtrij zijn limiet? Zijn de prestaties constant of veranderen deze radicaal onder belasting?

Ja, er zijn overlappende zorgen. En ja, dit is een vereenvoudigde weergave. Maar het idee houdt stand. IaC lost veel problemen op, maar kan ook de kloof tussen teams creëren en versterken. Belangrijker nog is dat het de kloof kan benadrukken tussen de intentie van wat je probeert op te bouwen en de realiteit van wat je hebt opgebouwd.

Als gevolg hiervan escaleren de veiligheidsproblemen vaak.

De meeste tooling – commercieel of open source – is gericht op het identificeren van dingen die mis zijn met de infrastructuursjablonen. Deze
is een goede constructie. Maken dit
zou slecht zijn. Deze tools zijn bedoeld om deze resultaten te genereren als onderdeel van de pijplijn voor continue integratie/continue levering (CI/CD).

Dat is een goed begin. Maar het weerspiegelt hetzelfde taalprobleem.

Wie praat en wie luistert?

Wanneer een IaC-tool een probleem benadrukt, wie zal dit dan aanpakken? Als het het ontwikkelingsteam is, beschikt het dan over voldoende informatie om te weten waarom dit als een probleem is gemarkeerd? Als het het operationele team betreft, worden de gevolgen van het probleem dan uiteengezet in het rapport?

Wat ontwikkelaars vaak overkomen, is dat ze eenvoudigweg de configuratie aanpassen om de IaC-tests te laten slagen.

Voor operaties is het meestal een kwestie van of de tests slagen. Als dat zo is, ga dan door naar de volgende taak. Dat is voor geen van beide teams een klap; het benadrukt eerder de kloof tussen verwachtingen en realiteit.

Wat nodig is, is context. IaC-beveiligingstools bieden inzicht in wat er (hopelijk) gaat worden gebouwd. Het doel is om problemen te stoppen vaardigheden ze gaan in productie.

De huidige IaC-beveiligingstools benadrukken echte problemen die moeten worden aangepakt. Het nemen van de output van deze tools en het verrijken ervan met extra context die specifiek is voor het team dat verantwoordelijk is voor de code, is een perfecte gelegenheid voor enige aangepaste automatisering.

Dit zal ook helpen de taalkloof te overbruggen. De output van uw tooling is in wezen in een derde taal – om de zaken nog ingewikkelder te maken – en moet worden gecommuniceerd op een manier die zinvol is voor zowel een ontwikkelings- als een operationeel publiek. Vaak allebei.

Als een scan bijvoorbeeld aangeeft dat een beveiligingsgroepregel geen beschrijving heeft, waarom doet dat er dan toe? Alleen al het ontvangen van een waarschuwing met de tekst 'Voeg een beschrijving voor context toe' helpt niemand om beter te bouwen.

Dit type vlag is een geweldige kans om de teams die in de cloud bouwen te informeren. Het toevoegen van een uitleg dat de regels voor beveiligingsgroepen zo specifiek mogelijk moeten zijn, verkleint de kans op kwaadwillige aanvallen. Geef verwijzingen naar voorbeelden van sterke regels. Roep dat op zonder de bedoeling te kennen, en andere teams kunnen de geldigheid van de beveiligingsbevestiging niet testen.

Beveiliging is de verantwoordelijkheid van iedereen, dus het erkennen van de taalkloof tussen ontwikkelaars en operaties zal kansen als deze benadrukken om eenvoudige automatiseringen toe te voegen die inzichten bieden aan uw teams. Dit zal helpen bij het verbeteren van wat ze bouwen en zal als gevolg daarvan betere beveiligingsresultaten opleveren.

Over de auteur

Ik ben een forensisch wetenschapper, spreker en technologieanalist en probeer u te helpen de digitale wereld en de impact ervan op ons te begrijpen. Voor gewone gebruikers helpt mijn werk uit te leggen wat de uitdagingen van de digitale wereld zijn. Hoe groot is de impact van het gebruik van sociale media op uw privacy? Wat betekent het als technologieën zoals gezichtsherkenning in onze gemeenschappen worden gebruikt? Ik help vragen als deze en meer te beantwoorden. Voor mensen die technologie bouwen, help ik hen een beveiligings- en privacylens op hun werk toe te passen, zodat ze gebruikers in staat kunnen stellen duidelijkere beslissingen te nemen over hun informatie en gedrag. Er bestaat een berg verwarring als het gaat om privacy en veiligheid. Dat zou niet zo moeten zijn. Ik maak beveiliging en privacy begrijpelijker.