Osvědčené postupy architektury pracovních prostorů Microsoft Sentinelu

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.

Při plánování nasazení pracovního prostoru Microsoft Sentinelu musíte také navrhnout architekturu pracovního prostoru služby Log Analytics. Rozhodnutí o architektuře pracovního prostoru se obvykle řídí obchodními a technickými požadavky. Tento článek popisuje klíčové rozhodovací faktory, které vám pomůžou určit správnou architekturu pracovních prostorů pro vaše organizace, včetně:

  • Bez ohledu na to, jestli budete používat jednoho nebo více tenantů
  • Všechny požadavky na dodržování předpisů, které máte pro shromažďování a ukládání dat
  • Řízení přístupu k datům služby Microsoft Sentinel
  • Nákladové důsledky pro různé scénáře

Další informace najdete v tématu Návrh architektury pracovního prostoru Microsoft Sentinelu a Ukázkové návrhy pracovních prostorů pro běžné scénáře a Aktivity před nasazením a požadavky pro nasazení služby Microsoft Sentinel.

Podívejte se na naše video: Architecting SecOps for Success: Best Practices for Deploying Microsoft Sentinel

Důležité informace oancy

Správa menšího počtu pracovních prostorů je jednodušší, ale můžete mít specifické potřeby pro více tenantů a pracovních prostorů. Mnoho organizací má například cloudové prostředí, které obsahuje více tenantů Azure Active Directory (Azure AD),které jsou důsledkem fúzí a akvizic nebo kvůli požadavkům na oddělení identit.

Při určování, kolik tenantů a pracovních prostorů se má použít, zvažte, že většina funkcí Microsoft Sentinelu funguje pomocí jednoho pracovního prostoru nebo instance Microsoft Sentinelu a Microsoft Sentinel ingestuje všechny protokoly, které jsou v pracovním prostoru.

Důležité

Náklady jsou jedním z hlavních faktorů při určování architektury služby Microsoft Sentinel. Další informace najdete v tématu Náklady a fakturace služby Microsoft Sentinel.

Práce s více tenanty

Pokud máte více tenantů, například pokud jste poskytovatel spravované služby zabezpečení (MSSP), doporučujeme vytvořit pro každého tenanta Azure AD alespoň jeden pracovní prostor, který bude podporovat integrované konektory dat mezi službami, které fungují pouze v rámci vlastního tenanta Azure AD.

Všechny konektory založené na nastavení diagnostiky nelze připojit k pracovnímu prostoru, který není umístěný ve stejném tenantovi, ve kterém se prostředek nachází. To platí pro konektory, jako jsou Azure Firewall, Azure Storage, aktivita Azure nebo Azure Active Directory.

Pomocí Azure Lighthouse můžete spravovat více instancí Microsoft Sentinelu v různých tenantech.

Poznámka

Partnerské datové konektory jsou často založené na rozhraní API nebo kolekcích agentů, a proto nejsou připojené ke konkrétnímu tenantovi Azure AD.

Aspekty dodržování předpisů

Po shromažďování, uložení a zpracování vašich dat se může dodržování předpisů stát důležitým požadavkem na návrh s výrazným dopadem na architekturu Microsoft Sentinelu. Schopnost ověřovat a prokazovat, kdo má přístup k jakým datům za všech podmínek, je zásadním požadavkem na suverenitu dat v mnoha zemích a oblastech a posouzení rizik a získání přehledů v pracovních postupech Microsoft Sentinelu je prioritou pro mnoho zákazníků.

V Microsoft Sentinelu se data většinou ukládají a zpracovávají ve stejné geografické oblasti nebo oblasti, s některými výjimkami, například při použití pravidel detekce, která využívají strojové učení Microsoftu. V takových případech mohou být data zkopírována mimo geografickou oblast pracovního prostoru ke zpracování.

Další informace naleznete v tématu:

Pokud chcete začít s ověřováním dodržování předpisů, vyhodnoťte zdroje dat a způsob a kam odesílající data.

Poznámka

Agent Log Analytics podporuje protokol TLS 1.2, aby se zajistilo zabezpečení dat při přenosu mezi agentem a službou Log Analytics a také standard FIPS 140.

Pokud odesíláte data do geografické oblasti nebo oblasti, která se liší od pracovního prostoru Microsoft Sentinelu, bez ohledu na to, jestli se odesílající prostředek nachází v Azure, zvažte použití pracovního prostoru ve stejné geografické oblasti nebo oblasti.

Aspekty oblastí

Pro každou oblast použijte samostatné instance Microsoft Sentinelu. I když se Microsoft Sentinel může používat ve více oblastech, můžete mít požadavky na oddělení dat podle týmu, oblasti nebo webu, předpisů a ovládacích prvků, které znemožní nebo komplikuje modely ve více oblastech, než je potřeba. Použití samostatných instancí a pracovních prostorů pro každou oblast pomáhá vyhnout se nákladům na šířku pásma a odchozí přenos dat při přesunu dat mezi oblastmi.

Při práci s více oblastmi vezměte v úvahu následující:

  • Egress náklady obecně platí, když se ke shromažďování protokolů, například na virtuálních počítačích, vyžaduje Azure Monitor Log Analytics nebo agent služby Log Analytics.

  • Účtují se také poplatky za internetový přenos dat, což vás nemusí ovlivnit, pokud neexportujete data mimo pracovní prostor služby Log Analytics. Pokud například exportujete data Log Analytics na místní server, náklady na přenos dat z internetu se vám účtují.

  • Náklady na šířku pásma se liší v závislosti na zdrojové a cílové oblasti a metodě shromažďování. Další informace naleznete v tématu:

  • Šablony můžete použít pro analytická pravidla, vlastní dotazy, sešity a další prostředky, aby vaše nasazení byla efektivnější. Nasaďte šablony místo ručního nasazení jednotlivých prostředků v každé oblasti.

  • Za konektory založené na nastavení diagnostiky se ne účtuly náklady na šířku pásma. Další informace najdete v tématu Správa využití a nákladů pomocí Azure Monitor protokolů.

Pokud se například rozhodnete shromažďovat protokoly z Virtual Machines v USA – východ a odesílat je do pracovního prostoru Microsoft Sentinelu v USA – západ, budou se vám účtovat poplatky za příchozí přenos dat. Vzhledem k tomu, že agent Log Analytics komprimuje data během přenosu, může být velikost účtovaná za šířku pásma nižší než velikost protokolů v Microsoft Sentinelu.

Pokud shromažďujete protokoly Syslog a CEF z několika zdrojů po celém světě, můžete chtít nastavit kolektor Syslogu ve stejné oblasti jako pracovní prostor Microsoft Sentinelu, abyste se vyhnuli nákladům na šířku pásma, pokud dodržování předpisů není problém.

Vysvětlení, jestli náklady na šířku pásma odůvodňují samostatné pracovní prostory Microsoft Sentinelu, závisí na objemu dat, která potřebujete přenášet mezi oblastmi. K odhadu nákladů použijte cenovou kalkulačku Azure.

Další informace najdete v tématu Rezidence dat v Azure.

Důležité informace o přístupu

Možná máte naplánované situace, kdy budou různé týmy potřebovat přístup ke stejným datům. Například váš tým SOC musí mít přístup ke všem datům Microsoft Sentinelu, zatímco provozní a aplikace budou týmy potřebovat přístup jenom ke konkrétním částem. Nezávislé bezpečnostní týmy mohou také potřebovat přístup k funkcím Microsoft Sentinelu, ale s různými sadami dat.

Zkombinujte RBAC v kontextu prostředků a RBAC na úrovni tabulky, abyste týmům poskytovali širokou škálu možností přístupu, které by měly podporovat většinu případů použití.

Další informace najdete v tématu Oprávnění ve službě Microsoft Sentinel.

Řízení přístupu na základě role v kontextu prostředku

Následující obrázek ukazuje zjednodušenou verzi architektury pracovního prostoru, kde týmy zabezpečení a provozu potřebují přístup k různým sadám dat a K poskytnutí požadovaných oprávnění se používá RBAC v kontextu prostředku.

Diagram ukázkové architektury pro řízení přístupu na základě role v kontextu prostředku

Na tomto obrázku je pracovní prostor Microsoft Sentinelu umístěný v samostatném předplatném, aby bylo možné lépe izolovat oprávnění.

Poznámka

Další možností by bylo umístit Microsoft Sentinel do samostatné skupiny pro správu vyhrazené pro zabezpečení, která zajistí, že se zdědí jenom minimální přiřazení oprávnění. V rámci bezpečnostního týmu je několik skupin přiřazeno oprávnění podle jejich funkcí. Vzhledem k tomu, že tyto týmy mají přístup k celému pracovnímu prostoru, budou mít přístup k úplnému prostředí Microsoft Sentinelu, které jsou omezené jenom rolemi Microsoft Sentinelu, které mají přiřazené. Další informace najdete v tématu Oprávnění ve službě Microsoft Sentinel.

Kromě předplatného zabezpečení se pro týmy aplikací k hostování úloh používá samostatné předplatné. Týmům aplikací je udělen přístup k příslušným skupinám prostředků, kde mohou spravovat své prostředky. Toto samostatné předplatné a řízení přístupu na základě role v kontextu prostředku umožňuje těmto týmům zobrazit protokoly generované prostředky, ke které mají přístup, i když jsou protokoly uložené v pracovním prostoru, kde nemají přímý přístup. Týmy aplikací mají přístup ke svým protokolům prostřednictvím oblasti Protokoly v Azure Portal, kde se zobrazují protokoly pro konkrétní prostředek nebo přes Azure Monitor. Zobrazí se tak všechny protokoly, ke všem protokolům, ke které mají současně přístup.

Prostředky Azure mají integrovanou podporu řízení přístupu na základě role v kontextu prostředku, ale při práci s prostředky mimo Azure mohou vyžadovat další doladění. Další informace najdete v tématu Explicitní konfigurace řízení přístupu na základě role v kontextu prostředku.

Řízení přístupu na základě role (RBAC) na úrovni tabulky

RBAC na úrovni tabulky umožňuje definovat konkrétní datové typy (tabulky), aby byly přístupné pouze pro zadanou sadu uživatelů.

Zvažte například, jestli organizace, jejíž architektura je popsaná na obrázku výše, musí také udělit přístup Office 365 protokolům internímu týmu auditu. V takovém případě můžou pomocí řízení přístupu na úrovni tabulky udělit auditnímu týmu přístup k celé tabulce OfficeActivity bez udělení oprávnění k jakékoli jiné tabulce.

Aspekty přístupu s více pracovními prostory

Pokud máte v rámci vaší organizace různé entity, pobočky nebo zeměpisné oblasti s vlastními bezpečnostními týmy, které potřebují přístup k Microsoft Sentinelu, použijte pro každou entitu nebo pobočku samostatné pracovní prostory. Implementujte samostatné pracovní prostory v rámci jednoho tenanta Azure AD nebo napříč několika tenanty pomocí Azure Lighthouse.

Váš centrální tým SOC může také použít další volitelný pracovní prostor Microsoft Sentinelu ke správě centralizovaných artefaktů, jako jsou analytická pravidla nebo sešity.

Další informace najdete v tématu Zjednodušení práce s více pracovními prostory.

Technické osvědčené postupy pro vytvoření pracovního prostoru

Při vytváření pracovního prostoru služby Log Analytics, který budete používat pro Microsoft Sentinel, použijte následující osvědčené postupy:

  • Při pojmenování pracovního prostoru zahrřte do názvu Microsoft Sentinel nebo nějaký jiný indikátor, abyste ho mohli snadno identifikovat mezi ostatními pracovními prostory.

  • Použijte stejný pracovní prostor pro Microsoft Sentinel i Microsoft Defender for Cloud, aby microsoft Sentinel mohl také ingestovat a používat všechny protokoly shromážděné službou Microsoft Defender for Cloud. Výchozí pracovní prostor vytvořený službou Microsoft Defender for Cloud se nezobrazí jako dostupný pracovní prostor pro Microsoft Sentinel.

  • Vyhrazený cluster pracovních prostorů použijte v případě, že je přibližně 1 TB za den přibližně nebo více než 1 TB dat. Vyhrazený cluster umožňuje zabezpečit prostředky pro data Microsoft Sentinelu, což umožňuje lepší výkon dotazů u velkých datových sad. Vyhrazené clustery také poskytují možnost většího šifrování a kontroly nad klíči vaší organizace.

Zjednodušení práce s více pracovními prostory

Pokud potřebujete pracovat s více pracovními prostory, zjednodušte správu a šetření incidentů tím, že zkrátíte a vyjádřete všechny incidenty z každé instance Microsoft Sentinelu na jednom místě.

Pokud chcete odkazovat na data, která se nachází v jiných pracovních prostorech Microsoft Sentinelu, například v sešitech napříč pracovními prostory, použijte dotazy napříč pracovními prostory.

Nejlepší čas k použití dotazů mezi pracovními prostory je, když jsou cenné informace uložené v jiném pracovním prostoru, předplatném nebo tenantovi a mohou poskytnout hodnotu vaší aktuální akci. Například následující kód ukazuje ukázkový dotaz mezi pracovními prostory:

union Update, workspace("contosoretail-it").Update, workspace("WORKSPACE ID").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification

Další informace najdete v tématu Rozšíření Microsoft Sentinelu mezi pracovní prostory a tenanty.

Další kroky