맞춤 애플리케이션 액세스 로그 수집

다음에서 지원:

이 문서에서는 클라우드 스토리지 또는 스트리밍 수집 방법을 사용하여 맞춤 애플리케이션 액세스 로그를 Google Security Operations에 수집하는 방법을 설명합니다.

맞춤 애플리케이션 액세스 로그는 독점 또는 맞춤 빌드 애플리케이션의 인증 이벤트, 승인 결정, 액세스 패턴을 캡처합니다. 이러한 로그는 사용자 활동을 모니터링하고, 승인되지 않은 액세스 시도를 감지하고, 보안 정책을 준수하는 데 필수적입니다.

시작하기 전에

다음 기본 요건이 충족되었는지 확인합니다.

  • Google SecOps 인스턴스
  • JSON, CSV 또는 구조화된 텍스트 형식의 맞춤 애플리케이션 액세스 로그
  • 다음 중 하나에 대한 액세스 권한이 있어야 합니다.
    • Google Cloud Storage 버킷 (GCS 수집용)
    • Amazon S3 버킷 (S3 수집용)
    • Microsoft Azure Storage 계정 (Azure Blob 수집용)
    • 웹훅 엔드포인트 기능 (푸시 기반 수집용)
    • Amazon Kinesis Data Firehose (스트리밍 수집용)

맞춤 로그 유형 만들기

CUSTOM_APPLICATION_ACCESS 로그 유형이 Google SecOps에 사전 빌드된 파서로 존재하지 않습니다. 로그를 수집하기 전에 맞춤 로그 유형을 만들어야 합니다.

  1. SIEM 설정 > 사용 가능한 로그 유형으로 이동합니다.
  2. 로그 유형 요청을 클릭합니다.
  3. 커스텀 로그 유형 직접 만들기에서 다음 세부정보를 입력합니다.
    • 공급업체/제품: Custom Application Access Logs 입력
    • 로그 유형: CUSTOM_APPLICATION_ACCESS을 입력합니다.

  4. 로그 유형 만들기를 클릭합니다.

  5. 피드를 만들기 전에 새 로그 유형이 모든 구성요소에서 사용 가능하도록 10분 동안 기다립니다.

수집 방법 선택

인프라에 가장 적합한 수집 방법을 선택합니다.

  • Google Cloud Storage (GCS): 애플리케이션이 GCS 버킷에 로그를 작성하거나 로그를 GCS로 내보낼 수 있는 경우 사용합니다.
  • Amazon S3: 애플리케이션이 S3 버킷에 로그를 작성하거나 로그를 S3로 내보낼 수 있는 경우 사용합니다.
  • Azure Blob Storage: 애플리케이션이 Azure Storage에 로그를 작성하거나 로그를 Azure로 내보낼 수 있는 경우 사용합니다.
  • 웹훅: 애플리케이션이 외부 엔드포인트에 HTTP POST 요청을 보낼 수 있는 경우 사용
  • Amazon Kinesis Data Firehose: 애플리케이션이 CloudWatch Logs에 쓰는 경우 또는 실시간 스트리밍이 필요한 경우 사용

옵션 1: Google Cloud Storage에서 수집

Google Cloud Storage 버킷 만들기

  1. Google Cloud Console로 이동합니다.
  2. 프로젝트를 선택하거나 새 프로젝트를 만듭니다.
  3. 탐색 메뉴에서 Cloud Storage> 버킷으로 이동합니다.
  4. 버킷 만들기를 클릭합니다.

  5. 다음 구성 세부정보를 제공합니다.

    설정 값
    버킷 이름 지정 전역적으로 고유한 이름 (예: custom-app-access-logs)을 입력합니다.
    위치 유형 필요에 따라 선택 (리전, 이중 리전, 멀티 리전)
    위치 위치를 선택합니다 (예: us-central1).
    스토리지 클래스 Standard (자주 액세스하는 로그에 권장)
    액세스 제어 균일 (권장)
    보호 도구 선택사항: 객체 버전 관리 또는 보관 정책 사용 설정

  6. 만들기를 클릭합니다.

GCS에 로그를 기록하도록 애플리케이션 구성

액세스 로그를 생성한 GCS 버킷에 기록하도록 맞춤 애플리케이션을 구성합니다. 로그는 다음 형식 중 하나로 작성해야 합니다.

  • JSON 형식 (권장):

    {"timestamp": "2025-01-15T10:30:00Z", "user": "john.doe@example.com", "action": "login", "result": "success", "source_ip": "203.0.113.45", "application": "custom-app", "resource": "/api/users"}

  • CSV 형식:

    timestamp,user,action,result,source_ip,application,resource
2025-01-15T10:30:00Z,john.doe@example.com,login,success,203.0.113.45,custom-app,/api/users

  • 줄바꿈으로 구분된 JSON (NDJSON):

    {"timestamp": "2025-01-15T10:30:00Z", "user": "john.doe@example.com", "action": "login", "result": "success"}
{"timestamp": "2025-01-15T10:30:05Z", "user": "jane.smith@example.com", "action": "access", "result": "denied"}

Google SecOps 서비스 계정 가져오기

Google SecOps는 고유한 서비스 계정을 사용하여 GCS 버킷에서 데이터를 읽습니다. 이 서비스 계정에 버킷에 대한 액세스 권한을 부여해야 합니다.

  1. SIEM 설정> 피드로 이동합니다.
  2. 새 피드 추가를 클릭합니다.
  3. 단일 피드 구성을 클릭합니다.
  4. 피드 이름 필드에 피드 이름을 입력합니다(예: Custom Application Access Logs - GCS).
  5. 소스 유형으로 Google Cloud Storage V2를 선택합니다.
  6. 로그 유형으로 CUSTOM_APPLICATION_ACCESS_CUSTOM을 선택합니다.
  7. 서비스 계정 가져오기를 클릭합니다.

  8. 고유한 서비스 계정 이메일이 표시됩니다. 예를 들면 다음과 같습니다.

    chronicle-12345678@chronicle-gcp-prod.iam.gserviceaccount.com

  9. 다음 단계에서 사용할 수 있도록 이 이메일 주소를 복사합니다.

Google SecOps 서비스 계정에 IAM 권한 부여

Google SecOps 서비스 계정에는 GCS 버킷에 대한 스토리지 객체 뷰어 역할이 필요합니다.

  1. Cloud Storage> 버킷으로 이동합니다.
  2. 버킷 이름을 클릭합니다.
  3. 권한 탭으로 이동합니다.
  4. 액세스 권한 부여를 클릭합니다.
  5. 다음 구성 세부정보를 제공합니다.
    • 주 구성원 추가: Google SecOps 서비스 계정 이메일을 붙여넣습니다.
    • 역할 할당: 스토리지 객체 뷰어 선택

  6. 저장을 클릭합니다.

Google SecOps에서 피드 구성

  1. 피드 생성 페이지로 돌아가거나 SIEM 설정> 피드> 새 피드 추가로 이동합니다.
  2. 다음을 클릭합니다.

  3. 다음 입력 매개변수의 값을 지정합니다.

    • 스토리지 버킷 URL: 다음 접두사 경로를 사용하여 GCS 버킷 URI를 입력합니다.

      gs://custom-app-access-logs/

    • 소스 삭제 옵션: 환경설정에 따라 삭제 옵션을 선택합니다.

      • 삭제 안함: 전송 후 파일을 삭제하지 않습니다 (테스트에 권장).
      • 전송된 파일 삭제: 전송이 완료되면 파일을 삭제합니다.
      • 전송된 파일 및 빈 디렉터리 삭제: 전송이 완료되면 파일과 빈 디렉터리를 삭제합니다.

    • 최대 파일 기간: 지난 일수 동안 수정된 파일을 포함합니다 (기본값은 180일).

    • 애셋 네임스페이스: 애셋 네임스페이스입니다.

    • 수집 라벨: 이 피드의 이벤트에 적용할 라벨입니다 (예: custom_app_access).

  4. 다음을 클릭합니다.

  5. 확정 화면에서 새 피드 구성을 검토한 다음 제출을 클릭합니다.

옵션 2: Amazon S3에서 수집

Amazon S3 버킷 만들기

  1. Amazon S3 콘솔을 엽니다.
  2. 버킷 만들기를 클릭합니다.
  3. 다음 구성 세부정보를 제공합니다.
    • 버킷 이름: 버킷의 의미 있는 이름을 입력합니다 (예: custom-app-access-logs).
    • 리전: 애플리케이션이 실행되는 리전을 선택합니다 (예: us-east-1).
  4. 만들기를 클릭합니다.

S3 액세스 권한이 있는 IAM 사용자 만들기

  1. IAM 콘솔을 엽니다.
  2. 사용자 > 사용자 추가를 클릭합니다.
  3. 사용자 이름을 입력합니다 (예: chronicle-s3-reader).
  4. 프로그래매틱 액세스를 선택합니다.
  5. 다음: 권한을 클릭합니다.
  6. 기존 정책 직접 연결을 선택합니다.
  7. AmazonS3FullAccess 정책을 검색하여 선택합니다.
  8. 다음: 태그를 클릭합니다.
  9. 다음: 검토를 클릭합니다.
  10. 사용자 만들기를 클릭합니다.
  11. .csv 파일 다운로드를 클릭하여 나중에 참고할 수 있도록 액세스 키와 보안 비밀 액세스 키를 저장합니다.
  12. 닫기를 클릭합니다.

S3에 로그를 작성하도록 애플리케이션 구성

액세스 로그를 생성한 S3 버킷에 기록하도록 맞춤 애플리케이션을 구성합니다. GCS 섹션에 설명된 것과 동일한 로그 형식 (JSON, CSV 또는 NDJSON)을 사용합니다.

S3에서 로그를 수집하도록 Google SecOps에서 피드 구성

  1. SIEM 설정> 피드로 이동합니다.
  2. 새 피드 추가를 클릭합니다.
  3. 단일 피드 구성을 클릭합니다.
  4. 피드 이름 필드에 피드 이름을 입력합니다(예: Custom Application Access Logs - S3).
  5. 소스 유형으로 Amazon S3 V2를 선택합니다.
  6. 로그 유형으로 CUSTOM_APPLICATION_ACCESS_CUSTOM을 선택합니다.
  7. 다음을 클릭한 후 제출을 클릭합니다.

  8. 다음 입력 매개변수의 값을 지정합니다.

    • S3 URI: 버킷 URI를 다음 형식으로 입력합니다.

      s3://custom-app-access-logs/

    • 소스 삭제 옵션: 환경설정에 따라 삭제 옵션을 선택합니다.

    • 최대 파일 기간: 지난 일수 동안 수정된 파일을 포함합니다 (기본값은 180일).

    • 액세스 키 ID: S3 버킷에 대한 액세스 권한이 있는 사용자 액세스 키

    • 보안 비밀 액세스 키: S3 버킷에 액세스할 수 있는 사용자 보안 비밀 키입니다.

    • 애셋 네임스페이스: 애셋 네임스페이스입니다.

    • 수집 라벨: 이 피드의 이벤트에 적용할 라벨입니다 (예: custom_app_access).

  9. 다음을 클릭한 후 제출을 클릭합니다.

옵션 3: Azure Blob Storage에서 수집

Azure 스토리지 계정 만들기

  1. Azure 포털에서 스토리지 계정을 검색합니다.
  2. + 만들기를 클릭합니다.

  3. 다음 구성 세부정보를 제공합니다.

    설정 값
    구독 Azure 구독 선택
    리소스 그룹 기존 항목 선택 또는 새로 만들기
    스토리지 계정 이름 고유한 이름 (예: customappaccesslogs)을 입력합니다.
    리전 리전을 선택합니다 (예: East US).
    성능 표준 (권장)
    중복성 LRS (로컬 중복 스토리지)

  4. 검토 + 만들기를 클릭합니다.

  5. 계정 개요를 검토하고 만들기를 클릭합니다.

  6. 배포가 완료될 때까지 기다립니다.

스토리지 계정 사용자 인증 정보 가져오기

  1. 방금 만든 스토리지 계정으로 이동합니다.
  2. 왼쪽 탐색 메뉴의 보안 + 네트워킹에서 액세스 키를 선택합니다.
  3. 키 표시를 클릭합니다.
  4. 나중에 사용할 수 있도록 다음을 복사하여 저장합니다.
    • 스토리지 계정 이름: customappaccesslogs
    • 키 1 또는 키 2: 공유 액세스 키

블로그 컨테이너 만들기

  1. 동일한 스토리지 계정의 왼쪽 탐색에서 컨테이너를 선택합니다.
  2. + 컨테이너를 클릭합니다.
  3. 다음 구성 세부정보를 제공합니다.
    • 이름: access-logs을 입력합니다.
    • 공개 액세스 수준: 비공개 (익명 액세스 없음)를 선택합니다.
  4. 만들기를 클릭합니다.

Azure Blob Storage에 로그를 쓰도록 애플리케이션 구성

생성한 Azure Blob Storage 컨테이너에 액세스 로그를 쓰도록 맞춤 애플리케이션을 구성합니다. GCS 섹션에 설명된 것과 동일한 로그 형식 (JSON, CSV 또는 NDJSON)을 사용합니다.

Azure의 로그를 수집하도록 Google SecOps에서 피드 구성

  1. SIEM 설정> 피드로 이동합니다.
  2. 새 피드 추가를 클릭합니다.
  3. 단일 피드 구성을 클릭합니다.
  4. 피드 이름 필드에 피드 이름을 입력합니다(예: Custom Application Access Logs - Azure).
  5. 소스 유형으로 Microsoft Azure Blob Storage V2를 선택합니다.
  6. 로그 유형으로 CUSTOM_APPLICATION_ACCESS_CUSTOM을 선택합니다.
  7. 다음을 클릭합니다.

  8. 다음 입력 매개변수의 값을 지정합니다.

    • Azure URI: 컨테이너 경로와 함께 Blob 서비스 엔드포인트 URL을 입력합니다.

      https://customappaccesslogs.blob.core.windows.net/access-logs/

    • 소스 삭제 옵션: 환경설정에 따라 삭제 옵션을 선택합니다.

    • 최대 파일 기간: 지난 일수 동안 수정된 파일을 포함합니다 (기본값은 180일).

    • 공유 키: 스토리지 계정에서 캡처한 공유 키 값 (액세스 키)을 입력합니다.

    • 애셋 네임스페이스: 애셋 네임스페이스

    • 수집 라벨: 이 피드의 이벤트에 적용할 라벨입니다 (예: custom_app_access).

  9. 다음을 클릭합니다.

  10. 확정 화면에서 새 피드 구성을 검토한 다음 제출을 클릭합니다.

옵션 4: 웹훅을 사용하여 수집

Google SecOps에서 웹훅 피드 만들기

  1. SIEM 설정> 피드로 이동합니다.
  2. 새 피드 추가를 클릭합니다.
  3. 단일 피드 구성을 클릭합니다.
  4. 피드 이름 필드에 피드 이름을 입력합니다(예: Custom Application Access Logs - Webhook).
  5. 소스 유형으로 웹훅을 선택합니다.
  6. 로그 유형으로 CUSTOM_APPLICATION_ACCESS_CUSTOM을 선택합니다.
  7. 다음을 클릭합니다.
  8. 다음 입력 파라미터의 값을 지정합니다.
    • 분할 구분 기호: 요청당 여러 이벤트를 전송하는 경우 \n을 입력하여 줄바꿈으로 구분된 이벤트를 분할합니다.
    • 애셋 네임스페이스: 애셋 네임스페이스입니다.
    • 수집 라벨: 이 피드의 이벤트에 적용할 라벨입니다 (예: custom_app_access).
  9. 다음을 클릭합니다.
  10. 확정 화면에서 새 피드 구성을 검토한 다음 제출을 클릭합니다.

보안 비밀 키 생성 및 저장

  1. 피드 세부정보 페이지에서 보안 비밀 키 생성을 클릭합니다.
  2. 대화상자에 보안 비밀 키가 표시됩니다.

  3. 보안 비밀 키를 복사하여 안전하게 저장합니다.

피드 엔드포인트 URL 가져오기

  1. 피드의 세부정보 탭으로 이동합니다.
  2. 엔드포인트 정보 섹션에서 피드 엔드포인트 URL을 복사합니다.

  3. URL 형식은 다음과 같습니다.

    https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate

  4. 다음 단계를 위해 이 URL을 저장합니다.

  5. 완료를 클릭합니다.

Google Cloud API 키 만들기

Google SecOps에는 인증을 위한 API 키가 필요합니다. Google Cloud 콘솔에서 제한된 API 키를 만듭니다.

  1. Google Cloud 콘솔 사용자 인증 정보 페이지로 이동합니다.
  2. 프로젝트 (Chronicle 인스턴스와 연결된 프로젝트)를 선택합니다.
  3. 사용자 인증 정보 만들기 API 키를 클릭합니다.
  4. API 키가 생성되어 대화상자에 표시됩니다.
  5. API 키 수정을 클릭하여 키를 제한합니다.
  6. API 키 설정 페이지에서 다음을 수행합니다.
    • 이름: 설명이 포함된 이름을 입력합니다 (예: Chronicle Webhook API Key).
  7. API 제한사항에서 다음을 수행합니다.
    1. 키 제한을 선택합니다.
    2. API 선택 드롭다운에서 Google SecOps API (또는 Chronicle API)를 검색하여 선택합니다.
  8. 저장을 클릭합니다.
  9. 페이지 상단의 API 키 필드에서 API 키 값을 복사합니다.
  10. API 키를 안전하게 저장합니다.

웹훅을 통해 로그를 전송하도록 애플리케이션 구성

Chronicle 웹훅 엔드포인트에 HTTP POST 요청을 전송하도록 맞춤 애플리케이션을 구성합니다.

  • 웹훅 URL 구성:

    1. 피드 엔드포인트 URL에 API 키를 추가합니다.

      https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=<API_KEY>

    2. <API_KEY>를 만든 API 키로 바꿉니다.

  • HTTP POST 요청 형식:

    POST https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=<API_KEY> HTTP/1.1
Content-Type: application/json
x-chronicle-auth: <SECRET_KEY>

{"timestamp": "2025-01-15T10:30:00Z", "user": "john.doe@example.com", "action": "login", "result": "success", "source_ip": "203.0.113.45"}

  • 여러 이벤트 (줄바꿈으로 구분)의 경우:

    POST https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=<API_KEY> HTTP/1.1
Content-Type: application/json
x-chronicle-auth: <SECRET_KEY>

{"timestamp": "2025-01-15T10:30:00Z", "user": "john.doe@example.com", "action": "login", "result": "success"}
{"timestamp": "2025-01-15T10:30:05Z", "user": "jane.smith@example.com", "action": "access", "result": "denied"}

  • curl을 사용한 예:

    curl -X POST \
  "https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "x-chronicle-auth: YOUR_SECRET_KEY" \
  -d '{"timestamp": "2025-01-15T10:30:00Z", "user": "john.doe@example.com", "action": "login", "result": "success", "source_ip": "203.0.113.45"}'

옵션 5: Amazon Kinesis Data Firehose를 사용하여 수집

Google SecOps에서 피드 만들기

  1. SIEM 설정> 피드로 이동합니다.
  2. 새 피드 추가를 클릭합니다.
  3. 단일 피드 구성을 클릭합니다.
  4. 피드 이름 필드에 피드 이름을 입력합니다(예: Custom Application Access Logs - Firehose).
  5. 소스 유형으로 Amazon Data Firehose를 선택합니다.
  6. 로그 유형으로 CUSTOM_APPLICATION_ACCESS_CUSTOM을 선택합니다.
  7. 다음을 클릭합니다.
  8. 다음 입력 파라미터의 값을 지정합니다.
    • 분할 구분 기호: \n를 입력하여 줄바꿈으로 구분된 로그를 분할합니다.
    • 애셋 네임스페이스: 애셋 네임스페이스입니다.
    • 수집 라벨: 이 피드의 이벤트에 적용할 라벨입니다 (예: custom_app_access).
  9. 다음을 클릭합니다.
  10. 피드 구성을 검토하고 제출을 클릭합니다.
  11. 보안 비밀 키 생성을 클릭하여 이 피드를 인증하기 위한 보안 비밀 키를 생성합니다.
  12. 이 보안 비밀을 다시 볼 수 없으므로 보안 비밀 키를 복사하여 저장합니다.
  13. 세부정보 탭으로 이동합니다.
  14. 엔드포인트 정보 필드에서 피드 엔드포인트 URL을 복사합니다.
  15. 완료를 클릭합니다.

Amazon Data Firehose 피드에 대한 API 키 만들기

  1. https://console.cloud.google.com/apis/credentials의 Google Cloud 콘솔 사용자 인증 정보 페이지로 이동합니다.
  2. 사용자 인증 정보 만들기를 클릭한 후 API 키를 선택합니다.
  3. API 키 수정을 클릭하여 키를 제한합니다.
  4. API 제한사항에서 키 제한을 선택합니다.
  5. Google SecOps API를 검색하여 선택합니다.
  6. 저장을 클릭합니다.
  7. API 키를 복사하여 저장합니다.

엔드포인트 URL 구성

  1. 다음 형식으로 피드 엔드포인트 URL에 API 키를 추가합니다.

    <FEED_ENDPOINT_URL>?key=<API_KEY>

  2. 다음을 바꿉니다.

    • <FEED_ENDPOINT_URL>: 이전 단계의 피드 엔드포인트 URL
    • <API_KEY>: 이전 단계의 API 키

    예:

    https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=AIzaSyD...

  3. 다음 단계를 위해 이 전체 URL을 저장합니다.

Firehose용 IAM 정책 만들기

  1. AWS 콘솔에서 IAM > 정책 > 정책 만들기 > JSON 탭으로 이동합니다.

  2. 다음 정책 JSON을 붙여넣습니다.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "firehose:PutRecord",
                "firehose:PutRecordBatch"
            ],
            "Resource": "arn:aws:firehose:us-east-1:123456789012:deliverystream/CustomAppAccessToChronicle"
        }
    ]
}

  3. 다음을 바꿉니다.

    • us-east-1: AWS 리전
    • 123456789012: AWS 계정 ID (12자리 숫자)
    • CustomAppAccessToChronicle: Firehose 전송 스트림 이름 (다음 단계에서 생성)

  4. CustomAppAccessFirehoseWritePolicy 정책의 이름을 지정합니다.

  5. 정책 만들기를 클릭합니다.

CloudWatch Logs용 IAM 역할 만들기

  1. IAM > 역할 > 역할 만들기로 이동합니다.

  2. 커스텀 트러스트 정책을 선택하고 다음을 붙여넣습니다.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "logs.us-east-1.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

  3. us-east-1을 AWS 리전으로 바꿉니다.

  4. 다음을 클릭합니다.

  5. 이전 단계에서 만든 정책 CustomAppAccessFirehoseWritePolicy를 검색하고 선택합니다.

  6. 다음을 클릭합니다.

  7. 역할 이름을 CloudWatchLogsToFirehoseRole로 지정합니다.

  8. 역할 만들기를 클릭합니다.

Kinesis Data Firehose 전송 스트림 만들기

  1. AWS 콘솔에서 Kinesis > Data Firehose > 전송 스트림 만들기로 이동합니다.

  2. 다음 구성 세부정보를 제공합니다.

    • 소스 및 대상:

      • 소스: 직접 PUT 또는 기타 소스를 선택합니다.
      • 대상: HTTP 엔드포인트를 선택합니다.

    • 전송 스트림 이름:

      • 전송 스트림 이름: CustomAppAccessToChronicle을 입력합니다.

    • HTTP 엔드포인트 대상:

      • HTTP 엔드포인트 URL: 이전에 구성한 전체 엔드포인트 URL (피드 엔드포인트 + API 키)을 입력합니다.
      • 콘텐츠 인코딩: GZIP을 선택합니다 (대역폭 절약에 권장).

    • 맞춤 HTTP 헤더:

      • 맞춤 HTTP 헤더 추가를 클릭합니다.
      • 헤더 이름: X-Goog-Chronicle-Auth를 입력합니다.
      • 헤더 값: 이전 단계에서 저장한 보안 비밀 키를 입력합니다.

    • 백업 설정:

      • Amazon S3의 소스 레코드 백업: 실패한 데이터만을 선택합니다 (권장).
      • S3 버킷: 기존 버킷을 선택하거나 실패한 레코드를 위한 새 버킷을 만듭니다.

    • 버퍼 힌트:

      • 버퍼 크기: 1MiB (HTTP 엔드포인트의 최소값)를 입력합니다.
      • 버퍼 간격: 60초 입력

    • 재시도 기간:

      • 재시도 기간: 300초 (5분)를 입력합니다.

  3. 전송 스트림 만들기를 클릭합니다.

  4. 전송 스트림 상태가 활성으로 변경될 때까지 기다립니다 (1~2분).

CloudWatch Logs에 쓰도록 애플리케이션 구성

CloudWatch 로그 그룹에 액세스 로그를 작성하도록 맞춤 애플리케이션을 구성합니다. 그런 다음 Firehose로 로그를 스트리밍하는 구독 필터를 만듭니다.

  1. AWS 콘솔에서 CloudWatch > 로그 > 로그 그룹으로 이동합니다.
  2. 새 로그 그룹을 만들거나 애플리케이션이 로그를 쓰는 기존 로그 그룹을 선택합니다.
  3. 구독 필터 탭을 클릭합니다.
  4. 만들기 > Amazon Kinesis Data Firehose 구독 필터 만들기를 클릭합니다.

  5. 다음 구성 세부정보를 제공합니다.

    • 대상: 전송 스트림 CustomAppAccessToChronicle를 선택합니다.
    • 권한 부여: 역할 CloudWatchLogsToFirehoseRole를 선택합니다.
    • 구독 필터 이름: CustomAppAccessToChronicle을 입력합니다.
    • 로그 형식: 기타를 선택합니다 (Google SecOps에서 파싱을 처리함).
    • 구독 필터 패턴: 모든 이벤트를 전송하려면 비워 둡니다.

  6. 스트리밍 시작을 클릭합니다.

  7. 로그는 Firehose를 통해 Google SecOps로 실시간 스트리밍됩니다.

맞춤 파서 만들기

로그를 수집한 후 데이터를 UDM 형식으로 정규화하는 커스텀 파서를 만들어야 합니다.

  1. SIEM 설정 > 파서로 이동합니다.
  2. 파서 만들기를 클릭합니다.
  3. 로그 유형으로 CUSTOM_APPLICATION_ACCESS_CUSTOM을 선택합니다.

  4. 파서 편집기를 사용하여 로그 필드를 UDM 필드에 매핑하는 Grok 패턴 또는 파서 확장 프로그램을 만드세요.

    파서 매핑 예:

    맞춤 로그 필드 UDM 필드
    timestamp metadata.event_timestamp
    user principal.user.email_addresses
    action security_result.action
    result security_result.summary
    source_ip principal.ip
    application target.application
    resource target.resource.name

  5. 샘플 로그로 파서를 테스트합니다.

  6. 저장을 클릭하여 파서를 활성화합니다.

파서 생성에 관한 자세한 내용은 셀프 서비스 파서 옵션을 참고하세요.

수집 확인

피드와 파서를 구성한 후 로그가 수집되는지 확인합니다.

  1. 검색 > UDM 검색으로 이동합니다.

  2. 다음 쿼리를 실행합니다.

    metadata.log_type = "CUSTOM_APPLICATION_ACCESS_CUSTOM"

  3. 이벤트가 검색 결과에 표시되는지 확인합니다.

  4. 파서 구성에 따라 UDM 필드가 올바르게 채워져 있는지 확인합니다.

UDM 매핑 테이블

로그 필드 UDM 매핑 논리
추가 서비스, env, msg.attachment.fileName, msg.attachment.digest, msg.attachment.key, msg.attachment.authorizeId, msg.attachment.contentType, dest.type, type, msg.sortID, msg.refID, state.reported.applications_installed, state.reported.applications_status, state.reported.ota_queue, state.reported.VICMB_Deg_Battery_LimpHome, state.reported.VICMB_Inhibit_Propulsion, state.reported.VICMB_FA_LostComm_BPCM, state.reported.VICMB_FA_LostComm_SFAM1, state.reported.VICMB_Inhibit_HV, state.reported.VICMB_FA_LostComm_RIDM, state.reported.VICMB_FA_LostComm_RWAM1, state.reported.uname, meta.reported.battery_charging_rate_kw.timestamp, state.reported.battery_charging_rate_kw, meta.reported.cell.connected.timestamp, meta.reported.cell.packet_loss.timestamp, meta.reported.cell.average_ping_ms.timestamp, meta.reported.cell.bitrate.timestamp, meta.reported.cell.download_speed_bytes_per_sec.timestamp, meta.reported.cell.signal_strength.timestamp, meta.reported.cell.signal.timestamp, state.reported.cell.connected, state.reported.cell.packet_loss, state.reported.cell.average_ping_ms, state.reported.cell.bitrate, state.reported.cell.download_speed_bytes_per_sec, state.reported.cell.signal_strength, state.reported.cell.signal에서 생성된 라벨과 병합됨
request_time metadata.collected_timestamp ISO8601 형식을 사용하여 request_time에서 파싱됨
msg_1, msg.body metadata.description 비어 있지 않으면 msg_1의 값, 그렇지 않으면 msg.body
user_id, src_email, otadata.1687965118.initiator metadata.event_type user_id, src_email, otadata.1687965118.initiator 중 하나라도 있으면 'USER_UNCATEGORIZED'로 설정하고, 그렇지 않으면 'GENERIC_EVENT'로 설정합니다.
otadata.1687965118.deployment_id metadata.product_deployment_id 값이 직접 복사됨
version metadata.product_version 값이 직접 복사됨
response.status network.http.response_code 정수로 변환됨
request_id principal.resource.product_object_id 값이 직접 복사됨
msg.attachment.url, otadata.1687965118.download_url principal.url 비어 있지 않은 경우 msg.attachment.url의 값, 그렇지 않은 경우 otadata.1687965118.download_url
src_email, otadata.1687965118.initiator principal.user.email_addresses 이메일 정규식과 일치하는 경우 src_email의 값, 그렇지 않은 경우 otadata.1687965118.initiator의 값
user_id principal.user.userid 값이 직접 복사됨
레벨 security_result.severity 수준이 'INFO'인 경우 'INFORMATIONAL'로 설정됩니다.
metadata.product_name '맞춤 애플리케이션 액세스'로 설정
metadata.vendor_name '맞춤 애플리케이션 액세스'로 설정

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