Biztonsági tesztelési javaslatok
Az Azure Well-Architected Framework biztonsági ellenőrzőlistájára vonatkozó javaslatra vonatkozik:
| SE:11 | Hozzon létre egy átfogó tesztelési rendszert, amely 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 kombinálja. |
|---|
A szigorú tesztelés a jó biztonsági tervezés alapja. A tesztelés az ellenőrzés taktikai formája, amely biztosítja, hogy a vezérlők a kívánt módon működjenek. A tesztelés proaktív módszer a rendszer biztonsági réseinek észlelésére is.
A tesztelési szigor kialakítása több szempontból is ütemezéssel és ellenőrzéssel. Olyan külső nézőpontokat kell tartalmaznia, amelyek tesztelik a platformot és az infrastruktúrát, valamint külső támadóként tesztelik a rendszert.
Ez az útmutató javaslatokat nyújt a számítási feladat biztonsági helyzetének teszteléséhez. Ezeket a tesztelési módszereket implementálva javíthatja a számítási feladatok támadásokkal szembeni ellenállását, valamint fenntarthatja az erőforrások titkosságát, integritását és rendelkezésre állását.
Definíciók
| Időszak | Definíció |
|---|---|
| Alkalmazásbiztonsági tesztelés (AST) | Egy Microsoft Security Development Lifecycle (SDL) technika, amely a white-box és a black-box tesztelési módszereket használja a kód biztonsági réseinek ellenőrzéséhez. |
| Fekete dobozos tesztelés | Egy tesztelési módszertan, amely ellenőrzi a külsőleg látható alkalmazás viselkedését a rendszer belső elemeinek ismerete nélkül. |
| Kék csapat | Egy csapat, amely védekezik a vörös csapat támadásai ellen egy háborús játékban. |
| Behatolás tesztelése | Egy tesztelési módszertan, amely etikus hackelési technikákat használ a rendszer biztonsági védelmének ellenőrzésére. |
| Piros csapat | Egy csapat, amely egy támadó szerepét tölti be, és megpróbálja feltörni a rendszert egy háborús játékban. |
| Biztonságfejlesztési életciklus (Security Development Lifecycle, SDL) | A Microsoft által biztosított olyan gyakorlatok, amelyek támogatják a biztonsági garanciára és a megfelelőségi követelményekre vonatkozó követelményeket. |
| Szoftverfejlesztési életciklus (SDLC) | A szoftverrendszerek fejlesztésének többlépcsős, szisztematikus folyamata. |
| Fehér dobozos tesztelés | Tesztelési módszertan, ahol a kód struktúrája ismert a kezelő 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 szempontjából. Lehetővé teszi a biztonsági problémák proaktív felderítését és kezelését azok kiaknázása előtt, valamint annak ellenőrzését, hogy a végrehajtott biztonsági vezérlők a tervezett módon működnek-e.
A tesztelés hatókörének magában kell foglalnia az alkalmazást, az infrastruktúrát, valamint az automatizált és emberi folyamatokat.
Megjegyzés
Ez az útmutató különbséget tesz a tesztelés és az incidensmegoldás között. Bár a tesztelés olyan észlelési mechanizmus, amely ideális esetben az éles üzem előtt oldja meg a problémákat, nem szabad összekeverni az incidensmegoldás részeként végzett szervizeléssel vagy vizsgálattal. A biztonsági incidensekből való helyreállítás aspektusát az Incidensmegoldási javaslatok című cikk ismerteti.
Az SDL számos teszttípust tartalmaz, amelyek észlelik a kód biztonsági réseit, ellenőrzik a futtatókörnyezet összetevőit, és etikus hackeléssel tesztelik a rendszer biztonsági rugalmasságát. Az SDL egy balra tolódásos fő tevékenység. A fejlesztési folyamat korai szakaszában olyan teszteket kell futtatnia, mint a statikus kódelemzés és az infrastruktúra kódként (IaC) történő automatikus vizsgálata.
Vegyen részt a tesztelés megtervezésében. Előfordulhat, hogy a számítási feladatért felelős csapat nem tervezi meg a tesztelési eseteket. Ezt a feladatot gyakran a vállalaton belül központosítják, vagy külső biztonsági szakértők végzik el. A számítási feladatokért felelős csapatnak részt kell vennie ebben a tervezési folyamatban annak biztosítása érdekében, hogy a biztonsági garanciák integrálva legyenek az alkalmazás funkcióival.
Gondolkodj úgy, mint egy támadó. Tervezzen teszteseteket azzal a feltételezéssel, hogy a rendszert megtámadták. Így feltárhatja a lehetséges biztonsági réseket, és ennek megfelelően rangsorolhatja a teszteket.
A teszteket strukturált módon és megismételhető eljárással futtathatja. A tesztelési szigort az ütemezés, a tesztek típusai, az autós tényezők és a kívánt eredmények köré építheti.
Használja a feladathoz megfelelő eszközt. Használjon olyan eszközöket, amelyek úgy vannak konfigurálva, hogy működjenek a számítási feladattal. Ha nincs eszköze, vásárolja meg az eszközt. Ne készítse el. A biztonsági eszközök rendkívül specializáltak, és a saját eszköz létrehozása kockázatot jelenthet. Kihasználhatja a központi SecOps-csapatok által kínált szakértelmet és eszközöket, vagy külső eszközökkel, ha a számítási feladatokért felelős csapat nem rendelkezik ezzel a szakértelemmel.
Külön környezetek beállítása. A tesztek destruktívnak vagy nem destruktívnak minősíthetők. A nem destruktív tesztek nem invazívak. Azt jelzik, hogy probléma van, de a probléma megoldásához nem módosítják a működést. A romboló tesztek invazívak, és az adatbázis adatainak törlésével károsíthatják a működést.
Az éles környezetekben végzett tesztelés a legjobb információt nyújtja, de a legtöbb fennakadást okozza. Általában csak nem strukturált teszteket végez éles környezetekben. A nem éles környezetekben végzett tesztelés általában kevésbé zavaró, de nem feltétlenül tükrözi pontosan az éles környezet konfigurációját a biztonság szempontjából fontos módon.
Ha IaC-vel és automatizálással végzi az üzembe helyezést, fontolja meg, hogy létrehozhat-e izolált klónt az éles környezetből tesztelés céljából. Ha folyamatos folyamattal rendelkezik a rutintesztekhez, javasoljuk, hogy dedikált környezetet használjon.
Mindig értékelje ki a teszteredményeket. A tesztelés hiábavaló erőfeszítés, ha az eredményeket nem a műveletek rangsorolására és a jobb felsőbb rétegbeli fejlesztésekre használják. Dokumentálja a feltárt biztonsági irányelveket, beleértve az ajánlott eljárásokat is. Az eredményeket és a javítási terveket rögzítő dokumentáció bemutatja a csapatot, hogy a támadók milyen módokon próbálhatják meg feltörni a biztonságot. Rendszeresen tart biztonsági képzést fejlesztőknek, rendszergazdáknak és tesztelőknek.
A teszttervek tervezésekor gondolja át az alábbi kérdéseket:
Milyen gyakran fog futni a teszt, és milyen hatással van a környezetre?
Melyek a különböző teszttípusok, amelyeket futtatnia kell?
Milyen gyakran futnak a tesztek?
Rendszeresen tesztelje a számítási feladatot, hogy a módosítások ne vezessenek be biztonsági kockázatokat, és ne legyenek regressziók. A csapatnak készen kell állnia arra is, hogy reagáljon azokra a szervezeti biztonsági ellenőrzésekre, amelyeket bármikor végre lehet hajtani. Vannak olyan tesztek is, amelyek biztonsági incidensre reagálva futtathatók. A következő szakaszok a tesztek gyakoriságára vonatkozó javaslatokat nyújtanak.
Rutintesztek
A rutinteszteket rendszeres időközönként, a szokásos üzemeltetési eljárások részeként és a megfelelőségi követelményeknek való megfelelés érdekében végezzük. A különböző tesztek különböző ütemben futtathatók, de a lényeg az, hogy rendszeres időközönként és ütemezés szerint vannak elvégezve.
Ezeket a teszteket integrálnia kell az SDLC-be, mert minden szakaszban mélységi védelmet nyújtanak. A tesztcsomag diverzifikálása az identitással, az adattárolással és átvitellel, valamint a kommunikációs csatornákkal kapcsolatos biztosítékok 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 létrehozni egy kezdeti teljesítménytesztet. Ez azonban csak egy kiindulási pont. Amikor új problémákat fedez fel az életciklus ugyanazon pontjain, új teszteseteket ad hozzá. A tesztek az ismétléssel is javulnak.
Ezeknek a teszteknek minden fázisban ellenőrizniük kell a hozzáadott vagy eltávolított kódot, vagy a konfigurációs beállításokat, amelyek módosultak a módosítások biztonsági hatásának észlelése érdekében. Javítania kell a tesztek hatékonyságát az automatizálással, kiegyensúlyozni a társértékelésekkel.
Érdemes lehet biztonsági teszteket futtatni egy automatizált folyamat vagy ütemezett tesztfuttatás részeként. Minél hamarabb észleli a biztonsági problémákat, annál könnyebb megtalálni az azokat okozó kódot vagy konfigurációs módosítást.
Ne csak automatizált tesztekre hagyatkozz. Manuális tesztelés használatával észlelheti azokat a biztonsági réseket, amelyeket csak az emberi szakértelem képes észlelni. A manuális tesztelés alkalmas feltáró jellegű használati esetekre és ismeretlen kockázatok felderítésére.
Improvizált tesztek
Az improvizált tesztek a biztonsági védelem időponthoz kötött ellenőrzését biztosítják. Azok a biztonsági riasztások, amelyek hatással lehetnek a számítási feladatra, aktiválják ezeket a teszteket. A szervezeti megbízásokhoz szükség lehet egy szüneteltetési és tesztelési gondolkodásmódra a védelmi stratégiák hatékonyságának ellenőrzéséhez, ha a riasztás vészhelyzetre eszkalál.
Az improvizált tesztek előnye a valódi incidensre való felkészültség. Ezek a tesztek kényszerítő függvények lehetnek a felhasználói elfogadás tesztelésére (UAT).
A biztonsági csapat szükség szerint naplózhatja az összes számítási feladatot, és futtathatja ezeket a teszteket. Számítási feladat tulajdonosaként elő kell segítenie és együtt kell működnie a biztonsági csapatokkal. Egyeztethet elég átfutási időt a biztonsági csapatokkal, hogy felkészülhessen. Nyugtázza és közölje a csapattal é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 az improvizált tesztek zavaró események, várhatóan újrarendezik a feladatokat, ami késleltetheti a többi tervezett munkát.
Kockázat: Fennáll az ismeretlen veszélye. Az improvizált tesztek egyszeri próbálkozások lehetnek, meghatározott folyamatok vagy eszközök nélkül. A fő kockázat azonban az üzletmenet ritmusának esetleges megszakadása. Ezeket a kockázatokat az előnyökhöz viszonyítva kell értékelnie.
Biztonsági incidenstesztek
Vannak olyan tesztek, amelyek észlelik a biztonsági incidens okát a forrásánál. Ezeket a biztonsági réseket meg kell oldani, hogy az incidens ne ismétlődjön meg.
Az incidensek a meglévő hiányosságok feltárásával idővel javítják a tesztelési eseteket is. A csapatnak alkalmaznia kell az incidensből levont tanulságokat, és rutinszerűen bele kell foglalnia a fejlesztéseket.
Melyek a különböző típusú tesztek?
A tesztek a technológia és a tesztelési módszerek szerint kategorizálhatók. Kombinálja ezeket a kategóriákat és megközelítéseket az adott kategóriákon belül, hogy teljes lefedettséget kapjon.
Ha több tesztet és teszttípust ad hozzá, az alábbiakat fedheti fel:
Hiányosságok a biztonsági vezérlőkben vagy a kompenzáló vezérlőkben.
Helytelen konfigurációk.
A megfigyelhetőségi és észlelési módszerek hiányosságai.
Egy jó fenyegetésmodellezési gyakorlat kulcsfontosságú területekre mutathat a tesztelési lefedettség és a gyakoriság 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 leírt legtöbb teszt rutintesztként futtatható. Az ismételhetőség azonban bizonyos esetekben költségekkel járhat, és fennakadást okozhat. Alaposan fontolja meg ezeket a kompromisszumokat.
A technológiai vermet ellenőrző tesztek
Íme néhány példa a tesztek típusaira és azok fókuszterületére. Ez a lista nem teljes. Tesztelje a teljes vermet, beleértve az alkalmazás vermet, az előtérrendszert, a háttérrendszert, az API-kat, az adatbázisokat és minden külső integrációt.
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ásokkal 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 feladatba.
Alkalmazás: Tesztelje a forráskódot alkalmazásbiztonsági tesztelési (AST) technikákkal, hogy biztosan kövesse a biztonságos kódolási eljárásokat, és észlelje a futásidejű hibákat, például a memóriasérülést és a jogosultsági problémákat. További részletekért tekintse meg ezeket a közösségi hivatkozásokat.
Identitás: Értékelje ki, hogy a szerepkör-hozzárendelések és a feltételes ellenőrzések a kívánt módon működnek-e.
Tesztelési módszer
A tesztelési módszereknek számos perspektívájuk van. Olyan teszteket ajánlunk, amelyek valós támadások szimulálásával teszik lehetővé a fenyegetéskeresést. Azonosíthatják a potenciális veszélyforrás-szereplőket, azok technikáit és azok kihasználtságait, amelyek fenyegetést jelentenek a számítási feladatra. A támadásokat a lehető legreálisabbra kell tenni. Használja az összes lehetséges fenyegetésvektort, amelyet a fenyegetésmodellezés során azonosít.
Íme néhány előnye a valós támadásokon keresztüli tesztelésnek:
Amikor ezeket a támadásokat a rutintesztek részévé teszi, külső perspektívát használ a számítási feladatok ellenőrzéséhez, és győződjön meg arról, hogy a védelem képes ellenállni a támadásoknak.
A tanultak alapján a csapat frissíti tudását és készségeit. A csapat javítja a helyzettudatosságot, és önértékeléssel képes reagálni az incidensekre.
Néhány példa a szimulált tesztekre: feketedobozos és fehérdobozos tesztelés, behatolástesztelés és hadijáték-gyakorlatok.
Fekete dobozos és fehérdobozos tesztelés
Ezek a teszttípusok két különböző perspektívát kínálnak. A fekete dobozos tesztekben a rendszer belső részei nem láthatók. A white-box tesztekben a tesztelő jól ismeri az alkalmazást, és még hozzáféréssel is rendelkezik a kísérlet végrehajtásához szükséges kódhoz, naplókhoz, erőforrás-topológiához és konfigurációkhoz.
Behatolástesztelésen keresztüli támadásokat szimuláló tesztek
Azok a biztonsági szakértők, akik nem részei a szervezet informatikai vagy alkalmazáscsapatainak, behatolástesztelést vagy tesztelést végeznek. Úgy tekintenek a rendszerre, ahogyan a rosszindulatú szereplők egy támadási felületet hatókörbe helyezik. Céljuk a biztonsági rések felderítése az információk összegyűjtésével, a biztonsági rések elemzésével és az eredmények jelentésével.
Előfordulhat, hogy a szakembereknek hozzáférésre van szükségük a bizalmas adatokhoz a teljes szervezetben. Kövesse az előjegyzési szabályokat annak érdekében, hogy a hozzáférés ne legyen visszaélve. Tekintse meg a kapcsolódó hivatkozásokban felsorolt erőforrásokat.
Tesztek, amelyek háborús játékgyakorlatokkal szimulálják a támadásokat
A szimulált támadásoknak ebben a módszertanában két csapat van:
A vörös csapat az a támadó, aki valós támadásokat próbál modellelni. Ha sikeresek, hiányosságokat talál a biztonsági tervben, és kiértékeli a behatolások sugárelszigetelését.
A kék csapat a számítási feladatokért felelős csapat, amely megvédi a támadásokat. Tesztelik, hogy képesek-e észlelni, reagálni és elhárítani a támadásokat. Ellenőrzik a számítási feladatok erőforrásainak védelme érdekében implementált védelmet.
Ha rutintesztekként végzik őket, a hadijáték-gyakorlatok folyamatos láthatóságot és biztosítékot nyújtanak arra, hogy a védelmük a tervezett módon működik. A hadijáték-gyakorlatok a számítási feladatok különböző szintjein tesztelhetők.
A reális támadási forgatókönyvek szimulálására népszerű választás a Office 365-höz készült Microsoft Defender Támadási szimulációs tréning.
További információ: Elemzések és jelentések Támadási szimulációs tréning.
A vörös csapat és a kék csapat beállításával kapcsolatos információkért lásd: Microsoft Cloud Red Teaming.
Azure-beli facilitálás
A Microsoft Sentinel egy natív vezérlő, amely egyesíti a biztonsági információk eseménykezelését (SIEM) és a biztonsági vezénylés automatizált válaszképességeit. Különböző csatlakoztatott forrásokból származó eseményeket és naplókat elemez. Az adatforrások és riasztásaik alapján a Microsoft Sentinel incidenseket hoz létre, és fenyegetéselemzést végez a korai észlelés érdekében. Intelligens elemzésekkel és lekérdezésekkel proaktívan megkeresheti a biztonsági problémákat. Incidens esetén automatizálhatja a munkafolyamatokat. Emellett a munkafüzetsablonokkal gyorsan betekintést nyerhet a vizualizációkba.
A termékdokumentációt a Vadászati képességek a Microsoft Sentinelben című témakörben találja.
Microsoft Defender a felhőhöz különböző technológiai területek sebezhetőségi vizsgálatát teszi lehetővé. További részletekért lásd: Biztonságirés-vizsgálat engedélyezése Microsoft Defender biztonságirés-kezelés – Microsoft Defender a felhőhöz.
A DevSecOps gyakorlata egy folyamatos és folyamatos fejlesztési szemlélet részeként integrálja a biztonsági tesztelést. A hadijáték-gyakorlatok olyan gyakori gyakorlatok, amelyek a Microsoft üzleti ritmusába integrálódnak. További információ: Biztonság a DevOpsban (DevSecOps).
Az Azure DevOps támogatja a külső eszközöket, amelyek a folyamatos integrációs/folyamatos üzembehelyezési folyamatok részeként automatizálhatók. Részletekért lásd: A DevSecOps engedélyezése az Azure-ral és a GitHubbal – Azure DevOps.
Kapcsolódó hivatkozások
Kövesse az előjegyzési szabályokat, és győződjön meg arról, hogy a hozzáférés nem hibás. A szimulált támadások tervezésével és végrehajtásával kapcsolatos útmutatásért tekintse meg a következő cikkeket:
A szolgáltatásmegtagadási (DoS-) támadásokat szimulálhatja az Azure-ban. Mindenképpen kövesse az Azure DDoS Protection szimulációs tesztelésében meghatározott szabályzatokat.
Közösségi hivatkozások
Alkalmazásbiztonsági tesztelés: Eszközök, típusok és ajánlott eljárások – A GitHub-erőforrások azokat a tesztelési módszereket ismertetik, amelyek tesztelhetik az alkalmazás buildelési és futásidejű védelmét.
A behatolásteszt-végrehajtási standard (PTES) útmutatást nyújt a gyakori forgatókönyvekhez és az alapkonfiguráció létrehozásához szükséges tevékenységekhez.
OWASP Top 10 | Az OWASP Foundation biztonsági ajánlott eljárásokat biztosít a gyakori fenyegetéseket lefedő alkalmazásokhoz és tesztelési esetekhez.
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: