Sådan udfordrer DevOps din sikkerhed –og sådan løser du problemet

DevOps-teams med høje release-rates skaber løbende værdi for virksomheder. Men arkaiske sikkerhedspolitikker og personlige modviljer overfor nye arbejdsmetoder fører til sikkerhedsbrister. Så hvordan holder man kadencen uden at sætte sikkerheden over styr?

”Hvis din virksomhed ikke har DevOps-grupper i gang, har den ikke fremdrift”. Måske lidt sat på spidsen, men det er den helt grundlæggende sandhed for mange moderne virksomheder i dag. Men selvom fremdrift er grundstenen i overlevelse, er det ikke uden problemer, at der sidder DevOps-teams og udvikler agilt med en konstant strøm af nye releases, hvis virksomhedens sikkerhedspolitik kører i et helt andet spor.

DevOps er et samarbejde mellem Dev, Ops – og sikkerhed

Et grundlæggende problem, som optræder i mange virksomheder, er, at der kommer meget fokus på ”Dev”, som arbejder ekstremt agilt, og der ikke er meget kærlighed tilbage til ”Ops”. I samspil med en ledelse, der mener, at it-sikkerhed er en ledelsesmæssig beslutning, og implementerer sikkerhedstiltag i en klassisk vandfaldsmodel med halv- eller helårlige releases, skaber det en række sikkerhedsmæssige svagheder, forklarer Michael Dreves Beier, Business Unit Manager for Cloud hos Orange Cyberdefense.

“I mange virksomheder er der DevOps-teams, som ses som udviklere og ikke andet. De får besked på at levere en applikation, der skal releases med en højfrekvent schedule. Ops-folkene står ofte som et rådyr i lyskeglen og tænker: ‘Hvad sker der her?

For når det hele kører uden om Ops-medarbejderne, har de ikke en chance for at gøre deres arbejde, og applikationen kommer i drift uden den gennemgribende kontrol, der er nødvendig for at opretholde et fornuftigt sikkerhedsniveau.

Udviklerne skaber jo ikke disse sikkerhedsproblemer med vilje, mener Michael Dreves. Det er simpelthen et strukturelt problem, at der simultant arbejdes i to vidt forskellige projektmodeller.

“DevOps har jo et opdrag om eksempelvis at ændre en funktionalitet så hurtigt som muligt, så virksomheden kan markedstilpasse og fejlrette. Samtidig har de fleste virksomheder jo en IT-afdeling, der tager sig af drift, incident management og lignende. Det er alt sammen meget manuelt – og kræver mennesker og tid.

Det harmonerer vældig dårligt med DevOps, hvor man kører fuldt automatiseret, lægger sin kode på Github, smider den på en server og tester den, og hvis alt fungerer, sendes den i produktion.

DevOps-teams vil ikke begrænses i handlefrihed af i den klassike projektmodel, så de kører udenom, fordi de har fokus på deadlines og deployments ”

Ironisk nok forstærkes det problem af en af tidens store hjælpende hænder: cloud-løsninger.

Skyen kunne være lyserød

Der er ikke længere nogen større debat om, hvorvidt cloud er vejen frem. Den er skalerbar, den er altid åben, og den er langt hen ad vejen både nemmere og billigere end at have alting on-premise. Men med det store ryk til cloud opstår der hurtigt sikkerhedsproblemer, fordi virksomheder ikke ændrer deres sikkerhedsmodel til den nye virkelighed, de er rykket ind i.

Efterhånden som flere og flere applikationer rykker ud i clouden, ændrer billedet af den optimale sikkerhedsmodel sig, fordi den måde, man opbygger sine applikationer til cloudens skalerbarhed og automatisering på, er anderledes, end den måde man arbejdede på før. Derfor opstår der en brist mellem den måde, virksomheders DevOps-teams arbejder på, og den eksisterende sikkerhedspolicy, vurderer Michael Dreves Beier. Det er sådan set det klassiske problem – blot nu flyttet over på en ny platform.

“Når man begynder at migrere ud til native cloud-applikationer, begynder teknologi og processer at blive helt anderledes. Det ser vi hos både store og små virksomheder, der er i gang med at skrive deres egne applikationer om fra monolitter til microservices. Der sidder DevOps-teams, der for eksempel får til opgave at skrive hele en fagorganisations medlemsapplikation om, så den kommer i cloud og kører i containers med microservices, og det ændrer billedet.

Når det sker, skal sikkerhedsmodellerne opbygges anderledes. Her kan den gamle firewall for eksempel ikke spille den samme rolle, som den gjorde før.

Fikspunktet i en almindelig next-gen firewall er, at man kender netværket. Men nu har netværket ikke længere faste holdepunkter, for det er ikke statisk og kontrollerbart på samme måde som før, og netværk er blevet en ressource på linje med CPU, memory, disk osv.”

Problemerne forstærkes af virksomhedskulturer, der har vænnet sig til at løse sikkerhedskrav i udvikling med flere konsulenter og flere processer. Altså mere manuel kontrol og mere tidsforbrug – det diametralt modsatte af den arbejdsgang, virksomhedernes DevOps-teams opererer med, understreger Michael Dreves.

“DevOps er fuldautomatisering af næsten alting. Ikke udviklingen, men man tager meget af den kode, der er skabt i forvejen, og kører på automatiserede engines med ændringer op til ti gange om dagen. Det kan man ikke med gatede releases eller manuel sikkerhedstest. Så der er et stort clash mellem den automatiserede del og den eksisterende infrastruktur. Frem for at ændre strukturen, vælger mange virksomheder i stedet at fortsætte med at tilføre flere ressourcer i et mønster, som er velkendt for dem. I det lider sikkerheden meget, fordi den ses som omkostning og begrænsende faktor.”

Løsning: det rette værktøj til opgaven

Løsningen er i virkeligheden ganske ligetil, ligesom det var inden applikationerne blev udviklet i skyen –  sikkerhedsværktøjerne skal indbygges i den automatiserede pipeline.

På den måde kan man relativt ubesværet implementere en såkaldt shift left-strategi – hvor vi rykker opgaverne længere til venstre på tidslinjen – og begynder test af applikationer langt tidligere, og afhjælper problemerne før applikationen er så langt i udviklingen, at man næsten skal rive det hele ned og begynde forfra.

Et godt eksempel er tidlig integrationstestning, der kan afsløre integrationsproblemer tidligt i udviklingsprocessen, før det reelt er for sent at ændre i applikationernes grundlæggende arkitektur.

Hvis man er i tvivl om, hvordan man skal komme i gang, er der flere værktøjer på markedet, understreger Michael Dreves.

“Nogle af vores producenter er rigtigt langt fremme med værktøjer til automatiseret applikationstestning. Andre har fokus på at sikre visibilitet i infrastrukturen. For som sagt er sikkerhedsproblemerne langt hen ad vejen de samme som før. De kører blot i en anden infrastruktur, og håndhævelse af sikkerhed sker et andet sted. Sidder man i et DevOps team, så man skal blandt andet lære at bruge de rigtige sikkerhedsværktøjer for containers og Kubernetes, samtidig med at man automatiserer hele CI/CD-pipelinen.

Under alle omstændigheder, så er det vores holdning at visibilitet og segmentering er strategisk afgørende for at videreudvikle sin cloud rejse.

”Vi tror på at alle virksomheder ender i multi cloud setup i løbet af nogle år, fordi det er den mest økonomiske måde at afvikle applikationer på, siger Michael Dreves og fortsætter: ”og i den sammenhæng bliver det vigtigt at vælge sikkerhedsværktøjer, som kan håndtere de forskellige cloud providers for at undgå lock-in”.

Overraskende nok er det vores holdning at man bør tage kontakt til en dygtig rådgiver, hvis man vil være helt sikker.” afslutter Michael Dreves.

Orange Cyberdefense har kompetencerne til at få jer videre – og dét kan du bl.a. læse mere om her: https://orangecyberdefense.com/dk/cloud-security/