Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A jól felépített biztonsági ellenőrzőlista erre a javaslatára vonatkozik Power Platform :
| SE:09 | Hozzon létre egy átfogó tesztelési rendszert, amely egyesíti a biztonsági problémák megelőzésére, a fenyegetésmegelőzési implementációk ellenőrzésére és a fenyegetésészlelési mechanizmusok tesztelésére szolgáló megközelítéseket. |
|---|
A szigorú tesztelés a jó biztonsági tervezés alapja. A tesztelés az érvényesítés taktikai formája, amely megbizonyosodik arról, hogy a vezérlők rendeltetésszerűen működnek. A tesztelés a rendszer sebezhetőségeinek észlelésének proaktív módja is.
Állítsa be a tesztelés szigorúságát a ritmus és az ellenőrzés révén több szempontból. A platformot és az infrastruktúrát tesztelő belső nézőpontokat és a külső értékeléseket is tartalmaznia kell, amelyek külső támadóként tesztelik a rendszert.
Ez az útmutató javaslatokat tartalmaz a számítási feladat biztonsági helyzetének teszteléséhez. Ezekkel a tesztelési módszerekkel javíthatja a számítási feladatok támadásokkal szembeni ellenálló képességét, és fenntarthatja az erőforrások bizalmasságát, integritását és rendelkezésre állását.
Meghatározások
| Kifejezés | Definíció |
|---|---|
| Alkalmazásbiztonsági tesztelés (AST) | A Microsoft biztonsági fejlesztési életciklus (SDL) technikája, amely fehér dobozos és fekete dobozos tesztelési módszereket használ a kód biztonsági réseinek ellenőrzésére. |
| Fekete doboz tesztelés | Olyan tesztelési módszertan, amely a rendszer belső elemeinek ismerete nélkül validálja a külsőleg látható alkalmazás viselkedését. |
| Kék csapat | Egy csapat, amely védekezik a vörös csapat támadásai ellen egy háborús játékgyakorlaton. |
| Behatolási vizsgálat | Olyan tesztelési módszertan, amely etikus hackelési technikákat használ a rendszer biztonsági védelmének érvényesítésére. |
| Piros csapat | Egy csapat, amely az ellenfél szerepét játssza, és megpróbálja feltörni a rendszert egy háborús játékgyakorlat során. |
| Biztonsági fejlesztési életciklus (SDL) | A Microsoft által biztosított eljárások, amelyek támogatják a biztonsági garanciát és a megfelelőségi követelményeket. |
| Szoftverfejlesztési életciklus (SDLC) | Többlépcsős, szisztematikus folyamat a szoftverrendszerek fejlesztésére. |
| White-box tesztelés | Olyan tesztelési módszertan, ahol a kód szerkezete ismert a gyakorló számára. |
Kulcsfontosságú tervezési stratégiák
A tesztelés nem tárgyalható stratégia, különösen a biztonság érdekében. Lehetővé teszi a biztonsági problémák proaktív felderítését és kezelését, mielőtt kihasználná őket, és ellenőrizheti, hogy a megvalósított biztonsági vezérlők a terveknek megfelelően működnek-e.
A tesztelés hatókörének ki kell terjednie az alkalmazásra, az infrastruktúrára, valamint az automatizált és emberi folyamatokra.
Feljegyzés
Ez az útmutató különbséget tesz a tesztelés és az incidensválasz között. Bár a tesztelés egy olyan észlelési mechanizmus, amely ideális esetben kijavítja a problémákat az éles környezet előtt, nem szabad összetéveszteni az incidensválasz részeként végzett szervizeléssel vagy vizsgálattal. A biztonsági incidensek utáni helyreállítás szempontját a biztonsági incidensek kezelésére vonatkozó javaslatok ismerteti.
Vegyen részt a teszttervezésben. Előfordulhat, hogy a számítási feladatok csapata nem tervezi meg a teszteseteket. Ezt a feladatot gyakran központosítják a vállalaton belül, vagy külső biztonsági szakértők végzik el. A számítási feladatok csapatát be kell vonni a tervezési folyamatba, hogy a biztonsági garanciák integrálódjanak az alkalmazás funkcióival.
Gondolkodj úgy, mint egy támadó. Tervezze meg teszteseteit azzal a feltételezéssel, hogy a rendszert megtámadták. Így feltárhatja a lehetséges sebezhetőségeket, és ennek megfelelően rangsorolhatja a teszteket.
Futtassa a teszteket strukturált módon és megismételhető folyamattal. A tesztelés szigorúságát a ritmus, a tesztek típusai, a hajtóerő tényezők és a tervezett eredmények köré építheti.
Használja a munkához megfelelő szerszámot. Használjon olyan eszközöket, amelyek a számítási feladattal való együttműködésre vannak konfigurálva. Ha nincs szerszáma, vásárolja meg az eszközt. Ne építsd meg. A biztonsági eszközök rendkívül specializáltak, és a saját eszköz létrehozása kockázatokkal járhat. Használja ki a központi SecOps-csapatok által kínált szakértelmet és eszközöket, vagy külső eszközöket, ha a számítási feladatok csapata nem rendelkezik ezzel a szakértelemmel.
Állítson be külön környezeteket. A tesztek roncsolásos vagy roncsolásmentes kategóriába sorolhatók. A roncsolásmentes tesztek nem invazívak. Jelzik, hogy probléma van, de nem módosítják a funkciókat a probléma megoldása érdekében. A roncsolásos tesztek invazívak, és károsíthatják a működést, ha adatokat törölnek az adatbázisból.
Az éles környezetben történő tesztelés a legjobb információkat nyújtja, de a legtöbb fennakadást okozza. Általában csak roncsolásmentes teszteket végez éles környezetben. A nem éles környezetben végzett tesztelés általában kevésbé zavaró, de előfordulhat, hogy nem tükrözi pontosan az éles környezet konfigurációját a biztonság szempontjából fontos módon.
Az éles környezet elkülönített klónját a környezet másolási funkciójával hozhatja létre. Ha üzembe helyezési folyamatok vannak beállítva, a megoldásokat egy dedikált tesztelési környezetben is üzembe helyezheti.
Mindig értékelje a teszt eredményeit. A tesztelés elpazarolt erőfeszítés, ha az eredményeket nem használják fel a műveletek rangsorolására és a fejlesztésekre. Dokumentálja a feltárt biztonsági irányelveket, beleértve az ajánlott eljárásokat is. Az eredményeket és a szervizelési terveket rögzítő dokumentáció tájékoztatja a csapatot arról, hogy a támadók milyen különböző módokon próbálhatják megsérteni a biztonságot. Rendszeres biztonsági képzést végezhet fejlesztőknek, rendszergazdáknak és tesztelőknek.
A teszttervek megtervezésekor gondolja át a következő kérdéseket:
- Várhatóan milyen gyakran fut a teszt, és hogyan befolyásolja a környezetét?
- Milyen különböző teszttípusokat kell futtatnia?
Várhatóan milyen gyakran futnak a tesztek?
Rendszeresen tesztelje a számítási feladatot, hogy megbizonyosodjon arról, hogy a módosítások nem vezetnek biztonsági kockázatokhoz, és hogy nincsenek-e regressziók. A csapatnak készen kell állnia arra is, hogy válaszoljon a bármikor végrehajtható szervezeti biztonsági ellenőrzésekre. Vannak olyan tesztek is, amelyeket biztonsági incidensekre válaszul futtathat. A következő szakaszok ajánlásokat tartalmaznak a vizsgálatok gyakoriságára vonatkozóan.
Rutin tesztek
A rutinteszteket rendszeres ütemben végzik el a szabványos működési eljárások részeként és a megfelelőségi követelmények teljesítése érdekében. A különböző teszteket különböző ütemben lehet futtatni, de a kulcs az, hogy rendszeresen és ütemezetten végezzék őket.
Ezeket a teszteket integrálnia kell az SDLC-be, mert minden szakaszban mélységi védelmet nyújtanak. Diverzifikálja a tesztcsomagot az identitás, az adattárolás és -átvitel, valamint a kommunikációs csatornák biztosítékainak ellenőrzéséhez. Végezze el ugyanazokat a teszteket az életciklus különböző pontjain, hogy ne legyenek regressziók. A rutintesztek segítenek a kezdeti viszonyítási alap kialakításában. Ez azonban csak egy kiindulópont. Ahogy az életciklus ugyanazon pontjain új problémákat fedez fel, új teszteseteket ad hozzá. A tesztek ismétléssel is javulnak.
Ezeknek a teszteknek minden szakaszban ellenőrizniük kell a hozzáadott vagy eltávolított kódot vagy a módosított konfigurációs beállításokat a módosítások biztonsági hatásának észlelése érdekében. A tesztek hatékonyságát automatizálással kell javítania, amelyet szakértői értékelésekkel kell egyensúlyozni.
Fontolja meg a biztonsági tesztek futtatását egy automatizált folyamat vagy ütemezett tesztfuttatás részeként. Minél hamarabb fedezi fel a biztonsági problémákat, annál könnyebben megtalálhatja az azokat okozó kódot vagy konfigurációs módosítást.
Ne csak automatizált tesztekre hagyatkozzon. Manuális teszteléssel észlelheti azokat a biztonsági réseket, amelyeket csak az emberi szakértelem tud észlelni. A manuális tesztelés jó a feltáró felhasználási esetekhez és az ismeretlen kockázatok felderítéséhez.
Rögtönzött tesztek
A rögtönzött tesztek a biztonsági védelem időponthoz kötött érvényesítését biztosítják. Biztonsági riasztások, amelyek hatással lehetnek a számítási feladatra, elindítják ezeket a teszteket. A szervezeti megbízások szüneteltetést és tesztelést igényelhetnek a védelmi stratégiák hatékonyságának ellenőrzéséhez, ha a riasztás vészhelyzetté eszkalálódik.
A rögtönzött tesztek előnye a valós eseményre való felkészültség. Ezek a tesztek kényszerítő funkciókat jelenthetnek a felhasználói elfogadási tesztelés (UAT) elvégzéséhez.
A biztonsági csapat naplózhatja az összes számítási feladatot, és szükség szerint futtathatja ezeket a teszteket. Számítási feladatok tulajdonosaként meg kell könnyítenie a biztonsági csapatokat, és együtt kell működnie velük. Egyeztessen elegendő átfutási időt a biztonsági csapatokkal, hogy felkészülhessen. Ismerje el és kommunikálja csapatával és az érdekelt felekkel, hogy ezekre a fennakadásokra szükség van.
Más esetekben előfordulhat, hogy teszteket kell futtatnia, és jelentenie kell a rendszer biztonsági állapotát a potenciális fenyegetéssel szemben.
Kompromisszum: Mivel a rögtönzött tesztek zavaró események, számítson a feladatok újrarangsorolására, ami késleltetheti a többi tervezett munkát.
Kockázat: Fennáll az ismeretlen kockázata. A rögtönzött tesztek egyszeri erőfeszítések lehetnek kialakult folyamatok vagy eszközök nélkül. De a domináns kockázat az üzleti ritmus esetleges megszakítása. Ezeket a kockázatokat az előnyökhöz viszonyítva kell értékelnie.
Biztonsági incidenstesztek
Vannak olyan tesztek, amelyek a biztonsági incidens okát a forrásánál észlelik. Ezeket a biztonsági réseket meg kell oldani, hogy az incidens ne ismétlődjön meg.
Az incidensek idővel javítják a teszteseteket is azáltal, hogy feltárják a meglévő hiányosságokat. A csapatnak alkalmaznia kell az incidensből levont tanulságokat, és rutinszerűen be kell építenie a fejlesztéseket.
Melyek a különböző típusú tesztek?
A tesztek technológia és tesztelési módszertanok szerint kategorizálhatók. Kombinálja ezeket a kategóriákat és megközelítéseket ezeken a kategóriákon belül, hogy teljes lefedettséget kapjon.
Több teszt és teszttípus hozzáadásával a következőket fedezheti fel:
- Hiányosságok a biztonsági ellenőrzésekben vagy a kompenzációs vezérlőkben.
- Hibás konfigurációk.
- Hiányosságok a megfigyelhetőségben és az észlelési módszerekben.
Egy jó fenyegetésmodellezési gyakorlat rámutathat a kulcsfontosságú területekre a teszt lefedettségének és gyakoriságának biztosítása érdekében. A fenyegetésmodellezéssel kapcsolatos javaslatokért lásd: Javaslatok a fejlesztési életciklus biztonságossá tételéhez.
Az ezekben a szakaszokban ismertetett legtöbb teszt rutintesztként futtatható. A megismételhetőség azonban bizonyos esetekben költségekkel járhat, és fennakadásokat okozhat. Alaposan fontolja meg ezeket a kompromisszumokat.
A technológiai vermet érvényesítő tesztek
Íme néhány példa a tesztek típusaira és azok fókuszterületeire. Ez a lista nem teljes. Tesztelje a teljes vermet, beleértve az alkalmazásvermet, az előtér-, a háttér-, az API-kat, az adatbázisokat és a külső integrációkat.
- Adatbiztonság: Tesztelje az adattitkosítás és a hozzáférés-vezérlés hatékonyságát, hogy biztosítsa az adatok megfelelő védelmét a jogosulatlan hozzáféréstől és illetéktelen módosítástól.
- Hálózat és kapcsolat: Tesztelje a tűzfalakat, és győződjön meg arról, hogy csak a várt, engedélyezett és biztonságos forgalmat engedélyezik a számítási feladathoz.
- Alkalmazás: Tesztelje a forráskódot alkalmazásbiztonsági tesztelési (AST) technikákkal, hogy megbizonyosodjon arról, hogy követi a biztonságos kódolási eljárásokat, és észleli a futásidejű hibákat, például a memóriasérülést és a jogosultsági problémákat.
- Identitás: Értékelje ki, hogy a szerepkör-hozzárendelések és a feltételes ellenőrzések megfelelően működnek-e.
Vizsgálati módszertan
A tesztelési módszertanoknak számos perspektívája van. Olyan teszteket ajánlunk, amelyek valós támadások szimulálásával engedélyezik a fenyegetésvadászatot. Azonosíthatják a potenciális fenyegetés szereplőit, technikáikat és kihasználásaikat, amelyek veszélyt jelentenek a számítási feladatra. Tegye a támadásokat a lehető legvalósághűbbé. Használja a fenyegetésmodellezés során azonosított összes lehetséges fenyegetésvektort.
Íme néhány előnye a valós támadásokkal történő tesztelésnek:
- Amikor ezeket a támadásokat a rutintesztelés részévé teszi, kívülről befelé néző perspektívával ellenőrzi a munkaterhelést, és megbizonyosodik arról, hogy a védelem ellenáll a támadásnak.
- A tanulságok alapján a csapat fejleszti tudás- és készségszintjét. A csapat javítja a helyzetfelismerést, és önállóan értékelheti az incidensekre való reagálásra való felkészültségét.
Néhány példa a szimulált tesztekre: fekete doboz és fehér doboz tesztelés, behatolási tesztelés és háborús játékgyakorlatok.
Fekete doboz és fehér doboz tesztelés
Ezek a teszttípusok két különböző perspektívát kínálnak. A fekete dobozos tesztekben a rendszer belseje nem látható. A fehér dobozos tesztekben a tesztelő jól ismeri az alkalmazást, és még a kísérlet elvégzéséhez szükséges kódhoz, naplókhoz, erőforrás-topológiához és konfigurációkhoz is hozzáfér.
Támadásokat szimuláló tesztek behatolási teszteléssel
Azok a biztonsági szakértők, akik nem tagjai a szervezet informatikai vagy alkalmazási csapatainak, behatolási tesztelést vagy pentestinget végeznek. Úgy nézik a rendszert, hogy a rosszindulatú szereplők egy támadási felületet érintenek. Céljuk a biztonsági rések megtalálása információgyűjtéssel, sebezhetőségek elemzésével és az eredmények jelentésével.
Előfordulhat, hogy a szakembereknek a teljes szervezet bizalmas adataihoz kell hozzáférniük. Kövesse az aktivitási szabályokat, hogy a hozzáféréssel ne éljenek vissza. Tekintse meg a Kapcsolódó információk című témakörbenfelsorolt forrásokat.
Tesztek, amelyek háborús játékgyakorlatokon keresztül szimulálják a támadásokat
A szimulált támadások ezen módszertanában két csapat van:
- A vörös csapat az ellenfél, aki valós támadásokat próbál modellezni. Ha sikerrel járnak, hiányosságokat talál a biztonsági kialakításban, és kiértékeli a biztonsági incidensek robbanási sugarát.
- A kék csapat az a munkaterhelési csapat, amely védekezik a támadások ellen. Tesztelik a támadások észlelésének, reagálásának és szervizelésének képességét. Ellenőrzik a számítási feladatok erőforrásainak védelme érdekében megvalósított védelmet.
Ha rutintesztként végzik őket, a háborús játékgyakorlatok folyamatos láthatóságot és biztosítékot nyújthatnak arra, hogy a védelem a terveknek megfelelően működik. A háborús játékgyakorlatok potenciálisan tesztelhetik a számítási feladatok különböző szintjeit.
A valósághű támadási forgatókönyvek szimulálására népszerű választás a Microsoft Defender for Office 365 Attack szimulációs betanítás.
További információ: Elemzések és jelentések a támadásszimulációs betanításhoz.
További információ a vörös csapat és a kék csapat beállításáról: Microsoft Cloud Red Teaming.
Power Platform Megkönnyítése
A Microsoft Sentinel megoldása Microsoft Power Platform lehetővé teszi az ügyfelek számára a különböző gyanús tevékenységek észlelését, például:
- Power Apps Végrehajtás jogosulatlan földrajzi területekről
- Gyanús adatmegsemmisítés Power Apps
- Tömeges törlés Power Apps
- Adathalász támadások Power Apps
- Power Automate Áramlási tevékenység távozó alkalmazottak szerint
- Microsoft Power Platform Környezethez hozzáadott összekötők
- Adatveszteség-megelőzési szabályzatok frissítése vagy eltávolítása Microsoft Power Platform
További információ: Microsoft Sentinel-megoldás Microsoft Power Platform áttekintés.
A termék dokumentációjáért lásd: Keresési képességek a Microsoft Sentinelben.
A Microsoft Defender for Cloud különböző technológiai területeken kínál sebezhetőség-vizsgálatot. További információ: Biztonsági rések vizsgálatának engedélyezése a Microsoft Defender biztonságirés-kezeléssel.
A DevSecOps gyakorlata a biztonsági tesztelést a folyamatos és folyamatos fejlesztési gondolkodásmód részeként integrálja. A háborús játékgyakorlatok bevett gyakorlat, amely beépül a Microsoft üzleti ritmusába. További információ: Biztonság a DevOpsban (DevSecOps).
Azure DevOps támogatja a folyamatos integrációs/folyamatos üzembe helyezési (CI/CD) folyamatok részeként automatizálható külső eszközöket. További információ: DevSecOps engedélyezése az Azure-ban és a GitHubon.
Kapcsolódó információk
A legújabb behatolási tesztek és biztonsági értékelések a Microsoft Service Trust portálján találhatók.
A Microsoft kiterjedt tesztelést végez a Microsoft felhőszolgáltatásain. Ez a tesztelés magában foglalja a behatolási tesztelést, amelynek eredményeit a szervezet Service Trust portálján teszik közzé. Szervezete saját behatolási tesztet végezhet a 365 Microsoft Power Platform szolgáltatásokon Microsoft Dynamics . Minden behatolási tesztelésnek követnie kell a Microsoft felhőalapú behatolási tesztelési szabályait. Fontos megjegyezni, hogy a Microsoft Cloud sok esetben megosztott infrastruktúrát használ a más ügyfelekhez tartozó eszközök és eszközök üzemeltetésére. Minden behatolási tesztet az eszközeire kell korlátoznia, és el kell kerülnie a körülötte lévő többi ügyfélre gyakorolt nem kívánt következményeket.
Kövesse az aktivitási szabályokat, és győződjön meg arról, hogy a hozzáféréssel nem élnek vissza. A szimulált támadások tervezésével és végrehajtásával kapcsolatos útmutatásért lásd:
Az Azure-ban szolgáltatásmegtagadási (DoS) támadásokat szimulálhat. Ügyeljen arra, hogy kövesse az Azure DDoS Protection szimulációs tesztelésében lefektetettszabályzatokat.
Biztonsági ellenőrzőlista
Tekintse meg a teljes javaslatot.