Ovládací prvky DevSecOps

DevSecOps aplikuje zabezpečení inovací integrací procesů zabezpečení a nástrojů do vývojového procesu DevOps.

Vzhledem k tomu, že Samotný DevOps je vznikající disciplína s vysokou mírou variant procesů, úspěšný DevSecOps se spoléhá na pochopení a promyšlenou integraci zabezpečení do procesu vývoje. Přidání zabezpečení by mělo začínat nízkými třeními změn kódu, vývojových procesů a infrastruktury, která hostuje úlohu. Nejprve se zaměřte na změny s nejvyšším pozitivním dopadem na zabezpečení a zároveň zatěžujte nízké zatížení procesů a dovedností DevOps.

Tato dokumentace zkontroluje jednotlivé fáze procesu Kontinuální integrace a průběžného doručování (CI/CD) DevOps a jaké kontroly zabezpečení doporučujeme nejprve integrovat.

Ovládací prvky DevSecOps

Plánování a vývoj

Moderní vývoj se obvykle řídí metodikou agilního vývoje. Scrum je jednou z implementací agilní metodologie, která má každý sprint začít s plánovací aktivitou. Zavedení zabezpečení do této části procesu vývoje by se mělo zaměřit na:

  • Modelování hrozeb pro zobrazení aplikace prostřednictvím objektivu potenciálního útočníka
  • Moduly plug-in zabezpečení integrovaného vývojového prostředí (IDE) a předběžné potvrzení pro jednoduchou kontrolu statické analýzy v integrovaném vývojovém prostředí (IDE).
  • Peer review and secure coding standards to identify effective security coding standards, peer review processes, and pre-commit hooks.

Není povinné přidat všechny tyto kroky. Každý krok ale pomáhá včas odhalit problémy se zabezpečením, když jsou mnohem levnější a jednodušší je opravit.

Modelování hrozeb

Modelování hrozeb je pravděpodobně nejdůležitějším postupem zabezpečení. Poskytuje okamžité výsledky a pomáhá vývojářům zajistit zabezpečení, aby zlepšil zabezpečení ve všech budoucích projektech.

Modelování hrozeb je jednoduchý koncept, i když může být podrobný a technický v případě potřeby. Modelování hrozeb odhalí a dokumentuje realistický pohled na zabezpečení vaší aplikace, která zahrnuje:

  • Jak můžou útočníci zneužít návrh aplikace
  • Jak opravit ohrožení zabezpečení
  • Jak důležité je opravit problémy

Modelování hrozeb vám efektivně dává na mysli útočníka. Umožňuje vidět aplikaci prostřednictvím očí útočníka. Dozvíte se, jak blokovat pokusy, než útočníci s ním můžou dělat cokoli. Pokud má váš tým v návrhu osoby uživatele, můžete s útočníkem zacházet jako s nepřátelskou osobou uživatele.

Existují publikované přístupy k modelování hrozeb, které se liší od jednoduchých metod otázek a odpovědí až po podrobnou analýzu na základě nástrojů. Přístup můžete založit na metodologiích, jako je model STRIDE, model DREAD nebo modelování hrozeb OWASP.

Modelování hrozeb: Zahájení jednoduchého

Vzhledem k tomu, že některé přístupy k modelování hrozeb můžou být časově náročné a náročné na dovednosti, doporučujeme začít jednodušším přístupem pomocí základních otázek. Jednodušší metody nejsou tak důkladné, ale začínají proces kritického myšlení a pomáhají rychle identifikovat hlavní problémy se zabezpečením.

Začněte následujícími jednoduchými metodami otázek:

V závislosti na tom, co je pro váš tým lepší, můžete použít jeden nebo oba tyto přístupy.

Jakmile se váš tým s procesem seznámí, můžou využít pokročilejší techniky z životního cyklu vývoje zabezpečení Microsoftu. A můžou integrovat nástroje pro modelování hrozeb, jako je nástroj microsoftu pro modelování hrozeb , a získat tak hlubší přehledy a automatizovat proces.

Dalším užitečným prostředkem je průvodce modelováním hrozeb pro vývojáře.

Moduly plug-in zabezpečení integrovaného vývojového prostředí (IDE) a předpřipravené háky

Vývojáři se zaměřují na rychlost doručování a řízení zabezpečení můžou proces zpomalit. K zpomalení obvykle dochází v případě, že kontroly zabezpečení začínají v kanálu. Vývojář zjistí potenciální ohrožení zabezpečení po nasdílením kódu do úložiště. Pokud chcete proces urychlit a poskytnout okamžitou zpětnou vazbu, stojí za to přidat kroky, jako jsou moduly plug-in zabezpečení integrovaného vývojového prostředí (IDE) a háky před potvrzením.

Moduly plug-in integrovaného vývojového prostředí (IDE) identifikují různé problémy se zabezpečením během procesu vývoje ve známém prostředí IDE vývojáře. Moduly plug-in můžou poskytnout okamžitou zpětnou vazbu, pokud je v písemném kódu vývojáře možné bezpečnostní riziko. Moduly plug-in můžou také odhalit rizika v knihovně nebo balíčku třetích stran. V závislosti na zvoleném integrovaném vývojovém prostředí je k dispozici mnoho opensourcových nebo komerčních modulů plug-in a poskytuje je společnosti zabezpečení.

Další možností, kterou je třeba zvážit, je použití architektury předběžného potvrzení, pokud to systém správy verzí umožňuje. Architektura předběžného potvrzení poskytuje skripty pro háky Git, které pomáhají identifikovat problémy před odesláním kódu pro kontrolu kódu. Jedním z příkladů je předběžné potvrzení , které můžete nastavit na GitHubu.

Partnerské kontroly a zabezpečené standardy kódování

Žádosti o přijetí změn jsou v procesu vývoje standardní. Součástí procesu žádosti o přijetí změn je partnerské kontroly, které často zobrazují nezjištěné vady, chyby nebo problémy související s lidskými chybami. Před vytvořením žádosti o přijetí změn je vhodné mít šampiona zabezpečení nebo znalost týmu zabezpečení, který může vývojáře vést během procesu kontroly partnerského vztahu.

Pokyny k bezpečnému kódování pomáhají vývojářům naučit se základní principy bezpečného kódování a způsob jejich použití. K dispozici jsou zabezpečené postupy kódování, například postupy zabezpečeného kódování OWASP , které se mají začlenit do obecných postupů kódování.

Potvrzení kódu

Vývojáři obvykle vytvářejí, spravují a sdílejí svůj kód v úložištích, jako je GitHub nebo Azure Repos. Tento přístup poskytuje centrální knihovnu kódu řízenou verzí, na které mohou vývojáři snadno spolupracovat. Povolení mnoha spolupracovníků na jediném základu kódu ale také vede k riziku zavedení změn. Toto riziko může vést k ohrožením zabezpečení nebo neúmyslným zahrnutím přihlašovacích údajů nebo tokenů do potvrzení.

Aby se toto riziko vyřešilo, měly by vývojové týmy vyhodnotit a implementovat funkci kontroly úložiště. Nástroje pro kontrolu úložiště provádějí statickou analýzu kódu u zdrojového kódu v úložištích. Nástroje hledají chyby zabezpečení nebo změny přihlašovacích údajů a označí všechny položky nalezené k nápravě. Tato schopnost slouží k ochraně před lidskou chybou a je užitečná ochrana pro distribuované týmy, ve kterých spolupracuje mnoho lidí ve stejném úložišti.

Správa závislostí

Až 90 % kódu v aktuálních aplikacích obsahuje prvky nebo je založeno na externích balíčcích a knihovnách. Při přijetí závislostí ve zdrojovém kódu je nezbytné řešit potenciální rizika. Řada knihoven třetích stran má vážné problémy se zabezpečením. Vývojáři také nebudou konzistentně sledovat nejlepší životní cyklus a udržovat závislosti aktuální.

Ujistěte se, že váš vývojový tým ví, jaké komponenty se mají do svých aplikací zahrnout. Budou chtít stáhnout zabezpečené a aktuální verze ze známých zdrojů. A budou chtít mít proces pro udržování verzí v aktualizovaném stavu. Váš tým může používat nástroje, jako je projekt OWASP Dependency-Check, WhiteSource a další.

Pokud se chcete zaměřit pouze na ohrožení zabezpečení závislostí nebo jejich životní cyklus nestačí. Je také důležité řešit zabezpečení informačních kanálů balíčků. Existují známé vektory útoku, které cílí na systémy správy balíčků: překlepování, ohrožení stávajících balíčků, útoky na náhradu a další. Zodpovědná správa balíčků proto musí tyto rizika řešit. Další informace najdete v tématu Tři způsoby zmírnění rizika při používání privátních kanálů balíčků.

Testování zabezpečení statické aplikace

Jakmile váš tým řeší knihovny třetích stran a správu balíčků, je nezbytné se soustředit a zlepšit zabezpečení kódu. Zabezpečení kódu můžete vylepšit různými způsoby. Můžete použít moduly plug-in zabezpečení integrovaného vývojového prostředí (IDE). Nebo můžete připojit přírůstkové kontroly předběžného potvrzení a potvrzení statické analýzy, jak je popsáno dříve. Je také možné provést úplnou kontrolu zdrojového kódu, abyste zachytili chyby zmeškané předchozími kroky. Je to nutné, ale může trvat hodiny nebo dokonce dny, než prohledá velký blok kódu. Tento přístup tedy může zpomalit vývoj a zavést zátěž.

Tým ale musí začít někde při implementaci postupů kontroly statického kódu. Jedním ze způsobů je zavést statickou analýzu kódu uvnitř kontinuální integrace. Tato metoda ověří zabezpečení, jakmile dojde ke změnám kódu. Jedním z příkladů je SonarCloud. Zabalí několik nástrojů pro testování zabezpečení statických aplikací (SAST) pro různé jazyky. SonarCloud posuzuje a sleduje technický dluh se zaměřením na udržovatelnost. Dívá se na kvalitu a styl kódu a obsahuje kontroly specifické pro zabezpečení. Existuje ale mnoho dalších komerčních a opensourcových nástrojů dostupných na trhu.

Aby se zajistilo, že smyčka zpětné vazby je účinná, je zásadní nástroj vyladit. Chcete minimalizovat falešně pozitivní výsledky a poskytnout jasnou a použitelnou zpětnou vazbu k problémům, které je potřeba vyřešit. Je také vhodné implementovat pracovní postup, který brání potvrzení kódu do výchozí větve, pokud existují zjištění. Chtěli byste pokrýt jak kvalitu, tak bezpečnostní zjištění. Zabezpečení se tedy stane součástí prostředí testování jednotek.

Zabezpečené kanály

DevOps přebírá automatizaci na jinou úroveň, protože všechno v životním cyklu vývoje prochází kanálem. Kontinuální integrace a průběžné doručování (CI/CD) jsou klíčovou součástí moderních vývojových cyklů. V CI/CD váš tým sloučí vývojářský kód do centrálního základu kódu podle běžného plánu a automaticky spouští standardní buildy a testovací procesy.

Kanály infrastruktury jsou ústřední součástí vývoje. Použití kanálů ke spouštění skriptů nebo nasazení kódu do produkčních prostředí ale může představovat jedinečné výzvy zabezpečení. Chcete zajistit, aby se kanály CI/CD nestaly cestami ke spuštění škodlivého kódu, povolení odcizení přihlašovacích údajů nebo poskytnutí přístupu útočníkům jakoukoli oblast. Také chcete zajistit, aby se pak nasadil jenom kód, který má váš tým v úmyslu uvolnit.

Týmy DevOps musí zajistit, aby implementovaly správné bezpečnostní mechanismy pro kanál. V závislosti na zvolené platformě existují různé pokyny k řešení rizik. Další informace najdete v tématu Zabezpečení služby Azure Pipelines.

Sestavení a otestování

Mnoho organizací používá kanály sestavení a vydávání verzí k automatizaci a standardizaci procesů pro sestavování a nasazování kódu. Kanály vydaných verzí umožňují vývojovými týmy rychle a škálovat iterativní změny oddílů kódu. Týmy nebudou muset trávit velké množství času opětovným nasazením nebo upgradem stávajících prostředí.

Používání kanálů vydaných verzí také umožňuje týmům propagovat kód z vývojových prostředí, prostřednictvím testovacích prostředí a nakonec do produkčního prostředí. V rámci automatizace by vývojové týmy měly zahrnovat nástroje zabezpečení, které spouští skriptované, automatizované testy při nasazování kódu do testovacích prostředí. Testy by měly zahrnovat testování částí u funkcí aplikace, aby bylo možné zkontrolovat ohrožení zabezpečení nebo veřejné koncové body. Testování zajišťuje úmyslný přístup.

Dynamické testování zabezpečení aplikací

V klasickém vodopádovém vývojovém modelu se zabezpečení obvykle zavedlo v posledním kroku přímo před přechodem do produkčního prostředí. Jedním z nejoblíbenějších přístupů k zabezpečení je penetrační testování nebo penetrační testování. Penetrační testování umožňuje týmu podívat se na aplikaci z pohledu zabezpečení černé skříňky, jako je tomu u útočníka.

Penetrační test se skládá z několika akčních bodů, z nichž jedna je dynamické testování zabezpečení aplikací (DAST). DAST je test zabezpečení webové aplikace, který najde problémy se zabezpečením spuštěné aplikace tím, že zjistí, jak aplikace reaguje na speciálně vytvořené požadavky. Nástroje DAST se také označují jako skenery ohrožení zabezpečení webových aplikací. Jedním z příkladů je opensourcový nástroj OWASP Zed Attack Proxy (ZAP). Najde ohrožení zabezpečení ve spuštěné webové aplikaci. Existují různé způsoby skenování OWASP ZAP: pasivní základní kontrola nebo úplná kontrola v závislosti na konfiguraci.

Nevýhodou testování pera je, že trvá čas. Důkladný test pera může trvat až několik týdnů a s rychlostí vývoje DevOps může být tento časový rámec nedodržitelný. Během procesu vývoje ale stále stojí za to přidat světlejší verzi testování pera, aby se odhalily problémy, které SAST zmeškaly a další kroky. Nástroje DAST, jako je OWASP ZAP, vám můžou pomoct.

Vývojáři integrují zap OWASP do kanálu jako úlohu. Během běhu se skener OWASP ZAP spustí v kontejneru a provede kontrolu a pak publikuje výsledky. Tento přístup nemusí být dokonalý, protože to není kompletní penetrační testování, ale je stále cenné. Je to ještě jedna míra kvality v vývojovém cyklu pro zlepšení stavu zabezpečení.

Ověřování konfigurace cloudu a kontrola infrastruktury

Kromě skenování a zabezpečení kódu pro aplikace se ujistěte, že prostředí, do kterého nasazujete aplikace, jsou také zabezpečená. Zabezpečená prostředí jsou klíčová pro organizace, které chtějí rychle přejít, inovovat a používat nové technologie. Zabezpečená prostředí také pomáhají týmům rychle vytvářet nová prostředí pro experimentování.

Funkce Azure umožňují organizacím vytvářet standardy zabezpečení z prostředí, jako je Azure Policy. Teams může k vytváření sad zásad použít Azure Policy. Sady zásad brání vytváření určitých typů úloh nebo položek konfigurace, jako jsou veřejné IP adresy. Tyto ochranné mantinely umožňují týmům experimentovat v bezpečném a řízeném prostředí, vyvážit inovace a zásady správného řízení.

Jedním ze způsobů, jak DevOps může spojit vývojáře a operace, je podporovat převod stávající infrastruktury na přístup infrastruktury jako kódu.

Infrastruktura jako kód (IaC) je správa infrastruktury (sítí, virtuálních počítačů, nástrojů pro vyrovnávání zatížení a topologie připojení) v popisném modelu. IaC používá stejný model správy verzí jako tým DevOps pro zdrojový kód. Stejně jako princip stejného zdrojového kódu generuje stejný binární soubor, model IaC generuje stejné prostředí pokaždé, když se použije. IaC je klíčovým postupem DevOps, který se používá s průběžným doručováním.

DevSecOps přesouvá zabezpečení doleva a ukazuje, že zabezpečení není jen o zabezpečení aplikací, ale také o zabezpečení infrastruktury. Jedním ze způsobů, jak DevSecOps podporuje zabezpečení infrastruktury, je zahrnout kontrolu zabezpečení před nasazením infrastruktury v cloudu. Jakmile se infrastruktura stala kódem, použili byste u infrastruktury stejné akce zabezpečení jako zabezpečení aplikace. K dispozici jsou nástroje zabezpečení pro spouštění kontroly zabezpečení infrastruktury na základě zvolené strategie IaC.

Díky přijetí cloudu je kontejnerizace oblíbeným přístupem, který týmy přijmou v rozhodnutích o architektuře aplikací. Některá úložiště kontejnerů prohledávají image, aby zachytila balíčky se známými ohroženími zabezpečení. Stále existuje riziko, že kontejner může mít zastaralý software. Vzhledem k tomuto riziku je důležité zkontrolovat kontejner pro rizika zabezpečení. Existuje spousta opensourcových a komerčních nástrojů zabezpečení, které cílí na tuto oblast a podporují úzkou integraci v procesu CD. Nástroje zabezpečení pomáhají týmům přijmout DevSecOps pro infrastrukturu jako kód a konkrétněji se dozvědět, jak používat kontejnery.

Přechod do produkčního prostředí a provoz

Když řešení přejde do produkčního prostředí, je důležité pokračovat v dohledu a správě stavu zabezpečení. V této fázi procesu je čas zaměřit se na cloudovou infrastrukturu a celkovou aplikaci.

Kontrola konfigurace a infrastruktury

Pokud chcete získat přehled o cloudových předplatných a konfiguraci prostředků napříč několika předplatnými, použijte řešení zabezpečení tenanta Azure od týmu AzSK.

Azure zahrnuje možnosti monitorování a zabezpečení. Tyto funkce detekují a upozorňují na neobvyklé události nebo konfigurace, které vyžadují šetření a potenciální nápravu. Technologie, jako je Microsoft Defender for Cloud a Microsoft Sentinel , jsou nástroje první strany, které se nativně integrují do prostředí Azure. Tyto technologie doplňují nástroje pro zabezpečení prostředí a kódu. A technologie poskytují důkladné monitorování zabezpečení, aby organizace mohly experimentovat a inovovat rychle a bezpečně.

Testování průniku

Testování průniku je doporučeným postupem pro kontrolu ohrožení zabezpečení v konfiguraci infrastruktury nebo aplikace, což může způsobit slabá místa, která útočníci můžou zneužít.

Mnoho produktů a partnerů nabízí služby penetračního testování. Microsoft poskytuje pokyny pro penetrační testování v Azure.

Testování obvykle zahrnuje následující typy testů:

  • Testování koncových bodů za účelem odhalení ohrožení zabezpečení
  • Testování fuzzu (vyhledání chyb programu poskytnutím poškozených vstupních dat) koncových bodů
  • Prohledávání portů koncových bodů

Inteligentní funkce s možností akce

Nástroje a techniky v těchto doprovodných materiálech nabízejí holistický model zabezpečení pro organizace, které chtějí rychle přejít a experimentovat s novými technologiemi, které mají za cíl podpořit inovace. Klíčovým prvkem DevSecOps jsou procesy řízené daty řízené událostmi. Tyto procesy pomáhají týmům identifikovat, vyhodnotit a reagovat na potenciální rizika. Mnoho organizací se rozhodne integrovat upozornění a data o využití do své platformy SPRÁVY IT služeb (ITSM). Tým pak může přenést stejný strukturovaný pracovní postup do událostí zabezpečení, které používají pro jiné incidenty a požadavky.

Smyčky zpětné vazby

Snímek obrazovky znázorňující model průběžného zabezpečení

Všechny tyto techniky a nástroje umožňují týmům najít a označit rizika a ohrožení zabezpečení, které vyžadují šetření a potenciální řešení. Provozní týmy, které obdrží upozornění nebo zjistí potenciální problém, když prošetří lístek podpory, potřebují trasu zpět vývojovému týmu, aby označili položky příznakem ke kontrole. Bezproblémová smyčka pro spolupráci a zpětnou vazbu je důležitá k rychlému řešení problémů a minimalizaci rizika ohrožení zabezpečení co nejvíce.

Běžným vzorem pro zpětnou vazbu je integrace do systému pro správu práce vývojáře, jako je Azure DevOps nebo GitHub. Organizace může propojit upozornění nebo incidenty s pracovními položkami, aby vývojáři mohli plánovat a provádět akce. Tento proces poskytuje efektivní způsob, jak vývojářům vyřešit problémy v rámci standardního pracovního postupu, včetně vývoje, testování a vydání.