Automatizzare la risposta alle minacce con playbook in Microsoft Sentinel

Questo articolo illustra i playbook di Microsoft Sentinel e come usarli per implementare le operazioni soAR (Security Orchestration, Automation and Response), ottenendo risultati migliori risparmiando tempo e risorse.

Importante

Microsoft Sentinel è disponibile come parte dell'anteprima pubblica per la piattaforma unificata per le operazioni di sicurezza nel portale di Microsoft Defender. Per altre informazioni, vedere Microsoft Sentinel nel portale di Microsoft Defender.

Che cos'è un playbook?

Gli analisti SOC vengono in genere inondati con avvisi di sicurezza ed eventi imprevisti regolarmente, a volumi così grandi che il personale disponibile viene sovraccaricato. Questo risultato è troppo spesso in situazioni in cui molti avvisi vengono ignorati e molti eventi imprevisti non vengono esaminati, lasciando l'organizzazione vulnerabile agli attacchi che non vengono rilevati.

Molti, se non la maggior parte, di questi avvisi e eventi imprevisti sono conformi a modelli ricorrenti che possono essere risolti da set specifici e definiti di azioni correttive. Gli analisti sono anche responsabili della correzione e dell'analisi di base degli eventi imprevisti che gestiscono per affrontare. Nella misura in cui queste attività possono essere automatizzate, un SOC può essere molto più produttivo ed efficiente, consentendo agli analisti di dedicare più tempo ed energia all'attività investigativa.

Un playbook è una raccolta di queste azioni correttive eseguite da Microsoft Sentinel come routine, per automatizzare e orchestrare la risposta alle minacce. Può essere eseguito in due modi:

  • Manualmente su richiesta, su un'entità o un avviso specifico
  • In risposta a avvisi o eventi imprevisti specifici, quando viene attivata da una regola di automazione.

Ad esempio, se un account e un computer sono compromessi, un playbook può isolare il computer dalla rete e bloccare l'account quando il team SOC riceve una notifica dell'evento imprevisto.

Mentre la scheda Playbook attivi nella pagina Automazione visualizza tutti i playbook attivi disponibili in tutte le sottoscrizioni selezionate, per impostazione predefinita un playbook può essere usato solo all'interno della sottoscrizione a cui appartiene, a meno che non si concedano specificamente le autorizzazioni di Microsoft Sentinel al gruppo di risorse del playbook.

Dopo l'onboarding nella piattaforma unificata per le operazioni di sicurezza, nella scheda Playbook attivi viene visualizzato un filtro predefinito con la sottoscrizione dell'area di lavoro di cui è stato eseguito l'onboarding. Nella portale di Azure aggiungere dati per altre sottoscrizioni usando il filtro della sottoscrizione di Azure.

Modelli di playbook

Un modello di playbook è un flusso di lavoro predefinito, testato e pronto per l'uso che può essere personalizzato per soddisfare le proprie esigenze. I modelli possono anche fungere da riferimento per le procedure consigliate quando si sviluppano playbook da zero o come ispirazione per i nuovi scenari di automazione.

I modelli di playbook non sono utilizzabili come playbook stessi. È possibile creare un playbook (una copia modificabile del modello) da essi.

È possibile ottenere modelli di playbook dalle origini seguenti:

  • Nella pagina Automazione la scheda Modelli playbook elenca i modelli di playbook installati. È possibile creare più playbook attivi dallo stesso modello.

    Quando viene pubblicata una nuova versione del modello, i playbook attivi creati da tale modello vengono visualizzati nella scheda Playbook attivi che visualizza un'etichetta che indica che è disponibile un aggiornamento.

  • I modelli di playbook sono disponibili come parte delle soluzioni di prodotto o del contenuto autonomo installato dalla pagina Hub contenuto in Microsoft Sentinel. Per altre informazioni, vedere Contenuti e soluzioni di Microsoft Sentinel e Individuare e gestire contenuti predefiniti di Microsoft Sentinel.

  • Il repository GitHub di Microsoft Sentinel contiene molti modelli di playbook. Possono essere distribuiti in una sottoscrizione di Azure selezionando il pulsante Distribuisci in Azure .

Tecnicamente, un modello di playbook è un modello di Resource Manager costituito da diverse risorse: un flusso di lavoro App per la logica di Azure e connessioni API per ogni connessione interessata.

Importante

I modelli di playbook sono attualmente disponibili in ANTEPRIMA. Vedere le Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per altre condizioni legali applicabili alle funzionalità di Azure disponibili in versione beta, in anteprima o non ancora rilasciate nella disponibilità generale.

App per la logica di Azure concetti di base

I playbook in Microsoft Sentinel si basano su flussi di lavoro creati in App per la logica di Azure, un servizio cloud che consente di pianificare, automatizzare e orchestrare attività e flussi di lavoro in tutti i sistemi aziendali. Ciò significa che i playbook possono sfruttare tutte le potenzialità e le funzionalità dei modelli predefiniti in App per la logica di Azure.

Nota

App per la logica di Azure crea risorse separate, quindi potrebbero essere applicati costi aggiuntivi. Per altre informazioni, visitare la pagina dei prezzi di App per la logica di Azure.

App per la logica di Azure comunica con altri sistemi e servizi usando i connettori. Di seguito è riportata una breve spiegazione dei connettori e alcuni dei relativi attributi importanti:

  • Connettore gestito: un set di azioni e trigger che incapsula le chiamate API a un determinato prodotto o servizio. App per la logica di Azure offre centinaia di connettori per comunicare con Microsoft e non servizi Microsoft. Per altre informazioni, vedere connettori App per la logica di Azure e la relativa documentazione

  • Connettore personalizzato: è possibile comunicare con i servizi che non sono disponibili come connettori predefiniti. I connettori personalizzati rispondono a questa esigenza consentendo di creare (e persino condividere) un connettore e definire i propri trigger e azioni. Per altre informazioni, vedere Creare connettori personalizzati App per la logica di Azure.

  • Connettore Microsoft Sentinel: per creare playbook che interagiscono con Microsoft Sentinel, usare il connettore Microsoft Sentinel. Per altre informazioni, vedere la documentazione del connettore di Microsoft Sentinel.

  • Trigger: componente connettore che avvia un flusso di lavoro, in questo caso, un playbook. Il trigger di Microsoft Sentinel definisce lo schema previsto dal playbook quando viene attivato. Il connettore Di Microsoft Sentinel ha attualmente tre trigger:

    • Trigger di avviso: il playbook riceve l'avviso come input.
    • Trigger di entità (anteprima): il playbook riceve un'entità come input.
    • Trigger di eventi imprevisti: il playbook riceve l'evento imprevisto come input, insieme a tutti gli avvisi e le entità inclusi.
  • Azioni: per azioni si intendono tutti i passaggi che si verificano dopo il trigger. Possono essere disposti in sequenza, in parallelo o in una matrice di condizioni complesse.

  • Campi dinamici: campi temporanei, determinati dallo schema di output di trigger e azioni e popolati dal relativo output effettivo, che possono essere usati nelle azioni che seguono.

Tipi di app per la logica

Microsoft Sentinel supporta ora i tipi di risorse dell'app per la logica seguenti:

  • Consumo, che viene eseguito in App per la logica di Azure multi-tenant e usa il motore di App per la logica di Azure classico e originale.
  • Standard, che viene eseguito in App per la logica di Azure a tenant singolo e usa un motore di App per la logica di Azure riprogettato.

Il tipo di app per la logica Standard offre prestazioni più elevate, prezzi fissi, funzionalità multiple del flusso di lavoro, gestione più semplice delle connessioni API, funzionalità di rete native come il supporto per reti virtuali ed endpoint privati (vedere la nota seguente), funzionalità CI/CD predefinite, migliore integrazione di Visual Studio Code, una finestra di progettazione del flusso di lavoro aggiornata e altro ancora.

Per usare questa versione dell'app per la logica, creare nuovi playbook Standard in Microsoft Sentinel (vedere la nota seguente). È possibile usare questi playbook negli stessi modi in cui si usano playbook a consumo:

  • Collegarli alle regole di automazione e/o alle regole di analisi.
  • Eseguirli su richiesta, sia da eventi imprevisti che da avvisi.
  • Gestirli nella scheda Playbook attivi.

Nota

  • I flussi di lavoro standard attualmente non supportano i modelli playbook, il che significa che non è possibile creare un playbook basato su flusso di lavoro Standard direttamente in Microsoft Sentinel. È invece necessario creare il flusso di lavoro in App per la logica di Azure. Dopo aver creato il flusso di lavoro, viene visualizzato come playbook in Microsoft Sentinel.

  • I flussi di lavoro Standard delle app per la logica supportano endpoint privati come indicato in precedenza, ma Microsoft Sentinel richiede la definizione di criteri di restrizione di accesso nelle app per la logica per supportare l'uso di endpoint privati nei playbook basati su flussi di lavoro Standard.

    Se non sono definiti criteri di restrizione dell'accesso, i flussi di lavoro con endpoint privati potrebbero essere ancora visibili e selezionabili quando si sceglie un playbook da un elenco in Microsoft Sentinel (se eseguire manualmente, aggiungere a una regola di automazione o nella raccolta playbook) e sarà possibile selezionarli, ma l'esecuzione avrà esito negativo.

  • Un indicatore identifica i flussi di lavoro Standard come con stato o senza stato. Microsoft Sentinel non supporta attualmente flussi di lavoro senza stato. Informazioni sulle differenze tra flussi di lavoro con stato e senza stato.

Esistono molte differenze tra questi due tipi di risorse, alcuni dei quali influiscono su alcuni dei modi in cui possono essere usati nei playbook in Microsoft Sentinel. In questi casi, la documentazione indica ciò che è necessario conoscere. Per altre informazioni, vedere Differenze tra il tipo di risorsa e l'ambiente host nella documentazione di App per la logica di Azure.

Autorizzazioni obbligatorie

Per consentire al team di SecOps di usare App per la logica di Azure per creare ed eseguire playbook in Microsoft Sentinel, assegnare ruoli di Azure al team delle operazioni di sicurezza o a utenti specifici del team. Di seguito vengono descritti i diversi ruoli disponibili e le attività per le quali devono essere assegnati:

Ruoli di Azure per App per la logica di Azure

  • Collaboratore app per la logica consente di gestire le app per la logica e di eseguire playbook, ma non è possibile modificare l'accesso (per cui è necessario il ruolo Proprietario ).
  • L'operatore app per la logica consente di leggere, abilitare e disabilitare le app per la logica, ma non è possibile modificarle o aggiornarle.

Ruoli di Azure per Microsoft Sentinel

  • Il ruolo Collaboratore di Microsoft Sentinel consente di collegare un playbook a una regola di analisi o automazione.

  • Il ruolo risponditore di Microsoft Sentinel consente di accedere a un evento imprevisto per eseguire manualmente un playbook. Ma per eseguire effettivamente il playbook, è anche necessario...

    • Il ruolo Operatore playbook di Microsoft Sentinel consente di eseguire manualmente un playbook.
    • Collaboratore automazione di Microsoft Sentinel consente alle regole di automazione di eseguire playbook. Non viene usato per altri scopi.

Altre informazioni

Passaggi per la creazione di un playbook

Casi d'uso per i playbook

La piattaforma App per la logica di Azure offre centinaia di azioni e trigger, quindi è possibile creare quasi tutti gli scenari di automazione. Microsoft Sentinel consiglia di iniziare con gli scenari SOC seguenti, per i quali sono disponibili modelli di playbook pronti per l'uso:

Arricchimento

Raccogliere i dati e collegarli all'evento imprevisto per prendere decisioni più intelligenti.

Ad esempio:

Un evento imprevisto di Microsoft Sentinel è stato creato da un avviso da una regola di analisi che genera entità di indirizzo IP.

L'evento imprevisto attiva una regola di automazione che esegue un playbook con la procedura seguente:

  • Iniziare quando viene creato un nuovo evento imprevisto di Microsoft Sentinel. Le entità rappresentate nell'evento imprevisto vengono archiviate nei campi dinamici del trigger di evento imprevisto.

  • Per ogni indirizzo IP, eseguire una query su un provider di Intelligence sulle minacce esterno, ad esempio Virus Total, per recuperare più dati.

  • Aggiungere i dati restituiti e le informazioni dettagliate come commenti dell'evento imprevisto.

Sincronizzazione bidirezionale

I playbook possono essere usati per sincronizzare gli eventi imprevisti di Microsoft Sentinel con altri sistemi di ticket.

Ad esempio:

Creare una regola di automazione per tutta la creazione di eventi imprevisti e allegare un playbook che apre un ticket in ServiceNow:

  • Iniziare quando viene creato un nuovo evento imprevisto di Microsoft Sentinel.

  • Creare un nuovo ticket in ServiceNow.

  • Includere nel ticket il nome dell'evento imprevisto, i campi importanti e un URL per l'evento imprevisto di Microsoft Sentinel per semplificare la pivoting.

Orchestrazione

Usare la piattaforma di chat SOC per controllare meglio la coda degli eventi imprevisti.

Ad esempio:

Un evento imprevisto di Microsoft Sentinel è stato creato da un avviso da una regola di analisi che genera entità nome utente e indirizzo IP.

L'evento imprevisto attiva una regola di automazione che esegue un playbook con la procedura seguente:

  • Iniziare quando viene creato un nuovo evento imprevisto di Microsoft Sentinel.

  • Inviare un messaggio al canale delle operazioni di sicurezza in Microsoft Teams o Slack per assicurarsi che gli analisti della sicurezza siano a conoscenza dell'evento imprevisto.

  • Inviare tutte le informazioni nell'avviso tramite posta elettronica all'amministratore di rete senior e all'amministratore della sicurezza. Il messaggio di posta elettronica includerà i pulsanti di opzione Blocca e Ignora utente.

  • Attendere che venga ricevuta una risposta dagli amministratori, quindi continuare l'esecuzione.

  • Se gli amministratori hanno scelto Blocca, inviare un comando al firewall per bloccare l'indirizzo IP nell'avviso e un altro in Microsoft Entra ID per disabilitare l'utente.

Response

Rispondere immediatamente alle minacce, con dipendenze umane minime.

Due esempi:

Esempio 1: Rispondere a una regola di analisi che indica un utente compromesso, come rilevato da Microsoft Entra ID Protection:

  • Iniziare quando viene creato un nuovo evento imprevisto di Microsoft Sentinel.

  • Per ogni entità utente nell'evento imprevisto sospettato di compromissione:

    • Inviare un messaggio di Teams all'utente, richiedendo di confermare che l'utente ha adottato l'azione sospetta.

    • Rivolgersi a Microsoft Entra ID Protection per confermare lo stato dell'utente come compromesso. Microsoft Entra ID Protection contrassegnerà l'utente come rischioso e applicherà i criteri di imposizione già configurati, ad esempio per richiedere all'utente di usare l'autenticazione a più fattori al successivo accesso.

      Nota

      Questa particolare azione Microsoft Entra non avvia alcuna attività di imposizione sull'utente, né avvia alcuna configurazione dei criteri di imposizione. Indica solo a Microsoft Entra ID Protection di applicare i criteri già definiti in base alle esigenze. Qualsiasi imposizione dipende interamente dai criteri appropriati definiti in Microsoft Entra ID Protection.

Esempio 2: Rispondere a una regola di analisi che indica un computer compromesso, come rilevato da Microsoft Defender per endpoint:

  • Iniziare quando viene creato un nuovo evento imprevisto di Microsoft Sentinel.

  • Usare l'azione Entities - Get Hosts in Microsoft Sentinel per analizzare i computer sospetti inclusi nelle entità degli eventi imprevisti.

  • Eseguire un comando per Microsoft Defender per endpoint isolare i computer nell'avviso.

Risposta manuale durante l'indagine o durante la ricerca

Rispondere alle minacce nel corso dell'attività investigativa attiva senza pivot fuori contesto.

Grazie al nuovo trigger di entità (ora in anteprima), è possibile intervenire immediatamente sui singoli attori di minacce individuati durante un'indagine, uno alla volta, direttamente dall'interno dell'indagine. Questa opzione è disponibile anche nel contesto di ricerca delle minacce, non connessa a qualsiasi evento imprevisto specifico. È possibile selezionare un'entità nel contesto ed eseguirvi azioni direttamente, risparmiando tempo e riducendo la complessità.

Le azioni che è possibile eseguire sulle entità usando questo tipo di playbook includono:

  • Blocco di un utente compromesso.
  • Blocco del traffico da un indirizzo IP dannoso nel firewall.
  • Isolamento di un host compromesso nella rete.
  • Aggiunta di un indirizzo IP a un watchlist di indirizzi sicuro/non sicuro o a CMDB esterno.
  • Ottenere un report hash di file da un'origine di Intelligence per le minacce esterna e aggiungerlo a un evento imprevisto come commento.

Come eseguire un playbook

I playbook possono essere eseguiti manualmente o automaticamente.

Sono progettati per essere eseguiti automaticamente e idealmente questo è il modo in cui devono essere eseguiti nel normale corso delle operazioni. Si esegue automaticamente un playbook definendolo come risposta automatica in una regola di analisi (per gli avvisi) o come azione in una regola di automazione (per gli eventi imprevisti).

Ci sono circostanze, tuttavia, che richiedono l'esecuzione manuale dei playbook. Ad esempio:

  • Quando si crea un nuovo playbook, è necessario testarlo prima di inserirlo nell'ambiente di produzione.

  • Potrebbero esserci situazioni in cui vuoi avere più controllo e input umano in quando e se un determinato playbook viene eseguito.

    Per eseguire manualmente un playbook, aprire un evento imprevisto, un avviso o un'entità e selezionare ed eseguire il playbook associato visualizzato. Attualmente questa funzionalità è disponibile a livello generale per gli avvisi e in anteprima per eventi imprevisti ed entità.

Impostare una risposta automatica

I team delle operazioni di sicurezza possono ridurre significativamente il carico di lavoro automatizzando completamente le risposte di routine a tipi ricorrenti di eventi imprevisti e avvisi, consentendo di concentrarsi maggiormente su eventi imprevisti e avvisi univoci, analizzando modelli, ricerca di minacce e altro ancora.

L'impostazione della risposta automatica significa che ogni volta che viene attivata una regola di analisi, oltre a creare un avviso, la regola eseguirà un playbook, che riceverà come input l'avviso creato dalla regola.

Se l'avviso crea un evento imprevisto, l'evento imprevisto attiverà una regola di automazione che a sua volta potrebbe eseguire un playbook, che riceverà come input l'evento imprevisto creato dall'avviso.

Risposta automatica per la creazione di avvisi

Per i playbook attivati dalla creazione di avvisi e ricevere avvisi come input (il primo passaggio è "Avviso di Microsoft Sentinel"), allegare il playbook a una regola di analisi:

  1. Modificare la regola di analisi che genera l'avviso per cui si vuole definire una risposta automatica.

  2. In Automazione avvisi nella scheda Risposta automatica selezionare il playbook o i playbook che questa regola di analisi attiverà quando viene creato un avviso.

Risposta automatica alla creazione di eventi imprevisti

Per i playbook che vengono attivati dalla creazione di eventi imprevisti e ricevono eventi imprevisti come input (il primo passaggio è "Evento imprevisto di Microsoft Sentinel"), creare una regola di automazione e definire un'azione Esegui playbook in esso. Questa operazione può essere eseguita in due modi:

  • Modificare la regola di analisi che genera l'evento imprevisto per cui si vuole definire una risposta automatica. In Automazione degli eventi imprevisti nella scheda Risposta automatica creare una regola di automazione. Verrà creata una risposta automatica solo per questa regola di analisi.

  • Nella scheda Regole di automazione della pagina Automazione creare una nuova regola di automazione e specificare le condizioni appropriate e le azioni desiderate. Questa regola di automazione verrà applicata a qualsiasi regola di analisi che soddisfi le condizioni specificate.

    Nota

    Microsoft Sentinel richiede le autorizzazioni per eseguire playbook di attivazione degli eventi imprevisti.

    Per eseguire un playbook basato sul trigger dell'evento imprevisto, sia manualmente che da una regola di automazione, Microsoft Sentinel usa un account del servizio appositamente autorizzato a farlo. L'uso di questo account (anziché dell'account utente) aumenta il livello di sicurezza del servizio e consente all'API delle regole di automazione di supportare i casi d'uso CI/CD.

    A questo account devono essere concesse autorizzazioni esplicite (che hanno il ruolo collaboratore di Automazione di Microsoft Sentinel) nel gruppo di risorse in cui risiede il playbook. A questo punto, sarà possibile eseguire qualsiasi playbook in tale gruppo di risorse, manualmente o da qualsiasi regola di automazione.

    Quando si aggiunge l'azione del playbook di esecuzione a una regola di automazione, verrà visualizzato un elenco a discesa di playbook per la selezione. I playbook a cui Microsoft Sentinel non dispone delle autorizzazioni verranno visualizzati come non disponibili ("disattivato"). È possibile concedere l'autorizzazione a Microsoft Sentinel sul posto selezionando il collegamento Gestisci autorizzazioni playbook.

    In uno scenario multi-tenant (Lighthouse) è necessario definire le autorizzazioni per il tenant in cui risiede il playbook, anche se la regola di automazione che chiama il playbook si trova in un tenant diverso. A tale scopo, è necessario disporre delle autorizzazioni proprietario per il gruppo di risorse del playbook.

    Esiste uno scenario univoco per un provider di servizi di sicurezza gestito (MSSP), in cui un provider di servizi, durante l'accesso al proprio tenant, crea una regola di automazione nell'area di lavoro di un cliente usando Azure Lighthouse. Questa regola di automazione chiama quindi un playbook appartenente al tenant del cliente. In questo caso, è necessario concedere autorizzazioni a Microsoft Sentinel per entrambi i tenant. Nel tenant del cliente è possibile concedere le autorizzazioni nel pannello Gestisci autorizzazioni del playbook, proprio come nello scenario multi-tenant normale. Per concedere le autorizzazioni pertinenti nel tenant del provider di servizi, è necessario aggiungere una delega di Azure Lighthouse aggiuntiva che concede i diritti di accesso all'app Azure Security Insights , con il ruolo Collaboratore automazione di Microsoft Sentinel nel gruppo di risorse in cui risiede il playbook. Informazioni su come aggiungere questa delega.

Vedere le istruzioni complete per la creazione di regole di automazione.

Eseguire manualmente un playbook

L'automazione completa è la soluzione migliore per tutte le attività di gestione, analisi e mitigazione degli eventi imprevisti che si ha familiarità con l'automazione. Detto questo, ci possono essere buoni motivi per una sorta di automazione ibrida: l'uso di playbook per consolidare una serie di attività su una serie di sistemi in un unico comando, ma l'esecuzione dei playbook solo quando e dove si decide. Ad esempio:

  • È consigliabile che gli analisti SOC abbiano un input più umano e il controllo su alcune situazioni.

  • È anche possibile che siano in grado di intervenire su specifici attori di minacce (entità) su richiesta, nel corso di un'indagine o di una ricerca di minacce, nel contesto senza dover eseguire il pivot su un'altra schermata. Questa funzionalità è ora disponibile in anteprima.

  • È possibile che i tecnici SOC scrivano playbook che agiscono su entità specifiche (ora in anteprima) e che possano essere eseguite solo manualmente.

  • È probabile che i tecnici siano in grado di testare i playbook scritti prima di distribuirli completamente nelle regole di automazione.

Per questi e altri motivi, Microsoft Sentinel consente di eseguire manualmente playbook su richiesta per le entità e gli eventi imprevisti (ora in anteprima), nonché per gli avvisi.

  • Per eseguire un playbook in un evento imprevisto specifico, selezionare l'evento imprevisto nella griglia nella pagina Eventi imprevisti . Nel portale di Azure selezionare Azioni nel riquadro dei dettagli dell'evento imprevisto e scegliere Esegui playbook (anteprima) dal menu di scelta rapida. Nel portale di Defender selezionare Esegui playbook (anteprima) direttamente dalla pagina dei dettagli dell'evento imprevisto.

    Verrà aperto il playbook Run nel pannello degli eventi imprevisti .

  • Per eseguire un playbook in un avviso, selezionare un evento imprevisto, immettere i dettagli dell'evento imprevisto e nella scheda Avvisi scegliere un avviso e selezionare Visualizza playbook.

    Verrà aperto il pannello Playbook avvisi.

  • Per eseguire un playbook in un'entità, selezionare un'entità in uno dei modi seguenti:

    • Nella scheda Entità di un evento imprevisto scegliere un'entità dall'elenco e selezionare il collegamento Esegui playbook (anteprima) alla fine della riga nell'elenco.
    • Nel grafico Indagine selezionare un'entità e selezionare il pulsante Esegui playbook (anteprima) nel pannello laterale dell'entità.
    • In Comportamento entità selezionare un'entità e nella pagina dell'entità selezionare il pulsante Esegui playbook (anteprima) nel pannello a sinistra.

    Verranno tutti aperti il playbook Run nel <pannello del tipo di> entità.

In uno di questi pannelli verranno visualizzate due schede: Playbook e Esecuzioni.

  • Nella scheda Playbook verrà visualizzato un elenco di tutti i playbook a cui si ha accesso e che usano il trigger appropriato, indipendentemente dall'evento imprevisto di Microsoft Sentinel, dall'avviso di Microsoft Sentinel o dall'entità di Microsoft Sentinel. Ogni playbook nell'elenco include un pulsante Esegui che si seleziona per eseguire immediatamente il playbook.
    Se si vuole eseguire un playbook di attivazione degli eventi imprevisti non visualizzato nell'elenco, vedere la nota sulle autorizzazioni di Microsoft Sentinel riportate sopra.

  • Nella scheda Esecuzioni verrà visualizzato un elenco di tutte le volte in cui è stato eseguito qualsiasi playbook nell'evento imprevisto o nell'avviso selezionato. Potrebbero essere necessari alcuni secondi per visualizzare qualsiasi esecuzione appena completata in questo elenco. Se si seleziona un'esecuzione specifica, verrà aperto il log di esecuzione completo in App per la logica di Azure.

Gestire i playbook

Nella scheda Playbook attivi viene visualizzato un elenco di tutti i playbook a cui si ha accesso, filtrati in base alle sottoscrizioni attualmente visualizzate in Azure. Il filtro delle sottoscrizioni è disponibile dal menu Directory e sottoscrizione nell'intestazione della pagina globale.

Facendo clic sul nome di un playbook si viene indirizzati alla pagina principale del playbook in App per la logica di Azure. La colonna Stato indica se è abilitata o disabilitata.

La colonna Plan indica se il playbook usa il tipo di risorsa Standard o Consumption in App per la logica di Azure. È possibile filtrare l'elenco in base al tipo di piano per visualizzare un solo tipo di playbook. Si noterà che i playbook del tipo Standard usano la LogicApp/Workflow convenzione di denominazione. Questa convenzione riflette il fatto che un playbook Standard rappresenta un flusso di lavoro esistente insieme ad altri flussi di lavoro in una singola app per la logica.

Il tipo di trigger rappresenta il trigger App per la logica di Azure che avvia questo playbook.

Tipo di trigger Indica i tipi di componente nel playbook
Evento imprevisto/avviso/entità di Microsoft Sentinel Il playbook viene avviato con uno dei trigger di Sentinel (evento imprevisto, avviso, entità)
Uso dell'azione di Microsoft Sentinel Il playbook viene avviato con un trigger non Sentinel, ma usa un'azione di Microsoft Sentinel
Altro Il playbook non include alcun componente sentinel
Non inizializzato Il playbook è stato creato, ma non contiene componenti (trigger o azioni).

Nella pagina App per la logica di Azure del playbook è possibile visualizzare altre informazioni sul playbook, incluso un log di tutte le volte in cui è stato eseguito e il risultato (esito positivo o negativo e altri dettagli). È anche possibile aprire la finestra di progettazione del flusso di lavoro in App per la logica di Azure e modificare direttamente il playbook, se si dispone delle autorizzazioni appropriate.

Connessioni API

Le connessioni API vengono usate per connettere App per la logica di Azure ad altri servizi. Ogni volta che viene creata una nuova autenticazione per un connettore in App per la logica di Azure, viene creata una nuova risorsa di tipo connessione API e contiene le informazioni fornite durante la configurazione dell'accesso al servizio.

Per visualizzare tutte le connessioni API, immettere connessioni API nella casella di ricerca dell'intestazione del portale di Azure. Si notino le colonne di interesse:

  • Nome visualizzato: il nome "descrittivo" assegnato alla connessione ogni volta che ne viene creato uno.
  • Stato : indica lo stato della connessione: errore, connesso.
  • Gruppo di risorse: le connessioni API vengono create nel gruppo di risorse della risorsa playbook (App per la logica di Azure).

Un altro modo per visualizzare le connessioni API consiste nel passare alla pagina Tutte le risorse e filtrarla in base al tipo connessione API. In questo modo è possibile selezionare, contrassegnare ed eliminare più connessioni contemporaneamente.

Per modificare l'autorizzazione di una connessione esistente, immettere la risorsa di connessione e selezionare Modifica connessione API.

I playbook consigliati seguenti e altri playbook simili sono disponibili nell'hub contenuto o nel repository GitHub di Microsoft Sentinel:

Passaggi successivi