O Elastic Workflows está geralmente disponível na versão 9.4. É a camada de automação integrada diretamente no Elastic, executada onde seus dados residem, abrangendo Segurança, Observabilidade e Busca. Embora este artigo se concentre em uma análise aprofundada de segurança, as mesmas funcionalidades de fluxo de trabalho se aplicam a todas as soluções, sem necessidade de implantação em plataforma separada ou movimentação de dados. Quando um alerta é acionado ou um agendamento é ativado, um fluxo de trabalho é executado: consultando o Elasticsearch, enriquecendo-o com informações sobre ameaças, criando casos, chamando APIs externas e notificando sua equipe. Defina em YAML ou descreva em linguagem natural e deixe a IA gerar o fluxo de trabalho.
A versão 9.3 Tech Preview introduziu a base para a automação nativa no Elastic. A versão 9.4 torna o produto disponível ao público em geral, com estabilidade de produção e capacidades significativamente expandidas. O gerenciamento de casos recebe 25 etapas de automação dedicadas que abrangem todo o ciclo de vida. A intervenção humana torna-se um elemento primitivo de primeira classe nos fluxos de trabalho. A criação de conteúdo em linguagem natural passa para a fase de Prévia Técnica. A plataforma ganha mais primitivas de controle de fluxo (while, switch, controle de iteração), etapas de transformação de dados para trabalhar com coleções, integração de IA mais profunda com o Agent Builder e gatilhos orientados a eventos mais abrangentes. Automação pronta para produção em toda a Elastic.
Automação de casos em escala
A principal novidade para as equipes de segurança é o gerenciamento de casos. Na versão de pré-visualização técnica, trabalhar com casos envolvia quatro etapas genéricas: criar, recuperar, atualizar e comentar. Qualquer coisa além disso exigia chamadas diretas à API.
Agora existem 25 etapas cases.* dedicadas que cobrem todo o ciclo de vida: criar, encontrar, encontrar similares, atualizar, fechar, atribuir, remover atribuição, adicionar alertas, adicionar observáveis, adicionar comentários, adicionar tags, definir gravidade, definir status e muito mais. Cada etapa é digitada, validada e aparece no recurso de autocompletar do editor YAML, o que significa que a escrita em linguagem natural também pode gerá-las com precisão.
Eis como seria um fluxo de trabalho de triagem realista. Um alerta é acionado. O fluxo de trabalho verifica se já existe um caso para este alerta. Caso contrário, cria um alerta, anexa o alerta e os indicadores, atribui o analista de plantão e encaminha a gravidade com base na pontuação de risco:
O código abaixo mostra um exemplo de um fluxo de trabalho descrito usando YAML:
name: Triage Workflow
enabled: true
triggers:
- type: alert
steps:
- name: check_existing
type: cases.getCasesByAlertId
with:
alert_id: "{{ event.alerts[0]._id }}"
- name: route
type: if
condition: "steps.check_existing.output : ''"
steps:
- name: update_existing
type: cases.addComment
with:
case_id: "{{ steps.check_existing.output[0].id }}"
comment: |
Correlated alert: {{ event.rule.name }}
Source: {{ event.alerts[0].source.ip | default: "unknown" }}
Risk score: {{ event.alerts[0].kibana.alert.risk_score }}
else:
- name: create_case
type: cases.createCase
with:
owner: securitySolution
title: "{{ event.rule.name }} - {{ event.alerts[0].host.name }}"
description: |
Auto-created from detection rule: {{ event.rule.name }}
Host: {{ event.alerts[0].host.name }}
Source IP: {{ event.alerts[0].source.ip | default: "N/A" }}
severity: high
tags:
- auto-triage
- "{{ event.rule.name }}"
- name: attach_evidence
type: cases.addAlerts
with:
case_id: "{{steps.create_case.output.case.id}}"
alerts:
- alertId: "{{ event.alerts[0]._id }}"
index: "{{ event.alerts[0]._index }}"
- name: add_observables
type: cases.addObservables
with:
case_id: "{{steps.create_case.output.case.id}}"
observables:
- typeKey: observable-type-ipv4
value: "{{ event.alerts[0].source.ip }}"
- typeKey: observable-type-file-hash
value: "{{ event.alerts[0].file.hash.sha256 }}"
on-failure:
continue: trueO fluxo de trabalho lida automaticamente com a desduplicação, anexação de evidências, enriquecimento observável, tratamento adequado de campos ausentes e atribuição de analistas. O analista abre o Kibana e vê um caso com todo o contexto já inserido.
As novas etapas 25 cases.* incluem criar, encontrar, encontrar similares, atualizar, fechar, excluir, atribuir, desatribuir, adicionar/remover alertas, adicionar/remover observáveis, adicionar/atualizar/excluir comentários, adicionar/remover tags, definir gravidade, definir status, obter por ID, obter por ID de alerta e muito mais para campos personalizados, ações do usuário e métricas. Cada etapa é digitada e validada. Se você estiver usando a criação de conteúdo em linguagem natural, a IA poderá gerá-los com precisão porque fazem parte do esquema.
À medida que os fluxos de trabalho amadurecem, você verá mais etapas específicas de domínio para gerenciamento de regras de detecção, ações de resposta de endpoint e operações de inteligência de ameaças.
Pontos de verificação humana em fluxos de trabalho automatizados
A automação de processos cuida do trabalho mecânico, mas nem todas as decisões devem ser totalmente automatizadas. A IA pode classificar um alerta e coletar contexto, mas cabe ao analista decidir se é necessário encaminhá-lo para instâncias superiores. A questão é quanto trabalho mecânico é realizado antes que eles tomem essa decisão.
waitForInput Interrompe um fluxo de trabalho para avaliação humana. O fluxo de trabalho executa a investigação, coleta evidências, classifica o alerta com IA e o encerra. Apresenta resultados estruturados e aguarda. O analista revisa, aprova ou redireciona, e adiciona notas, e então o fluxo de trabalho é retomado com base nas suas contribuições.
Como mostra a imagem a seguir, a automação realiza a investigação, mas
analista toma a decisão antes
a automação a execute. Classifica alertas recebidos com IA, pausa para revisão e aprovação do analista e só encaminha casos aprovados, criando um incidente de alta gravidade com contexto tanto do modelo quanto do analista.
name: HITL Example
enabled: true
triggers:
- type: alert
steps:
- name: classify
type: ai.classify
connector-id: Anthropic-Claude-Sonnet-4-6
with:
includeRationale: true
input: ${{ event.alerts[0] }}
categories:
- true_positive
- false_positive
- needs_investigation
- name: approval_gate
type: waitForInput
with:
message: |
Alert: {{ event.rule.name }}
Classification: {{ steps.classify.output.category }}
Rationale: {{ steps.classify.output.rationale }}
Review the classification and approve to escalate.
schema:
type: object
properties:
approved:
type: boolean
title: Approve escalation
notes:
type: string
title: Analyst notes
required:
- approved
- name: escalate
type: if
condition: "steps.approval_gate.output.approved : true"
steps:
- name: create_escalated_case
type: cases.createCase
with:
owner: securitySolution
title: "[Escalated] {{ event.rule.name }}"
description: |
Escalated by analyst after AI classification.
Classification: {{ steps.classify.output.category }}
Notes: {{ steps.approval_gate.output.notes }}
severity: high
tags:
- escalated
- analyst-reviewedHoje, waitForInput funciona através da visualização de execução do Kibana e da API REST. O Slack, o Teams e os canais de entrega por e-mail estão chegando para que os analistas possam revisar e aprovar sem precisar mudar de contexto. Isso é especialmente importante para fluxos de trabalho definidos como ferramentas no Agent Builder, onde investigações orientadas por agentes se beneficiam de verificações humanas antes de qualquer ação ser tomada.
Construindo fluxos de trabalho a partir da linguagem natural
Com os padrões de automação implementados, o próximo desafio é torná-los acessíveis. Escolhemos o YAML como linguagem de fluxo de trabalho porque é declarativo, revisável e portátil. Mas também foi uma escolha estratégica: YAML é texto estruturado, e grandes modelos de linguagem são muito bons em gerar texto estruturado. Um esquema de fluxo de trabalho bem tipado é um alvo ideal para a autoria com auxílio de IA. Em 9.4, essa aposta compensa. A criação de conteúdo em linguagem natural está disponível na versão de pré-visualização técnica.
Dentro do editor de fluxo de trabalho, descreva o que deve acontecer: "Quando um alerta de malware for acionado, verifique o hash do arquivo no VirusTotal, crie um caso de alta gravidade, anexe o alerta e os indicadores observáveis e notifique o canal do SOC." O assistente de IA gera o YAML. Você revisa, aprimora e implementa.
O arquivo YAML pode ser totalmente inspecionado e editado. Se você sabe o que deve acontecer, mas não é um especialista em YAML, isso te ajuda a transformar sua intenção em um fluxo de trabalho funcional. Se você é especialista em YAML, pode começar escrevendo em linguagem natural e refinar o texto no editor.
A experiência de autoria continuará evoluindo. A edição visual é uma modalidade complementar. Criação de conteúdo que se estende ao Slack e a outras ferramentas que sua equipe utiliza. O objetivo é atender às equipes de segurança onde quer que elas trabalhem.
Fluxos de trabalho componíveis
À medida que sua biblioteca de automação cresce, a organização torna-se fundamental. A automação de segurança torna-se complexa rapidamente. Você começa com um único fluxo de trabalho de triagem e, em seguida, percebe que diferentes tipos de alertas exigem diferentes etapas de investigação. Você adiciona condicionais, depois mais condicionais, e de repente seu fluxo de trabalho se torna centenas de linhas com lógica aninhada, difícil de acompanhar e ainda mais difícil de alterar.
workflow.execute Permite criar fluxos de trabalho reutilizáveis com entradas e saídas tipadas. Em vez de concentrar toda a lógica de investigação em um só lugar, você cria fluxos de trabalho específicos para cenários específicos e os combina. Atualize seu fluxo de trabalho de investigação de malware uma única vez, e todos os fluxos de trabalho que o utilizam serão beneficiados. A lógica permanece organizada, as alterações são controladas e sua automação se expande sem se tornar frágil.
Eis como isso se parece na prática. Classifique o alerta e, em seguida, encaminhe-o para o fluxo de trabalho especializado com base no tipo de ameaça:
steps:
- name: dispatch
type: switch
expression: "{{ steps.classify.output.category }}"
cases:
- match: malware
steps:
- name: run_malware
type: workflow.execute
with:
workflow-id: ${{ consts.malware_workflow_id }}
inputs:
alert: ${{ event.alerts[0] }}
- match: phishing
steps:
- name: run_phishing
type: workflow.execute
with:
workflow-id: ${{ consts.phishing_workflow_id }}
inputs:
alert: ${{ event.alerts[0] }}
default:
- name: run_generic
type: workflow.execute
with:
workflow-id: ${{ consts.generic_triage_id }}
inputs:
alert: ${{ event.alerts[0] }}Cada fluxo de trabalho pode ser testado de forma independente. A maioria das equipes começa com um único fluxo de trabalho e extrai subfluxos de trabalho à medida que os padrões emergem. Composição é algo que se desenvolve com o tempo.
A biblioteca de modelos será eventualmente integrada ao produto, permitindo que você descubra e instale fluxos de trabalho pré-configurados diretamente no Kibana.
Onde os analistas já trabalham
Os fluxos de trabalho são mais úteis quando estão disponíveis no local onde as decisões são tomadas. Os princípios e padrões já estão definidos, mas a automação só agrega valor se os analistas conseguirem acessá-la sem precisar trocar de ferramentas. Estamos investindo em tornar os fluxos de trabalho acessíveis em toda a experiência do analista de segurança, começando pela tabela de alertas e pela descoberta de ataques. Os analistas podem enviar alertas ou ataques completos diretamente para um fluxo de trabalho, acionando a lógica de investigação que desenvolveram sem sair do contexto atual. Essa integração continuará se expandindo para que a automação do fluxo de trabalho se torne parte integrante do trabalho diário do analista, e não um destino separado.
A opção "Executar fluxo de trabalho" na tabela de alertas permite clicar com o botão direito do mouse em um alerta (ou selecionar vários) e acionar um fluxo de trabalho diretamente. O contexto de alerta é transmitido automaticamente.
Este é o começo. Os fluxos de trabalho continuarão a se expandir para mais partes da experiência de segurança, tornando a automação acessível onde os analistas precisarem dela.
Mais controle, mais flexibilidade
Além das principais funcionalidades, a própria linguagem Workflow tornou-se mais capaz. Os novos recursos de controle de fluxo oferecem maneiras mais claras de lidar com lógica complexa. Os loops while permitem que você verifique condições ou aguarde mudanças de estado externas. switch fornece ramificação múltipla para que você possa rotear alertas por categoria sem condicionais aninhados. loop.break e loop.continue fornecem controle de iteração padrão.
As etapas de transformação de dados em nível de passo lidam com filtragem, localização, agregação e operações JSON em coleções, permitindo processar listas de alertas, pesquisas de indicadores de comprometimento (IOCs) e respostas de enriquecimento sem a necessidade de scripts personalizados.
As etapas de IA (ai.prompt, ai.classify, ai.summarize, ai.agent) são mais estáveis e agora suportam saídas estruturadas, tornando mais fácil usar classificações e resumos gerados por IA na lógica de fluxo de trabalho subsequente.
O recurso de templates LiquidJS também foi expandido. Agora você pode definir variáveis e acessá-las em todo o fluxo de trabalho, facilitando a referência a valores calculados em várias etapas.
Confiabilidade e controles de produção
Tudo isso só é útil se for confiável. Cada etapa suporta a configuração on-failure : tentar novamente em caso de falhas transitórias, continuar quando uma etapa não for crítica e abortar quando as etapas subsequentes dependerem do resultado. Os detalhes do erro estão disponíveis em steps.<step-id>.error para ajudar a contornar as falhas.
Os controles de concorrência impedem que tempestades de alertas gerem centenas de execuções paralelas. Os mecanismos de proteção em forma de laço impedem a execução descontrolada. Os limites de profundidade da composição impedem a recursão infinita.
O Elastic 9.4 introduz gatilhos orientados a eventos, começando com workflows.failed. Quando a execução de um fluxo de trabalho falha, isso pode acionar um fluxo de trabalho de tratamento separado. Crie um fluxo de trabalho de notificações que alerte sua equipe quando a automação falhar. Mais tipos de gatilhos estão a caminho: alterações no status do caso, transições no estado do alerta e atualizações nas regras de detecção, tornando os fluxos de trabalho reativos ao que está acontecendo em todo o seu ambiente de segurança.
Cada execução é registrada no histórico de execução com resultados passo a passo, incluindo decisões do analista a partir de waitForInput etapas. Esta é a sua ferramenta de depuração e o seu registro de auditoria.
Os fluxos de trabalho estão ativados por padrão na versão 9.4 com uma licença Enterprise. O RBAC granular controla quem cria, edita, executa e visualiza fluxos de trabalho. Todas as operações de gerenciamento registram informações no log de auditoria de segurança. A importação/exportação move fluxos de trabalho entre ambientes, mantendo intactas as referências dos conectores.
Licenciamento e preços
O Workflows está disponível com uma licença Enterprise em implantações hospedadas e autogerenciadas do Elastic Cloud, e com o nível Complete em projetos Elastic Cloud Serverless for Security.
A versão 9.4 introduz um modelo de precificação unificado baseado na execução para todos os tipos de implantação.
Em soluções Serverless, Elastic Cloud Hosted e autogerenciadas, o preço é baseado na execução de fluxos de trabalho, com descontos por volume em escala. Cada mês inclui uma alocação básica de execuções de fluxo de trabalho que não são faturadas. O uso além dessa alocação será cobrado por execução, com descontos baseados no volume aplicados conforme o uso aumenta.
O Elastic Cloud Serverless começa a aplicar este modelo em maio de 1, 2026. O uso que exceda as execuções mensais não faturadas será cobrado por execução, com descontos para volumes maiores. Veja os detalhes completos dos preços.
As implementações hospedadas e autogerenciadas do Elastic Cloud seguem o mesmo modelo de preços, mas estão atualmente em período promocional , com taxas de execução ainda não aplicadas. Isso permite que as equipes criem e executem fluxos de trabalho, estabeleçam padrões de uso e se preparem para a transição para a cobrança baseada em execução em uma versão futura.
Comece a construir agora. Os fluxos de trabalho que você criar hoje continuarão funcionando durante a transição de preços para o modelo unificado.
Para começar
Os fluxos de trabalho estão ativados por padrão na versão 9.4. Abra o Kibana, navegue até Fluxos de Trabalho e comece a criar.
Se você é novo no Workflows, a publicação de Prévia Técnica mostra como criar seu primeiro Workflow de triagem. O fluxo de trabalho Chrysalis APT demonstra a integração do Agent Builder em ação. A documentação contém a referência completa dos tipos de etapa. A Biblioteca de Fluxo de Trabalho Elástico possui modelos prontos para uso.
Comece com o fluxo de trabalho que economizaria mais tempo para sua equipe esta semana. Se você consegue descrever, você consegue construir.
O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.