Pastaba.
Prieigai prie šio puslapio reikalingas įgaliojimas. Galite bandyti prisijungti arba pakeisti katalogus.
Prieigai prie šio puslapio reikalingas įgaliojimas. Galite bandyti pakeisti katalogus.
Taikoma šiai Power Platform "Well-Architected Security" kontrolinio sąrašo rekomendacijai:
| SE:09 | Sukurkite išsamų testavimo režimą, kuriame derinami saugos problemų prevencijos metodai, grėsmių prevencijos diegimų patvirtinimas ir grėsmių aptikimo mechanizmų testavimas. |
|---|
Griežtas testavimas yra gero saugumo dizaino pagrindas. Testavimas yra taktinė patvirtinimo forma, siekiant įsitikinti, kad kontrolė veikia taip, kaip numatyta. Testavimas taip pat yra aktyvus būdas aptikti sistemos pažeidžiamumą.
Nustatykite testavimo griežtumą per ritmą ir patikrinimą iš kelių perspektyvų. Turėtumėte įtraukti iš vidaus į išorę požiūrius, kurie testuoja platformą ir infrastruktūrą, ir išorės vertinimus, kurie testuoja sistemą kaip išorinis užpuolikas.
Šiame vadove pateikiamos rekomendacijos, kaip patikrinti darbo krūvio saugos būseną. Įgyvendinkite šiuos testavimo metodus, kad pagerintumėte savo darbo krūvio atsparumą atakoms ir išlaikytumėte konfidencialumą, vientisumą ir išteklių prieinamumą.
Apibrėžtys
| Terminas | Apibrėžtis |
|---|---|
| Taikomųjų programų saugumo testavimas (AST) | "Microsoft" saugos kūrimo ciklo (SDL) metodas, kuris naudoja baltosios ir juodosios dėžės testavimo metodikas, kad patikrintų, ar kode nėra saugos pažeidžiamumų. |
| Juodosios dėžės testavimas | Testavimo metodika, kuri patvirtina išoriškai matomą programos elgseną nežinant sistemos vidinių dalių. |
| Mėlyna komanda | Komanda, kuri ginasi nuo raudonosios komandos atakų karo žaidimo pratybose. |
| Įsiskverbimo testavimas | Testavimo metodika, kuri naudoja etiškus įsilaužimo metodus sistemos saugumo apsaugai patvirtinti. |
| Raudona komanda | Komanda, kuri atlieka priešininko vaidmenį ir bando nulaužti sistemą karo žaidimo pratybose. |
| Saugos kūrimo ciklas (SDL) | "Microsoft" teikiamų praktikų rinkinys, palaikantis saugos užtikrinimo ir atitikties reikalavimus. |
| Programinės įrangos kūrimo ciklas (SDLC) | Daugiapakopis, sistemingas programinės įrangos sistemų kūrimo procesas. |
| Baltosios dėžės testavimas | Bandymo metodika, kai kodekso struktūra yra žinoma specialistui. |
Pagrindinės projektavimo strategijos
Testavimas yra nediskutuotina strategija, ypač saugumo srityje. Tai leidžia aktyviai aptikti ir spręsti saugos problemas prieš jas išnaudojant ir patikrinti, ar įdiegtos saugos kontrolės priemonės veikia taip, kaip numatyta.
Testavimo apimtis turi apimti programą, infrastruktūrą ir automatizuotus bei žmogiškuosius procesus.
Pastaba.
Šiose gairėse skiriamas testavimas ir reagavimas į incidentus. Nors testavimas yra aptikimo mechanizmas, kuris idealiai išsprendžia problemas prieš gamybą, jo nereikėtų painioti su taisymu ar tyrimu, kuris atliekamas reaguojant į incidentus. Atsigavimo po saugumo incidentų aspektas aprašytas Reagavimo į saugumo incidentus rekomendacijose.
Dalyvaukite planuojant testą. Darbo krūvio komanda gali nesukurti testavimo atvejų. Ši užduotis dažnai yra centralizuota įmonėje arba atliekama išorės saugumo ekspertų. Darbo krūvio komanda turėtų būti įtraukta į projektavimo procesą, siekiant užtikrinti, kad saugumo garantijos būtų integruotos su programos funkcijomis.
Mąstykite kaip užpuolikas. Sukurkite testavimo atvejus darant prielaidą, kad sistema buvo užpulta. Tokiu būdu galite atskleisti galimus pažeidžiamumus ir atitinkamai nustatyti testų prioritetus.
Atlikite testus struktūrizuotai ir pakartojamu procesu. Sukurkite testavimo griežtumą pagal ritmą, testų tipus, varomuosius veiksnius ir numatomus rezultatus.
Naudokite darbui tinkamą įrankį. Naudokite įrankius, sukonfigūruotus dirbti su darbo krūviu. Jei neturite įrankio, nusipirkite įrankį. Nestatyk jo. Saugos įrankiai yra labai specializuoti, o savo įrankio kūrimas gali kelti pavojų. Pasinaudokite centrinių "SecOps" komandų arba išorinėmis priemonėmis siūlomomis žiniomis ir įrankiais, jei darbo krūvio komanda neturi šios patirties.
Nustatykite atskiras aplinkas. Bandymai gali būti klasifikuojami kaip destruktyvūs arba nedestruktyvūs. Neardomieji bandymai nėra invaziniai. Jie rodo, kad yra problema, bet jie nekeičia funkcionalumo, kad išspręstų problemą. Destruktyvūs testai yra invaziniai ir gali pakenkti funkcionalumui, ištrindami duomenis iš duomenų bazės.
Testavimas gamybos aplinkoje suteikia geriausią informaciją, bet sukelia daugiausiai trikdžių. Gamybos aplinkoje esate linkę atlikti tik neardomuosius bandymus. Testavimas ne gamybinėje aplinkoje paprastai yra mažiau trikdantis, tačiau gali tiksliai neatspindėti gamybos aplinkos konfigūracijos saugai svarbiais būdais.
Galite sukurti izoliuotą gamybos aplinkos kloną naudodami aplinkos kopijavimo funkciją. Jei nustatėte diegimo srautus, taip pat galite įdiegti sprendimus tam skirtoje testavimo aplinkoje.
Visada įvertinkite bandymo rezultatus. Testavimas yra veltui, jei rezultatai nenaudojami veiksmų prioritetams nustatyti ir patobulinimams atlikti. Dokumentuokite atskleistas saugos gaires, įskaitant geriausią praktiką. Dokumentai, kuriuose fiksuojami rezultatai ir taisymo planai, supažindina komandą su įvairiais būdais, kuriais užpuolikai gali bandyti pažeisti saugą. Reguliariai rengkite saugos mokymus kūrėjams, administratoriams ir testuotojams.
Kurdami testavimo planus pagalvokite apie šiuos klausimus:
- Kaip dažnai tikitės, kad testas bus vykdomas ir kaip jis veikia jūsų aplinką?
- Kokius skirtingus testų tipus turėtumėte atlikti?
Kaip dažnai tikitės, kad testai bus vykdomi?
Reguliariai tikrinkite darbo krūvį, kad įsitikintumėte, jog pakeitimai nekelia pavojaus saugai ir ar nėra regresijų. Komanda taip pat turi būti pasirengusi reaguoti į organizacijos saugos patikrinimus, kurie gali būti atliekami bet kuriuo metu. Taip pat yra testų, kuriuos galite atlikti reaguodami į saugos incidentą. Tolesniuose skirsniuose pateikiamos rekomendacijos dėl tyrimų dažnumo.
Įprastiniai tyrimai
Įprasti bandymai atliekami reguliariai, kaip standartinių darbo procedūrų dalis ir siekiant atitikti atitikties reikalavimus. Įvairūs testai gali būti atliekami skirtingu ritmu, tačiau svarbiausia, kad jie būtų atliekami periodiškai ir pagal grafiką.
Turėtumėte integruoti šiuos testus į savo SDLC, nes jie užtikrina išsamią gynybą kiekviename etape. Paįvairinkite testų rinkinį, kad patikrintumėte tapatybės, duomenų saugojimo ir perdavimo bei ryšio kanalų garantijas. Atlikite tuos pačius bandymus skirtingais gyvavimo ciklo etapais, kad įsitikintumėte, jog nėra jokių regresijų. Įprasti testai padeda nustatyti pradinį etaloną. Tačiau tai tik atspirties taškas. Tais pačiais gyvavimo ciklo momentais aptikdami naujas problemas, įtraukiate naujų testavimo atvejų. Testai taip pat pagerėja kartojant.
Kiekviename etape šie testai turėtų patikrinti įtrauktą arba pašalintą kodą arba pasikeitusius konfigūracijos parametrus, kad būtų galima aptikti šių pakeitimų poveikį saugai. Turėtumėte pagerinti testų efektyvumą automatizuodami, suderindami su tarpusavio vertinimais.
Apsvarstykite galimybę vykdyti saugos testus kaip automatizuoto srauto arba suplanuoto bandomojo vykdymo dalį. Kuo anksčiau aptiksite saugos problemų, tuo lengviau rasti jas sukeliantį kodą ar konfigūracijos pakeitimą.
Nepasikliaukite tik automatizuotais testais. Naudokite rankinį testavimą, kad aptiktumėte pažeidžiamumus, kuriuos gali užfiksuoti tik žmogaus patirtis. Rankinis testavimas yra naudingas tiriamiesiems naudojimo atvejams ir nežinomos rizikos nustatymui.
Improvizuoti testai
Improvizuoti testai suteikia saugumo apsaugos patvirtinimą laiku. Saugos įspėjimai, galintys turėti įtakos darbo krūviui tuo metu, suaktyvina šiuos testus. Organizaciniai įgaliojimai gali reikalauti pauzės ir testavimo mąstymo, kad būtų galima patikrinti gynybos strategijų efektyvumą, jei perspėjimas perauga į ekstremalią situaciją.
Improvizuotų testų nauda yra pasirengimas tikram incidentui. Šie testai gali būti priverstinė funkcija atlikti vartotojo priėmimo testavimą (UAT).
Saugos komanda gali patikrinti visus darbo krūvius ir prireikus atlikti šiuos testus. Kaip darbo krūvio savininkas, turite palengvinti ir bendradarbiauti su saugos komandomis. Derėkitės su saugos komandomis dėl pakankamai laiko, kad galėtumėte pasiruošti. Pripažinkite ir praneškite savo komandai ir suinteresuotosioms šalims, kad šie sutrikimai yra būtini.
Kitais atvejais gali tekti atlikti bandymus ir pranešti apie sistemos saugos būseną nuo galimos grėsmės.
Kompromisas: Kadangi improvizuoti testai yra trikdantys įvykiai, tikėkitės iš naujo nustatyti užduočių prioritetus, o tai gali atidėti kitus suplanuotus darbus.
Rizika: Yra nežinomybės pavojus. Improvizuoti testai gali būti vienkartinės pastangos be nustatytų procesų ar įrankių. Tačiau pagrindinė rizika yra galimas verslo ritmo nutraukimas. Turite įvertinti šią riziką, palyginti su nauda.
Saugumo incidentų testai
Yra testų, kurie nustato saugumo incidento priežastį jo šaltinyje. Šios saugumo spragos turi būti pašalintos, kad incidentas nepasikartotų.
Incidentai laikui bėgant taip pat pagerina testavimo atvejus, atskleisdami esamas spragas. Komanda turėtų pritaikyti incidento metu išmoktas pamokas ir reguliariai įtraukti patobulinimus.
Kokie yra skirtingi testų tipai?
Testus galima suskirstyti į kategorijas pagal technologijas ir testavimo metodikas. Sujunkite šias kategorijas ir metodus tose kategorijose, kad gautumėte visišką aprėptį.
Pridėję kelis testus ir testų tipus, galite atskleisti:
- Saugumo kontrolės arba kompensacinės kontrolės spragos.
- Netinkamos konfigūracijos.
- Stebėjimo ir aptikimo metodų spragos.
Geras grėsmių modeliavimo pratimas gali nurodyti pagrindines sritis, užtikrinančias testų aprėptį ir dažnumą. Grėsmių modeliavimo rekomendacijų ieškokite Rekomendacijos, kaip užtikrinti kūrimo ciklą.
Dauguma šiuose skyriuose aprašytų testų gali būti atliekami kaip įprasti testai. Tačiau pakartojamumas kai kuriais atvejais gali patirti išlaidų ir sukelti sutrikimų. Atidžiai apsvarstykite šiuos kompromisus.
Testai, patvirtinantys technologijų paketą
Štai keletas testų tipų ir jų tikslinių sričių pavyzdžių. Šis sąrašas nėra baigtinis. Išbandykite visą krūvą, įskaitant programų rietuvę, priekinę dalį, galinę dalį, API, duomenų bazes ir visas išorines integracijas.
- Duomenų saugumas: patikrinkite duomenų šifravimo ir prieigos kontrolės efektyvumą, kad įsitikintumėte, jog duomenys yra tinkamai apsaugoti nuo neteisėtos prieigos ir klastojimo.
- Tinklas ir ryšys: patikrinkite užkardas, kad įsitikintumėte, jog jos leidžia tik numatomą, leidžiamą ir saugų srautą į darbo krūvį.
- Programa: išbandykite šaltinio kodą naudodami programų saugos testavimo (AST) metodus, kad įsitikintumėte, jog laikotės saugaus kodavimo praktikos, ir pastebėtumėte vykdymo laiko klaidas, pvz., atminties sugadinimą ir teisių problemas.
- Tapatybė: įvertinkite, ar vaidmenų priskyrimas ir sąlyginiai patikrinimai veikia taip, kaip numatyta.
Bandymo metodika
Yra daug testavimo metodikų perspektyvų. Rekomenduojame atlikti bandymus, kurie įgalina grėsmių paiešką imituojant realaus pasaulio atakas. Jie gali nustatyti galimus grėsmės veikėjus, jų metodus ir išnaudojimus, kurie kelia grėsmę darbo krūviui. Padarykite išpuolius kuo tikroviškesnius. Naudokite visus galimus grėsmių vektorius, kuriuos nustatote modeliuodami grėsmes.
Štai keletas testavimo naudojant realaus pasaulio atakas privalumų:
- Kai šias atakas paverčiate įprastinio testavimo dalimi, naudojate išorės perspektyvą, kad patikrintumėte darbo krūvį ir įsitikintumėte, kad gynyba gali atlaikyti ataką.
- Remdamasi išmoktomis pamokomis, komanda tobulina savo žinias ir įgūdžių lygį. Komanda pagerina situacijos suvokimą ir gali įsivertinti savo pasirengimą reaguoti į incidentus.
Kai kurie imituojamų testų pavyzdžiai yra juodosios ir baltosios dėžės testavimas, įsiskverbimo testavimas ir karo žaidimų pratybos.
Juodosios ir baltosios dėžės testavimas
Šie testų tipai siūlo dvi skirtingas perspektyvas. Atliekant juodosios dėžės testus, sistemos vidinės dalys nėra matomos. Atlikdamas baltosios dėžės testus, testuotojas gerai supranta programą ir netgi turi prieigą prie kodo, žurnalų, išteklių topologijos ir eksperimento atlikimo konfigūracijų.
Testai, imituojantys atakas atliekant įsiskverbimo testavimą
Saugumo ekspertai, kurie nėra organizacijos IT ar programų komandų dalis, atlieka įsiskverbimo testavimą arba pentesting. Jie žiūri į sistemą taip, kaip piktavaliai veikėjai aprėpia atakos paviršių. Jų tikslas yra rasti saugumo spragas renkant informaciją, analizuojant pažeidžiamumus ir pranešant apie rezultatus.
Specialistams gali prireikti prieigos prie slaptų duomenų visoje organizacijoje. Laikykitės įtraukimo taisyklių, kad užtikrintumėte, jog prieiga nebus piktnaudžiaujama. Žr. išteklius, išvardytus Susijusi informacija.
Testai, imituojantys atakas per karo žaidimo pratybas
Šioje imituojamų atakų metodikoje yra dvi komandos:
- Raudonoji komanda yra priešininkas, bandantis modeliuoti realaus pasaulio atakas. Jei jie sėkmingi, rasite spragų savo saugumo projekte ir įvertinsite jų pažeidimų sprogimo spindulį.
- Mėlyna komanda yra darbo krūvio komanda, kuri ginasi nuo atakų. Jie išbando savo gebėjimą aptikti, reaguoti ir ištaisyti atakas. Jie patvirtina apsaugą, kuri buvo įdiegta siekiant apsaugoti darbo krūvio išteklius.
Jei jie atliekami kaip įprasti bandymai, karo žaidimų pratybos gali užtikrinti nuolatinį matomumą ir užtikrinimą, kad jūsų gynyba veikia taip, kaip numatyta. Karo žaidimo pratimai gali potencialiai išbandyti visus lygius pagal jūsų darbo krūvį.
Populiarus pasirinkimas imituoti tikroviškus atakų scenarijus yra "Microsoft Defender for Attack" Office 365 modeliavimo mokymai.
Daugiau informacijos rasite Atakų modeliavimo mokymo įžvalgos ir ataskaitos.
Informacijos apie raudonos ir mėlynos komandos nustatymą rasite "Microsoft Cloud Red Teaming".
Power Platform Palengvinimo
"Microsoft Sentinel" sprendimas leidžia Microsoft Power Platform klientams aptikti įvairias įtartinas veiklas, tokias kaip:
- Power Apps Vykdymas iš neleistinų geografinių vietovių
- Įtartinas duomenų sunaikinimas Power Apps
- Masinis ištrynimas Power Apps
- Sukčiavimo atakos Power Apps
- Power Automate išeinančių darbuotojų srautų veikla
- Microsoft Power Platform Jungtys, įtrauktos į aplinką
- Duomenų politikos atnaujinimas arba pašalinimas Microsoft Power Platform
Daugiau informacijos rasite Microsoft Power Platform "Microsoft Sentinel" sprendime.
Produkto dokumentaciją rasite "Microsoft Sentinel" medžioklės galimybės.
"Microsoft Defender for Cloud" siūlo įvairių technologijų sričių pažeidžiamumo nuskaitymą. Daugiau informacijos rasite Pažeidžiamumo nuskaitymo įgalinimas naudojant "Microsoft" sargybos pažeidžiamumo valdymą.
"DevSecOps" praktika integruoja saugumo testavimą kaip nuolatinio ir nuolatinio tobulinimo mąstysenos dalį. Karo žaidimų pratybos yra įprasta praktika, integruota į "Microsoft" verslo ritmą. Daugiau informacijos rasite "DevOps" sauga ("DevSecOps").
Azure DevOps palaiko trečiųjų šalių įrankius, kuriuos galima automatizuoti kaip nuolatinio integravimo / nepertraukiamo diegimo (CI/CD) vamzdynų dalį. Daugiau informacijos rasite "DevSecOps" įgalinimas naudojant "Azure" ir "GitHub".
Susijusi informacija
Naujausius įsilaužimo testus ir saugos vertinimus galima rasti „Microsoft“ paslaugų patikimumo portale.
"Microsoft" atlieka išsamų "Microsoft" debesies paslaugų testavimą. Šis testavimas apima įsiskverbimo testavimą, kurio rezultatai publikuojami jūsų organizacijos tarnybos patikimumo portale. Jūsų organizacija gali atlikti savo įsiskverbimo testą Microsoft Power Platform ir Microsoft Dynamics 365 paslaugų. Visi įsiskverbimo testai turi atitikti "Microsoft" debesies įsiskverbimo testavimo taisykles. Svarbu atsiminti, kad daugeliu atvejų "Microsoft" debesis naudoja bendrą infrastruktūrą, kad talpintų jūsų turtą ir turtą, priklausantį kitiems klientams. Turite apriboti visus įsiskverbimo testus į savo turtą ir vengti nenumatytų pasekmių kitiems aplinkiniams klientams.
Laikykitės įtraukimo taisyklių, kad įsitikintumėte, jog prieiga nėra piktnaudžiaujama. Sužinokite daugiau apie imituojamų atakų planavimą ir vykdymą:
"Azure" galite imituoti paslaugų atsisakymo (DoS) atakas. Būtinai laikykitės strategijų, išdėstytų atliekant "Azure DDoS Protection" modeliavimo testavimą.
Saugos kontrolinis sąrašas
Peržiūrėkite visą rekomendacijų rinkinį.