Organisaties hebben DevOps inmiddels massaal omarmd. Ongeacht of het al wordt toegepast binnen de organisatie, het lijkt de heilige graal te zijn, in ieder geval voor de komende tijd, zoals dat in de it-branche gaat. Kernbegrip hierin is ci/cd, ofwel continuous integration & continuous delivery. De automatisering van automatisering.
Vanaf de tijd dat it nog automatisering heette, tot aan nu, wordt it voornamelijk via grote bouwblokken geleverd (server, besuringssysteem, apps, databases). Dat ging prima en snel genoeg tot we de term agile ontdekten, en de ‘business’ zich met it ging bemoeien. It-diensten moeten tegenwoordig snel worden geleverd en naar wens van de gebruiker, die anders zelf een alternatief gaat zoeken. Op die manier ontstaat schaduw-it waarbij hele afdelingen gebruikmaken van een cloudservice waar iemand zijn creditcard voor heeft uitgeleend. Inderdaad snel, niet altijd goedkoper en zelden veilig, want het gaat buiten het centrale beheer om.
Dus moeten we it anders inrichten en opknippen in containers en microprocessen om ze flexibeler te maken. Dankzij tooling zijn services te activeren zonder tussenkomst van mensen en goedkeuringsprocessen. Een enorme tijdswinst: van soms maanden naar hooguit een dag. De beweging naar DevOps is dan ook niet meer te keren; de voordelen zijn overduidelijk. Maar het gaat niet zonder slag of stoot. Er zijn namelijk drie groepen in een organisatie die moeten samenwerken om het voor elkaar te krijgen.
De drie groepen
Developers zijn verantwoordelijk voor de ontwikkeling van functionaliteit (groep 1). Zij willen zoveel mogelijk code schrijven en niet gehinderd worden door vertragende it-processen en al helemaal niet door security-eisen.
Groep 2 zijn de mensen van ‘operations’. Zij willen echter een stabiele omgeving met zo min mogelijk veranderingen. Elke verandering is er één te veel.
Hier springt DevOps op in door deze twee groepen te integreren waar mogelijk. Automatiseren van processen zodat veranderingen mogelijk zijn zonder aan de stabiliteit van een infrastructuur te tornen. Maar er is nog een derde groep die mee moet werken.
De laatste groep zijn de security-teams. Zij zijn verantwoordelijk voor de beveiliging van de it-omgeving en voor de compliance met het interne beleid. In de ogen van de developers en operations zijn dit vaak ‘de lastpakken’, daarom worden ze pas op het eind van een traject ingeschakeld. Meestal is het dan veel te laat, wat de frustratie bij alle partijen vergroot.
Hier is DevSecOps voor bedacht. DevOps is niet tegen beveiliging, zolang je er maar geen last van hebt. Security is niet tegen DevOps, zolang het maar veilig gebeurt. En dat kan ook! In DevOps-omgevingen draait het om secrets en credentials, de toegangssleutels. Omdat het er zo veel zijn, worden ze vaak slecht beveiligd en beheerd. Ze liggen vaak open en bloot omdat het dan makkelijk werken is, maar het vormt een groot risico. De ‘sleutels onder de deurmat’ zijn nog beter verstopt. Veel organisaties zijn zich hier niet van bewust, of weten niet goed hoe ermee om te gaan, omdat ze de gebruikers niet in de weg willen zitten. Door secrets en credentials veilig op te bergen, maar ze wel toegankelijk te maken voor de juiste mensen en applicaties/services lost u een groot gedeelte van de zorgen op. Niet met opgeheven vingers op elkaars verantwoordelijkheid wijzen, maar deze drie groepen in staat stellen hun werk te doen. Developers die mooie producten maken, operators die het onder controle houden, en security teams die de zaak veilig houden en auditen. Het kan echt.
