Artikelserie: DevOps del 3 av 3
DevOps - Deploy till Monitor
I den här artikeln beskriver vi den andra halvan av en utvecklingslivscykel (SDLC, Software Development Lifecycle) som är inspirerad av DevOps-loopens åtta delar, där vi mappar ut utvecklings- och säkerhetsaktiviteter till respektive del.
DevOps
Den “korrekt” DevOps loopen.
Deploy
Continuous Delivery – idén och inställningen att varje bygge skulle kunna vara en potentiell release. Beroende på hur mogna ni är som team kanske ni gör deployment till produktionsmiljön direkt (efter att den har passerat era olika testmiljöer).
Se till att alla miljöer är produktionslika, vilket ofta är enklare om ni jobbar i en molnmiljö. Se även till att de är skapade från kod, så kallad “infrastruktur som kod”.
Överväg att använda feature toggles för att aktivera/avaktivera ny funktionalitet eller funktioner som ännu inte är klara för att nå slutkunden.
Använd A/B tester för att utföra experiment på vad som levererar bäst värde till era kunder.
Release
“Release on demand” - att göra värdet av din release tillgänglig till kund vid ett tillfälle då den ger mest värde. Beroende på hur mogna ni är som team eller hur era affärsbehov ser ut kan release till kund ske antingen manuellt eller automatiskt.
Att releasa ofta leder till reducerad risk. Genom att releasa ofta tränar ni på releaseförfarandet och att felsöka eventuella problem är mycket enklare då mängden förändringar mellan föregående version och den nya versionen är färre.
Se till att alla releaser är automatiserade och inte kräver manuella handgrepp. Även om beslutet att göra en release är manuellt ska själva förfarandet vara automatiserat.
Se till att ni kan göra releaser till kund utan nertid och under dagtid då alla inblandade är på plats. Använd er av Blue/Green eller Canary releaser eller/och genom att använda feature toggles.
Operate
Överväg att använda “immutable infrastructure” där manuella förändringar i en miljö inte är tillåtna (utan måste göras genom att uppdatera kod/konfiguration och göra en ny release). Det borde kanske till och med vara en målsättning att inte tillåta människor att logga in i produktionssystem.
Om ni bygger er applikation i någon av de stora molnmiljöerna så har de kontrollpaneler för säkerhet som ni bör kontrollera med jämna mellanrum (Azure Security Center, AWS Security Hub etc.)
Våga skanna er applikation efter sårbarheter i produktionsmiljön, annars är det någon annan som gör det utanför er kontroll!
Genomför penetrationstester med jämna mellanrum, t.ex. var 6:e – 12:e månad. När ni releasar allt oftare måste ni frikoppla era penetrationstester från era releaser. Det är helt enkelt inte genomförbart om ni releasar varje vecka och ett penetrationstest tar två veckor. Efter ett genomfört penetrationstest, försök då att skapa automatiserade testfall baserade på eventuella sårbarheter funna i testet. På så sätt kan ni säkerställa att dessa inte kan inträffa igen.
Har ni en modern leverantör av penetrationstester kanske de till och med kan leverera tickets till er backlog och automatiserade testfall (istället för tjocka rapporter).
En målsättning skulle kunna vara att ni så småningom öppnar upp er applikation för ett bug bounty program som komplement till era penetrationstester. Detta kräver att man har ett moget team och en mogen applikation, annars kommer förmodligen bug bounty aktiviteterna konsumera stor del av er tillgängliga tid.
Monitor
Se till att ni får ut säkerhetsrelaterade mätvärden från er applikation eller systemmiljö, exempelvis:
förhållandet mellan antalet lyckade och antalet misslyckade inloggningar (stora förändringar skulle kunna indikera att er applikation är under attack)
en ovanligt hög mängd 4xx eller 5xx fel kan vara en indikation på att ni har ett allvarligt problem eller är under attack
Se till att ni skapar relevanta larm med väl beskrivna åtgärder och försök hitta en bra balans mellan för många och för få.
Målsättningen med era mätvärden bör vara att ni proaktivt kan upptäcka och hantera både drifts- och säkerhetsrelaterade problem innan de inträffar och drabbar era kunder.
Slutord och mer information
Nu har vi gått igenom en DevOps inspirerad utvecklingslivscykel med mängder av aktiviteter. Rekommendationen är inte att ni ska börja med alla på en gång. Välj de aktiviteter som ni tror passar er bäst eller ger er mest värde.
Kom ihåg att det inte bara handlar om verktyg utan först och främst ”people, process” och sen ”product”. Förändrade beteenden kanske är det ni ska uppmärksamma mest.
För ytterligare inspiration skulle vi varmt rekommendera:
Boken ”The DevOps Handbook”
Boken ”Accelerate: The Science of Lean Software and DevOps” som sammanfattar år av studier hur högpresterande DevOps-team jobbar
Boken ”The Phoenix Project” som är en novell om DevOps från ett driftsperspektiv
Boken ”The Unicorn Project” som är en novell om DevOps från ett utvecklarperspektiv
Omegapoints artikelserie “Applikationssäkerhet - försvar på djupet”
Forskningen bakom år av State of DevOps reports finns sammanfattad här: