Design your Microsoft Sentinel workspace architecture
Ez a cikk egy döntési fát tartalmaz, amely segít a Microsoft Sentinel-munkaterület architektúrájának tervezésével kapcsolatos legfontosabb döntések meghozatalában. További információkért tekintse meg a Microsoft Sentinel minta-munkaterületterveket és a Microsoft Sentinel-munkaterület architektúrájának ajánlott eljárásait. Ez a cikk a Microsoft Sentinel üzembe helyezési útmutatójának része.
Előfeltételek
A döntési fa használata előtt győződjön meg arról, hogy rendelkezik a következő információkkal:
Előfeltételek | Leírás |
---|---|
Az Azure-adattárolással kapcsolatos szabályozási követelmények | A Microsoft Sentinel a legtöbb munkaterületen futtatható, de nem minden olyan régióban , amelyet a Log Analytics a GA-ban támogat. Az újonnan támogatott Log Analytics-régiók eltarthatnak egy ideig a Microsoft Sentinel szolgáltatás előkészítéséhez. A Microsoft Sentinel által létrehozott adatok, például incidensek, könyvjelzők és elemzési szabályok tartalmazhatnak néhány, az ügyfél Log Analytics-munkaterületéről származó ügyféladatot. További információ: Földrajzi rendelkezésre állás és adattárolás. |
Adatforrások | Megtudhatja, hogy mely adatforrásokhoz kell csatlakoznia, beleértve a Microsoft és a nem Microsoft-megoldások beépített összekötőit is. A Common Event Format (CEF), a Syslog vagy a REST-API használatával is csatlakoztathatja adatforrásait a Microsoft Sentinelhez. Ha több Azure-beli azure-beli virtuális géppel rendelkezik, amelyekből be kell gyűjtenie a naplókat, és az adatforgalom költségeinek mentése fontos Önnek, akkor az egyes Azure-helyek sávszélesség-díjszabási kalkulátorával ki kell számítania az adatforgalom költségét. |
Felhasználói szerepkörök és adathozzáférési szintek/engedélyek | A Microsoft Sentinel azure-beli szerepköralapú hozzáférés-vezérléssel (Azure RBAC) biztosít beépített szerepköröket , amelyek hozzárendelhetők az Azure felhasználóihoz, csoportjaihoz és szolgáltatásaihoz. Minden beépített Microsoft Sentinel-szerepkör olvasási hozzáférést biztosít a Microsoft Sentinel-munkaterületen lévő adatokhoz. Ezért meg kell állapítania, hogy szükség van-e az adatforrásonkénti vagy sorszintű adathozzáférés szabályozására, mivel ez hatással lesz a munkaterület tervezési döntésére. További információ: Egyéni szerepkörök és speciális Azure RBAC. |
Napi betöltési arány | A napi betöltési arány, amely általában GB/nap, a Microsoft Sentinel költségkezelési és tervezési szempontjainak és munkaterület-kialakításának egyik fő tényezője. A legtöbb felhőalapú és hibrid környezetben a hálózati eszközök, például tűzfalak vagy proxyk, valamint a Windows és Linux kiszolgálók a legelterjedtebb adatokat állítják elő. A legpontosabb eredmények eléréséhez a Microsoft az adatforrások teljes leltárát javasolja. Másik lehetőségként a Microsoft Sentinel költségkalkulátora hasznos táblázatokat is tartalmaz az adatforrások lábnyomának becsléséhez. Fontos: Ezek a becslések kiindulópontok, és a napló részletességi beállításai és a számítási feladatok varianciákat eredményeznek. Javasoljuk, hogy rendszeresen figyelje a rendszert a változások nyomon követése érdekében. A forgatókönyv alapján rendszeres monitorozás javasolt. További információkért tekintse meg az Azure Monitor-naplók díjszabásának részleteit. |
Döntési fa
Az alábbi képen egy teljes döntésifa-folyamatábra látható, amely segít megérteni, hogyan tervezheti meg a legjobban a munkaterületet.
A következő szakaszok a döntési fa teljes szöveges verzióját tartalmazzák, beleértve a képen hivatkozott alábbi megjegyzéseket:
Megjegyzés #1 | Megjegyzés #2 | Megjegyzés #3 | Megjegyzés #4 | Megjegyzés #5 | Megjegyzés #6 | Megjegyzés #7 | Megjegyzés #8 | Megjegyzés #9 | Megjegyzés #10
1. lépés: Új vagy meglévő munkaterület?
Rendelkezik olyan munkaterülettel, amelyet a Microsoft Sentinelhez használhat?
Ha nem, és minden esetben új munkaterületet fog létrehozni, folytassa közvetlenül a 2. lépéssel.
Ha van egy meglévő munkaterülete , amelyet használhat, fontolja meg, hogy mennyi adatot fog betöltésre használni.
Ha naponta több mint 100 GB-ot fog elfogyasztani, javasoljuk, hogy a költséghatékonyság érdekében használjon külön munkaterületet.
Ha napi 100 GB-nál kevesebbet fog betöltésre, folytassa a 2. lépéssel a további értékeléshez. Ezt a kérdést az 5. lépésben felmerülő esetekben érdemes újra megfontolni.
2. lépés: Az adatok megőrzése különböző Azure-beli földrajzi helyeken?
Ha a különböző Azure-beli földrajzi helyeken való adatmegőrzésre vonatkozó jogszabályi követelményekkel rendelkezik, minden olyan Azure-régióhoz használjon külön Microsoft Sentinel-munkaterületet, amely megfelelőségi követelményekkel rendelkezik. További információkért tekintse meg a régióval kapcsolatos szempontokat.
Ha nem kell különböző Azure-földrajzi helyeken tárolnia az adatokat, folytassa a 3. lépéssel.
3. lépés: Több Azure-bérlője van?
Ha csak egyetlen bérlővel rendelkezik, folytassa közvetlenül a 4. lépéssel.
Ha több Azure-bérlője van, fontolja meg, hogy olyan naplókat gyűjt-e, amelyek egy bérlőhatárra vonatkoznak, például az Office 365-re vagy a Microsoft Defender XDR-re.
Ha nem rendelkezik bérlőspecifikus naplókkal, folytassa közvetlenül a 4. lépéssel.
Ha bérlőspecifikus naplókat gyűjt, minden Microsoft Entra-bérlőhöz használjon külön Microsoft Sentinel-munkaterületet. Folytassa a 4. lépéssel más szempontokat is figyelembe véve.
1. döntésifa megjegyzés: A bérlői határokra vonatkozó naplók, például az Office 365-ből és Felhőhöz készült Microsoft Defender, csak ugyanabban a bérlőn belüli munkaterületen tárolhatók.
Bár egyéni gyűjtők használatával is gyűjthet bérlőspecifikus naplókat egy másik bérlő munkaterületéről, ezt a következő hátrányok miatt nem javasoljuk:
- Az egyéni összekötők által gyűjtött adatok egyéni táblákba kerülnek. Ezért nem fogja tudni használni az összes beépített szabályt és munkafüzetet.
- Az egyéni táblákat egyes beépített funkciók, például az UEBA és a gépi tanulási szabályok nem veszik figyelembe.
- Az egyéni összekötőkhöz, például az Azure Functions és a Logic Apps használatához további költségekre és erőfeszítésekre van szükség.
Ha ezek a hátrányok nem okoznak problémát a szervezet számára, folytassa a 4. lépéssel a különálló Microsoft Sentinel-munkaterületek használata helyett.
4. lépés: Számlázás felosztása/ visszaterhelés?
Ha fel kell osztania a számlázást vagy a díjakat, fontolja meg, hogy a használati jelentés vagy a manuális keresztdíj működik-e Önnek.
Ha nem kell felosztania a számlázást vagy a díjvisszafizetést, folytassa az 5. lépéssel.
Ha fel kell osztania a számlázást vagy a visszaterhelést, fontolja meg a manuális keresztdíj használatát. Az entitásonkénti pontos költségek lekéréséhez használhatja a Microsoft Sentinel Cost munkafüzet egy módosított verzióját, amely entitásonként lebontja a költségeket.
Ha a használati jelentés vagy a manuális kereszttöltés működik Önnek, folytassa az 5. lépéssel.
Ha sem a használati jelentés, sem a manuális kereszthasználat nem működik Önnek, minden költségtulajdonoshoz használjon külön Microsoft Sentinel-munkaterületet.
Döntési fa megjegyzés #2: További információkért lásd a Microsoft Sentinel költségeit és számlázását.
5. lépés: Nem SOC-adatok gyűjtése?
Ha nem gyűjt nem SOC-adatokat, például működési adatokat, közvetlenül a 6. lépésre ugorhat.
Ha nem SOC-adatokat gyűjt, fontolja meg, hogy vannak-e átfedések, ahol a SOC- és a nem SOC-adatok esetében is ugyanaz az adatforrás szükséges.
Ha átfedésben van a SOC és a nem SOC-adatok között, az átfedésben lévő adatokat csak SOC-adatokként kezelje. Ezután fontolja meg, hogy a SOC- és a nem SOC-adatok betöltése egyenként kisebb-e, mint 100 GB / nap, de kombinálva több mint 100 GB/nap:
- Igen: Folytassa a 6. lépéssel a további értékeléshez.
- Nem: A költséghatékonyság érdekében nem javasoljuk, hogy ugyanazt a munkaterületet használja. Folytassa a 6. lépéssel a további értékeléshez.
Mindkét esetben további információt a 10. megjegyzésben talál.
Ha nincsenek átfedésben lévő adatok, fontolja meg, hogy a SOC- és a nem SOC-adatok betöltése egyenként kisebb-e 100 GB/napnál, de kombinálva több mint 100 GB/nap:
- Igen: Folytassa a 6. lépéssel a további értékeléshez. További információ: 3. megjegyzés.
- Nem: A költséghatékonyság érdekében nem javasoljuk, hogy ugyanazt a munkaterületet használja. Folytassa a 6. lépéssel a további értékeléshez.
SOC- és nem SOC-adatok kombinálása
3. döntésifa megjegyzés: Bár általában azt javasoljuk, hogy az ügyfelek külön munkaterületet tartsanak a nem SOC-adatokhoz, hogy a nem SOC-adatokra ne vonatkozhassanak a Microsoft Sentinel költségei, előfordulhatnak olyan helyzetek, amikor az SOC és a nem SOC-adatok kombinálása kevésbé költséges, mint az elkülönítésük.
Vegyük például azt a szervezetet, amelynek biztonsági naplói 50 GB/nap sebességgel vannak betöltve, a műveleti naplók 50 GB/nap sebességgel vannak betöltve, és egy munkaterület az USA keleti régiójában.
Az alábbi táblázat összehasonlítja a munkaterület beállításait külön munkaterületekkel és anélkül.
Megjegyzés:
Az alábbi táblázatban felsorolt költségek és kifejezések hamisak, és csak szemléltető célokra használhatók. A költségekről a Microsoft Sentinel díjszabási kalkulátorában tájékozódhat.
Munkaterület architektúrája | Leírás |
---|---|
Az SOC-csapat saját munkaterülettel rendelkezik, és a Microsoft Sentinel engedélyezve van. Az Ops csapata saját munkaterülettel rendelkezik, a Microsoft Sentinel engedélyezése nélkül. |
SOC-csapat: A Microsoft Sentinel 50 GB/nap költsége havonta 6500 dollár. Az első három hónap megőrzés ingyenes. Műveleti csapat: - A Log Analytics 50 GB/nap költsége havonta körülbelül 3500 dollár. - Az első 31 nap megőrzés ingyenes. A teljes költség mindkét esetben havi 10 000 usd. |
Az SOC és az Ops csapata is ugyanazt a munkaterületet használja, és a Microsoft Sentinel engedélyezve van. | Mindkét napló kombinálásával a betöltés 100 GB /nap lesz, amely jogosult a kötelezettségvállalási szintre (a Sentinel esetében 50%, az LA esetében pedig 15%). A Microsoft Sentinel 100 GB/nap költsége havi 9000 dollárnak felel meg. |
Ebben a példában havonta 1000 usd költségmegtakarítás érhető el mindkét munkaterület kombinálásával, és az Ops csapata 31 nap helyett 3 hónap ingyenes megőrzést is élvez.
Ez a példa csak akkor releváns, ha mind a SOC, mind a nem SOC-adatok betöltési mérete >=50 GB/nap és <100 GB/nap.
Döntési fa megjegyzés #10: Javasoljuk, hogy használjon külön munkaterületet a nem SOC-adatokhoz, hogy a nem SOC-adatok ne tartoznak a Microsoft Sentinel költségeinek hatálya alá.
Ez a nem SOC-adatokhoz tartozó különálló munkaterületekre vonatkozó javaslat azonban tisztán költségalapú, és más kulcsfontosságú tervezési tényezőket is figyelembe kell venni annak meghatározásakor, hogy egy vagy több munkaterületet használ-e. A dupla betöltési költségek elkerülése érdekében fontolja meg az átfedésben lévő adatok gyűjtését egyetlen munkaterületen csak táblaszintű Azure RBAC-vel.
6. lépés: Több régió?
Ha csak egyetlenrégióban gyűjt naplókat azure-beli virtuális gépekről, folytassa közvetlenül a 7. lépéssel.
Ha több régióban lévő Azure-beli virtuális gépekről gyűjt naplókat, mennyire aggódik az adatforgalom költségeivel kapcsolatban?
Döntési fa megjegyzés #4: Az adatforgalom az adatok Azure-adatközpontból való áthelyezésének sávszélesség-költségét jelenti. További információkért tekintse meg a régióval kapcsolatos szempontokat.
Ha a különálló munkaterületek fenntartásához szükséges munkamennyiség csökkentése prioritást élvez, folytassa a 7. lépéssel.
Ha az adatforgalom költsége elég aggodalomra ad okot a különálló munkaterületek fenntartásához, minden olyan régióhoz használjon külön Microsoft Sentinel-munkaterületet, ahol csökkentenie kell az adatforgalom költségeit.
Döntési fa megjegyzés # 5: Azt javasoljuk, hogy a lehető legkevesebb munkaterületet. Az Azure díjkalkulátorával megbecsülheti a költségeket, és meghatározhatja, hogy mely régiókra van ténylegesen szüksége, és egyesítheti a munkaterületeket alacsony kimenő költségekkel rendelkező régiókhoz. A sávszélesség költségei csak kis részét képezhetik az Azure-számlának, ha összehasonlítjuk a Microsoft Sentinel és a Log Analytics különböző betöltési költségeit.
A költségeket például a következőképpen becsülheti meg:
- 1000 virtuális gép, amelyek mindegyike 1 GB/nap értéket hoz létre;
- Adatok küldése usa-beli régióból egy EU-régióba;
- 2:1 tömörítési sebesség használata az ügynökben
Ennek a becsült költségnek a kiszámítása a következő lenne:
1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost
Ez a mintaköltség sokkal olcsóbb lenne egy külön Microsoft Sentinel- és Log Analytics-munkaterület havi költségeihez képest.
Megjegyzés:
A felsorolt költségek hamisak, és csak szemléltető célokra használhatók. A költségekről a Microsoft Sentinel díjszabási kalkulátorában tájékozódhat.
7. lépés: Adatok elkülönítése vagy határok meghatározása tulajdonjog alapján?
Ha nem kell elkülönítenie az adatokat, vagy nem határoz meg tulajdonjogi határokat, folytassa közvetlenül a 8. lépéssel.
Ha el kell különítenie az adatokat, vagy tulajdonosi korlátokat kell meghatároznia, minden adattulajdonosnak használnia kell a Microsoft Sentinel portált?
Ha minden adattulajdonosnak hozzáféréssel kell rendelkeznie a Microsoft Sentinel portálhoz, minden tulajdonoshoz külön Microsoft Sentinel-munkaterületet kell használnia.
Döntési fa megjegyzés #6: A Microsoft Sentinel portálhoz való hozzáféréshez minden felhasználónak rendelkeznie kell legalább egy Microsoft Sentinel-olvasó szerepkörrel, amely rendelkezik olvasói engedélyekkel a munkaterület összes tábláján. Ha egy felhasználó nem rendelkezik hozzáféréssel a munkaterület összes táblához, akkor a Log Analytics használatával kell hozzáférnie a keresési lekérdezések naplóihoz.
Ha a naplókhoz való hozzáférés a Log Analyticsen keresztül elegendő minden olyan tulajdonos számára, aki nem fér hozzá a Microsoft Sentinel portálhoz, folytassa a 8. lépéssel.
További információ: Engedélyek a Microsoft Sentinelben.
8. lépés: Adathozzáférés szabályozása adatforrás/tábla alapján?
Ha nem kell forrás vagy tábla alapján szabályoznia az adathozzáférést, használjon egyetlen Microsoft Sentinel-munkaterületet.
Ha forrás vagy tábla szerint kell szabályoznia az adathozzáférést, fontolja meg az erőforrás-környezet RBAC használatát a következő helyzetekben:
Ha sorszinten kell szabályoznia a hozzáférést, például több tulajdonost kell biztosítani minden adatforráshoz vagy táblához
Ha több egyéni adatforrása/táblája van, ahol mindegyiknek külön engedélyre van szüksége
Más esetekben, ha nem kell a sor szintjén szabályoznia a hozzáférést, adjon meg több, egyéni adatforrást/táblát külön engedélyekkel, használjon egyetlen Microsoft Sentinel-munkaterületet, valamint táblaszintű RBAC-t az adathozzáférés-vezérléshez.
Az erőforrás-környezet vagy a táblaszintű RBAC szempontjai
Amikor erőforrás-környezet vagy táblaszintű RBAC használatát tervezi, vegye figyelembe a következő információkat:
7. döntésifa megjegyzés: Az erőforrás-környezet RBAC nem Azure-erőforrásokhoz való konfigurálásához célszerű lehet erőforrás-azonosítót társítani az adatokhoz a Microsoft Sentinelnek való küldéskor, hogy az engedély hatóköre erőforrás-környezetbeli RBAC használatával legyen korlátozva. További információ: Az erőforrás-környezet RBAC - és hozzáférési módjának explicit konfigurálása üzembe helyezés szerint.
Döntési fa megjegyzés #8: Az erőforrás-engedélyek vagy az erőforrás-környezet lehetővé teszi, hogy a felhasználók csak olyan erőforrások naplóit tekinthessék meg, amelyekhez hozzáféréssel rendelkeznek. A munkaterület hozzáférési módjának felhasználói erőforrásra vagy munkaterület-engedélyekre kell állítania. A Microsoft Sentinel Naplók lapján csak azoknak az erőforrásoknak megfelelő táblák jelennek meg, amelyekhez a felhasználó rendelkezik engedélyekkel.
Döntési fa megjegyzés #9: A táblaszintű RBAC lehetővé teszi a Log Analytics-munkaterület adatainak részletesebb vezérlését a többi engedély mellett. Ez a vezérlő lehetővé teszi, hogy meghatározott adattípusokat definiáljon, amelyek csak bizonyos felhasználók számára érhetők el. További információ: Táblaszintű RBAC a Microsoft Sentinelben.
További lépések
Ebben a cikkben áttekintett egy döntési fát, amely segítséget nyújt a Microsoft Sentinel-munkaterület architektúrájának tervezésével kapcsolatos legfontosabb döntések meghozatalában.
Visszajelzés
https://aka.ms/ContentUserFeedback.
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ó:Visszajelzés küldése és megtekintése a következőhöz: