Sdílet prostřednictvím

Automatizace reakcí na hrozby v Microsoft Sentinelu pomocí pravidel automatizace

  • Článek
  • Platí pro:
    Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

Tento článek vysvětluje, co jsou pravidla automatizace služby Microsoft Sentinel a jak je používat k implementaci operací orchestrace zabezpečení, automatizace a reakce (SOAR). Pravidla automatizace zvyšují efektivitu SOC a šetří vám čas a prostředky.

Důležité

Microsoft Sentinel je teď obecně dostupný na portálu Microsoft Defenderu na sjednocené platformě operací zabezpečení Microsoftu. Další informace najdete v tématu Microsoft Sentinel na portálu Microsoft Defender.

Co jsou pravidla automatizace?

Pravidla automatizace představují způsob, jak centrálně spravovat automatizaci v Microsoft Sentinelu tím, že vám umožní definovat a koordinovat malou sadu pravidel, která se dají použít v různých scénářích.

Pravidla automatizace se vztahují na následující kategorie případů použití:

  • Provádění základních úloh automatizace pro zpracování incidentů bez použití playbooků Příklad:

    • Přidejte úkoly incidentů pro analytiky, které mají sledovat.
    • Potlačit hlučné incidenty.
    • Třídění nových incidentů změnou stavu Nové na Aktivní a přiřazením vlastníka
    • Označte incidenty a klasifikujte je.
    • Eskalujte incident přiřazením nového vlastníka.
    • Zavření vyřešených incidentů, zadání důvodu a přidání komentářů

  • Automatizujte odpovědi pro více analytických pravidel najednou.

  • Řídí pořadí spuštěných akcí.

  • Zkontrolujte obsah incidentu (výstrahy, entity a další vlastnosti) a proveďte další akce voláním playbooku.

  • Pravidla automatizace můžou být také mechanismem, kterým spouštíte playbook v reakci na výstrahu , která není přidružená k incidentu.

Stručně řečeno, pravidla automatizace zjednodušují používání automatizace v Microsoft Sentinelu, což vám umožní zjednodušit složité pracovní postupy pro procesy orchestrace reakcí na hrozby.

Komponenty

Pravidla automatizace se skládají z několika komponent:

  • Triggery, které definují, jaký druh události incidentu způsobí, že se pravidlo spustí za podmínek.
  • Podmínky , které určují přesné okolnosti, za kterých pravidlo běží a provádí akce.
  • Akce pro změnu incidentu nějakým způsobem nebo volání playbooku, který provádí složitější akce a komunikuje s jinými službami.

Aktivační události

Pravidla automatizace se aktivují při vytvoření nebo aktualizaci incidentu nebo při vytvoření výstrahy. Vzpomeňte si, že incidenty zahrnují výstrahy a že výstrahy i incidenty je možné vytvářet analytickými pravidly, jak je vysvětleno v detekci hrozeb v Microsoft Sentinelu.

Následující tabulka uvádí různé možné scénáře, které způsobují spuštění pravidla automatizace.

Typ aktivační události Události, které způsobují spuštění pravidla
Při vytvoření incidentu Unified security operations platform in Microsoft Defender:
  • Na portálu Microsoft Defenderu se vytvoří nový incident.

    Microsoft Sentinel není onboardovaný na sjednocenou platformu:
  • Nový incident se vytvoří analytickým pravidlem.
  • Incident se ingestuje z XDR v programu Microsoft Defender.
  • Nový incident se vytvoří ručně.
    		•
    Při aktualizaci incidentu
  • Stav incidentu se změní (zavřeno, znovu otevřeno nebo třídění).
  • Vlastník incidentu se přiřadí nebo změní.
  • Závažnost incidentu je vyvolána nebo nižší.
  • Výstrahy se přidají do incidentu.
  • Komentáře, značky nebo taktiky se přidají do incidentu.
    		•
    Při vytvoření výstrahy
  • Výstrahu vytvoří pravidlo naplánované služby Microsoft Sentinel nebo analytické pravidlo NRT.
    		•

    Automatizace založená na incidentech nebo výstrahách?

    Díky pravidlům automatizace, která centrálně zpracovávají reakci na incidenty i výstrahy, jak byste se měli rozhodnout, které zautomatizovat a za jakých okolností?

    Pro většinu případů použití je vhodnější použít automatizaci aktivovanou incidenty. V Microsoft Sentinelu je incident "případový soubor" – agregace všech relevantních důkazů pro konkrétní šetření. Jedná se o kontejner pro výstrahy, entity, komentáře, spolupráci a další artefakty. Na rozdíl od výstrah , které jsou jedinými důkazy, jsou incidenty upravitelné, mají nejaktuálnější stav a dají se rozšířit o komentáře, značky a záložky. Incident umožňuje sledovat scénář útoku, který se neustále vyvíjí s přidáním nových upozornění.

    Z těchto důvodů je vhodnější vytvořit automatizaci v případě incidentů. Nejvhodnější způsob, jak vytvořit playbooky, je tedy založit je na triggeru incidentu Microsoft Sentinelu v Azure Logic Apps.

    Hlavním důvodem použití automatizace aktivované výstrahami je reakce na výstrahy generované analytickými pravidly, která nevytvářejí incidenty (to znamená, že vytváření incidentů je zakázané na kartě Nastavení incidentu v průvodci analytickým pravidlem).

    Tento důvod je zvlášť relevantní, pokud je váš pracovní prostor Microsoft Sentinelu nasazený na sjednocené platformě operací zabezpečení. V tomto scénáři probíhá veškeré vytváření incidentů v XDR v programu Microsoft Defender, a proto musí být pravidla vytváření incidentů v Microsoft Sentinelu zakázaná.

    I bez onboardingu na sjednocený portál se můžete přesto rozhodnout použít automatizaci aktivovanou výstrahou, pokud chcete použít jinou externí logiku k rozhodnutí, jestli a kdy vytvářet incidenty z výstrah a jak se výstrahy seskupují. Příklad:

    • Playbook aktivovaný výstrahou, která nemá přidružený incident, může rozšířit výstrahu o informace z jiných zdrojů a na základě nějaké externí logiky rozhodnout, jestli se má incident vytvořit, nebo ne.

    • Playbook aktivovaný výstrahou může místo vytvoření incidentu vyhledat odpovídající existující incident, do něhož se má výstraha přidat. Přečtěte si další informace o rozšíření incidentů.

    • Playbook aktivovaný výstrahou může informovat pracovníky SOC o upozornění, aby se tým mohl rozhodnout, jestli má incident vytvořit nebo ne.

    • Playbook aktivovaný výstrahou může odeslat výstrahu externímu systému lístků pro vytvoření a správu incidentů a tento systém vytvoří nový lístek pro každou výstrahu.

    Poznámka:

    Podmínky

    Komplexní sady podmínek je možné definovat tak, aby se řídily, kdy se mají spustit akce (viz níže). Mezi tyto podmínky patří událost, která aktivuje pravidlo (vytvoření nebo aktualizace incidentu nebo vytvoření výstrahy), stavy nebo hodnoty vlastností incidentu a vlastností entity (pouze pro trigger incidentu) a také analytické pravidlo nebo pravidla, která vygenerovala incident nebo výstrahu.

    Když se aktivuje pravidlo automatizace, zkontroluje aktivační incident nebo výstrahu s podmínkami definovanými v pravidle. U incidentů se podmínky na základě vlastností vyhodnocují v závislosti na aktuálním stavu vlastnosti v okamžiku, kdy dojde k vyhodnocení, nebo podle změn ve stavu vlastnosti (podrobnosti najdete níže). Vzhledem k tomu, že jedna událost vytvoření nebo aktualizace incidentu může aktivovat několik pravidel automatizace, pořadí , ve kterém se spouští (viz níže), je rozdíl při určování výsledku vyhodnocení podmínek. Akce definované v pravidle se spustí jenom v případě, že jsou splněny všechny podmínky.

    Trigger vytvoření incidentu

    Pro pravidla definovaná pomocí triggeru Při vytvoření incidentu můžete definovat podmínky, které kontrolují aktuální stav hodnot daného seznamu vlastností incidentu pomocí jednoho nebo několika následujících operátorů:

    • rovná se nebo se nerovná hodnotě definované v podmínce.
    • obsahuje nebo neobsahuje hodnotu definovanou v podmínce.
    • začíná nebo nezačíná hodnotou definovanou v podmínce.
    • končí nebo nekončí hodnotou definovanou v podmínce.

    Pokud například definujete název analytického pravidla jako Obsahuje == útok hrubou silou na cloudový počítač, analytické pravidlo s útokem Hrubou silou na Azure Portal nesplňuje podmínku. Pokud ale definujete název analytického pravidla jako neobsahuje == Přihlašovací údaje uživatele, pak jak útok hrubou silou na cloudový počítač, tak hrubou silou na analytická pravidla webu Azure Portal splňují podmínku.

    Poznámka:

    Aktuální stav v tomto kontextu odkazuje na okamžik vyhodnocení podmínky – to znamená okamžik, kdy se pravidlo automatizace spustí. Pokud je definováno více než jedno pravidlo automatizace, které se má spustit v reakci na vytvoření tohoto incidentu, považují se změny incidentu dříve spuštěným pravidlem automatizace za aktuální stav pravidel pozdějšího spuštění.

    Trigger aktualizace incidentu

    Podmínky vyhodnocené v pravidlech definovaných pomocí triggeru Při aktualizaci incidentu zahrnují všechny podmínky uvedené pro trigger vytvoření incidentu. Aktivační událost aktualizace ale obsahuje více vlastností, které je možné vyhodnotit.

    Jedna z těchto vlastností je aktualizována. Tato vlastnost umožňuje sledovat typ zdroje, který provedl změnu v incidentu. Můžete vytvořit podmínku, která vyhodnotí, jestli byl incident aktualizován některou z následujících hodnot v závislosti na tom, jestli jste pracovní prostor onboardovali na sjednocenou platformu operací zabezpečení:

    • Aplikace, včetně aplikací na portálech Azure i Defender.
    • Uživatel, včetně změn provedených uživateli na portálech Azure i Defender.
    • AIR pro aktualizace prostřednictvím automatizovaného vyšetřování a reakce v Microsoft Defender pro Office 365
    • Seskupení výstrah (které do incidentu přidalo výstrahy), včetně seskupení výstrah provedených analytickými pravidly a integrovanou logikou korelace XDR v programu Microsoft Defender
    • Playbook
    • Pravidlo automatizace
    • Jiné, pokud se žádná z výše uvedených hodnot nepoužije

    Pomocí této podmínky můžete například dát tomuto pravidlu automatizace pokyn, aby se spustilo při jakékoli změně incidentu, s výjimkou případu, kdy ho provedl jiný pravidlo automatizace.

    Aktivační událost aktualizace navíc používá další operátory, které kontrolují změny stavu v hodnotách vlastností incidentu a jejich aktuální stav. Podmínka změny stavu by byla splněna v následujících případech:

    Hodnota vlastnosti incidentu byla

    • změněno (bez ohledu na skutečnou hodnotu před nebo po).
    • změna z hodnoty definované v podmínce.
    • změna na hodnotu definovanou v podmínce.
    • přidáno do (to platí pro vlastnosti se seznamem hodnot).

    Vlastnost značky : jednotlivá vs. kolekce

    Značka vlastnosti incidentu je kolekce jednotlivých položek – u jednoho incidentu může být použito více značek. Můžete definovat podmínky, které kontrolují jednotlivé značky v kolekci jednotlivě, a podmínky, které kontrolují kolekci značek jako jednotku.

    • Všechny operátory jednotlivých značek kontrolují podmínku pro každou značku v kolekci. Vyhodnocení platí, pokud podmínka splňuje alespoň jednu značku.
    • Kolekce všech operátorů značek kontroluje podmínku pro kolekci značek jako jednu jednotku. Vyhodnocení platí pouze v případě, že kolekce jako celek splňuje podmínku.

    Toto rozlišení záleží, když je vaše podmínka negativní (neobsahuje) a některé značky v kolekci splňují podmínku a jiné ne.

    Podívejme se na příklad, kde je vaše podmínka, značka neobsahuje "2024" a máte dva incidenty, z nichž každá má dvě značky:

    \Incidenty ▶
    Podmínka ▼ \    		 Incident 1
    Značka 1: 2024
    Značka 2: 2023    		 Incident 2
    Značka 1: 2023
    Značka 2: 2022
    Libovolná jednotlivá značka
    neobsahuje "2024"    		 PRAVDIVÝ TRUE
    Kolekce všech značek
    neobsahuje "2024"    		 FALEŠNÝ TRUE

    V tomto příkladu v incidentu 1:

    • Pokud podmínka zkontroluje každou značku jednotlivě, znamená to, že existuje alespoň jedna značka, která splňuje podmínku (která neobsahuje "2024"), je celková podmínka pravdivá.
    • Pokud podmínka zkontroluje všechny značky v incidentu jako jednu jednotku, znamená to, že existuje alespoň jedna značka, která nesplňuje podmínku (která obsahuje "2024"), je celková podmínka nepravda.

    V incidentu 2 je výsledek stejný bez ohledu na to, jaký typ podmínky je definován.

    Podporované vlastnosti entity

    Seznam vlastností entit podporovaných jako podmínky pro pravidla automatizace najdete v referenčních informacích k pravidlu automatizace služby Microsoft Sentinel.

    Trigger pro vytvoření výstrahy

    Jedinou podmínkou, kterou je možné nakonfigurovat pro trigger vytvoření upozornění, je sada analytických pravidel, pro která se pravidlo automatizace spouští.

    Akce

    Akce je možné definovat, aby se spustily, když jsou splněny podmínky (viz výše). V pravidlu můžete definovat mnoho akcí a můžete zvolit pořadí, ve kterém se spouští (viz níže). Následující akce je možné definovat pomocí pravidel automatizace, aniž by bylo nutné provádět pokročilé funkce playbooku:

    • Přidání úkolu k incidentu – můžete vytvořit kontrolní seznam úkolů pro analytiky, které budou sledovat v rámci procesů třídění, vyšetřování a nápravy incidentu, abyste zajistili, že nedojde k chybě žádných kritických kroků.

    • Změna stavu incidentu a udržování pracovního postupu v aktualizovaném stavu

      • Při změně na "uzavřeno" zadejte důvod uzavření a přidání komentáře. To vám pomůže sledovat výkon a efektivitu a doladit, abyste snížili falešně pozitivní výsledky.

    • Změna závažnosti incidentu – můžete znovu vyhodnotit a přepsat na základě přítomnosti, nepřítomnosti, hodnot nebo atributů entit zapojených do incidentu.

    • Přiřazení incidentu vlastníkovi – to vám pomůže směrovat typy incidentů na pracovníky, kteří jsou nejvhodnější pro jejich řešení nebo pro ty nejpřístupnější pracovníky.

    • Přidání značky k incidentu – to je užitečné pro klasifikaci incidentů podle předmětu, podle útočníka nebo jakéhokoli jiného společného jmenovatele.

    Můžete také definovat akci pro spuštění playbooku, aby bylo možné provádět složitější akce reakce, včetně všech externích systémů. Playbooky, které je možné použít v pravidle automatizace, závisí na triggeru, na kterém jsou založené playbooky a pravidlo automatizace: Pouze playbooky triggeru incidentu je možné spouštět z pravidel automatizace triggeru incidentů a z pravidel automatizace triggeru výstrah je možné spouštět pouze playbooky triggeru upozornění. Můžete definovat více akcí, které volají playbooky, nebo kombinace playbooků a dalších akcí. Akce se provádějí v pořadí, v jakém jsou uvedené v pravidle.

    Playbooky využívající buď verzi Azure Logic Apps (Standard, nebo Consumption), jsou k dispozici ke spuštění z pravidel automatizace.

    Datum vypršení platnosti

    Datum vypršení platnosti můžete definovat u pravidla automatizace. Pravidlo je po uplynutí tohoto data zakázané. To je užitečné pro zpracování (tj. uzavření) incidentů "šumu" způsobených plánovanými, časově omezenými aktivitami, jako je penetrační testování.

    Objednávka

    Můžete definovat pořadí, ve kterém se pravidla automatizace spouští. Později pravidla automatizace vyhodnocují podmínky incidentu podle jeho stavu po provedení předchozích pravidel automatizace.

    Pokud například "První pravidlo automatizace" změnilo závažnost incidentu ze střední na nízké a "Druhé pravidlo automatizace" je definováno tak, aby se spustilo pouze u incidentů se střední nebo vyšší závažností, neběží u tohoto incidentu.

    Pořadí pravidel automatizace, která přidávají úkoly incidentu, určuje pořadí, ve kterém se úkoly zobrazují v daném incidentu.

    Pravidla založená na triggeru aktualizace mají vlastní samostatnou frontu objednávek. Pokud se taková pravidla aktivují tak, aby běžela na právě vytvořeném incidentu (změnou provedenou jiným pravidlem automatizace), spustí se až po dokončení všech příslušných pravidel založených na triggeru vytvoření.

    Poznámky k pořadí provádění a prioritě

    • Nastavení čísla objednávky v pravidlech automatizace určuje jejich pořadí provádění.
    • Každý typ triggeru udržuje svou vlastní frontu.
    • U pravidel vytvořených na webu Azure Portal se pole objednávky automaticky vyplní číslem, které následuje za nejvyšším číslem používaným existujícími pravidly stejného typu triggeru.
    • Pro pravidla vytvořená jinými způsoby (příkazový řádek, rozhraní API atd.) je však nutné číslo objednávky přiřadit ručně.
    • Neexistuje žádný ověřovací mechanismus, který brání více pravidlům mít stejné číslo objednávky, a to i v rámci stejného typu triggeru.
    • Dvě nebo více pravidel stejného typu triggeru můžete povolit, aby měla stejné číslo objednávky, pokud vám nezáleží na tom, ve kterém pořadí se spouští.
    • Pro pravidla stejného typu triggeru se stejným číslem objednávky modul spouštění náhodně vybere, která pravidla se spouštějí v jakém pořadí.
    • Pro pravidla různých typů triggerů incidentu se nejprve spustí všechna příslušná pravidla s typem triggeru vytvoření incidentu (podle jejich čísel objednávek) a teprve potom pravidla s typem triggeru aktualizace incidentu (podle jejich čísel objednávek).
    • Pravidla se vždy spouštějí postupně, nikdy paralelně.

    Poznámka:

    Po připojení k jednotné platformě operací zabezpečení se v případě, že během pěti až desetiminutového období provede několik změn stejného incidentu, odešle se do Microsoft Sentinelu jedna aktualizace s pouze nejnovější změnou.

    Běžné scénáře a případy použití

    Úkoly incidentu

    Pravidla automatizace umožňují standardizovat a formalizovat kroky potřebné pro třídění, vyšetřování a nápravu incidentů vytvořením úloh , které se dají použít na jeden incident, napříč skupinami incidentů nebo pro všechny incidenty podle podmínek, které jste nastavili v pravidle automatizace, a logiky detekce hrozeb v podkladových analytických pravidlech. Úkoly použité na incident se zobrazí na stránce incidentu, takže vaši analytici mají celý seznam akcí, které potřebují provést, přímo před nimi a nezmeškávají žádné kritické kroky.

    Automatizace aktivovaná incidenty a výstrahy

    Pravidla automatizace se dají aktivovat vytvořením nebo aktualizací incidentů a také vytvořením výstrah. Všechny tyto výskyty můžou aktivovat automatizované řetězy odpovědí, které můžou zahrnovat playbooky (vyžadují se speciální oprávnění).

    Aktivace playbooků pro poskytovatele Microsoftu

    Pravidla automatizace poskytují způsob, jak automatizovat zpracování výstrah zabezpečení Microsoftu použitím těchto pravidel na incidenty vytvořené z výstrah. Pravidla automatizace můžou volat playbooky (vyžadují se zvláštní oprávnění) a předat jim incidenty se všemi podrobnostmi, včetně výstrah a entit. Obecně platí, že osvědčené postupy Microsoft Sentinelu určují použití fronty incidentů jako ústředního bodu operací zabezpečení.

    Výstrahy zabezpečení Společnosti Microsoft zahrnují následující:

    • Ochrana Microsoft Entra ID
    • Microsoft Defender for Cloud
    • Microsoft Defender for Cloud Apps
    • Microsoft Defender for Office 365
    • Microsoft Defender for Endpoint
    • Microsoft Defender for Identity
    • Microsoft Defender for IoT

    Více sekvencovaných playbooků a akcí v jednom pravidlu

    Teď můžete mít téměř úplnou kontrolu nad pořadím provádění akcí a playbooků v jediném pravidlu automatizace. Řídíte také pořadí provádění samotných pravidel automatizace. To vám umožní výrazně zjednodušit playbooky, omezit je na jeden úkol nebo na malou, jednoduchou posloupnost úkolů a kombinovat tyto malé playbooky v různých kombinacích v různých pravidlech automatizace.

    Přiřazení jednoho playbooku k více analytickým pravidlům najednou

    Pokud máte úkol, který chcete automatizovat ve všech analytických pravidlech – například vytvoření lístku podpory v externím systému lístků – můžete použít jeden playbook na libovolná nebo všechna analytická pravidla – včetně jakýchkoli budoucích pravidel – na jednom snímku. Díky tomu je jednoduchá, ale opakující se údržba a úklid úkolů mnohem méně práce.

    Automatické přiřazení incidentů

    Incidenty můžete automaticky přiřadit správnému vlastníkovi. Pokud má váš SOC analytika, který se specializuje na konkrétní platformu, všechny incidenty související s danou platformou se dají danému analytikovi automaticky přiřadit.

    Potlačení incidentů

    Pravidla můžete použít k automatickému řešení incidentů, které jsou známé jako falešně/neškodné pozitivní výsledky bez použití playbooků. Například při spouštění penetračních testů, provádění plánované údržby nebo upgradů nebo testovacích automatizačních procedur může být vytvořeno mnoho falešně pozitivních incidentů, které soC chce ignorovat. Pravidlo automatizace s časovým limitem může tyto incidenty automaticky zavřít při jejich vytváření a zároveň je označit popisovačem příčiny jejich generování.

    Časově omezená automatizace

    Pro pravidla automatizace můžete přidat data vypršení platnosti. Mohou existovat jiné případy než potlačení incidentů, které zaručují časově omezenou automatizaci. Konkrétní typ incidentu můžete konkrétnímu uživateli (například internovi nebo konzultantovi) přiřadit pro určitý časový rámec. Pokud je časový rámec známý předem, můžete účinně způsobit, že pravidlo bude zakázané na konci jeho levnosti, aniž byste si to museli pamatovat.

    Automatické označování incidentů

    Do incidentů můžete automaticky přidávat značky volného textu, abyste je seskupili nebo klasifikovali podle libovolných kritérií podle vašeho výběru.

    Případy použití přidané triggerem aktualizace

    Teď, když změny provedené v incidentech můžou aktivovat pravidla automatizace, jsou pro automatizaci otevřené další scénáře.

    Rozšíření automatizace při vývoji incidentu

    Trigger aktualizace můžete použít k použití mnoha výše uvedených případů použití incidentů v průběhu vyšetřování a analytici přidávají výstrahy, komentáře a značky. Řízení seskupení výstrah v incidentech

    Aktualizace orchestrace a oznámení

    Upozorněte různé týmy a další pracovníky, když dojde k nějakým změnám incidentů, aby nezmeškali žádné důležité aktualizace. Eskalujte incidenty tím, že je přiřadíte novým vlastníkům a informujete nové vlastníky o svých přiřazeních. Řízení, kdy a jak se incidenty znovu otevřou.

    Údržba synchronizace s externími systémy

    Pokud jste při vytváření incidentů použili playbooky k vytvoření lístků v externích systémech, můžete pomocí pravidla automatizace triggeru aktualizace volat playbook, který tyto lístky aktualizuje.

    Spouštění pravidel automatizace

    Pravidla automatizace se spouští postupně podle pořadí, které určíte. Každé pravidlo automatizace se spustí poté, co předchozí pravidlo dokončí jeho spuštění. V rámci pravidla automatizace se všechny akce spouštějí postupně v pořadí, v jakém jsou definovány.

    Akce playbooku v rámci pravidla automatizace se můžou za určitých okolností zacházet odlišně podle následujících kritérií:

    Čas běhu playbooku Pravidlo automatizace přejde na další akci...
    Méně než sekunda Ihned po dokončení playbooku
    Méně než dvě minuty Až dvě minuty po spuštění playbooku,
    ale po dokončení playbooku maximálně 10 sekund
    Více než dvě minuty Dvě minuty po spuštění playbooku,
    bez ohledu na to, zda byl dokončen nebo nebyl dokončen

    Oprávnění pro pravidla automatizace ke spouštění playbooků

    Když pravidlo automatizace Microsoft Sentinelu spustí playbook, použije pro tuto akci speciální účet služby Microsoft Sentinel, který je speciálně autorizovaný. Použití tohoto účtu (na rozdíl od vašeho uživatelského účtu) zvyšuje úroveň zabezpečení služby.

    Aby mohlo pravidlo automatizace spustit playbook, tento účet musí mít udělená explicitní oprávnění ke skupině prostředků, ve které se playbook nachází. V tomto okamžiku může jakékoli pravidlo automatizace spouštět libovolný playbook v této skupině prostředků.

    Když konfigurujete pravidlo automatizace a přidáte akci run playbooku, zobrazí se rozevírací seznam playbooků. Playbooky, u kterých Microsoft Sentinel nemá oprávnění, se zobrazují jako nedostupné (šedě). Microsoft Sentinel můžete udělit oprávnění ke skupinám prostředků playbooků na místě výběrem odkazu Spravovat oprávnění playbooku. K udělení těchto oprávnění potřebujete oprávnění vlastníka těchto skupin prostředků. Podívejte se na úplné požadavky na oprávnění.

    Oprávnění ve víceklientové architektuře

    Pravidla automatizace plně podporují nasazení mezi pracovními prostory a více tenanty (v případě víceklientů pomocí Azure Lighthouse).

    Proto pokud vaše nasazení Microsoft Sentinelu používá víceklientské architektury, můžete mít v jednom tenantovi pravidlo automatizace, které běží v jiném tenantovi, ale oprávnění pro Sentinel ke spouštění playbooků musí být definována v tenantovi, kde se nacházejí playbooky, ne v tenantovi, ve kterém jsou definovaná pravidla automatizace.

    V konkrétním případě poskytovatele spravované služby zabezpečení (MSSP), kde tenant poskytovatele služeb spravuje pracovní prostor Služby Microsoft Sentinel v tenantovi zákazníka, existují dva konkrétní scénáře, které vyžadují vaši pozornost:

    • Pravidlo automatizace vytvořené v tenantovi zákazníka je nakonfigurováno pro spuštění playbooku umístěného v tenantovi poskytovatele služeb.

      Tento přístup se obvykle používá k ochraně duševního vlastnictví v playbooku. Pro tento scénář není potřeba nic zvláštního. Při definování akce playbooku v pravidle automatizace a dostanete se do fáze, ve které udělíte oprávnění Microsoft Sentinelu k příslušné skupině prostředků, ve které se playbook nachází (pomocí panelu Spravovat oprávnění playbooku), můžete zobrazit skupiny prostředků patřící do tenanta poskytovatele služeb mezi těmi, ze kterých si můžete vybrat. Podívejte se na celý proces, který je zde popsaný.

    • Pravidlo automatizace vytvořené v pracovním prostoru zákazníka (při přihlášení k tenantovi poskytovatele služeb) je nakonfigurované pro spuštění playbooku umístěného v tenantovi zákazníka.

      Tato konfigurace se používá, když není potřeba chránit duševní vlastnictví. Aby tento scénář fungoval, musí být oprávnění ke spuštění playbooku udělena službě Microsoft Sentinel v obou tenantech. V tenantovi zákazníka je udělíte na panelu Spravovat oprávnění playbooku stejně jako ve výše uvedeném scénáři. Pokud chcete udělit příslušná oprávnění v tenantovi poskytovatele služeb, musíte přidat další delegování Azure Lighthouse, které uděluje přístupová práva k aplikaci Azure Security Insights s rolí Přispěvatel služby Microsoft Sentinel Automation ve skupině prostředků, ve které se nachází playbook.

      Scénář vypadá takto:

      Architektura pravidel automatizace s více tenanty

      Pokyny k nastavení najdete v našich pokynech .

    Vytváření a správa pravidel automatizace

    V závislosti na konkrétní potřebě a použití můžete vytvářet a spravovat pravidla automatizace z různých oblastí v Microsoft Sentinelu nebo na jednotné platformě operací zabezpečení.

    • Stránka Automation

      Pravidla automatizace je možné centrálně spravovat na stránce Automation na kartě Pravidla automatizace. Odtud můžete vytvořit nová pravidla automatizace a upravit stávající pravidla. Pravidla automatizace můžete také přetáhnout, aby se změnilo pořadí provádění, a můžete je povolit nebo zakázat.

      Na stránce Automation uvidíte všechna pravidla definovaná v pracovním prostoru spolu se stavem (Povoleno/Zakázáno) a na která analytická pravidla se použijí.

      Pokud potřebujete pravidlo automatizace, které se vztahuje na incidenty z XDR v programu Microsoft Defender nebo z mnoha analytických pravidel v Microsoft Sentinelu, vytvořte ho přímo na stránce Automation .

    • Průvodce analytickým pravidlem

      Na kartě Automatizovaná odpověď v průvodci analytickým pravidlem Služby Microsoft Sentinel můžete v části Pravidla automatizace zobrazit, upravit a vytvořit pravidla automatizace, která se vztahují na konkrétní analytické pravidlo, které se v průvodci vytváří nebo upravuje.

      Když tady vytvoříte pravidlo automatizace, zobrazí se na panelu Vytvořit nové pravidlo automatizace stav analytického pravidla jako nedostupný, protože toto pravidlo je už nastavené tak, aby platilo jenom pro analytické pravidlo, které upravujete v průvodci. Všechny ostatní možnosti konfigurace jsou pro vás stále dostupné.

    • Stránka Incidenty

      Můžete také vytvořit pravidlo automatizace ze stránky Incidenty , aby bylo možné reagovat na jeden opakovaný incident. To je užitečné při vytváření pravidla potlačení pro automatické zavření "hlučných" incidentů.

      Když odsud vytvoříte pravidlo automatizace, panel Vytvořit nové pravidlo automatizace naplní všechna pole hodnotami z incidentu. Pojmenuje pravidlo stejným názvem jako incident, použije ho na analytické pravidlo, které incident vygenerovalo, a jako podmínky pravidla použije všechny dostupné entity v incidentu. Ve výchozím nastavení navrhuje také akci potlačení (uzavření) a navrhne datum vypršení platnosti pravidla. Můžete přidat nebo odebrat podmínky a akce a změnit datum vypršení platnosti podle potřeby.

    Export a import pravidel automatizace

    Exportujte pravidla automatizace do souborů šablon Azure Resource Manageru (ARM) a importujte pravidla z těchto souborů jako součást správy a řízení nasazení Microsoft Sentinelu jako kódu. Akce exportu vytvoří soubor JSON v umístění pro stahování prohlížeče, který pak můžete přejmenovat, přesunout a jinak zpracovat stejně jako jakýkoli jiný soubor.

    Exportovaný soubor JSON je nezávislý na pracovním prostoru, takže ho můžete importovat do jiných pracovních prostorů a dokonce i jiných tenantů. Jako kód se dá také řídit verzemi, aktualizovat a nasadit v rámci spravované architektury CI/CD.

    Soubor obsahuje všechny parametry definované v pravidle automatizace. Pravidla libovolného typu triggeru je možné exportovat do souboru JSON.

    Pokyny k exportu a importu pravidel automatizace najdete v tématu Export a import pravidel automatizace služby Microsoft Sentinel.

    Další kroky

    V tomto dokumentu jste se dozvěděli, jak vám pravidla automatizace můžou pomoct centrálně spravovat automatizaci odpovědí pro incidenty a výstrahy Microsoft Sentinelu.