Biztonsági tesztelési javaslatok
Az Azure Well-Architected Framework biztonsági ellenőrzőlistára vonatkozó javaslatra vonatkozik:
| SE:11 | 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 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.
Tesztelési szigor kialakítása több szemszögből történő ütemezéssel és ellenőrzéssel. Olyan külső nézőpontokat kell tartalmaznia, amelyek tesztelik a platformot és az infrastruktúrát, valamint a külső teszteket, amelyek külső támadóként tesztelik a rendszert.
Ez az útmutató javaslatokat nyújt a számítási feladatok 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 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) | 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 a rendszer belső elemeinek ismerete nélkül ellenőrzi a külsőleg látható alkalmazás viselkedését. |
| Kék csapat | Egy csapat, amely megvédi a támadásokat a vörös csapat egy háborús játék gyakorlat. |
| Behatolás tesztelése | Tesztelési módszertan, amely etikai hackelési technikákat használ a rendszer biztonsági védelmének ellenőrzéséhez. |
| 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 eljárások, 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) | Többtényezős, szisztematikus folyamat szoftverrendszerek fejlesztéséhez. |
| Fehér dobozos tesztelés | Egy tesztelési módszertan, amelyben a kód struktúrája ismert a gyakorló számára. |
Főbb 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, hogy proaktívan felderítse és kezelje a biztonsági problémákat, mielőtt azok kihasználhatók lennének, és ellenőrizheti, hogy a végrehajtott biztonsági vezérlők a tervezett módon működnek-e.
A tesztelés hatókörének tartalmaznia kell az alkalmazást, az infrastruktúrát, valamint az automatizált és emberi folyamatokat.
Feljegyzés
Ez az útmutató különbséget tesz a tesztelés és az incidenskezelés között. Bár a tesztelés olyan észlelési mechanizmus, amely ideális megoldás a problémákra az éles üzem előtt, nem szabad összetéveszteni az incidensmegoldás részeként végzett szervizeléssel vagy vizsgálattal. A biztonsági incidensekből való helyreállítás szempontjait az incidensmegoldási javaslatok ismertetik.
Az SDL számos olyan teszttípust tartalmaz, amelyek észlelik a kód biztonsági réseit, ellenőrzik a futtatókörnyezet összetevőit, és etikus hackelés használatával tesztelik a rendszer biztonsági rugalmasságát. Az SDL egy balra tolódásos 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ő automatizált vizsgálata.
Vegyen részt a tesztelés megtervezésében. Előfordulhat, hogy a számítási feladatok csapata nem tervezi meg a teszteseteket. 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 csapatának részt kell vennie ebben a tervezési folyamatban, hogy a biztonsági garanciák integrálhatók 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 ütem, a tesztek típusai, a vezetési tényezők és a tervezett 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 szerszáma, vásárolja meg az eszközt. Ne építsd fel. A biztonsági eszközök rendkívül specializáltak, és a saját eszköz létrehozása kockázatokat jelenthet. Használja ki a központi SecOps-csapatok vagy külső eszközök által kínált szakértelmet és eszközöket, ha a számítási feladatokat végző csapat nem rendelkezik ezzel a szakértelemmel.
Hozzon létre külön környezeteket. A tesztek destruktívnak vagy nem strukturáltnak minősíthetők. A nem strukturált tesztek nem invazívak. Azt jelzik, hogy probléma van, de nem módosítják a működést a probléma megoldása érdekében. A romboló tesztek invazívak, és az adatok adatbázisból való törlésével károsíthatják a funkciókat.
Az éles környezetekben végzett tesztelés a legjobb információt nyújtja, de a legnagyobb fennakadást okozza. Általában csak nem strukturált teszteket végez éles környezetben. A nem termelési környezetekben végzett tesztelés általában kevésbé zavaró, de nem feltétlenül felel meg pontosan az éles környezet konfigurációjának a biztonság számára fontos módon.
Ha IaC-vel és automatizálással telepít, 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 pazarlás, ha az eredményeket nem a műveletek rangsorolására és a fejlesztésekre használják fel. 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ó bemutatja a csapatnak, hogy a támadók milyen módszerekkel próbálhatják 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 a következő kérdéseket:
Milyen gyakran várható, hogy a teszt lefut, és milyen hatással van a környezetére?
Melyek a különböző teszttípusok, amelyeket futtatnia kell?
A számítási feladat rendszeres tesztelése
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 válaszoljon azokra a szervezeti biztonsági ellenőrzésekre, amelyeket bármikor elvégezhet. Vannak olyan tesztek is, amelyeket biztonsági incidensre válaszul futtathat. A következő szakaszok a tesztek gyakoriságára vonatkozó javaslatokat nyújtanak.
Rutintesztek
A rutintesztek rendszeres időközönként, a szabványos üzemeltetési eljárások részeként és a megfelelőségi követelményeknek való megfelelés érdekében zajlanak. A különböző tesztek különböző ütemben futtathatók, de a kulcs az, hogy rendszeres időközönként és ütemezés szerint hajtják végre őket.
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 az adatá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 kiindulópont. Amikor új problémákat tár fel az életciklus ugyanazon pontjain, új teszteseteket ad hozzá. A tesztek az 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ításokat módosító konfigurációs beállításokat 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, a társértékelésekkel kiegyensúlyozottan.
Érdemes lehet biztonsági teszteket futtatni egy automatizált folyamat vagy ütemezett tesztfuttatás részeként. Minél hamarabb észlel biztonsági problémákat, annál könnyebb megtalálni az őket 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 elkapni. A manuális tesztelés alkalmas feltáró jellegű használati esetekre és ismeretlen kockázatok felderítésére.
Rögtönzött tesztek
Az improvizált tesztek a biztonsági védelem időszerű ellenőrzését biztosítják. Ezeket a teszteket olyan biztonsági riasztások aktiválják, amelyek hatással lehetnek a számítási feladatra. A szervezeti megbízatá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 egy valós 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 a biztonsági csapatokkal elegendő átfutási időről, hogy felkészülhessen. Nyugtázza és közölje a csapattal és az érdekelt felekkel, hogy ezek a fennakadások szükségesek.
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 kockázata. Az improvizatív tesztek egyszeri próbálkozások lehetnek, amelyekhez nincs szükség meghatározott folyamatokra vagy eszközökre. De az elsődleges kockázat az üzletmenet ritmusának esetleges megszakítása. Ezeket a kockázatokat az előnyökhöz képest 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 be kell építenie a fejlesztéseket.
Különböző tesztek alkalmazása
A tesztek a technológia és a tesztelési módszerek szerint kategorizálhatók. A teljes lefedettség érdekében egyesítse ezeket a kategóriákat és megközelítéseket ezeken a kategóriákon belül.
Több teszt és teszttípus hozzáadásával a következőt 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.
A 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 tekintse meg a fejlesztési életciklus biztonságossá tételére vonatkozó javaslatokat.
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 gondolja át 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érbeli, a háttérrendszert, az API-kat, az adatbázisokat és az esetleges külső integrációkat.
Adatbiztonság: Az adattitkosítás és a hozzáférés-vezérlés hatékonyságának tesztelése annak érdekében, 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, hogy csak a várt, engedélyezett és biztonságos forgalmat engedélyezze a számítási feladat számára.
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 hogy é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: Annak kiértékelése, 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ó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 teszik lehetővé a fenyegetéskeresést. Azonosíthatják a potenciális veszélyforrás-szereplőket, a technikákat és azok kihasználásait, amelyek fenyegetést jelentenek a számítási feladatra. A támadásokat a lehető legreálisabbá teheti. 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:
Ha ezeket a támadásokat a rutintesztelés részévé teszi, külső szemszögből ellenőrzi a számítási feladatot, és meggyőződik arról, hogy a védelem képes ellenállni a támadásoknak.
A tanultak alapján a csapat fejleszti tudását és képzettségi szintjét. 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 feketedobozos 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 a kódhoz, a naplókhoz, az erőforrástopológiához és a kísérlet elvégzéséhez szükséges konfigurációkhoz is hozzáfér.
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, hogy biztonsági réseket találjanak az információk gyűjtésével, a biztonsági rések elemzésével és az eredmények jelentésével.
Előfordulhat, hogy a szakembereknek az egész szervezetben szükségük lehet a bizalmas adatokhoz való hozzáférésre. 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, réseket 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 vé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 rutintesztké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 a 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 a Microsoft Cloud Red Teaminget.
Az Azure megkönnyítése
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égét (SOAR). 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ív módon kereshet 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 Microsoft Sentinel vadászati képességei című témakörben találja.
Felhőhöz készült Microsoft Defender különböző technológiai területek sebezhetőségi vizsgálatát teszi lehetővé. További információt a biztonsági rések vizsgálatának engedélyezése Microsoft Defender biztonságirés-kezelés – Felhőhöz készült Microsoft Defender című témakörben talál.
A DevSecOps gyakorlata egy folyamatos és folyamatos fejlesztési gondolkodásmód részeként integrálja a biztonsági tesztelést. A hadijáték-gyakorlatok a Microsoft üzleti ritmusába integrálható gyakori gyakorlatok. További információ: Security in DevOps (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. További részletekért lásd : DevSecOps engedélyezése az Azure-ral és a GitHubon – Azure DevOps.
Kapcsolódó hivatkozások
Kövesse az előjegyzési szabályokat annak érdekében, hogy a hozzáférés ne legyen visszaélve. A szimulált támadások tervezésével és végrehajtásával kapcsolatos útmutatásért tekintse meg az alábbi cikkeket:
Szolgáltatásmegtagadási (DoS-) támadásokat szimulálhat 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ástesztelési végrehajtási szabvány (PTES) útmutatást nyújt a gyakori forgatókönyvekről és az alapkonfiguráció létrehozásához szükséges tevékenységekről.
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.