Javaslatok a biztonsági teszteléshez
Erre a Power Platform jól felépített biztonsági ellenőrzőlistára vonatkozó javaslatra vonatkozik:
| SE:09 | Hozzon létre egy átfogó tesztelési rendszert, amely egyesíti a biztonsági problémák megelőzésének, a fenyegetésmegelőzési megvalósítások ellenőrzésének és a fenyegetésészlelési mechanizmusok tesztelésének megközelítéseit. |
|---|
A szigorú tesztelés a jó biztonsági tervezés alapja. A tesztelés az érvényesítés taktikai formája, amely biztosítja, hogy a vezérlők rendeltetésszerűen működnek. A tesztelés proaktív módja a rendszer sebezhetőségeinek észlelésére is.
Hozza létre a tesztelési szigorúságot a lépésszám és az ellenőrzés révén több szempontból. Tartalmaznia kell a belső nézőpontokat, amelyek tesztelik a platformot és az infrastruktúrát, valamint a külső értékeléseket, amelyek külső támadóként tesztelik a rendszert.
Ez az útmutató javaslatokat tartalmaz a számítási feladatok 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ását, és fenntarthatja az erőforrások titkossá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ának (SDL) technikája, amely fehér doboz és fekete doboz 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 ellenőrzi a külsőleg látható alkalmazásviselkedést. |
| Kék csapat | Egy csapat, amely védekezik a vörös csapat támadásai ellen egy háborús játék gyakorlaton. |
| Behatolási tesztelés | Olyan tesztelési módszertan, amely etikus hackelési technikákat alkalmaz 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ék gyakorlatában. |
| Biztonsági fejlesztési életciklus (SDL) | A Microsoft által biztosított eljárások készlete, amely támogatja a biztonsági garanciális és megfelelőségi követelményeket. |
| Szoftverfejlesztési életciklus (SDLC) | Többlépcsős, szisztematikus folyamat szoftverrendszerek fejlesztésére. |
| White-box tesztelés | Olyan tesztelési módszertan, ahol a kód szerkezete ismert a szakember számára. |
Fő tervezési stratégiák
A tesztelés vitathatatlan stratégia, különösen a biztonság szempontjából. Lehetővé teszi a biztonsági problémák proaktív felderítését és megoldását, mielőtt kihasználná őket, valamint annak ellenőrzését, hogy az alkalmazott biztonsági vezérlők 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 incidensekre való reagálás között. Bár a tesztelés egy észlelési mechanizmus, amely ideális esetben az éles környezet előtt kijavítja a problémákat, nem tévesztendő össze az incidensekre adott válasz részeként végzett szervizeléssel vagy vizsgálattal. A biztonsági incidensekből való helyreállítás szempontját a Biztonsági incidensekre való reagálásra vonatkozó javaslatok ismertetik.
Vegyen részt a teszt tervezésében. Előfordulhat, hogy a számítási feladatok csapata nem tervezi meg a tesztelési eseteket. Ezt a feladatot gyakran központosítják a vállalatnál, vagy külső biztonsági szakértők végzik el. A számítási feladatok csapatát be kell vonni ebbe a tervezési folyamatba annak biztosítása érdekében, 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 potenciális sebezhetőségeket, és ennek megfelelően rangsorolhatja a teszteket.
Futtasson teszteket strukturált módon és megismételhető folyamattal. A tesztelési szigorúságot a lépésszám, a teszttípusok, a vezetési tényezők és a tervezett eredmények köré építse.
Használja a feladathoz megfelelő eszközt. Olyan eszközöket használjon, amelyek úgy vannak konfigurálva, hogy működjenek a számítási feladattal. Ha nincs szerszáma, vásárolja meg. 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 vagy külső eszközökkel kínált szakértelmet és 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 destruktív vagy roncsolásmentes kategóriába sorolhatók. A roncsolásmentes tesztek nem invazívak. Azt jelzik, hogy probléma van, de nem módosítják a funkcionalitást a probléma megoldása érdekében. A roncsolásos tesztek invazívak, és az adatok adatbázisból való törlésével károsíthatják a működést.
Az éles környezetben történő tesztelés biztosítja a legjobb információkat, de a legtöbb fennakadást okozza. Éles környezetben általában csak roncsolásmentes teszteket végez. A nem éles környezetekben való tesztelés általában kevésbé zavaró, de előfordulhat, hogy nem ábrázolja 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 vizsgálati eredményeket. A tesztelés elvesztegetett erőfeszítés, ha az eredményeket nem használják fel a műveletek rangsorolására és a fejlesztések elvégzésére. 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 meg feltörni a biztonságot. Rendszeres biztonsági képzéseket tarthat fejlesztők, rendszergazdák és tesztelők számára.
A teszttervek tervezésekor gondoljon a következő kérdésekre:
- Milyen gyakran várható a teszt futtatása, és milyen hatással van a környezetére?
- Melyek azok a különböző teszttípusok, amelyeket érdemes futtatni?
Várhatóan milyen gyakran futnak majd a tesztek?
Rendszeresen tesztelje a számítási feladatot, és győződjön meg arról, hogy a módosítások nem vezetnek biztonsági kockázatokkal, és hogy nincsenek regressziók. A csapatnak készen kell állnia arra is, hogy válaszoljon a szervezeti biztonsági ellenőrzésekre, amelyek bármikor elvégezhetők. Vannak olyan tesztek is, amelyek biztonsági incidensekre válaszul futtathatók. A következő szakaszok ajánlásokat fogalmaznak meg a vizsgálatok gyakoriságára vonatkozóan.
Rutinvizsgálatok
A rutinteszteket rendszeres ütemben végezzük el a szabványos működési eljárások részeként és a megfelelőségi követelményeknek való megfelelés érdekében. A különböző tesztek különböző ütemben futtathatók, de a legfontosabb az, hogy rendszeresen és ütemezés szerint végezzék el őket.
Ezeket a teszteket integrálnod kell az SDLC-be, mert minden szakaszban mélyreható védelmet nyújtanak. A tesztcsomag diverzifikálásával ellenőrizheti az identitás, az adattárolás és -átvitel, valamint a kommunikációs csatornák biztonságát. Végezze el ugyanazokat a teszteket az életciklus különböző pontjain, hogy ne legyenek regressziók. A rutinvizsgálatok segítenek a kezdeti referenciaérték meghatározásában. Ez azonban csak a kiindulópont. Ahogy új problémákat tár fel az életciklus ugyanazon pontjain, ú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, illetve 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ítani, szakértői értékelésekkel egyensúlyba hozva.
Érdemes lehet biztonsági teszteket futtatni 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önnyebb megtalálni az azokat okozó kódot vagy konfigurációs változást.
Ne hagyatkozzon csak automatizált tesztekre. Manuális teszteléssel észlelheti azokat a biztonsági réseket, amelyeket csak emberi szakértelem képes észlelni. A manuális tesztelés jó a feltáró használati esetekhez és az ismeretlen kockázatok megtalálásához.
Improvizált tesztek
Az improvizált tesztek a biztonsági védelem időponthoz időben való ellenőrzését biztosítják. A biztonsági riasztások, amelyek hatással lehetnek a számítási feladatra abban az időben, elindítják ezeket a teszteket. A szervezeti mandátumok szüneteltetési és tesztelési gondolkodásmódot igényelhetnek a védelmi stratégiák hatékonyságának ellenőrzéséhez, ha a riasztás vészhelyzetre eszkalálódik.
Az improvizált tesztek előnye a valós eseményre való felkészültség. Ezek a tesztek kényszeríthetik a felhasználói elfogadási tesztelést (UAT).
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 elő kell segítenie a biztonsági csapatokat, és együtt kell működnie velük. Egyeztessen elegendő átfutási időt a biztonsági csapatokkal a felkészüléshez. Ismerje el és kommunikálja csapatával és érdekelt feleivel, 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 az improvizált tesztek zavaró események, számítson arra, hogy a tevékenységek prioritása megváltozik, ami késleltetheti a többi tervezett munkát.
Kockázat: Fennáll az ismeretlen kockázata. Az improvizált tesztek egyszeri erőfeszítések lehetnek meghatározott folyamatok vagy eszközök nélkül. A legfontosabb kockázat azonban az üzleti ritmus esetleges megszakítása. Értékelnie kell ezeket a kockázatokat az előnyökhöz viszonyítva.
Biztonsági incidensek tesztelése
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 a teszteseteket is javítják a meglévő hiányosságok feltárásával. A csapatnak alkalmaznia kell az incidensből levont tanulságokat, és rutinszerűen be kell építenie a fejlesztéseket.
Melyek a tesztek különböző típusai?
A tesztek technológia és tesztelési módszerek szerint kategorizálhatók. Kombinálja ezeket a kategóriákat és megközelítéseket ezeken a kategóriákon belül a teljes lefedettség érdekében.
Több teszt és teszttípus hozzáadásával a következőket tárhatja fel:
- A védelmi ellenőrzések hiányosságai vagy kompenzáló ellenőrzések.
- Hibás konfigurációk.
- Hiányosságok a megfigyelhetőségi és kimutatási módszerekben.
Egy jó fenyegetésmodellezési gyakorlat rámutathat a kulcsfontosságú területekre a tesztelés 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ére.
Az ezekben a szakaszokban leírt legtöbb teszt rutintesztként futtatható. Az ismételhetőség azonban bizonyos esetekben költségekkel járhat, és fennakadásokat okozhat. Alaposan gondolja át ezeket a kompromisszumokat.
A technológiai vermet ellenőrző tesztek
Íme néhány példa a teszttípusokra és azok fókuszterületeire. Ez a lista nem teljes. Tesztelje a teljes vermet, beleértve az alkalmazáskészletet, az előteret, a háttérrendszert, 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 az adatok megfelelően védve legyenek a jogosulatlan hozzáféréssel és illetéktelen módosítással szemben.
- 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 gyakorlatokat, é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ódszereknek számos perspektívája van. Olyan teszteket ajánlunk, amelyek valós támadások szimulálásával engedélyezik a veszélyforrás-keresést. Azonosíthatják a potenciális fenyegetés szereplőit, technikáikat és kihasználásaikat, amelyek veszélyt jelentenek a munkaterhelésre. Tegye a támadásokat a lehető legreálisabbá. 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ásokon keresztüli tesztelésnek:
- Ha ezeket a támadásokat a rutintesztelés részévé teszi, külső perspektívát használ a munkaterhelés ellenőrzéséhez, és győződjön meg arról, hogy a védelem ellenáll-e a támadásnak.
- A levont tanulságok alapján a csapat fejleszti tudását és készségszintjét. A csapat javítja a helyzetismeretet, és önértékelésre képes, hogy készen áll-e az incidensekre való reagálásra.
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ék gyakorlatok.
Black-box és white-box tesztelés
Ezek a teszttípusok két különböző perspektívát kínálnak. A fekete doboz tesztekben a rendszer belseje nem látható. A fehér dobozos tesztek során a tesztelő jól ismeri az alkalmazást, és még kódhoz, naplókhoz, erőforrás-topológiához és konfigurációkhoz is hozzáférhet a kísérlet elvégzéséhez.
Olyan tesztek, amelyek behatolási teszteléssel szimulálják a támadásokat
Azok a biztonsági szakértők, akik nem részei a szervezet informatikai vagy alkalmazáscsapatának, behatolási tesztelést vagy tolltesztelést végeznek. Úgy nézik a rendszert, ahogyan a rosszindulatú szereplők kiterjednek a támadási felületre. 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 hozzá kell férniük a bizalmas adatokhoz az egész szervezetben. Kövesse az eljegyzési szabályokat, hogy a hozzáféréssel ne lehessen visszaélni. Tekintse meg a Lásd még.
Tesztek, amelyek támadásokat szimulálnak háborús játékgyakorlatokon keresztül
A szimulált támadások ezen módszertanában két csapat van:
- A vörös csapat az ellenfél, aki megpróbálja modellezni a valós támadásokat. Ha sikeresek, hiányosságokat talál a biztonsági tervezésben, és kiértékeli a biztonsági rések robbanási sugarának elszigetelését.
- A kék csapat az a munkaterhelési csapat, amely védelmet nyújt a támadások ellen. Tesztelik, hogy képesek-e észlelni, reagálni és orvosolni a támadásokat. Ellenőrzik a számítási feladatok erőforrásainak védelme érdekében megvalósított védelmet.
Ha rutintesztként hajtják végre őket, a háborús játék gyakorlatok folyamatos láthatóságot és biztosítékot nyújthatnak arra, hogy a védelem a tervek szerint működik. A háborús játék gyakorlatai potenciálisan tesztelhetők a munkaterhelések szintjein belül.
A valósághű támadási forgatókönyvek szimulálásának népszerű választása a Microsoft Defender for Office 365 Attack szimulációs képzés.
További információ: Elemzések és jelentések támadásszimulációs betanításhoz.
További információ a vörös és kék csapat beállításáról: Microsoft Cloud Red Teaming.
Power Platform Megkönnyítése
A Microsoft Sentinel-megoldás lehetővé teszi az Microsoft Power Platform ü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 helyekről
- Gyanús adatmegsemmisítés Power Apps
- Tömeges törlés Power Apps
- Adathalász támadások Power Apps
- Power Automate Folyamatok a távozó alkalmazottak tevékenységével
- Microsoft Power Platform Környezethez hozzáadott összekötők
- Adatveszteség-megelőzési házirendek Microsoft Power Platform frissítése vagy eltávolítása
További információ: A Microsoft Sentinel megoldás áttekintése Microsoft Power Platform .
A termékdokumentációé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 biztonsági rések vizsgálatát. További információ: Biztonsági rések vizsgálatának engedélyezése a Microsoft Defender biztonsági rések kezelésével.
A DevSecOps gyakorlata integrálja a biztonsági tesztelést a folyamatos és folyamatos fejlesztési gondolkodásmód részeként. A háborús játékok gyakorlatai gyakori gyakorlat, amely integrálva van 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ó: Enable DevSecOps with Azure and GitHub (A DevSecOps engedélyezése az Azure-ral és a GitHub).
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 Cloud szolgáltatásokon. Ez a tesztelés magában foglalja a behatolási tesztelést, amelynek eredményeit a szervezet szolgáltatásmegbízhatósági portálján teszik közzé. A szervezet saját behatolási tesztet végezhet a és Microsoft Power Platform a 365-ös szolgáltatásokon Microsoft Dynamics . Minden behatolási tesztelésnek követnie kell a Microsoft Cloud 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éhez. Az összes behatolási tesztet az eszközeire kell korlátoznia, és el kell kerülnie a nem kívánt következményeket a körülötte lévő többi ügyfél számára.
Kövesse az eljegyzési szabályokat, hogy megbizonyosodjon 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 szimulálhatja a szolgáltatásmegtagadási (DoS) támadásokat. Ügyeljen arra, hogy kövesse a szimulációs tesztelésben Azure DDoS Protection szabályzatokat.
Biztonsági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: