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

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

JV:02 Udržiavajte bezpečný životný cyklus vývoja pomocou zosilneného, prevažne automatizovaného a auditovateľného dodávateľského reťazca softvéru. Začlente bezpečný dizajn pomocou modelovania hrozieb na ochranu pred implementáciami, ktoré ohrozujú bezpečnosť.

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

Jadrom pracovnej záťaže sú komponenty, ktoré implementujú obchodnú logiku. Tieto komponenty môžu byť kombináciou prvkov s nízkym kódom, ako sú aplikácie a postupy plátna, a prvkov s prvým kódom, ako sú pluginy. 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 infraštruktúrnej roviny pomocou kontrol identity a siete je dôležité, ale nestačí. Zabráňte zlej implementácii pracovných záťaží a ohrozeným aktivitám v týchto záťažiach, aby ste posilnili celkovú bezpečnostnú pozíciu. Power Platform Proces integrácie bezpečnosti do vášho vývojového cyklu je v podstate procesom sprísňovania. Rovnako ako sprísňovanie zdrojov, aj sprísňovanie vývoja kódu je kontextovo agnostické. Dôraz sa kladie na zvýšenie bezpečnosti, nie na funkčné požiadavky aplikácie.

Definície

Pojem Definícia
Životný cyklus vývoja bezpečnosti (SDL) Súbor postupov poskytovaných spoločnosťou Microsoft, ktoré podporujú požiadavky na zabezpečenie a dodržiavanie predpisov.
Životný cyklus vývoja softvéru (SDLC) Viacstupňový, systematický proces vývoja softvérových systémov.

Kľúčové dizajnérske stratégie

Bezpečnostné opatrenia by mali byť integrované vo viacerých bodoch 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.
  • Komponenty s nízkym kódom a komponenty zamerané na kód, ako aj konfigurácia, nevytvárajú zraniteľnosti kvôli zneužiteľnej implementácii a nesprávnym kódovacím postupom.
  • Komponenty s nízkym kódom a komponenty s prvým kódom a procesy nasadenia nie sú nijako ovplyvnené.
  • Zraniteľnosti odhalené incidentmi sú zmiernené.
  • Požiadavky na dodržiavanie predpisov 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 praktizované 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ú záťaž alebo novú funkciu pracovnej záťaže. Táto fáza je dôležitá, pretože uľahčuje vytvorenie ochranných rámcov, 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.

Napríklad, predstavte si pracovnú záťaž, kde používatelia zadávajú a upravujú údaje v rámci aplikácie. Možnosti bezpečnostného návrhu by mali zahŕňať záruky interakcie používateľa s údajmi, ako je overovanie 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ť. Možnosti zabezpečenia by mali zahŕňať hranice segmentácie, vstup a výstup cez firewall a ďalšie prierezové bezpečnostné aspekty.

Všetky tieto rozhodnutia by mali viesť k dobrej definícii bezpečnostného stavu pracovnej záťaže. Zdokumentujte bezpečnostné požiadavky v dohodnutej špecifikácii a zohľadnite ich v zozname nevybavených úloh. Dokument by mal výslovne uvádzať investície do bezpečnosti a kompromisy a riziká, ktoré je podnik ochotný podstúpiť, ak investície neschvália zainteresované strany v podniku. Napríklad môžete zdokumentovať potrebu používania IP firewallu v prostredí na ochranu údajov vašej organizácie obmedzením prístupu iba na povolené IP adresy. Power Platform Dataverse Ak zainteresované strany v podnikaní nie sú ochotné znášať dodatočné náklady spojené s používaním riešenia, ako je spravované prostredie, musia byť pripravené akceptovať 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 zdroju údajov tretej strany. Power Platform môže mať na to pripravený konektor, ale nemusí podporovať požiadavky na overenie schválené vašimi bezpečnostnými tímami. V tomto prípade môžu byť vaši bezpečnostní partneri ochotní akceptovať riziko použitia neschválenej metódy overovania. Prípadne môžete zvážiť použitie vlastného konektora a zároveň zvážiť výhody dlhšieho času vývoja a možného oneskorenia projektu.

Zhromažďovanie bezpečnostných požiadaviek je kľúčovou súčasťou tejto fázy. Bez tohto úsilia budú fázy návrhu a implementácie založené na nešpecifikovaných rozhodnutiach, čo môže viesť k bezpečnostným medzerám alebo zmenám v požiadavkách, ktoré predĺžia čas vývoja. Možno budete musieť neskôr zmeniť implementáciu, aby ste zohľadnili bezpečnosť, č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 sú niektoré typické úlohy:

  • Definujte bezpečnostný rozmer architektúry. Prekryte architektúru bezpečnostnými kontrolami. Napríklad ovládacie prvky, ktoré sú praktické na hraniciach izolácie siete, typy identít a metódy overovania potrebné pre komponenty pracovnej záťaže a typ metód šifrovania, ktoré sa majú použiť.

  • Vyhodnoťte affordancie poskytované platformou. Je dôležité pochopiť, rozdelenie zodpovednosti medzi vami a Power Platform. Vyhnite sa prekrývaniu alebo duplicite s Power Platform natívne bezpečnostné kontroly. Získate lepšie bezpečnostné krytie 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 postupoch, použite politiky údajov na kategorizáciu spôsobu použitia konektorov.

    Vyberajte iba dôveryhodné referenčné implementácie, šablóny, komponenty kódu, skripty a knižnice. Váš návrh by mal tiež špecifikovať bezpečnú 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 podelia sa o svoj plán zodpovedného zverejňovania informácií. Akýkoľvek bezpečnostný incident by mal byť okamžite nahlásený, aby ste mohli podniknúť potrebné kroky. Taktiež niektoré knižnice alebo implementácie referencií môžu byť vašou organizáciou zakázané. Napríklad, aj keď je bezpečná a neobsahuje zraniteľnosti, stále môže byť zamietnutá, pretože používa funkcie, ktoré ešte nie sú schválené vašou organizáciou, licenčné obmedzenia alebo model podpory referenčnej implementácie.

    Aby ste zabezpečili dodržiavanie týchto pokynov, veďte zoznam schválených a/alebo neschválených rámcov, knižníc a dodávateľov a uistite sa, že vaši tvorcovia sú s týmto zoznamom oboznámení. Ak je to možné, umiestnite do vývojových kanálov ochranné zábradlia na podporu zoznamu. V čo najväčšej miere automatizujte používanie nástrojov na skenovanie závislostí a vyhľadávanie zraniteľností.

  • Bezpečne uložte tajomstvá aplikácie. Bezpečne implementujte používanie tajných kódov aplikácie a predzdieľaných kľúčov, ktoré vaša aplikácia používa. Poverenia a tajné údaje aplikácie by sa nikdy nemali ukladať do zdrojového kódu pracovnej záťaže (aplikácie alebo postupu). Používajte externé zdroje, ako napríklad Azure Key Vault, aby ste zabezpečili, že ak sa váš zdrojový kód stane dostupným potenciálnemu útočníkovi, nebude k nemu možné získať ďalší prístup.

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

  • Definujte, ako budú koncoví používatelia interagovať s pracovnou záťažou a údajmi. Zvážte, či budú mať používatelia priamy prístup k údajom, akú úroveň prístupu potrebujú a odkiaľ budú k údajom pristupovať. Premýšľajte o tom, 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í ich potrebujú. Vyhýbajte sa zložitým bezpečnostným modelom, ktoré podporujú obchádzanie bezpečnostných prekážok.

  • Vyhnite sa tvrdému kódovaniu. Vyhnite sa pevnému kódovaniu URL adries a kľúčov. Napríklad sa vyhnite pevnému kódovaniu URL adresy alebo kľúča pre backendovú službu v akcii HTTP. Power Automate Namiesto toho použite vlastný konektor alebo premennú prostredia pre URL adresu a Azure Key Vault pre kľúč API.

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

Poznámka

Počas tejto fázy vykonajte modelovanie hrozieb. Modelovanie hrozieb môže potvrdiť, že dizajnové rozhodnutia 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é modelovanie 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. Robenie tak počas tejto fázy vám pomôže 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 celého vývoja softvéru.

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

Fáza vývoja a testovania

Počas tejto fázy je cieľom predchádzať bezpečnostným chybám a manipulácii s kódom, zostavovaním a nasadzovaním.

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

Vývojový tím by mal mať školenie v oblasti bezpečných postupov kódovania . Napríklad, vývojári by mali byť oboznámení s bezpečnostnými konceptmi pri implementácii modelu zabezpečenia s najnižšími privilégiami, s politikami zabezpečenia obsahu pre aplikácie riadené modelom na obmedzenie vkladania na dôveryhodné domény a s metódami overovania konektorov/lokálnych brán. Microsoft Dataverse

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

Vykonávajte interné partnerské kontroly kódu s cieľom podporiť neustále vzdelávanie.

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

Kontrola riešení by sa mala používať pre zdroje a zdrojový kód akéhokoľvek tradičného kódu by sa dal skontrolovať na potenciálne bezpečnostné chyby vrátane prítomnosti poverení v kóde. Power Platform Identifikujte možné prípady úniku poverení a tajných údajov v zdrojovom kóde a konfiguračných súboroch. Toto je vhodný čas na kontrolu toho, ako sa budú s povereniami na pripojenie zaobchádzať v produkčnom prostredí.

Vykonajte fuzz testovanie

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

Napíšte len toľko kódu, koľko potrebujete

Keď znížite svoju kódovú stopu, znížite aj pravdepodobnosť bezpečnostných chýb. Namiesto duplikovania kódu znovu použite kód a knižnice, ktoré sa už používajú a prešli bezpečnostnými overeniami. Detekcia a kontrola verzie, zraniteľnosti a právnych záväzkov softvéru s otvoreným zdrojovým kódom. Existuje stále viac zdrojov s otvoreným zdrojovým kódom, takže by sa to nemalo prehliadať. Power Platform Ak je to možné, malo by sa to prediskutovať už počas fázy návrhu, aby sa predišlo problémom na poslednú chvíľu.

Chráňte vývojárske prostredia

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

Úložisko zdrojového kódu musí byť tiež chránené. Poskytnite prístup k úložiskám kódu na základe potreby a čo najviac znížte vystavenie zraniteľnostiam, aby ste sa vyhli útokom. Majte dôkladný proces na kontrolu kódu zraniteľností. Na tento účel použite bezpečnostné skupiny a implementujte schvaľovací proces, ktorý je založený na obchodných odôvodneniach.

Bezpečné nasadenie kódu

Nestačí len zabezpečiť kód. Ak beží v zneužiteľných kanáloch, všetko úsilie o zabezpečenie je márne a neúplné. Prostredia pre zostavovanie a vydávanie musia byť tiež chránené, pretože chcete zabrániť zlým aktérom v spúšťaní škodlivého kódu vo vašom kanáli.

Udržiavajte aktuálny inventár všetkých komponentov integrovaných do vašej aplikácie

Každý nový komponent integrovaný do aplikácie zvyšuje plochu pre útok. Aby ste zabezpečili riadnu zodpovednosť a upozornenia pri pridávaní alebo aktualizácii nových komponentov, mali by ste mať zoznam týchto komponentov. Pravidelne kontrolujte, či sa váš manifest zhoduje s tým, čo je súčasťou vášho procesu zostavovania. Týmto spôsobom sa zabezpečí, že sa neočakávane nepridajú žiadne nové komponenty, ktoré obsahujú zadné vrátka alebo iný škodlivý softvér.

Odporúčame používať Potrubia pre Power Platform pre vaše nasadenia. Rozšírte kanály pomocou akcií GitHub. Ak používate pracovné postupy GitHub, uprednostňujte úlohy vytvorené spoločnosťou Microsoft. Úlohy tiež overujte, pretože bežia v bezpečnostnom kontexte vášho kanála.

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

Fáza výroby

Produkčná fáza predstavuje posledná zodpovedná príležitosť na odstránenie bezpečnostných medzier. Uchovávajte si záznamy o zlatom obrázku, ktorý bol vydaný do produkcie.

Ponechať verzované artefakty

Uchovávajte katalóg všetkých nasadených prostriedkov a ich verzií. Tieto informácie sú užitočné počas triedenia incidentov, pri riešení problémov a pri vrátení systému do funkčného stavu. Verzované aktíva je možné porovnať aj s publikovanými oznámeniami o bežných zraniteľnostiach a rizikách (CVE). Na vykonanie týchto porovnaní by ste mali použiť automatizáciu.

Núdzové opravy

Váš automatizovaný návrh potrubia by mal mať flexibilitu podpora bežných aj núdzových nasadení. Táto flexibilita je dôležitá pre 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. Tento proces môže zahŕňať komunikáciu medzi tímami. Kanál by mal umožňovať rýchle nasadenie s postupným vracaním dopredu a späť, ktoré rieši bezpečnostné opravy, kritické chyby a aktualizácie kódu, ku ktorým dochádza 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 pomocou núdzového kanála, starostlivo zvážte, ktoré automatizované testy je možné obísť. Vyhodnoťte hodnotu každého testu vzhľadom na čas 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 prostrediach s nižšou úrovňou ochrany, pretože tieto prostredia nemusia mať prísne bezpečnostné kontroly, ktoré má produkčné prostredie.** Vyhnite sa pripájaniu z neprodukčnej aplikácie k produkčnej databáze a vyhnite sa pripájaniu neprodukčných komponentov k produkčným sieťam.

Používajte progresívnu expozíciu

Používajte postupné sprístupňovanie funkcií pre podmnožinu používateľov na základe zvolených kritérií. Ak sa vyskytnú problémy, dopad na týchto používateľov je minimalizovaný. Tento prístup je bežnou stratégiou na zmiernenie rizika, pretože zmenšuje povrchovú plochu. Ako bude funkcia dozrievať a budete mať väčšiu dôveru v bezpečnostné záruky, môžete ju postupne vydávať širšej skupine používateľov.

Fáza údržby

Cieľom tejto fázy je zabezpečiť, aby sa bezpečnostná situácia časom nezhoršovala . SDLC je prebiehajúci agilný proces. Koncepty uvedené v predchádzajúcich fázach sa vzťahujú aj na túto fázu, pretože požiadavky sa časom menia.

Neustále zlepšovanie. Neustále hodnotiť a zlepšovať bezpečnosť procesu vývoja softvéru s ohľadom na kontroly kódu, spätnú väzbu, získané poznatky a vyvíjajúce sa hrozby, ako aj nové funkcie, ktoré sprístupňuje Power Platform.

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

Údržba zahŕňa aj opravy incidentov. Ak sa vo výrobe zistia problémy, je potrebné ich okamžite integrovať späť do procesu, aby sa už neopakovali.

Neustále zlepšujte svoje postupy bezpečného kódovania, aby ste držali krok s aktuálnymi hrozbami.

SDL 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. Spoliehanie sa na model STRIDE pomáha riešiť najčastejšie problémy s neistý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í. Viac informácií nájdete v dokumente OWASP Top 10 Risks: Mitigations v Power Platform.

Power Platform uľahčenie

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

Nástroje Defender for DevOps a SAST (Static Application Security Testing) sú súčasťou balíka 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 časť Použitie kontroly riešení na overenie vašich riešení.

Kontrolný zoznam zabezpečenia

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

Kontrolný zoznam zabezpečenia

  • Last updated on