Share via

Automatize a resposta a ameaças com playbooks no Microsoft Sentinel

  • Artigo
  • Aplica-se a:
    Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

Este artigo explica o que são os playbooks do Microsoft Sentinel e como usá-los para implementar suas operações SOAR (Security Orchestration, Automation and Response), obtendo melhores resultados e economizando tempo e recursos.

Importante

O Microsoft Sentinel está disponível como parte da visualização pública da plataforma unificada de operações de segurança no portal Microsoft Defender. Para obter mais informações, consulte Microsoft Sentinel no portal do Microsoft Defender.

O que é uma cartilha?

Os analistas SOC normalmente são inundados com alertas e incidentes de segurança regularmente, em volumes tão grandes que o pessoal disponível fica sobrecarregado. Isso resulta muitas vezes em situações em que muitos alertas são ignorados e muitos incidentes não são investigados, deixando a organização vulnerável a ataques que passam despercebidos.

Muitos, se não a maioria, desses alertas e incidentes estão em conformidade com padrões recorrentes que podem ser abordados por conjuntos específicos e definidos de ações de correção. Os analistas também são encarregados de remediação básica e investigação dos incidentes que conseguem resolver. Na medida em que essas atividades podem ser automatizadas, um SOC pode ser muito mais produtivo e eficiente, permitindo que os analistas dediquem mais tempo e energia à atividade investigativa.

Um manual é uma coleção dessas ações de correção que você executa do Microsoft Sentinel como rotina, para ajudar a automatizar e orquestrar sua resposta a ameaças. Pode ser executado de duas maneiras:

  • Manualmente sob demanda, em uma entidade ou alerta específico
  • Automaticamente em resposta a alertas ou incidentes específicos, quando acionados por uma regra de automação.

Por exemplo, se uma conta e uma máquina estiverem comprometidas, um manual pode isolar a máquina da rede e bloquear a conta no momento em que a equipe SOC for notificada do incidente.

Embora a guia Playbooks ativos na página Automação exiba todos os playbooks ativos disponíveis em qualquer assinatura selecionada, por padrão, um playbook pode ser usado somente dentro da assinatura à qual pertence, a menos que você conceda especificamente permissões do Microsoft Sentinel ao grupo de recursos do playbook.

Após a integração à plataforma unificada de operações de segurança, a guia Playbooks ativos mostra um filtro predefinido com a assinatura do espaço de trabalho integrado. No portal do Azure, adicione dados para outras assinaturas usando o filtro de assinatura do Azure.

Modelos de playbook

Um modelo de playbook é um fluxo de trabalho pré-criado, testado e pronto para uso que pode ser personalizado para atender às suas necessidades. Os modelos também podem servir como referência para as melhores práticas ao desenvolver playbooks do zero ou como inspiração para novos cenários de automação.

Os modelos de playbooks não são utilizáveis como playbooks em si. Você cria um playbook (uma cópia editável do modelo) a partir deles.

Você pode obter modelos de playbook das seguintes fontes:

  • Na página Automação, a guia Modelos de playbook lista os modelos de playbook instalados. Vários playbooks ativos podem ser criados a partir do mesmo modelo.

    Quando uma nova versão do modelo é publicada, os playbooks ativos criados a partir desse modelo aparecem na guia Playbooks ativos exibindo um rótulo indicando que uma atualização está disponível.

  • Os modelos de playbook estão disponíveis como parte de soluções de produtos ou conteúdo autônomo que você instala a partir da página do hub de conteúdo no Microsoft Sentinel. Para obter mais informações, consulte Conteúdo e soluções do Microsoft Sentinel e Descubra e gerencie conteúdo pronto para uso do Microsoft Sentinel.

  • O repositório GitHub do Microsoft Sentinel contém muitos modelos de playbook. Eles podem ser implantados em uma assinatura do Azure selecionando o botão Implantar no Azure .

Tecnicamente, um modelo de playbook é um modelo ARM que consiste em vários recursos: um fluxo de trabalho de Aplicativos Lógicos do Azure e conexões de API para cada conexão envolvida.

Importante

Os modelos de Playbook estão atualmente em PRÉ-visualização. Consulte os Termos de Utilização Suplementares das Pré-visualizações do Microsoft Azure para obter os termos legais adicionais que se aplicam às funcionalidades do Azure que estão em versão beta, pré-visualização ou ainda não disponibilizadas para disponibilidade geral.

Conceitos básicos dos Aplicativos Lógicos do Azure

Os playbooks no Microsoft Sentinel baseiam-se em fluxos de trabalho criados nas Aplicações Lógicas do Azure, um serviço na nuvem que o ajuda a agendar, automatizar e orquestrar tarefas e fluxos de trabalho entre sistemas em toda a empresa. Tal significa que os manuais de procedimentos podem tirar partido de todo o poder e capacidades dos modelos incorporados no Azure Logic Apps.

Nota

As Aplicações Lógicas do Azure criam recursos separados, pelo que poderão ser aplicadas taxas adicionais. Para obter mais informações, visite a página de preços dos Aplicativos Lógicos do Azure.

Os Aplicativos Lógicos do Azure se comunicam com outros sistemas e serviços usando conectores. A seguir está uma breve explicação dos conectores e alguns de seus atributos importantes:

  • Conector gerenciado: um conjunto de ações e gatilhos que envolvem chamadas de API para um determinado produto ou serviço. As Aplicações Lógicas do Azure oferecem centenas de conectores para comunicar com serviços Microsoft e não Microsoft. Para obter mais informações, consulte Conectores de Aplicativos Lógicos do Azure e sua documentação

  • Conector personalizado: talvez você queira se comunicar com serviços que não estão disponíveis como conectores pré-construídos. Os conectores personalizados atendem a essa necessidade, permitindo que você crie (e até compartilhe) um conector e defina seus próprios gatilhos e ações. Para obter mais informações, consulte Criar seus próprios conectores personalizados de Aplicativos Lógicos do Azure.

  • Conector Microsoft Sentinel: para criar playbooks que interagem com o Microsoft Sentinel, use o conector Microsoft Sentinel. Para obter mais informações, consulte a documentação do conector do Microsoft Sentinel.

  • Gatilho: um componente de conector que inicia um fluxo de trabalho, neste caso, um playbook. O gatilho do Microsoft Sentinel define o esquema que o manual espera receber quando acionado. O conector Microsoft Sentinel atualmente tem três gatilhos:

  • Ações: as ações são todos os passos que ocorrem após o acionador. Podem ser dispostos sequencialmente, em paralelo ou numa matriz de condições complexas.

  • Campos dinâmicos: campos temporários, determinados pelo esquema de saída de gatilhos e ações e preenchidos por sua saída real, que podem ser usados nas ações a seguir.

Tipos de aplicativos lógicos

O Microsoft Sentinel agora oferece suporte aos seguintes tipos de recursos de aplicativos lógicos:

  • Consumo, que é executado em Aplicativos Lógicos do Azure multilocatários e usa o mecanismo clássico e original de Aplicativos Lógicos do Azure.
  • Standard, que é executado em Aplicativos Lógicos do Azure de locatário único e usa um mecanismo de Aplicativos Lógicos do Azure redesenhado.

O tipo de aplicativo lógico padrão oferece maior desempenho, preço fixo, capacidade de fluxo de trabalho múltiplo, gerenciamento de conexões de API mais fácil, recursos de rede nativa, como suporte para redes virtuais e pontos de extremidade privados (veja a nota abaixo), recursos internos de CI/CD, melhor integração com o Visual Studio Code, um designer de fluxo de trabalho atualizado e muito mais.

Para usar essa versão do aplicativo lógico, crie novos playbooks padrão no Microsoft Sentinel (veja a nota abaixo). Pode utilizar estes playbooks da mesma forma que utiliza os playbooks de Consumo:

  • Anexe-os a regras de automação e/ou regras de análise.
  • Execute-os sob demanda, tanto a partir de incidentes quanto de alertas.
  • Gerencie-os na guia Playbooks ativos.

Nota

  • Atualmente, os fluxos de trabalho padrão não suportam modelos de Playbook, o que significa que você não pode criar um playbook baseado em fluxo de trabalho padrão diretamente no Microsoft Sentinel. Em vez disso, você deve criar o fluxo de trabalho nos Aplicativos Lógicos do Azure. Depois de criar o fluxo de trabalho, ele aparece como um manual no Microsoft Sentinel.

  • Os fluxos de trabalho padrão dos aplicativos lógicos suportam pontos de extremidade privados, conforme mencionado acima, mas o Microsoft Sentinel requer a definição de uma política de restrição de acesso em aplicativos lógicos para dar suporte ao uso de pontos de extremidade privados em playbooks baseados em fluxos de trabalho padrão.

    Se uma política de restrição de acesso não estiver definida, os fluxos de trabalho com pontos de extremidade privados ainda poderão ficar visíveis e selecionáveis quando você escolher um playbook de uma lista no Microsoft Sentinel (seja para ser executado manualmente, para adicionar a uma regra de automação ou na galeria de playbooks) e poderá selecioná-los, mas sua execução falhará.

  • Um indicador identifica fluxos de trabalho padrão como stateful ou stateless. No momento, o Microsoft Sentinel não oferece suporte a fluxos de trabalho sem monitoração de estado. Saiba mais sobre as diferenças entre fluxos de trabalho com e sem monitoração de estado.

Há muitas diferenças entre esses dois tipos de recursos, algumas das quais afetam algumas das maneiras como eles podem ser usados em playbooks no Microsoft Sentinel. Nesses casos, a documentação indicará o que você precisa saber. Para obter mais informações, consulte Tipo de recurso e diferenças de ambiente de host na documentação dos Aplicativos Lógicos do Azure.

Permissões necessárias

Para dar à sua equipa de SecOps a capacidade de utilizar as Aplicações Lógicas do Azure para criar e executar manuais no Microsoft Sentinel, atribua funções do Azure à sua equipa de operações de segurança ou a utilizadores específicos da equipa. A seguir são descritas as diferentes funções disponíveis e as tarefas para as quais elas devem ser atribuídas:

Funções do Azure para Aplicativos Lógicos do Azure

  • O Colaborador do Aplicativo Lógico permite gerenciar aplicativos lógicos e executar playbooks, mas você não pode alterar o acesso a eles (para isso você precisa da função Proprietário ).
  • O Operador de Aplicativo Lógico permite ler, habilitar e desabilitar aplicativos lógicos, mas você não pode editá-los ou atualizá-los.

Funções do Azure para o Microsoft Sentinel

  • A função de Colaborador do Microsoft Sentinel permite anexar um manual a uma regra de análise ou automação.

  • A função Microsoft Sentinel Responder permite acessar um incidente para executar um manual manualmente. Mas para realmente executar a cartilha, você também precisa...

    • A função Operador de Playbook do Microsoft Sentinel permite executar um playbook manualmente.
    • O Microsoft Sentinel Automation Contributor permite que regras de automação executem playbooks. Não é utilizado para outros fins.

Mais informações

Etapas para criar um playbook

Casos de uso para playbooks

A plataforma de Aplicativos Lógicos do Azure oferece centenas de ações e gatilhos, portanto, quase qualquer cenário de automação pode ser criado. O Microsoft Sentinel recomenda começar com os seguintes cenários SOC, para os quais modelos de playbook prontos estão disponíveis imediatamente:

Melhoramento

Colete dados e anexe-os ao incidente para tomar decisões mais inteligentes.

Por exemplo:

Um incidente do Microsoft Sentinel foi criado a partir de um alerta de uma regra de análise que gera entidades de endereço IP.

O incidente aciona uma regra de automação que executa um manual com as seguintes etapas:

  • Inicie quando um novo incidente do Microsoft Sentinel for criado. As entidades representadas no incidente são armazenadas nos campos dinâmicos do gatilho do incidente.

  • Para cada endereço IP, consulte um provedor externo de Threat Intelligence, como o Virus Total, para recuperar mais dados.

  • Adicione os dados e informações retornados como comentários do incidente.

Sincronização bidirecional

Os playbooks podem ser usados para sincronizar seus incidentes do Microsoft Sentinel com outros sistemas de emissão de tíquetes.

Por exemplo:

Crie uma regra de automação para toda a criação de incidentes e anexe um playbook que abra um ticket no ServiceNow:

Orquestração

Use a plataforma de bate-papo SOC para controlar melhor a fila de incidentes.

Por exemplo:

Um incidente do Microsoft Sentinel foi criado a partir de um alerta de uma regra de análise que gera entidades de nome de usuário e endereço IP.

O incidente aciona uma regra de automação que executa um manual com as seguintes etapas:

  • Inicie quando um novo incidente do Microsoft Sentinel for criado.

  • Envie uma mensagem para o seu canal de operações de segurança no Microsoft Teams ou no Slack para se certificar de que os analistas de segurança estão cientes do incidente.

  • Envie todas as informações do alerta por e-mail para o administrador de rede sênior e administrador de segurança. A mensagem de e-mail incluirá os botões de opção Bloquear e Ignorar usuário.

  • Aguarde até que uma resposta seja recebida dos administradores e, em seguida, continue a executar.

  • Se os administradores tiverem escolhido Bloquear, envie um comando para o firewall para bloquear o endereço IP no alerta e outro para o ID do Microsoft Entra para desabilitar o usuário.

Response

Responda imediatamente às ameaças, com dependências humanas mínimas.

Dois exemplos:

Exemplo 1: Responda a uma regra de análise que indica um usuário comprometido, conforme descoberto pelo Microsoft Entra ID Protection:

  • Inicie quando um novo incidente do Microsoft Sentinel for criado.

  • Para cada entidade utilizadora no incidente suspeito de estar comprometida:

    • Envie uma mensagem do Teams para o usuário, solicitando a confirmação de que o usuário tomou a ação suspeita.

    • Verifique com o Microsoft Entra ID Protection para confirmar o status do usuário como comprometido. O Microsoft Entra ID Protection rotulará o usuário como arriscado e aplicará qualquer política de imposição já configurada - por exemplo, para exigir que o usuário use MFA na próxima entrada.

      Nota

      Esta ação específica do Microsoft Entra não inicia nenhuma atividade de imposição no usuário, nem inicia qualquer configuração de política de imposição. Ele apenas diz ao Microsoft Entra ID Protection para aplicar quaisquer políticas já definidas, conforme apropriado. Qualquer imposição depende inteiramente das políticas apropriadas que estão sendo definidas na Proteção de ID do Microsoft Entra.

Exemplo 2: Responda a uma regra de análise que indica uma máquina comprometida, conforme descoberto pelo Microsoft Defender for Endpoint:

Resposta manual durante a investigação ou durante a caça

Responda a ameaças no decurso de uma atividade de investigação ativa sem sair do contexto.

Graças ao novo gatilho de entidade (agora em Visualização), você pode tomar medidas imediatas sobre os agentes de ameaça individuais que descobrir durante uma investigação, um de cada vez, diretamente de dentro da investigação. Esta opção também está disponível no contexto de caça a ameaças, sem ligação a qualquer incidente em particular. Você pode selecionar uma entidade no contexto e executar ações nela ali mesmo, economizando tempo e reduzindo a complexidade.

As ações que você pode executar em entidades usando esse tipo de manual incluem:

  • Bloquear um utilizador comprometido.
  • Bloquear o tráfego de um endereço IP malicioso na sua firewall.
  • Isolar um anfitrião comprometido na sua rede.
  • Adicionar um endereço IP a uma lista de observação de endereços seguros/não seguros ou ao seu CMDB externo.
  • Obter um relatório de hash de arquivo de uma fonte externa de inteligência de ameaças e adicioná-lo a um incidente como um comentário.

Como executar um playbook

Os playbooks podem ser executados manualmente ou automaticamente.

Eles são projetados para serem executados automaticamente e, idealmente, é assim que devem ser executados no curso normal das operações. Você executa um manual automaticamente definindo-o como uma resposta automatizada em uma regra de análise (para alertas) ou como uma ação em uma regra de automação (para incidentes).

Há circunstâncias, porém, que exigem a execução manual de playbooks. Por exemplo:

  • Ao criar um novo manual, você vai querer testá-lo antes de colocá-lo em produção.

  • Pode haver situações em que você queira ter mais controle e informações humanas sobre quando e se um determinado manual é executado.

    Você executa um playbook manualmente abrindo um incidente, alerta ou entidade e selecionando e executando o playbook associado exibido lá. Atualmente, esse recurso está geralmente disponível para alertas e em visualização para incidentes e entidades.

Definir uma resposta automatizada

As equipes de operações de segurança podem reduzir significativamente sua carga de trabalho automatizando totalmente as respostas de rotina a tipos recorrentes de incidentes e alertas, permitindo que você se concentre mais em incidentes e alertas exclusivos, analisando padrões, caça a ameaças e muito mais.

Definir resposta automatizada significa que toda vez que uma regra de análise é acionada, além de criar um alerta, a regra executará um playbook, que receberá como entrada o alerta criado pela regra.

Se o alerta criar um incidente, o incidente acionará uma regra de automação que, por sua vez, poderá executar um playbook, que receberá como entrada o incidente criado pelo alerta.

Resposta automatizada de criação de alertas

Para playbooks que são acionados pela criação de alertas e recebem alertas como entradas (a primeira etapa é "Alerta do Microsoft Sentinel"), anexe o manual a uma regra de análise:

  1. Edite a regra de análise que gera o alerta para o qual você deseja definir uma resposta automatizada.

  2. Em Automação de alertas, na guia Resposta automatizada, selecione o playbook ou playbooks que essa regra de análise acionará quando um alerta for criado.

Resposta automatizada de criação de incidentes

Para playbooks que são acionados pela criação de incidentes e recebem incidentes como entradas (o primeiro passo é "Incidente do Microsoft Sentinel"), crie uma regra de automação e defina uma ação Executar playbook nela. Isto pode ser feito de 2 maneiras:

  • Edite a regra de análise que gera o incidente para o qual você deseja definir uma resposta automatizada. Em Automação de incidentes, na guia Resposta automatizada, crie uma regra de automação. Isso criará uma resposta automatizada apenas para essa regra de análise.

  • Na guia Regras de automação na página Automação , crie uma nova regra de automação e especifique as condições apropriadas e as ações desejadas. Esta regra de automação será aplicada a qualquer regra de análise que cumpra as condições especificadas.

    Nota

    O Microsoft Sentinel requer permissões para executar playbooks de acionamento de incidentes.

    Para executar um manual com base no gatilho de incidente, seja manualmente ou a partir de uma regra de automação, o Microsoft Sentinel usa uma conta de serviço especificamente autorizada a fazê-lo. O uso dessa conta (ao contrário da sua conta de usuário) aumenta o nível de segurança do serviço e permite que a API de regras de automação ofereça suporte a casos de uso de CI/CD.

    Essa conta deve receber permissões explícitas (na forma da função de Colaborador do Microsoft Sentinel Automation) no grupo de recursos onde o manual reside. Nesse ponto, você poderá executar qualquer manual nesse grupo de recursos, manualmente ou a partir de qualquer regra de automação.

    Quando você adiciona a ação executar playbook a uma regra de automação, uma lista suspensa de playbooks será exibida para sua seleção. Os playbooks para os quais o Microsoft Sentinel não tem permissões serão exibidos como indisponíveis ("acinzentados"). Você pode conceder permissão ao Microsoft Sentinel no local selecionando o link Gerenciar permissões do playbook.

    Em um cenário multilocatário (Farol), você deve definir as permissões no locatário onde o playbook vive, mesmo que a regra de automação que chama o playbook esteja em um locatário diferente. Para fazer isso, você deve ter permissões de proprietário no grupo de recursos do playbook.

    Há um cenário exclusivo enfrentado por um MSSP (Managed Security Service Provider), em que um provedor de serviços, enquanto conectado em seu próprio locatário, cria uma regra de automação no espaço de trabalho de um cliente usando o Azure Lighthouse. Em seguida, essa regra de automação chama um manual pertencente ao locatário do cliente. Nesse caso, o Microsoft Sentinel deve receber permissões em ambos os locatários. No locatário do cliente, você concede a eles no painel Gerenciar permissões do playbook, assim como no cenário multilocatário regular. Para conceder as permissões relevantes no locatário do provedor de serviços, você precisa adicionar uma delegação adicional do Azure Lighthouse que conceda direitos de acesso ao aplicativo Azure Security Insights, com a função de Colaborador de Automação do Microsoft Sentinel, no grupo de recursos onde o manual reside. Saiba como adicionar esta delegação.

Consulte as instruções completas para criar regras de automação.

Executar um playbook manualmente

A automação total é a melhor solução para tantas tarefas de tratamento de incidentes, investigação e mitigação quanto você se sentir confortável em automatizar. Dito isso, pode haver boas razões para uma espécie de automação híbrida: usar playbooks para consolidar uma série de atividades contra uma variedade de sistemas em um único comando, mas executar os playbooks apenas quando e onde você decidir. Por exemplo:

  • Você pode preferir que seus analistas SOC tenham mais informações humanas e controle sobre algumas situações.

  • Você também pode querer que eles sejam capazes de tomar medidas contra agentes de ameaça específicos (entidades) sob demanda, no decorrer de uma investigação ou de uma caça a ameaças, no contexto, sem ter que girar para outra tela. (Esta capacidade está agora em Pré-visualização.)

  • Você pode querer que seus engenheiros SOC escrevam playbooks que atuam em entidades específicas (agora em Visualização) e que só podem ser executados manualmente.

  • Você provavelmente gostaria que seus engenheiros pudessem testar os playbooks que escrevem antes de implantá-los totalmente em regras de automação.

Por esses e outros motivos, o Microsoft Sentinel permite que você execute playbooks manualmente sob demanda para entidades e incidentes (ambos agora em Visualização), bem como para alertas.

  • Para executar um manual sobre um incidente específico, selecione o incidente na grade na página Incidentes . No portal do Azure, selecione Ações no painel de detalhes do incidente e escolha Executar playbook (Visualização) no menu de contexto. No portal do Defender, selecione Executar manual (Visualização) diretamente na página de detalhes do incidente.

    Isso abre o playbook Executar no painel de incidentes .

  • Para executar um playbook em um alerta, selecione um incidente, insira os detalhes do incidente e, na guia Alertas , escolha um alerta e selecione Exibir playbooks.

    Isso abre o painel Playbooks de alerta.

  • Para executar um playbook em uma entidade, selecione uma entidade de uma das seguintes maneiras:

    • Na guia Entidades de um incidente, escolha uma entidade na lista e selecione o link Executar playbook (Visualização) no final de sua linha na lista.
    • No gráfico Investigação, selecione uma entidade e selecione o botão Executar playbook (Visualização) no painel lateral da entidade.
    • Em Comportamento da entidade, selecione uma entidade e, na página da entidade, selecione o botão Executar playbook (Visualização) no painel esquerdo.

    Todos eles abrirão o painel Executar playbook no <tipo de> entidade.

Em qualquer um desses painéis, você verá duas guias: Playbooks e Runs.

  • Na guia Playbooks, você verá uma lista de todos os playbooks aos quais você tem acesso e que usam o gatilho apropriado - seja Microsoft Sentinel Incident, Microsoft Sentinel Alert ou Microsoft Sentinel Entity. Cada playbook na lista tem um botão Executar que você seleciona para executar o playbook imediatamente.
    Se você quiser executar um manual de acionamento de incidente que não vê na lista, consulte a observação sobre as permissões do Microsoft Sentinel acima.

  • Na guia Execuções, você verá uma lista de todas as vezes que qualquer manual foi executado no incidente ou alerta selecionado. Pode levar alguns segundos para que qualquer execução recém-concluída apareça nesta lista. Selecionar uma execução específica abrirá o log de execução completo nos Aplicativos Lógicos do Azure.

Gerencie seus playbooks

Na guia Playbooks ativos, aparece uma lista de todos os playbooks aos quais você tem acesso, filtrada pelas assinaturas que são exibidas atualmente no Azure. O filtro de assinaturas está disponível no menu Diretório + assinatura no cabeçalho da página global.

Clicar no nome de um playbook direciona você para a página principal do playbook nos Aplicativos Lógicos do Azure. A coluna Estado indica se está ativada ou desativada.

A coluna Plano indica se o manual usa o tipo de recurso Padrão ou Consumo nos Aplicativos Lógicos do Azure. Você pode filtrar a lista por tipo de plano para ver apenas um tipo de manual. Você notará que os playbooks do tipo Standard usam a LogicApp/Workflow convenção de nomenclatura. Essa convenção reflete o fato de que um manual padrão representa um fluxo de trabalho que existe ao lado de outros fluxos de trabalho em um único aplicativo lógico.

Tipo de gatilho representa o gatilho dos Aplicativos Lógicos do Azure que inicia este manual.

Tipo de gatilho Indica tipos de componentes no playbook
Incidente/Alerta/Entidade do Microsoft Sentinel O manual é iniciado com um dos gatilhos Sentinel (incidente, alerta, entidade)
Usando o Microsoft Sentinel Action O manual é iniciado com um gatilho que não é do Sentinel, mas usa uma ação do Microsoft Sentinel
Outro O manual não inclui quaisquer componentes do Sentinel
Não inicializado O manual foi criado, mas não contém componentes (gatilhos ou ações).

Na página Aplicativos Lógicos do Azure do playbook, você pode ver mais informações sobre o playbook, incluindo um log de todas as vezes que ele foi executado e o resultado (sucesso ou falha e outros detalhes). Você também pode abrir o designer de fluxo de trabalho nos Aplicativos Lógicos do Azure e editar o manual diretamente, se tiver as permissões apropriadas.

Ligações da API

As conexões de API são usadas para conectar os Aplicativos Lógicos do Azure a outros serviços. Sempre que uma nova autenticação é feita para um conector nos Aplicativos Lógicos do Azure, um novo recurso do tipo conexão de API é criado e contém as informações fornecidas ao configurar o acesso ao serviço.

Para ver todas as conexões de API, insira conexões de API na caixa de pesquisa de cabeçalho do portal do Azure. Observe as colunas de interesse:

  • Nome para exibição - o nome "amigável" que você dá à conexão toda vez que cria uma.
  • Status - indica o status da conexão: erro, conectado.
  • Grupo de recursos - as conexões de API são criadas no grupo de recursos do recurso playbook (Aplicativos Lógicos do Azure).

Outra maneira de visualizar conexões de API seria ir para a página Todos os recursos e filtrá-la por tipo de conexão de API. Dessa forma, permite a seleção, marcação e exclusão de várias conexões ao mesmo tempo.

Para alterar a autorização de uma conexão existente, insira o recurso de conexão e selecione Editar conexão de API.

Os seguintes playbooks recomendados e outros playbooks semelhantes estão disponíveis para você no hub Conteúdo ou no repositório GitHub do Microsoft Sentinel:

Próximos passos