Návrh architektury pracovního prostoru služby Microsoft Sentinel

Tento článek obsahuje rozhodovací strom, který vám pomůže při rozhodování o tom, jak navrhnout architekturu pracovního prostoru Služby Microsoft Sentinel. Další informace najdete v ukázkových návrzích pracovních prostorů Microsoft Sentinelu a osvědčených postupech architektury pracovního prostoru Microsoft Sentinelu. Tento článek je součástí průvodce nasazením pro Microsoft Sentinel.

Požadavky

Než začnete pracovat s rozhodovacím stromem, ujistěte se, že máte následující informace:

Požadavek	Popis
Zákonné požadavky související s rezidencí dat Azure	Microsoft Sentinel může běžet ve většině pracovních prostorů, ale ne ve všech oblastech podporovaných v ga pro Log Analytics. Nově podporované oblasti Log Analytics můžou nějakou dobu trvat, než se služba Microsoft Sentinel nasadí. Data generovaná službou Microsoft Sentinel, jako jsou incidenty, záložky a analytická pravidla, můžou obsahovat některá zákaznická data zdrojová z pracovních prostorů služby Log Analytics zákazníka. Další informace najdete v tématu Geografická dostupnost a rezidence dat.
Zdroje dat	Zjistěte, které zdroje dat potřebujete připojit, včetně integrovaných konektorů k řešením Microsoftu i jiných společností než Microsoft. K propojení zdrojů dat s Microsoft Sentinelem můžete použít také common event Format (CEF), Syslog nebo REST-API. Pokud máte virtuální počítače Azure ve více umístěních Azure, ze kterých potřebujete shromáždit protokoly, a úspora nákladů na výchozí přenos dat je pro vás důležitá, musíte vypočítat náklady na výchozí přenos 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 nebo oprávnění	Microsoft Sentinel používá řízení přístupu na základě role v Azure (Azure RBAC) k poskytování předdefinovaných rolí , které je možné přiřadit uživatelům, skupinám a službám v Azure. Všechny předdefinované role Microsoft Sentinelu uděluje přístup pro čtení k datům v pracovním prostoru Služby Microsoft Sentinel. Proto je potřeba zjistit, jestli je potřeba řídit přístup k datům podle zdroje dat nebo na úrovni řádků, protože to bude mít vliv na rozhodnutí o návrhu pracovního prostoru. Další informace najdete v tématu Vlastní role a pokročilé řízení přístupu na základě role v Azure.
Denní rychlost příjmu dat	Denní míra příjmu dat, obvykle v GB/den, je jedním z klíčových faktorů při správě nákladů a plánování a návrhu pracovních prostorů pro Microsoft Sentinel. Ve většině cloudových a hybridních prostředí vytvářejí síťová zařízení, jako jsou brány firewall nebo proxy servery, a servery s Windows a Linuxem nejvíce přijatých dat. K získání nejpřesnějších výsledků microsoft doporučuje vyčerpávající inventář zdrojů dat. Alternativně kalkulačka nákladů služby Microsoft Sentinel zahrnuje tabulky užitečné při odhadování nároků na zdroje dat. Důležité: Tyto odhady představují výchozí bod a nastavení podrobností protokolu a zatížení způsobí odchylky. Doporučujeme pravidelně monitorovat systém, abyste mohli sledovat všechny změny. Pravidelné monitorování se doporučuje na základě vašeho scénáře. Další informace najdete v podrobnostech o cenách protokolů služby Azure Monitor.

Rozhodovací strom

Následující obrázek znázorňuje kompletní vývojový diagram rozhodovacího stromu, který vám pomůže pochopit, jak nejlépe navrhnout pracovní prostor.

Následující části obsahují fulltextovou verzi tohoto rozhodovacího stromu, včetně následujících poznámek odkazovaných 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, a v každém případě vytvoříte nový pracovní prostor , pokračujte přímo krokem 2.

• Pokud máte existující pracovní prostor , který můžete použít, zvažte, kolik dat budete ingestovat.

  • Pokud budete ingestovat více než 100 GB za den, doporučujeme pro zajištění nákladové 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 znovu zvažte, jakmile nastane v kroku 5.

Krok 2: Uchovává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 zeměpisných oblastech Azure, použijte samostatný pracovní prostor Služby Microsoft Sentinel pro každou oblast Azure, která má požadavky na dodržování předpisů. Další informace najdete v tématu Aspekty oblasti.

• Pokud nepotřebujete uchovávat data v různých zeměpisný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 krokem 4.

• Pokud máte více tenantů Azure, zvažte, jestli shromažďujete protokoly specifické pro hranici tenanta, jako je Office 365 nebo XDR v programu Microsoft Defender.

  • Pokud nemáte žádné protokoly specifické pro tenanta, pokračujte přímo krokem 4.

  • Pokud shromažďujete protokoly specifické pro tenanta, použijte pro každého tenanta Microsoft Entra samostatný pracovní prostor Služby Microsoft Sentinel. Další důležité informace najdete v kroku 4.

    Poznámka rozhodovacího stromu č. 1: Protokoly specifické pro hranice tenantů, například z Office 365 a Microsoft Defenderu pro cloud, se dají ukládat jenom do pracovního prostoru v rámci stejného tenanta.

    I když je možné použít vlastní kolektory 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 nejsou považovány za některé předdefinované funkce, jako jsou UEBA a pravidla strojového učení.
    • Další náklady a úsilí vyžadované pro vlastní konektory, jako je použití Azure Functions a Logic Apps.

    Pokud tyto nevýhody nejsou pro vaši organizaci důležité, pokračujte krokem 4 místo použití samostatných pracovních prostorů Služby Microsoft Sentinel.

Krok 4: Rozdělení fakturace nebo vrácení poplatku?

Pokud potřebujete rozdělit fakturaci nebo vratku zpět, zvažte, jestli vám sestavy využití nebo ruční křížové poplatky fungují.

• Pokud není potřeba rozdělit fakturaci nebo vratku zpět, pokračujte krokem 5.

• Pokud potřebujete rozdělit fakturaci nebo vratku zpět, zvažte použití ručního křížového poplatku. Pokud chcete získat přesné náklady na entitu, můžete použít upravenou verzi sešitu Nákladů služby Microsoft Sentinel, který rozdělí náklady podle entity.

  • Pokud pro vás funguje generování sestav využití nebo ruční křížové účtování, pokračujte krokem 5.

  • Pokud pro vás nebudou fungovat žádné sestavy využití ani ruční křížové účtování, použijte pro každého vlastníka nákladů samostatný pracovní prostor Služby Microsoft Sentinel.

  Poznámka k rozhodovacímu stromu č. 2: Další informace najdete v tématu Náklady a fakturace služby Microsoft Sentinel.

Krok 5: Shromažďování jakýchkoli dat mimo SOC?

• Pokud neshromažďujete žádná data mimo SOC, jako jsou provozní data, můžete přeskočit přímo ke kroku 6.

• Pokud shromažďujete jiná data než SOC, zvažte, jestli nedošlo k překrývání, kdy je pro data SOC i jiná data než SOC vyžadován stejný zdroj dat.

  Pokud se mezi daty SOC a jiným než SOC překrývají, zacházejte s překrývajícími se daty pouze jako s daty SOC. Pak zvažte, jestli příjem dat SOC i dat mimo SOC jednotlivě je menší než 100 GB za den, ale více než 100 GB / den v kombinaci:

  • Ano: Pokračujte krokem 6 pro další vyhodnocení.
  • Ne: Kvůli efektivitě nákladů 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 nemáte překrývající se data, zvažte, jestli příjem dat soc i dat bez SOC jednotlivě je 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: Kvůli efektivitě nákladů nedoporučujeme používat stejný pracovní prostor. Pokračujte krokem 6 pro další vyhodnocení.

Kombinování dat SOC a jiných než SOC

Poznámka rozhodovacího stromu č. 3: Přestože obecně doporučujeme, aby zákazníci zachovali samostatný pracovní prostor pro data mimo SOC, aby data mimo SOC nebyla předmětem nákladů na Microsoft Sentinel, mohou nastat situace, kdy kombinace dat SOC a jiných než SOC je levnější než jejich oddělení.

Představte si například organizaci, která má protokoly zabezpečení ingestování na 50 GB/den, protokoly operací ingestují 50 GB za den a pracovní prostor v oblasti USA – východ.

Následující tabulka porovnává možnosti pracovního prostoru s samostatnými pracovními prostory a bez těchto samostatných pracovních prostorů.

Poznámka:

Náklady a termíny uvedené v následující tabulce jsou falešné a používají se pouze pro ilustrativní účely. Aktuální informace o nákladech najdete v cenové kalkulačce Microsoft Sentinelu.

Architektura pracovního prostoru	Popis
Tým SOC má vlastní pracovní prostor s povolenou službou Microsoft Sentinel. Tým Ops má svůj vlastní pracovní prostor bez povolené služby Microsoft Sentinel.	Tým SOC: Náklady na Microsoft Sentinel za 50 GB za den jsou 6 500 USD za měsíc. První tři měsíce uchovávání jsou zdarma. Provozní tým: – Náklady na Log Analytics na 50 GB za den jsou přibližně 3 500 USD za měsíc. - Prvních 31 dnů uchovávání je zdarma. Celkové náklady na oba se rovnají 10 000 USD za měsíc.
Týmy SOC i Ops sdílejí stejný pracovní prostor s povolenou službou Microsoft Sentinel.	Zkombinováním obou protokolů bude příjem dat 100 GB za den a nárok na úroveň závazku (50 % pro Sentinel a 15 % pro LA). Náklady na Microsoft Sentinel za 100 GB za den se rovnají 9 000 USD za měsíc.

V tomto příkladu byste měli úsporu nákladů 1 000 USD za měsíc kombinací obou pracovních prostorů a provozní tým bude mít místo jenom 31 dnů bezplatné uchovávání 3 měsíce.

Tento příklad je relevantní jenom v případě, že data SOC i jiná data než SOC mají velikost >příjmu dat = 50 GB za den a <100 GB za den.

Poznámka k rozhodovacímu stromu č. 10: Doporučujeme použít samostatný pracovní prostor pro jiná data než SOC, aby data mimo SOC nebyla předmětem nákladů na Microsoft Sentinel.

Toto doporučení pro samostatné pracovní prostory pro jiná data než SOC však pochází z čistě nákladového hlediska a existují další klíčové faktory návrhu, které je potřeba prozkoumat při určování, jestli se má použít jeden nebo více pracovních prostorů. Pokud se chcete vyhnout dvojím nákladům na příjem dat, zvažte shromažďování překrývajících se dat v jednom pracovním prostoru pouze s azure RBAC na úrovni tabulky.

Krok 6: Více oblastí?

• Pokud shromažďujete protokoly pouze z virtuálních počítačů Azure v jedné oblasti, pokračujte přímo krokem 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ýchozí přenos dat?

  Poznámka rozhodovacího stromu č. 4: Výchozí přenos dat odkazuje na náklady na šířku pásma pro přesun dat z datacenter Azure. Další informace najdete v tématu Aspekty oblasti.

  • Pokud je prioritou snížení množství úsilí potřebného k údržbě samostatných pracovních prostorů, pokračujte krokem 7.

  • Pokud jsou náklady na výchozí přenos dat dostatečně důležité, aby se zachovaly samostatné pracovní prostory, použijte samostatný pracovní prostor Microsoft Sentinelu pro každou oblast, kde potřebujete snížit náklady na výchozí přenos dat.

    Poznámka rozhodovacího stromu č. 5: Doporučujeme, abyste měli co nejméně pracovních prostorů. Pomocí cenové kalkulačky Azure můžete odhadnout náklady a určit, které oblasti skutečně potřebujete, a kombinovat pracovní prostory pro oblasti s nízkými náklady na výchozí přenos dat. Náklady na šířku pásma můžou být v porovnání s samostatnými náklady na příjem dat služby Microsoft Sentinel a Log Analytics pouze malou částí faktury za Azure.

    Například náklady se můžou odhadnout takto:

    • 1 000 virtuálních počítačů, každý generuje 1 GB za den;
    • Odesílání dat z oblasti USA do oblasti EU;
    • Použití komprese 2:1 v agentu

    Výpočet těchto odhadovaných nákladů: 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 samostatného pracovního prostoru Služby Microsoft Sentinel a Služby Log Analytics.

    Poznámka:

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

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

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

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

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

    Poznámka rozhodovacího stromu č. 6: Přístup k portálu Microsoft Sentinel vyžaduje, aby každý uživatel měl roli alespoň čtenáře Microsoft Sentinelu s oprávněními čtenáře 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 k přístupu k protokolům v vyhledávacích dotazech použít Log Analytics.

  • Pokud přístup k protokolům prostřednictvím Log Analytics stačí 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 Sentinelu.

Krok 8: Řízení přístupu k datům podle zdroje dat nebo tabulky?

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

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

  • Pokud potřebujete řídit přístup na úrovni řádku, například poskytnout více vlastníků pro každý zdroj dat nebo tabulku

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

  Pokud v jiných případech nepotřebujete řídit přístup na úrovni řádku, zadejte více vlastních zdrojů dat nebo tabulek s samostatnými oprávněními, použijte pro řízení přístupu k datům jeden pracovní prostor Služby Microsoft Sentinel s řízením přístupu na úrovni tabulky.

Důležité informace o řízení přístupu na úrovni prostředků nebo na úrovni tabulky

Při plánování použití řízení přístupu na úrovni prostředků nebo na úrovni tabulky zvažte následující informace:

• Poznámka k rozhodovacímu stromu č. 7: Pokud chcete nakonfigurovat řízení přístupu na základě role na základě kontextu prostředku pro prostředky mimo Azure, můžete při odesílání do Služby Microsoft Sentinel přidružit ID prostředku k datům, aby bylo možné oprávnění vymezit pomocí řízení přístupu na základě kontextu prostředku. Další informace najdete v tématu Explicitní konfigurace režimů řízení přístupu na základě role a přístupu v kontextu prostředků podle nasazení.

• Poznámka rozhodovacího stromu č. 8: Oprávnění k prostředkům nebo kontext prostředků umožňují uživatelům zobrazit protokoly pouze pro prostředky, ke kterým mají přístup. Režim přístupu k pracovnímu prostoru musí být nastavený na uživatelský prostředek nebo oprávnění pracovního prostoru. Do výsledků hledání na stránce Protokoly v Microsoft Sentinelu se zahrnou jenom tabulky relevantní pro prostředky, ve kterých má uživatel oprávnění.

• Poznámka rozhodovacího stromu č. 9: Řízení přístupu na úrovni tabulky umožňuje definovat podrobnější řízení dat v pracovním prostoru služby Log Analytics kromě dalších oprávnění. Tento ovládací prvek umožňuje definovat konkrétní datové typy, které jsou přístupné pouze konkrétní sadě uživatelů. Další informace najdete v tématu Řízení přístupu na úrovni tabulky v Microsoft Sentinelu.

Další kroky

V tomto článku jste si prostudovali rozhodovací strom, který vám pomůže při rozhodování o návrhu architektury pracovního prostoru Microsoft Sentinelu.

Ukázkové návrhy pracovních prostorů služby Microsoft Sentinel