Ovládací prvky DevSecOps

DevSecOps používá zabezpečení inovací integrací procesů zabezpečení a nástrojů do procesu vývoje DevOps.

Vzhledem k tomu, že DevOps je vznikající disciplína s vysokou mírou variací procesů, úspěšný DevSecOps závisí na pochopení a promyšlené integraci zabezpečení do procesu vývoje. Přidání zabezpečení by mělo začínat nízkými změnami kódu, vývojových procesů a infrastruktury, která je hostitelem úlohy. Nejprve se zaměřte na změny s nejvyšším pozitivním dopadem na zabezpečení a současně zatěžte procesy a dovednosti DevOps.

Tato dokumentace kontroluje jednotlivé fáze procesu kontinuální integrace a průběžného doručování (CI/CD) DevOps a toho, jaké bezpečnostní prvky doporučujeme integrovat jako první.

DevSecOps controls

Plánování a vývoj

Moderní vývoj se obvykle řídí metodologií agilního vývoje. Scrum je jednou z implementací agilní metodologie, která má každý sprint začínat 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řipojení před potvrzením pro jednoduchou statickou analýzu 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á odhalit problémy se zabezpečením včas, když jsou mnohem levnější a snadněji se opravují.

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 stanovit bezpečnostní myšlení, aby zlepšil zabezpečení ve všech svých budoucích projektech.

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

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

Modelování hrozeb vám v podstatě dává na mysli útočníka. Umožňuje zobrazit aplikaci prostřednictvím očí útočníka. Dozvíte se, jak zablokovat pokusy, aby útočníci s tím mohli cokoli dělat. 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 založenou na nástrojích. Přístup můžete založit na metodologiích, jako je model STRIDE 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 s jednodušším přístupem pomocí základních otázek. Jednodušší metody nejsou tak důkladné, ale zahajují kritický proces myšlení a pomáhají rychle identifikovat hlavní problémy se zabezpečením.

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

  • Jednoduchá metoda otázek od Microsoftu: Tato metoda klade konkrétní technické otázky navržené tak, aby se zomešly běžné chyby návrhu zabezpečení.
  • Modelování hrozeb OWASP: Tato metoda se zaměřuje na kladení jednoduchých, netechnických otázek, které vám pomůžou začít s procesem modelování hrozeb.

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

Jakmile se váš tým s procesem více seznámí, můžou použí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řipojení k předběžnému potvrzení

Vývojáři se zaměřují na rychlost doručování a bezpečnostní prvky můžou proces zpomalit. K zpomalení obvykle dochází v případě, že se kontroly zabezpečení spustí 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, je vhodné přidat kroky, jako jsou moduly plug-in zabezpečení integrovaného vývojového prostředí (IDE) a hooky před potvrzením.

Moduly plug-in zabezpečení 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 napsané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í strany. V závislosti na zvoleném integrovaném vývojovém prostředí (IDE) je k dispozici mnoho opensourcových nebo komerčních modulů plug-in, které poskytují bezpečnostní společnosti.

Další možností, jak zvážit, je použít architekturu předběžného potvrzení, pokud to systém správy verzí umožňuje. Architektura předběžného potvrzení poskytuje skripty háku Gitu, které pomáhají identifikovat problémy před tím, než vývojář odešle kód pro kontrolu kódu. Jedním z příkladů je předběžné potvrzení , které můžete nastavit na GitHubu.

Peer review and secure coding standards

Žádosti o přijetí změn jsou v procesu vývoje standardní. Součástí procesu žádosti o přijetí změn jsou partnerské kontroly, které často odhalí nezjištěné chyby, 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 šampióna zabezpečení nebo znalost týmu zabezpečení, který může vést vývojáře během procesu peer review.

Pokyny pro bezpečné kódování pomáhají vývojářům naučit se základní principy bezpečného kódování a 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é můžou vývojáři snadno spolupracovat. Povolení mnoha spolupracovníků na jediném základu kódu ale také představuje riziko 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 prohledávání úložiště provádějí analýzu statického kódu ve zdrojovém kódu v rámci úložišť. 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čnou zárukou pro distribuované týmy, kde mnoho lidí spolupracuje ve stejném úložišti.

Správa závislostí

Až 90 procent kódu v aktuálních aplikacích obsahuje prvky externích balíčků a knihoven nebo je založené na těchto prvcích. Při přijetí závislostí ve zdrojovém kódu je nezbytné řešit potenciální rizika. Mnoho knihoven třetích stran má vážné problémy se zabezpečením. Vývojáři také nechovají konzistentně podle nejlepšího životního cyklu a udržují závislosti aktuální.

Ujistěte se, že váš vývojový tým ví, které komponenty mají do svých aplikací zahrnout. Budou si chtít stáhnout zabezpečené a aktuální verze ze známých zdrojů. A budou chtít mít proces 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í informačních kanálů privátních balíčků.

Testování zabezpečení statických aplikací

Jakmile váš tým řeší knihovny třetích stran a správu balíčků, je nezbytné zaměřit se a zlepšit zabezpečení kódu. Existují různé způsoby, jak zlepšit zabezpečení kódu. 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é statické analýzy předběžné potvrzení a potvrzení kontroly, jak je popsáno dříve. Je také možné provést úplnou kontrolu zdrojového kódu a zachytit chyby zmeškané předchozími kroky. Je to nutné, ale může trvat hodiny nebo dokonce dny, než se naskenuje 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 v rámci kontinuální integrace. Tato metoda ověřuje 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. Sleduje kvalitu a styl kódu a má kontrolní nástroje specifické pro zabezpečení. Na trhu je ale k dispozici mnoho dalších komerčních a opensourcových nástrojů.

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é chcete opravit. Je také vhodné implementovat pracovní postup, který brání potvrzení kódu do výchozí větve, pokud dojde k zjištění. Chtěli byste pokrýt kvalitu i bezpečnostní zjištění. Zabezpečení se tak stane součástí prostředí pro 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čí kód vývojáře do centrálního základu kódu podle běžného plánu a automaticky spouští standardní sestavení a testovací procesy.

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

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

Sestavení a testování

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

Použití kanálů 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í. Jako součást automatizace by vývojové týmy měly zahrnovat nástroje zabezpečení, které spouštějí skriptované automatizované testy při nasazování kódu do testovacích prostředí. Testy by měly zahrnovat testování částí na funkcích 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 vývojovém modelu vodopádu se zabezpečení obvykle zavedlo v posledním kroku těsně 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, jak je blízko myšlení útočníka.

Penetrační test se skládá z několika akčních bodů, z nichž jeden je dynamický test zabezpečení aplikace (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 kontroly ohrožení zabezpečení webové aplikace. 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 kontroly OWASP ZAP: pasivní základní kontrola nebo úplná kontrola v závislosti na konfiguraci.

Nevýhodou testování pera je, že to nějakou dobu trvá. 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ý. Ale stále stojí za to přidat světlejší verzi testování pera během procesu vývoje, aby se odhalily problémy, které SAST vynechal a další kroky. Nástroje DAST, jako je OWASP ZAP, 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 výsledky publikuje. Tento přístup nemusí být dokonalý, protože není kompletní penetrační testování, ale je stále cenný. Je to ještě jedna míra kvality ve 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 jsou také zabezpečená prostředí, do které nasazujete aplikace. Zabezpečená prostředí jsou klíčová pro organizace, které chtějí postupovat tempem, 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í.

Možnosti Azure umožňují organizacím vytvářet standardy zabezpečení z prostředí, jako je Azure Policy. Týmy můžou k vytváření sad zásad použít Azure Policy. Sady zásad brání vytvoření určitých typů úloh nebo položek konfigurace, jako jsou veřejné IP adresy. Tyto 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 Může DevOps postupně přivést vývojáře a operace, je podporovat převod stávající infrastruktury na přístup typu infrastruktura jako kód.

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í při každém použití. IaC je klíčovou praxí 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 stejné akce zabezpečení na infrastrukturu 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.

Při přijetí cloudu je kontejnerizace oblíbeným přístupem, který týmy přijmou při rozhodování 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. Kvůli tomuto riziku je důležité zkontrolovat kontejner z hlediska bezpečnostních rizik. 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 naučit 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, 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

Penetrační testování je doporučeným postupem zkontrolovat všechna 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í se obvykle týká následujících typů testů:

  • Testování koncových bodů za účelem odhalení ohrožení zabezpečení
  • Přibližné testování (vyhledání chyb programu zadání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í postupovat tempem a experimentovat s novými technologiemi, jejichž cílem je 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. Řada organizací se rozhodne integrovat výstrahy a data o využití do své platformy pro správu IT služeb (ITSM). Tým pak může stejný strukturovaný pracovní postup přenést do událostí zabezpečení, které používají pro jiné incidenty a požadavky.

Smyčky zpětné vazby

Screenshot showing the Continuous security model.

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 zpětné vazby, která umožňuje rychle řešit problémy a minimalizovat riziko ohrožení zabezpečení co nejvíce.

Běžným vzorem zpětné vazby je integrace do systému pro správu práce vývojáře, jako je Azure DevOps nebo GitHub. Organizace může propojit výstrahy nebo incidenty s pracovními položkami, aby vývojáři mohli plánovat a reagovat. Tento proces poskytuje vývojářům efektivní způsob řešení problémů ve standardním pracovním postupu, včetně vývoje, testování a vydání.