Zdieľať cez

Odporúčania na zabezpečenie životného cyklu vývoja

Vzťahuje sa na toto odporúčanie Power Platform dobre zostaveného kontrolného zoznamu zabezpečenia:

SE:02 Udržiavajte bezpečný životný cyklus vývoja pomocou spevneného, ​​väčšinou automatizovaného a auditovateľného softvéru dodávateľský reťazec. Zahrňte bezpečný dizajn pomocou modelovania hrozieb na ochranu pred implementáciami, ktoré porušujú bezpečnosť.

Táto príručka popisuje odporúčania na zabezpečenie kódu a vývojového prostredia aplikovaním osvedčených postupov zabezpečenia počas celého vývojového cyklu.

Jadrom pracovného zaťaženia sú komponenty, ktoré implementujú obchodnú logiku. Tieto komponenty môžu byť kombináciou nízkokódové prvkov, ako sú aplikácie a toky plátna, a prvkov na začiatku kódu, ako sú doplnky. Všetky komponenty, ktoré tvoria vašu pracovnú záťaž, musia byť bez bezpečnostných chýb, aby sa zabezpečila dôvernosť, integrita a dostupnosť.

Zabezpečenie úrovne infraštruktúry pomocou ovládacích prvkov identity a siete je dôležité, ale nestačí. Zabráňte zlej implementácii Power Platform pracovnej záťaže a narušeným aktivitám v týchto záťažiach, aby ste posilnili svoje celkové zabezpečenie. Proces integrácie bezpečnosti do životného cyklu vývoja je v podstate procesom zosilňovania. Rovnako ako posilnenie zdrojov, sprísnenie vývoja kódu je tiež kontextovo agnostické. Dôraz je kladený na zvýšenie bezpečnosti, nie na funkčné požiadavky aplikácie.

Definície

Pojem Definícia
Životný cyklus vývoja zabezpečenia (SDL) Súbor postupov poskytovaných Microsoft, ktoré podporujú požiadavky na zaistenie bezpečnosti a súlad.
Životný cyklus vývoja softvéru (SDLC) Viacstupňový, systematický proces vývoja softvérových systémov.

Kľúčové dizajnové stratégie

Bezpečnostné opatrenia by mali byť integrované vo viacerých bodoch do vášho existujúceho životného cyklu vývoja softvéru (SDLC), aby sa zabezpečilo:

  • Voľby dizajnu nevedú k bezpečnostným medzerám.
  • Nízkokódové a komponenty na prvom mieste, ako aj konfigurácia nevytvárajú zraniteľné miesta z dôvodu zneužiteľnej implementácie a nesprávnych praktík kódovania.
  • Nízkokódové a komponenty a procesy nasadenia na prvom mieste kódu nie sú sfalšované.
  • Zraniteľnosť odhalená prostredníctvom incidentov je zmiernená.
  • Požiadavky na súlad nie sú ohrozené ani znížené.
  • Protokolovanie auditu je implementované vo všetkých prostrediach.

Nasledujúce časti poskytujú bezpečnostné stratégie pre bežne používané fázy SDLC.

Fáza požiadaviek

Cieľom fázy požiadaviek je zhromaždiť a analyzovať funkčné a nefunkčné požiadavky na pracovné zaťaženie alebo novú vlastnosť pracovného zaťaženia. Táto fáza je dôležitá, pretože uľahčuje vytváranie mantinelov, ktoré sú prispôsobené cieľom pracovnej záťaže. Ochrana údajov a integrity vašej pracovnej záťaže by mala byť základnou požiadavkou v každej fáze životného cyklu vývoja.

Predstavte si napríklad pracovné zaťaženie, pri ktorom budú používatelia zadávať a upravovať údaje v rámci aplikácie. Voľby bezpečnostného dizajnu by mali zahŕňať záruky interakcie používateľa s údajmi, ako je autentifikácia a autorizácia identity používateľa a umožnenie iba povolených akcií s údajmi. Nefunkčné požiadavky zahŕňajú dostupnosť, použiteľnosť a udržiavateľnosť. Voľby zabezpečenia by mali zahŕňať hranice segmentácie, vstup a výstup brány firewall a ďalšie prierezové otázky bezpečnosti.

Všetky tieto rozhodnutia by mali viesť k dobrej definícii bezpečnostnej pozície pracovného zaťaženia. Zdokumentujte bezpečnostné požiadavky v dohodnutej špecifikácii a premietnite ich do nevybavených úloh. Dokument by mal explicitne uvádzať investície do bezpečnosti a kompromisy a riziká, ktoré je podnik ochotný podstúpiť, ak investície neschvália zainteresované strany. Môžete napríklad zdokumentovať potrebu používať IP firewall v Power Platform prostrediach na ochranu vašich organizačných údajov obmedzením Dataverse prístupu len na povolené adresy IP. Ak zainteresované strany nie sú ochotné znášať dodatočné náklady na používanie riešenia ako Spravované prostredia, musia byť pripravené prijať riziko prístupu k organizačným zdrojom z verejných miest, ako je napríklad kaviareň. Ako ďalší príklad si predstavte, že vaša aplikácia sa musí pripojiť k zdroj údajov tretej strany. Power Platform môže mať na to pripravený konektor, ale nemusí podporovať požiadavky na autentifikáciu schválené vašimi bezpečnostnými tímami. V tomto prípade môžu byť vaši zainteresovaní v oblasti bezpečnosti ochotní akceptovať riziko použitia neschválenej metódy autentifikácie. Prípadne môžete preskúmať použitie vlastného konektora a zároveň zvážiť výhody predĺženého času vývoja a potenciálneho oneskorenia projektu.

Zhromažďovanie bezpečnostných požiadaviek je kritickou súčasťou tejto fázy. Bez tohto úsilia budú fázy návrhu a implementácie založené na neuvedených možnostiach, čo môže viesť k bezpečnostným medzerám alebo zmenám požiadaviek, ktoré predĺžia čas vývoja. Možno budete musieť neskôr zmeniť implementáciu, aby ste sa prispôsobili bezpečnosti, čo môže byť drahé.

Fáza návrhu

Počas tejto fázy sa bezpečnostné požiadavky prevedú na technické požiadavky. Vo svojej technickej špecifikácii zdokumentujte všetky rozhodnutia o návrhu, aby ste predišli nejasnostiam počas implementácie. Tu je niekoľko typických úloh:

  • Definujte bezpečnostný rozmer architektúry. Prekryte architektúru bezpečnostnými ovládacími prvkami. Napríklad ovládacie prvky, ktoré sú praktické na hraniciach izolácie siete, typy identít a metód autentifikácie potrebných pre komponenty pracovného zaťaženia a typ metód šifrovania, ktoré sa majú použiť.

  • Vyhodnoťte prostriedky poskytnuté platformou. Je dôležité pochopiť, rozdelenie zodpovednosti medzi vás a Power Platform. Vyhnite sa prekrývaniu alebo duplicite s Power Platform natívne bezpečnostné kontroly. Získate lepšie bezpečnostné pokrytie a budete môcť prerozdeliť vývojové zdroje podľa potrieb aplikácie.

    Napríklad namiesto vytvárania vlastnej logiky, ktorá reaktívne identifikuje a upozorňuje na neschválené vzory používania v aplikáciách a tokoch, použite zásady prevencie straty údajov na kategorizáciu spôsobu použitia konektorov.

    Vyberte si iba dôveryhodné referenčné implementácie, šablóny, komponenty kódu, skripty a knižnice. Váš návrh by mal tiež špecifikovať zabezpečenú správu verzií. Závislosti aplikácií by mali pochádzať od dôveryhodných strán. Dodávatelia tretích strán by mali byť schopní splniť vaše bezpečnostné požiadavky a zdieľať svoj plán zodpovedného zverejňovania. Akýkoľvek bezpečnostný incident by mal byť okamžite nahlásený, aby ste mohli podniknúť potrebné kroky. Vaša organizácia môže tiež zakázať určité knižnice alebo implementácie odkazov. Napríklad, aj keď je bezpečný a neobsahuje chyby zabezpečenia, stále môže byť zakázaný, pretože používa funkcie, ktoré ešte neschválila vaša organizácia, licenčné obmedzenia alebo model podpory referenčnej implementácie.

    Aby ste zabezpečili dodržiavanie tohto usmernenia, veďte zoznam schválených a/alebo neschválených rámcov, knižníc a predajcov a uistite sa, že vaši tvorcovia sú s týmto zoznamom oboznámení. Ak je to možné, umiestnite zábradlia do vývojových potrubí na podporu zoznamu. Pokiaľ je to možné, automatizujte používanie nástrojov na skenovanie závislostí na zraniteľnosti.

  • Bezpečne uchovávajte tajomstvá aplikácií. Bezpečne implementujte používanie tajných kľúčov aplikácie a vopred zdieľaných kľúčov, ktoré vaša aplikácia používa. Poverenia a tajomstvá aplikácie by sa nikdy nemali ukladať do zdrojového kódu pracovného zaťaženia (aplikácie alebo toku). Použite externé zdroje, ako je Azure Key Vault, aby ste zabezpečili, že ak sa váš zdrojový kód stane dostupným pre potenciálneho útočníka, nebude možné získať ďalší prístup.

  • Pripojte sa k svojim údajom bezpečne. Využite silné bezpečnostné funkcie, ktoré Microsoft Dataverse ponúka ochranu vašich údajov, ako je zabezpečenie na úrovni rolí a stĺpcov. Pre iné zdroje údajov použite konektory, ktoré majú zabezpečené metódy autentifikácie. Vyhnite sa dopytom, ktoré ukladajú používateľské meno a heslo v obyčajnom texte. Vyhnite sa HTTP pri vytváraní vlastných konektorov.

  • Definujte, ako budú koncoví používatelia interagovať s pracovným zaťažením a údajmi. Zvážte, či budú mať používatelia priamy prístup k údajom, akú úroveň prístupu požadujú a odkiaľ budú k údajom pristupovať. Zamyslite sa nad tým, ako budú aplikácie zdieľané s koncovými používateľmi. Uistite sa, že prístup k aplikácii a údajom budú mať iba tí, ktorí potrebujú prístup. Vyhnite sa zložitým bezpečnostným modelom, ktoré podporujú riešenia, aby ste sa vyhli blokovaniu zabezpečenia.

  • Vyhnite sa tvrdému kódovaniu. Vyhnite sa pevnému kódovaniu adries URL a kľúčov. Vyhnite sa napríklad tomu, aby ste v akcii Power Automate HTTP pevne zakódovali adresu URL alebo kľúč ku koncovej službe. Namiesto toho použite vlastný konektor alebo použite premennú prostredia pre adresu URL a Azure Key Vault pre kľúč API.

  • Definujte plány testov. Definujte jasné testovacie prípady pre bezpečnostné požiadavky. Vyhodnoťte, či môžete automatizovať tieto testy vo svojich kanáloch. Ak má váš tím procesy na manuálne testovanie, zahrňte pre tieto testy bezpečnostné požiadavky.

Poznámka

Počas tejto fázy vykonajte modelovanie hrozieb. Modelovanie hrozieb môže potvrdiť, že voľby dizajnu sú v súlade s bezpečnostnými požiadavkami a odhaliť medzery, ktoré by ste mali zmierniť. Ak vaša pracovná záťaž spracováva vysoko citlivé údaje, investujte do bezpečnostných expertov, ktorí vám môžu pomôcť s modelovaním hrozieb.

Počiatočné cvičenie modelovania hrozieb by sa malo uskutočniť počas fázy návrhu, keď sa definuje architektúra softvéru a návrh na vysokej úrovni. Ak to urobíte počas tejto fázy, pomôže vám to identifikovať potenciálne bezpečnostné problémy skôr, ako budú začlenené do štruktúry systému. Toto cvičenie však nie je jednorazová aktivita. Je to nepretržitý proces, ktorý by mal pokračovať počas vývoja softvéru.

Viac informácií nájdete v časti Odporúčania týkajúce sa analýzy hrozieb.

Fáza vývoja a testovania

Počas tejto fázy je cieľom predísť bezpečnostným chybám a neoprávneným zásahom do kanálov kódu, zostavovania a nasadenia.

Buďte dobre vyškolení v postupoch bezpečného kódovania

Vývojový tím by mal mať školenie na bezpečné kódovanie. Vývojári by napríklad mali poznať bezpečnostné koncepty v Microsoft Dataverse aby mohli implementovať model zabezpečenia s najnižšími oprávneniami, zásady zabezpečenia obsahu pre modelom riadené aplikácie na obmedzenie vkladania do dôveryhodných domén a autentifikáciu konektorom/on-premise bránou. metódy.

Vývojári by mali byť povinní absolvovať toto školenie predtým, ako začnú pracovať na Power Platform pracovných záťažiach.

Vykonajte interné kontroly partnerského kódu na propagáciu Priebežné učenie.

Použite nástroje na analýzu kódu

Solution Checker by sa mal použiť pre Power Platform zdroje a zdrojový kód akéhokoľvek tradičného kódu by sa mal skontrolovať na potenciálne bezpečnostné chyby vrátane prítomnosti poverení v kóde. Identifikujte možné prípady odhalenia poverení a tajných informácií v zdrojovom kóde a konfiguračných súboroch. Toto je vhodný čas na preskúmanie toho, ako sa bude s prihlasovacími údajmi narábať v produkcii.

Vykonajte fuzz testovanie

Použite chybné a neočakávané údaje na kontrolu zraniteľností a overenie spracovania chýb, čo je obzvlášť dôležité pri riešeniach, ktoré zahŕňajú Power Pages.

Napíšte dostatok kódu

Keď znížite svoju kódovú stopu, znížite aj šance na chyby zabezpečenia. Opätovne použite kód a knižnice, ktoré sa už používajú a prešli overením zabezpečenia namiesto duplikovania kódu. Detekcia open source softvéru a kontrola verzie, zraniteľnosti a zákonných povinností. Rastie množstvo open-source Power Platform zdrojov, takže by sa to nemalo prehliadať. Ak je to možné, malo by sa to prediskutovať vo fáze návrhu, aby sa predišlo problémom na poslednú chvíľu.

Chráňte prostredia vývojárov

Vývojárske pracovné stanice musia byť chránené silnými sieťovými a identifikačnými kontrolami, aby sa zabránilo ich vystaveniu. Uistite sa, že aktualizácie zabezpečenia sú aplikované dôsledne.

Úložisko zdrojového kódu musí byť tiež zabezpečené . Poskytnite prístup k úložiskám kódu na základe potreby poznať a čo najviac znížte vystavenie zraniteľnosti, aby ste sa vyhli útokom. Vykonajte dôkladný proces kontroly kódu na chyby zabezpečenia. Na tento účel použite skupiny zabezpečenia a implementujte proces schvaľovania, ktorý je založený na obchodných dôvodoch.

Bezpečné nasadenie kódu

Nestačí len zabezpečiť kód. Ak to beží v zneužiteľných potrubiach, všetky bezpečnostné snahy sú márne a neúplné. Prostredia zostavovania a vydávania musia byť chránené aj pretože chcete zabrániť zlým aktérom spúšťať škodlivý kód vo vašom kanáli.

Udržujte aktuálny inventár každého komponentu, ktorý je integrovaný do vašej aplikácie

Každý nový komponent, ktorý je integrovaný do aplikácie, zvyšuje útočnú plochu. Aby ste zabezpečili správnu zodpovednosť a upozorňovanie, keď sú pridané alebo aktualizované nové komponenty, mali by ste mať zoznam týchto komponentov. Pravidelne kontrolujte, či sa váš manifest zhoduje s tým, čo je v procese zostavovania. Pomôže to zaistiť, že sa neočakávane nepridajú žiadne nové komponenty, ktoré obsahujú zadné vrátka alebo iný malvér.

Pre vaše nasadenia odporúčame použiť Pravidlá pre Power Platform . Rozšírte kanály pomocou akcií GitHub. Ak používate pracovné postupy GitHub, uprednostňujte úlohy od spoločnosti Microsoft. Overte tiež úlohy, pretože sa spúšťajú v kontexte zabezpečenia vášho kanála.

Preskúmajte použitie principálov služieb na nasadenie.

Výrobná fáza

Výrobná fáza predstavuje posledná zodpovedná príležitosť na nápravu bezpečnostných medzier. Zaznamenajte si zlatý obrázok, ktorý sa uvoľnil vo výrobe.

Uchovávajte artefakty s verziou

Udržujte katalóg všetkých nasadených aktív a ich verzií. Tieto informácie sú užitočné pri triedení incidentov, pri zmierňovaní problémov a pri návrate systému do funkčného stavu. Verziované aktíva možno tiež porovnať s uverejnenými oznámeniami o bežných zraniteľnostiach a vystaveniach (CVE). Na vykonanie týchto porovnaní by ste mali použiť automatizáciu.

Núdzové opravy

Váš automatizovaný návrh potrubia by mal byť flexibilný podporovať pravidelné aj núdzové nasadenie. Táto flexibilita je dôležitá na podporu rýchlych a zodpovedných bezpečnostných opráv.

Vydanie je zvyčajne spojené s viacerými schvaľovacími bránami. Zvážte vytvorenie núdzového procesu na urýchlenie opráv zabezpečenia. Proces môže zahŕňať komunikáciu medzi tímami. Potrubie by malo umožňovať rýchle nasadenia vpred a vrátenia, ktoré riešia opravy zabezpečenia, kritické chyby a aktualizácie kódu, ktoré sa vyskytujú mimo bežného životného cyklu nasadenia.

Poznámka

Vždy uprednostňujte bezpečnostné opravy pred pohodlím. Oprava zabezpečenia by nemala spôsobiť regresiu alebo chybu. Ak chcete urýchliť opravu prostredníctvom núdzového potrubia, dôkladne zvážte, ktoré automatizované testy je možné obísť. Vyhodnoťte hodnotu každého testu v porovnaní s časom vykonania. Napríklad jednotkové testy sa zvyčajne dokončia rýchlo. Integračné alebo end-to-end testy môžu prebiehať dlho.

Udržujte rôzne prostredia oddelené

Produkčné dáta by sa nemali používať v nižších prostrediach** pretože tieto prostredia nemusia mať prísne bezpečnostné kontroly, aké má produkcia. Vyhnite sa pripájaniu z neprodukčnej aplikácie k produkčnej databáze a vyhýbajte sa pripájaniu neprodukčných komponentov k produkčným sieťam.

Použite progresívnu expozíciu

Pomocou postupného vystavenia uvoľňujte funkcie pre podskupinu používateľov na základe zvolených kritérií. Ak sa vyskytnú problémy, dopad sa na týchto používateľov minimalizuje. Tento prístup je bežnou stratégiou na zmiernenie rizika, pretože znižuje plochu. Ako funkcia dozrieva a vy budete mať väčšiu dôveru v bezpečnostné záruky, môžete ju postupne sprístupniť širšej skupine používateľov.

údržba fáza

Cieľom tejto fázy je zabezpečiť, aby sa bezpečnostná pozícia časom neznížila. SDLC je prebiehajúci agilný proces. Koncepcie zahrnuté v predchádzajúcich fázach sa vzťahujú na túto fázu, pretože požiadavky sa časom menia.

Neustále zlepšovanie. Neustále vyhodnocujte a zlepšujte bezpečnosť procesu vývoja softvéru tým, že beriete do úvahy kontroly kódu, spätnú väzbu, ponaučenia a vyvíjajúce sa hrozby, ako aj nové funkcie sprístupnené spoločnosťou Power Platform.

Vyraďte staré aktíva , ktoré sú zastarané alebo sa už nepoužívajú. Tým sa zmenší povrch aplikácie.

údržba obsahuje aj opravy incidentov. Ak sa vo výrobe zistia problémy, je potrebné ich rýchlo integrovať späť do procesu, aby sa neopakovali.

Neustále zdokonaľujte svoje postupy bezpečného kódovania, aby ste udržali krok s prostredím hrozieb.

SDĽ v Microsoft Power Platform

Power Platform je postavená na kultúre a metodológii bezpečného dizajnu. Kultúra aj metodológia sa neustále posilňujú prostredníctvom popredných postupov spoločnosti Microsoft Životný cyklus vývoja zabezpečenia (SDL) a Modelovanie hrozieb.

Proces kontroly Modelovanie hrozieb zaisťuje, že hrozby sú identifikované počas fázy návrhu, sú zmiernené a overené, aby sa zabezpečilo, že boli zmiernené.

Modelovanie hrozieb tiež zohľadňuje všetky zmeny služieb, ktoré sú už aktívne prostredníctvom priebežných pravidelných kontrol. Spoliehajúc sa na Model STRIDE pomáha riešiť najčastejšie problémy s nezabezpečeným dizajnom.

SDL od spoločnosti Microsoft je ekvivalentom pre OWASP Software Assurance Maturity Model (SAMM). Obe riešenia sú postavené na predpoklade, že bezpečný dizajn je neoddeliteľnou súčasťou zabezpečenia webových aplikácií. Ďalšie informácie nájdete v časti OWASP Top 10 Risks: Mitigations in Power Platform.

Power Platform uľahčenie

Microsoft Životný cyklus vývoja zabezpečenia (SDL) odporúča bezpečné postupy, ktoré môžete použiť vo svojom životnom cykle vývoja. Ďalšie informácie nájdete v časti Microsoft Životný cyklus vývoja zabezpečenia.

Defender for DevOps a nástroje SAST (Static Application Security Testing) sú súčasťou GitHub Advanced Security a Azure DevOps. Tieto nástroje vám môžu pomôcť sledovať skóre zabezpečenia vašej organizácie.

Vďaka funkcii kontroly riešenia môžete vykonať rozsiahle statické analýzy vašich riešení voči skupine najlepších postupov a rýchle identifikovať tieto problematické vzory. Pozrite si Používanie nástroja na kontrolu riešení na overenie riešení.

Kontrolný zoznam zabezpečenia

Pozrite si úplný súbor odporúčaní.

Kontrolný zoznam zabezpečenia