Automatizar a resposta a ameaças em Microsoft Sentinel com regras de automatização

Este artigo explica o que são regras de automatização Microsoft Sentinel e como utilizá-las para implementar as operações SOAR (Security Orchestration, Automation and Response). As regras de automatização aumentam a eficácia do SOC e poupam-lhe tempo e recursos.

Importante

Após 31 de março de 2027, Microsoft Sentinel deixarão de ser suportados no portal do Azure e só estarão disponíveis no portal do Microsoft Defender. Todos os clientes que utilizem Microsoft Sentinel no portal do Azure serão redirecionados para o portal do Defender e utilizarão apenas Microsoft Sentinel no portal do Defender.

Se ainda estiver a utilizar Microsoft Sentinel no portal do Azure, recomendamos que comece a planear a transição para o portal do Defender para garantir uma transição suave e tirar o máximo partido da experiência de operações de segurança unificada oferecida pelo Microsoft Defender.

O que são regras de automatização?

As regras de automatização são uma forma de gerir centralmente a automatização no Microsoft Sentinel, permitindo-lhe definir e coordenar um pequeno conjunto de regras que podem ser aplicadas em diferentes cenários.

As regras de automatização aplicam-se às seguintes categorias de casos de utilização:

  • Executar tarefas básicas de automatização para processamento de incidentes sem utilizar manuais de procedimentos. Por exemplo:

    • Adicione tarefas de incidente para os analistas seguirem.
    • Suprimir incidentes ruidosos.
    • Faça a triagem de novos incidentes ao alterar o respetivo estado de Novo para Ativo e atribuir um proprietário.
    • Etiquete os incidentes para os classificar.
    • Escale um incidente atribuindo um novo responsável.
    • Feche os incidentes resolvidos, especificando um motivo e adicionando comentários.
  • Automatizar respostas para múltiplas regras de análise ao mesmo tempo.

  • Controlar a ordem das ações executadas.

  • Inspecione o conteúdo de um incidente (alertas, entidades e outras propriedades) e tome medidas adicionais ao chamar um manual de procedimentos.

  • As regras de automatização também podem ser o mecanismo através do qual executa um manual de procedimentos em resposta a um alertanão associado a um incidente.

Em suma, as regras de automatização simplificam a utilização da automatização no Microsoft Sentinel, o que lhe permite simplificar fluxos de trabalho complexos para os seus processos de orquestração de resposta a ameaças.

Componentes

As regras de automatização são compostas por vários componentes:

  • Acionadores que definem que tipo de evento de incidente faz com que a regra seja executada, sujeita a condições.
  • Condições que determinam as circunstâncias exatas em que a regra é executada e executa ações.
  • Ações para alterar o incidente de alguma forma ou chamar um manual de procedimentos, que executa ações mais complexas e interage com outros serviços.

Acionadores

As regras de automatização são acionadas quando um incidente é criado ou atualizado ou quando é criado um alerta. Lembre-se de que os incidentes incluem alertas e que os alertas e os incidentes podem ser criados pelas regras de análise, conforme explicado em Deteção de ameaças no Microsoft Sentinel.

A tabela seguinte mostra os diferentes cenários possíveis que fazem com que uma regra de automatização seja executada.

Tipo de acionador Eventos que fazem com que a regra seja executada
Quando o incidente é criado portal do Microsoft Defender:
  • É criado um novo incidente no portal do Microsoft Defender.

    Microsoft Sentinel não integrado no portal do Defender:
  • Um novo incidente é criado por uma regra de análise.
  • Um incidente é importado do Microsoft Defender XDR.
  • Um novo incidente é criado manualmente.
  • Quando o incidente é atualizado
  • O estado de um incidente é alterado (fechado/reaberto/classificado).
  • É atribuído ou alterado o responsável por um incidente.
  • A gravidade de um incidente é elevada ou reduzida.
  • Os alertas são adicionados a um incidente.
  • Os comentários, etiquetas ou táticas são adicionados a um incidente.
  • Quando o alerta é criado
  • Um alerta é criado por uma regra de análise do Microsoft Sentinel Agendada ou NRT.
  • Se o seu espaço de trabalho estiver integrado no portal do Microsoft Defender, também pode usar os gatilhos de criação eatualização de casos do Simple Flows (pré-visualização) para automatizar fluxos de trabalho de casos.

    Automatização baseada em incidentes ou em alertas?

    Com as regras de automatização a processar centralmente a resposta a incidentes e alertas, como deve escolher qual automatizar e em que circunstâncias?

    Para a maioria dos casos de utilização, a automatização acionada por incidentes é a abordagem preferível. No Microsoft Sentinel, um incidente é um "ficheiro de caso" – uma agregação de todas as provas relevantes para uma investigação específica. É um contentor para alertas, entidades, comentários, colaboração e outros artefactos. Ao contrário dos alertas que são provas individuais, os incidentes são modificáveis, têm o estado mais atualizado e podem ser enriquecidos com comentários, etiquetas e marcadores. O incidente permite-lhe controlar a história do ataque que continua a evoluir com a adição de novos alertas.

    Por estas razões, faz mais sentido criar a sua automatização em torno de incidentes. Assim, a forma mais adequada de criar manuais de procedimentos é baseá-los no Microsoft Sentinel acionador de incidentes no Azure Logic Apps.

    O principal motivo para utilizar a automatização acionada por alertas é para responder a alertas gerados por regras de análise que não criam incidentes (ou seja, onde a criação de incidentes está desativada no separador Definições de incidente do assistente de regras de análise).

    Este motivo é especialmente relevante quando a área de trabalho Microsoft Sentinel está integrada no portal do Defender. Neste cenário, toda a criação de incidentes ocorre no portal do Defender e, por conseguinte, as regras de criação de incidentes no Microsoft Sentinel têm de ser desativadas.

    Mesmo sem ser integrado no portal unificado, pode mesmo assim decidir utilizar a automatização acionada por alertas se quiser utilizar outra lógica externa para decidir se e quando criar incidentes a partir de alertas e como os alertas são agrupados em conjunto. Por exemplo:

    • Um manual de procedimentos, acionado por um alerta que não tem um incidente associado, pode enriquecer o alerta com informações de outras origens e, com base numa lógica externa, decidir se pretende ou não criar um incidente.

    • Um manual de procedimentos, acionado por um alerta, pode, em vez de criar um incidente, procurar um incidente existente adequado ao qual adicionar o alerta. Saiba mais sobre a expansão de incidentes.

    • Um manual de procedimentos, acionado por um alerta, pode notificar o pessoal do SOC do alerta para que a equipa possa decidir se pretende ou não criar um incidente.

    • Um manual de procedimentos, acionado por um alerta, pode enviar o alerta para um sistema de pedidos de suporte externo para criação e gestão de incidentes e esse sistema cria um novo pedido de suporte para cada alerta.

    Nota

    Condições

    Podem ser definidos conjuntos complexos de condições para governar quando as ações (ver abaixo) devem ser executadas. Estas condições incluem o evento que aciona a regra (incidente criado ou atualizado ou alerta criado), os estados ou valores das propriedades e propriedades da entidade do incidente (apenas para o acionador de incidentes) e também a regra ou regras de análise que geraram o incidente ou alerta.

    Quando uma regra de automatização é acionada, verifica o incidente de acionamento ou o alerta em relação às condições definidas na regra. Para incidentes, as condições baseadas na propriedade são avaliadas de acordo com o estado atual da propriedade no momento em que a avaliação ocorre ou de acordo com as alterações no estado da propriedade (veja abaixo para obter detalhes). Uma vez que um único evento de criação ou atualização de incidentes pode acionar várias regras de automatização, a ordem pela qual são executadas (ver abaixo) faz a diferença na determinação do resultado da avaliação das condições. As ações definidas na regra são executadas apenas se todas as condições forem cumpridas.

    Acionador de criação de incidentes

    Para regras definidas com o acionador Quando é criado um incidente, pode definir condições que verificam o estado atual dos valores de uma determinada lista de propriedades do incidente, utilizando um ou mais dos seguintes operadores:

    • é igual ou não é igual ao valor definido na condição.
    • contém ou não contém o valor definido na condição.
    • começa com ou não começa com o valor definido na condição.
    • termina com ou não termina com o valor definido na condição.

    Por exemplo, se definir Nome da regra analítica como Contém == ataque de força bruta contra um PC na Cloud, uma regra analítica com ataque de força bruta contra o portal do Azure não satisfaz a condição. No entanto, se definir o Nome da regra de análise como Não contém == Credenciais de utilizador, tanto o ataque de força bruta contra um PC na Cloud como a força bruta contra portal do Azure regras de análise cumprem a condição.

    Nota

    O estado atual neste contexto refere-se ao momento em que a condição é avaliada, ou seja, o momento em que a regra de automatização é executada. Se mais do que uma regra de automatização estiver definida para ser executada em resposta à criação deste incidente, as alterações efetuadas ao incidente por uma regra de automatização de execução anterior são consideradas o estado atual para regras de execução posterior.

    Acionador de atualização de incidentes

    As condições avaliadas nas regras definidas com o acionador Quando um incidente é atualizado incluem todas as condições listadas para o acionador de criação de incidentes. No entanto, o acionador de atualização inclui mais propriedades que podem ser avaliadas.

    Uma destas propriedades é Atualizada por. Esta propriedade permite-lhe acompanhar o tipo de fonte responsável pela alteração no incidente. Pode criar uma condição que avalie se o incidente foi atualizado com base num dos seguintes valores, consoante tenha integrado a sua área de trabalho ao portal do Defender:

    • Uma aplicação, incluindo aplicações nos portais do Azure e do Defender.
    • Um utilizador, incluindo as alterações efetuadas pelos utilizadores nos portais do Azure e do Defender.
    • AIR, para atualizações da investigação e resposta automatizadas no Microsoft Defender para Office 365
    • Agrupamento de alertas (que adicionou alertas ao incidente), incluindo agrupamentos de alertas efetuados tanto por regras de análise como pela lógica de correlação incorporada do Microsoft Defender XDR
    • Um guia prático
    • Uma regra de automatização
    • Outro, caso nenhum dos valores acima se aplique

    Com esta condição, por exemplo, pode instruir esta regra de automatização para que seja executada sempre que for feita qualquer alteração a um incidente, exceto se essa alteração tiver sido feita por outra regra de automatização.

    Mais concretamente, o acionador de atualização também utiliza outros operadores que verificam alterações de estado nos valores das propriedades do incidente, bem como o seu estado atual. Uma condição de alteração de estado seria satisfeita se:

    O valor de uma propriedade de incidente foi

    • alterado (independentemente do valor real antes ou depois).
    • alterado em relação ao valor definido na condição.
    • alterado para o valor definido na condição.
    • adicionado a (isto aplica-se a propriedades com uma lista de valores).

    Propriedade etiqueta : individual vs. coleção

    A propriedade incidente Tag é uma coleção de itens individuais— um único incidente pode ter várias etiquetas aplicadas à mesma. Pode definir condições que verificam cada etiqueta na coleção individualmente e as condições que verificam a coleção de etiquetas como uma unidade.

    • Todos os operadores de etiquetas individuais verificam a condição em relação a todas as etiquetas na coleção. A avaliação é verdadeira quando , pelo menos, uma etiqueta satisfaz a condição.
    • Coleção de todas as etiquetas os operadores verificam a condição em relação à coleção de etiquetas como uma única unidade. A avaliação só é verdadeira se a coleção como um todo satisfizer a condição.

    Esta distinção é importante quando a sua condição é uma condição negativa (não contém) e algumas etiquetas da coleção satisfazem a condição, enquanto outras não.

    Vejamos um exemplo em que a sua condição é A etiqueta não contém "2024" e tem dois incidentes, cada um com duas etiquetas:

    \ Incidentes ▶
    Condição ▼ \
    Incidente 1
    Etiqueta 1: 2024
    Etiqueta 2: 2023
    Incidente 2
    Etiqueta 1: 2023
    Etiqueta 2: 2022
    Qualquer etiqueta individual
    não contém "2024"
    VERDADEIRO VERDADEIRO
    Coleção de todas as etiquetas
    não contém "2024"
    FALSO VERDADEIRO

    Neste exemplo, no Incidente 1:

    • Se a condição verificar cada etiqueta individualmente, uma vez que existe pelo menos uma etiqueta que satisfaz a condição (que não contém "2024"), a condição geral é verdadeira.
    • Se a condição verificar todas as etiquetas no incidente como uma única unidade, uma vez que existe pelo menos uma etiqueta que não satisfaz a condição(que contém "2024"), a condição geral é falsa.

    No Incidente 2, o resultado é o mesmo, independentemente do tipo de condição definido.

    Propriedades de entidade suportadas

    Para consultar a lista de propriedades da entidade suportadas como condições para regras de automatização, veja referência das regras de automatização do Microsoft Sentinel.

    Acionador de criação de alertas

    Atualmente, a única condição que pode ser configurada para o acionador de criação de alertas é o conjunto de regras de análise para as quais a regra de automatização é executada.

    Ações

    As ações podem ser definidas para serem executadas quando as condições (ver acima) forem cumpridas. Pode definir muitas ações numa regra e pode escolher a ordem pela qual são executadas (ver abaixo). As seguintes ações podem ser definidas através de regras de automatização, sem a necessidade da funcionalidade avançada de um manual de procedimentos:

    • Adicionar uma tarefa a um incidente: pode criar uma lista de verificação de tarefas para os analistas seguirem ao longo dos processos de triagem, investigação e remediação do incidente, para garantir que não são ignorados passos críticos.

    • Alterar o estado de um incidente, mantendo o fluxo de trabalho atualizado.

      • Ao mudar para "fechado", especifique o motivo de fecho e adicione um comentário. Isto ajuda-o a controlar o seu desempenho e eficácia e a ajustar para reduzir os falsos positivos.
    • Alterar a gravidade de um incidente: pode reavaliar e repriorizar com base na presença, ausência, valores ou atributos das entidades envolvidas no incidente.

    • Atribuir um incidente a um proprietário: isto ajuda-o a direcionar os tipos de incidentes para o pessoal mais adequado para lidar com eles ou para o pessoal mais disponível.

    • Adicionar uma etiqueta a um incidente: isto é útil para classificar incidentes por assunto, por atacante ou por qualquer outro denominador comum.

    Se o seu espaço de trabalho estiver integrado no portal do Microsoft Defender, Simple Flows (versão preliminar) adiciona mais ações pré-criadas que pode utilizar diretamente no assistente de regras de automatização, sem ter de escrever um playbook. As ações disponíveis incluem Enviar e-mail de Caso criado/atualizado/SLA excedido, Atualizar Caso, Adicionar Tarefa e Atualizar Alerta.

    Além disso, pode definir uma ação para executar um manual de procedimentos para efetuar ações de resposta mais complexas, incluindo quaisquer que envolvam sistemas externos. Os playbooks disponíveis para utilização numa regra de automatização dependem do disparador em que os playbooks e a regra de automatização se baseiam: apenas os playbooks com disparador de incidente podem ser executados a partir de regras de automatização com disparador de incidente, e apenas os playbooks com disparador de alerta podem ser executados a partir de regras de automatização com disparador de alerta. Pode definir várias ações que acionam playbooks, ou combinações de playbooks e outras ações. As ações são executadas pela ordem em que são listadas na regra.

    Os playbooks que utilizam qualquer uma das versões do Azure Logic Apps (Standard ou Consumption) estão disponíveis para ser executados a partir de regras de automatização.

    Data de expiração

    Pode definir uma data de expiração numa regra de automatização. A regra é desativada após essa data passar. Isto é útil para processar (ou seja, fechar) incidentes de "ruído" causados por atividades planeadas e limitadas no tempo, como testes de penetração.

    Encomenda

    Pode definir a ordem pela qual as regras de automatização são executadas. As regras de automatização subsequentes avaliam as condições do incidente de acordo com o seu estado depois de este ter sido processado pelas regras de automatização anteriores.

    Por exemplo, se a "Primeira Regra de Automatização" tiver alterado a gravidade de um incidente de Média para Baixa e a "Segunda Regra de Automatização" estiver definida para ser executada apenas em incidentes com gravidade média ou superior, não será executada nesse incidente.

    A ordem das regras de automatização que adicionam tarefas de incidente determina a ordem pela qual as tarefas aparecem num determinado incidente.

    As regras baseadas no disparador de atualização têm a sua própria fila de ordenação separada. Se essas regras forem acionadas para serem executadas num incidente acabado de criar (por uma alteração efetuada por outra regra de automatização), só são executadas depois de todas as regras aplicáveis baseadas no acionador de criação terem terminado de ser executadas.

    Notas sobre a ordem de execução e a prioridade

    • Definir o número da encomenda nas regras de automatização determina a ordem de execução.
    • Cada tipo de acionador mantém a sua própria fila.
    • Para as regras criadas no portal do Azure, o campo ordem é preenchido automaticamente com o número imediatamente a seguir ao número mais elevado utilizado pelas regras existentes do mesmo tipo de acionamento.
    • No entanto, para as regras criadas de outras formas (linha de comandos, API, etc.), o número da encomenda tem de ser atribuído manualmente.
    • Não existe nenhum mecanismo de validação que impeça que múltiplas regras tenham o mesmo número de ordem, mesmo dentro do mesmo tipo de acionador.
    • Pode permitir que duas ou mais regras do mesmo tipo de acionador tenham o mesmo número de ordem, se não se importar com a ordem em que são executadas.
    • Para regras do mesmo tipo de disparador com o mesmo número de ordem, o motor de execução seleciona aleatoriamente que regras são executadas e por que ordem.
    • Para regras de diferentes tipos de acionadores de incidentes , todas as regras aplicáveis com o tipo de acionador de criação de incidentes são executadas primeiro (de acordo com os respetivos números de encomenda) e apenas as regras com o tipo de acionador de atualização de incidentes (de acordo com os respetivos números de encomenda).
    • As regras são sempre executadas sequencialmente, nunca em paralelo.

    Nota

    Após a integração no portal Defender, se forem feitas várias alterações ao mesmo incidente num período de 5-10 minutos, é enviada uma única atualização para o Microsoft Sentinel, com apenas a alteração mais recente. As atualizações intermédias são perdidas, o que pode afetar fluxos de trabalho que dependem do processamento das alterações sequenciais de estado dos incidentes.

    Cenários e casos de utilização comuns

    Tarefas do incidente

    As regras de automatização permitem-lhe uniformizar e formalizar os passos necessários para a triagem, investigação e remediação de incidentes ao criar tarefas que podem ser aplicadas a um único incidente, a grupos de incidentes ou a todos os incidentes, de acordo com as condições definidas na regra de automatização e a lógica de deteção de ameaças nas regras de análise subjacentes. As tarefas aplicadas a um incidente são apresentadas na página do incidente, para que os seus analistas tenham a lista completa das ações que precisam de realizar, mesmo à sua frente, e não percam quaisquer passos críticos.

    Automatização acionada por incidentes e alertas

    As regras de automatização podem ser acionadas pela criação ou atualização de incidentes e também pela criação de alertas. Estas ocorrências podem acionar cadeias de resposta automatizadas, que podem incluir manuais de procedimentos (são necessárias permissões especiais).

    Acionar manuais de procedimentos para fornecedores da Microsoft

    As regras de automatização fornecem uma forma de automatizar o processamento de alertas de segurança da Microsoft ao aplicar estas regras a incidentes criados a partir dos alertas. As regras de automatização podem chamar manuais de procedimentos (são necessárias permissões especiais) e transmitir-lhes os incidentes com todos os seus detalhes, incluindo alertas e entidades. Em geral, as melhores práticas do Microsoft Sentinel determinam a utilização da fila de incidentes como ponto central das operações de segurança.

    Os alertas de segurança da Microsoft incluem o seguinte:

    • Proteção do Microsoft Entra ID
    • Microsoft Defender para a Cloud
    • Microsoft Defender para Aplicações na Nuvem
    • Microsoft Defender para Office 365
    • Microsoft Defender para Endpoint
    • Microsoft Defender para Identidade
    • Microsoft Defender para IoT

    Vários manuais de procedimentos sequenciados/ações numa única regra

    Agora, pode ter controlo quase completo sobre a ordem de execução de ações e manuais de procedimentos numa única regra de automatização. Também pode controlar a ordem de execução das próprias regras de automatização. Isto permite-lhe simplificar bastante os seus manuais de procedimentos, reduzindo-os a uma única tarefa ou a uma sequência pequena e simples de tarefas, e combinar estes pequenos manuais de procedimentos em combinações diferentes em diferentes regras de automatização.

    Atribuir um manual de procedimentos a várias regras de análise ao mesmo tempo

    Se tiver uma tarefa que pretende automatizar em todas as regras de análise, por exemplo, a criação de um pedido de suporte num sistema de pedidos de suporte externo, pode aplicar um único manual de procedimentos a qualquer uma ou a todas as suas regras de análise (incluindo quaisquer regras futuras) numa só oportunidade. Isto torna as tarefas simples, mas repetitivas, de manutenção e domésticas muito menos penosas.

    Atribuição automática de incidentes

    Pode atribuir automaticamente os incidentes ao responsável adequado. Se o seu SOC tiver um analista especializado numa determinada plataforma, quaisquer incidentes relacionados com essa plataforma podem ser automaticamente atribuídos a esse analista.

    Supressão de incidentes

    Pode utilizar regras para resolver automaticamente incidentes que são positivos falsos/benignos conhecidos sem a utilização de manuais de procedimentos. Por exemplo, ao executar testes de penetração, efetuar manutenção ou atualizações agendadas ou testar procedimentos de automatização, poderão ser criados muitos incidentes falsos positivos que o SOC pretende ignorar. Uma regra de automatização com limite de tempo pode fechar automaticamente estes incidentes à medida que são criados, ao mesmo tempo que os identifica com um descritor da causa da sua geração.

    Automatização com limite de tempo

    Pode adicionar datas de expiração para as regras de automatização. Podem existir outros casos que não a supressão de incidentes que justificam uma automatização limitada no tempo. Poderá querer atribuir um tipo específico de incidente a um determinado utilizador (por exemplo, um estagiário ou um consultor) para um período de tempo específico. Se o período de tempo for conhecido antecipadamente, pode efetivamente fazer com que a regra seja desativada no final da sua relevância, sem ter de se lembrar de o fazer.

    Etiquetar incidentes automaticamente

    Pode adicionar automaticamente etiquetas de texto livre a incidentes para agrupar ou classificá-las de acordo com quaisquer critérios à sua escolha.

    Casos de utilização adicionados pelo acionador de atualização

    Agora que as alterações efetuadas aos incidentes podem acionar regras de automatização, existem mais cenários abertos à automatização.

    Expandir a automatização quando o incidente evolui

    Pode utilizar o acionador de atualização para aplicar muitos dos casos de utilização acima aos incidentes à medida que a investigação progride e os analistas adicionam alertas, comentários e etiquetas. Controlar o agrupamento de alertas em incidentes.

    Atualizar orquestração e notificação

    Notifique as suas várias equipas e outros funcionários quando forem efetuadas alterações a incidentes, para que não percam quaisquer atualizações críticas. Escale os incidentes, atribuindo-os a novos responsáveis e informando-os das respetivas atribuições. Controlar quando e como os incidentes são reabertos.

    Manter a sincronização com sistemas externos

    Se utilizou playbooks para criar tickets em sistemas externos quando os incidentes são criados, pode utilizar uma regra de automatização acionada por atualização para invocar um playbook que atualize esses tickets.

    Execução de regras de automatização

    As regras de automatização são executadas sequencialmente, de acordo com a ordemque determinar. Cada regra de automatização é executada após a execução da anterior. Dentro de uma regra de automatização, todas as ações são executadas sequencialmente pela ordem em que são definidas.

    As ações do manual de procedimentos dentro de uma regra de automatização podem ser tratadas de forma diferente em algumas circunstâncias, de acordo com os seguintes critérios:

    Tempo de execução do manual de procedimentos A regra de automatização avança para a próxima ação...
    Menos de um segundo Imediatamente após a conclusão do manual de procedimentos
    Menos de dois minutos Até dois minutos após o manual de procedimentos começar a ser executado,
    mas não mais de 10 segundos após a conclusão do manual de procedimentos
    Mais de dois minutos Dois minutos após o manual de procedimentos começar a ser executado,
    independentemente de ter sido ou não concluído

    Permissões para regras de automatização para executar manuais de procedimentos

    Quando uma regra de automatização Microsoft Sentinel executa um manual de procedimentos, utiliza uma conta de serviço Microsoft Sentinel especial especificamente autorizada para esta ação. A utilização desta conta (por oposição à sua conta de utilizador) aumenta o nível de segurança do serviço.

    Para que uma regra de automatização execute um manual de procedimentos, esta conta tem de ter permissões explícitas para o grupo de recursos onde reside o manual de procedimentos. Nessa altura, qualquer regra de automatização pode executar qualquer manual de procedimentos nesse grupo de recursos.

    Ao configurar uma regra de automatização e ao adicionar uma ação executar manual de procedimentos, aparece uma lista pendente de manuais de procedimentos. Os manuais de procedimentos para os quais Microsoft Sentinel não têm permissões são apresentados como indisponíveis ("desativado"). Pode conceder ao Microsoft Sentinel permissões para os grupos de recursos dos playbooks de imediato, selecionando a hiperligação Gerir permissões dos playbooks. Para conceder essas permissões, precisa de permissões de Proprietário nesses grupos de recursos. Veja os requisitos de permissões completos.

    Permissões numa arquitetura multicliente

    As regras de automatização suportam totalmente implementações entre espaços de trabalho e implementações multitenant (no caso de implementações multitenant, utilizando o Azure Lighthouse).

    Por conseguinte, se a implementação do Microsoft Sentinel utilizar uma arquitetura multi-inquilino, pode ter uma regra de automatização num inquilino a executar um manual de procedimentos que reside num inquilino diferente, mas as permissões para Sentinel executar os manuais de procedimentos têm de ser definidas no inquilino onde residem os manuais de procedimentos e não no inquilino onde as regras de automatização estão definidas.

    No caso específico de um Fornecedor de Serviços de Segurança Gerida (MSSP), em que um inquilino do fornecedor de serviços gere uma área de trabalho Microsoft Sentinel num inquilino do cliente, existem dois cenários específicos que justificam a sua atenção:

    • Uma regra de automatização criada no tenant do cliente está configurada para executar um playbook localizado no tenant do prestador de serviços.

      Normalmente, esta abordagem é utilizada para proteger a propriedade intelectual no manual de procedimentos. Não é necessário nada de especial para que este cenário funcione. Ao definir uma ação de playbook na sua regra de automatização e, ao chegar à fase em que concede permissões ao Microsoft Sentinel no grupo de recursos relevante onde o playbook está localizado (utilizando o painel Gerir permissões do playbook), pode ver os grupos de recursos pertencentes ao tenant do fornecedor de serviços entre aqueles de que pode escolher. Veja todo o processo descrito aqui.

    • Uma regra de automatização criada no espaço de trabalho do cliente (tendo iniciado sessão no tenant do fornecedor de serviços) está configurada para executar um playbook localizado no tenant do cliente.

      Esta configuração é utilizada quando não é necessário proteger a propriedade intelectual. Para que este cenário funcione, as permissões para executar o manual de procedimentos têm de ser concedidas a Microsoft Sentinel em ambos os inquilinos. No inquilino do cliente, pode concedê-los no painel Gerir permissões do manual de procedimentos , tal como no cenário acima. Para conceder as permissões relevantes no tenant do fornecedor de serviços, tem de adicionar uma delegação adicional do Azure Lighthouse que concede direitos de acesso à aplicação Azure Security Insights, com a função Contribuidor de Automatização do Microsoft Sentinel, no grupo de recursos onde reside o playbook.

      O cenário tem o seguinte aspeto:

      Arquitetura multicliente de regras de automação

      Veja as nossas instruções para configurar esta configuração.

    Criar e gerir regras de automatização

    Pode criar e gerir regras de automatização a partir de diferentes áreas no Microsoft Sentinel ou no portal do Defender, consoante a sua necessidade específica e caso de utilização.

    • Página automatização

      As regras de automatização podem ser geridas centralmente na página Automatização , no separador Regras de automatização . A partir daí, pode criar novas regras de automatização e editar as existentes. Também pode arrastar regras de automatização para alterar a ordem de execução e ativá-las ou desativá-las.

      Na página Automatização , verá todas as regras definidas na área de trabalho, juntamente com o respetivo estado (Ativado/Desativado) e a que regras de análise são aplicadas.

      Quando precisar de uma regra de automatização que se aplique a incidentes de Microsoft Defender XDR ou de muitas regras de análise no Microsoft Sentinel, crie-a diretamente na página Automatização.

    • Assistente de regras de análise

      No separador Resposta automatizada do assistente de regras de análise de Microsoft Sentinel, em Regras de automatização, pode ver, editar e criar regras de automatização que se aplicam à regra de análise específica que está a ser criada ou editada no assistente.

      Quando cria uma regra de automatização a partir daqui, o painel Criar nova regra de automatização mostra a condição regra de análise como indisponível, uma vez que esta regra já está definida para ser aplicada apenas à regra de análise que está a editar no assistente. Todas as outras opções de configuração ainda estão disponíveis para si.

    • Página incidentes

      Também pode criar uma regra de automatização a partir da página Incidentes para responder a um único incidente periódico. Isto é útil ao criar uma regra de supressão para fechar automaticamente incidentes "ruidosos".

      Quando cria uma regra de automatização a partir daqui, o painel Criar nova regra de automatização preenche todos os campos com valores do incidente. Atribui o mesmo nome à regra que o incidente, aplica-a à regra de análise que gerou o incidente e utiliza todas as entidades disponíveis no incidente como condições da regra. Também sugere uma ação de supressão (fecho) por predefinição e sugere uma data de expiração para a regra. Pode adicionar ou remover condições e ações e alterar a data de expiração, conforme pretender.

    Exportar e importar regras de automatização

    Exporte as suas regras de automatização para ficheiros de modelo do Azure Resource Manager (ARM) e importe regras a partir desses ficheiros, como parte da gestão e do controlo das implementações do Microsoft Sentinel como código. A ação de exportação cria um ficheiro JSON na pasta de transferências do navegador, que depois pode renomear, mover e gerir como qualquer outro ficheiro.

    O ficheiro JSON exportado é independente da área de trabalho, pelo que pode ser importado para outras áreas de trabalho e até mesmo para outros inquilinos. Como código, também pode ser controlado por versões, atualizado e implementado numa estrutura CI/CD gerida.

    O ficheiro inclui todos os parâmetros definidos na regra de automatização. As regras de qualquer tipo de acionador podem ser exportadas para um ficheiro JSON.

    Para obter instruções sobre como exportar e importar regras de automatização, veja Exportar e importar Microsoft Sentinel regras de automatização.

    Passos seguintes

    Neste documento, aprendeu como as regras de automatização podem ajudá-lo a gerir centralmente a automatização de respostas para Microsoft Sentinel incidentes e alertas.