Sdílet prostřednictvím

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

  • Článek

Vztahuje se na toto doporučení Power Platform Dobře uspořádaného kontrolního seznamu zabezpečení:

SE:02 Udržujte bezpečný životní cyklus vývoje pomocí posíleného, většinou automatizovaného a auditovatelného softwarového dodavatelského řetězce. Zahrňte bezpečný návrh pomocí modelování hrozeb k ochraně před implementacemi, které porušují zabezpečení.

Tato příručka popisuje doporučení pro zabezpečení kódu a vývojového prostředí aplikováním osvědčených bezpečnostních postupů během vývojového cyklu.

Jádrem úlohy jsou komponenty, které implementují obchodní logiku. Tyto komponenty mohou být kombinací prvků s minimem kódu, jako jsou aplikace a toky plátna, a prvků na prvním místě kódu, jako jsou moduly plug-in. Aby byla zajištěna důvěrnost, integrita a dostupnost, všechny součásti, které tvoří vaši úlohy, musí být bez chyb zabezpečení.

Zabezpečení úrovně infrastruktury pomocí ovládacích prvků identity a sítě je důležité, ale nestačí. Zabraňte špatné implementaci úloh Power Platform a ohroženým aktivitám v těchto úlohách, abyste posílili celkovou pozici zabezpečení. Proces integrace zabezpečení do vašeho životního cyklu vývoje je v podstatě procesem posílení. Stejně jako posílení prostředků je i zpřísnění vývoje kódu kontextově nezávislé. Důraz je kladen na zvýšení bezpečnosti, nikoli na funkční požadavky aplikace.

Definice

Pojem definice
Životní cyklus vývoje zabezpečení (SDL) Sada postupů poskytovaných Microsoft , které podporují požadavky na zajištění bezpečnosti a shodu.
Životní cyklus vývoje softwaru (SDLC) Vícestupňový systematický proces vývoje softwarových systémů.

Klíčové strategie návrhu

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

  • Možnosti návrhu nevedou k chybám zabezpečení.
  • Komponenty s minimem kódu a komponenty založené na kódu, stejně jako konfigurace nevytvářejí chyby zabezpečení z důvodu zneužitelné implementace a nesprávných postupů kódování.
  • S komponentami s minimem kódu a komponentami založenými na kódu, stejně jako s konfiguracemi se nijak nemanipuluje.
  • Chyby zabezpečení odhalené prostřednictvím incidentů jsou zažehnány.
  • Požadavky na dodržování předpisů nejsou ohroženy ani omezeny.
  • Protokolování auditu je implementováno ve všech prostředích.

Následující sekce obsahují bezpečnostní strategie pro běžně používané 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 úlohu nebo novou funkci úlohy. Tato fáze je důležitá, protože usnadňuje vytváření ochranných prvků, které jsou přizpůsobeny cílům úlohy. Ochrana dat a integrity úlohy 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 úlohu, kdy uživatelé zadávají a upravují data v rámci aplikace. Možnosti návrhu zabezpečení by měly zahrnovat záruky pro interakci uživatele s daty, jako je ověření a autorizace identity uživatele a umožnění pouze povolených akcí s daty. Nefunkční požadavky zahrnují dostupnost, použitelnost a udržovatelnost. Možnosti zabezpečení by měly zahrnovat hranice segmentace, vstup a výstup brány firewall a další průřezové záležitosti zabezpečení.

Všechna tato rozhodnutí by měla vést k dobré definici pozice zabezpečení dané úlohy. Zdokumentujte bezpečnostní požadavky v dohodnuté specifikaci a promítněte je do nevyřízených položek. Dokument by měl explicitně uvádět investice do zabezpečení, stejně jako kompromisy a rizika, která je podnik ochoten podstoupit, pokud investice neschválí obchodní partneři. Můžete například zdokumentovat potřebu používat bránu firewall IP v prostředích Power Platform k ochraně organizačních dat omezením přístupu Dataverse pouze k povoleným umístěním IP. Pokud obchodní účastníci nejsou ochotni nést dodatečné náklady na používání řešení, jako jsou spravovaná prostředí, musí být připraveni přijmout riziko přístupu k prostředkům organizace z veřejných míst, například z kavárny. Nebo si představte, že se vaše aplikace musí připojit ke zdroji dat třetí strany. Power Platform může mít pro to připravený konektor, ale nemusí podporovat požadavky na ověřování schválené vašimi týmy pro zabezpečení. V tomto případě mohou být účastníci ochotni přijmout riziko použití neschválené metody ověřování. Případně můžete prozkoumat použití vlastního konektoru a zároveň zvážit výhody a nevýhody delší doby vývoje a potenciálního zpoždění projektu.

Schůze ohledně požadavků na zabezpečení je kritickou součástí této fáze. Bez tohoto kroku budou fáze návrhu a implementace založeny na nevyřčených volbách, což může vést k bezpečnostním nedostatkům nebo změnám požadavků, které prodlouží dobu vývoje. Možná budete muset později změnit implementaci, aby vyhovovala zabezpečení, což může být drahé.

Fáze návrhu

Během této fáze jsou požadavky na zabezpečení převedeny na technické požadavky. Ve své technické specifikaci zdokumentujte všechna rozhodnutí o návrhu, abyste předešli nejednoznačnosti během implementace. Zde jsou některé typické kroky:

  • Definujte bezpečnostní dimenzi architektury. Překryjte architekturu bezpečnostními opatřeními. Například těmi, která jsou užitečná na hranicích izolujících síť, jako jsou typy identit a metod ověřování potřebných pro komponenty úlohy nebo typy metod šifrování, které se mají použít.

  • Vyhodnoťte finanční prostředky vyplývající z použité platformy. Je důležité pochopit rozdělení odpovědnosti mezi vás a Power Platform. Vyhněte se překrývání nebo duplikaci s nativními bezpečnostními opatřeními Power Platform. Získáte lepší bezpečnostní pokrytí a budete moci přerozdělit vývojové prostředky podle potřeb aplikace.

    Například namísto vytváření vlastní logiky, která reaktivně identifikuje a upozorňuje na neschválené vzorce použití v aplikacích a tocích, použijte zásady ochrany před únikem informací ke kategorizaci způsobu použití konektorů.

    Vyberte pouze důvěryhodné referenční implementace, šablony, komponenty kódu, skripty a knihovny. Váš návrh by měl také specifikovat bezpečnou 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 bezpečnostní požadavky a sdílet svůj plán odpovědného zveřejňování. Jakýkoli bezpečnostní incident by měl být okamžitě nahlášen, abyste mohli podniknout potřebné kroky. Rovněž určité knihovny nebo referenční implementace mohou být zakázány vaší organizací. I když jsou například zabezpečené a neobsahují chyby zabezpečení, mohou být stále zakázány, protože používají funkce, které ještě nebyly schváleny vaší organizací, licenčními omezeními nebo modely podpory referenční implementace.

    Abyste zajistili dodržování těchto pokynů, udržujte seznam schválených a/nebo neschválených rámců, knihoven a dodavatelů a zajistěte, aby vaši tvůrci byli s tímto seznamem obeznámeni. Pokud je to možné, do kanálů vývoje vložte ochranné prvky, abyste seznam podpořili. Co nejvíce automatizujte používání nástrojů ke zjišťování chyb zabezpečení v závislostech.

  • Bezpečně ukládejte tajné kódy aplikací. Bezpečně implementujte používání tajných kódů aplikací a předem sdí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ženy ve zdrojovém kódu úlohy (aplikaci nebo toku). Použijte externí prostředky, jako je Azure Key Vault, abyste zajistili, že pokud bude váš zdrojový kód dostupný potenciálnímu útočníkovi, nebude možné získat žádný další přístup.

  • Ke svým datům se připojujte bezpečně. Využijte účinné funkce zabezpečení, které nabízí Microsoft Dataverse k ochraně vašich dat, například zabezpečení založené na rolích nebo na úrovni sloupců. Pro jiné zdroje dat použijte konektory, které mají bezpečné metody ověřování. Nepoužívejte dotazy, které ukládají uživatelské jméno a heslo jako prostý text. Nepoužívejte HTTP pro vytváření vlastních konektorů.

  • Definujte, jak koncoví uživatelé budou interagovat s úlohou a daty. Zvažte, zda budou mít uživatelé přímý přístup k datům, jakou úroveň přístupu požadují a odkud budou k datům přistupovat. Přemýšlejte, jak budou aplikace sdíleny s koncovými uživateli. Ujistěte se, že přístup k aplikaci a datům budou mít pouze uživatelé, kteří potřebují přístup. Vyhněte se komplexním modelům zabezpečení, které umožňují alternativní řešení, aby nedocházelo k blokování zabezpečení.

  • Vyhněte se pevnému kódování. Vyhněte se pevnému kódování adres URL a klíčů. Například se vyhněte pevnému kódování adresy URL nebo klíče v akci Power Automate HTTP do backendové služby. Místo toho použijte vlastní konektor nebo proměnnou prostředí pro adresu URL a Azure Key Vault pro klíč rozhraní API.

  • Definujte plány testování. Definujte jasné testovací případy pro bezpečnostní požadavky. Vyhodnoťte, zda můžete tyto ve svých kanálech tyto testy automatizovat. Pokud má váš tým procesy pro ruční testování, zahrňte pro ně bezpečnostní požadavky.

Poznámka:

Během této fáze proveďte modelování hrozeb. Modelování hrozeb může potvrdit, že možnosti návrhu jsou v souladu s požadavky na zabezpečení a odhalit nedostatky, které byste měli odstranit. Pokud vaše úloha zpracovává vysoce citlivá data, investujte do bezpečnostních expertů, kteří vám mohou pomoci s modelováním hrozeb.

Počáteční modelování hrozeb by mělo proběhnout během fáze návrhu, kdy se definuje architektura softwaru a návrh na vysoké úrovni. Pokud to uděláte během této fáze, pomůže vám to identifikovat potenciální bezpečnostní problémy dříve, než budou začleněny do struktury systému. Toto modelování však není jednorázovou aktivitou. Je to nepřetržitý proces, který by měl pokračovat po celou dobu vývoje softwaru.

Další informace viz Doporučení pro analýzu hrozeb.

Fáze vývoje a testování

Cílem této fáze je předejít chybám zabezpečení a neoprávněným zásahům do kódu, sestavení a kanálů nasazení.

Buďte dobře vyškoleni v postupech bezpečného kódu

Vývojový tým by měl mít k dispozici školení ohledně postupů bezpečného kódování. Vývojáři by například měli být obeznámeni s bezpečnostními koncepty v Microsoft Dataverse pro implementaci modelu zabezpečení s nejnižšími oprávněními, zásad zabezpečení obsahu pro modelem řízené aplikace, které omezují vkládání do důvěryhodných domén, a metod ověřování pomocí konektoru / místní brány dat.

Vývojáři by měli mít povinnost absolvovat toto školení, než začnou pracovat na úlohách Power Platform.

Provádějte interní vzájemné hodnocení kódu, abyste podpořili neustálé učení.

Používejte nástroje pro analýzu kódu

Kontrola řešení by se měla používat pro prostředky Power Platform a zdrojový kód jakéhokoli tradičního kódu by mohl být zkontrolován, zda neobsahuje potenciální bezpečnostní chyby, včetně přihlašovacích údajů nacházejících se v kódu. Identifikujte možné případy vystavení přihlašovacích údajů a tajných kódů ve zdrojovém kódu a konfiguračních souborech. Toto je vhodná doba, abyste si přečetli, jak bude s přihlašovacími údaji pro připojení nakládáno v provozu.

Provádění testování neplatným vstupem

Vezměte chybná, neočekávaná data a použijte je ke kontrole zranitelnosti a ověření zpracování chyb, což je zvláště důležité u řešení, která zahrnují Power Pages.

Nepište více kódu, než je třeba

Když snížíte využití paměti kódem, snížíte také šance na bezpečnostní chyby. Znovu použijte kód a knihovny, které se již používají a prošly ověřením zabezpečení místo duplikování kódu. Detekce opensourcového softwaru a kontrola verze, zranitelnosti a zákonných povinností. Roste množství opensourcových prostředků Power Platform, což byste neměli pomíjet. Pokud je to možné, mělo by to být projednáno ve fázi návrhu, aby se předešlo problémům na poslední chvíli.

Ochrana prostředí vývojáře

Vývojářské pracovní stanice musí být chráněny účinnými kontrolami sítě a identity, aby se zabránilo ohrožení. Ujistěte se, že jsou pečlivě používány aktualizace zabezpečení.

Úložiště zdrojového kódu musí být také zabezpečeno . Udělujte přístup k úložištím kódu pouze těm, kteří jej potřebují, a co nejvíce snižte vystavení slabých míst zabezpečení, abyste se vyhnuli útokům. Proveďte důkladný proces kontroly kódu , zda neobsahuje chyby zabezpečení. Pro tento účel použijte skupiny zabezpečení a implementujte proces schvalování, který je založen na obchodních odůvodněních.

Zabezpečené nasazení kódu

Kód nestačí pouze zabezpečit. Pokud běží ve zneužitelných kanálech, veškeré bezpečnostní snahy jsou marné a neúplné. Prostředí sestavení a vydání musí být také chráněno , protože chcete zabránit špatným aktérům ve spouštění škodlivého kódu ve vašem kanálu.

Udržujte aktuální inventář každé komponenty, která je integrována do vaší aplikace

Každá nová komponenta, která je integrována do aplikace, zvyšuje plochu útoku. Chcete-li zajistit řádnou odpovědnost a upozornění, když jsou přidány nebo aktualizovány nové komponenty, měli byste mít jejich soupis. Pravidelně kontrolujte, zda váš manifest odpovídá procesu sestavování. Tím zajistíte, že nebudou neočekávaně přidány žádné nové komponenty, které obsahují zadní vrátka nebo jiný malware.

Pro nasazení doporučujeme použít Kanály pro Power Platform. Rozšiřte kanály pomocí GitHub Actions. Pokud používáte pracovní postupy GitHubu, upřednostňujte úlohy autorů Microsoft. Úlohy také ověřte, protože jsou spouštěny v kontextu zabezpečení vašeho kanálu.

Prozkoumejte použití instančních objektů pro nasazení.

Provozní fáze

Provozní fáze představuje poslední příležitost, kdy může odpovědný tvůrce napravit bezpečnostní nedostatky. Ponechte si záznam zlaté bitové kopie vydané při provozu.

Uchovávejte verze artefaktů

Udržujte katalog všech nasazených prostředků a jejich verzí. Tyto informace jsou užitečné při třídění incidentů, zmírňování problémů a navracení systému zpět do funkčního stavu. Verze prostředků lze také porovnat s publikovanými oznámeními o společných chybách a ohroženích zabezpečení (CVE). K provedení těchto srovnání byste měli použít automatizaci.

Nouzové opravy

Váš automatizovaný návrh kanálu by měl být flexibilní a podporovat pravidelné i nouzové nasazení. Tato flexibilita je důležitá pro podporu rychlých a odpovědných oprav zabezpečení.

Vydání je obvykle spojeno s několika branami schválení. Zvažte vytvoření nouzového procesu pro urychlení oprav zabezpečení. Proces může zahrnovat komunikaci mezi týmy. Kanál by měl umožňovat rychlé vracení i zavádění nasazení řešících 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řednostňujte bezpečnostní opravy před pohodlím. Oprava zabezpečení by neměla způsobit regresi nebo chybu. Pokud chcete opravu urychlit prostřednictvím nouzového kanálu, pečlivě zvažte, které automatizované testy lze obejít. Vyhodnoťte hodnotu každého testu oproti době provedení. Například testy jednotek jsou obvykle dokončeny rychle. Testy integrace nebo kompletní testy mohou běžet po dlouhou dobu.

Udržujte různá prostředí oddělená

Provozní 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í opatření, jaká má provozní prostředí. Vyhněte se připojování z neprovozní aplikace k produkční databázi a z neprovozních komponent k provozním sítím.

Použijte progresivní expozici

Použijte progresivní expozici k uvolnění funkcí podskupině uživatelů na základě zvolených kritérií. Pokud se vyskytnou problémy, dopad je minimalizován na tyto uživatele. Tento přístup je běžnou strategií zmírňování rizik, protože snižuje možnosti útoku. Jak funkce dozrává a vy máte větší důvěru v bezpečnostní záruky, můžete ji postupně zpřístupnit širší skupině uživatelů.

Fáze údržby

Cílem této fáze je zajistit, že pozice zabezpečení se v průběhu času nesníží. SDLC je nekončící pružný proces. Na tuto fázi se vztahují koncepty popsané v předchozích fázích, protože požadavky se v průběhu času mění.

Neustálé zlepšování. Neustále vyhodnocujte a zlepšujte zabezpečení procesu vývoje softwaru tím, že budete brát v úvahu kontroly kódu, zpětnou vazbu, získané zkušenosti a vyvíjející se hrozby, stejně jako nové funkce dostupné v Power Platform.

Vyřaďte z provozu starší aktiva , která jsou zastaralá nebo se již nepoužívají. Tím se zmenší možnosti útoku na aplikaci.

Údržba zahrnuje také opravy incidentů. Pokud se v provozu objeví problémy, je třeba je rychle integrovat zpět do procesu, aby se neopakovaly.

Neustále vylepšujte postupy bezpečného kódování, abyste udrželi krok s prostředím hrozeb.

SDL v Microsoft Power Platform

Power Platform je postaven na kultuře a metodologii bezpečného designu. Kultura i metodika jsou neustále posilovány prostřednictvím Microsoftvedoucího životního cyklu vývoje zabezpečení (SDL) a modelování hrozeb cvičí.

Robustní proces kontroly modelování hrozeb zajišťuje, že hrozby jsou identifikovány během fáze návrhu, zmírňovány a ověřovány pro zajištění, že byly zmírněny.

Modelování hrozeb také zohledňuje všechny změny služeb, které jsou již aktivní prostřednictvím průběžných pravidelných kontrol. Spoléhání se na model STRIDE pomáhá řešit nejčastější problémy s nezabezpečeným designem.

MicrosoftSDL je ekvivalentní OWASP Software Assurance Maturity Model (SAMM). Oba jsou postaveny na předpokladu, že bezpečný design je nedílnou součástí zabezpečení webových aplikací. Více informací viz 10 hlavních rizik OWASP a jejich zmírnění v Power Platform.

Usnadnění dáky Power Platform

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

Defender for DevOps a nástroje SAST (Static Application Security Testing) jsou součástí GitHub Advanced Security a Azure DevOps. Tyto nástroje vám mohou pomoci sledovat skóre zabezpečení vaší organizace.

Pomocí funkce kontroly řešení můžete provést bohatou kontrolu statické analýzy vašich řešení proti souboru pravidel osvědčených postupů a rychle identifikovat tyto problematické vzorce. Viz Použití kontroly řešení k ověření vašich řešení.

Kontrolní seznam zabezpečení

Podívejte se na úplný soubor doporučení.

Bezpečnostní kontrolní seznam