Ieteikumi izstrādes dzīves cikla nodrošināšanai

Attiecas uz šo Power Platform labi arhitektūras drošības kontrolsaraksta ieteikumu:

SE:02 Uzturiet drošu izstrādes dzīves ciklu, izmantojot nostiprinātu, lielākoties automatizētu un auditējamu programmatūras piegādes ķēdi. Iekļaujiet drošu dizainu, izmantojot draudu modelēšanu, lai aizsargātu pret drošību traucējošu ieviešanu.

Šajā rokasgrāmatā ir aprakstīti ieteikumi koda un izstrādes vides aizsardzībai, izmantojot drošības paraugpraksi visā izstrādes ciklā.

Darba slodzes pamatā ir komponenti, kas īsteno biznesa loģiku. Šie komponenti var būt zema koda elementu, piemēram, audekla lietotņu un plūsmu, un koda elementu, piemēram, spraudņu, sajaukums. Visiem komponentiem, kas veido jūsu darba slodzi, jābūt bez drošības defektiem, lai nodrošinātu konfidencialitāti, integritāti un pieejamību.

Infrastruktūras plaknes nodrošināšana ar identitātes un tīkla vadīklām ir svarīga, taču ar to nepietiek. Novērsiet sliktu darba slodzes Power Platform ieviešanu un apdraudētas darbības šajās darba slodzēs, lai stiprinātu vispārējo drošības stāvokli. Drošības integrēšanas process izstrādes dzīves ciklā būtībā ir nostiprinošais process. Tāpat kā resursu nostiprināšana, arī koda izstrādes pastiprināšana ir atkarīga no konteksta. Galvenā uzmanība tiek pievērsta drošības uzlabošanai, nevis lietojumprogrammas funkcionālajām prasībām.

Definīcijas

Termins Definīcija
Drošības izstrādes dzīves cikls (SDL) Microsoft nodrošināts prakses kopums, kas atbalsta drošības nodrošināšanas un atbilstības prasības.
Programmatūras izstrādes dzīves cikls (SDLC) Daudzpakāpju, sistemātisks programmatūras sistēmu izstrādes process.

Galvenās dizaina stratēģijas

Drošības pasākumi ir jāintegrē vairākos punktos jūsu esošajā programmatūras izstrādes dzīves ciklā (SDLC), lai nodrošinātu:

  • Noformējuma izvēle nerada drošības nepilnības.
  • Zema koda un koda komponenti, kā arī konfigurācija nerada ievainojamību izmantojamas ieviešanas un nepareizas kodēšanas prakses dēļ.
  • Zema koda un koda komponenti un izvietošanas procesi netiek manipulēti.
  • Incidentu rezultātā atklātās ievainojamības tiek mazinātas.
  • Atbilstības prasības netiek apdraudētas vai samazinātas.
  • Audita reģistrēšana tiek ieviesta visās vidēs.

Turpmākajās sadaļās ir sniegtas drošības stratēģijas visbiežāk izmantotajiem SDLC posmiem.

Prasību fāze

Prasību fāzes mērķis ir apkopot un analizēt funkcionālās un nefunkcionālās prasības darba slodzei vai jaunai darba slodzes iezīmei. Šis posms ir svarīgs, jo tas atvieglo darba slodzes mērķiem pielāgotu aizsargmargu izveidi. Datu un darba slodzes integritātes aizsardzībai jābūt galvenajai prasībai katrā izstrādes dzīves cikla posmā.

Piemēram, apsveriet darba slodzi, kurā lietotāji ievada un modificē datus lietojumprogrammā. Drošības dizaina izvēlēm būtu jāaptver lietotāja mijiedarbības ar datiem garantijas, piemēram, lietotāja identitātes autentifikācija un autorizēšana un atļaušana tikai atļautajām darbībām ar datiem. Nefunkcionālās prasības attiecas uz pieejamību, lietojamību un uzturamību. Drošības izvēlēm jāietver segmentācijas robežas, ugunsmūra ienākšana un izeja, kā arī citas transversālas drošības problēmas.

Visiem šiem lēmumiem vajadzētu labi definēt darba slodzes drošības stāvokli. Dokumentējiet drošības prasības saskaņotā specifikācijā un atspoguļojiet tās uzkrājumā. Dokumentā skaidri jānorāda drošības ieguldījumi un kompromisi un riski, kurus uzņēmums ir gatavs uzņemties, ja investīcijas neapstiprina biznesa ieinteresētās personas. Piemēram, varat dokumentēt nepieciešamību izmantot IP ugunsmūri Power Platform vidē, lai aizsargātu organizācijas datus, ierobežojot Dataverse piekļuvi tikai atļautajām IP atrašanās vietām. Ja biznesa ieinteresētās puses nevēlas segt papildu izmaksas, izmantojot tādu risinājumu kā pārvaldītas vides, tām jābūt gatavām uzņemties risku, ka organizatoriskie resursi var piekļūt no publiskām vietām, piemēram, kafejnīcas. Kā vēl vienu piemēru iedomājieties, ka jūsu lietojumprogrammai ir jāizveido savienojums ar trešās puses datu avotu. Power Platform Iespējams, tam ir gatavs savienotājs, bet tas var neatbalstīt jūsu drošības komandu apstiprinātās autentifikācijas prasības. Šādā gadījumā jūsu drošības ieinteresētās puses var būt gatavas uzņemties risku, izmantojot neapstiprinātu autentifikācijas metodi. Varat arī izpētīt pielāgota savienotāja izmantošanu, vienlaikus izvērtējot priekšrocības, ko sniedz pagarināts izstrādes laiks un iespējamā projekta aizkavēšanās.

Drošības prasību vākšana ir kritiska šī posma daļa. Bez šiem centieniem izstrādes un ieviešanas fāzes būs balstītas uz neformulētām izvēlēm, kas var izraisīt drošības nepilnības vai mainīgas prasības, kas palielinās izstrādes laiku. Iespējams, vēlāk būs jāmaina ieviešana, lai pielāgotos drošībai, kas var būt dārga.

Projektēšanas fāze

Šajā posmā drošības prasības tiek pārveidotas par tehniskām prasībām. Tehniskajā specifikācijā dokumentējiet visus projektēšanas lēmumus, lai izvairītos no neskaidrībām ieviešanas laikā. Šeit ir daži tipiski uzdevumi:

  • Definējiet arhitektūras drošības dimensiju. Pārklājiet arhitektūru ar drošības vadīklām. Piemēram, vadības ierīces, kas ir praktiskas tīkla izolācijas robežām, identitātes veidiem un autentifikācijas metodēm, kas nepieciešamas darba slodzes komponentiem, un izmantojamo šifrēšanas metožu veidu.

  • Novērtējiet platformas nodrošinātās pieejamus. Ir svarīgi saprast atbildības sadalījumu starp jums un Power Platform. Izvairieties no pārklāšanās vai dublēšanās ar Power Platform vietējām drošības vadīklām. Jūs iegūsit labāku drošības pārklājumu un varēsiet pārdalīt izstrādes resursus lietojumprogrammas vajadzībām.

    Piemēram, tā vietā, lai izveidotu pielāgotu loģiku, kas reaktīvi identificē un brīdina par neapstiprinātiem lietošanas modeļiem programmās un plūsmās, izmantojiet datu politikas, lai kategorizētu, kā savienotājus var izmantot.

    Izvēlieties tikai uzticamas atsauces implementācijas, veidnes, koda komponentus, skriptus un bibliotēkas. Noformējumam ir jānorāda arī droša versiju kontrole. Lietojumprogrammu atkarības ir jāiegūst no uzticamām pusēm. Trešo pušu piegādātājiem ir jāspēj izpildīt jūsu drošības prasības un kopīgot savu atbildīgās informācijas atklāšanas plānu. Nekavējoties jāziņo par jebkuru drošības incidentu, lai jūs varētu veikt nepieciešamās darbības. Jūsu organizācija var aizliegt arī noteiktas bibliotēkas vai atsauču ieviešanas. Piemēram, pat ja tas ir drošs un bez ievainojamības, tas joprojām var būt neatļauts, jo tajā tiek izmantoti līdzekļi, kurus jūsu organizācija vēl nav apstiprinājusi, licencēšanas ierobežojumi vai atsauces ieviešanas atbalsta modelis.

    Lai nodrošinātu, ka šie norādījumi tiek ievēroti, uzturiet apstiprināto un/vai neapstiprināto sistēmu, bibliotēku un piegādātāju sarakstu un pārliecinieties, ka jūsu veidotāji ir iepazinušies ar šo sarakstu. Ja iespējams, novietojiet aizsargmargas izstrādes cauruļvados, lai atbalstītu sarakstu. Cik vien iespējams, automatizējiet rīku izmantošanu, lai skenētu atkarības, lai meklētu ievainojamību.

  • Droši glabājiet lietojumprogrammu noslēpumus. Droši ieviesiet lietojumprogrammu noslēpumu un iepriekš koplietojamo atslēgu izmantošanu, ko izmanto jūsu lietojumprogramma. Akreditācijas datus un lietojumprogrammu noslēpumus nekad nedrīkst glabāt darba slodzes avota kodā (lietojumprogrammā vai plūsmā). Izmantojiet ārējos resursus, piemēram, Azure Key Vault, lai nodrošinātu, ka, ja jūsu avota kods kļūst pieejams potenciālajam uzbrucējam, vairs nevar iegūt piekļuvi.

  • Droši izveidojiet savienojumu ar saviem datiem. Izmantojiet spēcīgos drošības līdzekļus, kas Microsoft Dataverse piedāvā jūsu datu aizsardzībai, piemēram, lomu un kolonnu līmeņa drošību. Citiem datu avotiem izmantojiet savienotājus, kuriem ir drošas autentifikācijas metodes. Izvairieties no vaicājumiem, kas lietotājvārdu un paroli saglabā vienkāršā tekstā. Izveidojot pielāgotus savienotājus, izvairieties no HTTP.

  • Definējiet, kā gala lietotāji mijiedarbosies ar darba slodzi un datiem. Apsveriet, vai lietotājiem būs tieša piekļuve datiem, kāds piekļuves līmenis viņiem ir nepieciešams un no kurienes viņi piekļūs datiem. Padomājiet par to, kā lietojumprogrammas tiks koplietotas ar gala lietotājiem. Pārliecinieties, ka piekļuve lietotnei un datiem būs tikai tiem, kam tā nepieciešama. Izvairieties no sarežģītiem drošības modeļiem, kas veicina risinājumus, lai apietu drošības bloķētājus.

  • Izvairieties no cietās kodēšanas. Izvairieties no URL un atslēgu cietās kodēšanas. Piemēram, izvairieties no cietā kodējuma iekļaušanas Power Automate HTTP darbībā URL vai atslēgas servera pakalpojumam. Tā vietā izmantojiet pielāgotu savienotāju vai vides mainīgo URL adresei un Azure Key Vault API atslēgai.

  • Definējiet testēšanas plānus. Definējiet skaidrus drošības prasību testa gadījumus. Novērtējiet, vai varat automatizēt šos testus savos cauruļvados. Ja jūsu komandai ir manuālas testēšanas procesi, iekļaujiet šo testu drošības prasības.

Piezīmes

Šajā fāzē veiciet apdraudējumu modelēšanu. Draudu modelēšana var apstiprināt, ka dizaina izvēles atbilst drošības prasībām, un atklāt nepilnības, kuras jums vajadzētu novērst. Ja jūsu darba slodze apstrādā ļoti sensitīvus datus, ieguldiet drošības ekspertos, kas var palīdzēt veikt apdraudējumu modelēšanu.

Sākotnējai apdraudējumu modelēšanai jānotiek projektēšanas fāzē, kad tiek definēta programmatūras arhitektūra un augsta līmeņa dizains. To darot šajā fāzē, jūs varēsiet identificēt potenciālās drošības problēmas, pirms tās tiek iekļautas sistēmas struktūrā. Tomēr šis vingrinājums nav vienreizējs. Tas ir nepārtraukts process, kam jāturpinās visas programmatūras attīstības laikā.

Lai iegūtu plašāku informāciju, skatiet Ieteikumi par draudu analīzi.

Izstrādes un testēšanas fāze

Šajā fāzē mērķis ir novērst drošības defektus un manipulācijas koda, būvēšanas un izvietošanas procesos.

Esiet labi apmācīti drošas koda prakses jomā

Izstrādes komandai jābūt apmācībai drošas kodēšanas praksē. Piemēram, izstrādātājiem ir jāpārzina drošības koncepcijas, lai ieviestu vismazāko privilēģiju drošības modeli, satura drošības politikas modeļu vadītām lietotnēm, lai ierobežotu iegulšanu uzticamos domēnos, un savienotāja/lokālās vārtejas autentifikācijas metodes. Microsoft Dataverse

Izstrādātājiem būtu jāpabeidz šī apmācība, pirms viņi sāk darbu ar Power Platform darba slodzēm.

Veikt iekšējas vienaudžu koda pārskatīšanas, lai veicinātu nepārtrauktu mācīšanos.

Izmantojiet koda analīzes rīkus

Resursiem jāizmanto risinājumu pārbaudītājs, un jebkura tradicionālā koda pirmkodu var pārbaudīt, lai atrastu iespējamus drošības trūkumus, tostarp akreditācijas datu esamību kodā. Power Platform Identificējiet iespējamos akreditācijas datu un slepeno datu izpaušanas gadījumus pirmkodā un konfigurācijas failos. Šis ir labs laiks, lai pārskatītu, kā savienojuma akreditācijas dati tiks apstrādāti ražošanas vidē.

Veiciet izplūduma testēšanu

Izmantojiet nepareizi veidotus un negaidītus datus, lai pārbaudītu ievainojamības un validētu kļūdu apstrādi, kas ir īpaši svarīgi risinājumiem, kas ietver Power Pages.

Uzrakstiet tieši tik daudz koda, cik nepieciešams

Samazinot koda ietekmi, jūs samazināt arī drošības defektu iespējamību. Atkārtoti izmantojiet kodu un bibliotēkas, kas jau tiek lietotas un ir izturējušas drošības validācijas, nevis dublējiet kodu. Atvērtā pirmkoda programmatūras versiju, ievainojamību un juridisko saistību noteikšana un pārbaude. Arvien vairāk atvērtā pirmkoda resursu ir pieejami, tāpēc to nevajadzētu ignorēt. Power Platform Ja iespējams, tas jāapspriež projektēšanas posmā, lai izvairītos no pēdējā brīža problēmām.

Aizsargājiet izstrādātāju vides

Izstrādātāju darbstacijas ir jāaizsargā ar spēcīgu tīkla un identitātes kontroli, lai novērstu atkļūšanu. Pārliecinieties, ka drošības atjauninājumi tiek rūpīgi ieviesti.

Arī pirmkoda krātuve ir jāaizsargā. Piešķiriet piekļuvi koda krātuvēm, pamatojoties uz nepieciešamību zināt, un pēc iespējas samaziniet ievainojamību risku, lai izvairītos no uzbrukumiem. Ieviesiet rūpīgu koda pārskatīšanas procesu, lai atklātu drošības ievainojamības. Šim nolūkam izmantojiet drošības grupas un ieviesiet apstiprināšanas procesu, kas balstīts uz biznesa pamatojumiem.

Droša koda izvietošana

Nepietiek tikai ar koda drošību. Ja tas darbojas izmantojamos cauruļvados, visi drošības centieni ir veltīgi un nepilnīgi. Arī būvēšanas un izlaišanas vides ir jāaizsargā, jo vēlaties novērst ļaunprātīgu dalībnieku ļaunprātīga koda palaišanu jūsu cauruļvadā.

Uzturēt atjauninātu visu jūsu lietojumprogrammā integrēto komponentu inventāru

Katrs jauns komponents, kas tiek integrēts lietojumprogrammā, palielina uzbrukuma virsmu. Lai nodrošinātu pienācīgu atbildību un brīdinājumus par jaunu komponentu pievienošanu vai atjaunināšanu, jums ir jābūt šo komponentu inventarizācijai. Regulāri pārbaudiet, vai jūsu manifests atbilst jūsu būvēšanas procesam. Tas palīdz nodrošināt, ka negaidīti netiek pievienoti jauni komponenti, kas satur aizmugurējās durvis vai citu ļaunprogrammatūru.

Izvietošanai iesakām izmantot Pipelines for Power Platform . Paplašiniet cauruļvadus, izmantojot GitHub Actions. Ja izmantojat GitHub darbplūsmas, dodiet priekšroku Microsoft veidotiem uzdevumiem. Tāpat validējiet uzdevumus, jo tie darbojas jūsu cauruļvada drošības kontekstā.

Izpētiet pakalpojumu vadītāju izmantošanu izvietošanai.

Ražošanas fāze

Ražošanas fāze atspoguļo pēdējā atbildīgā iespēja novērst drošības nepilnības. Saglabājiet ierakstu par zelta attēlu, kas tiek izlaists ražošanā.

Saglabāt versijas kārtotus artefaktus

Saglabājiet visu izvietoto resursu un to versiju katalogu. Šī informācija ir noderīga incidentu triāžas laikā, problēmu mazināšanas laikā un sistēmas atjaunošanas laikā. Versiju resursus var salīdzināt arī ar publicētajiem paziņojumiem par bieži sastopamajām ievainojamībām un riska faktoriem (CVE). Lai veiktu šīs salīdzināšanas, jums jāizmanto automatizācija.

Avārijas labojumi

Jūsu automatizētā cauruļvada projektam jābūt elastīgam, lai atbalstīt gan regulāras, gan ārkārtas izvietošanas. Šī elastība ir svarīga, lai atbalstītu ātrus un atbildīgus drošības risinājumus.

Atbrīvošana parasti ir saistīta ar vairākiem apstiprināšanas vārtiem. Apsveriet iespēju izveidot ārkārtas procesu, lai paātrinātu drošības problēmu novēršanu. Process varētu ietvert komunikāciju starp komandām. Cauruļvadam vajadzētu nodrošināt ātru atcelšanas un atcelšanas izvietošanu, kas risina drošības labojumus, kritiskas kļūdas un koda atjauninājumus, kas rodas ārpus regulārā izvietošanas dzīves cikla.

Piezīmes

Vienmēr prioritizējiet drošības risinājumus, nevis ērtības. Drošības labojumam nevajadzētu radīt regresiju vai kļūdu. Ja vēlaties paātrināt labošanu, izmantojot avārijas cauruļvadu, rūpīgi apsveriet, kurus automatizētos testus var apiet. Novērtējiet katra testa vērtību attiecībā pret izpildes laiku. Piemēram, vienības testi parasti tiek pabeigti ātri. Integrācijas vai pilnīgas pārbaudes var ilgt ilgu laiku.

Turiet dažādas vides atsevišķi

Ražošanas datus nevajadzētu izmantot zemākas kvalitātes vidēs.** jo šajās vidēs var nebūt tik stingras drošības kontroles kā ražošanas vidē. Izvairieties no savienojuma izveides no neražojošas lietojumprogrammas ar ražošanas datubāzi un izvairieties no neražojošu komponentu savienošanas ar ražošanas tīkliem.

Izmantojiet progresīvo ekspozīciju

Izmantojiet progresīvu ekspozīciju, lai izlaistu līdzekļus lietotāju apakškopai, pamatojoties uz izvēlētajiem kritērijiem. Ja rodas problēmas, ietekme uz šiem lietotājiem tiek samazināta līdz minimumam. Šī pieeja ir izplatīta riska mazināšanas stratēģija, jo tā samazina virsmas laukumu. Tā kā līdzeklis kļūst nobriedis un jums ir lielāka pārliecība par drošības garantijām, varat to pakāpeniski izlaist plašākam lietotāju lokam.

Uzturēšanas fāze

Šīs fāzes mērķis ir pārliecināties, ka drošības stāvoklis laika gaitā nesamazinās. SDLC ir nepārtraukts veikls process. Iepriekšējos posmos aplūkotie jēdzieni attiecas uz šo posmu, jo prasības laika gaitā mainās.

Nepārtraukta uzlabošana. Nepārtraukti novērtēt un uzlabot programmatūras izstrādes procesa drošību, ņemot vērā koda pārskatīšanu, atsauksmes, gūtās atziņas un mainīgos draudus, kā arī jaunās funkcijas, kas ir pieejamas Power Platform.

Mantoto aktīvu ekspluatācijas pārtraukšana, kas ir novecojuši vai vairs netiek izmantoti. Tas samazina aplikācijas virsmas laukumu.

Apkope ietver arī incidentu labojumus. Ja ražošanā tiek konstatētas problēmas, tās nekavējoties jāintegrē atpakaļ procesā, lai tās neatkārtotos.

Nepārtraukti uzlabojiet savu drošo kodēšanas praksi, lai neatpaliktu no draudu vides.

SDL Microsoft Power Platform

Power Platform ir būvēts uz droša noformējuma kultūras un metodoloģijas bāzes Gan kultūru, gan metodoloǵiju nemitīgi stiprina, izmantojot Microsoft vadošo Security Development Lifecycle(SDL) un apdraudējuma modelēšanas praksi.

Apdraudējuma modelēšanas izvērtējuma process nodrošina, ka apdraudējums tiek identificēts noformēšanas posmā, novērsts un pārbaudīts, lai pārliecinātos, ka draudu vairs nav.

Apdraudējuma modelēšanā arī tiek ņemtas vērā visas pakalpojumu izmaiņas, kas jau ir aktīvas, izmantojot nepārtrauktu, regulāru izvērtēšanu. Paļaušanās uz STRIDE modeli palīdz risināt visbiežāk sastopamās problēmas ar nedrošu dizainu.

Microsoft SDL ir ekvivalents OWASP Software Assurance Maturity Model (SAMM). Abi ir veidoti uz premisas, ka drošs noformējums ir būtisks tīmekļa programmas drošībai. Plašāku informāciju skatiet sadaļā OWASP Top 10 riski: mazināšana. Power Platform

Power Platform Atvieglošana

Microsoft drošības izstrādes dzīves cikls (SDL) iesaka drošu praksi, ko varat lietot savam izstrādes dzīves ciklam. Papildinformāciju skatiet sadaļā Microsoft drošības izstrādes dzīves cikls.

Defender for DevOps un SAST (statisko lietojumprogrammu drošības testēšana) rīki ir iekļauti kā daļa no GitHub Advanced Security un Azure DevOps. Šie rīki var palīdzēt izsekot organizācijas drošības rādītājam.

Izmantojot risinājumu pārbaudes līdzekli, varat veikt daudzveidīgu statisko analīzi risinājumiem, izmantojot labākās prakses kārtulu kopu, un ātri noteikt šīs problēmas shēmas. Skatiet rakstu Risinājumu pārbaudītāja izmantošana, lai validētu risinājumus.

Drošības kontrolsaraksts

Skatiet pilnu ieteikumu kopumu.

Drošības kontrolsaraksts

  • Last updated on