Cloud-native-applicaties bevatten infrastructure-as-code (in het kort iac) die bepalen hoe applicaties werken binnen een cloud-infrastructuur en hoe gecontaineriseerde applicaties op Kubernetes draaien. Iac betekent snellere, herhaalbare implementaties, maar verhoogt tegelijkertijd de druk voor ontwikkelaars om niet alleen hun code te beveiligen, maar ook de infrastructuurconfiguratie, code-afhankelijkheden en containers.
Organisaties hebben nog niet dé manier gevonden van iac-gebruik en bepaalt wie verantwoordelijk is voor het schrijven en onderhoud ervan. Uit recent onderzoek blijkt echter dat de personen die geautomatiseerde securitytesten voor hun iac-definities gebruiken, verkeerde configuraties sneller vinden en oplossen. Deze high-performers vinden en repareren binnen een dag problemen in hun iac-definities; terwijl collega’s hier meer dan een week over doen.
De voordelen op het gebied van snelheid en betrouwbaarheid zijn groot wanneer alles in code en geautomatiseerd is, maar zorgt zoals gezegd voor een toenemende druk op ontwikkelaars om meer dan alleen hun eigen code te beveiligen. Veel bedrijven zijn pas net met iac begonnen: twee derde begint de technologie net te verkennen en slechts zeven procent geeft aan dat ze iac hebben geïmplementeerd volgens de huidige mogelijkheden van de sector. Hoewel er veel tools in gebruik zijn, standaardiseert 71 procent liever een gemeenschappelijke toolset/workflow voor alle iac-configuratietypen en -formats.
Security vaak op de achterbank
Moderne applicaties worden vaak automatisch geïmplementeerd op infrastructuur die is gemaakt en geconfigureerd via code. Hierdoor zit security vaak op de achterbank bij een snelle implementatie en worden configuratieproblemen pas na implementatie ontdekt. Gartner stelt zelfs dat tegen 2025 zeventig procent van de aanvallen op containers het gevolg zijn van bekende kwetsbaarheden en verkeerde configuraties die verholpen hadden kunnen worden.
Dit betekent niet dat snelheid altijd risicovol is. Geautomatiseerde test- en releasegates kunnen voor andere vormen van code worden gebruikt met iac en helpen om best practices op het gebied van security onderdeel te maken van het ontwikkel- en releaseproces. Qua security staat dit type geautomatiseerd testen echter nog in de kinderschoenen. Zo’n zestig procent van de organisaties zegt dat hun huidige workflow voor iac en configuratiecode continue integratietests (ci) doorloopt, maar slechts een derde neemt securitycontroles op in hun pijplijn.
De meeste securityproblemen worden ontdekt na implementatie, doorgaans na penetratietesten, audits en het onderzoeken van incidenten. Bij bedrijven die controles na de implementatie uitvoeren, duurt het in de helft van de gevallen minimaal een week om een securityprobleem te ontdekken en in bijna twee derde van de gevallen meer dan een dag om die op te lossen. Zij hebben acht dagen langer een securityprobleem dan de beste performers die vaak binnen een dag een probleem ontdekken en oplossen.
De grootste uitdaging voor respondenten die ci-tests gebruiken, is de integratie van securitycontroles door een gebrek aan gestandaardiseerde best practices over wat ze moeten controleren. Teams nemen nu vaak hun eigen beslissing over wat ze moeten testen. Als je dat koppelt aan de 41 procent die zegt dat onduidelijke benchmarks een grote barrière voor security is, moeten we betere tools inzetten die duidelijke begeleiding bieden terwijl teams de vrijheid behouden om te bepalen wat voor hen het belangrijkst is.
Stukje van de puzzel
Het vinden van het probleem is een stukje van de puzzel. Zodra een probleem is ontdekt, moet iemand het oplossen. Als ze de keuze hebben, beweert iets meer dan de helft van de respondenten dat ze een securityprobleem meestal oplossen door de infrastructuur rechtstreeks aan te passen in plaats van de iac-broncode. Dit kan voor problemen op de lange termijn zorgen, omdat de gewijzigde infrastructuur bij de volgende implementatie is te resetten naar de verkeerd geconfigureerde staat. Respondenten die handmatig herstellen, zeggen dat dit komt door een gebrek aan standaardisatie, kennis en communicatie, maar ook omdat ze reparaties zo snel mogelijk willen uitvoeren.
Een van de barrières voor het verschuiven van iac-security naar links, was dat teams moeite hadden met standaardisatie in hun organisatie, waardoor elk team iac op een eigen manier controleert. Naast de voor de hand liggende securityproblemen die dit meebrengt, laat dit een gat in verantwoordelijkheid zien.
Devsecops-modellen
Er lijkt geen consensus over wie verantwoordelijk is voor security van cloud-infrastructuur. Ontwikkelaars en devops-rollen hebben een iets grotere rol dan andere teams. Veel respondenten vinden security een gedeelde verantwoordelijkheid, mogelijk passend bij de nieuwere devsecops-modellen. Als iac-security geen gedeelde verantwoordelijkheid mag zijn, kiest het merendeel van de respondenten voor ontwikkelaars en devops-teams. De reden dat securityverantwoordelijkheden niet verder naar links verschuiven is het vertrouwen in het vermogen van de organisatie om problemen in de code snel te herkennen en op te lossen.
Een schaalbare oplossing voor iac-securityuitdagingen is het investeren in de tools en training die nodig zijn om het vertrouwen en de reikwijdte van teams te vergroten en ervoor te zorgen dat zij code snel en veilig kunnen implementeren. Gartner ziet ook het potentieel van deze geautomatiseerde tools en voorspelt dat organisaties tegen 2025 hun herstel van codekwetsbaarheden met een derde zullen versnellen met codesuggesties die worden toegepast vanuit geautomatiseerde oplossingen, waardoor ze de helft minder tijd besteden aan het oplossen van bugs.
“Uit recent onderzoek blijkt echter dat de personen die geautomatiseerde securitytesten voor hun iac-definities gebruiken, verkeerde configuraties sneller vinden en oplossen.”
Klinkt als dagelijks beheer waarbij je uitgaat van een valide configuratie op basis van best practices voor de ‘hardening’ van het systeem. De geautomatiseerde zoektocht naar ongeautoriseerde wijzigingen in het configuratie management kan ingevuld worden met scripts. Uiteraard zullen ‘high-performers’ in het beheer dan wel up-to-date moeten blijven aangaande het dreigingsbeeld zodat de templates e.d. voorzien worden van de laatste stand van beveiliging, lees de meest recente firmware, drivers en patches. En de meeste securityproblemen worden inderdaad ontdekt na implementatie, doorgaans na de (penetratie)testen die nog weleens achterwege gelaten worden omdat de time-to-market belangrijker is dan de veiligheid. En daarom lezen we in de audits na onderzoeken van de incidenten (lees datalekken) weer de gebruikelijke excuses dat er geen consensus is over wie er verantwoordelijk is voor de security van de infrastructuur omdat de techniek uitbesteed is.
De cloud is dan ook echt een zegen want het knuffelen van de infrastructuur door deze rechtstreeks aan te passen in plaats van workarounds middels iac-broncode is een optie die je door de uitbesteding van de techniek niet hebt omdat de verantwoordelijkheid voor de infrastructuur bij de provider ligt. En of de provider ‘high-performers’ in het beheer heeft is afhankelijk van het contract, maatwerk kost geld want het verdienmodel van de cloud gaat om standarisatie van de infrastructuur zodat deze gedeeld kan worden met meerdere tenants. Contractuele exoneratieclausule leggen het risico van afwijking op de norm terug bij de afnemer, de juridische jungle van uitbesteding heeft dan ook niks met de techniek van de cloud te maken maar met het maken van de juiste afspraken over het beheer.
Het gat van verantwoordelijkheid is veelal organisatorisch en kun je niet dichten met tools, hieraan is sowieso geen gebrek alleen blijken velen niet in staat om de juiste vertaling te maken. Want de andere veel gehoorde klacht gaat namelijk over de inschatting van de risico’s. Formule waarin kans van optreden met de mate van impact gecombineerd wordt betekent dat je een inzicht moet hebben in het dreigingsbeeld en weet welke schade er veroorzaakt kan worden. Deze ‘doemdenkers’ zijn over het algemeen niet populair bij de opportunistische business die in alles een kans ziet.
mooi artikel, met de gebruikelijke definitie misverstanden.
“Er lijkt geen consensus over wie verantwoordelijk is voor security van cloud-infrastructuur.”
shared responsibility misschien, maar tussen wie dan.
dev en ops, ook beetje vreemd want wat is dan devops team ? cloud lerancier en afnemer dan ? Dat sowieso want volgens bijv AWS :
AWS responsibility “Security of the Cloud”
Customer responsibility “Security in the Cloud”
en is devops nou het automatiseren van je dev pipelines of het automatiseren van je infrastructure middels code.
“Een van de barrières voor het verschuiven van iac-security naar links, was dat teams moeite hadden met standaardisatie in hun organisatie, waardoor elk team iac op een eigen manier controleert.” Dat helpt ook niet echt, met die zelfsturende teams 😛
Ook leuk dat zoveel respondenten beweren dat ze een “securityprobleem meestal oplossen door de infrastructuur rechtstreeks aan te passen in plaats van de iac-broncode”. Handig, kunnen die high perfomers 7 maal sneller onveilige infra uitrollen dan hun langzamere collega’s.
Niet zo gek als de security meestal toch al niet in de IAC wordt meenomen.
Die https://nl.wikipedia.org/wiki/Zevenmijlslaarzen moet je misschien ook maar wat met een korrel zout nemen. Al wordt er vaak over gesproken, volgens wikipedia alleen in sprookjes.
Ewouts reactie brengt ook geen helderheid.
De term workaround gebruiken voor het configureren van infrastructure via code.
En dat je dat in de cloud niet zou hebben, omdat daar alles in code moet.
Je kunt prima je on-prem volledig in code opbouwen en in de cloud alles aan mekaar clicken en interactief configureren via cli.
En welk deel is nou met IaaS uitbesteed aan de provider.. De firmware bijv of de ILO en fysieke toegang, maar het veilig configureren van je VMs in de cloud blijft toch echt je eigen verantwoording.
Automatisering is te ingewikkeld om allemaal te doorgronden dus uiteindelijk gaat het om vertrouwen.
– uitbesteden lijkt niet echt de oplossing zoals we wekelijks in computable lezen
– je eigen beheerders dan? nee, die zijn nog nooit door iemand vertrouwd
– de zogenaamd onafhankelijk adviseur dan, verassend vaak zeggen die over gratis diensten dat de klant het product is en ze adviseren altijd onafhankelijk zichzelf
De adviseur die zo graag zijn hybride cloud oplossing verkoopt, terwijl zoveel situaties niet vragen om elasticiteit. “Ik ben eerlijk, elke inspanning kost geld”. Ik gok dat het weer een offerte wordt met 3 oplossingen. Denkt die klant dat die in regie is, omdat die denkt dat die een verstandige keus gemaakt, namelijk die je zo hebt gepresenteerd dat je al wist dat die daarvoor zou gaan.
Dino, dank voor je uitgebreide reactie maar voordat je begint over alle definitie misverstanden zou je eerst duidelijkheid moeten geven wat je met bepaalde termen bedoeld want eerst alles on-prem bouwen om het vervolgens naar de cloud te verplaatsen klinkt voor mij als een hybride cloud. De definitie hiervan heeft het namelijk over een gemengde omgeving die bestaat uit een on-premises infrastructuur met private-cloud service en een public cloud waardoor je de plaatsing van workloads kunt laten bepalen door de vereisten vanuit de business via geautomatiseerde deployment mogelijkheden, veelal gebeurt dit op basis van de REST API’s want de CLI voor toegang tot hardware kent veelal geen multitenancy als het om administratieve rollen en rechten gaat.
Misschien wil je niet een onafhankelijke adviseur maar wel een eerlijke zodat je vanuit meerdere gezichtspunten naar het op te lossen probleem kijkt want uiteindelijk zijn alle afspraken termijngebonden, wat betreft de regie zul je vooral 3 zetten vooruit moeten denken want ik ben nog nooit code tegengekomen die zichzelf onderhoud. Ik ken wel veel code waarvan de kosten van inspanning verlaagd zijn door offshoring naar lagelonen landen of gewoon de rigor mortis van geen onderhoud kennen. En ik ken veel licenties die gebaseerd zijn op groei, de elasticiteit kent hierdoor dus een onvoorspelbare OpEx want de uitdaging zat (en zit) vooral in de veranderlijkheid en het voordeel van een hybride oplossing met eigendom is dat je een grotere flexibiliteit hebt middels het idee van Infrastructure-as-Code t.o.v. het Infrastructure-as-a-Service waarin vaak contractuele verplichtingen zitten. En één van die contractuele verplichtingen betreft dus het onderhoud wat opmerkelijk vaak vergeten wordt.
De circulaire economie heeft het over hergebruik wat met een private-cloud service veelal eenvoudig is doordat er geen contractuele verplichtingen aangaande de inzet zijn, software-defined oplossingen zorgen voor een commoditisering van de infrastructuur en je kunt heel goed al wat oudere hardware upgraden of inzetten voor een andere belasting. De adviseur die niet alleen eerlijk is maar ook multidisciplinair kan je precies vertellen welke combinaties wel of niet werken en hoe lang het onderhouden kan worden op basis van een roadmap, het vooruit denken in contracten betekent veelal dat je een relatie hebt met leveranciers in de supply chain zodat je minder verrast zal worden door de veranderlijkheid hierin.
Want zoals de Amerikanen weer laten zien is hun exit strategie eentje van verlies want nadat je de cloud verlaten hebt zul je zekerheid moeten hebben dat ook je data gewist is en niet in verkeerde handen terecht komt. Bij eigendom van de schijven is dit gegarandeerd omdat je deze mee kunt nemen of vernietigen, ik hoop dat de grote aantallen wapens die in handen van de Taliban zijn gevallen onklaar zijn gemaakt omdat ze anders weleeens hergebruikt kunnen worden door groeperingen die zich niet zo aan de regels houden.
Definities devops, shared responsibility mbt iaas, workaround.
hybride cloud is duidelijk toch, alleen hebben veel bedrijven die niet nodig.
alleen als je elastisch moet zijn. maar goed nu herhaal ik mijn reactie..
alles in code is wel nodig, dus ook je infra.
daarom doe ik dat ook, gewoon on prem. geen last meer van ransomware in de backup, wel snelle reproduceerbaarheid, en periodiek afdwingen dat Het resultaat nog voldoet aan hoe het defined is enzo. handig.
Ook het installeren en configureren van de hypervisors beginnend bij kickstart.
daarna heb je alleen nog met een virtueel platform te maken, net als bij cloud als je klant bent.
Maar na het opzetten niet verplaatsen naar cloud, al zou dat wel eenvoudig kunnen.
gewoon overbodig als je continue load hebt die weinig varieert. hebben de meeste organisaties.
het automatisch elastisch schalen overigens, zou je bijv ook als oplossing kunnen zien die zichzelf onderhoudt.
Maar net hoe je het definieert, de schaalparameters staan weer in je code.
toegang tot hardware ben ik nog niet eerder tegengekomen bij cloud, ook niet iaas. Das het hele idee, alles waar je als cloudklant bij kan is virtueel.
je pleidooi voor het herinzetten van oude hardware als bijv resource pool spreekt dat van je hybride cloud weer tegen.
Blijkbaar hanteren we ook een andere definitie van regie, want als je daar een extern adviseur voor nodig hebt 😛
exit strategie is belangrijk. Eens. Weet je wat. Als we nou eens on prem bleven..
Maar uiteindelijk verschillen we zoveel niet.
infra as code, altijd goed.
infra as service, cloud, vaak fout. Daarin verschillen we.
maar ja ik verkoop geen oplossing met cloud.
Dino,
De monolitische cloud van één merk en één type is een bijzondere invulling van de definitie hybride cloud als we overwegen dat het eerste woord om een kruising gaat. Zo is de hybride auto een voertuig dat twee technologieën van voortdrijving in één oplossing combineert. Wij van WC-eend verkopen dan ook WC-eend alleen van een ander merk want een regievoering op basis van schaalparameters gaat om het capaciteitsmanagement en de hybride cloud is feitelijk een extensie hierop. Workload plaatsing op basis van schaalparameters kan echter alleen als de benzinemeter ook aangesloten is op de brandstoftank, de vraag is of je infra-as-code deze koppeling ook maakt of dat daar een aanvullende regievoering voor nodig is. Hetzelfde geldt voor eventuele loadbalancers, de regievoering over een mix & match resource pool op basis van schaalparameters zou je hier heel goed mee in kunnen vullen. En last but not least ben ik benieuwd naar je cost accounting omdat prijselasticiteit van de cloud om de belasting van de infrastructuur gaat, graag ook hierin meenemen het stroomverbruik want de regievoering hierop wordt steeds belangrijker. Don Quichot die in iedere server een zieke koe ziet denkt namelijk ook dat we draadloos stroom hebben.
Doing right things, goed.
doing things right, goed.
alles in code, goed.
weten is goed, meten is weten.
continue hoge on prem load is goed, want cloud is duurder bij continue belasting. Indien niet zo, wrom dan niet alles cloud.
hybrid cloud is goed als elasticiteit echt belangrijk is. Meestal is dat niet zo.
regie doe je zelf en dev en ops laat je over aan iemand die je vertrouwt.