Osvědčené postupy pro architekturu pracovního prostoru služby Microsoft Sentinel

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

  • Bez ohledu na to, jestli budete používat jednoho tenanta 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 Microsoft Sentinelu
  • Dopad na náklady pro různé scénáře

Další informace najdete v tématu Návrh architektury pracovního prostoru Služby Microsoft Sentinel a vzorových návrhů pracovních prostorů pro běžné scénáře a aktivity předběžného nasazení a požadavky pro nasazení služby Microsoft Sentinel.

Podívejte se na naše video: Navrhování secOps pro úspěch: Osvědčené postupy pro nasazení služby Microsoft Sentinel.

Tento článek je součástí průvodce nasazením pro Microsoft Sentinel.

Aspekty tenantů

Méně pracovních prostorů je sice jednodušší spravovat, ale možná budete 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ů Microsoft Entra, které jsou výsledkem fúze a akvizice nebo kvůli požadavkům na oddělení identit.

Při určování počtu tenantů a pracovních prostorů, které se mají použít, vezměte v úvahu, ž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 součástí pracovního prostoru.

Náklady jsou jedním z hlavních aspektů při určování architektury Microsoft Sentinelu. 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 poskytovatelem spravované služby zabezpečení (MSSP), doporučujeme vytvořit alespoň jeden pracovní prostor pro každého tenanta Microsoft Entra, který podporuje integrované datové konektory service to service, které fungují jenom v rámci vlastního tenanta Microsoft Entra.

Všechny konektory založené na nastavení diagnostiky se nedají 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 je Azure Firewall, Azure Storage, aktivita Azure nebo ID Microsoft Entra.

Azure Lighthouse vám pomůže spravovat více instancí Služby Microsoft Sentinel 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 Microsoft Entra.

Úvahy o dodržování předpisů

Po shromáždění, uložení a zpracování dat se dodržování předpisů může stát důležitým požadavkem na návrh s významným dopadem na architekturu Microsoft Sentinelu. Schopnost ověřovat a prokázat, kdo má přístup k datům za všech podmínek, je kritickým požadavkem suverenity 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ů.

Ve službě Microsoft Sentinel se data většinou ukládají a zpracovávají ve stejné zeměpisné 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 se data můžou zkopírovat mimo geografickou oblast pracovního prostoru ke zpracování.

Další informace naleznete v tématu:

Pokud chcete začít ověřovat dodržování předpisů, vyhodnoťte zdroje dat a zjistěte, jak a kam odesílají data.

Poznámka:

Agent Log Analytics podporuje protokol TLS 1.2, aby zajistil zabezpečení přenášených dat mezi agentem a službou Log Analytics a standardem FIPS 140.

Pokud odesíláte data do zeměpisné 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é zeměpisné oblasti nebo oblasti.

Aspekty oblastí

Pro každou oblast používejte samostatné instance Služby Microsoft Sentinel. Microsoft Sentinel je sice možné použít ve více oblastech, ale možná budete mít požadavky na oddělení dat podle týmu, oblasti nebo webu nebo předpisů a kontrol, které znemožňují nebo složitější modely s více oblastmi, 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 výchozí přenos dat pro přesun dat napříč oblastmi.

Při práci s více oblastmi zvažte následující skutečnosti:

Pokud se například rozhodnete shromažďovat protokoly z virtuálních počítačů v oblasti USA – východ a odesílat je do pracovního prostoru Služby Microsoft Sentinel v oblasti USA – západ, budou se vám účtovat náklady na příchozí přenos dat. Vzhledem k tomu, že agent Log Analytics komprimuje přenášená data, 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 více zdrojů po celém světě, můžete chtít nastavit kolektor Syslog ve stejné oblasti jako pracovní prostor Služby Microsoft Sentinel, abyste se vyhnuli nákladům na šířku pásma za předpokladu, že dodržování předpisů není problém.

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

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

Aspekty 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í týmy a týmy aplikací budou potřebovat přístup jenom ke konkrétním částem. Nezávislé bezpečnostní týmy můžou také potřebovat přístup k funkcím Microsoft Sentinelu, ale s různými sadami dat.

Zkombinujte řízení přístupu na úrovni prostředků a řízení přístupu na úrovni tabulky a poskytněte týmům š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í v Microsoft Sentinelu.

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

Následující obrázek znázorňuje zjednodušenou verzi architektury pracovního prostoru, kde bezpečnostní a provozní týmy potřebují přístup k různým sadám dat, a řízení přístupu na základě role v kontextu prostředků se používá k poskytnutí požadovaných oprávnění.

Diagram of a sample architecture for resource-context RBAC.

Na tomto obrázku se pracovní prostor Microsoft Sentinelu umístí do samostatného předplatného, aby se lépe izolovala oprávnění.

Poznámka:

Další možností je umístit Microsoft Sentinel do samostatné skupiny pro správu, která je vyhrazená pro zabezpečení, což by zajistilo, že se zdědí pouze minimální přiřazení oprávnění. V rámci bezpečnostního týmu je podle jejich funkcí přiřazeno několik skupin. 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 omezené jenom rolemi Microsoft Sentinelu, které přiřazují. Další informace najdete v tématu Oprávnění v Microsoft Sentinelu.

Kromě předplatného zabezpečení se pro týmy aplikací používá samostatné předplatné k hostování úloh. Týmům aplikací je udělen přístup ke svým příslušným skupinám prostředků, kde můžou spravovat své prostředky. Toto samostatné předplatné a řízení přístupu na základě prostředků umožňuje těmto týmům zobrazit protokoly vygenerované všemi prostředky, ke kterým 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 k protokolům prostřednictvím oblasti Protokolů na webu Azure Portal, k zobrazení protokolů pro konkrétní prostředek nebo přes Azure Monitor, aby zobrazily všechny protokoly, ke kterým mají přístup současně.

Prostředky Azure mají integrovanou podporu řízení přístupu na základě role na základě kontextu prostředků, ale při práci s prostředky mimo Azure můžou vyžadovat další vyladě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

Řízení přístupu na úrovni tabulky umožňuje definovat konkrétní datové typy (tabulky), které budou přístupné jenom 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 k protokolům Office 365 internímu týmu auditu. V takovém případě můžou pomocí řízení přístupu na úrovni tabulky udělit týmu auditu přístup k celé tabulce OfficeActivity , aniž by udělili oprávnění k jakékoli jiné tabulce.

Aspekty přístupu s několika pracovními prostory

Pokud máte v organizaci různé entity, pobočky nebo zeměpisné oblasti, každý z nich má vlastní bezpečnostní týmy, které potřebují přístup k Microsoft Sentinelu, použijte pro každou entitu nebo dceřinou společnost samostatné pracovní prostory. Implementujte samostatné pracovní prostory v rámci jednoho tenanta Microsoft Entra nebo napříč několika tenanty pomocí Azure Lighthouse.

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 vytvář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í doporučené postupy:

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

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

  • Cluster vyhrazeného pracovního prostoru použijte v případě, že se váš předpokládaný příjem dat pohybuje kolem nebo více než 1 TB za den. Vyhrazený cluster umožňuje zabezpečit prostředky pro data Microsoft Sentinelu, což umožňuje lepší výkon dotazů pro velké datové sady. Vyhrazené clustery také poskytují možnost pro větší šifrování a kontrolu nad klíči vaší organizace.

Nepoužívejte zámek prostředků na pracovní prostor služby Log Analytics, který použijete pro Microsoft Sentinel. Zámek prostředku v pracovním prostoru může způsobit selhání mnoha operací Microsoft Sentinelu.

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 vyšetřování incidentů tím, že zkondenzujete a vypisujete všechny incidenty z každé instance Služby Microsoft Sentinel v jednom umístění.

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

Nejvhodnější doba pro 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 můžou vaší aktuální akci poskytnout hodnotu. 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í služby Microsoft Sentinel mezi pracovními prostory a tenanty.

Další kroky

V tomto článku jste se seznámili s klíčovými rozhodovacími faktory, které vám pomůžou určit správnou architekturu pracovního prostoru pro vaše organizace.