이 페이지는 Cloud Translation API를 통해 번역되었습니다.

파서 확장 프로그램

다음에서 지원:

Google SecOps SIEM

이 문서에서는 파서 확장 프로그램을 만들어 원시 로그 데이터에서 필드를 추출하고 Google Security Operations 플랫폼 내의 대상 UDM (통합 데이터 모델) 필드에 매핑하는 방법을 설명합니다.

이 문서에서는 파서 확장 프로그램 생성 프로세스를 간략하게 설명합니다.

파서 확장 프로그램 만들기
기본 요건 및 제한사항
원시 로그 데이터에서 소스 필드를 식별합니다.
적절한 대상 UDM 필드를 선택합니다.
적절한 파서 확장 프로그램 정의 접근 방식 선택:

파서 확장 프로그램을 정의하는 작업에는 원시 로그 데이터를 필터링하고, 데이터를 변환하고, 대상 UDM 필드에 매핑하는 파싱 로직을 설계하는 작업이 포함됩니다. Google SecOps는 파서 확장 프로그램을 만드는 두 가지 방법을 제공합니다.
- 노 코드 (데이터 필드 매핑) 접근 방식을 사용하여 파서 확장 프로그램을 만듭니다.
- 코드 스니펫 접근 방식을 사용하여 파서 확장 프로그램을 만듭니다.
다양한 로그 형식과 시나리오에 대한 설명용 파서 확장 프로그램 생성 예 예를 들어 JSON을 사용하는 노코드 예시와 복잡한 로직 또는 비 JSON 형식 (CSV, XML, Syslog)을 위한 코드 스니펫이 있습니다.

파서 확장 프로그램 만들기

파서 확장 프로그램은 기존 기본 파서 (및 맞춤 파서)의 기능을 확장하는 유연한 방법을 제공합니다. 파서 확장 프로그램을 사용하면 기존 기본 파서 (또는 맞춤 파서)를 대체하지 않고도 기능을 유연하게 확장할 수 있습니다. 확장 프로그램을 사용하면 새 파싱 로직을 추가하고, 필드를 추출 및 변환하고, UDM 필드 매핑을 업데이트하거나 삭제하여 파서 파이프라인을 맞춤설정할 수 있습니다.

파서 확장 프로그램은 맞춤 파서와 다릅니다. 기본 파서가 없는 로그 유형에 대해 또는 파서 업데이트를 선택 해제하기 위해 맞춤 파서를 만들 수 있습니다.

파서 추출 및 정규화 프로세스

Google SecOps는 원본 로그 데이터를 원시 로그로 수신합니다. 기본 파서(및 맞춤 파서)는 핵심 로그 필드를 추출하여 UDM 레코드의 구조화된 UDM 필드로 정규화합니다. 이는 원본 원시 로그 데이터의 일부만 나타냅니다. 기본 파서에서 처리하지 않는 로그 값을 추출하도록 파서 확장 프로그램을 정의할 수 있습니다. 활성화되면 파서 확장 프로그램이 Google SecOps 데이터 추출 및 정규화 프로세스의 일부가 됩니다.

수집 및 정규화 워크플로

새 파서 확장 프로그램 정의

기본 파서에는 핵심 보안 값을 추출, 변환, 정규화하는 방법을 지정하는 사전 정의된 매핑 명령어 세트가 포함되어 있습니다. 노 코드 (데이터 필드 매핑) 방식 또는 코드 스니펫 방식을 사용하여 매핑 명령어를 정의하여 새 파서 확장 프로그램을 만들 수 있습니다.

노코드 접근 방식

로우 코드 방식은 네이티브 JSON, XML 또는 CSV 형식의 원시 로그에서 간단하게 추출하는 데 가장 적합합니다. 원시 로그 소스 필드를 지정하고 해당 대상 UDM 필드를 매핑할 수 있습니다.

예를 들어 간단한 동등성 비교를 사용하여 최대 10개의 필드가 있는 JSON 로그 데이터를 추출할 수 있습니다.
코드 스니펫 접근 방식

코드 스니펫 접근 방식을 사용하면 원시 로그에서 값을 추출 및 변환하고 UDM 필드에 할당하는 명령어를 정의할 수 있습니다. 코드 스니펫은 기본 (또는 맞춤) 파서와 동일한 Logstash와 유사한 문법을 사용합니다.

이 방법은 지원되는 모든 로그 형식에 적용됩니다. 다음과 같은 시나리오에 가장 적합합니다.
- 복잡한 데이터 추출 또는 복잡한 로직
- Grok 기반 파서가 필요한 비정형 데이터
- CSV, XML과 같은 JSON이 아닌 형식
코드 스니펫은 함수를 사용하여 원시 로그 데이터에서 특정 데이터를 추출합니다. 예를 들어 Grok, JSON, KV, XML이 있습니다.

대부분의 경우 기본 파서 (또는 맞춤 파서)에서 사용된 데이터 매핑 접근 방식을 사용하는 것이 가장 좋습니다.

새로 추출된 값을 UDM 필드에 병합

활성화되면 파서 확장 프로그램은 사전 정의된 병합 원칙에 따라 새로 추출된 값을 해당 UDM 레코드의 지정된 UDM 필드에 병합합니다. 예를 들면 다음과 같습니다.

기존 값 덮어쓰기: 추출된 값이 대상 UDM 필드의 기존 값을 덮어씁니다.

유일한 예외는 반복 필드로, UDM 레코드의 반복 필드에 데이터를 쓸 때 새 값을 추가하도록 파서 확장 프로그램을 구성할 수 있습니다.
파서 확장 프로그램이 우선 적용됨: 파서 확장 프로그램의 데이터 매핑 명령어가 해당 로그 유형의 기본 (또는 맞춤) 파서의 명령어보다 우선 적용됩니다. 매핑 명령어에 충돌이 있으면 파서 확장 프로그램이 기본값으로 설정된 값을 덮어씁니다.

예를 들어 기본 파서가 원시 로그 필드를 event.metadata.description UDM 필드에 매핑하고 파서 확장 프로그램이 다른 원시 로그 필드를 동일한 UDM 필드에 매핑하면 파서 확장 프로그램이 기본 파서에서 설정한 값을 덮어씁니다.

제한사항

로그 유형당 하나의 파서 확장 프로그램: 로그 유형당 하나의 파서 확장 프로그램만 만들 수 있습니다.
하나의 데이터 매핑 명령어 접근 방식만 사용: 코드 없음 또는 코드 스니펫 접근 방식 중 하나를 사용하여 파서 확장 프로그램을 빌드할 수 있지만 두 접근 방식을 함께 사용할 수는 없습니다.
검증을 위한 로그 샘플: UDM 파서 확장 프로그램을 검증하려면 지난 30일의 로그 샘플이 필요합니다. 자세한 내용은 로그 유형에 활성 파서가 있는지 확인을 참고하세요.
기본 파서 오류: 기본 파서 오류는 파서 확장 프로그램 내에서 식별하거나 수정할 수 없습니다.
코드 스니펫의 반복 필드: 의도치 않은 데이터 손실을 방지하려면 코드 스니펫에서 전체 반복 객체를 바꿀 때 주의하세요. 자세한 내용은 반복되는 입력란 선택기에 대한 자세한 정보를 참고하세요.
명확한 이벤트: 파서 확장 프로그램은 단일 레코드에 고유한 이벤트가 여러 개 있는 로그(예: Google Drive 배열)를 처리할 수 없습니다.
XML 및 노코드: XML에는 노코드 모드가 지원되지 않습니다. 대신 코드 스니펫 메서드를 사용하세요.
소급 데이터 없음: 원시 로그 데이터를 소급하여 파싱할 수 없습니다.
무코드 접근 방식의 예약어: 로그에 다음 예약어 중 하나가 포함된 경우 무코드 접근 방식 대신 코드 스니펫 접근 방식을 사용합니다.
- collectionTimestamp
- createTimestamp
- enableCbnForLoop
- event
- filename
- message
- namespace
- output
- onErrorCount
- timestamp
- timezone
기존 매핑 삭제: 코드 스니펫 접근 방식만 사용하여 기존 UDM 필드 매핑을 삭제할 수 있습니다.
반복 IP 필드의 매핑 삭제: 반복 IP 필드의 UDM 필드 매핑은 삭제할 수 없습니다.

파서 개념

다음 문서에서는 중요한 파서 개념을 설명합니다.

기본 요건

파서 확장 프로그램 생성의 기본 요건:

로그 유형에 활성 상태인 기본 파서 또는 맞춤 파서가 있어야 합니다.
Google SecOps는 기본 (또는 맞춤) 파서를 사용하여 원시 로그를 수집하고 정규화할 수 있어야 합니다.
타겟 로그 유형의 활성 기본 파서 (또는 맞춤 파서)가 지난 30일 이내에 원시 로그 데이터를 수집했는지 확인합니다. 이 데이터에는 추출하거나 로그 레코드를 필터링하는 데 사용할 필드의 샘플이 포함되어야 합니다. 이 파일은 새 데이터 매핑 명령어를 검증하는 데 사용됩니다.

시작하기

파서 확장 프로그램을 만들기 전에 다음을 수행하세요.

기본 요건 확인:

로그 유형에 활성 파서가 있는지 확인합니다. 아직 파서가 없으면 맞춤 파서를 만듭니다.
원시 로그에서 추출할 필드 식별:

원시 로그에서 추출할 필드를 식별합니다.
적절한 UDM 필드 선택:

추출된 원시 로그 필드를 매핑할 적절한 해당 UDM 필드를 선택합니다.
파서 확장 프로그램 정의 접근 방식 선택:

두 확장 프로그램 접근 방식 (데이터 매핑 접근 방식) 중 하나를 선택하여 파서 확장 프로그램을 만듭니다.

기본 요건 확인

다음 섹션에 설명된 대로 확장하려는 로그 유형에 활성 파서가 있는지 확인합니다.

로그 유형에 활성 파서가 있는지 확인

확장하려는 로그 유형에 활성 기본 파서 (또는 맞춤 파서)가 있는지 확인합니다.

다음 목록에서 로그 유형을 검색합니다.

기본 파서가 있는 지원되는 로그 유형
- 로그 유형에 기본 파서가 있는 경우 파서가 활성 상태인지 확인합니다.
- 로그 유형에 기본 파서가 없는 경우 로그 유형에 맞게 맞춤 파서를 사용해야 합니다.
기본 파서가 없는 지원되는 로그 유형
- 로그 유형에 기본 파서가 없는 경우 로그 유형에 맞게 맞춤 파서를 사용해야 합니다.

로그 유형에 대한 맞춤 파서가 있는지 확인

로그 유형에 대한 커스텀 파서가 있는지 확인하려면 다음 단계를 따르세요.

탐색 메뉴에서 SIEM 설정 > 파서를 선택합니다.
파서 표에서 확장하려는 로그 유형을 검색합니다.
- 해당 로그 유형에 아직 기본 또는 맞춤 파서가 없는 경우 파서 만들기를 클릭하고 매핑 명령어 기반의 맞춤 파서 만들기의 단계를 따릅니다.
- 해당 로그 유형에 맞춤 파서가 이미 있는 경우 파서가 활성 상태인지 확인합니다.

로그 유형에 파서가 활성 상태인지 확인

파서가 로그 유형에 대해 활성 상태인지 확인하려면 다음 단계를 따르세요.

탐색 메뉴에서 SIEM 설정 > 파서를 선택합니다.
파서 표에서 확장하려는 로그 유형을 검색합니다.

로그 유형의 파서가 활성화되지 않은 경우 활성화합니다.
- 기본 파서는 사전 빌드된 파서 업데이트 관리를 참고하세요.
- 커스텀 파서의 경우 커스텀 파서 업데이트 관리를 참고하세요.

원시 로그에서 추출할 필드를 식별합니다.

데이터를 추출할 원시 로그를 분석하여 기본 파서 (또는 맞춤 파서)로 추출되지 않은 필드를 식별합니다. 기본 파서 (또는 맞춤 파서)가 원시 로그 필드를 추출하고 해당 UDM 필드에 매핑하는 방법을 확인하세요.

원시 로그에서 추출할 특정 필드를 식별하려면 검색 도구를 사용하여 필드를 식별하면 됩니다.

검색 도구에 액세스하려면 조사 > SIEM 검색으로 이동합니다. 검색어 앞에 raw=를 입력합니다. 자세한 내용은 원시 로그 검색 실행하기를 참고하세요.
기존 검색 도구에 액세스하려면 SIEM 검색 페이지 상단에서 기존 검색으로 이동을 클릭합니다. 자세한 내용은 원시 로그 스캔을 사용하여 원시 로그 검색하기를 참고하세요.

원시 로그 검색에 대한 자세한 내용은 다음을 참고하세요.

적절한 UDM 필드 선택

이제 추출할 특정 타겟 필드를 식별했으므로 해당 필드를 상응하는 대상 UDM 필드에 매칭할 수 있습니다. 원시 로그 소스 필드와 대상 UDM 필드 간의 명확한 매핑을 설정합니다. 표준 데이터 유형 또는 반복 필드를 지원하는 UDM 필드에 데이터를 매핑할 수 있습니다.

올바른 UDM 필드 선택

다음 리소스를 사용하면 프로세스를 간소화할 수 있습니다.

주요 UDM 개념 숙지하기
기존 파서에서 사용되는 데이터 매핑 이해하기
UDM 조회 도구를 사용하여 소스 필드와 일치하는 잠재적 UDM 필드를 찾습니다.
파서 데이터 매핑을 위한 중요한 UDM 필드 가이드에는 UDM 스키마에서 가장 자주 사용되는 필드의 요약과 설명이 포함되어 있습니다.
통합 데이터 모델 필드 목록에는 모든 UDM 필드와 설명이 포함되어 있습니다. 반복 필드는 목록에서 'repeated' 라벨로 식별됩니다.
오류를 방지하기 위한 중요한 UDM 고려사항

주요 UDM 개념 숙지

논리적 객체: 이벤트 및 항목

UDM 스키마는 데이터를 저장하는 모든 사용 가능한 속성을 설명합니다. 각 UDM 레코드는 이벤트 또는 항목을 설명합니다. 데이터는 레코드가 이벤트 또는 항목을 설명하는지 여부에 따라 서로 다른 필드에 저장됩니다.
- UDM 이벤트 객체는 환경에서 발생한 작업에 관한 데이터를 저장합니다. 원래 이벤트 로그는 방화벽 또는 웹 프록시와 같이 기기에 기록된 대로 작업을 설명합니다.
- UDM 항목 객체는 환경의 애셋, 사용자, 리소스와 같이 UDM 이벤트에 관련된 참여자 또는 항목에 관한 데이터를 저장합니다.
UDM 이벤트 구조
UDM 항목 구조

UDM 명사: 명사는 UDM 이벤트의 참여자 또는 항목을 나타냅니다. 예를 들어 명사는 이벤트에 기술된 작업을 수행하는 기기 또는 사용자일 수 있습니다. 명사는 이벤트에 기술된 활동의 타겟이 되는 기기 또는 사용자일 수도 있습니다.

UDM 명사	설명
`principal`	이벤트에 설명된 작업을 시작한 항목입니다.
`target`	행위의 수신자 또는 객체인 항목입니다. 방화벽 연결에서 연결을 수신하는 머신이 타겟이 됩니다.
`src`	주 구성원이 조치를 취한 소스 항목입니다. 예를 들어 사용자가 한 머신에서 다른 머신으로 파일을 복사하면 파일과 파일이 시작된 머신이 src로 표시됩니다.
`intermediary`	프록시 서버와 같이 이벤트에서 중개자 역할을 하는 모든 항목입니다. 요청을 차단하거나 변경하는 등의 작업에 영향을 줄 수 있습니다.
`observer`	이벤트를 모니터링하고 보고하지만 트래픽과 직접 상호작용하지 않는 항목입니다. 네트워크 침입 감지 시스템 또는 보안 정보 및 이벤트 관리 시스템이 그 예입니다.
`about`	이전 카테고리에 해당하지 않는 이벤트에 관련된 기타 항목입니다. 예를 들어 이메일 첨부파일이나 프로세스 실행 중에 로드된 DLL입니다.

실제로 주체 및 타겟 명사 객체가 가장 자주 사용됩니다. 위의 설명은 명사의 권장 사용법을 나타냅니다. 실제 사용량은 기본 또는 맞춤 기본 파서의 구현에 따라 다를 수 있습니다.

기존 파서에서 사용되는 데이터 매핑 이해

원시 로그 소스 필드와 대상 UDM 필드 간에 기본 파서 (또는 맞춤 파서)에서 사용하는 기존 데이터 매핑을 이해하는 것이 좋습니다.

기존 기본 파서 (또는 맞춤 파서)에 사용되는 원시 로그 소스 필드와 대상 UDM 필드 간의 데이터 매핑을 보려면 다음 단계를 따르세요.

탐색 메뉴에서 SIEM 설정 > 파서를 선택합니다.
파서 표에서 확장하려는 로그 유형을 검색합니다.
해당 행으로 이동한 다음 메뉴 > 보기를 클릭합니다.

파서 코드 탭에는 기존 기본 파서 (또는 맞춤 파서)에 사용되는 원시 로그 소스 필드와 대상 UDM 필드 간의 데이터 매핑이 표시됩니다.

UDM 조회 도구 사용

UDM 조회 도구를 사용하여 원시 로그 소스 필드와 일치하는 UDM 필드를 식별합니다.

Google SecOps는 대상 UDM 필드를 빠르게 찾는 데 도움이 되는 UDM 조회 도구를 제공합니다. UDM 조회 도구에 액세스하려면 조사 > SIEM 검색으로 이동합니다.

UDM 조회 도구 사용 방법에 대한 자세한 내용은 다음 주제를 참고하세요.

UDM 조회 도구 예시

예를 들어 원시 로그에 'packets'라는 소스 필드가 있는 경우 UDM 조회 도구를 사용하여 이름에 'packets'가 있는 잠재적 대상 UDM 필드를 찾습니다.

조사 > SIEM 검색으로 이동합니다.
SIEM 검색 페이지의 UDM 필드를 값으로 조회 필드에 'packets'를 입력한 후 UDM 조회를 클릭합니다.

UDM 조회 대화상자가 열립니다. 검색 도구는 필드 이름 또는 필드 값을 기준으로 UDM 필드를 일치시킵니다.
- 필드 이름으로 조회 - 입력한 텍스트 문자열을 해당 텍스트가 포함된 필드 이름과 일치시킵니다.
- 필드 값으로 조회 - 입력한 값을 저장된 로그 데이터에 해당 값이 포함된 필드와 일치시킵니다.
UDM 조회 대화상자에서 UDM 필드를 선택합니다.

검색 기능은 UDM 필드 이름에 'packets'라는 텍스트가 포함된 잠재적 UDM 필드 목록을 표시합니다.
각 행을 하나씩 클릭하여 각 UDM 필드의 설명을 확인합니다.

오류를 방지하기 위한 중요한 UDM 고려사항

유사한 필드: UDM의 계층 구조로 인해 이름이 유사한 필드가 있을 수 있습니다. 안내는 기본 파서를 참고하세요. 자세한 내용은 기존 파서에서 사용되는 데이터 매핑 이해하기를 참고하세요.
임의 필드 매핑: UDM 필드에 직접 매핑되지 않는 데이터에는 additional 객체를 사용합니다. 자세한 내용은 UDM으로의 임의 필드 매핑을 참고하세요.
반복 필드: 코드 스니펫에서 반복 필드를 사용할 때는 주의해야 합니다. 전체 객체를 바꾸면 원래 데이터가 덮어쓰여질 수 있습니다. 노코드 방식을 사용하면 반복 필드를 더 세부적으로 제어할 수 있습니다. 자세한 내용은 반복되는 입력란 선택기에 대한 자세한 정보를 참고하세요.
UDM 이벤트 유형의 필수 UDM 필드: UDM metadata.event_type 필드를 UDM 레코드에 할당할 때 각 event_type에는 UDM 레코드에 있어야 하는 서로 다른 관련 필드 집합이 필요합니다. 자세한 내용은 UDM metadata.event_type 필드 할당에 관한 자세한 정보를 참고하세요.
기본 파서 문제: 파서 확장 프로그램은 기본 파서의 오류를 수정할 수 없습니다. 기본 파서는 UDM 레코드를 만든 기본 파서 또는 맞춤 파서입니다. 파서 확장 프로그램 개선, 기본 파서 수정, 로그 사전 필터링과 같은 옵션을 고려하세요.

UDM으로의 임의 필드 매핑

데이터를 저장할 적합한 표준 UDM 필드를 찾을 수 없는 경우 additional 객체를 사용하여 데이터를 맞춤 키-값 쌍으로 저장합니다. 이렇게 하면 일치하는 UDM 필드가 없더라도 UDM 레코드에 유용한 정보를 저장할 수 있습니다.

파서 확장 프로그램 정의 접근 방식 선택

파서 확장 프로그램 정의 접근 방식을 선택하기 전에 다음 섹션을 살펴봐야 합니다.

파서 확장 프로그램 만들기
시작하기

다음 단계는 파서 확장 프로그램 페이지를 열고 파서 확장 프로그램을 정의하는 데 사용할 확장 프로그램 접근 방식을 선택하는 것입니다.

파서 확장 프로그램 페이지 열기

파서 확장 프로그램 페이지에서 새 파서 확장 프로그램을 정의할 수 있습니다.

설정 메뉴, 원시 로그 검색 또는 기존 원시 로그 검색에서 다음과 같은 방법으로 파서 확장 프로그램 페이지를 열 수 있습니다.

설정 메뉴에서 열기

설정 메뉴에서 파서 확장 프로그램 페이지를 여는 방법은 다음과 같습니다.

탐색 메뉴에서 SIEM 설정 > 파서를 선택합니다.

파서 표에는 로그 유형별 기본 파서 목록이 표시됩니다.
확장하려는 로그 유형을 찾아 메뉴 > 확장 프로그램 만들기를 클릭합니다.

파서 확장 프로그램 페이지가 열립니다.

원시 로그 검색에서 열기

원시 로그 검색에서 파서 확장 프로그램 페이지를 열려면 다음 단계를 따르세요.

조사 > SIEM 검색으로 이동합니다.
검색창에서 검색 인수에 raw = 접두사를 추가하고 검색어를 인용부호로 묶습니다. 예를 들면 raw = "example.com"입니다.
검색 실행을 클릭합니다. 결과가 원시 로그 패널에 표시됩니다.
원시 로그 패널에서 로그 (행)를 클릭합니다. 이벤트 보기 패널이 표시됩니다.
이벤트 보기 패널에서 원시 로그 탭을 클릭합니다. 원시 로그가 표시됩니다.
파서 관리 > 확장 프로그램 만들기 > 다음을 클릭합니다.

파서 확장 프로그램 페이지가 열립니다.

기존 원시 로그 검색에서 열기

기존 원시 로그 검색에서 파서 확장 프로그램 페이지를 열려면 다음 단계를 따르세요.

기존 원시 로그 검색을 사용하여 파싱될 레코드와 유사한 레코드를 검색합니다.
이벤트 > 타임라인 패널에서 이벤트를 선택합니다.
이벤트 데이터 패널을 펼칩니다.
파서 관리 > 확장 프로그램 만들기 > 다음을 클릭합니다.

파서 확장 프로그램 페이지가 열립니다.

파서 확장 프로그램 페이지

페이지에 원시 로그 및 확장 프로그램 정의 패널이 표시됩니다.

원시 로그 패널:

그러면 선택한 로그 유형의 샘플 원시 로그 데이터가 표시됩니다. 원시 로그 검색에서 페이지를 연 경우 샘플 데이터는 검색 결과입니다. 다음으로 보기 메뉴(RAW, JSON, CSV, XML 등)와 텍스트 줄바꿈 체크박스를 사용하여 샘플의 형식을 지정할 수 있습니다.
1. 표시된 원시 로그 데이터 샘플이 파서 확장 프로그램에서 처리할 로그를 나타내는지 확인합니다.
2. UDM 출력 미리보기를 클릭하여 샘플 원시 로그 데이터의 UDM 출력을 확인합니다.
확장 프로그램 정의 패널:

이를 통해 데이터 필드 매핑 (코드 없음) 또는 코드 스니펫 작성이라는 두 가지 매핑 명령어 접근 방식 중 하나를 사용하여 파서 확장 프로그램을 정의할 수 있습니다. 동일한 파서 확장 프로그램에서 두 접근 방식을 모두 사용할 수는 없습니다.

선택한 접근 방식에 따라 수신되는 원시 로그에서 추출할 소스 로그 데이터 필드를 지정하고 해당 UDM 필드에 매핑하거나 이러한 작업을 수행하는 코드 스니펫을 작성할 수 있습니다.

확장 프로그램 접근 방식 선택

파서 확장 프로그램 페이지의 확장 프로그램 정의 패널에 있는 확장 프로그램 메서드 필드에서 다음 방법 중 하나를 선택하여 파서 확장 프로그램을 만듭니다.

데이터 필드 매핑 (코드 없음) 접근 방식:

이 방법을 사용하면 원시 로그의 필드를 지정하고 대상 UDM 필드에 매핑할 수 있습니다.

이 방법은 다음 원시 로그 형식에서 작동합니다.
- 네이티브 JSON, 네이티브 XML 또는 CSV
- Syslog 헤더와 네이티브 JSON, 네이티브 XML 또는 CSV JSON, XML, CSV, SYSLOG + JSON, SYSLOG + XML, SYSLOG + CSV 형식의 원시 로그에 대한 데이터 필드 유형 매핑 안내를 만들 수 있습니다.
다음 단계인 코드 없는 (지도 데이터 필드) 명령어 만들기를 참고하세요.
코드 스니펫 작성 접근 방식:

이 방법을 사용하면 Logstash와 비슷한 문법을 사용하여 원시 로그에서 값을 추출 및 변환하고 UDM 레코드의 UDM 필드에 할당하는 명령어를 지정할 수 있습니다.
- 코드 스니펫은 기본 (또는 맞춤) 파서와 동일한 문법과 섹션을 사용합니다. 자세한 내용은 파서 문법을 참고하세요.
- 이 접근 방식은 해당 로그 유형에 지원되는 모든 데이터 형식에서 작동합니다.
다음 단계인 코드 스니펫 명령어 만들기를 참고하세요.

노 코드 (지도 데이터 필드) 명령어 만들기

코드 없는 방식 (데이터 필드 매핑 메서드라고도 함)을 사용하면 원시 로그 필드의 경로를 지정하고 해당 대상 UDM 필드에 매핑할 수 있습니다.

노코드 접근 방식을 사용하여 파서 확장 프로그램을 만들기 전에 다음 섹션을 살펴봐야 합니다.

파서 확장 프로그램 만들기
시작하기
확장 프로그램 접근 방식 선택에서 데이터 필드 매핑 옵션을 선택합니다.

파서 확장 프로그램을 정의하는 다음 단계는 다음과 같습니다.

반복 필드 선택기 설정
각 필드의 데이터 매핑 명령어 정의
파서 확장 프로그램 제출 및 활성화

반복 필드 선택기 설정

확장 프로그램 정의 패널의 반복 필드 필드에서 파서 확장 프로그램이 값을 반복 필드 (예: principal.ip 값 배열을 지원하는 필드)에 저장하는 방법을 설정합니다.

값 추가: 새로 추출된 값이 UDM 배열 필드에 저장된 기존 값 집합에 추가됩니다.
값 바꾸기: 새로 추출된 값이 기본 파서에 의해 이전에 저장된 UDM 배열 필드의 기존 값 집합을 바꿉니다.

반복 필드 선택기의 설정은 반복되지 않는 필드에 영향을 주지 않습니다.

자세한 내용은 반복되는 입력란 선택기에 대한 자세한 정보를 참고하세요.

각 필드의 데이터 매핑 명령어 정의

원시 로그에서 추출할 각 필드의 데이터 매핑 안내를 정의합니다. 명령어는 원시 로그의 원본 필드 경로를 지정하고 대상 UDM 필드에 매핑해야 합니다.

원시 로그 패널에 표시된 원시 로그 샘플에 Syslog 헤더가 포함되어 있으면 Syslog 및 대상 필드가 표시됩니다. (일부 로그 형식에는 Syslog 헤더가 포함되지 않습니다(예: 네이티브 JSON, 네이티브 XML 또는 CSV).)

Google SecOps는 Syslog 헤더를 사전 처리하고 로그의 구조화된 부분을 추출하기 위해 Syslog 및 대상 필드가 필요합니다.
1. 다음 필드를 정의합니다.
  - Syslog: 원시 로그의 구조화된 부분에서 Syslog 헤더를 전처리하고 분리하는 사용자 정의 패턴입니다.
    
    Grok 및 정규 표현식을 사용하여 Syslog 헤더와 원시 로그 메시지를 식별하는 추출 패턴을 지정합니다. 자세한 내용은 Syslog 추출기 필드 정의하기를 참고하세요.
  - 타겟: 로그의 구조화된 부분을 저장하는 Syslog 필드의 변수 이름입니다.
    
    로그의 구조화된 부분을 저장하는 추출 패턴에 변수 이름을 지정합니다.
  다음은 각각 Syslog 및 Target 필드의 추출 패턴과 변수 이름의 예입니다.
2. Syslog 및 대상 필드에 값을 입력한 후 검증 버튼을 클릭합니다.
  
  검증 프로세스는 문법 및 파싱 오류를 모두 확인한 후 다음 중 하나를 반환합니다.
  - 성공: 데이터 매핑 필드가 표시됩니다. 파서 확장 프로그램의 나머지 부분을 정의합니다.
  - 실패: 오류 메시지가 표시됩니다. 계속하기 전에 오류 조건을 수정하세요.
원하는 경우 전제조건 명령어를 정의합니다.

전제조건 명령어는 정적 값을 원시 로그의 필드와 일치시켜 파서 확장 프로그램이 처리하는 원시 로그의 하위 집합을 식별합니다. 수신 원시 로그가 전제조건 기준에 부합하면 파서 확장 프로그램이 매핑 명령어를 적용합니다. 값이 일치하지 않으면 파서 확장 프로그램이 매핑 명령어를 적용하지 않습니다.

다음 입력란을 작성하세요.
- 전제조건 필드: 비교할 값이 포함된 원시 로그의 필드 식별자입니다. 로그 데이터 형식이 JSON 또는 XML인 경우 필드의 전체 경로를 입력하고 데이터 형식이 CSV인 경우 열 위치를 입력합니다.
- 전제조건 연산자: EQUALS 또는 NOT EQUALS를 선택합니다.
- 전제조건 값: 원시 로그의 전제조건 필드와 비교할 정적 값입니다.
사전 조건 명령의 또 다른 예는 No-code - 사전 조건 값으로 필드 추출을 참고하세요.
원시 로그 데이터 필드를 대상 UDM 필드에 매핑합니다.
- 원시 데이터 필드: 로그 데이터 형식이 JSON (예: jsonPayload.connection.dest_ip) 또는 XML (예: /Event/Reason-Code)인 경우 필드의 전체 경로를 입력하고 데이터 형식이 CSV인 경우 열 위치를 입력합니다 (참고: 색인 위치는 1부터 시작).
- 대상 필드: 값이 저장될 정규화된 UDM 필드 이름을 입력합니다(예: udm.metadata.collected_timestamp.seconds).
중요: 원시 로그가 JSON 형식인 경우 로그 값의 데이터 유형이 해당 대상 UDM 필드의 데이터 유형과 일치해야 합니다. 예를 들어 로그가 문자열("packets_sent":"16")로 packets sent를 기록하고 사용자가 uint64 데이터 유형이 있는 network.sent_bytes UDM 필드에 이를 매핑하려고 하면 명령어가 실패합니다. 이 요구사항은 CSV 및 XML 형식의 로그에는 적용되지 않습니다.
필드를 계속 추가하려면 추가를 클릭하고 다음 필드의 모든 매핑 안내 세부정보를 입력합니다.

필드 매핑의 또 다른 예는 코드 없음 - 필드 추출을 참고하세요.

파서 확장 프로그램 제출 및 활성화

원시 로그에서 추출할 모든 필드의 데이터 매핑 명령어를 정의한 후 파서 확장 프로그램을 제출하고 활성화합니다.

제출을 클릭하여 매핑 명령어를 저장하고 검증합니다.

Google SecOps에서 매핑 명령어를 검증합니다.

검증 프로세스가 성공하면 상태가 라이브로 변경되고 매핑 명령어가 수신되는 로그 데이터를 처리하기 시작합니다.

검증 프로세스가 실패하면 상태가 실패로 변경되고 원시 로그 필드에 오류가 표시됩니다.

다음은 검증 오류의 예입니다.

  ERROR: generic::unknown: pipeline.ParseLogEntry failed: LOG_PARSING_CBN_ERROR:
  "generic::invalid_argument: pipeline failed: filter mutate (7) failed: copy failure:
  copy source field \"jsonPayload.dest_instance.region\" must not be empty
  (try using replace to provide the value before calling copy)

  "LOG: {"insertId":"14suym9fw9f63r","jsonPayload":{"bytes_sent":"492",
  "connection":{"dest_ip":"10.12.12.33","dest_port":32768,"protocol":6,
  "src_ip":"10.142.0.238","src_port":22},"end_time":"2023-02-13T22:38:30.490546349Z",
  "packets_sent":"15","reporter":"SRC","src_instance":{"project_id":"example-labs",
  "region":"us-east1","vm_name":"example-us-east1","zone":"us-east1-b"},
  "src_vpc":{"project_id":"example-labs","subnetwork_name":"default",
  "vpc_name":"default"},"start_time":"2023-02-13T22:38:29.024032655Z"},
  "logName":"projects/example-labs/logs/compute.googleapis.com%2Fvpc_flows",
  "receiveTimestamp":"2023-02-13T22:38:37.443315735Z","resource":{"labels":
  {"location":"us-east1-b","project_id":"example-labs",
    "subnetwork_id":"00000000000000000000","subnetwork_name":"default"},
    "type":"gce_subnetwork"},"timestamp":"2023-02-13T22:38:37.443315735Z"}

파서 확장 프로그램의 수명 주기 상태

파서 확장 프로그램의 수명 주기 상태는 다음과 같습니다.

DRAFT: 아직 제출되지 않은 새로 만든 파서 확장 프로그램입니다.
VALIDATING: Google SecOps에서 필드가 오류 없이 파싱되도록 기존 원시 로그를 기준으로 매핑 명령어를 검증합니다.
LIVE: 파서 확장 프로그램이 검증을 통과했으며 현재 프로덕션 단계입니다. 수신되는 원시 로그에서 데이터를 추출하여 UDM 레코드로 변환합니다.
FAILED: 파서 확장 프로그램이 검증을 통과하지 못했습니다.

반복 필드 선택기에 대한 자세한 정보

일부 UDM 필드에는 principal.ip 필드와 같은 값 배열이 저장됩니다. 반복 필드 선택기를 사용하면 파서 확장 프로그램이 새로 추출된 데이터를 반복 필드에 저장하는 방식을 제어할 수 있습니다.

값 추가:

파서 확장 프로그램은 새로 추출된 값을 UDM 필드의 기존 값 배열에 추가합니다.
값 바꾸기:

파서 확장 프로그램은 UDM 필드의 기존 값 배열을 새로 추출된 값으로 바꿉니다.

파서 확장 프로그램은 반복 필드가 계층 구조의 최하위 수준에 있는 경우에만 데이터를 반복 필드에 매핑할 수 있습니다. 예를 들면 다음과 같습니다.

반복된 ip 필드는 계층 구조의 최하위 수준에 있고 principal은 반복 필드가 아니므로 udm.principal.ip에 값을 매핑하는 것이 지원됩니다.
intermediary가 반복 필드이고 계층 구조의 최하위 수준에 있지 않으므로 udm.intermediary.hostname에 값을 매핑하는 것은 지원되지 않습니다.

다음 표에는 반복 필드 선택기 구성이 생성된 UDM 레코드에 미치는 영향에 대한 예시가 나와 있습니다.

반복 필드 선택	예시 로그	파서 확장 프로그램 구성	생성된 결과
값 추가	`{"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"1.1.1.1, 2.2.2.2"}}}`	전제조건 필드: `protoPayload.requestMetadata.callerIp` 전제조건 값: `" "` 전제조건 연산자: `NOT_EQUALS` 원시 데이터 필드: `protoPayload.requestMetadata.callerIp` 대상 필드: `event.idm.read_only_udm.principal.ip`	`metadata:{event_timestamp:{}.....}principal:{Ip:"1.1.1.1, 2.2.2.2"} } }`
값 추가	`{"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"2.2.2.2, 3.3.3.3", "name":"Akamai Ltd"}}}`	전제조건 1: 전제조건 필드:`protoPayload.requestMetadata.callerIp` 전제조건 값: `" "` 전제조건 연산자: `NOT_EQUALS` 원시 데이터 필드: `protoPayload.requestMetadata.callerIp` 대상 필드: `event.idm.read_only_udm.principal.ip` 전제조건 2: 원시 데이터 필드: `protoPayload.requestMetadata.name` 대상 필드: `event.idm.read_only_udm.metadata.product_name`	확장 프로그램을 적용하기 전에 사전 빌드된 파서에 의해 생성된 이벤트입니다. `metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}}` 확장 프로그램을 적용한 후의 출력입니다. `timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} .... product_name: "Akamai Ltd"}principal:{ip:"1.1.1.1, 2.2.2.2, 3.3.3.3"}}}`
값 바꾸기	`{"protoPayload":{"@type":"type..AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"2.2.2.2"}}}`	전제조건 필드: `protoPayload.authenticationInfo.principalEmail` 전제조건 값: `" "` 전제조건 연산자: `NOT_EQUALS` 원시 데이터 필드: `protoPayload.authenticationInfo.principalEmail` 대상 필드: `event.idm.read_only_udm.principal.ip`	확장 프로그램을 적용하기 전에 사전 빌드된 파서에 의해 생성된 UDM 이벤트입니다. `timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}}` 확장 프로그램을 적용한 후 UDM 출력 `timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ....} principal:{ip:"2.2.2.2"}}}`

Syslog 추출기 필드 자세히 알아보기

Syslog 추출기 필드를 사용하면 Grok, 정규 표현식 및 정규 표현식 패턴의 이름 지정 토큰을 정의하여 출력을 저장함으로써 구조화된 로그에서 Syslog 헤더를 분리할 수 있습니다.

Syslog 추출기 필드 정의

Syslog 및 대상 필드의 값이 함께 작동하여 파서 확장 프로그램이 Syslog 헤더를 원시 로그의 구조화된 부분에서 분리하는 방법을 정의합니다. Syslog 필드에서 Grok 및 정규 표현식 문법의 조합을 사용하여 표현식을 정의합니다. 표현식에는 원시 로그의 구조화된 부분을 식별하는 변수 이름이 포함됩니다. 타겟 필드에 변수 이름을 지정합니다.

다음 예는 이러한 필드가 함께 작동하는 방식을 보여줍니다.

다음은 원시 로그의 예입니다.

<13>1 2022-09-14T15:03:04+00:00 fieldname fieldname - - - {"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

원시 로그에는 다음 섹션이 포함됩니다.

Syslog 헤더: <13> 2022-09-14T15:03:04+00:00 fieldname fieldname - - -
JSON 형식 이벤트: {"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

원시 로그의 JSON 부분에서 Syslog 헤더를 분리하려면 Syslog 필드에 다음 예시 표현식을 사용합니다. %{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}

표현식의 이 부분에서 Syslog 헤더를 식별합니다. %{TIMESTAMP\_ISO8601} %{WORD} %{WORD} ([- ]+)?
표현식의 이 부분에서 원시 로그의 JSON 세그먼트를 캡처합니다. %{GREEDYDATA:msg}

이 예시에는 변수 이름 msg이 포함되어 있습니다. 변수 이름을 선택합니다. 파서 확장 프로그램은 원시 로그의 JSON 세그먼트를 추출하여 msg 변수에 할당합니다.

타겟 필드에 변수 이름 msg를 입력합니다. msg 변수에 저장된 값이 파서 확장 프로그램에서 만드는 데이터 필드 매핑 명령어에 입력됩니다.

예시 원시 로그를 사용하여 다음 세그먼트를 데이터 매핑 명령어에 입력합니다.

{"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

다음은 완료된 Syslog 및 대상 필드를 보여줍니다.

Syslog 추출기 필드

다음 표에서는 샘플 로그, Syslog 추출 패턴, 대상 변수 이름, 결과가 포함된 추가 예시를 제공합니다.

샘플 원시 로그	Syslog 필드	대상 필드	결과
`<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}"`	`%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}`	msg	`field_mappings { field: "msg" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }`
`<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}`	`%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg1} ([- ]+)?%{GREEDYDATA:msg2}`	msg2	`field_mappings { field: "msg2" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }`
`"<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}"`	`%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:message} ([- ]+)?%{GREEDYDATA:msg2}`	msg2	`Error - message already exists in state and not overwritable.`

UDM `metadata.event_type` 필드 할당에 대한 자세한 내용

UDM 레코드에 UDM metadata.event_type 필드를 할당하면 필수 관련 필드가 UDM 레코드에 있는지 확인하기 위해 검증됩니다. 각 UDM metadata.event_type에는 서로 다른 관련 필드 집합이 필요합니다. 예를 들어 user가 없는 USER_LOGIN 이벤트는 유용하지 않습니다.

필수 관련 필드가 누락되면 UDM 검증에서 오류를 반환합니다.

  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT"
  }

grok 파서는 더 자세한 오류를 반환합니다.

  generic::unknown: 
  invalid event 0: LOG_PARSING_GENERATED_INVALID_EVENT: 
  "generic::invalid_argument: udm validation failed: target field is not set"

할당하려는 UDM event_type의 필수 필드를 찾으려면 다음 리소스를 사용하세요.

Google SecOps 문서: UDM 사용 가이드 - 각 이벤트 유형의 필수 및 선택적 UDM 필드

서드 파티 비공식 리소스: UDM 이벤트 유효성 검사

UDM 사용 가이드에 세부정보가 부족한 경우 이 문서에서는 특정 UDM metadata.event_type를 채우는 데 필요한 최소 필수 UDM 필드를 제공하여 공식 문서를 보완합니다.

예를 들어 문서를 열고 GROUP_CREATION 이벤트 유형을 검색합니다.

다음과 같은 최소 UDM 필드가 UDM 객체로 표시됩니다.

{
    "metadata": {
        "event_timestamp": "2023-07-03T13:01:10.957803Z",
        "event_type": "GROUP_CREATION"
    },
    "principal": {
        "user": {
            "userid": "pinguino"
        }
    },
    "target": {
        "group": {
            "group_display_name": "foobar_users"
        }
    }
}

코드 스니펫 명령어 만들기

코드 스니펫 접근 방식을 사용하면 Logstash와 비슷한 문법을 사용하여 원시 로그에서 값을 추출 및 변환하고 UDM 레코드의 UDM 필드에 할당하는 방법을 정의할 수 있습니다.

코드 스니펫 접근 방식을 사용하여 파서 확장 프로그램을 만들기 전에 다음 섹션을 살펴봐야 합니다.

파서 확장 프로그램 만들기
시작하기
확장 접근 방식 선택에서 코드 스니펫 작성 옵션을 선택합니다.

파서 확장 프로그램을 정의하는 다음 단계는 다음과 같습니다.

팁과 권장사항은 코드 스니펫 안내 작성 시 팁과 권장사항을 참고하세요.
코드 스니펫 명령어 만들기
코드 스니펫 명령어 제출

코드 스니펫 요청 사항 작성 시 유용한 정보 및 권장사항

잘못된 Grok 패턴, 이름 바꾸기 또는 바꾸기 작업 실패, 구문 오류와 같은 문제로 인해 코드 스니펫 안내가 실패할 수 있습니다. 팁과 권장사항은 다음을 참고하세요.

코드 스니펫 명령어 만들기

코드 스니펫 명령어는 기본 (또는 맞춤) 파서와 동일한 문법 및 섹션을 사용합니다.

섹션 1. 원시 로그에서 데이터를 추출합니다.
섹션 2. 추출된 데이터를 변환합니다.
섹션 3. UDM 필드에 하나 이상의 값을 할당합니다.
섹션 4. UDM 이벤트 필드를 @output 키에 결합합니다.

코드 스니펫 접근 방식을 사용하여 파서 확장 프로그램을 만들려면 다음 단계를 따르세요.

파서 확장 프로그램 페이지의 CBN 스니펫 패널에 코드 스니펫을 입력하여 파서 확장 프로그램을 만듭니다.
Validate(유효성 검사)를 클릭하여 매핑 명령어를 검증합니다.

코드 스니펫 명령어 예

다음 예시는 코드 스니펫을 보여줍니다.

다음은 원시 로그의 예입니다.

  {
      "insertId": "00000000",
      "jsonPayload": {
          ...section omitted for brevity...
          "packets_sent": "4",
          ...section omitted for brevity...
      },
      "timestamp": "2022-05-03T01:45:00.150614953Z"
  }

다음은 jsonPayload.packets_sent의 값을 network.sent_bytes UDM 필드에 매핑하는 코드 스니펫의 예입니다.

filter {
  mutate {
    replace => {
      "jsonPayload.packets_sent" => ""
    }
  }
  # Section 1. extract data from the raw JSON log
  json {
    source => "message"
    array_function => "split_columns"
    on_error => "_not_json"
  }
  if [_not_json] {
    drop {
      tag => "TAG_UNSUPPORTED"
    }
  } else {
    # Section 2. transform the extracted data
    if [jsonPayload][packets_sent] not in ["", 0] {
      mutate {
        convert => {
          "jsonPayload.packets_sent" => "uinteger"
        }
        on_error => "_exception1"
      }
      # Section 3. assign the value to a UDM field
      mutate {
        Replace => {
          "event.idm.read_only_udm.network.sent_bytes" => "jsonPayload.packets_sent"
        }
        on_error => "_exception2"
      }
      if ![_exception1] and![_exception2] {
        # Section 4. Bind the UDM fields to the @output key
        mutate {
          merge => {
            "@output" => "event"
          }
        }
      }
    }
  }
}

코드 스니펫 명령어 제출

제출을 클릭하여 매핑 명령어를 저장합니다.
Google SecOps에서 매핑 명령어를 검증합니다.
- 검증 프로세스가 성공하면 상태가 라이브로 변경되고 매핑 명령어가 수신되는 로그 데이터를 처리하기 시작합니다.
- 검증 프로세스가 실패하면 상태가 실패로 변경되고 원시 로그 필드에 오류가 표시됩니다.
참고: 파서 확장 프로그램이 검증되는 동안에는 데이터 매핑 명령어를 수정할 수 없습니다.

기존 파서 확장 프로그램 관리

기존 파서 확장 프로그램을 보고, 수정하고, 삭제하고, 액세스를 제어할 수 있습니다.

기존 파서 확장 프로그램 보기

탐색 메뉴에서 SIEM 설정 > 파서를 선택합니다.
파서 목록에서 보려는 파서 (로그 유형)를 찾습니다. 파서 확장 프로그램이 있는 파서는 이름 옆에 EXTENSION 텍스트로 표시됩니다.
해당 행으로 이동한 다음 메뉴 > 확장 프로그램 보기를 클릭합니다.

커스텀/사전 빌드된 파서 보기 > 확장 프로그램 탭이 파서 확장 프로그램 관련 세부정보와 함께 표시됩니다. 요약 패널에는 기본적으로 LIVE 파서 확장 프로그램이 표시됩니다.

파서 확장 프로그램 수정

기존 파서 확장 프로그램 보기에 설명된 대로 맞춤/사전 빌드된 파서 보기 > 확장 프로그램 탭을 엽니다.
확장 프로그램 수정 버튼을 클릭합니다.

파서 확장 프로그램 페이지가 표시됩니다.
파서 확장 프로그램을 수정합니다.
- 수정을 취소하고 변경사항을 삭제하려면 초안 삭제를 클릭합니다.
- 언제든지 파서 확장 프로그램을 삭제하려면 실패한 확장 프로그램 삭제를 클릭합니다.
- 파서 확장 프로그램 수정을 마치면 제출을 클릭합니다.
  
  검증 프로세스가 실행되어 새 구성을 검증합니다.
  
  참고: 파서 확장 프로그램이 검증되는 동안에는 데이터 매핑 명령어를 수정할 수 없습니다.

파서 확장 프로그램 삭제

기존 파서 확장 프로그램 보기에 설명된 대로 맞춤/사전 빌드된 파서 보기 > 확장 프로그램 탭을 엽니다.
확장 프로그램 삭제 버튼을 클릭합니다.

파서 확장 프로그램에 대한 액세스 제어

기본적으로 관리자 역할을 가진 사용자는 파서 확장 프로그램에 액세스할 수 있습니다. 파서 확장 프로그램을 보고 관리할 수 있는 사용자를 관리할 수 있습니다. 사용자 및 그룹 관리 또는 역할 할당에 대한 자세한 내용은 역할 기반 액세스 제어를 참고하세요.

다음 표에서는 Google SecOps의 새 역할을 요약해서 보여줍니다.

기능	작업	설명
파서	삭제	파서 확장 프로그램을 삭제합니다.
파서	수정	파서 확장 프로그램을 만들고 수정합니다.
파서	뷰	파서 확장 프로그램을 봅니다.

파서 확장 프로그램을 사용하여 UDM 필드 매핑 삭제

파서 확장 프로그램을 사용하여 기존 UDM 필드 매핑을 삭제할 수 있습니다.

SIEM 설정 > 파서를 클릭합니다.
다음 방법 중 하나를 사용하여 파서 확장 프로그램 페이지를 확인합니다.
- 기존 확장 프로그램의 경우 메뉴 > 파서 확장 > 확장 프로그램 보기를 클릭합니다.
- 새 파서 확장 프로그램의 경우 메뉴 > 파서 확장 > 확장 프로그램 만들기를 클릭합니다.
확장 프로그램 메서드로 코드 스니펫 작성을 선택하여 특정 UDM 필드의 값을 삭제하는 맞춤 코드 스니펫을 추가합니다.

기존 확장 프로그램의 경우 파서 확장 프로그램 창에서 수정을 클릭한 다음 코드 스니펫을 추가합니다.

예시 스니펫은 코드 스니펫 - 기존 매핑 삭제를 참고하세요.
코드 스니펫 제출 안내의 단계에 따라 확장 프로그램을 제출합니다.

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

파서 확장 프로그램

파서 확장 프로그램 만들기

파서 추출 및 정규화 프로세스

새 파서 확장 프로그램 정의

새로 추출된 값을 UDM 필드에 병합

제한사항

파서 개념

기본 요건

시작하기

기본 요건 확인

로그 유형에 활성 파서가 있는지 확인

로그 유형에 대한 맞춤 파서가 있는지 확인

로그 유형에 파서가 활성 상태인지 확인

원시 로그에서 추출할 필드를 식별합니다.

적절한 UDM 필드 선택

올바른 UDM 필드 선택

주요 UDM 개념 숙지

기존 파서에서 사용되는 데이터 매핑 이해

UDM 조회 도구 사용

UDM 조회 도구 예시

오류를 방지하기 위한 중요한 UDM 고려사항

UDM으로의 임의 필드 매핑

파서 확장 프로그램 정의 접근 방식 선택

파서 확장 프로그램 페이지 열기

설정 메뉴에서 열기

원시 로그 검색에서 열기

기존 원시 로그 검색에서 열기

파서 확장 프로그램 페이지

확장 프로그램 접근 방식 선택

노 코드 (지도 데이터 필드) 명령어 만들기

반복 필드 선택기 설정

각 필드의 데이터 매핑 명령어 정의

파서 확장 프로그램 제출 및 활성화

반복 필드 선택기에 대한 자세한 정보

Syslog 추출기 필드 자세히 알아보기

Syslog 추출기 필드 정의

UDM metadata.event_type 필드 할당에 대한 자세한 내용

코드 스니펫 명령어 만들기

코드 스니펫 요청 사항 작성 시 유용한 정보 및 권장사항

코드 스니펫 명령어 만들기

코드 스니펫 명령어 예

코드 스니펫 명령어 제출

기존 파서 확장 프로그램 관리

기존 파서 확장 프로그램 보기

파서 확장 프로그램 수정

파서 확장 프로그램 삭제

파서 확장 프로그램에 대한 액세스 제어

파서 확장 프로그램을 사용하여 UDM 필드 매핑 삭제

UDM `metadata.event_type` 필드 할당에 대한 자세한 내용