Poznámka
Na prístup k tejto stránke sa vyžaduje oprávnenie. Môžete sa skúsiť prihlásiť alebo zmeniť adresáre.
Na prístup k tejto stránke sa vyžaduje oprávnenie. Môžete skúsiť zmeniť adresáre.
Vzťahuje sa na toto odporúčanie kontrolného zoznamu dobre navrhnutého zabezpečenia: Power Platform
| JV:09 | Zaviesť komplexný testovací režim, ktorý kombinuje prístupy k predchádzaniu bezpečnostným problémom, overovaniu implementácií prevencie hrozieb a testovaniu mechanizmov detekcie hrozieb. |
|---|
Dôkladné testovanie je základom dobrého bezpečnostného návrhu. Testovanie je taktická forma overovania, ktorá zabezpečuje, aby kontroly fungovali podľa očakávaní. Testovanie je tiež proaktívny spôsob, ako odhaliť zraniteľnosti v systéme.
Stanovte prísnosť testovania prostredníctvom kadencie a overovania z viacerých perspektív. Mali by ste zahrnúť pohľady zvnútra von, ktoré testujú platformu a infraštruktúru, a hodnotenia zvonku dovnútra, ktoré testujú systém ako externý útočník.
Táto príručka poskytuje odporúčania na testovanie bezpečnostného stavu vašej pracovnej záťaže. Implementujte tieto testovacie metódy na zlepšenie odolnosti vašej pracovnej záťaže voči útokom a zachovanie dôvernosti, integrity a dostupnosti zdrojov.
Definície
| Pojem | Definícia |
|---|---|
| Testovanie bezpečnosti aplikácií (AST) | Technika životného cyklu vývoja zabezpečenia (SDL) od spoločnosti Microsoft, ktorá využíva metodiky testovania „white box“ a „black box“ na kontrolu bezpečnostných zraniteľností v kóde. |
| Testovanie čiernej skrinky | Testovacia metodika, ktorá overuje externe viditeľné správanie aplikácie bez znalosti vnútorných funkcií systému. |
| Modrý tím | Tím, ktorý sa bráni útokom červeného tímu vo vojnovej hre. |
| Penetračné testovanie | Testovacia metodika, ktorá využíva techniky etického hackingu na overenie bezpečnostných obranných mechanizmov systému. |
| Červený tím | Tím, ktorý hrá úlohu protivníka a pokúša sa hacknúť systém vo vojnovej hre. |
| Ž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. |
| Testovanie bielej skrinky | Metodika testovania, kde je štruktúra kódu praktikovi známa. |
Kľúčové dizajnérske stratégie
Testovanie je neoddiskutovateľná stratégia, najmä z hľadiska bezpečnosti. Umožňuje vám proaktívne odhaliť a riešiť bezpečnostné problémy skôr, ako ich možno zneužiť, a overiť, či zavedené bezpečnostné kontroly fungujú tak, ako boli navrhnuté.
Rozsah testovania musí zahŕňať aplikáciu, infraštruktúru a automatizované aj ľudské procesy.
Poznámka
Toto usmernenie rozlišuje medzi testovaním a reakciou na incidenty. Hoci testovanie je detekčný mechanizmus, ktorý ideálne rieši problémy pred ich uvedením do prevádzky, nemalo by sa zamieňať s nápravou alebo vyšetrovaním, ktoré sa vykonáva ako súčasť reakcie na incident. Aspekt obnovy po bezpečnostných incidentoch je opísaný v dokumente Odporúčania pre reakciu na bezpečnostné incidenty.
Zapojte sa do plánovania testov. Tím pre pracovné zaťaženie nemusí navrhnúť testovacie prípady. Táto úloha je často centralizovaná v podniku alebo ju vykonávajú externí bezpečnostní experti. Tím pre pracovné zaťaženie by mal byť zapojený do procesu návrhu, aby sa zabezpečila integrácia bezpečnostných záruk s funkcionalitou aplikácie.
Mysli ako útočník. Navrhnite testovacie prípady s predpokladom, že systém bol napadnutý. Takto môžete odhaliť potenciálne zraniteľnosti a podľa toho uprednostniť testy.
Vykonávajte testy štruktúrovaným spôsobom a s opakovateľným procesom. Prispôsobte si prísnosť testovania frekvencii, typom testov, hnacím faktorom a zamýšľaným výsledkom.
Použite správny nástroj na danú prácu. Používajte nástroje, ktoré sú nakonfigurované na prácu s danou pracovnou záťažou. Ak nemáte nástroj, kúpte si ho. Nestavajte to. Bezpečnostné nástroje sú vysoko špecializované a vytvorenie vlastného nástroja môže predstavovať riziká. Využite odborné znalosti a nástroje, ktoré ponúkajú centrálne tímy SecOps alebo externé prostriedky, ak tím pre pracovné záťaže tieto odborné znalosti nemá.
Nastavte si samostatné prostredia. Testy možno klasifikovať ako deštruktívne alebo nedeštruktívne. Nedeštruktívne testy nie sú invazívne. Naznačujú, že existuje problém, ale nemenia funkčnosť, aby problém odstránili. Deštruktívne testy sú invazívne a môžu poškodiť funkčnosť vymazaním údajov z databázy.
Testovanie v produkčnom prostredí vám poskytuje najlepšie informácie, ale spôsobuje najväčšie narušenie. V produkčnom prostredí zvyčajne vykonávate iba nedeštruktívne testy. Testovanie v neprodukčnom prostredí je zvyčajne menej rušivé, ale nemusí presne reprezentovať konfiguráciu produkčného prostredia spôsobmi, ktoré sú dôležité z hľadiska bezpečnosti.
Izolovaný klon produkčného prostredia môžete vytvoriť pomocou funkcie kopírovania prostredia . Ak máte nastavené kanály nasadenia, môžete svoje riešenia nasadiť aj do vyhradeného testovacieho prostredia.
Vždy vyhodnoťte výsledky testov. Testovanie je zbytočné úsilie, ak sa výsledky nepoužijú na stanovenie priorít akcií a vykonanie vylepšení v predchádzajúcich fázach. Zdokumentujte bezpečnostné pokyny vrátane osvedčených postupov, ktoré odhalíte. Dokumentácia, ktorá zachytáva výsledky a plány nápravy, vzdeláva tím o rôznych spôsoboch, akými sa útočníci môžu pokúsiť narušiť bezpečnosť. Pravidelne vykonávajte bezpečnostné školenia pre vývojárov, administrátorov a testerov.
Pri navrhovaní testovacích plánov premýšľajte o nasledujúcich otázkach:
- Ako často očakávate, že sa test bude spúšťať a ako ovplyvní vaše prostredie?
- Aké rôzne typy testov by ste mali spustiť?
Ako často očakávate, že sa testy budú vykonávať?
Pravidelne testujte pracovnú záťaž, aby ste sa uistili, že zmeny nepredstavujú bezpečnostné riziká a že nedochádza k žiadnym regresiám. Tím musí byť tiež pripravený reagovať na overenia bezpečnosti organizácie, ktoré sa môžu vykonať kedykoľvek. Existujú aj testy, ktoré môžete spustiť v reakcii na bezpečnostný incident. Nasledujúce časti obsahujú odporúčania týkajúce sa frekvencie testov.
Rutinných testov
Rutinná kontrola sa vykonáva v pravidelnej frekvencii ako súčasť štandardných prevádzkových postupov a na splnenie požiadaviek na zhodu. Rôzne testy sa môžu vykonávať s rôznou kadenciou, ale kľúčové je, aby sa vykonávali pravidelne a podľa plánu.
Tieto testy by ste mali integrovať do svojho SDLC, pretože poskytujú hĺbkovú ochranu v každej fáze. Diverzifikujte testovaciu sadu s cieľom overiť záruky identity, ukladania a prenosu údajov a komunikačných kanálov. Vykonajte rovnaké testy v rôznych bodoch životného cyklu, aby ste sa uistili, že nedochádza k žiadnym regresiám. Rutinnými testami sa dá stanoviť počiatočný referenčný bod. To je však len východiskový bod. Keď odhalíte nové problémy v rovnakých bodoch životného cyklu, pridáte nové testovacie prípady. Testy sa tiež zlepšujú opakovaním.
V každej fáze by tieto testy mali overiť pridaný alebo odstránený kód alebo zmenené konfiguračné nastavenia, aby sa zistil vplyv týchto zmien na bezpečnosť. Účinnosť testov by ste mali zlepšiť automatizáciou, vyváženou partnerskými recenziami.
Zvážte spustenie bezpečnostných testov ako súčasť automatizovaného kanála alebo plánovaného testovania. Čím skôr odhalíte bezpečnostné problémy, tým ľahšie nájdete kód alebo zmenu konfigurácie, ktorá ich spôsobuje.
Nespoliehajte sa len na automatizované testy. Na zistenie zraniteľností, ktoré dokáže odhaliť iba ľudská expertíza, použite manuálne testovanie. Manuálne testovanie je vhodné na prieskumné prípady použitia a hľadanie neznámych rizík.
Improvizované testy
Improvizované testy poskytujú overenie bezpečnostných obranných mechanizmov v danom čase. Tieto testy spúšťajú bezpečnostné upozornenia, ktoré by mohli v danom čase ovplyvniť pracovnú záťaž. Organizačné mandáty môžu vyžadovať zaujatý prístup „pauza a testovanie“, aby sa overila účinnosť obranných stratégií, ak sa výstraha vystupňova do núdzového stavu.
Výhodou improvizovaných testov je pripravenosť na skutočný incident. Tieto testy môžu byť vynútenou funkciou na vykonanie testovania akceptácie používateľmi (UAT).
Bezpečnostný tím môže auditovať všetky pracovné zaťaženia a podľa potreby spúšťať tieto testy. Ako vlastník pracovnej záťaže musíte uľahčovať a spolupracovať s bezpečnostnými tímami. Vyrokujte si s bezpečnostnými tímami dostatočný čas na prípravu. Uznajte a oznámte svojmu tímu a zainteresovaným stranám, že tieto narušenia sú nevyhnutné.
V iných prípadoch môže byť potrebné spustiť testy a nahlásiť stav zabezpečenia systému voči potenciálnej hrozbe.
Kompromis Keďže improvizované testy sú rušivé udalosti, očakávajte, že sa zmenia priority úloh, čo môže oddialiť inú plánovanú prácu.
Riziko: Existuje riziko neznámeho. Improvizované testy môžu byť jednorazové úsilie bez zavedených procesov alebo nástrojov. Hlavným rizikom je však potenciálne narušenie rytmu podnikania. Musíte zhodnotiť tieto riziká vo vzťahu k výhodám.
Testy bezpečnostných incidentov
Existujú testy, ktoré odhaľujú príčinu bezpečnostného incidentu pri jeho vzniku. Tieto bezpečnostné medzery musia byť vyriešené, aby sa zabezpečilo, že sa incident neopakuje.
Incidenty tiež časom zlepšujú testovacie prípady odhalením existujúcich medzier. Tím by mal aplikovať poznatky získané z incidentu a pravidelne zavádzať vylepšenia.
Aké sú rôzne typy testov?
Testy možno kategorizovať podľa technológie a metodológie testovania. Skombinujte tieto kategórie a prístupy v rámci týchto kategórií, aby ste získali úplné pokrytie.
Pridaním viacerých testov a typov testov môžete odhaliť:
- Medzery v bezpečnostných kontrolách alebo kompenzačných kontrolách.
- Nesprávne konfigurácie.
- Medzery v pozorovateľnosti a metódach detekcie.
Dobré modelovanie hrozieb môže poukázať na kľúčové oblasti na zabezpečenie pokrytia a frekvencie testov. Odporúčania týkajúce sa modelovania hrozieb nájdete v časti Odporúčania na zabezpečenie životného cyklu vývoja .
Väčšinu testov opísaných v týchto častiach je možné vykonať ako rutinné testy. Opakovateľnosť však môže v niektorých prípadoch viesť k nákladom a spôsobiť narušenie. Tieto kompromisy starostlivo zvážte.
Testy, ktoré overujú technologický stack
Tu je niekoľko príkladov typov testov a oblastí ich zamerania. Tento zoznam nie je vyčerpávajúci. Otestujte celý stack vrátane aplikačného stacku, front-endu, back-endu, API, databáz a akýchkoľvek externých integrácií.
- Zabezpečenie údajov: Otestujte účinnosť šifrovania údajov a kontroly prístupu, aby ste zabezpečili, že údaje sú riadne chránené pred neoprávneným prístupom a manipuláciou.
- Sieť a pripojenie: Otestujte svoje brány firewall, aby ste sa uistili, že povoľujú iba očakávanú, povolenú a bezpečnú prevádzku pre pracovnú záťaž.
- Aplikácia: Otestujte zdrojový kód pomocou techník testovania bezpečnosti aplikácií (AST), aby ste sa uistili, že dodržiavate postupy bezpečného kódovania a aby ste odhalili chyby za behu, ako je poškodenie pamäte a problémy s oprávneniami.
- Identita: Vyhodnoťte, či priradenia rolí a podmienené kontroly fungujú podľa očakávania.
Metodika testovania
Existuje mnoho pohľadov na metodiky testovania. Odporúčame testy, ktoré umožňujú vyhľadávanie hrozieb simuláciou útokov v reálnom svete. Môžu identifikovať potenciálnych aktérov ohrozenia, ich techniky a ich zneužitia, ktoré predstavujú hrozbu pre pracovnú záťaž. Urobte útoky čo najrealistickejšie. Použite všetky potenciálne vektory hrozieb, ktoré identifikujete počas modelovania hrozieb.
Tu sú niektoré výhody testovania prostredníctvom útokov z reálneho sveta:
- Keď tieto útoky zaradíte do bežného testovania, použijete pohľad zvonku dovnútra na kontrolu pracovnej záťaže a uistenie sa, že obrana dokáže útoku odolať.
- Na základe získaných skúseností si tím zvyšuje úroveň svojich vedomostí a zručností. Tím si zlepšuje situačné povedomie a dokáže sám posúdiť svoju pripravenosť reagovať na incidenty.
Medzi príklady simulovaných testov patrí testovanie čiernej a bielej skrinky, penetračné testovanie a cvičenia vojnových hier.
Testovanie čiernej a bielej skrinky
Tieto typy testov ponúkajú dva rôzne pohľady. V testoch čiernej skrinky nie sú vnútorné časti systému viditeľné. V testoch bielej skrinky má tester dobré znalosti o aplikácii a dokonca má prístup ku kódu, protokolom, topológii zdrojov a konfiguráciám na vykonanie experimentu.
Testy simulujúce útoky prostredníctvom penetračného testovania
Bezpečnostní experti, ktorí nie sú súčasťou IT alebo aplikačných tímov organizácie, vykonávajú penetračné testovanie alebo pentesting. Pozerajú sa na systém spôsobom, akým škodliví aktéri skúmajú oblasť útoku. Ich cieľom je nájsť bezpečnostné medzery zhromažďovaním informácií, analýzou zraniteľností a podávaním správ o výsledkoch.
Odborníci môžu potrebovať prístup k citlivým údajom v celej organizácii. Dodržiavajte pravidlá zapojenia, aby ste zabezpečili, že prístup nebude zneužitý. Pozrite si zdroje uvedené v Súvisiace informácie.
Testy simulujúce útoky prostredníctvom cvičení vo vojnových hrách
V tejto metodike simulovaných útokov existujú dva tímy:
- Ten/Tá/To červená Tím je protivník, ktorý sa snaží modelovať útoky z reálneho sveta. Ak budú úspešní, nájdete medzery vo vašom bezpečnostnom návrhu a vyhodnotíte rozsah výbuchu, v akom sa dajú obmedziť ich narušenia.
- Ten/Tá/To modrá tím je tím zodpovedný za pracovnú záťaž, ktorý sa bráni útokom. Testujú svoju schopnosť odhaliť, reagovať a napraviť útoky. Overujú ochranné opatrenia, ktoré boli implementované na ochranu zdrojov pracovnej záťaže.
Ak sa vykonávajú ako rutinné testy, cvičenia vojnových hier môžu poskytnúť priebežný prehľad a istotu, že vaša obrana funguje tak, ako bola navrhnutá. Cvičenia s vojnovými hrami môžu potenciálne otestovať rôzne úrovne v rámci vašej pracovnej záťaže.
Obľúbenou voľbou na simuláciu realistických scenárov útokov je Microsoft Defender. Office 365 Tréning simulácie útoku.
Viac informácií nájdete v časti *Prehľady a správy pre tréning simulácie útoku* .
Informácie o nastavení červeného a modrého tímu nájdete v článku Microsoft Cloud Red Teaming .
Power Platform uľahčenie
Riešenie Microsoft Sentinel pre Microsoft Power Platform umožňuje zákazníkom odhaliť rôzne podozrivé aktivity, ako napríklad:
- Power Apps poprava z neoprávnených geografických oblastí
- Podozrivé zničenie údajov zo strany Power Apps
- Hromadné vymazanie Power Apps
- Phishingové útoky uskutočnené prostredníctvom Power Apps
- Power Automate aktivita tokov odchádzajúcich zamestnancov
- Microsoft Power Platform konektory pridané do prostredia
- Aktualizácia alebo odstránenie zásad prevencie úniku údajov Microsoft Power Platform
Viac informácií nájdete v článku Prehľad riešenia Microsoft Sentinel Microsoft Power Platform .
Dokumentáciu k produktu nájdete v časti Možnosti vyhľadávania v programe Microsoft Sentinel .
Microsoft Defender for Cloud ponúka skenovanie zraniteľností pre rôzne technologické oblasti. Ďalšie informácie nájdete v článku Povolenie skenovania zraniteľností pomocou služby Microsoft Defender Vulnerability Management.
Prax DevSecOps integruje bezpečnostné testovanie ako súčasť neustáleho a neustáleho zlepšovania. Vojnové hry sú bežnou praxou, ktorá je v spoločnosti Microsoft integrovaná do rytmu podnikania. Viac informácií nájdete v časti Bezpečnosť v DevOps (DevSecOps).
Azure DevOps podporuje nástroje tretích strán, ktoré je možné automatizovať ako súčasť kanálov kontinuálnej integrácie/kontinuálneho nasadzovania (CI/CD). Viac informácií nájdete v článku Povolenie DevSecOps pomocou Azure a GitHub.
Súvisiace informácie
Najnovšie penetračné testy a hodnotenia bezpečnosti nájdete na portáli Microsoft Service Trust.
Spoločnosť Microsoft vykonáva rozsiahle testovanie cloudových služieb Microsoft. Toto testovanie zahŕňa penetračné testovanie, ktorého výsledky sú zverejnené na portáli dôveryhodnosti služieb pre vašu organizáciu. Vaša organizácia môže vykonať vlastný penetračný test na službách **a **365**. Microsoft Power Platform Microsoft Dynamics Všetky penetračné testy musia byť v súlade s pravidlami pre penetračné testovanie spoločnosti Microsoft Cloud. Je dôležité mať na pamäti, že v mnohých prípadoch služba Microsoft Cloud využíva zdieľanú infraštruktúru na hosťovanie vašich aktív a aktív patriacich iným zákazníkom. Všetky penetračné testy musíte obmedziť na svoje aktíva a vyhnúť sa nezamýšľaným následkom pre ostatných zákazníkov vo vašom okolí.
Dodržiavajte pravidlá zapojenia, aby ste zabezpečili, že prístup nebude zneužitý. Pokyny k plánovaniu a vykonávaniu simulovaných útokov nájdete tu:
V Azure môžete simulovať útoky typu odmietnutie služby (DoS). Dodržiavajte zásady uvedené v časti Simulačné testovanie ochrany Azure DDoS.
Kontrolný zoznam zabezpečenia
Pozrite si kompletný súbor odporúčaní.