Sdílet prostřednictvím

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

  • Platí pro: Microsoft Sentinel in the Microsoft Defender portal, Microsoft Sentinel in the Azure 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é

Po 31. březnu 2027 už Microsoft Sentinel nebude podporován na webu Azure Portal a bude dostupný jenom na portálu Microsoft Defender. Všichni zákazníci používající Microsoft Sentinel na webu Azure Portal budou přesměrováni na portál Defender a budou používat Microsoft Sentinel jenom na portálu Defender.

Pokud na webu Azure Portal stále používáte Microsoft Sentinel, doporučujeme začít plánovat přechod na portál Defender , abyste zajistili hladký přechod a plně využili sjednoceného prostředí operací zabezpečení, které nabízí 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 k incidentům pro analytiky, kteří je mají sledovat.
    • Potlačit rušivé 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 mohou být také mechanismem, prostřednictvím kterého spouštíte playbook jako reakci na výstrahu, která není spojena s incidentem.

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 na změnu incidentu určitým způsobem nebo použití playbooku, který provádí složitější akce a spolupracuje s jinými službami.

Spouštěče

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 Portál Microsoft Defenderu:
  • Na portálu Microsoft Defenderu se vytvoří nový incident.

    Microsoft Sentinel není onboardovaný na portál Defenderu:
  • 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 otříděno).
  • Vlastník incidentu je přiřazen nebo změněn.
  • Závažnost incidentu je zvýšena nebo snížena.
  • Výstrahy se přidají k incidentu.
  • Komentáře, značky nebo taktiky se přidají do incidentu.
    		•
    Při vytvoření výstrahy
  • Výstraha je vytvořena naplánovaným nebo analytickým pravidlem NRT služby Microsoft Sentinel.
    		•

    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 preferovaným přístupem automatizace spuštěná incidenty. V rámci Microsoft Sentinel je incident jako "případový soubor" – shromáždění 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 Sentinel nasazený do portálu Defender. V tomto scénáři probíhá veškeré vytváření incidentů na portálu 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 vhodný existující incident, ke kterému má být výstraha přidána. 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.

    • Pracovní postup aktivovaný výstrahou může odeslat tuto výstrahu do externího systému pro vytvoření a správu incidentů, přičemž 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ějí (viz níže), má význam pro určení výsledku hodnocení podmínek. Akce definované v pravidle se spustí jenom v případě, že jsou splněny všechny podmínky.

    Vytvoření triggeru 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á hodnotou nebo nezačíná hodnotou definovanou v podmínce.
    • končí hodnotou definovanou v podmínce 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í.

    Spouštěč 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í, zda byl incident aktualizován jednou z následujících entit, v závislosti na tom, jestli jste pracovní prostor připojili k portálu Defender.

    • Aplikace, včetně aplikací v 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
    • Příručka
    • Pravidlo automatizace
    • Jiné, pokud se žádná z výše uvedených hodnot nepoužije

    Pomocí této podmínky můžete například nařídit tomuto automatizačnímu pravidlu, aby se spustilo při jakékoli změně incidentu, s výjimkou, kdy byla změna provedena jiným pravidlem automatizace.

    Aktualizační spouštěč navíc používá další operátory, které kontrolují změny stavu vlastností incidentu i 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

    Vlastnost Tag incidentu je kolekce jednotlivých položek – na jeden incident může být aplikováno 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í je pravdivé, pokud alespoň jedna značka splňuje podmínku.
    • Kolekce všech značek operátoři kontrolují podmínku vůči kolekci značek jako jednotný celek. Vyhodnocení platí pouze v případě, že kolekce jako celek splňuje podmínku.

    Toto rozlišování je důležité, když je vaše podmínka záporná (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
    Jakákoli jednotlivá značka
    neobsahuje "2024"    		 PRAVDIVÝ PRAVDIVÝ
    Kolekce všech značek
    neobsahuje "2024"    		 FALEŠNÝ PRAVDIVÝ

    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řeřadit priority 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, abyste mohli provádět složitější odezvové akce, včetně těch, které zahrnují externí systémy. 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é spouštějí 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í službu Azure Logic Apps (Standard nebo Consumption) je možné spouštět 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 trigeru 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.
    • Můžete povolit, aby dvě nebo více pravidel stejného typu spouštěče měla stejné pořadové číslo, pokud vám nezáleží na pořadí jejich spuštění.
    • 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 vždy běží posloupně, nikdy paralelně.

    Poznámka:

    Po nastavení na portálu Defender, pokud se během pěti až deseti minut provede několik změn na stejném incidentu, odešle se do systému Microsoft Sentinel pouze jedna aktualizace s poslední změnou.

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

    Incidentní úkoly

    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 poplachy

    Pravidla automatizace se dají aktivovat vytvořením nebo aktualizací incidentů a také vytvořením výstrah. Všechny tyto incidenty mohou aktivovat automatizované řetězy odpovědí, které mohou zahrnovat playbooky (pro které jsou vyžadována 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 mohou volat playbooky (je nutné mít zvláštní oprávnění) a mohou předat incidenty playbookům se všemi jejich 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 pro cloudové aplikace
    • Microsoft Defender pro Office 365
    • Microsoft Defender for Endpoint (ochrana koncových bodů)
    • 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 všechna pravidla nebo kterákoli z nich – včetně jakýchkoli budoucích pravidel – najednou. Díky tomu je jednoduchá, ale opakující se údržba a úklidové činnosti méně namáhavé.

    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 efektivně způsobit, že se pravidlo na konci jeho relevantnosti deaktivuje, 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é spouštěčem 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

    Můžete použít trigger aktualizace k aplikaci mnoha výše zmíněných případů užití na incidenty během postupu jejich vyšetřování, kdy analytici přidávají výstrahy, komentáře a značky. Kontrola seskupování 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 jejich přiřazení. Kontrola, kdy a jak dochází ke znovuotevření incidentů.

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

    Pokud jste při vytváření incidentů použili playbook k vytvoření lístků v externích systémech, můžete pomocí pravidla automatizace aktualizačního triggeru 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 mohou být za určitých okolností vyhodnoceny odlišně podle následujících kritérií:

    Doba spuštění průvodce Pravidlo automatizace pokračuje 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 ne více než 10 sekund po dokončení playbooku
    Více než dvě minuty Dvě minuty po spuštění playbooku,
    bez ohledu na to, zda byl dokončen či nikoli

    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 spuštění 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ů přímo v rozhraní 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 multitenantní nasazení (v případě nasazení tenantů 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 manuálu. 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, který se nachází 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 jim udělíte oprávnění na panelu Správa 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

    Pravidla automatizace můžete vytvářet a spravovat z různých oblastí v Microsoft Sentinelu nebo na portálu Defender v závislosti na konkrétní potřebě a případu použití.

    • Stránka automatizace

      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 podmínka analytického pravidla jako nedostupná, protože toto pravidlo je už nastavené tak, aby se vztahovalo pouze na analytické pravidlo, které editujete v průvodci. Všechny ostatní možnosti konfigurace jsou pro vás stále dostupné.

    • Stránka incidentů

      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 pravidla 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.

    • Last updated on