Jak vypadá DevSecOps v praxi?

Na téma DevOps se toho napsalo už mnoho, ale co DevSecOps? I s ním se setkáváme stále častěji, ale co se za ním skutečně skrývá? Zjednodušeně řečeno – DevSecOps popisuje koncept zahrnutí softwarové bezpečnosti jako elementární součásti běžného vývojového procesu aplikací.

Abyste pochopili, proč je to důležité, je potřeba se zamyslet nad tím, jak se řešila softwarová bezpečnost v minulosti.

Monolitické aplikace vyvíjené metodou waterfall vznikaly v rukou „čistokrevných programátorů“. Nové verze, které se vytvořily v řádu měsíců nebo i let, byly podrobené akceptačním (funkčním) testům, jež druhý tým „čistokrevných adminů“ následně nasazoval do produkce.

Bezpečnostní testy se vykonávaly v rámci finálních akceptačních testů, v horším případě dokonce až v produkčním provozu. Stávalo se tak zcela běžně, že bezpečnostní incidenty byly odhalené až těsně před nasazením.

Projekt se tudíž vrátil zpět vývojářům k přepracování a bezpečnostní specialisté byli označováni mnohdy nevybíravými termíny – svět se svým způsobem dělil na tři vzájemně znesvářené tábory vývojářů, adminů a „bezpečáků“. Každý tým považoval další dva za někoho, kdo mluví cizím jazykem, jen jim komplikuje práci a hází klacky pod nohy.

Z dnešního pohledu je naprosto zřejmé, že tento přístup byl vysoce neefektivní. Přístup k vývoji softwaru se ale vydal cestou přes agilní metody směrem k DevOps. Cesta od monolitických aplikací přešla přes architekturu orientovanou na služby (SOA) ke kontejnerizovaným mikroslužbám.

Došlo tak k dramatickému zkrácení vývojového cyklu. Infrastruktura vzniká a zaniká společně se službami, pro jejichž provoz je určená. Servery a aplikace už nejsou opečovávané jako domácí mazlíčci, místo toho se chovají v masové míře jako dobytek. V maximálním rozsahu se využívá automatizace, infrastruktura se řídí kódem (IaC).

To všechno umožnil masivní rozmach cloudových technologií, které jsou ideálním prostředím pro kontejnerizovanou nebo tzv. serverless architekturu. Členové DevOps týmu už nejsou zodpovědní jen za programování, ale byly na ně delegované i pravomoci k nasazení a provozu jejich aplikací. Tábory vývojářů a adminů se sjednotily.

Sdílená odpovědnost

Dalším logickým krokem je tedy zahrnutí i třetího týmu, resp. delegace jeho bezpečnostních pravomocí. Mohlo by se zdát, že jde o oxymóron, vždyť segregace pravomocí je základním pilířem bezpečnosti.

Pokud se ale bezpečnost integruje do všech fází softwarového vývojového cyklu, vyřeší se tím problémy nastíněné výše. Je ale potřeba zajistit, aby vývojáři mysleli na bezpečnost už při psaní zdrojového kódu, aby se software testoval na přítomnost bezpečnostních hrozeb ještě před nasazením a aby IT týmy měly plány, jak identifikované bezpečnostní problémy rychle vyřešit, pokud se objeví až po nasazení v dalších fázích cyklu.

Odtud také pramení termín „shift-left security“ označující posunutí bezpečnosti na samotný začátek vývojového cyklu. DevOps tým tak dostává nejen pravomoci, ale s nimi i povinnosti řešit otázku bezpečnosti. Tři dříve nepřátelské tábory usedají k jednomu stolu a vzniká DevSecOps.

DevSecOps tedy nepředstavuje alternativu k DevOps, ale je jejím logickým rozšířením. Jde o myšlenku, že vývojáři společně s ostatními IT týmy, včetně toho bezpečnostního, by měli úzce spolupracovat namísto toho, aby si každý „hrál na vlastním písečku“.

Efektivní DevSecOps tak vyžaduje obejmutí DevOps a integraci bezpečnosti do celé CI/CD pipeline.

DevSecOps je kultura

K dosažení DevSecOps mohou organizace použít mnoho nástrojů a procesů, ale je důležité si uvědomit, že DevSecOps není konkrétní nástroj ani proces. Je to kultura.

Hlavním přínosem DevSecOps je vštěpení správných kulturních hodnot do organizace. Vývojáři, admini, bezpečnostní specialisté a všichni ostatní, kteří mají co do činění s dodávkou softwaru, musí táhnout za jeden provaz.

Při všem, co dělají, musejí myslet také na zabezpečení jejich produktu. Před jakýmkoliv rozhodnutím týkajícím se aplikace by měl celý tým přemýšlet o jeho dopadu na bezpečnost. Pokud tomu tak je, dosáhlo se DevSecOps.

Implementace DevSecOps

K DevSecOps se lze vydat celou řadou cest, ta nejlepší, nebo jejich ideální kombinace pro vaši organizaci, závisí na potřebách příslušné organizace. Pro přijetí DevSecOps kultury vám mohou pomoci následující strategie:

• Vzdělávání: Všichni, kdo se účastní procesu poskytování softwaru, by měli rozumět moderním bezpečnostním hrozbám a důležitosti jejich řešení.
• Komunikace: Vybudujte efektivní komunikační kanály mezi všemi členy týmu, aby mohli rychle sdílet informace o bezpečnostních hrozbách. Chatovací aplikace nebo nástroje pro týmovou spolupráci jsou výrazně vhodnější než běžné tiketovací helpdeskové systémy.
• Bezpečnostní playbook: Vytvořte příručky, které jasně specifikují, jak by měli jednotliví členové týmu reagovat na určitý typ bezpečnostního incidentu. Reakce na exponovanou kritickou zranitelnost, na kterou je k dispozici exploit, bude jistě jiná než na zranitelnost, jejíž zneužití je jen hypotetické.
• Audity a shoda s předpisy: Bezpečnostní audity a kontrola souladu s předpisy by se měly stát rutinní součástí procesu doručování softwaru.
• Zvolte správné nástroje: Vhodné nástroje dokážou cestu výrazně zkrátit a přispět k vybudování nové kultury. Porozhlédněte se po nástrojích na cloudovou bezpečnost, které jsou založené na API. Ty vám pomohou automatizovat aplikování bezpečnostních politik i následné auditování.

Přesvědčte vývojáře

Ve snaze implementovat DevSecOps narážejí organizace nejčastěji na odpor ze strany vývojářů. Takže klíčová otázka zní: jak lze přesvědčit vývojáře, aby se zajímali o bezpečnost, přijali práci navíc, a ještě k tomu si rozšiřovali v této oblasti znalosti?

Právě v tomto bodu může ten správný nástroj zafungovat jako katalyzátor transformace k DevSecOps. Klíčem je nevnucovat vývojářům používání dalších a dalších nástrojů. Vhodný bezpečnostní produkt by měl umožnit integraci do existujících DevOps procesů a použitých nástrojů – ať už jde o vývojové prostředí (IDE), řízení zdrojového kódu (SCM) nebo CI/CD nástroje.

Bezpečnostní řešení musejí poskytnout vývojářům okamžitou zpětnou vazbu v situaci, kdy budou vykonávat akce, které by mohly způsobit škodlivé chyby, a tak je vzdělávat za pochodu.

Abychom pokryli celou smyčku DevOps, nesmí se zapomenout na zabezpečení v poslední fázi, tedy při běhu. V této fázi musí zvolený bezpečnostní nástroj ideálně detekovat zranitelnosti v provozovaných aplikacích, monitorovat jakékoliv odchylky od běžného chování, identifikovat slabiny v konfiguraci a prioritizovat odhalené bezpečnostní incidenty.

Prisma Cloud, jeden z nástrojů pro komplexní zabezpečení DevOps prostředí, který nabízí společnost Palo Alto Networks

Nejvhodnější nástroje dokážou pokrýt celý životní cyklus aplikace od sestavení přes doručení až po běh, a to v libovolném veřejném nebo privátním prostředí, ale ani ta nejlepší technologie nic nezmůže, pokud nedojde k rozšíření povědomí o bezpečnosti mezi všechny členy týmu a nastavení správné firemní kultury.