Doporučení pro zabezpečení životního cyklu vývoje

  • Článek

Platí pro toto doporučení kontrolního seznamu zabezpečení architektury Azure Well-Architected Framework:

SE:02 Udržujte zabezpečený vývojový životní cyklus pomocí posíleného, většinou automatizovaného a auditovatelného softwarového dodavatelského řetězce. Zabudování zabezpečeného návrhu pomocí modelování hrozeb k ochraně před implementacemi porazí zabezpečení.

Související průvodce: Analýza hrozeb

Tato příručka popisuje doporučení pro posílení kódu, vývojového prostředí a dodavatelského řetězce softwaru pomocí osvědčených postupů zabezpečení v průběhu vývojového cyklu. Abyste pochopili tyto pokyny, měli byste mít znalosti DevSecOps.

Diagram cyklu zabezpečení

DevSecOps integruje zabezpečení do procesů DevOps pomocí:

  • Automatizace testování a ověřování zabezpečení

  • Implementace nástrojů, jako jsou kanály zabezpečení pro kontrolu kódu a infrastruktury jako kódu (IaC), z hlediska ohrožení zabezpečení

Jádrem úlohy je aplikační kód, který implementuje obchodní logiku. Kód a proces vývoje kódu musí být bez chyb zabezpečení, aby se zajistila důvěrnost, integrita a dostupnost.

Nestačí zabezpečit pouze rovinu infrastruktury pomocí ovládacích prvků pro identitu a sítě a další míry. Zabránění chybné implementaci kódu nebo ohroženého bloku kódu za účelem posílení celkového stavu zabezpečení Rovina použití, to znamená kód aplikace, musí být také posílena. Proces integrace zabezpečení do životního cyklu vývoje je v podstatě proces posílení zabezpečení. Podobně jako posílení zabezpečení prostředků je také zpřísnění vývoje kódu nezávislé na kontextu. Zaměřuje se na zvýšení zabezpečení a ne na funkční požadavky aplikace. Informace související s posílením zabezpečení najdete v tématu Doporučení pro posílení zabezpečení prostředků.

Definice

Pojem definice
Security Development Lifecycle (SDL) Sada postupů poskytovaných Microsoftem, která podporuje požadavky na zajištění zabezpečení a dodržování předpisů.
Životní cyklus vývoje softwaru (SDLC) Multistage, systematický proces vývoje softwarových systémů.

Klíčové strategie návrhu

Bezpečnostní opatření by měla být integrována v několika bodech do stávajícího životního cyklu vývoje softwaru (SDLC), aby se zajistilo:

  • Volby návrhu nemají za následek mezery v zabezpečení.

  • Kód aplikace a konfigurace nevytvořily chyby zabezpečení kvůli zneužitelné implementaci a nesprávným postupům kódování.

  • Software získaný prostřednictvím dodavatelského řetězce nezavádí bezpečnostní hrozby.

  • Kód aplikace, sestavení a procesy nasazení nejsou manipulovány.

  • Zmírňují se ohrožení zabezpečení odhalená prostřednictvím incidentů.

  • Nevyužité prostředky se správně vyřadí z provozu.

  • Požadavky na dodržování předpisů nejsou ohroženy ani omezeny.

  • Protokolování auditu se implementuje ve vývojářských prostředích.

Následující části obsahují strategie zabezpečení pro běžně používané fáze SDLC.

Shromáždění a zdokumentování požadavků na zabezpečení

Cílem fáze požadavků je shromáždit a analyzovat funkční a nefunkční požadavky na aplikaci nebo novou funkci aplikace. Tato fáze je důležitá, protože usnadňuje vytváření mantinelí, které jsou přizpůsobené cílům aplikace. Ochrana dat a integrity vaší aplikace by měla být základním požadavkem v každé fázi životního cyklu vývoje.

Představte si například aplikaci, která potřebuje podporovat kritické toky uživatelů, které uživateli umožňují nahrávat data a manipulovat s nimi. Možnosti návrhu zabezpečení by měly zahrnovat záruky pro interakci uživatele s aplikací, jako je ověřování a autorizace identity uživatele, povolení pouze povolených akcí na datech a zabránění injektáži SQL. Podobně se vztahují na požadavky, které nejsou funkční, jako je dostupnost, škálovatelnost a udržovatelnost. Mezi volby zabezpečení by měly patřit hranice segmentace, příchozí přenos dat brány firewall a výchozí přenos dat a další aspekty zabezpečení.

Všechna tato rozhodnutí by měla vést k dobré definici stavu zabezpečení aplikace. Zdokumentujte požadavky na zabezpečení ve schválené specifikaci a reflektujte je v backlogu. Měl by explicitně uvést investice do zabezpečení a kompromisy a rizika, která firma chce přijmout, pokud investice nejsou schváleny obchodními zúčastněnými stranami. Můžete například zdokumentovat potřebu použití firewallu webových aplikací (WAF) před vaší aplikací, jako je Azure Front Door nebo Aplikace Azure lication Gateway. Pokud obchodní účastníci nejsou připravení přijmout další náklady na provoz WAF, musí přijmout riziko, že útoky na aplikační vrstvu můžou být směrovány na aplikaci.

Shromažďování požadavků na zabezpečení je důležitou součástí této fáze. Bez tohoto úsilí budou fáze návrhu a implementace založeny na nestatných volbách, což může vést k mezerám v zabezpečení. Možná budete muset později změnit implementaci tak, aby vyhovovala zabezpečení, což může být nákladné.

Překlad požadavků na zabezpečení na technické požadavky

Během fáze návrhu se požadavky na zabezpečení převedou na technické požadavky. Ve své technické specifikaci zdokumentujte všechna rozhodnutí o návrhu, aby se zabránilo nejednoznačnosti během implementace. Tady je několik typických úloh:

Definování dimenze zabezpečení architektury systému

Překryjte architekturu ovládacími prvky zabezpečení. Například ovládací prvky, které jsou praktické na hranicích izolace podle strategie segmentace, typy identit potřebných pro komponenty aplikace a typ metod šifrování, které se mají použít. Příklady architektur najdete na ilustracích v příkladech článků o správě identit a přístupu a sítích .

Vyhodnocení cen poskytovaných platformou

Je důležité pochopit rozdělení odpovědnosti mezi vás a poskytovatelem cloudu. Vyhněte se překrývání s nativními bezpečnostními prvky Azure, například. Získáte lepší pokrytí zabezpečení a budete moct přidělit vývojové prostředky potřebám aplikace.

Pokud například návrh volá bránu firewall webových aplikací při příchozím přenosu dat, můžete tuto zodpovědnost přesměrovat na nástroj pro vyrovnávání zatížení, jako je Application Gateway nebo Azure Front Door. Vyhněte se replikaci funkcí jako vlastního kódu ve vaší aplikaci.

Zvolte jenom důvěryhodné architektury, knihovny a software dodavatelského řetězce. Váš návrh by měl také určovat zabezpečenou správu verzí. Závislosti aplikací by měly být zdrojové od důvěryhodných stran. Dodavatelé třetích stran by měli být schopni splnit vaše požadavky na zabezpečení a sdílet svůj zodpovědný plán zpřístupnění informací. Všechny incidenty zabezpečení by se měly okamžitě oznámit, abyste mohli provést nezbytné akce. Některé knihovny mohou být také zakázány vaší organizací. Software může být například zabezpečený před ohroženími zabezpečení, ale stále je nepovolen kvůli licenčním omezením.

Pokud chcete zajistit, aby tyto pokyny sledovali všichni přispěvatelé softwaru, udržujte seznam schválených a/nebo neschválené architektury, knihoven a dodavatelů. Pokud je to možné, umístěte do vývojových kanálů ochranné mantinely pro podporu seznamu. Co nejvíce zautomatizujte použití nástrojů ke kontrole ohrožení zabezpečení závislostí .

Určete vzory návrhu zabezpečení, které by měl implementovat kód aplikace.

Vzory můžou podporovat aspekty zabezpečení, jako jsou segmentace a izolace, silná autorizace, jednotné zabezpečení aplikací a moderní protokoly. Některé provozní vzory, jako je například model karantény, můžou pomoct ověřit a blokovat použití softwaru, který by mohl potenciálně zavádět ohrožení zabezpečení.

Další informace najdete v tématu Vzory návrhu cloudu, které podporují zabezpečení.

Bezpečné ukládání tajných kódů aplikací

Bezpečně implementujte použití tajných kódů aplikací a předsdílené klíče, které vaše aplikace používá. Přihlašovací údaje a tajné kódy aplikací by nikdy neměly být uloženy ve stromu zdrojového kódu. Pomocí externích prostředků, jako je Azure Key Vault, se ujistěte, že pokud je váš zdrojový kód dostupný potenciálnímu útočníkovi, není možné získat další přístup. Obecně můžete najít způsoby, jak se vyhnout tajným kódům. Pokud je to možné, je použití spravovaných identit jedním ze způsobů, jak tohoto cíle dosáhnout. Další informace najdete v tématu Doporučení pro správu tajných kódů aplikací.

Definování testovacích plánů

Definujte jasné testovací případy pro požadavky na zabezpečení. Vyhodnoťte, jestli můžete tyto testy automatizovat ve svých kanálech. Pokud váš tým má procesy ručního testování, uveďte požadavky na zabezpečení pro tyto testy.

Poznámka:

Modelování hrozeb v této fázi. Modelování hrozeb může potvrdit, že volby návrhu odpovídají požadavkům na zabezpečení a zpřístupňují mezery, které byste měli zmírnit. Pokud vaše úloha zpracovává vysoce citlivá data, investujte do odborníků na zabezpečení, kteří vám můžou pomoct s modelováním hrozeb.

Při definování architektury softwaru a návrhu vysoké úrovně by mělo během fáze návrhu dojít k počátečnímu cvičení modelování hrozeb. Když to uděláte během této fáze, pomůže vám to identifikovat potenciální problémy se zabezpečením, než se začlení do struktury systému. Toto cvičení ale není jednorázová aktivita. Je to nepřetržitý proces, který by měl pokračovat v průběhu vývoje softwaru.

Další informace najdete v tématu Doporučení pro analýzu hrozeb.

Postupy zabezpečeného vývoje a testování

Během fáze vývoje a testování je cílem zabránit chybám zabezpečení a manipulovat s kódem, sestavením a kanály nasazení.

Dobře natrénovat v zabezpečených postupech kódu

Vývojový tým by měl mít formální a specializované školení v zabezpečených postupech kódování. Vývojáři webových aplikací a rozhraní API mohou například potřebovat konkrétní školení pro ochranu před útoky skriptování mezi weby a back-endoví vývojáři můžou těžit z hloubkového trénování, aby se vyhnuli útokům na úrovni databáze, jako jsou útoky prostřednictvím injektáže SQL.

Aby vývojáři mohli získat přístup ke zdrojovému kódu produkčního prostředí, musí toto trénování dokončit.

Měli byste také provádět interní kontroly partnerského kódu pro podporu průběžného učení.

Použití nástrojů pro testování zabezpečení

Modelování hrozeb vyhodnoťte zabezpečení architektury aplikace.

K analýze ohrožení zabezpečení kódu použijte testování zabezpečení statických aplikací (SAST ). Integrujte tuto metodologii do vývojového prostředí a detekujte ohrožení zabezpečení v reálném čase.

Během běhu používejte dynamické testování zabezpečení aplikací (DAST ). Tento řetěz nástrojů může kontrolovat chyby v doménách zabezpečení a simulovat sadu útoků za účelem testování odolnosti zabezpečení aplikace. Pokud je to možné, integrujte tento nástroj do kanálů buildu.

Dodržujte oborové standardy pro postupy zabezpečeného kódování. Další informace najdete v části Komunitní zdroje tohoto článku.

Pomocí linterů a analyzátorů kódu zabráníte vložení přihlašovacích údajů do úložiště zdrojového kódu. Analyzátory .NET Compiler Platform (Roslyn) například kontrolují kód vaší aplikace.

Během procesu sestavení použijte doplňky kanálu k zachycení přihlašovacích údajů ve zdrojovém kódu. Prohledejte všechny závislosti, jako jsou knihovny třetích stran a komponenty architektury, jako součást procesu kontinuální integrace. Prozkoumejte ohrožené komponenty, které nástroj označí příznakem. Zkombinujte tuto úlohu s dalšími úlohami kontroly změn kódu, které kontrolují četnost změn kódu, výsledky testů a pokrytí.

Použijte kombinaci testů. Obecné informace otestováních

Napsat jen dostatek kódu

Když snížíte nároky na kód, snížíte také riziko chyb zabezpečení. Opakovaně používejte kód a knihovny, které se už používají a prošly ověřováním zabezpečení, místo duplikování kódu.

Použití funkcí Azure je dalším způsobem, jak zabránit zbytečnému kódu. Jedním ze způsobů je použití spravovaných služeb. Další informace najdete v tématu Použití možností paaS (platforma jako služba).

Ve výchozím nastavení napište kód se odepřením všech přístupů. Vytváření seznamů povolených jenom pro entity, které potřebují přístup. Pokud máte například kód, který potřebuje určit, jestli má být privilegovaná operace povolená, měli byste ji napsat tak, aby výsledek zamítnutí byl výchozím případem a výsledek povolení nastane pouze tehdy, když je výslovně povolený kódem.

Ochrana vývojářských prostředí

Vývojářské pracovní stanice musí být chráněné silnými síťovými ovládacími prvky a ovládacími prvky identit, aby se zabránilo vystavení. Ujistěte se, že jsou aktualizace zabezpečení aplikovány pečlivě.

Agenti sestavení jsou vysoce privilegovaní a mají přístup k buildovacímu serveru a kódu. Musí být chráněny se stejnou kategorií jako součásti úloh. To znamená, že přístup k agentům sestavení musí být ověřený a autorizovaný, měly by být segmentované sítí s ovládacími prvky brány firewall, měly by podléhat kontrole ohrožení zabezpečení atd. Agenti sestavení hostovaní Microsoftem by měli být upřednostňovaní před agenty sestavení hostovanými v místním prostředí. Agenti hostovaní Microsoftem poskytují výhody, jako jsou čisté virtuální počítače pro každé spuštění kanálu.

Vlastní agenti sestavení přidávají složitost správy a můžou se stát vektorem útoku. Přihlašovací údaje počítače k sestavení musí být bezpečně uložené a je potřeba pravidelně odebírat všechny dočasné artefakty sestavení ze systému souborů. Izolaci sítě můžete dosáhnout tím, že povolíte odchozí provoz jenom z agenta sestavení, protože používá model vyžádané komunikace s Azure DevOps.

Úložiště zdrojového kódu musí být také chráněno . Udělte přístup k úložištím kódu na základě potřeb a omezte ohrožení zabezpečení co nejvíce, abyste se vyhnuli útokům. Důkladně si projděte kód pro ohrožení zabezpečení. Pro tento účel používejte skupiny zabezpečení a implementujte schvalovací proces založený na obchodních odůvodněních.

Ochrana kódu v kanálech nasazení

Nestačí jen zabezpečit kód. Pokud běží v zneužitelných kanálech, veškeré úsilí o zabezpečení je zbytečné a neúplné. Prostředí sestavení a verzí musí být také chráněná , protože chcete zabránit škodlivým objektům actor ve spouštění škodlivého kódu ve vašem kanálu.

Udržujte aktuální inventář všech komponent integrovaných do vaší aplikace.

Každá nová komponenta integrovaná do aplikace zvyšuje prostor pro útoky. Pokud chcete zajistit správnou odpovědnost a upozorňování při přidání nebo aktualizaci nových komponent, měli byste mít inventář těchto komponent. Uložte ho mimo prostředí sestavení. Pravidelně zkontrolujte, jestli manifest odpovídá tomu, co je v procesu sestavení. Tím se zajistí, že se neočekávaně nepřidají žádné nové komponenty, které obsahují zadní dveře nebo jiný malware.

Úlohy kanálu

  • Načítejte úkoly v kanálu z důvěryhodných zdrojů, jako je Azure Marketplace. Spouštění úloh, které napsal váš dodavatel kanálu Doporučujeme úlohy GitHubu nebo GitHub Actions. Pokud používáte pracovní postupy GitHubu, upřednostněte úkoly vytvořené Microsoftem. Také ověřte úlohy, protože běží v kontextu zabezpečení vašeho kanálu.

  • Tajné kódy kanálu Prostředky nasazení, které běží v kanálu, mají přístup ke všem tajným kódům v daném kanálu. Pro různé fáze kanálu je vhodné segmentaci, aby se zabránilo zbytečné expozici. Používejte úložiště tajných kódů, která jsou integrovaná do kanálu. Nezapomeňte, že v některých situacích se můžete vyhnout používání tajných kódů. Prozkoumejte použití identit úloh (pro ověřování kanálů) a spravovaných identit (pro ověřování mezi službami).

Oddělení různých prostředí

Data používaná v různých prostředích musí být oddělená. Produkční data by se neměla používat v nižších prostředích, protože tato prostředí nemusí mít přísné kontrolní mechanismy zabezpečení, které má produkční prostředí. Vyhněte se připojení z neprodukční aplikace k produkční databázi a vyhněte se připojení neprodukčních komponent k produkčním sítím.

Progresivní expozice

Pomocí progresivní expozice můžete uvolnit funkce pro podmnožinu uživatelů na základě zvolených kritérií. Pokud dojde k problémům, dopad se na tyto uživatele minimalizuje. Tento přístup je běžnou strategií pro zmírnění rizik, protože snižuje plochu. S tím, jak funkce zralá a máte větší důvěru v záruky zabezpečení, můžete ji postupně uvolnit pro širší sadu uživatelů.

Ochrana kódu v produkčním prostředí

Produkční fáze představuje poslední zodpovědnou příležitost k opravě mezer zabezpečení. Uchovávejte záznam zlaté image vydané v produkčním prostředí.

Zachování artefaktů s verzí

Udržujte katalog všech nasazených prostředků a jejich verzí. Tyto informace jsou užitečné při třídění incidentů, při zmírnění problémů a při návratu systému do pracovního stavu. Prostředky s verzí je možné porovnat také s publikovanými běžnými oznámeními o ohroženích zabezpečení a ohroženích (CVE). K provedení těchto porovnání byste měli použít automatizaci.

Opravy tísňového volání

Návrh automatizovaného kanálu by měl mít flexibilitu pro podporu pravidelných i nouzových nasazení. Tato flexibilita je důležitá pro podporu rychlých a zodpovědných oprav zabezpečení.

Vydání je obvykle spojeno s více schvalovacími branami. Zvažte vytvoření tísňového procesu, který urychlí opravy zabezpečení. Proces může zahrnovat komunikaci mezi týmy. Kanál by měl umožňovat rychlé postupné a vrácení zpět nasazení, která řeší opravy zabezpečení, kritické chyby a aktualizace kódu, ke kterým dochází mimo běžný životní cyklus nasazení.

Poznámka:

Vždy upřednostněte opravy zabezpečení před pohodlím. Oprava zabezpečení by neměla zavádět regresi nebo chybu. Pokud chcete opravu urychlit prostřednictvím kanálu tísňového volání, pečlivě zvažte, které automatizované testy je možné obejít. Vyhodnoťte hodnotu každého testu v době provádění. Testy jednotek se například obvykle rychle dokončí. Integrace nebo kompletní testy můžou běžet dlouhou dobu.

Zachování zabezpečení kódu v průběhu životního cyklu

Cílem této fáze je zajistit, aby se stav zabezpečení v průběhu času nezkazil. SDLC je probíhající agilní proces. Koncepty popsané v předchozích fázích platí pro tuto fázi, protože se požadavky v průběhu času mění.

Správa oprav: Udržujte software, knihovny a komponenty infrastruktury v aktualizovaném stavu pomocí oprav zabezpečení a aktualizací.

Průběžné vylepšování. Průběžně vyhodnocujte a vylepšujte zabezpečení procesu vývoje softwaru s ohledem na revize kódu, zpětnou vazbu, poznatky získané a vyvíjející se hrozby.

Vyřazení starších prostředků z provozu, které jsou zastaralé nebo už se nepoužívají Tím se zmenšuje plocha aplikace.

Údržba také zahrnuje opravy incidentů. Pokud dojde k problémům v produkčním prostředí, je potřeba je okamžitě integrovat zpět do procesu, aby se nemusely opakovat.

Průběžně vylepšujte své postupy zabezpečeného kódování, abyste udrželi krok s prostředím hrozeb.

Usnadnění azure

Microsoft Security Development Lifecycle (SDL) doporučuje bezpečné postupy, které můžete použít pro životní cyklus vývoje. Další informace naleznete v tématu Životní cyklus vývoje zabezpečení společnosti Microsoft.

Defender for DevOps a nástroje SAST jsou součástí GitHub Advanced Security nebo Azure DevOps. Tyto nástroje vám můžou pomoct sledovat skóre zabezpečení pro vaši organizaci.

Postupujte podle doporučení zabezpečení Azure popsaných v těchto prostředcích:

Pokud chcete najít přihlašovací údaje ve zdrojovém kódu, zvažte použití nástrojů, jako jsou GitHub Advanced Security a nástroje pro analýzu zdrojového kódu OWASP.

Ověřte zabezpečení libovolného opensourcového kódu ve vaší aplikaci. S posouzením vám můžou pomoct tyto bezplatné nástroje a zdroje informací:

Kontrolní seznam zabezpečení

Projděte si kompletní sadu doporučení.

Kontrolní seznam zabezpečení