Elastic Workflows는 일반적으로 9.4에서 사용할 수 있습니다. 보안, 통합 가시성, 검색 전반에 걸쳐 데이터가 있는 곳에서 실행되는 Elastic에 직접 내장된 자동화 계층입니다. 이 게시물은 보안 심층 분석에 초점을 맞추고 있지만, 배포할 별도의 플랫폼이나 이동해야 할 데이터 없이 모든 솔루션에 동일한 워크플로 기능이 적용됩니다. 경보가 발령되거나 일정이 트리거되면 워크플로우가 실행됩니다. Elasticsearch 쿼리, 위협 인텔리전스로 보강, 사례 생성, 외부 API 호출, 팀 알림 등입니다. YAML로 정의하거나 자연어로 설명하면 AI가 워크플로우를 생성하도록 합니다.
9.3 테크 프리뷰에서는 Elastic의 기본 자동화를 위한 토대를 소개했습니다. 9.4는 프로덕션 안정성과 대폭 확장된 기능을 갖춘 정식 버전으로 출시됩니다. 사례 관리에서는 전체 수명 주기를 포괄하는 전용 자동화 단계( 25 )를 제공합니다. 휴먼 인 더 루프가 일류 워크플로의 기본이 됩니다. 자연어 작성 기능이 기술 미리보기로 이동합니다. 이 플랫폼은 더 많은 흐름 제어 기본 요소(while, switch, 반복 제어), 컬렉션 작업을 위한 데이터 변환 단계, 에이전트 빌더와의 심층적인 AI 통합, 더 광범위한 이벤트 중심 트리거를 제공합니다. Elastic 전반에 걸친 프로덕션 지원 자동화.
대규모 사례 자동화
보안 팀에게 가장 큰 추가 기능은 사례 관리입니다. 테크 프리뷰에서 사례 작업에는 생성, 검색, 업데이트, 댓글 달기 등 네 가지 일반적인 단계가 포함됩니다. 그 이상은 원시 API 호출이 필요합니다.
이제 생성, 찾기, 유사 항목 찾기, 업데이트, 닫기, 할당, 할당 취소, 알림 추가, 관찰 항목 추가, 댓글 추가, 태그 추가, 심각도 설정, 상태 설정 등 전체 수명 주기를 다루는 25 전용 cases.* 단계가 있습니다. 각 단계는 입력되고 유효성이 검사되어 YAML 편집기의 자동 완성 기능에 표시되므로 자연어 작성 기능도 정확하게 생성할 수 있습니다.
다음은 실제 분류 워크플로우의 모습입니다. 경고가 발령됩니다. 워크플로에서 이 알림에 대한 케이스가 이미 있는지 확인합니다. 그렇지 않은 경우 알림을 생성하고, 알림과 관찰 항목을 첨부하고, 대기 중인 분석가를 지정하고, 위험 점수에 따라 심각도를 라우팅합니다:
아래 코드는 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: true워크플로는 중복 제거, 증거 첨부, 관찰 가능한 보강, 누락된 필드 처리 및 분석가 할당을 자동으로 처리합니다. 분석가가 Kibana를 열면 모든 컨텍스트가 이미 있는 케이스를 볼 수 있습니다.
25 새로운 cases.* 단계에는 사용자 지정 필드, 사용자 작업 및 메트릭에 대한 만들기, 찾기, 유사 항목 찾기, 업데이트, 닫기, 삭제, 할당, 할당 취소, 알림 추가/제거, 관찰 항목 추가/제거, 댓글 추가/업데이트/삭제, 태그 추가/제거, 심각도 설정, 상태 설정, ID로 조회, 알림 ID로 조회 등의 기능이 포함되어 있습니다. 각 단계는 입력 및 유효성 검사를 거칩니다. 자연어 저작을 사용하는 경우 스키마의 일부이기 때문에 AI가 정확하게 생성할 수 있습니다.
워크플로가 성숙해지면 탐지 규칙 관리, 엔드포인트 대응 조치 및 위협 인텔리전스 운영을 위한 더 많은 도메인별 단계를 볼 수 있습니다.
자동화된 워크플로우의 인간 체크포인트
케이스 자동화는 기계적인 작업을 처리하지만 모든 의사 결정이 완전히 자동화되어서는 안 됩니다. AI가 알림을 분류하고 컨텍스트를 수집할 수는 있지만 에스컬레이션 여부는 분석가가 결정해야 합니다. 문제는 전화를 걸기 전에 얼마나 많은 기계적 작업이 이루어지는가입니다.
waitForInput 는 사람의 판단을 위해 워크플로를 일시 중지합니다. 워크플로에서 조사를 실행하고, 증거를 수집하고, AI로 경보를 분류한 후 중단합니다. 구조화된 결과를 제시하고 대기합니다. 분석가가 검토, 승인 또는 리디렉션하고 메모를 추가하면 입력한 내용을 바탕으로 워크플로가 다시 시작됩니다.
다음 이미지에서 볼 수 있듯이 자동화가 조사를 처리하지만, 분석가는 자동화가 실행하기 전에 결정을 내립니다.
AI로 수신 알림을 분류하고, 분석가의 검토 및 승인을 위해 일시 중지하며, 모델과 분석가 모두의 컨텍스트가 포함된 심각도가 높은 인시던트를 생성하여 승인된 사례만 에스컬레이션합니다.
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-reviewed현재 waitForInput 는 Kibana 실행 보기와 REST API를 통해 작동합니다. 분석가가 컨텍스트를 전환하지 않고도 검토하고 승인할 수 있도록 Slack, Teams 및 이메일 전달 채널이 곧 출시될 예정입니다. 이는 에이전트 빌더의 도구로 정의된 워크플로에서 특히 중요한데, 에이전트 중심 조사는 조치를 취하기 전에 사람이 직접 확인하는 것이 도움이 됩니다.
자연어로 워크플로 구축하기
자동화 패턴을 구축했다면 다음 과제는 접근성을 높이는 것입니다. 선언적이고, 검토가 가능하며, 이식성이 뛰어나기 때문에 워크플로 언어로 YAML을 선택했습니다. 하지만 이는 전략적인 선택이기도 했습니다. YAML은 구조화된 텍스트이고 대규모 언어 모델은 구조화된 텍스트를 생성하는 데 매우 능숙하기 때문입니다. 잘 입력된 워크플로 스키마는 AI 기반 저작을 위한 이상적인 대상입니다. 9.4에서는 그 베팅이 성과를 거두었습니다. 자연어 작성 기능은 기술 미리보기에서 사용할 수 있습니다.
워크플로 편집기에서 어떤 일이 일어날지 설명하세요: "맬웨어 알림이 발생하면 VirusTotal에서 파일 해시를 확인하고, 심각도가 높은 사례를 만들고, 알림과 관찰 항목을 첨부하고, SOC 채널에 알립니다(" ). AI 어시스턴트가 YAML을 생성합니다. 검토, 수정 및 배포합니다.
YAML은 완전히 검사하고 편집할 수 있습니다. 어떤 일이 일어나야 하는지는 알고 있지만 YAML 전문가가 아닌 경우, 의도에서 실제 워크플로로 전환할 수 있습니다. YAML 전문가인 경우 자연어로 시작하여 편집기에서 세분화할 수 있습니다.
저작 환경은 계속 발전할 것입니다. 시각적 편집은 보완적인 모드입니다. Slack 및 팀에서 사용하는 다른 도구로 확장되는 저작 기능입니다. 목표는 보안 팀이 일하는 모든 곳에서 보안 팀을 만나는 것입니다.
구성 가능한 워크플로
자동화 라이브러리가 커질수록 정리가 중요해집니다. 보안 자동화는 빠르게 복잡해지고 있습니다. 단일 분류 워크플로로 시작한 다음, 알림 유형마다 다른 조사 단계가 필요하다는 것을 깨닫게 됩니다. 조건문을 추가하고 또 조건문을 추가하면 갑자기 워크플로가 따라가기 어렵고 변경하기 어려운 중첩된 로직으로 수백 줄이 됩니다.
workflow.execute 를 사용하면 입력된 입력 및 출력으로 재사용 가능한 워크플로를 구축할 수 있습니다. 모든 조사 로직을 한 곳에 모으는 대신 특정 시나리오에 집중된 워크플로를 만들어 함께 구성할 수 있습니다. 멀웨어 조사 워크플로를 한 번 업데이트하면 이를 호출하는 모든 워크플로가 혜택을 받습니다. 로직이 체계적으로 유지되고, 변경 사항이 억제되며, 자동화가 취약해지지 않고 확장됩니다.
실제 모습은 다음과 같습니다. 경고를 분류한 다음 위협 유형에 따라 전문화된 워크플로로 라우팅합니다:
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] }}각 워크플로는 독립적으로 테스트할 수 있습니다. 대부분의 팀은 단일 워크플로로 시작하여 패턴이 나타나면 하위 워크플로를 추출합니다. 작곡은 성장하는 과정입니다.
템플릿 라이브러리는 결국 제품에 포함될 예정이므로 Kibana에서 미리 빌드된 워크플로를 직접 검색하고 설치할 수 있습니다.
분석가가 이미 근무하는 곳
워크플로는 의사 결정이 이루어지는 곳에서 사용할 수 있을 때 가장 유용합니다. 기본 요소와 패턴은 갖추어져 있지만, 분석가가 도구를 전환하지 않고도 자동화에 도달할 수 있을 때만 가치가 있습니다. 저희는 알림 테이블과 공격 검색을 시작으로 보안 분석가 경험 전반에서 워크플로우에 액세스할 수 있도록 하는 데 투자하고 있습니다. 분석가는 알림 또는 전체 공격을 워크플로로 직접 전송하여 현재 컨텍스트를 벗어나지 않고도 구축한 조사 로직을 트리거할 수 있습니다. 워크플로 자동화가 별도의 목적지가 아닌 분석가의 일상 업무의 일부가 될 수 있도록 이 통합은 계속 확장될 것입니다.
"알림 테이블의 워크플로 실행" 을 클릭하면 알림을 마우스 오른쪽 버튼으로 클릭(또는 여러 개 선택)하여 워크플로를 바로 트리거할 수 있습니다. 알림 컨텍스트는 자동으로 전달됩니다.
이것이 시작입니다. 워크플로는 보안 환경의 더 많은 부분으로 계속 확장되어 분석가가 필요한 곳에서 자동화에 액세스할 수 있게 될 것입니다.
더 많은 제어, 더 많은 유연성
주요 기능 외에도 워크플로 언어 자체의 기능이 더욱 향상되었습니다. 새로운 흐름 제어 프리미티브는 복잡한 로직을 보다 깔끔하게 처리할 수 있는 방법을 제공합니다. while 루프를 사용하면 조건을 폴링하거나 외부 상태 변경을 기다릴 수 있습니다. switch 는 중첩된 조건부 없이 카테고리별로 알림을 라우팅할 수 있도록 다방향 분기 기능을 제공합니다. loop.break 와 loop.continue 를 통해 표준 반복 제어 기능을 사용할 수 있습니다.
단계 수준의 데이터 변환 단계는 컬렉션에 대한 필터링, 찾기, 집계 및 JSON 작업을 처리하므로 사용자 지정 스크립팅 없이도 알림 목록, IOC 조회 및 보강 응답을 처리할 수 있습니다.
AI 단계(ai.prompt, ai.classify, ai.summarize, ai.agent)가 더욱 안정화되었으며 이제 구조화된 출력을 지원하므로 다운스트림 워크플로 로직에서 AI가 생성한 분류 및 요약을 더 쉽게 사용할 수 있습니다.
LiquidJS 템플릿도 확장되었습니다. 이제 변수를 설정하고 워크플로 전체에서 변수에 액세스할 수 있으므로 여러 단계에서 계산된 값을 더 쉽게 참조할 수 있습니다.
안정성 및 생산 관리
이 모든 것은 신뢰할 수 있는 경우에만 유용합니다. 모든 단계는 일시적인 실패 시 재시도, 단계가 중요하지 않은 경우 계속 진행, 결과에 따라 다운스트림 단계가 달라지는 경우 중단 등 on-failure 구성을 지원합니다. 오류에 대한 자세한 내용은 steps.<step-id>.error 에서 확인할 수 있으며 오류를 해결하는 데 도움이 됩니다.
동시성 제어는 알림 폭풍이 수백 개의 병렬 실행을 생성하는 것을 방지합니다. 루프 가드레일은 폭주 실행을 방지합니다. 컴포지션 깊이 제한은 무한 재귀를 방지합니다.
Elastic 9.4는 workflows.failed 에서부터 이벤트 기반 트리거를 도입합니다. 워크플로우 실행이 실패하면 별도의 핸들러 워크플로우를 트리거할 수 있습니다. 자동화가 중단되면 팀에게 알려주는 알림 워크플로를 구축하세요. 사례 상태 변경, 알림 상태 전환, 탐지 규칙 업데이트 등 더 많은 트리거 유형이 추가되어 보안 환경 전반에서 일어나는 일에 워크플로우가 반응할 수 있게 될 것입니다.
모든 실행은 waitForInput 단계의 분석가 결정을 포함하여 단계별 결과와 함께 실행 기록에 기록됩니다. 이것은 디버깅 도구이자 감사 추적입니다.
워크플로 기능은 9.4에서 엔터프라이즈 라이선스를 사용하는 경우 기본적으로 활성화됩니다. 세분화된 RBAC는 워크플로우를 만들고, 편집하고, 실행하고, 보는 사용자를 제어합니다. 모든 관리 작업은 보안 감사 로그에 기록됩니다. 가져오기/내보내기는 커넥터 참조를 그대로 유지한 채 환경 간에 워크플로우를 이동합니다.
라이선스 및 가격
워크플로는 Elastic Cloud Hosted 및 자체 관리형 배포의 Enterprise 라이선스와 보안용 Elastic Cloud 서버리스 프로젝트의 Complete 티어에서 사용할 수 있습니다.
버전 9.4에서는 모든 배포 유형에 걸쳐 통합된 실행 기반 요금 모델을 도입했습니다.
서버리스, Elastic Cloud 호스팅, 자체 관리형 모두에서 워크플로우 실행을 기준으로 가격이 책정되며, 규모에 따라 볼륨 기반 할인이 적용됩니다. 매월 청구되지 않는 워크플로 실행의 기본 할당량이 포함되어 있습니다. 이 할당량을 초과하는 사용량은 실행당 요금이 청구되며, 사용량이 증가할수록 볼륨 기반 할인이 적용됩니다.
Elastic Cloud Serverless는 5월부터 이 모델을 적용하기 시작합니다 1, 2026. 월별 청구되지 않은 실행 횟수를 초과하는 사용량은 실행당 요금이 부과되며, 사용량이 많을수록 할인이 적용됩니다. 전체 가격 세부 정보를 확인하세요.
Elastic Cloud Hosted와 자체 관리형 배포는 동일한 가격 모델을 따르지만, 현재 프로모션 기간 중이며 실행 요금은 아직 적용되지 않습니다. 이를 통해 팀은 워크플로를 구축 및 실행하고, 사용 패턴을 설정하고, 향후 릴리스에서 실행 기반 청구로 전환할 수 있도록 준비할 수 있습니다.
지금 바로 구축을 시작하세요. 현재 생성한 워크플로는 요금이 통합 모델로 전환되어도 계속 실행됩니다.
시작하기
워크플로는 9.4에서 기본적으로 활성화됩니다. Kibana를 열고 워크플로우로 이동한 다음 빌드를 시작합니다.
워크플로를 처음 사용하는 경우, 기술 미리보기 게시물에서 첫 번째 분류 워크플로를 구축하는 방법을 안내해 드립니다. Chrysalis APT 워크플로에서는 에이전트 빌더 통합이 실제로 작동하는 모습을 보여줍니다. 문서에 전체 단계 유형 참조가 있습니다. Elastic 워크플로우 라이브러리에는 바로 사용할 수 있는 템플릿이 있습니다.
이번 주에 팀의 시간을 가장 많이 절약할 수 있는 워크플로부터 시작하세요. 설명할 수 있다면 만들 수 있습니다.
이 게시물에서 설명된 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.