Navrhněte svoji architekturu pracovního prostoru Microsoft Sentinel

  • Článek
  • 11 min ke čtení

Poznámka

Azure Sentinel se teď nazývá Microsoft Sentinel a tyto stránky budeme v nadcházejících týdnech aktualizovat. Přečtěte si další informace o nedávných vylepšeních zabezpečení od Microsoftu.

Tento článek poskytuje rozhodovací strom, který vám pomůže při rozhodování o klíčových rozhodnutích k návrhu vaší architektury Microsoft Sentinel pracovního prostoru. Další informace najdete v tématu návrhy pracovních prostorů ukázek Microsoft Sentinel a osvědčené postupy pro architekturu pracovních prostorů Microsoft Sentinel.

Požadavky

Před prací do rozhodovacího stromu se ujistěte, že máte následující informace:

Požadavek Description
Zákonné požadavky týkající se sídla Azure Data Microsoft Sentinel může běžet v pracovních prostorech ve většině případů, ale ne u všech oblastí podporovaných v GA pro Log Analytics. Nově podporované oblasti Log Analytics můžou nějakou dobu trvat, než se připojí služba Microsoft Sentinel.

Data generovaná službou Microsoft Sentinel, jako jsou incidenty, záložky a analytická pravidla, můžou obsahovat některá zákaznická data, která jsou zdrojem Log Analyticsch pracovních prostorů zákazníka.

Další informace najdete v tématu geografická dostupnost a sídlo dat.
Zdroje dat Zjistěte, které zdroje dat potřebujete připojit, včetně integrovaných konektorů s řešeními Microsoftu i jiných společností. Ke spojování zdrojů dat pomocí nástroje Microsoft Sentinel můžete použít také CEF (Common Event Format), syslog nebo REST API.

Pokud máte virtuální počítače Azure ve více umístěních Azure, ke kterým potřebujete shromažďovat protokoly, a je pro vás důležitá úspora nákladů na výstup dat, je třeba vypočítat náklady na výstup dat pomocí cenové kalkulačky šířky pásma pro každé umístění Azure.
Role uživatelů a úrovně přístupu k datům/oprávnění Microsoft Sentinel používá řízení přístupu na základě role Azure (Azure RBAC) k poskytování integrovaných rolí , které se dají přiřadit uživatelům, skupinám a službám v Azure.

Všechny předdefinované role Microsoft Sentinel udělují přístup pro čtení k datům ve vašem pracovním prostoru Microsoft Sentinel. Proto potřebujete zjistit, jestli je potřeba řídit přístup k datům na zdroj dat nebo na úrovni řádků, protože by to ovlivnilo rozhodnutí o návrhu pracovního prostoru. Další informace najdete v tématech vlastní role a rozšířená RBAC Azure.
Denní rychlost ingestování Denní rychlost ingestování, obvykle v GB za den, je jedním z klíčových faktorů v části cost management a aspekty plánování a návrh pracovního prostoru pro Microsoft Sentinel.

ve většině cloudových a hybridních prostředí jsou k disbraným datům síťová zařízení, jako jsou brány firewall nebo proxy servery a servery Windows a Linux. Aby bylo možné získat nejpřesnější výsledky, společnost Microsoft doporučuje vyčerpávající inventarizaci zdrojů dat.

Kromě toho Kalkulačka nákladů na Microsoft Sentinel obsahuje tabulky užitečné při odhadování množství datových zdrojů.

Důležité: tyto odhady jsou počátečním bodem a nastavení podrobností protokolu a úlohy budou mít za následek odchylky. Doporučujeme vám pravidelně monitorovat systém a sledovat případné změny. Běžné monitorování se doporučuje na základě vašeho scénáře.

Další informace najdete v tématu Správa využití a nákladů pomocí protokolů Azure monitor.

Rozhodovací strom

Následující obrázek ukazuje graf toku celého rozhodovacího stromu, který vám pomůže pochopit, jak nejlépe navrhnout pracovní prostor.

Rozhodovací strom návrhu pracovního prostoru Microsoft Sentinel.

Následující části obsahují fulltextovou verzi tohoto rozhodovacího stromu, včetně následujících poznámek, na které se odkazuje z obrázku:

Poznámka #1 | Poznámka #2 | Poznámka #3 | Poznámka #4 | Poznámka #5 | Poznámka #6 | Poznámka #7 | Poznámka #8 | Poznámka #9 | Poznámka #10

Krok 1: nový nebo existující pracovní prostor?

Máte existující pracovní prostor, který můžete použít pro Microsoft Sentinel?

  • Pokud ne, vytvoříte nový pracovní prostor v jakémkoli případě a budete pokračovat přímo v kroku 2.

  • Pokud už máte pracovní prostor , který byste mohli použít, vezměte v úvahu, kolik dat budete ingestovat.

    • Pokud budete ingestovat víc než 100 GB za den, doporučujeme pro účely cenové efektivity použít samostatný pracovní prostor.

    • Pokud budete ingestovat méně než 100 GB za den, pokračujte krokem 2 pro další vyhodnocení. Tuto otázku můžete znovu zvážit, když nastane v kroku 5.

Krok 2: uchování dat v různých geografických oblastech Azure?

  • Pokud máte zákonné požadavky na uchovávání dat v různých geografických oblastech Azure, použijte samostatný pracovní prostor Microsoft Sentinel pro každou oblast Azure, která splňuje požadavky na dodržování předpisů. Další informace najdete v tématu věnovaném hlediskům oblastí.

  • Pokud nepotřebujete uchovávat data v různých geografických oblastech Azure, pokračujte krokem 3.

Krok 3: máte více tenantů Azure?

  • Pokud máte jenom jednoho tenanta, pokračujte přímo v kroku 4.

  • pokud máte více tenantů Azure, zvažte, jestli shromažďujete protokoly, které jsou specifické pro hranici tenanta, například Office 365 nebo Microsoft 365 Defender.

    • Pokud nemáte žádné protokoly konkrétního tenanta, pokračujte přímo v kroku 4.

    • Pokud shromažďujete protokoly konkrétního tenanta, použijte pro každého tenanta Azure AD samostatný pracovní prostor Microsoft Sentinel. Pokračujte krokem 4 pro další okolnosti.

      poznámka ke stromové struktuře rozhodnutí #1: protokoly specifické pro hranice klientů, jako je například z Office 365 a programu Microsoft Defender pro Cloud, lze ukládat pouze v pracovním prostoru v rámci stejného tenanta.

      I když je možné použít vlastní sběrače ke shromažďování protokolů specifických pro tenanta z pracovního prostoru v jiném tenantovi, nedoporučujeme to kvůli následujícím nevýhodám:

      • Data shromážděná vlastními konektory se ingestují do vlastních tabulek. Proto nebudete moct používat všechna předdefinovaná pravidla a sešity.
      • Vlastní tabulky se nepovažují za některé z vestavěných funkcí, jako jsou UEBA a pravidla strojového učení.
      • Další náklady a úsilí potřebné pro vlastní konektory, jako je například použití Azure Functions a Logic Apps.

      Pokud tyto nevýhody nesouvisejí s vaší organizací, pokračujte krokem 4 místo používání samostatných pracovních prostorů Microsoft Sentinel.

Krok 4: rozdělení fakturace/účtování zpět?

Pokud potřebujete rozdělit fakturaci nebo částku zpět, zvažte, jestli pro vás funguje vytváření sestav využití nebo ruční poplatky za vás.

Krok 5: shromažďování všech dat, která nejsou SOC?

  • Pokud neshromažďujete žádná NESOCá data, jako jsou provozní data, můžete přejít přímo na Krok 6.

  • Pokud shromažďujete data, která nejsou SOC, zvažte, jestli existují nějaké překrytí, kde je stejný zdroj dat nutný pro data SOC i non-SOC.

    Pokud se překrývají mezi SOC a SOC daty, považujte překrývající se data jenom jako SOC data. Pak zvažte, zda příjem dat pro SOC i neSOC data je méně než 100 GB za den, ale více než 100 GB za den v kombinaci:

    • Ano: pokračujte krokem 6 pro další vyhodnocení.
    • Ne: pro účely cenové efektivity nedoporučujeme používat stejný pracovní prostor. Pokračujte krokem 6 pro další vyhodnocení.

    V obou případech najdete další informace v poznámce 10.

    Pokud nepoužíváte žádná překrývající se data, zvažte, zda je individuální zpracování dat pro SOC i neSOCá data menší než 100 GB/den, ale více než 100 GB/den v kombinaci:

    • Ano: pokračujte krokem 6 pro další vyhodnocení. Další informace najdete v poznámce 3.
    • Ne: pro účely cenové efektivity nedoporučujeme používat stejný pracovní prostor. Pokračujte krokem 6 pro další vyhodnocení.

Kombinování dat SOC a non-SOC

Poznámka #3 rozhodovacího stromu: obecně doporučujeme, aby si zákazníci zachovali samostatný pracovní prostor pro svá neSOCá data, aby neSOCcí data nedocházelo k nákladům na sentinelou od společnosti Microsoft, mohou nastat situace, kdy kombinace SOC a SOC dat je levnější než jejich oddělení.

Představte si například organizaci, která má protokoly zabezpečení ingestující se 50 GB za den, protokoly operací, které ingestují do 50 GB za den, a pracovní prostor v oblasti Východní USA.

Následující tabulka porovnává možnosti pracovního prostoru s oddělenými pracovními prostory a bez nich.

Poznámka

Náklady a výrazy uvedené v následující tabulce jsou falešné a používají se jenom pro ilustrativní účely. Aktuální informace o nákladech najdete v cenové kalkulačkě Microsoft Sentinel.

Architektura pracovního prostoru Description
Tým SOC má svůj vlastní pracovní prostor s povolenou službou Microsoft Sentinel.

Tým OPS má svůj vlastní pracovní prostor, a to bez povoleného Microsoft Sentinel.		 SOC tým:
Náklady na 50 GB/den společnosti Microsoft jsou $6 500 měsíčně.
První tři měsíce uchování jsou zdarma.

Tým operace:
– Náklady Log Analytics v 50 GB za den jsou okolo $3 500 měsíčně.
– Prvních 31 dní uchování je zdarma.

Celkové náklady pro obě se rovnají $10 000 za měsíc.
SOC i Operations Teams sdílí stejný pracovní prostor s povoleným Microsoft Sentinel. Kombinací obou protokolů budou ingestování 100 GB za den a nárok na nárok na úroveň závazku (50% pro Sentinel a 15% pro LA).

Náklady na Microsoft Sentinel pro 100 GB za den se rovnají $9 000 za měsíc.

V tomto příkladu byste měli v kombinaci obou pracovních prostorů úsporu $1 000 za měsíc a tým OPS bude mít k dispozici také 3 měsíce volného uchování, nikoli jenom 31 dnů.

Tento příklad je relevantní pouze v případě, že data SOC i non-SOC mají velikost ingestování >= 50 GB/den a <100 GB/den.

Poznámka k rozhodovacímu stromu #10: doporučujeme použít samostatný pracovní prostor pro neSOCá data, aby SOC data nevzniklá na základě nákladů na Microsoft Sentinel.

Nicméně toto doporučení pro samostatné pracovní prostory pro neSOC data pochází z čistě perspektivy založené na nákladech a existují i další klíčové faktory návrhu, které je potřeba prostudovat při určování, jestli se má použít jeden nebo více pracovních prostorů. Aby nedocházelo k dvojitým příjmovým nákladům, zvažte shromažďování překrývajících dat v jednom pracovním prostoru, a to pouze s Azure RBAC na úrovni tabulky.

Krok 6: více oblastí?

  • Pokud shromažďujete protokoly z virtuálních počítačů Azure jenom v jedné oblasti, pokračujte přímo v kroku 7.

  • Pokud shromažďujete protokoly z virtuálních počítačů Azure ve více oblastech, jak vás zajímají náklady na výstup dat?

    Poznámka ke stromu rozhodování #4: Datový výstup odkazuje na náklady na šířku pásma pro přesun dat z datových center Azure. Další informace najdete v tématu věnovaném hlediskům oblastí.

    • Pokud se omezuje množství úsilí potřebného k udržení samostatných pracovních prostorů, pokračujte krokem 7.

    • Pokud náklady na přenos dat jsou dostatečně důležité, aby se zajistilo, že se budou udržovat samostatné pracovní prostory, použijte samostatný pracovní prostor Microsoft Sentinel pro každou oblast, ve které potřebujete snížit náklady na výstup dat.

      Poznámka #5 rozhodovacího stromu: Doporučujeme, abyste měli k dispozici co nejmenší počet pracovních prostorů. Použijte cenovou kalkulačku Azure k odhadu nákladů a určení oblastí, které skutečně potřebujete, a kombinování pracovních prostorů pro oblasti s nízkými náklady na výstup. Náklady na šířku pásma můžou být v porovnání s různými náklady na ingestování Log Analytics a používáním ingest od společnosti Microsoft jenom malé části vaší faktury za Azure.

      Například můžete odhadnout náklady následujícím způsobem:

      • 1 000 virtuálních počítačů, každé generování 1 GB za den;
      • Posílání dat z oblasti USA do oblasti EU;
      • Použití kompresní frekvence 2:1 v agentovi

      Výpočet pro tyto odhadované náklady by byl: 1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost

      Tyto ukázkové náklady by byly mnohem levnější v porovnání s měsíčními náklady na samostatný Microsoft Sentinel a Log Analytics pracovní prostor.

      Poznámka

      Uvedené náklady jsou falešné a používají se jenom pro ilustrativní účely. Aktuální informace o nákladech najdete v cenové kalkulačkě Microsoft Sentinel.

Krok 7: oddělení dat nebo definování hranic podle vlastnictví?

  • Pokud nepotřebujete oddělit data ani definovat hranice vlastnictví, pokračujte přímo v kroku 8.

  • Pokud potřebujete oddělení dat nebo definovat hranice na základě vlastnictví, musí každý vlastník dat používat portál Microsoft Sentinel?

    • Pokud má každý vlastník dat přístup k portálu Microsoft Sentinel, použijte samostatný pracovní prostor Microsoft Sentinel pro každého vlastníka.

      Poznámka ke stromu rozhodování #6: přístup k portálu Microsoft Sentinel vyžaduje, aby měl každý uživatel roli alespoň pro čtecí modul Microsoft Sentinels oprávněním Čtenář pro všechny tabulky v pracovním prostoru. Pokud uživatel nemá přístup ke všem tabulkám v pracovním prostoru, bude muset použít Log Analytics pro přístup k protokolům v vyhledávacích dotazech.

    • Pokud je přístup k protokolům prostřednictvím Log Analytics dostačující pro všechny vlastníky bez přístupu k portálu Microsoft Sentinel, pokračujte krokem 8.

    Další informace najdete v tématu oprávnění v Microsoft Sentinel.

Krok 8: řízení přístupu k datům pomocí zdroje dat/tabulky?

  • Pokud nepotřebujete řídit přístup k datům podle zdroje nebo tabulky, použijte jeden pracovní prostor Microsoft Sentinel.

  • Pokud potřebujete řídit přístup k datům podle zdroje nebo tabulky, zvažte použití správy kontextu prostředků v následujících situacích:

    • Pokud potřebujete řídit přístup na úrovni řádků, jako je například poskytování více vlastníků na každém zdroji dat nebo tabulce

    • Pokud máte více vlastních zdrojů dat/tabulek, kde každá z nich potřebuje samostatná oprávnění

    V ostatních případech, pokud nepotřebujete řídit přístup na úrovni řádků, poskytujete více vlastních zdrojů dat/tabulek s samostatnými oprávněními, použijete jeden pracovní prostor Microsoft Sentinel s nezávisle na úrovni tabulky pro řízení přístupu k datům.

Předpoklady pro RBAC v kontextu prostředků nebo na úrovni tabulky

Při plánování použití RBAC na úrovni kontextu prostředků nebo tabulek Vezměte v úvahu následující skutečnosti:

Další kroky

Příklady tohoto rozhodovacího stromu v praxi najdete v tématu vzory pracovních prostorů ukázek Microsoft Sentinel.

Další informace naleznete v tématu: