Piezīmes
Lai piekļūtu šai lapai, ir nepieciešama autorizācija. Varat mēģināt pierakstīties vai mainīt direktorijus.
Lai piekļūtu šai lapai, ir nepieciešama autorizācija. Varat mēģināt mainīt direktorijus.
Attiecas uz šo Power Platform labi arhitektūras drošības kontrolsaraksta ieteikumu:
| SE:09 | Izveidojiet visaptverošu testēšanas režīmu, kas apvieno pieejas drošības problēmu novēršanai, draudu novēršanas ieviešanas validēšanai un draudu noteikšanas mehānismu pārbaudei. |
|---|
Stingra testēšana ir laba drošības dizaina pamats. Testēšana ir taktisks validācijas veids, lai pārliecinātos, ka kontrole darbojas, kā paredzēts. Testēšana ir arī proaktīvs veids, kā atklāt sistēmas ievainojamību.
Izveidojiet testēšanas stingrību, izmantojot kadenci un verifikāciju no vairākām perspektīvām. Jums vajadzētu iekļaut iekšējus viedokļus, kas pārbauda platformu un infrastruktūru, un ārējos novērtējumus, kas pārbauda sistēmu kā ārējs uzbrucējs.
Šajā rokasgrāmatā ir sniegti ieteikumi, kā pārbaudīt darba slodzes drošības stāvokli. Ieviesiet šīs testēšanas metodes, lai uzlabotu darba slodzes izturību pret uzbrukumiem un saglabātu konfidencialitāti, integritāti un resursu pieejamību.
Definīcijas
| Termins | Definīcija |
|---|---|
| Lietojumprogrammu drošības testēšana (AST) | Microsoft drošības izstrādes dzīves cikla (SDL) paņēmiens, kas izmanto baltās un melnās kastes testēšanas metodes, lai pārbaudītu drošības ievainojamību kodā. |
| Melnās kastes testēšana | Testēšanas metodika, kas apstiprina ārēji redzamo lietojumprogrammu uzvedību, nezinot sistēmas iekšējos elementus. |
| Zilā komanda | Komanda, kas aizstāvas pret sarkanās komandas uzbrukumiem kara spēles vingrinājumā. |
| Iekļūšanas testēšana | Testēšanas metodoloģija, kas izmanto ētiskas uzlaušanas metodes, lai pārbaudītu sistēmas drošības aizsardzību. |
| Sarkanā komanda | Komanda, kas spēlē pretinieka lomu un mēģina uzlauzt sistēmu kara spēles vingrinājumā. |
| Drošības izstrādes dzīves cikls (SDL) | Microsoft nodrošināta prakses kopa, kas atbalsta drošības nodrošināšanas un atbilstības prasības. |
| Programmatūras izstrādes dzīves cikls (SDLC) | Daudzpakāpju, sistemātisks process programmatūras sistēmu izstrādei. |
| Baltās kastes testēšana | Testēšanas metodika, kurā praktizējošajam lietotājam ir zināma kodeksa struktūra. |
Galvenās dizaina stratēģijas
Testēšana ir neapspriežama stratēģija, jo īpaši drošības jomā. Tas ļauj proaktīvi atklāt un risināt drošības problēmas, pirms tās var izmantot, un pārbaudīt, vai ieviestās drošības vadīklas darbojas, kā paredzēts.
Testēšanas tvērumam jāietver lietojumprogramma, infrastruktūra un automatizētie un cilvēka procesi.
Piezīmes
Šajās vadlīnijās ir nošķirta testēšana un reaģēšana uz incidentiem. Lai gan testēšana ir noteikšanas mehānisms, kas ideāli novērš problēmas pirms ražošanas, to nevajadzētu jaukt ar koriģēšanu vai izmeklēšanu, kas tiek veikta kā daļa no reaģēšanas uz incidentiem. Atgūšanas aspekts no drošības incidentiem ir aprakstīts Ieteikumi reaģēšanai uz drošības incidentiem.
Iesaistieties testa plānošanā. Darba slodzes komanda, iespējams, neizstrādā testa gadījumus. Šis uzdevums bieži tiek centralizēts uzņēmumā vai to izpilda ārējie drošības eksperti. Darba slodzes komanda ir jāiesaista šajā izstrādes procesā, lai nodrošinātu, ka drošības garantijas integrējas lietojumprogrammas funkcionalitātē.
Domājiet kā uzbrucējs. Noformējiet testa gadījumus, pieņemot, ka sistēmai ir noticis uzbrukums. Tādā veidā jūs varat atklāt iespējamās ievainojamības un attiecīgi noteikt testu prioritātes.
Veiciet testus strukturētā veidā un ar atkārtojamu procesu. Veidojiet testēšanas stingrību, ņemot vērā kadenci, testu veidus, virzošos faktorus un paredzētos rezultātus.
Izmantojiet pareizo rīku darbam. Izmantojiet rīkus, kas ir konfigurēti darbam ar darba slodzi. Ja jums nav instrumenta, iegādājieties rīku. Neveidojiet to. Drošības rīki ir ļoti specializēti, un sava rīka izveide var radīt riskus. Izmantojiet centrālo SecOps komandu vai ārējo līdzekļu piedāvātās zināšanas un rīkus, ja darba slodzes komandai nav šādu zināšanu.
Iestatiet atsevišķas vides. Testus var klasificēt kā destruktīvus vai nedestruktīvus. Nesagraujošie testi nav invazīvi. Tie norāda, ka pastāv problēma, bet tie nemaina funkcionalitāti, lai novērstu problēmu. Destruktīvie testi ir invazīvi un var sabojāt funkcionalitāti, dzēšot datus no datu bāzes.
Testēšana ražošanas vidē sniedz vislabāko informāciju, bet rada vislielākos traucējumus. Ražošanas vidē jūs mēdzat veikt tikai nesagraujošus testus. Testēšana ar ražošanu nesaistītās vidēs parasti ir mazāk traucējoša, bet var precīzi neatspoguļot ražošanas vides konfigurāciju drošībai svarīgos veidos.
Varat izveidot izolētu ražošanas vides klonu, izmantojot vides kopēšanas līdzekli. Ja esat iestatījis izvietošanas konveijerus, varat arī izvietot savus risinājumus īpašā testēšanas vidē.
Vienmēr novērtējiet testa rezultātus. Testēšana ir veltīga pūle, ja rezultāti netiek izmantoti, lai noteiktu prioritātes darbībām un veiktu uzlabojumus augšup. Dokumentējiet atklātās drošības vadlīnijas, tostarp labāko praksi. Dokumentācija, kas fiksē rezultātus un koriģēšanas plānus, izglīto darba grupu par dažādiem veidiem, kā uzbrucēji var mēģināt pārkāpt drošību. Regulāri veiciet drošības apmācību izstrādātājiem, administratoriem un testētājiem.
Izstrādājot testēšanas plānus, padomājiet par šādiem jautājumiem:
- Cik bieži jūs sagaidāt, ka tests darbosies, un kā tas ietekmē jūsu vidi?
- Kādi ir dažādi testa veidi, kas jums jāizpilda?
Cik bieži jūs sagaidāt, ka testi darbosies?
Regulāri pārbaudiet darba slodzi, lai pārliecinātos, ka izmaiņas nerada drošības riskus un vai nav regresiju. Darba grupai ir jābūt gatavai reaģēt uz organizācijas drošības validācijām, kas var tikt veiktas jebkurā laikā. Ir arī testi, kurus varat izpildīt, reaģējot uz drošības incidentu. Turpmākajās sadaļās sniegti ieteikumi par pārbaužu biežumu.
Ikdienas testi
Ikdienas testi tiek veikti regulāri, kā daļa no standarta darbības procedūrām un atbilstības prasībām. Dažādi testi var tikt veikti dažādos ritmos, taču galvenais ir tas, ka tie tiek veikti periodiski un pēc grafika.
Jums vajadzētu integrēt šos testus savā SDLC, jo tie nodrošina padziļinātu aizsardzību katrā posmā. Dažādojiet testa komplektu, lai pārbaudītu identitātes, datu glabāšanas un pārraides, kā arī saziņas kanālu garantijas. Veiciet vienus un tos pašus testus dažādos dzīves cikla posmos, lai nodrošinātu, ka nav regresiju. Rutīnas testi palīdz noteikt sākotnējo etalonu. Tomēr tas ir tikai sākumpunkts. Atklājot jaunas problēmas tajos pašos dzīves cikla punktos, tiek pievienoti jauni testa gadījumi. Testi uzlabojas arī atkārtojoties.
Katrā posmā šīm pārbaudēm ir jāpārbauda pievienotais vai noņemtais kods vai mainītie konfigurācijas iestatījumi, lai noteiktu šo izmaiņu ietekmi uz drošību. Jums vajadzētu uzlabot testu efektivitāti ar automatizāciju, līdzsvarojot ar salīdzinošo izvērtēšanu.
Apsveriet iespēju veikt drošības testus kā daļu no automatizētas konveijera vai plānotas testa izpildes. Jo ātrāk atklājat drošības problēmas, jo vieglāk ir atrast kodu vai konfigurācijas izmaiņas, kas tās izraisa.
Nepaļaujieties tikai uz automatizētiem testiem. Izmantojiet manuālu testēšanu, lai atklātu ievainojamību, ko var uztvert tikai cilvēka pieredze. Manuālā testēšana ir piemērota izpētes lietošanas gadījumiem un nezināmu risku atrašanai.
Improvizēti testi
Improvizēti testi nodrošina drošības aizsardzības validāciju laikā. Drošības brīdinājumi, kas var ietekmēt darba slodzi tajā brīdī, aktivizē šos testus. Organizatoriskie mandāti var prasīt pauzes un testa domāšanu, lai pārbaudītu aizsardzības stratēģiju efektivitāti, ja brīdinājums pārvēršas ārkārtas situācijā.
Improvizēto testu ieguvums ir gatavība reālam incidentam. Šie testi var būt piespiedu funkcija, lai veiktu lietotāju pieņemšanas testēšanu (UAT).
Drošības komanda var auditēt visas darba slodzes un pēc vajadzības veikt šīs pārbaudes. Kā darba slodzes īpašniekam jums ir jāatvieglo un jāsadarbojas ar drošības komandām. Vienojieties ar drošības komandām pietiekami daudz laika, lai varētu sagatavoties. Atzīstiet un sazinieties ar savu komandu un ieinteresētajām pusēm, ka šie traucējumi ir nepieciešami.
Citos gadījumos jums var būt jāveic testi un jāziņo par sistēmas drošības stāvokli pret iespējamiem draudiem.
Kompromiss: Tā kā improvizēti testi ir traucējoši notikumi, sagaidiet uzdevumu prioritāti, kas var aizkavēt citu plānoto darbu.
Risks: Pastāv nezināmā risks. Improvizēti testi var būt vienreizēji centieni bez noteiktiem procesiem vai rīkiem. Bet galvenais risks ir iespējamais biznesa ritma pārtraukums. Jums ir jānovērtē šie riski attiecībā pret ieguvumiem.
Drošības incidentu testi
Ir testi, kas atklāj drošības incidenta cēloni tā avotā. Šīs drošības nepilnības ir jānovērš, lai nodrošinātu, ka incidents neatkārtojas.
Incidenti laika gaitā arī uzlabo testa gadījumus, atklājot esošās nepilnības. Komandai jāpielieto incidentā gūtās atziņas un regulāri jāiekļauj uzlabojumi.
Kādi ir dažādi testu veidi?
Testus var iedalīt kategorijās pēc tehnoloģijas un testēšanas metodoloģijām. Apvienojiet šīs kategorijas un pieejas šajās kategorijās, lai iegūtu pilnīgu pārklājumu.
Pievienojot vairākus testus un testu veidus, varat atklāt:
- Nepilnības drošības kontrolē vai kompensējošā kontrolē.
- Nepareizas konfigurācijas.
- Novērojamības un noteikšanas metožu nepilnības.
Labs draudu modelēšanas vingrinājums var norādīt uz galvenajām jomām, lai nodrošinātu testa pārklājumu un biežumu. Ieteikumus par draudu modelēšanu skatiet sadaļā Ieteikumi izstrādes dzīves cikla nodrošināšanai.
Lielāko daļu šajās sadaļās aprakstīto testu var veikt kā rutīnas testus. Tomēr dažos gadījumos atkārtojamība var radīt izmaksas un radīt traucējumus. Rūpīgi apsveriet šos kompromisus.
Testi, kas validē tehnoloģiju kaudzi
Šeit ir daži testu veidu un to fokusa jomu piemēri. Šis saraksts nav izsmeļošs. Pārbaudiet visu kaudzi, ieskaitot lietojumprogrammu kaudzi, priekšgalu, aizmuguri, API, datu bāzes un visas ārējās integrācijas.
- Datu drošība: pārbaudiet datu šifrēšanas un piekļuves kontroles efektivitāti, lai nodrošinātu, ka dati ir pienācīgi aizsargāti pret nesankcionētu piekļuvi un manipulācijām.
- Tīkls un savienojamība: pārbaudiet ugunsmūrus, lai pārliecinātos, ka tie atļauj tikai paredzēto, atļauto un drošu datplūsmu uz darba slodzi.
- Lietojumprogramma: pārbaudiet avota kodu, izmantojot lietojumprogrammu drošības testēšanas (AST) metodes, lai pārliecinātos, ka ievērojat drošas kodēšanas praksi, un lai konstatētu izpildlaika kļūdas, piemēram, atmiņas bojājumus un privilēģiju problēmas.
- Identitāte: novērtējiet, vai lomu piešķiršana un nosacījuma pārbaudes darbojas, kā paredzēts.
Testa metodoloģija
Testēšanas metodoloģijām ir daudz perspektīvu. Mēs iesakām veikt testus, kas nodrošina draudu meklēšanu, simulējot reālus uzbrukumus. Viņi var identificēt potenciālos apdraudējuma dalībniekus, to paņēmienus un to ekspluatāciju, kas apdraud darba slodzi. Padariet uzbrukumus pēc iespējas reālākus. Izmantojiet visus potenciālos draudu vektorus, kurus identificējat draudu modelēšanas laikā.
Šeit ir dažas priekšrocības, ko sniedz testēšana, izmantojot reālus uzbrukumus:
- Kad jūs padarāt šos uzbrukumus par daļu no ikdienas testēšanas, jūs izmantojat ārējo perspektīvu, lai pārbaudītu darba slodzi un pārliecinātos, ka aizsardzība spēj izturēt uzbrukumu.
- Balstoties uz gūtajām mācībām, komanda uzlabo savas zināšanas un prasmju līmeni. Komanda uzlabo situācijas izpratni un var pašnovērtēt savu gatavību reaģēt uz incidentiem.
Daži simulēto testu piemēri ir melnās kastes un baltās kastes testēšana, iekļūšanas testēšana un kara spēļu vingrinājumi.
Melnās un baltās kastes testēšana
Šie testa veidi piedāvā divas dažādas perspektīvas. Melnās kastes testos sistēmas iekšējie elementi nav redzami. Baltās kastes testos testētājam ir laba izpratne par lietojumprogrammu un pat piekļuve kodam, žurnāliem, resursu topoloģijai un konfigurācijām eksperimenta veikšanai.
Testi, kas simulē uzbrukumus, izmantojot iekļūšanas testēšanu
Drošības eksperti, kas nav daļa no organizācijas IT vai lietojumprogrammu komandām, veic iekļūšanas testēšanu vai pentesting. Viņi skatās uz sistēmu tā, kā ļaunprātīgi dalībnieki aptver uzbrukuma virsmu. Viņu mērķis ir atrast drošības nepilnības, apkopojot informāciju, analizējot ievainojamību un ziņojot par rezultātiem.
Praktizētājiem var būt nepieciešama piekļuve sensitīviem datiem visā organizācijā. Ievērojiet iesaistīšanās noteikumus, lai nodrošinātu, ka piekļuve netiek ļaunprātīgi izmantota. Skatiet resursus, kas uzskaitīti sadaļā Saistītā informācija.
Testi, kas simulē uzbrukumus, izmantojot kara spēļu vingrinājumus
Šajā simulēto uzbrukumu metodoloģijā ir divas komandas:
- Sarkanā komanda ir pretinieks, kas mēģina modelēt reālus uzbrukumus. Ja tie ir veiksmīgi, jūs atrodat nepilnības drošības dizainā un novērtējat to pārkāpumu sprādziena rādiusa ierobežošanu.
- Zilā komanda ir darba slodzes komanda, kas aizsargā pret uzbrukumiem. Viņi pārbauda savu spēju atklāt, reaģēt un novērst uzbrukumus. Viņi apstiprina aizsardzību, kas ir ieviesta, lai aizsargātu darba slodzes resursus.
Ja tie tiek veikti kā rutīnas testi, kara spēļu vingrinājumi var nodrošināt pastāvīgu redzamību un pārliecību, ka jūsu aizsardzība darbojas, kā paredzēts. Kara spēļu vingrinājumi var pārbaudīt visus līmeņus jūsu darba slodzēs.
Populāra izvēle reālistisku uzbrukumu scenāriju simulēšanai ir Microsoft Defender uzbrukuma Office 365 simulācijas apmācība.
Papildinformāciju skatiet sadaļā Ieskati un atskaites par uzbrukuma simulācijas apmācību.
Informāciju par sarkanās un zilās komandas iestatīšanu skatiet sadaļā Microsoft mākoņa sarkanā komanda.
Power Platform Atvieglošana
Microsoft Sentinel risinājums ļauj Microsoft Power Platform klientiem atklāt dažādas aizdomīgas darbības, piemēram:
- Power Apps Izpilde no nesankcionētām ģeogrāfiskajām vietām
- Aizdomīgu datu iznīcināšana Power Apps
- Masveida dzēšana Power Apps
- Pikšķerēšanas uzbrukumi, kas veikti, izmantojot Power Apps
- Power Automate Aizejošo darbinieku plūsmu aktivitāte
- Microsoft Power Platform Savienotāji, kas pievienoti videi
- Datu politiku atjaunināšana vai noņemšana Microsoft Power Platform
Papildinformāciju skatiet sadaļā Microsoft Sentinel risinājums, lai iegūtu Microsoft Power Platform pārskatu.
Produkta dokumentāciju skatiet sadaļā Microsoft Sentinel meklēšanas iespējas.
Microsoft Defender mākonim piedāvā ievainojamības skenēšanu dažādās tehnoloģiju jomās. Papildinformāciju skatiet sadaļā Ievainojamības skenēšanas iespējošana, izmantojot Microsoft Defender ievainojamības pārvaldību.
DevSecOps prakse integrē drošības testēšanu kā daļu no pastāvīgas un nepārtrauktas uzlabošanas domāšanas. Kara spēļu vingrinājumi ir izplatīta prakse, kas ir integrēta Microsoft biznesa ritmā. Papildinformāciju skatiet sadaļā Drošība programmā DevOps (DevSecOps).
Azure DevOps atbalsta trešo pušu rīkus, kurus var automatizēt kā daļu no nepārtrauktas integrācijas/nepārtrauktas izvietošanas (CI/CD) cauruļvadiem. Papildinformāciju skatiet sadaļā DevSecOps iespējošana ar Azure un GitHub.
Saistītā informācija
Jaunākos penetrācijas testus un drošības novērtējumu var atrast Microsoft Service Trust portālā.
Microsoft veic plašu Microsoft mākoņpakalpojumu testēšanu. Šī testēšana ietver iekļūšanas testēšanu, un rezultāti tiek publicēti jūsu organizācijas pakalpojumu uzticamības portālā. Jūsu organizācija var veikt savu iekļūšanas Microsoft Power Platform testu un Microsoft Dynamics 365 pakalpojumos. Visai iekļūšanas testēšanai ir jāievēro Microsoft mākoņa iekļūšanas testēšanas noteikumi. Ir svarīgi atcerēties, ka daudzos gadījumos Microsoft mākonis izmanto koplietojamu infrastruktūru, lai viesotu jūsu līdzekļus un līdzekļus, kas pieder citiem klientiem. Jums ir jāierobežo visi iekļūšanas testi ar saviem aktīviem un jāizvairās no neparedzētām sekām citiem apkārtējiem klientiem.
Ievērojiet iesaistīšanās noteikumus, lai nodrošinātu, ka piekļuve netiek ļaunprātīgi izmantota. Uzziniet vairāk par simulētu uzbrukumu plānošanu un izpildi:
Pakalpojumā Azure varat simulēt pakalpojuma atteikuma (DoS) uzbrukumus. Noteikti ievērojiet politikas, kas izklāstītas Azure DDoS aizsardzības simulācijas testēšanā.
Drošības kontrolsaraksts
Skatiet pilnu ieteikumu kopumu.