Hvad er DevOps-compliance – og hvorfor er det vigtigt?

Overholdelse af lovgivningen er måske et af de mindst glamourøse emner inden for teknologi.

Alligevel er det et helt nødvendigt emne. Kravene til overholdelse påvirker organisationer af alle størrelser – især enhver virksomhed, der opererer online, hvilket på nuværende tidspunkt er alle virksomheder.

»De fleste virksomheder oplever i dag ændringer i det lovgivningsmæssige landskab, hvor der kommer nye regler hvert år, nogle gange hvert kvartal,« siger Daniel Marashlian, CTO og medstifter af Drata, en virksomhed inden for automatisering af sikkerhed og overholdelse. »Overholdelse er ved at blive et krav for at kunne drive virksomhed [stort set overalt].«

Rækken af lovgivningsmæssige akronymer lyder da også som en synstest hos optikeren: HIPAA, PCI DSS, GDPR, SOX, FISMA, NIST – er du stadig med? Det er kun toppen af isbjerget, når det gælder de potentielle regler og rammeværk, du kan være nødt til at overholde, især i den moderne softwareverden.

Da virksomhedssoftware berører stort set alle dele af en virksomhed, følger det, at software – for ikke at nævne dens data og infrastruktur – i høj grad er en del af det lovgivningsmæssige landskab. Det betyder igen, at DevOps-teams i stigende grad har ansvar for deres organisations strategi for og status med hensyn til overholdelse.

»DevOps-organisationer bliver i stigende grad bedt om at opfylde disse nye lovgivningsmæssige krav,« siger Marashlian.

I denne artikel ser vi nærmere på overholdelse i DevOps – hvad det er, hvorfor det er vigtigt, og hvordan teams implementerer det.

Hvad er overholdelse i DevOps?

DevOps har altid handlet om at opbygge bedre processer, værktøjer og teams – med det ultimative mål hurtigt og pålideligt at levere fremragende software. Overholdelse i DevOps fokuserer derfor på at sikre, at softwareleverancens livscyklus (SDLC) opfylder alle krav til overholdelse, uanset om de er fastlagt af organisatoriske politikker, offentlige regler, branchestandarder eller andre bestemmelser.

Tidligere blev overholdelse måske betragtet som en afsluttende kontrol før implementering – eller endda som noget, man ikke prioriterede, medmindre der opstod et problem i en produktionsudgivelse. I dag er der et ønske om at flytte overholdelse – ligesom sikkerhed, QA og andre processer – så langt »til venstre« som muligt i SDLC, hvilket vil sige ind i de tidligste faser af softwareudviklingen. Det gør overholdelse til en mere integreret del af SDLC og giver teams mulighed for regelmæssigt at kontrollere deres kode og systemer for overholdelse på flere stadier, så risici reduceres.

Hvorfor er overholdelse i DevOps vigtigt?

DevOps er blevet en af de førende tilgange til softwareudvikling. Det er tilstrækkeligt at sige, at mange softwareapplikationer – og bestemt alle systemer, der genererer, bruger eller gemmer følsomme data – er underlagt de forskellige politikker, regler og sikkerhedsrammeværk, der regulerer, hvordan virksomheder opererer.

Overholdelse i DevOps er vigtigt, fordi det uden overholdelse er langt sværere at minimere risici og sikre konsekvent overholdelse, når softwareteams implementerer kode hurtigere og hyppigere – faktisk kontinuerligt – end nogensinde før. Det gælder i endnu højere grad, fordi mange elementer i SDLC er blevet automatiseret, herunder pipelines til kontinuerlig integration/levering (CI/CD), automatisering af infrastruktur, sikkerhedsautomatisering og meget mere. Den samme automatiseringsbaserede tankegang bør også omfatte overholdelse.

»Hvis overholdelse indarbejdes i funktioner, mens de udvikles, i stedet for at identificere problemerne, efter at funktionen er blevet implementeret, kan man undgå dyr afhjælpning,« siger Marashlian.

Udfordringer med overholdelse ved DevOps-implementeringer

Overholdelse i DevOps er også vigtigt, fordi det repræsenterer en fortsat ændring i den måde, softwareudviklingsteams interagerer med resten af organisationen på. Ligesom DevOps i sig selv havde til formål at nedbryde traditionelle barrierer mellem IT-domæner – nemlig udvikling og drift, men også funktioner som sikkerhed og QA – bør overholdelse i DevOps på samme måde mindske friktionen mellem softwareteams og andre vigtige interessenter, især medarbejdere inden for styring, risiko og overholdelse (GRC).

»Når det gælder ændringer, der foretages af udviklingsteams, mangler GRC-teams indsigt i, hvordan disse ændringer påvirker deres status med hensyn til overholdelse, eftersom den eneste måde at opnå denne indsigt på er gennem manuelle audits eller automatiserede værktøjer, der scanner deres produktionsmiljø,« siger Marashlian.

Dette peger på flere overlappende udfordringer med overholdelse i DevOps-virksomheder: manglende synlighed, manglende kommunikation, manglende samarbejde og mangel på effektive teknologiske værktøjer – især værktøjer, der kan hjælpe med at implementere, automatisere og administrere en »ønsket tilstand« for virksomhedens krav til overholdelse.

Overholdelse i DevOps »betyder, at udviklere får synlighed i rammeværk for overholdelse og lovgivningsmæssige krav på en tilgængelig og handlingsanvisende måde, så de kan sikre, at organisationens forretningsmæssige mål for overholdelse opfyldes af deres kodeændringer,« siger Marashlian.

Det går begge veje: GRC-teams har også brug for synlighed i og forståelse af, hvordan en organisations software påvirker dens status med hensyn til overholdelse, men på en måde, der ikke skaber friktion med udviklere og DevOps-ingeniører eller skaber flaskehalse i SDLC. 

Gode nyheder: Disse udfordringer bør lyde velkendte for erfarne DevOps-folk, fordi de minder om de konflikter, der tidligere eksisterede mellem udvikling og drift. DevOps-praksisser såsom fælles incitamenter og skyldfrie efterfølgende evalueringer kan også være værdifulde her.

Automatisering er også afgørende, da den muliggør hyppige kontroller, som begynder tidligt i SDLC'en og senere minimerer alvorlige problemer i produktionen. Hvis sådanne problemer alligevel opstår, er en samarbejdsorienteret tilgang til at løse dem – i modsætning til at placere skylden – afgørende.

“Når kritiske problemer med regeloverholdelse identificeres i produktionen, bør GRC- og ingeniørteams arbejde sammen om at prioritere løsninger på disse problemer og sikre, at organisationen fortsat opfylder sine mål for regeloverholdelse,” siger Marashlian. “Det hjælper med at undgå siloer og fremmer et tættere samarbejde mellem de to teams.”

Bedste praksis for regeloverholdelse i DevOps

Uanset hvilke specifikke værktøjer eller andre løsninger du vælger til regeloverholdelse i DevOps, er der nogle grundlæggende komponenter og bedste praksisser, som bør indgå som fundament i dit program. Disse omfatter:

Klare regler og mål: Du kan ikke overholde reglerne, hvis du ikke ved, hvad målet er. Derfor bør ethvert program for regeloverholdelse i DevOps naturligvis begynde med at identificere, hvilke regler og rammeværk du skal eller ønsker at overholde, og derefter implementere politikker og værktøjer i overensstemmelse hermed. Disse kan undertiden fastsættes som “acceptable intervaller”, hvilket betyder, at der findes et spektrum af potentielt acceptable resultater for de kontroller af regeloverholdelse, der køres under forskellige faser af SDLC'en.

Versionsstyring: Versionsstyringssystemer som Git findes allerede ofte i DevOps-værktøjskæder. Det er godt, fordi versionsstyring i vid udstrækning også betragtes som uundværligt for regeloverholdelse i DevOps – blandt andet fordi det er en teknologi, der muliggør sikkerheds- og regeloverholdelsesaudit.

Infrastruktur som kode (IaC): Værktøjer til infrastruktur som kode – eller infrastrukturautomatisering – gør det muligt for DevOps-ingeniører og andre programmatisk at håndtere opgaver inden for infrastrukturstyring, såsom klargøring, skalering eller konfiguration. Det gør det muligt for DevOps-teams at administrere infrastrukturen konsekvent og automatisk, hvilket sparer betydelig tid og kræfter på manuelt og gentagende infrastrukturarbejde.

Sikkerhedsautomatisering / DevSecOps: Selvom sikkerhed og regeloverholdelse typisk betragtes som separate områder, er de bestemt relaterede, især når det gælder data. For at beskrive sammenhængen enkelt: Hvis du har sikkerhedssårbarheder i din software, infrastruktur eller data, har du sandsynligvis også sårbarheder med hensyn til regeloverholdelse. En måde at betragte regeloverholdelse i DevOps på er, at den følger et mønster, der minder om DevOps og sikkerhed – hvilket undertiden kaldes DevSecOps – idet den kræver en tankegang, hvor sikkerheden indarbejdes tidligt, og hvor man opgiver gamle paradigmer, hvor sikkerhed (og regeloverholdelse) blev behandlet som en afsluttende tjekliste på tidspunktet for implementering.

Processer for regeloverholdelse krydser også ofte forskellige cybersikkerhedsstandarder og -strategier, såsom adgangskontrol (tænk MFA/2FA og rollebaseret adgangskontrol) og sikkerhedsrammeværk som dem, der er udgivet af NIST eller OWASP.

Regeloverholdelse som kode (CaC): Regeloverholdelse som kode (CaC) – undertiden kaldet automatisering af regeloverholdelse – anvender scripts og automatiseringsværktøjer til at mindske risiciene forbundet med manuel konfiguration og sikre ensartethed på tværs af en organisations IT-stak og SDLC.

CaC forbedrer sporbarheden og ansvarligheden for ændringer, der foretages i infrastruktur og software. Sammen med infrastruktur som kode (IaC) kan virksomheder opnå bæredygtige, gentagelige og auditerbare infrastrukturændringer, der er i overensstemmelse med kravene til regeloverholdelse – og gøre det samme i deres softwarekodebaser.

Vi ser nærmere på nogle CaC-værktøjer i næste afsnit. 

Værktøjer og løsninger til regeloverholdelse i DevOps

Som Marashlian bemærker ovenfor, er en af de overordnede udfordringer ved regeloverholdelse i enhver organisation, at det er et område i konstant udvikling. Nye regler og love vedtages, eksisterende rammeværk eller regler ændres og så videre.

Det er en af de grundlæggende værdifordele ved CaC-værktøjer. De tilfører større standardisering, ensartethed og automatisering til kontroller af regeloverholdelse gennem hele SDLC'en – samtidig med at der bevares et tydeligt revisionsspor. 

Som Jim Bird, forfatter til O’Reilly-bogen DevOpsSec, skriver: “Standardisering gør revisorer glade. Revision gør revisorer glade (naturligvis). Regeloverholdelse som kode giver et smukt revisionsspor for hver ændring, fra hvornår ændringen blev anmodet om, og hvorfor, til hvem der foretog ændringen, og hvad denne person ændrede, hvem der gennemgik ændringen, og hvad der blev fundet under gennemgangen, hvordan og hvornår ændringen blev testet, og hvornår den blev implementeret.”

Efterhånden som DevOps er blevet mere modent, ser det ud til, at flere organisationer begynder at forstå mulighederne: Marashlian fra Drata henviser til en nyere rapport fra Gartner, som forudsiger, at “70 % af virksomhederne i 2026 vil have integreret regeloverholdelse som kode i deres DevOps-værktøjskæder, hvilket reducerer risikostyringen og forbedrer gennemløbstiden med mindst 15 %.”

Drata lancerede for nylig en CaC-funktion på sin platform. »DevOps- og GRC-teams får indsigt i complianceproblemer tidligt i udviklingslivscyklussen, [kan] nemt og hurtigt afhjælpe disse problemer i koden og [kan] opbygge sikkerhedsforanstaltninger, der styrer, om kodeændringer, som påvirker organisationens compliance-status, må foretages,« siger Marashlian.

Hvis du for eksempel er en sundhedsorganisation, der ønsker at automatisere mere af sin HIPAA-compliance, kan du konfigurere et CaC-værktøj til at gøre det. Dette ligner de fleste andre større regelsæt, såsom SOC 2, GDPR og ISO 27001. CaC-værktøjer kan hjælpe med at automatisere valideringen af forskellige compliancestandarder gennem hele SDLC'en og bevæge sig hen imod en model for kontinuerlig compliance – ikke ulig kontinuerlig levering og CD-pipelines.

Ud over Drata findes der flere andre muligheder, herunder Vanta, Sprinto og Scrut. Et af dine grundlæggende udvælgelseskriterier bør naturligvis være at sikre, at ethvert værktøj, du bruger, kan understøtte dine specifikke compliancekrav.

Husk også, at der findes en langt bredere vifte af softwareværktøjer, som kan høre under paraplyen DevOps-compliance: versionsstyringssystemer som Git, automatiseringsplatforme som Terraform og Ansible og endda Kubernetes. De større cloudplatforme tilbyder også deres egne varianter af disse og andre værktøjer.

Den vigtigste pointe

Overholdelse af regler er måske ikke det bedste samtaleemne til et middagsselskab, men det er nødvendigt for de fleste organisationer. Og compliance – især når det gælder softwareapplikationer, data og infrastruktur – håndteres i stigende grad som kode på en meget automatiseret måde.  

Hvilken rolle spiller din DevOps i din organisations compliance? Tilmeld dig The CTO Clubs nyhedsbrev for flere branchenyheder og diskussioner!