운영 워크플로에 직접 맞게 탐색 구조를 재구성했습니다. 자세한 내용은 Google SecOps 출시 노트를 참고하세요.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

다단계 쿼리 만들기

다음에서 지원:

Google secops SIEM

이 문서에서는 YARA-L의 다단계 쿼리를 사용하여 한 쿼리 단계의 출력을 후속 단계의 입력에 직접 제공하는 방법을 설명합니다. 이 프로세스를 사용하면 단일 모놀리식 쿼리보다 데이터 변환을 더 효과적으로 제어할 수 있습니다.

다단계 쿼리를 기존 기능과 통합

다단계 쿼리는 Google Security Operations의 다음 기존 기능과 함께 작동합니다.

복합 감지 규칙: 다단계 쿼리는 자동 감지와 적극적인 조사 간의 격차를 해소하여 복합 감지 규칙을 보완합니다. 복합 규칙은 확장된 기간 동안 복잡한 다중 이벤트 상관관계를 식별하는 데 탁월하지만, 다단계 쿼리를 사용하면 분석가가 이러한 감지에서 실시간 반복 검색으로 전환하여 전개되는 위협을 즉시 검증하고 범위를 지정할 수 있습니다.
기간 및 멀티 이벤트 규칙: 다단계 쿼리를 사용하여 데이터 내의 여러 기간을 비교하여 이상치를 감지할 수 있습니다. 예를 들어 초기 쿼리를 사용하여 장기간에 걸쳐 기준을 설정한 다음, 후속 쿼리를 사용하여 최근 활동을 해당 기준과 비교하여 평가할 수 있습니다. 다중 이벤트 규칙을 사용하여 유사한 유형의 비교를 만들 수도 있습니다.

YARA-L의 다단계 쿼리는 대시보드와 검색 모두에서 지원됩니다.

조인을 사용하면 여러 소스의 데이터를 상호 연관시켜 조사에 더 많은 컨텍스트를 제공할 수 있습니다. 관련 이벤트, 항목, 기타 데이터를 연결하여 복잡한 공격 시나리오를 조사할 수 있습니다. 자세한 내용은 검색에서 조인 사용을 참고하세요.

주요 고려사항

다단계 쿼리를 구성할 때는 다음 사항에 유의하세요.

제한 단계: 다단계 쿼리에는 루트 단계 외에 이름이 지정된 단계가 1~4개 포함되어야 합니다.
순서 구문: 항상 루트 단계 구문을 정의하기 전에 이름이 지정된 단계 구문을 정의합니다.

다단계 쿼리를 구현할 때는 다음 알려진 문제와 권장되는 해결 방법을 검토하는 것이 좋습니다.

모든 다단계 쿼리는 통계 검색 쿼리와 같이 작동합니다 (출력은 집계되지 않은 이벤트 또는 데이터 테이블 행이 아닌 집계된 통계로 구성됨).
한쪽의 UDM 및 항목 이벤트와의 조인 성능은 해당 데이터 세트의 크기로 인해 성능이 저하될 수 있습니다. 조인의 UDM 및 항목 이벤트를 최대한 많이 필터링하는 것이 좋습니다 (예: 이벤트 유형으로 필터링).

권장사항에 관한 일반적인 안내는 YARA-L 2.0 권장사항을 참고하고, 조인 관련 정보는 권장사항을 참고하세요.

주요 용어

조인 컨텍스트에서 윈도우 처리된 단계는 윈도우가 포함된 match 섹션이 있는 단계를 의미합니다. 반면 테이블 스테이지는 창을 출력하지 않습니다.

다단계 YARA-L 쿼리 만들기

다단계 YARA-L 쿼리를 만들려면 다음 단계를 완료하세요.

단계 구조 및 문법

조사 > 검색으로 이동합니다. 쿼리 단계를 정의할 때는 다음 구조를 따르세요.

구문: 각 단계를 명명하고 다른 단계와 구분하려면 다음 구문을 사용합니다.

stage <stage name> { }

중괄호: 모든 단계 문법을 중괄호 {} 안에 배치합니다.
순서: 루트 단계를 정의하기 전에 이름이 지정된 모든 단계의 구문을 정의합니다.
참조: 각 단계는 쿼리에서 이전에 정의된 단계를 참조할 수 있습니다.
루트 단계: 쿼리에는 모든 명명된 단계 후에 처리되는 루트 단계가 있어야 합니다.

다음 예시 단계 daily_stats는 일일 네트워크 통계를 수집합니다.

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""
  match:
    $source, $target by day
  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

액세스 스테이지 출력

명명된 단계의 출력은 단계 필드를 사용하여 후속 단계에서 액세스할 수 있습니다. 스테이지 필드는 스테이지의 match 및 outcome 변수에 해당하며 통합 데이터 모델 (UDM) 필드와 유사하게 사용할 수 있습니다.

다음 구문을 사용하여 스테이지 필드에 액세스합니다.

$<stage name>.<variable name>

선택사항: 액세스 창 타임스탬프

명명된 스테이지에서 홉, 슬라이딩 또는 텀블링 윈도우를 사용하는 경우 다음 예약된 필드를 사용하여 각 출력 행의 윈도우 시작 및 윈도우 끝에 액세스합니다.

$<stage name>.window_start
$<stage name>.window_end

window_start 및 window_end은 Unix 에포크 이후 초 단위로 표현된 정수 필드입니다. 단계별 기간은 크기가 다를 수 있습니다.

다단계 쿼리 예시

이 섹션의 예는 완전한 다단계 YARA-L 쿼리를 만드는 방법을 보여줍니다.

예: 비정상적으로 활성 상태인 네트워크 연결 검색 (시간)

이 다단계 YARA-L 예시에서는 정상보다 네트워크 활동이 많은 IP 주소 쌍을 식별하여 3시간 이상 높은 활동을 유지하는 쌍을 타겟팅합니다. 쿼리에는 이름이 지정된 단계(hourly_stats)와 root 단계라는 두 가지 필수 구성요소가 포함됩니다.

hourly_stats 단계에서는 네트워크 활동 수준이 높은 principal.ip 및 target.ip 쌍을 검색합니다.

이 단계에서는 다음 필드에 대해 시간별 단일 값을 반환합니다.

소스 IP 통계 (문자열): $hourly_stats.src_ip
대상 IP 통계 (문자열): $hourly_stats.dst_ip
이벤트 수 (정수) 통계: $hourly_stats.count
표준 편차 수신 바이트 (부동 소수점): $hourly_stats.std_recd_bytes
평균 수신 바이트 (부동 소수점): $hourly_stats.avg_recd_bytes
시간 버킷 시작 시간 (초 단위, 유닉스 시간 기준, 정수): $hourly_stats.window_start
시간 버킷 종료 시간 (초 단위, 유닉스 시간 기준, 정수): $hourly_stats.window_end

루트 단계는 hourly_stats 단계의 출력을 처리합니다. $hourly_stats에 지정된 기준점을 초과하는 활동이 있는 principal.ip 및 target.ip 쌍의 통계를 계산합니다. 그런 다음 활동이 많은 시간이 3시간을 초과하는 페어를 필터링합니다.


stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip by hour

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

루트 단계에서 다음과 같이 일치 조건을 변경하면 다단계 쿼리에 대해 일별로 창 집계를 도입할 수 있습니다.

match:
 $src_ip, $dst_ip by day

예: 비정상적으로 활성 상태인 네트워크 연결 검색 (Z 점수 사용)

이 다단계 쿼리는 Z 점수 계산 (평균에서 벗어난 표준 편차 수 측정)을 사용하여 일일 평균 네트워크 활동을 오늘의 활동과 비교합니다. 이 쿼리는 내부 애셋과 외부 시스템 간의 비정상적으로 높은 네트워크 활동을 효과적으로 검색합니다.

기본 요건: 계산된 Z 점수가 유효하려면 쿼리 기간이 2일 이상이어야 하고 당일이 포함되어야 합니다.

이 다단계 쿼리에는 daily_stats 단계와 root 단계가 포함되어 있으며, 이 두 단계는 함께 작동하여 네트워크 활동의 Z 점수를 계산합니다.

daily_stats 단계는 초기 일일 집계를 실행합니다. 각 IP 쌍 (source 및 target)에 대해 매일 교환된 총 바이트를 계산하고 다음 단계 필드 (출력 행의 열에 해당)를 반환합니다.
- $daily_stats.source: 단수, 문자열
- $daily_stats.target: 단수, 문자열
- $daily_stats.exchanged_bytes: 단수, 정수
- $daily_stats.window_start: 단수, 정수
- $daily_stats.window_end: 단수, 정수
루트 단계에서는 각 IP 쌍의 daily_stats 단계 출력을 집계합니다. 전체 검색 범위에서 교환된 일일 바이트의 평균과 표준 편차를 오늘 교환된 바이트와 함께 계산합니다. 이러한 세 가지 계산된 값을 사용하여 Z-점수를 결정합니다.
출력에는 오늘 모든 IP 쌍의 Z 점수가 내림차순으로 정렬되어 표시됩니다.

// Calculate the total bytes exchanged per day by source and target

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""

  match:
    $source, $target by day

  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

// Calculate the average per day over the time window and compare with the bytes exchanged today

$source = $daily_stats.source
$target = $daily_stats.target
$date = timestamp.get_date($daily_stats.window_start)

match:
  $source, $target

outcome:
  $today_bytes = sum(if($date = timestamp.get_date(timestamp.current_seconds()), cast.as_int($daily_stats.exchanged_bytes), 0))
  $average_bytes = window.avg($daily_stats.exchanged_bytes)
  $stddev_bytes = window.stddev($daily_stats.exchanged_bytes)
  $zscore = ($today_bytes - $average_bytes) / $stddev_bytes

order:
  $zscore desc

단계에서 집계되지 않은 변수 내보내기

일반적인 다단계 쿼리에서는 집계 프로세스를 통해 단계 간에 데이터가 전달되는 경우가 많으며, 이 경우 여러 이벤트가 하나의 요약으로 '축소'될 수 있습니다. 하지만 세부사항을 잃지 않고 고유한 프로세스 ID나 특정 명령줄과 같은 모든 이벤트의 세부정보를 보존해야 하는 시나리오도 있습니다. 이를 지원하기 위해 그룹화 함수 없이 변수를 직접 내보낼 수 있습니다.

이름이 지정된 단계에는 집계되지 않은 outcome 섹션이 포함될 수 있습니다. 즉, 해당 outcome 섹션 내에 정의된 변수는 단계에서 직접 출력되므로 후속 단계에서 그룹화된 집계 없이 단계 필드로 액세스할 수 있습니다.

이 세부정보는 다음과 같은 이유로 유용합니다.

데이터 충실도 유지: max() 또는 array_distinct()와 같은 인공 '자리표시자' 집계를 사용하지 않고도 이벤트의 정확한 속성 (예: 특정 파일 경로)을 다음 단계로 전달할 수 있습니다.
쿼리 복잡성 감소: 1단계에서 2단계로 값을 전송하기 위해 match 섹션이 필요하거나 문을 그룹화할 필요가 없으므로 YARA-L 로직이 간소화됩니다.
성능 최적화: 집계 엔진을 우회함으로써 시스템이 단계 간에 데이터를 더 효율적으로 스트리밍할 수 있으므로 복잡하고 대량의 검색의 실행 시간이 단축됩니다.

예: 집계되지 않은 변수 내보내기

이 예에서는 집계되지 않은 변수를 내보내는 방법을 보여줍니다. 다음 로직을 참고하세요.

top_5_bytes_sent 단계에서는 네트워크 활동이 가장 많은 5개의 이벤트를 검색합니다.
top_5_bytes_sent 단계는 출력 행의 열에 해당하는 다음 단계 필드를 출력합니다.
- $top_5_bytes_sent.bytes_sent: 단수, 정수
- $top_5_bytes_sent.timestamp_seconds: 단수, 정수
root 단계에서는 네트워크 활동이 가장 많은 5개 이벤트의 최신 및 가장 빠른 타임스탬프를 계산합니다.

stage top_5_bytes_sent {
  metadata.event_type = "NETWORK_CONNECTION"
  network.sent_bytes > 0

  outcome:
    $bytes_sent = network.sent_bytes
    $timestamp_seconds = metadata.event_timestamp.seconds

  order:
    $bytes_sent desc

  limit:
    5
}

outcome:
  $latest_timestamp = timestamp.get_timestamp(max($top_5_bytes_sent.timestamp_seconds))
  $earliest_timestamp = timestamp.get_timestamp(min($top_5_bytes_sent.timestamp_seconds))

다단계 쿼리에서 윈도우 기능 구현

다단계 감지에서 윈도우를 사용하면 단계 내 이벤트 상관관계에 대한 특정 시간 경계를 정의할 수 있습니다. 데이터를 5분 슬라이딩 윈도우 또는 1시간 텀블링 윈도우와 같은 개별 시간 버킷으로 파티셔닝하면 시간 제한 시퀀스로 분석할 때만 표시되는 무차별 대입 공격 또는 비콘 동작과 같은 패턴을 식별할 수 있습니다.

다단계 쿼리는 명명된 단계에서 모든 유형의 윈도우 (홉, 슬라이딩, 텀블링)를 지원합니다. 이를 통해 1단계를 사용하여 빈도가 높은 이벤트 기간을 식별하고 2단계를 사용하여 해당 특정 기간을 후속 관리 작업과 연관시키는 등 단계 간에 시간 맥락화된 데이터를 전달할 수 있습니다.

명명된 스테이지에 윈도우가 포함된 경우 각 출력 행의 윈도우 시작 및 윈도우 종료는 다음 예약된 필드를 사용하여 액세스할 수 있습니다.

$stage_window_start: 기간의 시작을 표시하는 Unix 타임스탬프입니다.
$stage_window_end: 기간의 종료를 표시하는 Unix 타임스탬프입니다.

윈도잉에 대한 자세한 내용은 YARA-L 2.0 윈도잉 로직을 참고하세요.

일반적인 사용 사례

순차적 감지: 감지된 로그인 실패 급증의 특정 기간을 그 직후에 로그인 성공을 찾는 두 번째 단계로 전달합니다.
기간 분석: 초기 익스플로잇 단계의 $stage_window_start를 후반 단계의 이벤트 타임스탬프와 비교하여 '침해까지 걸린 시간'을 계산합니다.
이전 기준 설정: 창을 사용하여 현재 이벤트 수를 이전 창의 출력 변수와 비교합니다.

예: 홉 윈도우

다음 예에서는 다단계 쿼리에서 홉 윈도우를 사용하는 방법을 보여줍니다.

hourly_stats 단계에서는 동일한 시간 내에 네트워크 활동이 많은 IP 쌍을 검색합니다.
hourly_stats는 출력 행의 열에 해당하는 다음 단계 필드를 출력합니다.
- $hourly_stats.src_ip: 단수, 문자열
- $hourly_stats.dst_ip: 단수, 문자열
- $hourly_stats.count: 단수, 정수
- $hourly_stats.std_recd_bytes: 단수, 부동 소수점
- $hourly_stats.avg_recd_bytes: 단수, 부동 소수점
- $hourly_stats.window_start: 단수, 정수
- $hourly_stats.window_end: 단수, 정수
루트 단계에서는 활동이 많은 시간이 3시간을 초과하는 IP 쌍을 필터링합니다. hourly_stats 단계에서 홉 윈도우를 사용하면 시간이 겹칠 수 있습니다.

stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip over 1h

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

다단계 쿼리의 내부 조인

내부 조인을 사용하면 다양한 단계 또는 소스 유형의 데이터를 상호 연관시켜 사전 계산된 통계 기준과 실시간 이벤트를 비교하는 등 복잡한 분석 워크플로를 만들 수 있습니다. 단계를 결합하면 단일 단계 이벤트 필터에서 놓칠 수 있는 이상치 또는 다중 벡터 위협을 식별하기 위해 상태 저장 데이터 (예: 중앙값 또는 조회 테이블)로 원시 원격 분석을 보강할 수 있습니다.

내부 조인은 다단계 쿼리의 단계 내 및 단계 간에 지원됩니다. 내부 조인 기능은 다음 유형을 지원합니다.

UDM 및 UDM: 서로 다른 두 보안 이벤트 집합을 상호 연관시킵니다 (예: 로그인 이벤트와 후속 파일 액세스 매칭).
UDM 및 ECG: ID 또는 애셋 보강을 위해 이벤트 데이터를 항목 컨텍스트 그래프 정보와 병합합니다.
UDM 및 데이터 테이블: 정적 또는 업로드된 참조 목록 (예: 가치가 높은 애셋 목록 또는 부서별 IP 범위)에 대해 실시간 이벤트를 조인합니다.

다음 예에서는 UDM 이벤트와 계산된 테이블 단계 간에 일치하지 않는 조인 (match 섹션이 아닌 outcome 또는 events 섹션에서 실행되는 조인)을 구성하는 방법을 보여줍니다. 이 패턴을 사용하면 다음 평균 절대 편차 (MAD) 계산과 같이 통계적 이상 감지를 실행할 수 있습니다.

median 단계: 각 소스 호스트와 대상 IP 쌍에 대해 전송된 바이트의 중앙값을 계산합니다.
- $median.host: 단수, 문자열
- $median.target: 단수, 문자열
- $median.median: 단수, 부동 소수점
absolute_deviations 단계: 각 UDM 이벤트를 중간 단계의 해당 행과 조인합니다. 이를 통해 동종업체 그룹과 관련된 각 개별 이벤트에 대해 전송된 바이트의 절대 편차를 계산할 수 있습니다.
- $absolute_deviations.host: 단수, 문자열
- $absolute_deviations.target: 단수, 문자열
- $absolute_deviations.absolute_deviation: 단수, 부동 소수점
루트 단계: 모든 UDM 이벤트에서 이러한 절대 편차의 평균을 계산하여 비정상치 기준점을 설정합니다.

예: 일치하지 않는 조인 구성

stage median {
  metadata.event_type = "NETWORK_CONNECTION"
  $host = principal.hostname
  $target = target.ip

  match:
    $host, $target

  outcome:
    $median = window.median(network.sent_bytes, true)
}

stage absolute_deviations {
  metadata.event_type = "NETWORK_CONNECTION"
  $join_host = principal.hostname
  $join_host = $median.host
  $join_target = target.ip[0]
  $join_target = $median.target

  outcome:
    $host = $join_host
    $target = $join_target
    $absolute_deviation = math.abs(network.sent_bytes - $median.median)
}

$host = $absolute_deviations.host
$target = $absolute_deviations.target

match:
  $host, $target

outcome:
  $mean_absolute_deviation = avg($absolute_deviations.absolute_deviation)

예: 윈도우 처리 단계와 테이블 단계 간의 일치하지 않는 조인

다음 예시에서는 다단계 쿼리에서 윈도우 단계와 테이블 단계 간에 일치하지 않는 조인을 구성하는 방법을 보여줍니다.

hourly_stats 단계에서는 각 소스 및 타겟 호스트 쌍과 시간 버킷에 대해 전송된 총 바이트를 계산합니다.
hourly_stats 단계에서는 출력 행의 열에 해당하는 다음 단계 필드를 출력합니다.
- $hourly_stats.source_host: 단수, 문자열
- $hourly_stats.dst_host: 단수, 문자열
- $hourly_stats.total_bytes_sent: 단수, 부동 소수점
- $hourly_stats.window_start: 단수, 정수
- $hourly_stats.window_end: 단수, 정수
agg_stats 단계에서는 각 소스 및 타겟 호스트 쌍의 시간당 바이트의 평균과 표준 편차를 계산합니다.
agg_stats는 출력 행의 열에 해당하는 다음 단계 필드를 출력합니다.
- $agg_stats.source_host: 단수, 문자열
- $agg_stats.dst_host: 단수, 문자열
- $agg_stats.avg_bytes_sent: 단수, 부동 소수점
- $agg_stats.stddev_bytes_sent: 단수, 부동 소수점
루트 단계에서는 hourly_stats의 각 행을 동일한 소스 및 타겟 호스트 쌍의 agg_stats 행과 조인합니다. 각 소스 및 타겟 호스트 쌍에 대해 해당 호스트 쌍 버킷의 총 전송 바이트와 집계 통계를 사용하여 z-점수를 계산합니다.

stage hourly_stats {
 $source_host = principal.hostname
 $dst_host = target.hostname
 principal.hostname != ""
 target.hostname != ""
 match:
   $source_host, $dst_host by hour
 outcome:
   $total_bytes_sent = sum(network.sent_bytes)
}

stage agg_stats {
  $source_host = $hourly_stats.source_host
  $dst_host = $hourly_stats.dst_host
  match:
    $source_host, $dst_host
  outcome:
   $avg_bytes_sent = avg($hourly_stats.total_bytes_sent)
   $stddev_bytes_sent = stddev($hourly_stats.total_bytes_sent)
}

$source_host = $agg_stats.source_host
$source_host = $hourly_stats.source_host

$dst_host = $agg_stats.dst_host
$dst_host = $hourly_stats.dst_host

outcome:
  $hour_bucket = timestamp.get_timestamp($hourly_stats.window_start)
  $z_score = ($hourly_stats.total_bytes_sent - $agg_stats.avg_bytes_sent)/$agg_stats.stddev_bytes_sent

다단계 쿼리의 교차 조인

Google SecOps 검색 또는 대시보드를 사용할 때 다단계 쿼리의 크로스 조인을 사용하면 개별 UDM 이벤트 데이터를 다른 YARA-L 단계에서 계산된 집계 통계와 비교할 수 있습니다.

YARA-L에서 cross join 키워드는 행을 하나만 반환하는 단계와 함께 작동합니다.

제한이 1인 단계와 다른 데이터 세트 (예: UDM 이벤트) 간에 교차 조인이 사용되면 단계에서 출력된 단일 행이 다른 데이터 세트의 각 행에 추가됩니다. 이렇게 하면 전체 통계로 이벤트 데이터가 보강됩니다.

예: 비정상적인 로그인 활동 찾기

다음 예에서는 정상보다 더 자주 로그인하는 사용자를 식별합니다. 이 값은 각 사용자의 로그인 수 (user_login_counts 단계 사용)와 모든 사용자의 평균 로그인 수 (total_users 단계 사용)를 비교하여 계산됩니다. 비정상적으로 많은 횟수로 로그인하는 사용자는 검색 결과에서 정렬될 수 있습니다.

그런 다음 교차 조인 키워드를 사용하여 total_users 단계의 결과를 user_login_counts 단계의 결과에 연결합니다.

stage user_login_counts {
    $user = principal.user.userid
    metadata.event_type = "USER_LOGIN"
    security_result.action = "ALLOW"

    match:
        $user

    outcome:
        $login_count = count(metadata.id)
}

stage total_users {
    outcome:
        $count = count($user_login_counts.user)
    limit:
        1
}

cross join $total_users, $user_login_counts

$login_count = $user_login_counts.login_count
$user = $user_login_counts.user
$tot_users = $total_users.count

// all users who logged in the same number of times are grouped together.
match:
    $login_count
outcome:
    $num_users = count($user)
    $frequency_percent = (count($user) / max($tot_users) ) * 100

제한사항

다단계 쿼리에는 다음과 같은 기능 및 구조적 제약 조건이 있습니다.

구조적 요구사항

쿼리를 빌드할 때는 다음 구조적 요구사항을 따라야 합니다.

루트 단계: 쿼리당 하나의 루트 단계만 허용됩니다.
이름이 지정된 단계: 최대 4개의 이름이 지정된 단계가 지원됩니다.
참조 단계: 단계는 동일한 쿼리에서 논리적으로 앞에 정의된 단계만 참조할 수 있습니다.
교차 조인: 교차 조인은 단일 행을 반환하는 단계만 참조할 수 있습니다. 이 요구사항을 충족하려면 참조된 단계에 한도 (1)를 포함해야 합니다. 이를 통해 비교를 위해 모든 개별 이벤트 행에 최대값 또는 평균과 같은 단일 전역 통계를 추가할 수 있으므로 유용합니다.
조인: 모든 단계에서 데이터 테이블이 아닌 조인은 최대 4개까지 허용됩니다.
결과 요구사항: 이름이 지정된 각 단계 (루트 단계 제외)에는 match 섹션 또는 outcome 섹션이 포함되어야 합니다. outcome 섹션에는 집계가 필요하지 않습니다.

창 및 호환성 제한

창을 사용하는 방법과 쿼리를 실행하는 위치에는 다음 제한사항이 적용됩니다.

기능 지원: 다단계 쿼리는 검색 및 대시보드에서 작동하지만 규칙에서는 지원되지 않습니다.
기간 유형: 단일 쿼리 내에서 다양한 기간 유형을 혼합하지 마세요.
창 종속 항목: 홉 또는 슬라이딩 창을 사용하는 스테이지는 홉 또는 슬라이딩 창을 사용하는 다른 스테이지에 종속될 수 없습니다.
텀블링 윈도우 크기: 여러 단계에서 텀블링 윈도우의 크기는 다를 수 있지만 크기 차이는 720x 미만이어야 합니다.

예: 스테이지 집계 차이 (잘못됨)

다음 구성은 한 달에 44,640분이 포함되어 있으므로 잘못되었습니다 (44,640 / 1 > 720).

스테이지: monthly_stats { ... match: by month }

루트: match: by minute

예: 스테이지 집계 차이 (유효)

이 문제를 해결하려면 단계 간 비율을 더 작게 설정하세요. 예를 들어 시간별 데이터를 일일 보고서로 집계합니다.

스테이지: daily_stats { ... match: by day }

루트: match: by hour

24 (하루의 시간)는 720보다 작으므로 시스템은 스테이지 데이터를 루트 스테이지에 효율적으로 매핑할 수 있습니다.

단계 및 쿼리 제한사항

다단계 쿼리 내의 각 개별 단계에는 특정 제약 조건이 있습니다. 단일 단계 쿼리에 적용되는 대부분의 제한사항은 각 개별 단계에도 적용됩니다.

출력 요구사항: 모든 단계는 하나 이상의 일치 또는 결과 변수 (단계 필드)를 출력해야 합니다.
쿼리 기간:
- 표준 쿼리: 최대 30일입니다.
- 일치하지 않는 조인이 있는 다단계 쿼리: 최대 14일로 제한됩니다.
창 크기 제한: 최대 창 크기 (홉, 슬라이딩 또는 텀블링)는 쿼리에 조인이 포함되어 있는지에 따라 달라집니다.
- 조인 사용: 모든 유형 (홉, 슬라이딩, 텀블링)의 최대 기간은 2일입니다. 자세한 내용은 검색 조인 제한사항을 참고하세요.
- 조인 없음 (단일 이벤트):
- 홉 및 슬라이딩 윈도우: 최대 2일
- 롤링 기간: 최대 30일로 증가
최대 결과 변수:
- 기본값은 20입니다.
- 더 큰 한도를 선택한 고객의 경우 50
- 배열 한도: 배열 값 결과 변수에는 최대 10,000개의 요소가 허용됩니다.
쿼리당 이벤트 제약 조건:
- 최대 2개의 UDM 이벤트
- 최대 1개의 심전도 이벤트
- 데이터 테이블 최대 2개

서비스 및 성능 한도

다단계 쿼리에는 통계 쿼리와 동일한 제한사항이 적용됩니다.

통계 쿼리: 120QPH (API 및 UI)
검색 조회수: 분당 100회 조회
API 지원: Google SecOps 시스템과 EventService.UDMSearch API는 다단계 조인을 지원하지만 SearchService.UDMSearch API는 지원하지 않습니다. 또한 시스템을 사용하면 조인 없이 다단계 쿼리를 실행할 수 있습니다.

이벤트 및 전역 제한사항

다음 이벤트 및 플랫폼 전체 경계 내에 있어야 합니다.

최대 이벤트 수

다단계 쿼리는 동시에 처리할 수 있는 이벤트 수를 엄격하게 제한합니다.

UDM 이벤트: UDM 이벤트는 최대 2개까지 허용됩니다.
엔티티 컨텍스트 그래프 (ECG) 이벤트: ECG 이벤트는 최대 1개까지 허용됩니다.

전역 쿼리 제한사항

이러한 플랫폼 전체 제약 조건은 다단계 쿼리에서 반환되는 데이터의 기간과 양을 제어합니다.

쿼리 기간: 표준 쿼리의 최대 기간은 30일입니다.
전체 결과 집합: 최대 전체 결과 집합 크기는 10,000개입니다.

도움이 더 필요하신가요? 커뮤니티 회원 및 Google SecOps 전문가에게 문의하여 답변을 받으세요.