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ý životní cyklus vývoje pomocí posíleného, většinou automatizovaného a auditovatelného dodavatelského řetězce softwaru. Začlenit zabezpečený návrh s využitím modelování hrozeb k ochraně před implementacemi, které mají dopad na zabezpečení.

Související příručka: Analýza hrozeb

Tato příručka popisuje doporučení pro posílení zabezpečení kódu, vývojového prostředí a dodavatelského řetězce softwaru použitím osvědčených postupů zabezpečení v průběhu vývojového cyklu. Abyste tomuto návodu porozuměli, 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í, ke kontrole ohrožení zabezpečení v kódu a infrastruktuře jako kódu (IaC).

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

Nestačí zabezpečit jenom rovinu infrastruktury pomocí ovládacích prvků identit a sítí a dalších opatření. Zabraňte chybné implementaci kódu nebo narušení bloku kódu , abyste posílili celkový stav zabezpečení. Musí být také posílena rovina využití, tj. kód aplikace. 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 i zpřísnění vývoje kódu nezávislé na kontextu. Zaměřuje se na zvýšení zabezpečení, nikoli na funkční požadavky aplikace. Informace související s posílením zabezpečení najdete v tématu Doporučení pro prostředky posílení zabezpečení.

Definice

Období Definice
Security Development Lifecycle (SDL) Sada postupů poskytovaná Microsoftem, která podporuje zabezpečení a požadavky na dodržování předpisů.
Životní cyklus vývoje softwaru (SDLC) Vícestupňový systematický proces pro vývoj softwarových systémů.

Klíčové strategie návrhu

Bezpečnostní opatření by měla být do vašeho stávajícího životního cyklu vývoje softwaru (SDLC) integrovaná na více místech, aby se zajistilo:

  • Volby návrhu nevedou k mezerám v zabezpečení.

  • Kód a konfigurace aplikace nevytvoří ohrožení 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 nezanáší bezpečnostní hrozby.

  • S procesy kódu, sestavení a nasazení aplikace se nehýbá.

  • Ohrožení zabezpečení odhalená prostřednictvím incidentů se zmírní.

  • Nevyužité prostředky se řádně 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ě nacvičované fáze SDLC.

Fáze požadavků

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ůsobeny 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í s daty a zabránění injektáži SQL. Podobně pokrýváme požadavky, které nejsou funkční, jako je dostupnost, škálovatelnost a udržovatelnost. Možnosti zabezpečení by měly zahrnovat hranice segmentace, příchozí a výchozí přenos dat brány firewall a další otázky týkající se horizontálního 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 promítte je do backlogu. Měl by explicitně uvádět investice do zabezpečení, kompromisy a rizika, které je firma ochotná přijmout, pokud tyto investice neschválí obchodní účastníci. Můžete například zdokumentovat potřebu použití Firewallu webových aplikací (WAF) před vaší aplikací, jako je Azure Front Door nebo Azure Application Gateway. Pokud obchodní účastníci nejsou připraveni přijmout dodatečné náklady na provoz WAF, musí přijmout riziko, že útoky na aplikační vrstvu mohou 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 neoznačené volbě, což může vést k nedostatkům zabezpečení. Možná budete muset implementaci později změnit, aby vyhovovala zabezpečení, což může být nákladné.

Fáze návrhu

Během této fáze 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 jsou některé typické úlohy:

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é pro komponenty aplikace a typ šifrovacích metod, které se mají použít. Ukázkové architektury najdete na ilustracích v částech Příklady v článcích Správa identit a přístupu aSítě .

Vyhodnocení cen poskytovaných platformou

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

Pokud například váš návrh vyžaduje firewall webových aplikací při příchozím přenosu dat, můžete tuto odpovědnost přenést 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. Návrh by měl také určovat zabezpečenou správu verzí. Závislosti aplikací by měly pocházet 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 plán zodpovědného zpřístupnění. Všechny incidenty zabezpečení by se měly okamžitě nahlásit, abyste mohli provést nezbytné akce. Vaše organizace může také některé knihovny zakázat. Například software může být zabezpečený před ohroženími zabezpečení, ale stále může být zakázaný kvůli licenčním omezením.

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

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

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

Další informace najdete v tématu Způsoby 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ých klíčů, které vaše aplikace používá. Přihlašovací údaje a tajné kódy aplikací by nikdy neměly být uložené ve stromu zdrojového kódu. Použijte externí prostředky, jako je Azure Key Vault, abyste zajistili, že pokud bude váš zdrojový kód k dispozici potenciálnímu útočníkovi, nebude možné získat žádný další přístup. Obecně najděte způsoby, jak se vyhnout tajným kódům. Použití spravovaných identit, pokud je to možné, je 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 ve svých kanálech automatizovat. Pokud má váš tým procesy pro ruční testování, zahrňte požadavky na zabezpečení pro tyto testy.

Poznámka

Během této fáze proveďte modelování hrozeb. Modelování hrozeb může potvrdit, že volby návrhu odpovídají požadavkům na zabezpečení a odhalí 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.

Počáteční modelování hrozeb by mělo proběhnout ve fázi návrhu, kdy se definuje architektura softwaru a návrh vysoké úrovně. 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 předtí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 po celou dobu vývoje softwaru.

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

Fáze vývoje a testování

Během této fáze je cílem zabránit chybám zabezpečení a manipulaci s kódem, buildem a kanály nasazení.

Být dobře natrénovaný v postupech zabezpečeného kódu

Vývojový tým by měl mít formální a specializované školení v oblasti postupů bezpečného kódování. Vývojáři webů a rozhraní API mohou například potřebovat konkrétní školení, aby se chránili před skriptovacími útoky 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.

Vývojáři by měli být povinni absolvovat toto školení, aby mohli získat přístup ke zdrojovému kódu v produkčním prostředí.

Měli byste také provádět interní kontroly kódu peerů, abyste podpořili průběžné učení.

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

Proveďte modelování hrozeb a vyhodnoťte zabezpečení architektury aplikace.

Pomocí statického testování zabezpečení aplikací (SAST) analyzujte kód z hlediska ohrožení zabezpečení. Integrujte tuto metodologii do vývojového prostředí, abyste mohli detekovat ohrožení zabezpečení v reálném čase.

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

Dodržujte oborové standardy pro postupy bezpečného kódování. Další informace najdete v tomto článku v části Zdroje informací komunity .

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. Například analyzátory .NET Compiler Platform (Roslyn) kontrolují kód aplikace.

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

Použijte kombinaci testů. Obecné informace o testování zabezpečení najdete v tématu Doporučení pro testování zabezpečení.

Napsat jenom dostatečný počet 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ěřením zabezpečení místo duplikování kódu.

Využívání výhod 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í můžete psát kód s přístupem odepřít vše. Vytvářejte seznamy 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 povolená privilegovaná operace, měli byste ho zapsat tak, aby byl výsledek zamítnutí výchozím případem a výsledek povolení nastal pouze v případě, že to kód výslovně povoluje.

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

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

Agenti sestavení jsou vysoce privilegovaní a mají přístup k buildovacímu serveru a kódu. Musí být chráněné se stejnou přísnou ochranou jako komponenty úloh. To znamená, že přístup k agentům sestavení musí být ověřený a autorizovaný, musí být segmentovaný na síť s ovládacími prvky brány firewall, musí podléhat kontrole ohrožení zabezpečení atd. Agenti sestavení hostovaní Microsoftem by měli být upřednostňováni před agenty sestavení v místním prostředí. Agenti hostovaní Microsoftem poskytují výhody, jako je vyčištění virtuálních počítačů 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 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ů. Izolace sítě můžete dosáhnout tím, že povolíte jenom odchozí provoz z agenta sestavení, protože používá model vyžádání komunikace s Azure DevOps.

Úložiště zdrojového kódu musí být také chráněné . Udělte přístup k úložištím kódu na základě potřeby a co nejvíce omezte odhalení ohrožení zabezpečení, abyste se vyhnuli útokům. Projděte si důkladný proces kontroly chyb zabezpečení v kódu . Použijte k tomu skupiny zabezpečení a implementujte schvalovací proces, který je založený na obchodních odůvodněních.

Zabezpečená nasazení kódu

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 vydaných verzí musí být také chráněná , protože chcete zabránit špatným účastníkům ve spouštění škodlivého kódu v kanálu.

Udržujte aktuální inventář všech komponent, které jsou integrované do vaší aplikace.

Každá nová komponenta, která je integrovaná do aplikace, zvyšuje prostor pro útok. Abyste zajistili 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ě kontrolujte, jestli manifest odpovídá tomu, co je v procesu sestavení. Tím zajistíte, aby se neočekávaně nepřidály žádné nové komponenty, které obsahují zadní vrátka nebo jiný malware.

Úlohy kanálu

  • Načítejte si úkoly v kanálu z důvěryhodných zdrojů, jako je Azure Marketplace. Spouštějte úlohy napsané dodavatelem kanálu. Doporučujeme úlohy githubu nebo GitHub Actions. Pokud používáte pracovní postupy GitHubu, dáte přednost úkolům vytvořeným Microsoftem. Ověřte také úlohy, protože se spouští v kontextu zabezpečení vašeho kanálu.

  • Tajné kódy kanálu. Prostředky nasazení, které běží uvnitř 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 mějte správnou segmentaci , abyste se vyhnuli zbytečnému ohrožení. Použijte úložiště tajných kódů, která jsou integrovaná v 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 se musí uchovávat 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é bezpečnostní kontroly jako produkční prostředí. Vyhněte se připojení z neprodukční aplikace k produkční databázi a připojení neprodukčních komponent k produkčním sítím.

Progresivní expozice

Postupné vystavení funkcí podmnožině uživatelů na základě zvolených kritérií. Pokud dojde k problémům, dopad na tyto uživatele se minimalizuje. Tento přístup představuje běžnou strategii pro zmírnění rizik, protože snižuje povrchovou plochu. S tím, jak tato funkce vyzrává a vy máte větší důvěru v záruky zabezpečení, můžete ji postupně vydávat pro širší skupinu uživatelů.

Fáze výroby

Produkční fáze představuje poslední zodpovědnou příležitost k opravě nedostatků zabezpečení. Udržujte si záznamy o zlatém obrázku, který je vydaný v produkčním prostředí.

Zachovat artefakty 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írňování problémů a při obnovení funkčního stavu systému. Prostředky s verzí lze také porovnat s publikovanými oznámeními CVE (Common Vulnerabilities and Exposures). K provedení těchto porovnání byste měli použít automatizaci.

Nouzové opravy

Automatizovaný návrh kanálu by měl mít flexibilitu pro podporu pravidelného i nouzového 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í nouzového procesu, který urychlí opravy zabezpečení. Tento proces může zahrnovat komunikaci mezi týmy. Kanál by měl umožňovat rychlé roll-forward a rollback 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řednostnit 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 nouzového kanálu, pečlivě zvažte, které automatizované testy je možné obejít. Vyhodnoťte hodnotu každého testu proti době provádění. Například testy jednotek se obvykle dokončí rychle. Integrační nebo kompletní testy můžou běžet dlouhou dobu.

Fáze údržby

Cílem této fáze je zajistit, aby se stav zabezpečení v průběhu času nezhoršil. SDLC je průběžný agilní proces. Koncepty popsané v předchozích fázích se vztahují na tuto fázi, protože požadavky se v průběhu času mění.

Správa oprav. Udržujte software, knihovny a komponenty infrastruktury v aktuální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, získané poznatky a vyvíjející se hrozby.

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

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

Průběžně vylepšujte 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 zabezpečené postupy, které můžete použít pro životní cyklus vývoje. Další informace najdete v tématu Životní cyklus vývoje zabezpečení Microsoftu.

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í vaší organizace.

Postupujte podle doporučení k zabezpečení Azure, která jsou popsaná v těchto zdrojích informací:

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í jakéhokoli 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í