Vad är efterlevnad inom DevOps – och varför är det viktigt?
Efterlevnad är nödvändigt: Regelefterlevnad är avgörande för företag, särskilt för dem som bedriver verksamhet online. Efterlevnad påverkar alla organisationer och blir allt viktigare för att kunna bedriva verksamhet i princip var som helst.
Regelverkens alfabetssoppa: Företag måste följa många regelverk och standarder, till exempel HIPAA, PCI DSS, GDPR och SOX. Dessa regler påverkar modern programvaruutveckling, vilket gör efterlevnad till ett viktigt ansvar för DevOps-team.
Flytta efterlevnaden åt vänster med DevOps: Efterlevnad inom DevOps syftar till att integrera regulatoriska kontroller tidigt i livscykeln för programvaruutveckling (SDLC). Detta proaktiva arbetssätt minskar riskerna genom att säkerställa efterlevnad i flera utvecklingsfaser, inte bara före driftsättning.
Automatisering räddar efterlevnaden: Automatiseringen i livscykeln för programvaruutveckling bör omfatta efterlevnad för att minimera risker och kostnader. Genom att säkerställa efterlevnad under utvecklingen av funktioner undviker man kostsamma korrigeringar efter driftsättning och främjar kontinuerlig efterlevnad av regelverken.
Utmaningar med insyn och samarbete: Effektiv efterlevnad inom DevOps bygger på att överbrygga klyftorna mellan teknik- och GRC-team genom insyn, förbättrad kommunikation, samarbete och avancerade tekniska verktyg. Båda sidor måste kunna arbeta sömlöst tillsammans.
Efterlevnad av regelverk är kanske ett av de minst glamorösa ämnena inom hela teknikområdet.
Ändå är det ett helt nödvändigt ämne. Krav på efterlevnad påverkar stora och små organisationer och alla däremellan – särskilt alla företag som bedriver verksamhet online, vilket vid det här laget innebär alla företag.
”De flesta företag ser i dag förändringar i regelverkslandskapet, där nya regler införs varje år, ibland varje kvartal”, säger Daniel Marashlian, CTO och medgrundare av Drata, ett företag inom automatisering av säkerhet och efterlevnad. ”Efterlevnad håller på att bli ett måste för att kunna bedriva verksamhet [i princip var som helst].”
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Listan över akronymer för regelverk låter verkligen som ett syntest hos optikern: HIPAA, PCI DSS, GDPR, SOX, FISMA, NIST – hänger ni fortfarande med? Det där är bara toppen av isberget när det gäller potentiella regler och ramverk som ni kan behöva följa, särskilt i dagens mjukvaruvärld.
Eftersom företagsmjukvara berör i princip alla delar av ett företag följer det att mjukvaran – för att inte tala om dess data och infrastruktur – i allra högsta grad är en del av regelverkslandskapet. Detta innebär i sin tur att DevOps-team i allt högre grad ansvarar för organisationens strategi och ställning när det gäller efterlevnad.
”DevOps-organisationer ombeds i allt högre grad att uppfylla de här nya regelverkskraven”, säger Marashlian.
I den här artikeln tittar vi närmare på efterlevnad inom DevOps – vad det är, varför det är viktigt och hur team implementerar det.
Vad är efterlevnad inom DevOps?
DevOps har alltid handlat om att bygga bättre processer, verktyg och team – med det yttersta målet att snabbt och tillförlitligt leverera bra mjukvara. Efterlevnad inom DevOps fokuserar därför på att säkerställa att livscykeln för mjukvaruleveranser (SDLC) uppfyller alla krav på efterlevnad, oavsett om de fastställs av organisatoriska policyer, myndighetsföreskrifter, branschstandarder eller andra regler.
Tidigare kan efterlevnad ha betraktats som en sista kontroll före driftsättning – eller till och med som något man inte prioriterade om det inte uppstod ett problem i en produktionsrelease. I dag finns det en strävan att flytta efterlevnad – precis som säkerhet, kvalitetssäkring och andra processer – så långt ”åt vänster” som möjligt i SDLC, det vill säga till de tidigaste faserna av mjukvaruutvecklingen. Det gör efterlevnad till en mer integrerad del av SDLC och gör det möjligt för team att regelbundet kontrollera sin kod och sina system med avseende på efterlevnad i flera olika faser, vilket minskar riskerna.
-
Spacelift
Visit Website -
ManageEngine Applications Manager
Visit WebsiteThis rating combines scores from multiple user review sites to reflect overall customer sentiment about the product.4.3 -
Site24x7
Visit WebsiteThis rating combines scores from multiple user review sites to reflect overall customer sentiment about the product.4.7
Varför är efterlevnad inom DevOps viktigt?
DevOps har blivit en av de ledande metoderna för mjukvaruutveckling. Det räcker att säga att många mjukvaruapplikationer – och definitivt alla system som genererar, använder eller lagrar känsliga data – omfattas av de olika policyer, regler och säkerhetsramverk som styr hur företag bedriver sin verksamhet.
Efterlevnad inom DevOps är viktig eftersom det utan den blir betydligt svårare att minimera risker och säkerställa konsekvent efterlevnad när mjukvaruteam distribuerar kod snabbare och oftare – egentligen kontinuerligt – än någonsin tidigare. Det gäller i ännu högre grad eftersom många delar av SDLC har blivit automatiserade, däribland pipelines för kontinuerlig integrering/kontinuerlig leverans (CI/CD), infrastrukturautomatisering, säkerhetsautomatisering och mycket mer. Samma automationsfokuserade tankesätt bör även omfatta efterlevnad.
”Att bygga in efterlevnad i funktioner medan de utvecklas, i stället för att identifiera problemen efter att funktionen har driftsatts, kan undvika kostsam åtgärdshantering”, säger Marashlian.
Utmaningar med efterlevnad vid DevOps-implementeringar
Efterlevnad inom DevOps är också viktig eftersom den representerar en fortsatt förändring av hur mjukvaruutvecklingsteam samarbetar med resten av organisationen. Precis som DevOps i sig syftade till att bryta ned traditionella barriärer mellan IT-områden – framför allt mellan utveckling och drift, men även mellan funktioner som säkerhet och kvalitetssäkring – bör efterlevnad inom DevOps på samma sätt minska friktionen mellan mjukvaruteam och andra viktiga intressenter, särskilt personal som arbetar med styrning, risk och efterlevnad (GRC).
”När det gäller ändringar som görs av utvecklingsteamen saknar GRC-teamen insyn i hur dessa ändringar påverkar organisationens ställning när det gäller efterlevnad, eftersom det enda sättet att få denna insyn är genom manuella granskningar eller automatiserade verktyg som genomsöker produktionsmiljön”, säger Marashlian.
Detta belyser flera överlappande utmaningar när det gäller efterlevnad i DevOps-miljöer: brist på insyn, brist på kommunikation, brist på samarbete och brist på effektiva tekniska verktyg – särskilt verktyg som kan hjälpa till att implementera, automatisera och hantera ett ”önskat tillstånd” för företagets krav på efterlevnad.
Efterlevnad inom DevOps ”innebär att ge utvecklare insyn i efterlevnadsramverk och regelverkskrav på ett tillgängligt och handlingsinriktat sätt, så att de kan säkerställa att organisationens affärsmål när det gäller efterlevnad uppfylls genom deras kodändringar”, säger Marashlian.
Det går åt båda hållen: GRC-team behöver också insyn i och förståelse för hur en organisations mjukvara påverkar dess ställning när det gäller efterlevnad, men på ett sätt som inte skapar friktion med utvecklare och DevOps-ingenjörer eller skapar flaskhalsar i SDLC.
Goda nyheter: Dessa utmaningar borde låta bekanta för erfarna DevOps-proffs eftersom de liknar de konflikter som tidigare fanns mellan utveckling och drift. DevOps-metoder som gemensamma incitament och icke-anklagande eftergranskningar/utvärderingar kan också vara värdefulla här.
Automatisering är också mycket viktigt, eftersom det möjliggör frekventa kontroller som börjar tidigt i SDLC och minimerar produktionsproblem senare. Om sådana problem ändå uppstår är ett samarbetsinriktat sätt att lösa dem – i stället för att skuldbelägga någon – avgörande.
”När kritiska efterlevnadsproblem identifieras i produktion bör GRC- och ingenjörsteamen samarbeta för att prioritera korrigeringar av dessa problem och säkerställa att organisationen fortsätter att uppfylla sina efterlevnadsmål”, säger Marashlian. ”Detta bidrar till att undvika stuprör och underlättar ett närmare samarbete mellan de två teamen.”
Bästa praxis för efterlevnad inom DevOps
Oavsett vilka specifika verktyg eller andra lösningar du väljer för efterlevnad inom DevOps finns det några grundläggande komponenter och bästa praxis att ta hänsyn till som fundament för ditt program. Dessa omfattar:
Tydliga regler och mål: Du kan inte uppfylla kraven om du inte vet vad målet är. Därför bör alla program för efterlevnad inom DevOps naturligtvis börja med att identifiera vilka regelverk och ramverk ni behöver eller vill följa och därefter implementera policyer och verktyg i enlighet med detta. Dessa kan ibland anges som ”acceptabla intervall”, vilket innebär att det finns ett spektrum av möjliga acceptabla resultat för efterlevnadskontroller när de körs under olika faser av SDLC.
Versionshantering: Versionshanteringssystem som Git finns vanligtvis redan i DevOps-verktygskedjor. Det är bra, eftersom versionshantering även i stor utsträckning anses vara ett måste för efterlevnad inom DevOps – bland annat eftersom det är en möjliggörande teknik för säkerhets- och efterlevnadsrevisioner.
Infrastruktur som kod (IaC): Verktyg för infrastruktur som kod – eller infrastrukturautomatisering – gör det möjligt för DevOps-ingenjörer och andra att programmässigt hantera uppgifter inom infrastrukturhantering, såsom etablering, skalning eller konfigurationer. Detta gör det möjligt för DevOps-team att hantera infrastruktur konsekvent och automatiskt, vilket sparar betydande tid och arbete vid manuellt och repetitivt infrastrukturarbete.
Säkerhetsautomatisering / DevSecOps: Även om säkerhet och efterlevnad vanligtvis betraktas som separata områden är de definitivt relaterade, särskilt när det gäller data. För att uttrycka sambandet enkelt: Om du har säkerhetssårbarheter i din programvara, infrastruktur eller data har du sannolikt även sårbarheter vad gäller efterlevnad. Ett sätt att se på efterlevnad inom DevOps är att det följer ett mönster som liknar DevOps och säkerhet – vilket ibland kallas DevSecOps – genom att det kräver ett ”shift left”-tankesätt och att gamla paradigm överges, där säkerhet (och efterlevnad) behandlades som en slutlig checklista vid driftsättning.
Efterlevnadsprocesser korsar också ofta olika cybersäkerhetsstandarder och -strategier, såsom åtkomstkontroll (tänk MFA/2FA och rollbaserad åtkomstkontroll) och säkerhetsramverk som publicerats av NIST eller OWASP.
Efterlevnad som kod (CaC): Efterlevnad som kod (CaC) – ibland kallad efterlevnadsautomatisering – använder skript och automatiseringsverktyg för att minska riskerna kopplade till manuell konfiguration och säkerställa konsekvens genom hela organisationens IT-stack och SDLC.
CaC förbättrar spårbarheten och ansvarsskyldigheten för ändringar som görs i infrastruktur och programvara. Tillsammans med infrastruktur som kod (IaC) kan företag uppnå hållbara, repeterbara och granskningsbara infrastrukturändringar som överensstämmer med efterlevnadskrav – och göra detsamma i sina programvarukodbaser.
Vi tittar närmare på några CaC-verktyg i nästa avsnitt.
Verktyg och lösningar för efterlevnad inom DevOps
Som Marashlian påpekar ovan är en av de övergripande utmaningarna med efterlevnad i alla organisationer att det är ett landskap som utvecklas kontinuerligt. Nya regler och lagar antas, befintliga ramverk eller regler ändras och så vidare.
Det är en av de grundläggande värdeerbjudandena med CaC-verktyg. De ger större standardisering, konsekvens och automatisering åt efterlevnadskontroller genom hela SDLC – samtidigt som ett tydligt revisionsspår bevaras.
Som Jim Bird, författare till O’Reilly-boken DevOpsSec, skriver: ”Standardisering gör revisorer nöjda. Revision gör revisorer nöjda (uppenbarligen). Efterlevnad som kod ger ett vackert revisionsspår för varje ändring, från när ändringen begärdes och varför, till vem som gjorde ändringen och vad den personen ändrade, vem som granskade ändringen och vad som upptäcktes i granskningen, hur och när ändringen testades och när den driftsattes.”
I takt med att DevOps har mognat verkar fler organisationer se ljuset: Marashlian från Drata hänvisar till en nyligen publicerad rapport från Gartner som förutspår att ”70 % av företagen senast 2026 kommer att ha integrerat efterlevnad som kod i sina DevOps-verktygskedjor, vilket minskar riskhanteringen och förbättrar ledtiden med minst 15 %.”
Drata lanserade nyligen en CaC-funktion på sin plattform. ”DevOps- och GRC-team får tidigt insyn i efterlevnadsproblem under utvecklingens livscykel, [kan] enkelt och snabbt åtgärda dessa problem i koden och [kan] bygga skyddsräcken för att kontrollera om kodändringar som påverkar organisationens efterlevnadsnivå får genomföras”, säger Marashlian.
Om du till exempel är en vårdorganisation som vill automatisera mer av er HIPAA-efterlevnad kan ni konfigurera ett CaC-verktyg för att göra det. Detta liknar de flesta andra större regelverk, såsom SOC 2, GDPR och ISO 27001. CaC-verktyg kan hjälpa till att automatisera valideringen av olika efterlevnadsstandarder genom hela SDLC och därmed gå mot en modell för kontinuerlig efterlevnad – inte olikt kontinuerlig leverans och CD-pipelines.
Utöver Drata finns det flera andra alternativ, däribland Vanta, Sprinto och Scrut. Uppenbarligen bör ett av dina grundläggande urvalskriterier vara att säkerställa att alla verktyg du använder kan stödja just dina efterlevnadskrav.
Kom också ihåg att det finns ett betydligt bredare utbud av programvaruverktyg som kan rymmas under paraplyet DevOps-efterlevnad: versionshanteringssystem som Git, automatiseringsplattformar som Terraform och Ansible och till och med Kubernetes. De stora molnplattformarna erbjuder också sina egna varianter av dessa och andra verktyg.
Slutsatsen
Efterlevnad av regelverk kanske inte är det bästa samtalsämnet på en middagsbjudning, men det är ett måste för de flesta organisationer. Och efterlevnad – särskilt när det gäller programvaruapplikationer, data och infrastruktur – hanteras i allt högre grad som kod på ett högautomatiserat sätt.
Vilken roll spelar DevOps för efterlevnaden i din organisation? Gå med i The CTO Clubs nyhetsbrev för fler branschnyheter och diskussioner!
