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

Toto doporučení kontrolního seznamu zabezpečení v rámci Azure Well-Architected Framework platí pro:

SE:02 Zarovnejte životní cyklus zabezpečeného vývoje (SDL) v průběhu životního cyklu vývoje softwaru (SDLC), abyste zajistili důvěrnost, integritu a dostupnost softwaru a přijali přístup s prioritou bezpečnosti.

Kód aplikace je jádrem každé úlohy. Vkládání zabezpečení v rámci SDLC integrací ovládacích prvků ve více fázích vývoje Cílem je zajistit, aby rozhodnutí o návrhu nevedla ke vzniku zbytečných mezer v zabezpečení a že volby v oblasti kódu a konfigurace nevyústí ve zneužitelné chyby zabezpečení.

Diagram cyklu zabezpečení

Tato příručka popisuje osvědčené postupy zabezpečení pro ochranu kódu aplikace a zabránění ohrožené implementaci a zavedení ohrožených komponent. Rozšiřte osvědčené postupy na komponenty třetích stran a opensourcových komponent, abyste snížili riziko dodavatelského řetězce. Fokus není na vrstvě infrastruktury.

Pokyny vycházejí z postupů SDL a předpokládají základní znalosti principů DevSecOps. Přesahuje kód aplikace, který řeší celý softwarový dodavatelský řetězec, včetně vývojářských pracovních stanic, zdrojových úložišť, systémů sestavení a prostředí nasazení.

Terminology

Term Definition
Společné zranitelnosti a expozice (CVE) Veřejně dostupná databáze známých ohrožení zabezpečení a ohrožení v softwarových a hardwarových produktech.
Vícevrstvý obranný systém Strategie zabezpečení, která k ochraně systémů používá více vrstev ochrany, takže pokud jedna vrstva selže, ostatní budou dál poskytovat zabezpečení.
DevSecOps Přístup, který integruje postupy zabezpečení do procesu DevOps a zdůrazňuje spolupráci mezi vývojovými, bezpečnostními a provozními týmy v průběhu životního cyklu softwaru.
Dynamické testování zabezpečení aplikací (DAST) Testování zabezpečení, které analyzuje aplikace za běhu za účelem identifikace ohrožení zabezpečení simulací scénářů útoku z reálného světa.
Spravovaná identita Funkce Azure, která poskytuje aplikacím automaticky spravovanou identitu v Microsoft Entra ID a eliminuje nutnost ukládat přihlašovací údaje v kódu.
Progresivní expozice Strategie nasazení, která postupně vydává změny podmnožinám uživatelů, aby minimalizovala riziko a zachytila potenciální problémy.
Životní cyklus vývoje zabezpečení (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) Vícestupňový, systematický proces pro vývoj softwarových systémů.
Testování zabezpečení statických aplikací (SAST) Testování zabezpečení, které analyzuje zdrojový kód, bajtové kódy nebo binární soubory bez spuštění programu za účelem identifikace potenciálních ohrožení zabezpečení.
STRIDE Metodologie modelování hrozeb, která kategorizuje hrozby do šesti typů: Falšování identity, Manipulace, Repudiation, Information Disclosure, Denial of Service a Zvýšení oprávnění.
Zabezpečení dodavatelského řetězce Ochrana celého dodavatelského řetězce softwaru, včetně komponent třetích stran, vývojových nástrojů a procesů před ohrožením nebo manipulací.
Modelování hrozeb Strukturovaný proces pro identifikaci, vyhodnocení a zmírnění potenciálních bezpečnostních hrozeb systému v rané fázi návrhu.

Přemýšlejte o zabezpečení od prvního dne

Během prvních diskuzí o plánování a architektuře definujte funkční i nefunkční požadavky na zabezpečení společně s obchodními cíli. Překryjte architekturu ovládacími prvky zabezpečení. Zamyslete se nad hranicemi izolace, vnějšími a vnitřními přístupy a úrovněmi citlivosti, které se vztahují na data úloh. Doporučujeme pečlivě sledovat kontrolní seznam zabezpečení pro vývoj dimenze zabezpečení architektury. Projděte si také vzory návrhu architektury, které podporují zabezpečení.

Aby byl tým zodpovědný, musí být aspekty zabezpečení a výsledky přidány přímo do položek backlogu, aby byly navrženy a dodány jako součást produktu. Představte si například aplikaci, která podporuje kritické toky uživatelů, které uživatelům umožňují nahrávat data a manipulovat s nimi. Dodávky zabezpečení musí řešit, jak uživatelé komunikují se systémem (vynucují silné ověřování a autorizaci), aby se zajistilo, že jsou povolené pouze povolené akce.

Architekti musí explicitně zdokumentovat kompromisy v oblasti zabezpečení a formalizovat přijetí rizik, aby zajistili transparentnost a odpovědnost. Například rozhodnutí o zabezpečení může vyžadovat opatření k blokování ohrožení zabezpečení OWASP předem. Pokud se účastníci rozhodnou ho nefinanciovat, musí potvrdit a přijmout výsledné riziko útoků na aplikační vrstvu.

Volba možností technologie, které podporují zabezpečení

Identifikujte kontrolní mechanismy zabezpečení potřebné k dosažení požadovaných výsledků a pokud je to možné, využijte nativní funkce Azure. Můžete například definovat strategii segmentace pomocí hranic identit, sítě a prostředků a vybrat firewally webových aplikací (WAF), jako je Azure Front Door nebo Azure Application Gateway, aby se aplikace chránila. Pokud je při příchozím přenosu dat potřeba WAF, používejte tyto spravované služby místo replikace jejich funkcí ve vlastním kódu aplikace.

Mezi technické aspekty patří také výběr jenom důvěryhodných architektur, knihoven a softwaru dodavatelského řetězce, který pochází od ověřených poskytovatelů. Dodavatelé třetích stran musí splňovat vaše požadavky na zabezpečení a udržovat zodpovědný plán zpřístupnění, který okamžitě hlásí všechny incidenty zabezpečení. Udržujte seznam schválených a nepovolených prostředků a pokud je to možné, vynucujte ochranné mantinely ve vývojových kanálech, aby se zabránilo použití neschválených komponent. U schválených závislostí pomáhá automatizovaná kontrola včas a konzistentně zjišťovat ohrožení zabezpečení.

Rozhodněte se, jak bezpečně ukládat tajné kódy aplikací a předsdílené klíče. Nikdy neukládejte přihlašovací údaje ani tajné kódy v úložišti zdrojového kódu. Použijte externí nástroje, jako je Azure Key Vault, aby i když je zdrojový kód vystavený, útočníci nezíská přístup. Pokud je to možné, vyhněte se používání tajných kódů úplně, například využitím spravovaných identit. Další pokyny najdete v tématu Doporučení pro správu tajných kódů aplikací.

Udělejte z modelování hrozeb disciplínu návrhu

Modelování hrozeb pomáhá identifikovat ohrožení zabezpečení, vyhodnotit hrozby a definovat zmírnění rizik v rané fázi návrhu. Začněte definováním rozsahu: nastavte jasné hranice systému a inventarizaci prostředků, abyste se zaměřili na to, co je nejdůležitější. Shromážděte podrobné informace o jednotlivých komponentách, včetně toků dat a závislostí, a analyzujte je z pohledu útočníka, abyste zjistili, jak by se dal zneužít. Přijměte myšlení počítejte s porušením – předpokládejte selhání kontroly a použijte strategii vrstvené ochrany k omezení dopadu.

Pomocí oborové metodologie, jako je STRIDE , klasifikovat hrozby a řídit rozhodnutí o zmírnění rizik. Zdokumentujte každou identifikovanou hrozbu, ovládací prvky, které ji brání, a plán reakce, pokud tyto kontroly selžou. Definujte jasné časové osy a odpovědnost k rychlé nápravě zranitelností, aby nezůstaly neřešené.

Sledujte výsledky modelování hrozeb a sledujte je v průběhu životního cyklu úloh. Aktualizujte model tak, jak se architektura vyvíjí, aby se zajistilo, že nové funkce a změny nezavádějí nespravované riziko.

Odkaz na: Microsoft Threat Modeling Tool

Vytváření odborných znalostí zabezpečeného kódování

Zajistěte, aby vývojový tým dokončil formální školení specifické pro konkrétní roli v zabezpečených postupech kódování. Vývojáři webů a rozhraní API by například měli vědět, jak zabránit skriptování mezi weby (XSS), zatímco back-endoví vývojáři by měli pochopit, jak zmírnit rizika, jako je injektáž SQL a další útoky na databázovou vrstvu. Před udělením přístupu ke zdrojovému kódu v produkčním prostředí vyžadují, aby vývojáři toto trénování dokončili. Posílit tyto dovednosti prostřednictvím interních kontrol partnerských kódů, které podporují odpovědnost, sdílení znalostí a průběžné zlepšování.

Použití testování zabezpečení jako strategického řízení

Testování zabezpečení je základní technická disciplína. Vytvořte testovací strategii, která v průběhu životního cyklu vývoje průběžně vyhodnocuje chování architektury, kódu a modulu runtime. Použijte kombinaci analýz architektury, statického a dynamického testování, skenování závislostí a automatizovaných mantinely.

Pomocí statického testování zabezpečení aplikací (SAST) můžete detekovat zranitelnosti v kódu během procesu jeho psaní vývojáři. Doplňte to dynamickým testováním zabezpečení aplikací (DAST) k vyhodnocení spuštěné aplikace a simulaci scénářů útoku z reálného světa.

Integrujte automatizované skenování zabezpečení do pracovních postupů sestavení a integrace, aby se zabezpečení stalo kvalitativní hranicí. Nepřetržitě kontrolovat závislosti a komponenty třetích stran a zacházet s ohroženými knihovnami jako s riziky dodavatelského řetězce, která vyžadují aktivní správu. Pomocí linterů a analyzátorů kódu můžete zabránit tomu, aby se citlivá data, jako jsou přihlašovací údaje, dostala do systému správy verzí, a posílit tyto ochrany pomocí kontrolních mechanismů v rámci pipeline, které detekují a blokují únik tajných informací.

Osvojte si oborové standardy jako způsob, jak zvýšit spolehlivost odolnosti zabezpečení. Další informace najdete v části Komunitní zdroje tohoto článku.

Napsat jen dostatek kódu

Každý řádek kódu zvyšuje prostor pro útoky. Upřednostněte opětovné použití před znovuvynalézáním. Používejte dobře zavedené architektury a knihovny, které už prošly ověřováním zabezpečení, místo duplikování funkcí ve vlastním kódu.

Osvojte si přístup zaměřený především na platformu. Používejte spravované služby Azure a funkce PaaS, kdykoli je to možné, když je to možné, aby bylo možné převést náročné úlohy do Azure, jako je ověřování, šifrování, škálování a ochrana příchozího přenosu dat. Čím méně vlastní logiky zabezpečení napíšete, tím nižší je vaše dlouhodobé riziko.

Při psaní kódu nastavte ve výchozím nastavení odmítnutí. Navrhněte logiku autorizace tak, aby byl přístup zablokován, pokud není explicitně povolen. Používejte seznamy povolených pro konkrétní, schválené entity a zajistěte, aby privilegované operace proběhly úspěšně jenom v případě, že jsou jasně autorizované.

Posílit vývojářská prostředí

Vaše vývojové prostředí je součástí prostoru pro útoky. Chraňte své vývojářské pracovní stanice se stejným důrazem jako produkční systémy. To znamená prosazování silných kontrol identit, aplikace ochrany sítě a systematické udržování aktualizací. Ohrožená pracovní stanice se může stát přímou cestou do kódové základny a systémů pro sestavování.

Úložiště zdrojového kódu je důležitým prostředkem. Udělte přístup na principu nejmenší potřebnosti a pouze na základě nutnosti. Vytvořte strukturované procesy kontroly kódu zaměřené na zabezpečení s jasnými pracovními postupy schvalování svázanými s obchodním odůvodněním. Silná správa nad úložišti a kanály snižuje pravděpodobnost manipulace a omezuje dopad porušení zabezpečení.

Přístup k síti by měl být také segmentovaný, aby vývojáři neměli přímý přístup k produkčním systémům.

Vývojové nástroje můžou také pomoct zlepšit zabezpečení pomocí rozšíření IDE, která monitorují kód při zápisu a kontrolují místní sestavení na zranitelnosti. Přihlašovací údaje musí být chráněné zajištěním, že tajné kódy nejsou uložené v konfiguračních souborech a při vyžadování přístupu k tajným kódům používají správce přihlašovacích údajů.

Vývojáři by měli dodržovat schválené vývojářské nástroje a používat instalace spravované centrálně. Vývojová prostředí, jako je GitHub Codespaces a Microsoft Dev Box, můžou vynutit zabezpečení poskytováním izolovaných a centrálně spravovaných pracovních prostorů.

Testy by se také měly spouštět v řízeném prostředí s minimálními potřebnými oprávněními.

Zabezpečené kanály sestavení a nasazení

Řetězce sestavení a nasazení jsou hlavním terčem. Útočníci můžou manipulovat s vaším kanálem, vkládat škodlivý kód, přistupovat k tajným kódům nebo ohrozit podřízená prostředí.

Zacházejte s agenty sestavení jako s cennými aktivy. Mají privilegovaný přístup ke zdrojovému kódu a sestavovacím procesům, což z nich činí atraktivní cíle. Ověřte a autorizujte přístup striktně, segmentujte jej na úrovni sítě a podminěte jej nepřetržitému sledování zabezpečení. Upřednostněte buildovací agenti hostované Microsoftem před agenty hostovanými lokálně, abyste snížili provozní riziko a omezili stálost, protože poskytují čistá prostředí pro každé spuštění kanálu. Vlastní agenti zvyšují režijní náklady na správu a rozšiřují prostor pro útoky.

Zabezpečte přihlašovací údaje pro sestavení a odeberte dočasné artefakty, aby se zabránilo úniku. Pokud je to možné, izolujte agenty sestavení omezením příchozího přístupu a povolením pouze řízené odchozí komunikace.

Začněte udržováním jasné viditelnosti a řízení. Udržujte aktuální inventář všech integrovaných komponent a závislostí a pravidelně ověřujte, že to, co se spouští v pipeline, odpovídá schválenému nastavení. Používejte jenom úlohy kanálu a rozšíření z důvěryhodných, ověřených zdrojů, s vědomím, že se spouštějí s privilegovaným přístupem.

Chraňte přihlašovací údaje odstraněním pevně zakódovaných tajných kódů a upřednostňováním spravovaných identit a zabezpečených úložišť tajných kódů.Segmentujte fáze kanálu, abyste snížili nepotřebnou expozici citlivých prostředků a omezili laterální pohyb v případě ohrožení fáze.

Izolace prostředí je stejně důležitá. Přísně oddělené produkční a neprodukční systémy, vyhněte se používání produkčních dat v nižších prostředích bez ekvivalentní ochrany a zabraňte přímému připojení, které by mohlo umožnit šíření porušení zabezpečení. Řízení rizika prostřednictvím progresivní expozice. Uvolňujte změny postupně, pomocí příznaků funkcí nebo postupného zavádění, takže pokud dojde k ohrožení zabezpečení, omezíte dopad. Navrhněte kanály tak, aby podporovaly běžná i tísňová nasazení. Opravy zabezpečení často vyžadují rychlou reakci a váš proces by měl umožňovat rychlý postup vpřed nebo vrácení zpět, aniž by byla ohrožena stabilita systému. Zajistěte jasné postupy komunikace a schvalování, které urychlují nouzové změny zodpovědně.

Poznámka:

Vždy upřednostněte opravy zabezpečení před pohodlím. Ale nikdy neohrožujte kvalitu nebo zaváděte regrese. Pokud potřebujete zrychlit opravu prostřednictvím kanálu tísňového volání, vyhodnoťte, které automatizované testy je možné bezpečně obejít. Zvažte kompromis mezi hodnotou každého testu a časem jejího spuštění. Testy jednotek jsou například rychlé a důležité, zatímco integrace nebo kompletní testy můžou trvat déle, ale přesto poskytují kritické pokrytí. Úmyslně učinte tato rozhodnutí, aby bylo zajištěno vyvážení rychlosti s důvěrou v opravě.

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

Produkční prostředí je poslední obrannou čarou pro ochranu kódu vývojáře před tím, než dosáhne uživatelů. Týmy by měly udržovat záznam zlaté image nasazené do produkčního prostředí a udržovat katalog všech nasazených prostředků a jejich verzí, aby podporovaly řešení potíží, reakce na incidenty a správu ohrožení zabezpečení. Může také ovlivnit mechanismy posunu konfigurace. Automatizované kontroly publikovaných CVE pomáhají rychle identifikovat zastaralé nebo rizikové komponenty.

Vývojová prostředí by neměla mít přímý produkční přístup. Tento přístup by měl být omezen. Pravidelně také obměňujte tajemství a certifikáty a provádějte bezpečnostně zaměřená cvičení, jako jsou simulace u kulatého stolu a nasazení red teamu, aby byla ověřena obranyschopnost.

Ochrana kódu od vývoje až po dekomisi

Ochrana kódu je průběžná odpovědnost. SDLC je iterativní a požadavky se vyvíjejí, takže postupy z dřívějších fází musí být v průběhu času nadále aplikovány a posíleny.

Udržujte veškerý software, knihovny a komponenty infrastruktury v aktualizovaném stavu díky včasným opravám zabezpečení. Průběžně vyhodnocujte a vylepšujte procesy tím, že začleníte poznatky z kontrol kódu, zpětné vazby, vyšetřování incidentů a vznikajících hrozeb. Okamžitě integrujte opravy z produkčních problémů zpět do vývojového životního cyklu, abyste zabránili opakování.

Vyřazení starších prostředků, které se už nepoužívají k omezení prostoru pro útoky a zjednodušení údržby Pravidelně upřesněte postupy zabezpečeného kódování, abyste zůstali před vývojem hrozeb a zajistili, že stav zabezpečení zůstane po celý životní cyklus silný a odolný.

Usnadnění na platformě 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í

  • Last updated on