Tento článek popisuje, jak automatizovat operace integrace a nasazení Služby Microsoft Sentinel pomocí Azure DevOps. Azure DevOps implementujete pomocí funkcí Microsoft Sentinelu, které vám pomůžou zabezpečit nasazení. Pak použijete architekturu DevSecOps ke správě a nasazení artefaktů Služby Microsoft Sentinel ve velkém měřítku.
Architektura
Následující diagram znázorňuje nastavení Azure DevOps a Microsoft Sentinel IaC.
Stáhněte si soubor aplikace Visio s touto architekturou.
Tok dat
- Hlavní scrum a správa produktů používají Azure DevOps k definování námětů, uživatelských scénářů a položek backlogu produktů v rámci backlogu projektu.
- Hlavní scrum a správa produktů používají Azure Boards k vytvoření backlogu, plánování práce ve sprintech, kontrole panelu projektu, vytvoření struktury úložiště a nastavení pravidel zabezpečení, jako jsou pracovní postupy schválení a větve.
- Úložiště Azure Git ukládá skripty a umožňuje spravovat artefakty Služby Microsoft Sentinel v infrastruktuře jako kód.
- Artefakty a správa zdrojového kódu udržují rozšíření a balíčky aktualizací nebo komponenty pracovního postupu DevSecOps, které se používají v řešení, jako je sada nástrojů šablon Azure Resource Manageru a Pester PowerShellu.
- Artefakty Microsoft Sentinelu:
- Zásady: Technici SIEM používají zásady Azure v referenční architektuře ke konfiguraci a škálování nastavení diagnostiky služeb Azure. Zásady pomáhají automatizovat nasazení datových konektorů Microsoft Sentinelu, jako je Azure Key Vault. Zásady jsou závislé na rozhraní API OMSIntegration.
- Konektory. Microsoft Sentinel používá logické konektory, datové konektory Azure k ingestování dat zabezpečení, jako jsou audity nebo metriky, z podporovaných zdrojů dat, jako jsou ID Microsoft Entra, prostředky Azure, Microsoft Defender nebo řešení třetích stran. Hlavní seznam datových konektorů spravuje rozhraní SecurityInsights API. Ostatní spoléhají na rozhraní OMSIntegration API a spravují se pomocí nastavení diagnostiky služby Azure Policy.
- Spravovaná identita Microsoft Sentinel používá spravovanou identitu k jednání jménem identity spravované služby (MSI) při interakci s playbooky, aplikacemi logiky nebo runbooky automatizace a trezorem klíčů.
- Automatizace. Týmy SOC používají automatizaci během vyšetřování. Týmy SOC spouštějí postupy získávání digitálních forenzních dat pomocí služby Azure Automation, jako je řetězec opatrovnictví virtuálního počítače Azure nebo eDiscovery (Premium) pro Microsoft Defender.
- Analýza. Analytici SOC nebo lovci hrozeb používají předdefinovaná nebo vlastní analytická pravidla k analýze a korelaci dat v Microsoft Sentinelu nebo k aktivaci playbooků v případě identifikace hrozby a incidentu.
- Playbooky. Aplikace logiky spouštějí opakovatelné akce SecOps, jako je přiřazení incidentu, aktualizace incidentu nebo provádění nápravných akcí, jako je izolace nebo obsahující virtuální počítač, odvolání tokenu nebo resetování hesla uživatele.
- Proaktivně vyhledávat hrozby Lovci hrozeb používají proaktivní možnosti proaktivního vyhledávání hrozeb, které je možné spojit s poznámkovými bloky Jupyter pro pokročilé případy použití, jako je zpracování dat, manipulace s daty, vizualizace dat, strojové učení nebo hluboké učení.
- Sešity. Technici SIEM používají řídicí panely Workbooks k vizualizaci trendů a statistik a k zobrazení stavu instance Služby Microsoft Sentinel a jejích dílčích součástí.
- Analýza hrozeb: Konkrétní datový konektor, který provází platformy analýzy hrozeb, se používá k microsoft Sentinelu. Podporují se dvě metody připojení: TAXII a Graph API. Obě metody slouží jako tiIndicators nebo indikátory analýzy hrozeb v rozhraních API zabezpečení.
- Microsoft Entra ID. Funkce správy identit a přístupu se doručují do komponent, které se používají v referenční architektuře, jako jsou spravované identity, instanční objekty, řízení přístupu na základě role v Azure (RBAC) pro Microsoft Sentinel, aplikace logiky a runbooky automatizace.
- Azure Pipelines. Technici DevOps používají kanály k vytváření připojení služeb pro správu různých předplatných Azure, jako je sandbox a produkční prostředí s kanály kontinuální integrace a průběžného doručování (CI/CD). Pokud cílíte na více předplatných na prostředí Azure, doporučujeme používat pracovní postupy schvalování, abyste zabránili neočekávaným nasazením a odděleným instančním objektům.
- Azure Key Vault. Technici SOC používají trezor klíčů k bezpečnému ukládání tajných kódů a certifikátů instančního objektu. Tato komponenta architektury pomáhá vynucovat princip DevSecOps bez tajných kódů v kódu při použití připojení služby Azure Pipeline.
- Předplatné Azure. Týmy SOC používají v této referenční architektuře dvě instance Služby Microsoft Sentinel oddělené ve dvou logických předplatných Azure k simulaci produkčního a sandboxového prostředí. Škálovat můžete podle svých potřeb s jinými prostředími, jako jsou testování, vývoj, předprodukční prostředí atd.
Příklad toku dat
- Správce přidá, aktualizuje nebo odstraní položku ve svém forku konfiguračního souboru Microsoftu 365.
- Správce potvrdí a synchronizuje změny do svého rozvětvovaného úložiště.
- Správce pak vytvoří žádost o přijetí změn pro sloučení změn v hlavním úložišti.
- Kanál buildu běží v žádosti o přijetí změn.
Komponenty
- Microsoft Entra ID je cloudová služba pro správu identit a řízení přístupu.
- Azure DevOps je cloudová služba, která umožňuje spolupracovat na kódu, sestavovat a nasazovat aplikace nebo plánovat a sledovat vaši práci.
- Azure Key Vault je cloudová služba pro bezpečné ukládání tajných kódů a přístup k nim. Tajný kód je vše, co chcete pevně řídit přístup, jako jsou klíče rozhraní API, hesla, certifikáty nebo kryptografické klíče.
- Azure Policy je služba pro vytváření, přiřazování a správě definic zásad ve vašem prostředí Azure.
- Microsoft Sentinel je škálovatelné, nativní cloudové řešení, SIEM a orchestrace zabezpečení, automatizace a reakce (SOAR).
- Azure Automation je služba pro zjednodušení správy cloudu prostřednictvím automatizace procesů. Azure Automation slouží k automatizaci dlouhotrvajících, ručních, náchylných chyb a často opakovaných úloh. Automatizace pomáhá zlepšit spolehlivost, efektivitu a čas pro vaši společnost.
Podrobnosti scénáře
Týmy soc (Security Operations Center) někdy čelí problémům, když integrují Microsoft Sentinel s Azure DevOps. Proces zahrnuje mnoho kroků a instalace může trvat dny a zahrnovat opakování. Tuto část vývoje můžete automatizovat.
Aby technici mohli modernizovat cloud, musí neustále učit nové dovednosti a techniky pro zabezpečení a ochranu důležitých obchodních prostředků. Technici musí vytvářet robustní a škálovatelná řešení, která udržují krok s měnícím se zabezpečením a obchodními potřebami. Řešení zabezpečení musí být flexibilní, agilní a pečlivě plánované od nejstarších fází vývoje. Tato metodologie prvotního plánování se označuje jako posun doleva.
Tento článek popisuje, jak automatizovat operace integrace a nasazení Služby Microsoft Sentinel pomocí Azure DevOps. Řešení můžete rozšířit pro složité organizace s více entitami, předplatnými a různými provozními modely. Mezi provozní modely podporované tímto řešením patří místní SOC, globální SOC, poskytovatel cloudových služeb (CSP) a spravovaný poskytovatel služeb zabezpečení (MSSP).
Tento článek je určený pro následující cílové skupiny:
- Specialisté SOC, jako jsou analytici a lovci hrozeb
- Technici pro správu informací o zabezpečení a událostí (SIEM)
- Architekti kybernetické bezpečnosti
- Vývojáři
Potenciální případy použití
Toto jsou typické případy použití pro tuto architekturu:
- Rychlé vytváření prototypů a testování konceptu. Toto řešení je ideální pro organizace zabezpečení a týmy SOC, které chtějí zlepšit pokrytí cloudových hrozeb nebo modernizovat infrastrukturu SIEM s infrastrukturou jako kódem (IaC) a Microsoft Sentinelem.
- Microsoft Sentinel jako služba. Tato vývojová architektura integruje principy správy životního cyklu služeb. Tyto principy vyhovují jednoduchým nebo složitým týmům, jako jsou MSSP, kteří spouštějí opakovatelné standardizované akce napříč více tenanty zákazníků a současně kombinují výkon Azure DevOps a Azure Lighthouse. Tento řešení by mohl použít například tým, který potřebuje publikovat případy použití služby Microsoft Sentinel pro nového aktéra hrozeb nebo probíhající kampaň.
- Vytváření případů použití SOC pro detekci hrozeb Mnoho skupin a platforem analýzy hrozeb využívá obsah a taxonomii MITRE Att&ck k analýze stavu zabezpečení proti pokročilým obchodním postupům nebo technikám a postupům a taktikám. Řešení definuje strukturovaný přístup pro vývoj technik detekce hrozeb tím, že do vývoje artefaktů Microsoft Sentinelu začlení terminologii MITRE Att&ck.
Následující obrázek ukazuje scénář cloudu MITRE Att&ck.
Stáhněte si soubor aplikace Visio s touto architekturou.
Scénáře útoku na definici hrozeb založené na MITRE
Tato tabulka ukazuje termíny, definice a podrobnosti důležitých aspektů scénářů útoku.
| Datová položka | Popis | Artefakty Microsoft Sentinelu |
|---|---|---|
| Nadpis | Popisný název scénáře útoku na základě charakteristik vektoru útoku nebo popisu techniky. | Manifest MITRE |
| Taktika MITRE ATT&CK | Taktika MITRE ATT&CK související se scénářem útoku | Manifest MITRE |
| Techniky MITRE ATT&CK | Techniky MITRE ATT&CK, včetně techniky nebo ID dílčí techniky související se scénářem útoku. | Manifest MITRE |
| Zdroje datových konektorů | Zdroj informací shromážděných senzorem nebo systémem protokolování, který může být použit ke shromažďování informací relevantních k identifikaci prováděné akce, posloupnosti akcí nebo výsledků těchto akcí nežádoucí osobou. | Datový konektor Microsoft Sentinelu nebo vlastní zdroj protokolů |
| Popis | Informace o technice, o tom, k čemu se obvykle používá, jak ho může nežádoucí osoba využít, a varianty, jak se dá použít. Obsahuje odkazy na autoritativní články popisující technické informace související s technikou a také odkazy na zástupné použití podle potřeby. | |
| Detection | Analytické procesy vysoké úrovně, senzory, data a strategie detekce užitečné při identifikaci techniky používané nežádoucí osobou. Tato část informuje ty, kteří zodpovídají za zjišťování nežádoucího chování, jako jsou například ochrana sítě, aby mohli provést akci, jako je napsání analytické analýzy nebo nasazení senzoru. Měly by existovat dostatek informací a odkazů, které by ukazovaly na užitečné obranné metodologie. Detekce nemusí být vždy možná pro určitou techniku a měla by být zdokumentovaná jako taková. | Analýza proaktivního vyhledávání hrozeb |
| Zmírnění | Konfigurace, nástroje nebo procesy, které brání tomu, aby technika fungovala nebo měla požadovaný výsledek pro nežádoucí osobu. Tato část informuje ty, kteří zodpovídají za zmírnění rizik nežádoucích osob, jako jsou ochrana sítě nebo tvůrci zásad, aby mohli provést akci, jako je změna zásady nebo nasazení nástroje. Zmírnění rizik nemusí být vždy možné pro danou techniku a mělo by být zdokumentované jako takové. | |
| Zmírnění | Konfigurace, nástroje nebo procesy, které brání tomu, aby technika fungovala nebo měla požadovaný výsledek pro nežádoucí osobu. Tato část popisuje, jak zmenšit účinky nežádoucích útoků na ochranu sítě nebo tvůrce zásad. Popisuje kroky pro změnu zásady nebo nasazení nástroje. Zmírnění rizik nemusí být vždy možné pro určitou techniku a mělo by být zdokumentované jako takové. | Playbooky, runbooky automatizace |
Důležité informace
Tyto aspekty implementují pilíře dobře architektuře Azure, sadu hlavních principů, které můžete použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.
Zabezpečení
Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v tématu Přehled pilíře zabezpečení.
Obecně platí, že automatizace zvyšuje efektivitu provozu a šetří čas u složitějších případů použití, jako jsou techniky detekce hrozeb, analýzy hrozeb, SOC a případy použití SOAR. Týmy DevOps potřebují vědět, kde můžou bezpečně používat IaC v kontextu CI/CD služby Microsoft Sentinel. Tento proces zavádí použití konkrétních identit, které jsou používány jinými než lidskými účty v Microsoft Entra ID označované jako instanční objekty a spravované identity.
Následující tabulka shrnuje aspekty zabezpečení pro instanční objekty a hlavní případy použití, na které se vztahují kanály verze Microsoft Sentinel a Azure DevOps.
| Případ použití | Požadavky (nejnižší oprávnění) | Doba trvání přiřazení role | Obor oprávnění | Správce | Bezpečnostní aspekty |
|---|---|---|---|---|---|
| Povolení konektorů Microsoft Sentinelu | Správce zabezpečení** Vlastník* Přispěvatel Microsoft Sentinelu Čtenář |
JIT (jednorázová aktivace) Pro účely (pokaždé, když se nasadí nové předplatné a konektor) |
Tenant | Hlavní název služby (SPN) | Trezor klíčů použijte k ukládání tajných kódů a certifikátů hlavního názvu služby (SPN). Povolte auditování hlavního názvu služby (SPN). Pravidelně zkontrolujte přiřazení oprávnění (Azure Privileged Identity Management pro SPN) nebo podezřelou aktivitu hlavního názvu služby (SPN). Pro privilegované účty používejte certifikační autority Microsoft Entra a vícefaktorové ověřování (pokud je podporováno). Pro větší členitost použijte vlastní role Microsoft Entra. |
| Nasazení artefaktů Microsoft Sentinelu, jako jsou sešity, analýzy, pravidla, dotazy proaktivního vyhledávání hrozeb, poznámkové bloky a playbooky | Přispěvatel Microsoft Sentinelu Přispěvatel Logic Apps |
Trvale | Pracovní prostor nebo skupina prostředků služby Microsoft Sentinel | Hlavní název služby (SPN) | Schválení pracovního postupu Azure DevOps (ADO) a kontroly k zabezpečení nasazení kanálu pomocí tohoto hlavního názvu služby (SPN) |
| Přiřazení zásad pro konfiguraci funkcí streamování protokolů do Microsoft Sentinelu | Přispěvatel zásad prostředků ** | Pro účely (pokaždé, když se nasadí nové předplatné a konektor) | Všechna předplatná, která se mají monitorovat | Hlavní název služby (SPN) | Pro privilegované účty používejte ID Microsoft Entra, CA a MFA. |
* Týká se pouze nastavení diagnostiky Microsoft Entra.
** Konkrétní konektory potřebují další oprávnění, jako je "správce zabezpečení" nebo přispěvatel zásad prostředků, aby bylo možné streamovat data do pracovního prostoru Služby Microsoft Sentinel, Microsoft Entra ID, Microsoft 365 nebo Microsoft Defender a prostředků PaaS (Platforma jako služba), jako je Azure Key Vault.
Model privilegovaného přístupu
Doporučujeme přijmout strategii modelu privilegovaného přístupu, která rychle sníží rizika pro vaši společnost z vysoce ovlivněných a vysoce pravděpodobnostných útoků na privilegovaný přístup. V případě automatických procesů v modelu DevOps založte identitu na identitách instančního objektu .
Privilegovaný přístup by měl být nejvyšší prioritou zabezpečení každé společnosti. Jakékoli ohrožení těchto identit vytváří vysoce negativní dopady. Privilegované identity mají přístup k důležitým podnikovým prostředkům, což téměř vždy způsobuje velký dopad, když útočníci napadnou tyto účty.
Zabezpečení privilegovaného přístupu je velmi důležité, protože je základem všech ostatních bezpečnostních záruk. Útočník, který má kontrolu nad vašimi privilegovanými účty, může podkopávat všechny ostatní záruky zabezpečení.
Z tohoto důvodu doporučujeme logicky rozšířit instanční objekty do různých úrovní nebo úrovní podle principu minimálních oprávnění. Následující obrázek ukazuje, jak klasifikovat instanční objekty v závislosti na typu přístupu a požadovaném přístupu.
Instanční objekty úrovně 0
Instanční objekty úrovně 0 mají nejvyšší úroveň oprávnění. Tyto instanční objekty mají nárok na provádění úloh správy celé tenanta nebo kořenové skupiny pro správu jako globální správce.
Z bezpečnostních důvodů a možností správy doporučujeme, abyste pro tuto úroveň měli pouze jeden instanční objekt. Oprávnění pro tento instanční objekt se zachovají, proto doporučujeme udělit pouze minimální požadovaná oprávnění a ponechat účet monitorovaný a zabezpečený.
Bezpečně uložte tajný klíč nebo certifikát pro tento účet ve službě Azure Key Vault. Důrazně doporučujeme, abyste trezor klíčů našli ve vyhrazeném předplatném pro správu, pokud je to možné.
Instanční objekty úrovně 1
Instanční objekty úrovně 1 jsou zvýšená oprávnění omezená a omezená na skupiny pro správu na úrovni obchodní organizace. Tyto instanční objekty mají nárok na vytváření předplatných v rámci skupiny pro správu, která je v oboru.
Z bezpečnostních důvodů a možností správy doporučujeme, abyste pro tuto úroveň měli pouze jeden instanční objekt. Oprávnění pro tento instanční objekt se zachovají, proto důrazně doporučujeme udělit pouze minimální požadovaná oprávnění a ponechat účet monitorovaný a zabezpečený.
Bezpečně uložte tajný klíč nebo certifikát pro tento účet ve službě Azure Key Vault. Důrazně doporučujeme, abyste trezor klíčů našli ve vyhrazeném předplatném pro správu, pokud je to možné.
Instanční objekty úrovně 2
Instanční objekty úrovně 2 jsou omezené na úroveň předplatného. Tyto instanční objekty mají nárok na provádění úloh správy v rámci předplatného, které fungují jako vlastník předplatného.
Z bezpečnostních důvodů a možností správy doporučujeme, abyste pro tuto úroveň měli pouze jeden instanční objekt. Oprávnění pro tento instanční objekt se zachovají, proto důrazně doporučujeme udělit pouze minimální požadovaná oprávnění a udržovat účet monitorovaný a zabezpečený.
Bezpečně uložte tajný klíč nebo certifikát pro tento účet ve službě Azure Key Vault. Důrazně doporučujeme najít trezor klíčů ve vyhrazené skupině prostředků pro správu.
Instanční objekty úrovně 3
Instanční objekty úrovně 3 jsou omezené na správce úloh. V typickém scénáři se každá úloha nachází ve stejné skupině prostředků. Tato struktura omezuje oprávnění instančního objektu pouze na tuto skupinu prostředků.
Z bezpečnostních důvodů a možností správy doporučujeme mít na každou úlohu pouze jeden instanční objekt. Oprávnění pro tento instanční objekt se zachovají, proto důrazně doporučujeme udělit pouze minimální požadovaná oprávnění a udržovat účet monitorovaný a zabezpečený.
Bezpečně uložte tajný klíč nebo certifikát pro tento účet ve službě Azure Key Vault. Důrazně doporučujeme najít trezor klíčů ve vyhrazené skupině prostředků pro správu.
Instanční objekty úrovně 4
Instanční objekty úrovně 4 mají nejvíce omezená oprávnění. Tyto instanční objekty mají nárok na provádění úloh správy, které jsou omezené na jeden prostředek.
Pokud je to možné, doporučujeme používat spravované identity. V případě nespravovaných identit bezpečně uložte tajný klíč nebo certifikát ve službě Azure Key Vault, kde jsou uložené tajné kódy úrovně 3.
Provozní dokonalost
Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v tématu Přehled pilíře efektivity provozu.
Řešení Microsoft Sentinel se skládají ze tří bloků, které zajišťují dokončení a úspěšné operace.
Prvním blokem je definice prostředí, která tvoří základní prvky architektury. Hlavním zájmem tohoto bloku je zvážit počet produkčních a neprodukčních prostředí, která se mají nasadit, a pak zajistit, aby nastavení bylo ve všech případech homogenní.
Druhým blokem je nasazení konektoru Microsoft Sentinelu, kde zvažujete druh konektorů, které váš tým vyžaduje, a požadavky na zabezpečení, které jim umožní.
Třetím blokem je správa životního cyklu artefaktů Microsoft Sentinelu, která se zabývá kódováním, nasazením a používáním nebo zničením komponent. Tento blok například obsahuje analytická pravidla, playbooky, sešity, proaktivní vyhledávání hrozeb atd.
Zvažte tyto závislosti mezi artefakty:
- Pravidla automatizace definovaná v analytickém pravidle
- Sešity nebo analýzy, které vyžadují nový zdroj dat nebo konektor
- Správa aktualizací existujících komponent
- Jak vytvořit verzi artefaktů
- Identifikace, testování a nasazení aktualizovaného nebo zcela nového analytického pravidla
Sestavení, testování a nasazení infrastruktury
Při správě řešení Microsoft Sentinel a DevOps je důležité zvážit aspekty připojení a zabezpečení podnikové architektury.
Azure DevOps může používat agenty hostované Microsoftem nebo agenty v místním prostředí k vytváření, testování a nasazování aktivit. V závislosti na požadavcích vaší společnosti můžete používat hostované Microsoftem, v místním prostředí nebo kombinaci obou modelů.
- Agenti hostovaní Microsoftem. Tato možnost představuje nejrychlejší způsob práce s agenty Azure DevOps, protože se jedná o sdílenou infrastrukturu pro celou organizaci. Další informace o používání agentů hostovaných Microsoftem ve vašem kanálu najdete v tématu Agenti hostovaní Microsoftem. Agenti hostovaní Microsoftem můžou pracovat v hybridních síťových prostředích a udělovat přístup k rozsahům IP adres. Pokud chcete stáhnout rozsahy IP adres, ke kterým tito agenti udělují přístup, přečtěte si téma Rozsahy IP adres Azure a značky služeb – veřejný cloud.
- Agenti v místním prostředí. Tato možnost poskytuje vyhrazené prostředky a větší kontrolu nad instalací závislého softwaru pro sestavení a nasazení. Agenti v místním prostředí můžou pracovat na virtuálních počítačích, škálovacích sadách a kontejnerech v Azure. Další informace o agentech v místním prostředí najdete v tématu Agenti Azure Pipelines.
Spouštěče GitHubu
GitHub může používat spouštěče hostované na GitHubu nebo spouštěče v místním prostředí pro aktivity, které souvisejí s vytvářením, testováním a nasazováním. V závislosti na potřebách vaší společnosti můžete použít GitHub hostovaný, v místním prostředí nebo kombinaci obou modelů.
Spouštěče hostované na GitHubu
Tato možnost představuje nejrychlejší způsob práce s pracovními postupy GitHubu, protože se jedná o sdílenou infrastrukturu pro celou organizaci. Další informace najdete v tématu o spouštěčích hostovaných na GitHubu. Agenti hostovaní gitHubem pracují v hybridních síťových prostředích podle určitých požadavků na síť. Další informace o požadavcích na síť najdete v tématu Podporované spouštěče a hardwarové prostředky.
Spouštěče v místním prostředí
Tato možnost dává vaší společnosti vyhrazenou infrastrukturu prostředků. Spouštěče v místním prostředí pracují na virtuálních počítačích a kontejnerech v Azure a podporují automatické škálování.
Důležité informace o výběru spouštěčů
Při výběru možností pro agenty a spouštěče ve vašem řešení Microsoft Sentinel zvažte následující potřeby:
- Potřebuje vaše společnost vyhrazené prostředky pro spouštění procesů ve vašich prostředích Microsoft Sentinelu?
- Chcete izolovat prostředky pro aktivity DevOps produkčního prostředí od ostatních prostředí?
- Potřebujete otestovat určité případy, které vyžadují přístup k důležitým prostředkům nebo prostředkům, které jsou k dispozici pouze v interní síti?
Orchestrace a automatizace procesů vydávání verzí
Proces nasazení můžete nastavit pomocí Azure DevOps nebo GitHubu. Azure DevOps podporuje použití kanálu YAML nebo kanálu verze. Další informace o používání kanálu YAML v Azure DevOps najdete v tématu Použití Azure Pipelines. Další informace o používání kanálu verze v Azure DevOps najdete v kanálech vydaných verzí. Další informace o používání GitHubu s GitHub Actions najdete v tématu Principy GitHub Actions.
Azure DevOps
V nasazení Azure DevOps můžete provádět následující aktivity nasazení.
- Kanál YAML můžete použít k automatické aktivaci schválení žádostí o přijetí změn nebo spuštění na vyžádání.
- Správa připojení služeb pro různá prostředí pomocí skupin Azure DevOps
- V důležitých prostředích nastavte schválení nasazení pomocí funkce připojení služby a skupin Azure DevOps k přiřazení konkrétních uživatelských oprávnění ve vašem týmu.
GitHub
V nasazení GitHubu můžete provádět následující aktivity nasazení.
- Pomocí GitHubu můžete vytvářet žádosti o přijetí změn nebo aktivity nasazení.
- Správa přihlašovacích údajů instančního objektu pomocí tajných kódů GitHubu
- Integrujte schválení nasazení prostřednictvím pracovního postupu přidruženého k GitHubu.
Automatické nasazení s infrastrukturou Microsoft Sentinelu
V závislosti na podnikové architektuře můžete nasadit jedno nebo více prostředí Microsoft Sentinelu:
- Organizace, které potřebují více instancí v produkčním prostředí, můžou pro každé zeměpisné umístění nastavit různá předplatná ve stejném tenantovi.
- Centralizovaná instance v produkčním prostředí poskytuje přístup k jedné nebo více organizacím ve stejném tenantovi.
- Skupiny, které potřebují více prostředí, jako je produkční, předprodukční, integrace atd., je můžou podle potřeby vytvářet a zničit.
Definice fyzických a logických prostředí
Při nastavování definic prostředí, fyzických nebo logických možností máte dvě možnosti. Oba mají různé možnosti a výhody:
- Fyzická definice – Prvky architektury Služby Microsoft Sentinel jsou definovány s následujícími možnostmi infrastruktury jako kódu (IaC):
- Šablony Bicep
- Šablony Azure Resource Manageru (šablony ARM)
- Terraform
- Logická definice – slouží jako abstrakční vrstva pro nastavení různých týmů ve skupině a definování jejich prostředí. Definice je nastavena v kanálu nasazení a pracovních postupech jako vstup pro prostředí sestavení pomocí vrstvy fyzické infrastruktury.
Při definování logických prostředí zvažte tyto body:
- Zásady vytváření názvů
- Identifikace prostředí
- Konektory a konfigurace
Úložiště kódu
Vzhledem k přístupům k prostředí, které jsou uvedené v předchozí části, zvažte následující organizaci úložiště kódu GitHubu.
Fyzická definice – na základě možností IaC se zamyslete nad přístupem, který používá definice jednotlivých modulů, které jsou propojené v hlavní definici nasazení.
Následující příklad ukazuje, jak může být váš kód uspořádaný.
Omezte přístup k tomuto úložišti týmu, který definuje architekturu na fyzické úrovni a zajišťuje homogenní definici v podnikové architektuře.
Strategii větvení a sloučení můžete přizpůsobit strategii nasazení pro každou organizaci. Pokud váš tým potřebuje začít s definicí, přečtěte si téma Přijetí strategie větvení Gitu.
Další informace o šablonách ARM najdete v tématu Použití propojených a vnořených šablon při nasazování prostředků Azure.
Další informace o nastavení prostředí Bicep najdete v tématu Instalace nástrojů Bicep. Další informace o GitHubu najdete v toku GitHubu.
Logické definice definují prostředí společnosti. Úložiště Git shromažďuje různé definice společnosti.
Následující příklad ukazuje, jak může být váš kód uspořádaný.
Úložiště odráží akce žádosti o přijetí změn provedené různými týmy. Několik prostředí jsou definována různými týmy a schválena vlastníky nebo schvalovateli společnosti.
Úroveň oprávnění pro spuštění nasazení prostředí je úroveň 2. Tato úroveň zajišťuje vytvoření skupiny prostředků a prostředků pro prostředí s nezbytným zabezpečením a ochranou osobních údajů. Tato úroveň také nastaví uživatelská oprávnění k povoleným akcím v produkčních prostředích, produkčním a předprodukčním prostředí.
Organizace, které chtějí prostředí na vyžádání pro testování a vývoj a schopnost následně zničit prostředí po dokončení testování, můžou implementovat kanál Azure DevOps nebo akce GitHubu. Můžou podle potřeby nastavit naplánované triggery, které zničí prostředí pomocí událostí Azure DevOps nebo akcí GitHubu.
Automatická konfigurace konektorů Microsoft Sentinelu
Konektory Microsoft Sentinelu jsou základní součástí řešení, které podporuje propojení s různými prvky v prostředí podnikové architektury, jako je Microsoft Entra ID, Microsoft 365, Microsoft Defender, řešení platformy analýzy hrozeb atd.
Při definování prostředí můžete pomocí konfigurace konektorů nastavit prostředí s homogenními konfiguracemi.
Povolení konektorů v rámci modelu DevOps musí být podporováno modelem na úrovni instančního objektu. Tento fokus zajišťuje správnou úroveň oprávnění, jak je znázorněno v následující tabulce.
| Scénář konektoru | Úroveň modelu přístupu k oprávněním | Nejnižší oprávnění Azure | Vyžaduje schválení pracovního postupu. |
|---|---|---|---|
| Microsoft Entra ID | Úroveň 0 | globální správce nebo správce zabezpečení | Doporučené |
| Ochrana Microsoft Entra ID | Úroveň 0 | globální správce nebo správce zabezpečení | Doporučené |
| Microsoft Defender for Identity | Úroveň 0 | globální správce nebo správce zabezpečení | Doporučené |
| Microsoft Office 365 | Úroveň 0 | globální správce nebo správce zabezpečení | Doporučené |
| Microsoft Cloud App Security | Úroveň 0 | globální správce nebo správce zabezpečení | Doporučené |
| Microsoft Defender XDR | Úroveň 0 | globální správce nebo správce zabezpečení | Doporučené |
| Microsoft Defender for IOT | Úroveň 2 | Přispěvatel | Doporučené |
| Microsoft Defender for Cloud | Úroveň 2 | Čtenář zabezpečení | Volitelné |
| Aktivity v Azure | Úroveň 2 | Čtenář předplatného | Volitelné |
| Platformy analýzy hrozeb | Úroveň 0 | globální správce nebo správce zabezpečení | Doporučené |
| Události zabezpečení | Level 4 | Nic | Volitelné |
| Syslog | Level 4 | Nic | Volitelné |
| DNS (Preview) | Level 4 | Nic | Volitelné |
| Windows Firewall | Level 4 | Nic | Volitelné |
| Zabezpečení Windows události prostřednictvím AMA | Level 4 | Nic | Volitelné |
Nasazení artefaktů Microsoft Sentinelu
Při implementaci artefaktů Služby Microsoft Sentinel získá DevOps větší význam, protože každá společnost vytvoří více artefaktů pro prevenci a nápravu útoků.
Implementace artefaktů může být zodpovědností jednoho týmu nebo několika týmů. Automatické nasazení sestavení a artefaktů je často nejčastějším požadavkem na proces a určuje přístup a podmínky pro vaše agenty a spouštěče.
Nasazení a správa artefaktů Microsoft Sentinelu vyžaduje použití rozhraní REST API služby Microsoft Sentinel. Další informace najdete v tématu Rozhraní REST API služby Microsoft Sentinel. Následující diagram znázorňuje kanál Azure DevOps ve stacku rozhraní Azure REST API.
Úložiště můžete implementovat také pomocí PowerShellu.
Pokud váš tým používá MITRE, zvažte klasifikaci různých artefaktů a určení taktiky a technik pro každý z nich. Ujistěte se, že pro každý typ artefaktu zahrnete odpovídající soubor metadat.
Pokud například vytváříte nový playbook pomocí šablony Azure ARM a název souboru je Playbook.arm.json, přidáte soubor JSON s názvem Playbook.arm.mitre.json. Metadata pro tento soubor pak zahrnují formáty CSV, JSON nebo YAML, které odpovídají taktikám nebo technikám MITRE, které používáte.
Podle tohoto postupu může váš tým vyhodnotit pokrytí MITRE na základě úloh, které se provádějí během nastavování pro různé typy artefaktů, které používáte.
Artefakty sestavení
Cílem procesu sestavení je zajistit, že vygenerujete artefakty s nejvyšší kvalitou. Následující diagram znázorňuje některé akce procesu sestavení, které můžete provést.
Stáhněte si soubor aplikace Visio s touto architekturou.
- Definici artefaktu můžete založit na popisném schématu ve formátu JSON nebo YAML a pak schéma ověřit, aby nedocházelo k chybám syntaxe.
- Pomocí testovací sady nástrojů pro šablony ARM ověřte šablony ARM.
- Pomocí PowerShellu ověřte soubory YAML a JSON pro vlastní modely.
- Ověřte nastavení seznamu ke zhlédnutí a ujistěte se, že záznamy CIDR (Classless Inter-Domain Routing), které definujete, dodržují správné schéma, například 10.1.0.0/16.
- Použijte dotazy dotazovacího jazyka KQL (Keyword Query Language), které můžete ověřit na úrovni syntaxe, pro analytická pravidla, pravidla proaktivního vyhledávání a pravidla živého streamu, která můžete ověřit na úrovni syntaxe.
- Proveďte místní ověření KQL jednou z možností.
- Integrujte nástroj pro vložené ověřování KQL v kanálu DevOps.
- Pokud implementujete logiku založenou na PowerShellu pro Azure Automation, můžete použít ověřování syntaxe a testování jednotek pomocí následujících prvků:
- Vygenerujte sestavu metadat manifestu MITRE na základě souborů metadat, které jsou součástí artefaktů.
Export artefaktů
Obvykle více týmů pracuje na několika instancích Microsoft Sentinelu, aby vygenerovalo potřebné artefakty a ověřilo je. S cílem opětovného použití existujících artefaktů může vaše společnost nastavit automatické procesy pro získání definic artefaktů z existujících prostředí. Automatizace může také poskytnout informace o všech artefaktech vytvořených různými vývojovými týmy během instalace.
Následující diagram znázorňuje příklad procesu extrakce artefaktů.
Stáhněte si soubor aplikace Visio s touto architekturou.
Nasazení artefaktů
Cílem procesu nasazení je:
- Zkraťte dobu uvedení na trh.
- Zvyšte výkon napříč několika týmy, které se zabývají nastavením a správou vašeho řešení.
- Nastavte integrační testování, abyste vyhodnotili stav prostředí.
Vývojové týmy tento proces používají k zajištění toho, aby mohli nasazovat, testovat a ověřovat případy použití artefaktů, které jsou ve vývoji. Týmy architektury a SOC ověřují kvalitu kanálu v prostředích kontroly kvality a pracují s integračními testy pro scénáře útoku. V testovacích případech tým obvykle kombinuje různé artefakty jako analytická pravidla, playbooky oprav, seznamy ke zhlédnutí atd. Součástí každého případu použití je simulace útoků, ve kterých se celý řetězec vyhodnocuje z příjmu dat, detekce a nápravy.
Následující diagram znázorňuje sekvenci procesu nasazení, která zajišťuje nasazení artefaktů ve správném pořadí.
Stáhněte si soubor aplikace Visio s touto architekturou.
Správa artefaktů sentinelu jako kódu nabízí flexibilní způsoby, jak udržovat operace a automatizovat nasazení v kanálu CI/CD DevOps.
Řešení Microsoftu poskytují pracovní postupy automatizace pro následující artefakty.
| Artefakt | Pracovní postupy automatizace |
|---|---|
| Seznamy ke zhlédnutí | Revize kódu Ověřování schématu Nasazení Vytváření, aktualizace, odstraňování seznamů ke zhlédnutí a položek |
| Sloučení analytických pravidel Microsoft Security Analýza chování ML Anomálie Plánováno |
Revize kódu Ověření syntaxe KQL Ověřování schématu Otravovat Nasazení Vytvoření, povolení, aktualizace, odstranění, export Podpora šablon upozornění |
| Pravidla automatizace | Revize kódu Ověřování schématu Nasazení Vytvoření, povolení, aktualizace, odstranění, export |
| Konektory | Revize kódu Ověřování schématu Nasazení Akce: povolení, odstranění (zakázání), aktualizace |
| Pravidla proaktivního vyhledávání | Revize kódu Ověření syntaxe KQL Ověřování schématu Otravovat Nasazení Akce: vytvoření, povolení, aktualizace, odstranění, export |
| Playbooky | Revize kódu TTK Nasazení Akce: vytvoření, povolení, aktualizace, odstranění, export |
| Workbooks | Nasazení Akce: vytvoření, aktualizace, odstranění |
| Runbooky | Revize kódu Ověřování syntaxe PowerShellu Otravovat Nasazení Akce: vytvoření, povolení, aktualizace, odstranění, export |
V závislosti na zvoleném automatizačním jazyce nemusí být některé možnosti automatizace podporované. Následující diagram ukazuje, které možnosti automatizace jsou podporovány jazykem.
* Funkce ve vývoji, které ještě nejsou zdokumentované
** Metody automatizace podporované rozhraními MICROSOFT Operational Insights nebo rozhraními API poskytovatele prostředků Microsoft Insights
Azure Automation
Následující diagram znázorňuje komponenty zjednodušení přístupu k Microsoft Sentinelu pomocí identity spravované služby.
Stáhněte si soubor aplikace Visio s touto architekturou.
Pokud potřebujete udělit přístup k jiným prostředkům, použijte spravovanou identitu, která zajišťuje jedinečnou identitu pro všechny důležité operace.
K nastavení playbooků použijte Azure Automation. Ke složitým úlohám a funkcím automatizace použijte skripty PowerShellu:
- Integrace s řešeními třetích stran, kde jsou vyžadovány různé úrovně přihlašovacích údajů a založené na ID Microsoft Entra nebo vlastních přihlašovacích údajích:
- Přihlašovací údaje uživatele Microsoft Entra
- Přihlašovací údaje instančního objektu Microsoft Entra
- Ověření certifikátu
- Vlastní přihlašovací údaje
- Spravovaná identita
- Implementace řešení, které opakovaně používá organizační skripty nebo řešení vyžadující použití příkazů PowerShellu, aby se zabránilo složitému překladu do playbooků:
- Řešení založená na PowerShellu
- Řešení založená na Pythonu
- Implementace řešení v hybridních scénářích, kdy nápravné akce můžou ovlivnit vaše cloudové a místní prostředky.
Úložiště Microsoft Sentinelu
Zkušení týmy DevOps můžou zvážit správu Služby Microsoft Sentinel v infrastruktuře jako kódu (IaC) pomocí kanálů CI/CD, které jsou integrované v Azure DevOps. Produktové skupiny chápou výzvy, kterým čelí zákazníci a partneři při vytváření architektury zabezpečení Azure DevOps, takže vám můžou pomoct následující dvě iniciativy:
- Dokumentace referenční architektury
- Vývoj nového řešení, které bylo oznámeno na konferenci Ignite 2021, se nazývá "Úložiště Microsoft Sentinelu"
Pro podporu výběru řešení, které vyhovuje potřebám vašeho týmu, porovnává následující tabulka funkční a technická kritéria.
| Případ použití a funkce | Vlastní přístup Azure DevOps a GitHub | Úložiště Microsoft Sentinelu |
|---|---|---|
| Chceme rychle začít nasazovat artefakty Microsoft Sentinelu bez nutnosti trávit čas definováním komponent architektury Azure DevOps, jako jsou agenti, kanály, Git, řídicí panely, wiki, instanční objekty, RBACs, auditování atd. | Nedoporučuje se | Doporučené |
| Máme malé týmy a sady dovedností pro správu kanálů CI/CD. | Nedoporučuje se | Doporučené |
| Chceme řídit a spravovat všechny aspekty zabezpečení kanálů CI/CD. | Podporováno | Nepodporováno |
| Před aktivací kanálů nasazení, jako je správa zdrojového kódu, kontrola kódování, vrácení zpět, schválení pracovního postupu atd., musíme integrovat brány a větvení pro dohled nad integrací. | Podporováno | Částečně podporováno |
| Máme přizpůsobenou strukturu Gitu nebo úložiště. | Podporováno | Podporováno |
| K vytváření artefaktů nepoužíváme jazyky Resource Manager ani Bicep IaC. | Podporováno | Nepodporováno |
| Chceme centrálně spravovat nasazení artefaktů do více pracovních prostorů Microsoft Sentinelu v jednom tenantovi Microsoft Entra. | Podporováno | Podporováno |
| Chceme integrovat nebo rozšířit kanály CI/CD napříč několika tenanty Microsoft Entra. | Podporováno | Podporováno |
| Máme playbooky s různou parametrizací v závislosti na předplatném, umístění, prostředí atd. | Podporováno | TBD, pokyny k dokumentaci |
| Chceme integrovat různé artefakty do stejného úložiště, abychom mohli vytvářet případy použití. | Podporováno | Podporováno |
| Chceme mít možnost hromadně odebírat artefakty. | Podporováno | Nepodporuje se |
Dostupnost, výkon a škálovatelnost
Při výběru architektury pro agenty Azure DevOps ve vaší společnosti pro scénáře Microsoft Sentinelu zvažte následující potřeby:
- Produkční prostředí může vyžadovat vyhrazený fond agentů pro operace v prostředí Microsoft Sentinelu.
- Neprodukční prostředí můžou fond agentů sdílet s velkým počtem instancí pro zpracování různých požadavků od týmů, zejména pro postupy CI/CD.
- Scénáře simulace útoku jsou zvláštní případ, kdy je možné potřebovat vyhrazené agenty. Zvažte, jestli je vyhrazený fond nezbytný pro vaše potřeby testování.
- Organizace, které pracují na scénářích hybridní sítě, můžou zvážit integraci agentů v síti.
Organizace můžou vytvářet vlastní image pro agenty založené na kontejnerech. Další informace najdete v tématu Spuštění místního agenta v Dockeru.
Správa mezi tenanty v Microsoft Sentinelu s využitím Azure DevOps
Jako globální SOC nebo MSSP možná budete muset spravovat více tenantů. Azure Lighthouse podporuje škálované operace napříč několika tenanty Microsoft Entra najednou a tím zefektivňuje úlohy správy. Další informace najdete v tématu Přehled služby Azure Lighthouse.
Správa napříč tenanty je zvlášť účinná v následujících scénářích:
- Správa prostředků Microsoft Sentinelu v tenantech zákazníků
- Sledujte útoky a zobrazte výstrahy zabezpečení napříč několika tenanty.
- Umožňuje zobrazit incidenty napříč několika pracovními prostory Služby Microsoft Sentinel, které jsou rozložené mezi tenanty.
Metody onboardingu zákazníků
Máte dvě možnosti pro onboarding zákazníků, nabídku spravovaných služeb a šablonu ARM.
Ruční onboarding pomocí šablony ARM
Pokud nechcete publikovat nabídku na Azure Marketplace jako poskytovatele služeb nebo nesplňujete všechny požadavky, můžete zákazníky nasadit ručně pomocí šablon ARM. Tato možnost je nejpravděpodobnější v podnikovém scénáři, kdy má stejný podnik více tenantů.
Následující tabulka porovnává metody onboardingu.
| Situace | Nabídka spravované služby | Šablony ARM |
|---|---|---|
| Vyžaduje účet Partnerského centra. | Yes | No |
| Vyžaduje úroveň kompetence cloudové platformy Silver nebo Gold nebo stav poskytovatele spravovaných služeb Azure Expert (MSP). | Yes | No |
| K dispozici pro nové zákazníky prostřednictvím Azure Marketplace | Yes | No |
| Může omezit nabídku konkrétním zákazníkům. | Ano (pouze u privátních nabídek, které se nedají použít s předplatnými vytvořenými prostřednictvím prodejce programu CSP) | Ano |
| Vyžaduje přijetí zákazníka na webu Azure Portal. | Yes | No |
| Automatizace se dá použít k onboardingu několika předplatných, skupin prostředků nebo zákazníků. | No | Ano |
| Poskytuje okamžitý přístup k novým integrovaným rolím a funkcím Azure Lighthouse. | Ne vždy (obecně dostupné po určité prodlevě) | Ano |
Další informace o publikování nabídek spravovaných služeb najdete v tématu Publikování nabídky spravovaných služeb na Azure Marketplace.
Další informace o tom, jak vytvořit šablonu ARM, najdete v tématu Vytvoření a nasazení šablon ARM.
Následující diagram znázorňuje integraci architektury vysoké úrovně mezi tenantem MSSP a tenanty poskytovatele prostředků zákazníka se službou Azure Lighthouse a Microsoft Sentinelem.
Stáhněte si soubor aplikace Visio s touto architekturou.
- Nabídka MSP je integrovaná prostřednictvím šablony ARM nebo nabídky služby Azure Marketplace.
- Delegovaná správa prostředků Azure kontroluje, jestli žádost pochází z partnerského tenanta, a volá poskytovatele prostředků spravované služby.
- Poskytovatel prostředků spravované služby používá řízení přístupu MSP pomocí RBAC.
- Msp dokončí akce SecOps u prostředku zákazníka.
- Proces fakturace zpracovává výdaje jako poplatky zákazníků. Rozdělení fakturace je možné, pokud entity zákazníků mají samostatné pracovní prostory ve stejném tenantovi Microsoft Entra.
- Zabezpečení a suverenita dat závisí na hranicích tenanta zákazníka.
Identita napříč několika tenanty
Pokud chcete spravovat Microsoft Sentinel pomocí Azure DevOps, vyhodnoťte následující rozhodnutí o návrhu komponent.
| Případ použití | Výhody |
|---|---|
| Globální identita pro správu akcí DevOps, jeden instanční objekt | Tento případ platí pro globální procesy nasazení, které zahrnují všechny tenanty. Použití sjednocené identity usnadňuje přístup pro různé tenanty, ale může proces správy akcí schválení pro konkrétní tenanty komplexní. Mechanismus ochrany a model autorizace pro tento druh identity je také velmi důležitý, aby se zabránilo neautorizované použití, které je způsobeno souvisejícím globálním dopadem. |
| Vyhrazená identita pro správu akcí DevOps, několik instančních objektů | Tento případ platí, když jsou procesy nasazení vyhrazené pro jednotlivé akce tenanta nebo tenanta, které vyžadují schválení. V tomto případě je doporučení pro ochranu a autorizaci tohoto použití identity stejné jako v globálním případě, i když dojde ke snížení dopadu. |
Organizace úložiště kódu
| Případ použití | Výhody |
|---|---|
| Jednotné úložiště s jednou verzí kódu pro všechny tenanty | Tento případ usnadňuje jednotné verze kódu v úložišti. V tomto případě může jednotná verze kódu, která spravuje konkrétní verzi pro tenanty, vyžadovat podporu větví pro každý případ. |
| Jednotné úložiště s konkrétními složkami kódu podle tenanta | Tento případ doplňuje případ s jedním úložištěm. V této části může struktura složek rozdělit vyhrazené artefakty podle tenanta. |
| Vyhrazené úložiště podle tenanta | Tento přístup poskytuje izolaci při správě artefaktů kódu. Usnadňuje vývoj mezi tenanty s různými týmy nebo požadavky. Konsolidace změn vyžaduje vytvoření procesu mezi úložišti, které může vyžadovat úsilí o údržbu. |
Procesy sestavení a nasazení
| Případ použití | Výhody |
|---|---|
| Jeden proces sestavení pro všechny tenanty | Pokud všichni tenanti pracují se stejnou verzí artefaktů, je to nejjednodušší možnost implementace generování a balíčku. |
| Proces sestavení podle tenanta | Do každého tenanta se nasadí jiná verze kódu. |
| Globální proces nasazení pro všechny tenanty | Nová nasazení a aktualizace nasazení platí pro všechny tenanty. Kroky procesů nasazení a aktualizace se používají pro všechny tenanty. |
| Tenant globálního procesu nasazení podle tenanta | Nová nasazení a aktualizace nasazení platí pro jednoho nebo více tenantů. |
| Vyhrazený proces nasazení podle tenanta | Proces nasazení je přizpůsobený pro každého tenanta. |
Optimalizace nákladů
Optimalizace nákladů se týká snížení zbytečných výdajů a zlepšení efektivity provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.
Náklady na řešení závisí na následujících faktorech:
- Objem dat, která vaše společnost odesílá do pracovního prostoru Služby Log Analytics služby Microsoft Sentinel měsíčně
- Zvolená úroveň závazku nebo způsob fakturace, například průběžné platby (PAYG)
- Míra uchovávání zásad dat na tabulce nebo na globální úrovni
Další informace najdete v tématu Uchovávání datových typů Azure.
Pokud chcete vypočítat ceny, podívejte se na cenovou kalkulačku Microsoft Sentinelu. Další informace o rozšířených cenových aspektech a příkladech najdete v tématu Plánování nákladů pro Microsoft Sentinel.< a1/>.
Pokud své řešení rozšíříte o následující komponenty, můžete mít za následek další náklady:
- Playbooky – moduly runtime pro Azure Logic Apps a Azure Functions Další informace najdete v tématu Podrobnosti o cenách.
- Export do externího úložiště, jako je Azure Data Explorer, Event Hubs nebo účet Azure Storage.
- Pracovní prostor strojového učení a výpočetní prostředky, které komponenta Jupyter Notebook používá.
Nasazení tohoto scénáře
Následující část popisuje kroky pro nasazení tohoto scénáře ve formě ukázkového případu použití, který pokrývá různé procesy DevOps.
Sestavení a vydání architektury Microsoft Sentinelu
Nejprve nastavte potřebné komponenty NuGet ve vyhrazeném úložišti, kde mohou různé procesy využívat vydané verze, které vygenerujete.
Pokud pracujete s Azure DevOps, můžete vytvořit informační kanál komponent pro hostování různých balíčků NuGet z architektury Microsoft Sentinel pro PowerShell. Další informace najdete v tématu Začínáme s balíčky NuGet.
Pokud váš tým zvolí registr GitHubu, můžete ho připojit jako úložiště NuGet, protože je kompatibilní s protokolem informačního kanálu. Další informace najdete v tématu Úvod k balíčkům GitHubu.
Pokud máte dostupné úložiště NuGet, kanál obsahuje připojení služby pro NuGet. Tyto snímky obrazovky znázorňují konfiguraci nového připojení služby s názvem Připojení NuGet Framework pro Microsoft Sentinel.
Po nakonfigurování informačního kanálu můžete kanál pro sestavení architektury PowerShellu importovat přímo z GitHubu v konkrétním forku. Další informace najdete v tématu Vytváření úložišť GitHub. V takovém případě vytvoříte nový kanál a jako zdroj kódu zvolíte GitHub.
Další možností je importovat úložiště Git jako úložiště Azure DevOps, které je založené na Gitu. V obou případech pro import kanálu zadejte následující cestu:
src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml
Kanál teď můžete spustit poprvé. Pak architektura sestaví a vydá do informačního kanálu NuGet.
Definování prostředí Microsoft Sentinelu
Když začínáte se službou Microsoft Sentinel a používáte tyto ukázky, definujte prostředí ve vaší společnosti, například Environment as Code nebo EaC. V každém případě zadáte různé prvky, které tvoří prostředí.
Architektura Microsoft Sentinelu zahrnuje v Azure následující prvky:
- Pracovní prostor Služby Log Analytics – Tento pracovní prostor tvoří základ řešení. Informace související se zabezpečením se tady ukládají a pracovní prostor je modul pro dotazovací jazyk Kusto (KQL).
- Řešení Microsoft Sentinel nad pracovním prostorem Služby Log Analytics – toto řešení rozšiřuje funkce pracovního prostoru služby Log Analytics tak, aby zahrnovalo funkce SIEM a SOAR.
- Key Vault – Trezor klíčů uchovává tajné kódy a klíče, které se používají během procesů nápravy.
- Účet Automation – Tento účet je volitelný a používá se pro procesy nápravy. Proces nápravy, který použijete, je založený na runboocích PowerShellu a Pythonu. Tento proces zahrnuje identitu spravovanou systémem, která funguje s různými prostředky podle osvědčených postupů.
- Identita spravovaná uživatelem – Tato funkce funguje jako sjednocená vrstva identit Microsoft Sentinelu, která spravuje interakce mezi playbooky Microsoft Sentinelu a runbooky.
- Připojení aplikací logiky – Jedná se o připojení pro Microsoft Sentinel, trezor klíčů a automatizaci, která používají identitu spravovanou uživatelem.
- Připojení externí aplikace logiky – Jedná se o připojení pro externí prostředky, které jsou zapojeny do procesů nápravy a které jsou založené na playbookech.
- Azure Event Hubs – Tato funkce je volitelná a zpracovává integraci mezi Microsoft Sentinelem a dalšími řešeními, jako jsou Splunk, Azure Databricks a strojové učení a odolné.
- Účet úložiště – Tato funkce je volitelná a zpracovává integraci mezi Microsoft Sentinelem a dalšími řešeními, jako jsou Splunk, Azure Databricks a strojové učení a odolné.
Pomocí příkladů z úložiště můžete definovat prostředí se soubory JSON a určit tak různé logické koncepty. Možnosti, které jsou k dispozici pro definování prostředí, mohou být literálové nebo automatické.
V definici literálu zadáte název a prvky pro každý prostředek v prostředí, jak je znázorněno v tomto příkladu.
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Literal",
"ResourceGroupName": "<resource-group-name>"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Literal",
"LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
"ManagedIdentityName": "<user-managed-identity-name>",
"SentinelConnectionName": "<Sentinel-API-connection-name>",
"KeyVaultName": "<Key-Vault-name>",
"KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
},
"Automation":
{
"Type": "Literal",
"AutomationAccountName": "<automation-account-name>",
"AutomationAccountConnectionName": "<automation-account-API-connection-name>"
},
"Integration":
{
"Type": "Literal",
"EventHubNamespaces": [
"<Event-Hubs-namespace-1-name>",
"<Event-Hubs-namespace-2-name>",
"<Event-Hubs-namespace-3-name>",
"<Event-Hubs-namespace-4-name>",
"<Event-Hubs-namespace-5-name>",
"<Event-Hubs-namespace-6-name>",
"<Event-Hubs-namespace-7-name>",
"<Event-Hubs-namespace-8-name>",
"<Event-Hubs-namespace-9-name>",
"<Event-Hubs-namespace-10-name>",
],
"StorageAccountName": "<storage-account-name>"
}
}
}
V automatické definici se názvy elementů generují automaticky na základě konvencí pojmenování, jak je znázorněno v tomto příkladu.
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Automatic"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Automatic"
},
"Automation":
{
"Type": "Automatic"
},
"Integration":
{
"Type": "Automatic",
"MaxEventHubNamespaces": 5
}
}
}
Ukázky najdete v úložišti GitHub v cestě prostředí Microsoft Sentinelu a ukázky můžete použít jako referenci při přípravě případů použití.
Nasazení prostředí Microsoft Sentinelu
Pokud máte definované aspoň jedno prostředí, můžete vytvořit připojení služby Azure pro integraci s Azure DevOps. Po vytvoření připojení služby nastavte propojený instanční objekt na roli vlastníka nebo podobnou úroveň oprávnění pro cílové předplatné.
Naimportujte kanál pro vytvoření nového prostředí, jak je definováno v tomto souboru.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.ymlDále zadejte název připojení služby, které představuje prostředí.
Zvolte větev pro definici prostředí v úložišti.
Do pole Připojení prostředí Azure zadejte název připojení služby Azure DevOps pro vaše předplatné.
Zadejte název prostředí, které může připojení služby použít k překladu více prostředí ve stejném předplatném.
Zvolte akci, která se má použít u konektorů.
Pokud chcete použít předběžné verze součástí architektury PowerShellu, vyberte Použít artefakty před vydáním PowerShellu.
Kanál zahrnuje následující kroky jako součást toku nasazení:
- Nasaďte komponenty NuGet.
- Připojte se pomocí nástrojů NuGet s úložištěm artefaktů.
- Vyřešte informační kanál.
- Nainstalujte požadované moduly.
- Získejte definici prostředí.
- Ověřte, které prostředky existují v cíli.
- Pokud nejsou v pracovním prostoru, přidejte Log Analytics a Microsoft Sentinel.
- Pokud už máte Log Analytics, přidejte Microsoft Sentinel přes vaši instanci Log Analytics.
- Vytvořte spravovanou identitu, která představuje interakci mezi Microsoft Sentinelem a Logic Apps.
- Vytvořte Azure Key Vault a nastavte přiřazení role pro správu tajných kódů a klíčů ke spravované identitě.
- Pokud je to možné, vytvořte účet Azure Automation a zapněte spravovanou identitu přiřazenou systémem.
- Nastavte přiřazení role přes trezor klíčů pro spravovanou identitu přiřazenou systémem.
- Vytvořte definice služby Event Hubs, pokud neexistují, a nastavte, jestli definice obsahuje prvky integrace.
- Nastavte přiřazení role přes trezor klíčů pro spravovanou identitu přiřazenou systémem.
- Pokud neexistují, vytvořte definice účtu úložiště a nastavte, jestli definice obsahuje integrační prvky.
- Nastavte přiřazení role přes trezor klíčů pro spravovanou identitu přiřazenou systémem.
- Nasaďte akce konektoru.
- Nasaďte runbook integrace do účtu Automation.
- Nasaďte připojení Logic Apps, pokud jsou definovaná jako součást prostředí.
Zničení prostředí Microsoft Sentinelu
Pokud už prostředí nepotřebujete, například v případě vývojového nebo testovacího prostředí, můžete ho zničit, jak je definováno v tomto souboru.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml
Stejně jako při nasazování kanálu prostředí zadáte název připojení služby, které představuje prostředí.
Práce s prostředím Microsoft Sentinelu
Jakmile je prostředí připravené, můžete začít vytvářet artefakty pro nastavení různých případů použití.
Exportujte artefakty z prostředí, na kterém pracujete, jak je definováno v tomto souboru.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.ymlZvolte větev pro definici prostředí v úložišti.
Do pole Připojení k prostředí Azure zadejte název připojení služby Azure DevOps pro prostředí, které se exportuje.
Pokud chcete použít předběžné verze součástí architektury PowerShellu, vyberte Použít artefakty před vydáním PowerShellu.
Zvolte formát pro analytická pravidla a pravidla proaktivního vyhledávání.
Ve výsledcích je k dispozici výstupní soubor artefaktů. Jakmile budete mít artefakty, můžete do úložiště Git zahrnout výstupní soubor.
Sestavení artefaktů v prostředí Microsoft Sentinelu
Umístěte artefakty do cesty k případům použití MITRE služby Microsoft Sentinel. Nastavte strukturu složek podle různých typů artefaktů.
Spusťte proces sestavení definovaný v tomto souboru.
src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yamlZvolte větev pro definici prostředí v úložišti.
Diagram způsobu, jak zvolit větev pro sestavení artefaktů.](./media/build-artifacts-pipeline.png)
Pokud chcete použít předběžné verze součástí architektury PowerShellu, vyberte Použít artefakty před vydáním PowerShellu.
Kanál se skládá z těchto kroků:
- Nasaďte komponenty NuGet.
- Připojte nástroje NuGet k úložišti artefaktů.
- Vyřešte informační kanál.
- Nainstalujte požadované moduly.
- Získejte architekturu testovací sady nástrojů pro ověřování šablon ARM.
- Ověřte šablony ARM.
- Ověřte kód runbooků PowerShellu a proveďte ověření syntaxe.
- Pokud je to možné, spusťte testy jednotek Pester.
- Ověřte syntaxi KQL v pravidlech proaktivního vyhledávání a analýzy.
Nasazení artefaktů do prostředí Microsoft Sentinelu
Při nasazování artefaktů můžete v tomto úložišti použít úložiště Microsoft Sentinelu nebo ukázky kanálu nasazení. Další informace najdete v tématu Nasazení vlastního obsahu z úložiště.
Úložiště Microsoft Sentinelu
Pokud používáte úložiště Microsoft Sentinel, můžete nastavit proces vydávání verzí tak, aby zahrnoval artefakty v úložišti, které je připojené k jednotlivým instancím Microsoft Sentinelu. Po potvrzení artefaktů v úložišti se některé kroky automaticky provádějí v rámci vytváření kanálu a povolení úložišť Microsoft Sentinel.
Můžete také přizpůsobit procesy nasazení, které úložiště Microsoft Sentinel dělají, na základě postupů popsaných v tomto dokumentu. Jedním z důležitých aspektů, které je potřeba vzít v úvahu, je schválení vydané verze, které můžete nastavit pomocí těchto přístupů:
- Schválení žádosti o přijetí změn při potvrzení artefaktů Další informace najdete v tématu Vytváření žádostí o přijetí změn.
- Schválení kanálu verze při spuštění nasazení Další informace najdete v tématu Definování schválení a kontrol.
Ukázky kanálů nasazení Microsoft Sentinelu
Pomocí ukázek kanálu nasazení Služby Microsoft Sentinel můžete nastavit proces vydání.
Nastavte proces vydání podle definice v tomto souboru.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.ymlZvolte větev pro definici prostředí v úložišti.
Do pole Připojení k prostředí Azure zadejte název připojení služby Azure DevOps pro prostředí, které se exportuje.
Pokud chcete použít předběžné verze součástí architektury PowerShellu, vyberte Použít artefakty před vydáním PowerShellu.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- Kevin Kisoka | Přidružení architekta
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
- Další informace o Microsoft Sentinelu s DevOps pro architekturu s jedním tenantem najdete v tématu Nasazení a správa Microsoft Sentinelu jako kódu.
- Další informace o návrhu architektury MSSP, která funguje napříč několika adresáři Microsoft Entra, najdete v tématu Kombinování služby Azure Lighthouse s možnostmi DevOps služby Microsoft Sentinel.
- Informace o spravované identitě pomocí Microsoft Sentinelu najdete v tématu Co je nového: Spravovaná identita pro konektor Microsoft Sentinel Logic Apps.
- Informace o nasazení obsahu z úložiště Microsoft Sentinel najdete v tématu Nasazení vlastního obsahu z úložiště.
- Informace o aspektech zabezpečení Azure DevOps najdete v rychlých referenčních informacích k výchozím oprávněním.
- Informace o ochraně úložiště Azure DevOps najdete v tématu Přidání ochrany k prostředku úložiště.
- Informace o správě zabezpečení připojení služby Azure DevOps najdete v tématu Připojení služeb v Azure Pipelines.