피드 UI 사용

다음에서 지원:

이 문서에서는 피드 관리 UI 내에서 피드를 만들고, 문제를 해결하고, 관리하는 방법을 설명합니다. 여기에는 피드를 수정하고, 사용 설정하고, 삭제하는 방법이 포함됩니다.

시작하기 전에

각 데이터 피드에는 Google Security Operations에서 설정하기 전에 충족해야 하는 특정 기본 요건이 있습니다. 피드의 요구사항을 확인하려면 소스 유형별 구성에서 특정 데이터 소스를 검색하세요.

지원되는 압축 형식 및 파일 크기

피드 수집에 지원되는 압축 형식은 .gz, .tar.gz, .tar, solr.gz입니다. 다음 표에는 Google SecOps 피드 변환에서 지원하는 다양한 파일 크기가 나와 있습니다.

작업 입력 유형 권장 크기 예상 기간 최대 크기
데이터 모델링 CSV 5GB 미만 7분 미만 10GB
데이터 모델링 CSV 5GB 미만 약 30분 10GB
데이터 모델링 CSV 미정 미정 2GB
데이터 모델링 XML / JSON 1GB 미만 10분 미만 2GB
데이터 모델링 XLS / XLSX 50MB 미만 1분 이내 50MB
파일 병합 모두 1GB 미만 파일 수에 따라 다름 100GB
파일 압축 해제 ZIP 아님 5GB 미만 파일 수에 따라 다름 10GB (비압축)
파일 압축 해제 우편번호 - 파일 수에 따라 다름 4GB (비압축)

로그 행 제한 및 구분자

텍스트 기반 로그 (JSON, CSV 또는 Syslog)를 수집할 때는 데이터가 다음 특정 수집 한도를 준수해야 합니다.

  • 최대 줄 크기: 단일 로그 줄은 4MB를 초과할 수 없습니다. 단일 행이 이 한도를 초과하면 피드가 MaxLogLineSize4MBExceeded 오류와 함께 실패합니다.
  • 지원되는 구분 기호: 줄바꿈 (\n)과 캐리지 리턴 + 줄바꿈(\r\n)이 모두 지원됩니다.

연결된 Cloud 프로젝트 변경이 데이터 피드에 미치는 영향

Google SecOps 인스턴스와 연결된 Google Cloud 프로젝트를 업데이트하는 경우 다음 커넥터를 사용하여 데이터를 수집하는 모든 피드가 중지되며 수동으로 다시 만들어야 합니다.

  • AMAZON_S3_V2
  • AMAZON_SQS_V2
  • GOOGLE_CLOUD_STORAGE_V2
  • AZURE_BLOBSTORE_V2
  • GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN

이러한 커넥터를 사용하지 않는 다른 모든 피드의 경우 중단 없이 인그레스가 계속됩니다. 고객이 취해야 할 조치는 없습니다.

이전 진행에 대한 모든 것

영향을 받는 피드의 경우 다음과 같은 변경사항이 적용됩니다.

  • 피드 상태: 이전 전에 생성된 피드는 즉시 실시간 데이터 가져오기를 중지하고 읽기 전용이 됩니다.
  • 기존 데이터: 이전 전에 이미 Google SecOps로 전송된 데이터는 자동으로 수집되며 데이터가 손실되지 않습니다.
  • 오류 메시지: 오래된 피드를 수정하거나 삭제하려고 하면 This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed라는 메시지가 표시됩니다.

고객이 취해야 하는 조치

데이터를 지속적으로 수집하려면 새 환경에서 피드를 수동으로 다시 만들어야 합니다. 중단을 최소화하려면 다음 단계를 따르세요.

  1. 피드 다시 만들기: 마이그레이션 전에 있던 피드를 대체할 새 피드를 만들어야 합니다.
  2. 최대 파일 기간 구성: 새 피드를 설정할 때 BYOP 업데이트가 시작되기 약 2시간 전으로 최대 파일 기간을 설정합니다. 이 시간 버퍼를 통해 원활한 전환이 가능합니다.
  3. 중복 데이터 관리: 선택한 최대 파일 기간에 따라 중복 데이터 전송이 발생할 수 있습니다. Google SecOps에서 중복 로그를 필터링하는 방법에 관한 기술적 세부정보는 중복 삭제 방지를 참고하세요.

  4. 기존 피드 기록 및 삭제 (이전 전): BYOP 이전을 시작하기 전에 영향을 받는 커넥터 (예: Amazon S3 V2)를 사용하는 모든 기존 피드의 구성 설정을 기록한 다음 피드를 삭제합니다. 마이그레이션 전에 생성된 피드를 삭제하지 않으면 관리할 수 없게 되고 Google SecOps 웹 인터페이스에 분리된 설정으로 남아 있습니다.

피드 설정 방법

Google SecOps 고객이 플랫폼에서 피드를 설정하는 방법은 두 가지입니다. 환경에 가장 적합한 방법을 사용하세요.

  • SIEM 설정 > 피드 (표준)
  • 콘텐츠 허브 > 콘텐츠 팩 (프리미엄)

피드 구성

이 섹션에서는 표준 절차 흐름부터 시작하여 피드를 일반적으로 구성하는 방법을 설명합니다. 피드 페이지에 나열된 데이터 피드에는 구성한 피드를 비롯해 Google에서 계정에 구성한 모든 피드가 포함됩니다.

피드 추가

Google SecOps 계정에 피드를 추가하려면 다음 단계를 완료하세요.

  1. Google SecOps 메뉴에서 SIEM 설정 > 피드를 선택합니다.

  2. 새 피드 추가를 클릭합니다.

  3. 다음 페이지에서 단일 피드 구성을 클릭합니다. 참고: Google SecOps SIEM 독립형 플랫폼을 사용하는 고객에게는 이 단계가 관련이 없습니다.

  4. 피드 이름을 추가합니다.

  5. 소스 유형 목록에서 Google SecOps로 데이터를 가져올 소스 유형을 선택합니다. 다음 피드 소스 유형 중에서 선택할 수 있습니다.

    • Amazon Data Firehose
    • Amazon S3 (지원 중단됨)
    • Amazon S3 (V2)
    • Amazon SQS (지원 중단됨)
    • Amazon SQS (V2)
    • Azure Blob Storage (지원 중단됨)
    • Azure Blob Storage (V2)
    • 맞춤 API
    • Google Cloud Pub/Sub
    • Cloud Storage (지원 중단됨)
    • Cloud Storage (V2)
    • Cloud Storage 이벤트 기반
    • 타사 API
    • 웹훅

    중요:

    • Amazon S3 (지원 중단됨), Amazon SQS (지원 중단됨), Azure Blob Storage (지원 중단됨), Google Cloud Cloud Storage (지원 중단됨) 피드를 사용하는 경우 유효한 디렉터리 경로가 있어야 합니다.
    • Amazon SQS (지원 중단됨) 또는 Amazon SQS (V2)를 사용하는 경우 Amazon SQS 큐에서 메시지를 삭제할 수 있는 Google SecOps 권한을 명시적으로 부여합니다.
    • Amazon SQS (지원 중단됨) 피드를 사용하는 경우 하나의 피드만 큐에서 메시지를 소비해야 합니다. 다른 애플리케이션이나 피드에서 읽은 메시지는 현재 피드에 수집되지 않습니다.
    • 피드 소스 유형으로 Amazon SQS (지원 중단됨)를 사용하는 것은 Amazon S3 버킷의 로그에만 지원됩니다.
  6. 로그 유형 목록에서 수집할 로그에 해당하는 로그 유형을 선택합니다. 사용 가능한 로그는 이전에 선택한 소스 유형에 따라 다릅니다.

    소스 유형으로 Cloud Storage를 선택한 경우 서비스 계정 가져오기 옵션을 사용해서 고유한 서비스 계정을 가져옵니다. Google Cloud Storage 피드 설정 예시를 참고하세요.

  7. 다음을 클릭합니다.

  8. 입력 매개변수 탭에서 필요한 매개변수를 지정합니다. 여기에 표시되는 옵션은 속성 설정 탭에서 선택한 소스와 로그 유형에 따라 다릅니다. 각 필드의 물음표 아이콘 위에 마우스 포인터를 가져가면 제공해야 하는 항목에 대한 추가 정보를 확인할 수 있습니다.

  9. 선택사항: 속성 설정 탭에서 네임스페이스를 지정할 수 있습니다. 네임스페이스에 대한 자세한 내용은 애셋 네임스페이스로 작업을 참고하세요.

  10. 다음을 클릭합니다.

  11. 확정 탭에서 새 피드 구성을 검토합니다.

  12. 제출을 클릭합니다. Google SecOps에서는 새 피드의 유효성 검사가 완료됩니다. 피드가 검사를 통과하면 피드 이름이 생성되어 Google SecOps에 제출되며 Google SecOps에서 데이터 가져오기를 시도하기 시작합니다.

    피드 요청 완료

제품군에 여러 피드 구성 (Google SecOps 고객만 해당)

로그 유형에 따라 제품군별로 여러 피드를 구성할 수 있습니다.

  • 기준 로그 유형: 권장으로 표시됩니다. 이러한 로그 유형은 핵심 플랫폼 기능에 권장됩니다.
  • 보조 로그 유형: 선택사항으로 표시됩니다. 이러한 로그 유형은 추가 컨텍스트를 제공합니다.

설정을 간소화하기 위해 플랫폼은 각 구성에 대한 구체적인 설정 안내와 사전 정의된 매개변수를 제공합니다. 예를 들어 CrowdStrike Falcon의 경우 권장선택사항 로그 유형 모두에서 고유한 피드를 여러 개 만들어 포괄적인 데이터 범위가 충분하도록 할 수 있습니다.

CrowdStrike EDR용 피드 구성

다음 단계에 따라 CrowdStrike EDR의 로그 피드를 구성합니다.

  1. 설정 > 피드에서 새 피드 추가를 클릭합니다.
    1. CrowdStrike Falcon 제품을 클릭합니다.
    2. CrowdStrike EDR 로그 유형을 선택합니다.
  2. 또는 콘텐츠 허브 > 콘텐츠 팩에서 CrowdStrike Falcon 제품을 클릭합니다.
    1. 시작하기를 클릭합니다.
    2. CrowdStrike EDR 로그 유형을 선택합니다.
  3. 다음 필드의 값을 지정합니다.

    필드 설명
    Source Type Amazon SQS
    Region URI와 연결된 AWS S3 리전입니다.
    Queue Name 읽어올 SQS 큐 이름입니다.
    Account Number SQS 계정 번호입니다.
    Source Deletion Option 전송 후 파일과 디렉터리를 삭제할지 여부를 나타냅니다.
    Queue Access Key ID 계정의 20자리 영숫자 액세스 키입니다(예: AKIAOSFOODNN7EXAMPLE).
    Queue Secret Access Key 계정의 40자리 영숫자 보안 비밀 액세스 키입니다(예: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY).

  4. 선택사항: 다음 매개변수를 구성합니다.

    • 피드 이름: 피드의 고유한 이름이 자동으로 입력됩니다.
    • 애셋 네임스페이스: 피드와 연결된 네임스페이스입니다.
    • 수집 라벨: 이 피드의 이벤트에 적용된 라벨입니다.
  5. 피드 만들기를 클릭합니다.

이 과정을 반복하여 동일한 로그 유형에 대한 피드를 추가로 만들 수 있습니다. 이 페이지에서 사용 가능한 다른 로그 유형의 피드를 직접 구성할 수도 있습니다. 완료되면 피드 관리 페이지로 이동하여 구성된 모든 로그 유형의 자세한 요약을 확인합니다.

IP 허용 목록

허용 목록을 사용 설정하고 서드 파티 API에서 데이터를 수집하는 모든 로그 유형에 대해 Google IP 범위를 추가합니다.

소스 파일 삭제

소스 삭제 옵션을 사용하면 전송이 완료된 후 스토리지에서 피드 소스 객체 (파일 및 폴더)를 삭제할 수 있습니다. 이 옵션은 Cloud Storage를 비롯한 일부 피드 소스 유형에서만 사용할 수 있습니다. 이러한 피드 소스 유형에는 새로 추가피드 수정 워크플로에 소스 삭제 옵션 필드가 포함됩니다.

소스 삭제 옵션

  • Cloud Storage를 비롯한 지원되는 피드 소스 유형의 경우 소스 삭제 옵션 필드에서 다음 옵션을 제공합니다.

    • 파일 삭제 안함
    • 전송된 파일 및 빈 디렉터리 삭제
    • 전송된 파일 삭제하기
  • Microsoft Azure Blob Storage (AZURE_BLOBSTORE)는 소스 파일 삭제를 지원하지 않습니다. 소스 삭제 옵션 필드에서 파일 삭제 안함 옵션만 선택합니다.

  • 다음 피드 소스 ("feedSourceType")의 경우 GOOGLE_CLOUD_STORAGE_V2, GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN, AMAZON_S3_V2, AMAZON_SQS_V2, AZURE_BLOBSTORE_V2, 소스 삭제 옵션 필드에 다음 두 가지 옵션이 제공됩니다.

    • 삭제 안함: 전송 후 파일을 삭제하지 않습니다.
    • ON_SUCCESS: 전송 후 모든 파일과 빈 디렉터리를 삭제합니다.

소스별 설정 및 권한

Google SecOps와 통신하려면 소스 유형에 따라 특정 인증 및 네트워킹 구성이 필요합니다. 이 섹션에서는 권한을 구성하고 서비스 계정을 설정하는 방법을 설명합니다. 설명된 설정은 Cloud Storage 수집 (풀 기반), 멀티 클라우드 수집 (크로스 클라우드 풀), 푸시 기반 수집 (API 또는 실시간)에 중점을 둡니다.

Google Cloud Storage 피드 설정 예시

  1. Google SecOps 메뉴에서 설정을 선택한 후 피드를 클릭합니다.
  2. 새 피드 추가를 클릭합니다.
  3. 다음 페이지에서 단일 피드 구성을 클릭합니다. Google SecOps SIEM 독립형 플랫폼을 사용하는 경우에는 이 단계가 적용되지 않습니다.
  4. 소스 유형으로 Cloud Storage v2를 선택합니다.
  5. 로그 유형을 선택합니다. 예를 들어 Google Kubernetes Engine 감사 로그의 피드를 만들려면 로그 유형으로 Google Kubernetes Engine 감사 로그를 선택합니다.
  6. 서비스 계정 가져오기를 클릭합니다. Google SecOps는 Google SecOps에서 데이터를 수집하는 데 사용하는 고유한 서비스 계정을 제공합니다. 또는 API를 사용하여 프로그래매틱 방식으로 이 서비스 계정을 가져올 수 있습니다. 서비스 계정 가져오기를 참고하세요.
  7. 선택사항: 서비스 계정을 구성합니다. 자세한 내용은 Google SecOps 서비스 계정에 대한 액세스 권한 부여를 참고하세요.
  8. 다음을 클릭합니다.
  9. 사용자가 만든 Cloud Storage 구성에 따라 다음 필드의 값을 지정합니다.

    • 스토리지 버킷 URI

    • 소스 삭제 옵션

    Cloud Storage 버킷 설정 방법에 대해 자세히 알아보려면 버킷 만들기를 참고하세요.

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

Google SecOps 서비스 계정에 대한 액세스 권한 부여

  1. Google Cloud 콘솔에서 Cloud Storage 버킷 페이지로 이동합니다.

    버킷으로 이동

  2. 관련된 Cloud Storage 객체에 대해 서비스 계정에 액세스 권한을 부여합니다.

    • 특정 파일에 대해 읽기 권한을 부여하려면 다음 단계를 완료하세요.

      1. 파일을 선택하고 액세스 수정을 클릭합니다.
      2. 주 구성원 추가를 클릭합니다.
      3. 새 주 구성원 필드에 Google SecOps 서비스 계정의 이름을 입력합니다.
      4. 읽기 권한이 포함된 역할을 Google SecOps 서비스 계정에 할당합니다. 예를 들어 스토리지 객체 뷰어(roles/storage.objectViewer)를 할당합니다. 이 작업은 균일한 버킷 수준 액세스를 사용 설정하지 않은 경우에만 수행할 수 있습니다.
      5. 저장을 클릭합니다.
    • 여러 파일에 읽기 권한을 부여하려면 다음과 같이 버킷 수준에서 액세스 권한을 부여합니다.

      • "feedSourceType": "GOOGLE_CLOUD_STORAGE"의 경우:

        1. Google SecOps 서비스 계정을 스토리지 버킷에 주 구성원으로 추가하고 여기에 IAM 스토리지 객체 뷰어 (roles/storage.objectViewer) 역할을 부여합니다.
        2. 소스 파일을 삭제하도록 피드를 구성하는 경우 Google SecOps 서비스 계정을 버킷의 주 구성원으로 추가하고 여기에 IAM 스토리지 객체 관리자(roles/storage.objectAdmin) 역할을 부여해야 합니다.
      • "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2"의 경우 다음 역할을 부여합니다.

        1. 다음 역할을 부여합니다.

          • 다른 Cloud Storage 버킷으로 전송되는 경우 스토리지 객체 뷰어 (roles/storage.objectViewer)
        2. 소스 삭제 옵션에 선택한 항목에 따라 다음 역할 중 하나를 부여합니다. 성공 시를 선택하는 경우 스토리지 기존 버킷 작성자 역할을 부여합니다. 사용 안함을 선택한 경우 스토리지 기존 버킷 리더 역할을 부여합니다.

          • 객체 삭제 권한이 필요한 경우 스토리지 기존 버킷 작성자 (roles/storage.legacyBucketWriter)
          • 객체 삭제 권한이 필요하지 않은 경우 스토리지 기존 버킷 리더 (roles/storage.legacyBucketReader)
      • "feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN"의 경우:

        1. 다음 역할 중 하나를 부여합니다.

          • 다른 Cloud Storage 버킷으로 전송되는 경우 스토리지 객체 뷰어 (roles/storage.objectViewer)
          • 전송이 파일 시스템으로 전송되는 경우 스토리지 객체 생성자 (roles/storage.objectCreator)
        2. 다음 역할 중 하나를 부여합니다.

          • 객체 삭제 권한이 필요한 경우 스토리지 기존 버킷 작성자 (roles/storage.legacyBucketWriter)
          • 객체 삭제 권한이 필요하지 않은 경우 스토리지 기존 버킷 리더 (roles/storage.legacyBucketReader)

Amazon S3 및 Azure Storage에 대한 STS 액세스 사용 설정

STS는 다음 Google Cloud Storage 피드에서 Amazon S3 및 Azure Storage 블롭 저장소의 데이터를 Google SecOps로 전송하는 데 사용됩니다.

  • Amazon S3 (V2)
  • Amazon SQS (V2)
  • Azure Blob Storage (V2)

STS는 정의된 STS IP 주소 범위 집합에서 Amazon S3 및 Azure 스토리지 서비스로 데이터 전송 요청을 보냅니다. 이러한 STS IP 주소 범위는 다음 JSON 파일에 게시됩니다. IP 범위

이러한 STS 피드 소스 유형을 사용하려면 STS가 Amazon S3 및 Azure 스토리지 서비스에 액세스할 수 있도록 IP 액세스 제한을 조정해야 할 수 있습니다.

  1. JSON 파일에서 최신 IP 범위를 가져옵니다.

    보안 구성을 업데이트된 상태로 유지하기 위해 최소한 매주 이 JSON 파일의 데이터를 확인하는 것이 좋습니다. 새 범위가 파일에 추가되면 시스템은 STS의 요청에 이 범위를 사용하기 전에 최소 7일 이상 기다립니다.

    JSON 파일에서 IP 범위를 가져오는 샘플 Python 스크립트는 기본 도메인의 IP 주소를 참고하세요.

  2. 현재 IP 범위 creationTime를 이전 JSON 파일에서 읽은 IP 범위 creationTime와 비교합니다. 이러한 IP 주소가 다른 경우 Amazon S3 및 Azure Storage blobstore에서 IP 액세스 제한을 업데이트하세요.

    • Amazon S3의 경우

      Amazon S3 blobstore에서 IP 액세스 제한을 업데이트하려면 다음 단계를 따르세요.

      AWS 프로젝트에 스토리지 액세스에 대해 IP 제한사항이 사용되는 경우 STS 작업자가 사용하는 IP 범위를 허용되는 IP 목록에 추가해야 합니다.

      이러한 범위를 허용된 IP로 추가하려면 AWS S3 문서: 특정 IP 주소를 기반으로 액세스 관리에 설명된 대로 bucket policyCondition 필드를 사용합니다.

    • Azure Storage의 경우

      Azure Storage blobstore의 IP 액세스 제한을 업데이트하려면 다음 단계를 따르세요.

      Azure Storage 방화벽을 사용하여 Azure 리소스에 대한 액세스를 제한하는 경우 STS 작업자가 사용하는 IP 범위를 허용된 IP 목록에 추가해야 합니다.

      이러한 범위를 허용되는 IP로 추가하려면 Azure Storage 방화벽 및 가상 네트워크 구성의 안내를 따르세요.

Pub/Sub 푸시 피드 설정

Pub/Sub 푸시 피드를 설정하려면 다음 단계를 따르세요.

  1. Pub/Sub 푸시 피드를 만듭니다.
  2. Pub/Sub 구독에서 엔드포인트 URL을 지정합니다.

Pub/Sub 푸시 피드 만들기

  1. Google SecOps 메뉴에서 설정을 선택한 후 피드를 클릭합니다.
  2. 새로 추가를 클릭합니다.
  3. 피드 이름 필드에 피드 이름을 입력합니다.
  4. 소스 유형 목록에서 Google Cloud Pub/Sub 푸시를 선택합니다.
  5. 로그 유형을 선택합니다. 예를 들어 개방형 사이버 보안 스키마 프레임워크의 피드를 만들려면 로그 유형으로 개방형 사이버 보안 스키마 프레임워크(OCSF)를 선택합니다.
  6. 다음을 클릭합니다.
  7. 선택사항: 다음 입력 파라미터의 값을 지정합니다.
    • 분할 구분 기호: 로그 줄을 구분하는 데 사용되는 구분 기호입니다. \n만 사용할 수 있습니다.
    • 애셋 네임스페이스: 애셋 네임스페이스입니다.
    • 수집 라벨: 이 피드의 이벤트에 적용할 라벨입니다.
  8. 다음을 클릭합니다.
  9. 확정 화면에서 새 피드 구성을 검토한 다음 제출을 클릭합니다.
  10. 세부정보 탭의 엔드포인트 정보 필드에서 피드 엔드포인트 URL을 복사합니다. Pub/Sub에서 푸시 구독을 만들려면 이 엔드포인트 URL이 필요합니다.
  11. 선택사항: 피드 사용 설정됨 전환 버튼을 클릭하여 피드를 사용 중지합니다. 피드는 기본적으로 사용 설정되어 있습니다.
  12. 완료를 클릭합니다.

엔드포인트 URL 지정

Pub/Sub 푸시 피드를 만든 후 다음과 같이 엔드포인트 URL을 지정합니다.

  1. Pub/Sub에서 푸시 구독을 만듭니다. 푸시 구독을 만드는 방법에 대한 자세한 내용은 푸시 구독 만들기를 참조하세요.
  2. Google Cloud Pub/Sub 푸시 피드에서 사용할 수 있는 엔드포인트 URL을 지정합니다.
  3. 인증 사용 설정을 선택하고 서비스 계정을 선택합니다.
  4. 푸시 페이로드 래핑 해제푸시 페이로드 래핑 해제 쓰기 메시지 메타데이터 옵션을 모두 사용 중지합니다.

Amazon Data Firehose 피드 설정

Amazon Data Firehose 피드를 설정하려면 다음 단계를 따르세요.

  1. Amazon Data Firehose 피드를 만들고 엔드포인트 URL과 비밀 키를 복사합니다.
  2. Google SecOps에 인증할 API 키를 만듭니다. 기존 API 키를 재사용하여 Google SecOps에 인증할 수도 있습니다.
  3. Amazon Data Firehose에서 엔드포인트 URL을 지정합니다.

Amazon Data Firehose 피드 만들기

  1. Google SecOps 메뉴에서 설정을 선택한 후 피드를 클릭합니다.
  2. 새로 추가를 클릭합니다.
  3. 피드 이름 필드에 피드 이름을 입력합니다.
  4. 소스 유형 목록에서 Amazon Data Firehose를 선택합니다.
  5. 로그 유형을 선택합니다. 예를 들어 개방형 사이버 보안 스키마 프레임워크의 피드를 만들려면 로그 유형으로 개방형 사이버 보안 스키마 프레임워크(OCSF)를 선택합니다.
  6. 다음을 클릭합니다.
  7. 선택사항: 다음 입력 파라미터의 값을 지정합니다.
    • 분할 구분 기호: 로그 줄을 구분하는 데 사용되는 구분 기호입니다. \n만 사용할 수 있습니다.
    • 애셋 네임스페이스: 애셋 네임스페이스입니다.
    • 수집 라벨: 이 피드의 이벤트에 적용할 라벨입니다.
  8. 다음을 클릭합니다.
  9. 확정 화면에서 새 피드 구성을 검토한 다음 제출을 클릭합니다.
  10. 보안 비밀 키 생성을 클릭하여 이 피드를 인증하기 위한 보안 비밀 키를 생성합니다.
  11. 이 보안 비밀을 다시 볼 수 없으므로 보안 비밀 키를 복사하여 저장합니다. 새 보안 비밀 키를 다시 생성할 수 있지만 보안 비밀 키를 다시 생성하면 이전 보안 비밀 키는 더 이상 사용할 수 없게 됩니다.
  12. 세부정보 탭의 엔드포인트 정보 필드에서 피드 엔드포인트 URL을 복사합니다. Amazon Data Firehose에서 전송 스트림의 대상 설정을 지정할 때 이 엔드포인트 URL이 필요합니다.
  13. 선택사항: 피드 사용 설정됨 전환 버튼을 클릭하여 피드를 사용 중지합니다. 피드는 기본적으로 사용 설정되어 있습니다.
  14. 완료를 클릭합니다.

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

Amazon Data Firehose 피드의 API 키를 만들려면 다음 단계를 따르세요.

  1. Google Cloud 콘솔의 사용자 인증 정보 페이지로 이동합니다.
  2. 사용자 인증 정보 만들기를 클릭한 후 API 키를 선택합니다.
  3. Chronicle API에 대한 API 키 액세스를 제한합니다.

엔드포인트 URL 지정

Amazon Data Firehose에서 다음과 같이 HTTPS 엔드포인트와 액세스 키를 지정합니다.

  1. 피드 엔드포인트 URL에 API 키를 추가하고 다음 형식으로 이 URL을 HTTP 엔드포인트 URL로 지정합니다.

      ENDPOINT_URL?key=API_KEY
    

    다음을 바꿉니다.

    • ENDPOINT_URL: 피드 엔드포인트 URL입니다.
    • API_KEY: Google SecOps에 인증하기 위한 API 키입니다.
  2. 액세스 키의 경우 Amazon Data Firehose 피드를 만들 때 가져온 보안 비밀 키를 지정합니다.

HTTPS 웹훅 피드 설정

시작하기 전에 다음 사항을 확인하세요.

  • Google SecOps용Google Cloud 프로젝트가 구성되어 있고 Chronicle API가 프로젝트에 사용 설정되어 있는지 확인합니다.
  • Google SecOps 인스턴스를 Google Cloud 서비스에 연결합니다.

HTTPS 웹훅 피드를 설정하려면 다음 단계를 따르세요.

  1. HTTPS 웹훅 피드를 만들고 엔드포인트 URL과 비밀 키를 복사합니다.
  2. 엔드포인트 URL로 지정된 API 키를 만듭니다. 기존 API 키를 재사용하여 Google SecOps에 인증할 수도 있습니다.
  3. 애플리케이션에서 엔드포인트 URL을 지정합니다.

단일 웹훅 요청에서 여러 이벤트 전송

다음 코드 샘플은 curl --location 항목 뒤에 여러 개의 JSON 객체를 줄바꿈으로 구분하여 단일 요청 본문의 형식을 지정하는 방법을 보여줍니다.

--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'

HTTPS 웹훅 피드 만들기

  1. Google SecOps 메뉴에서 설정을 선택한 후 피드를 클릭합니다.
  2. 새로 추가를 클릭합니다.
  3. 피드 이름 필드에 피드 이름을 입력합니다.
  4. 소스 유형 목록에서 웹훅을 선택합니다.
  5. 로그 유형을 선택합니다. 예를 들어 개방형 사이버 보안 스키마 프레임워크의 피드를 만들려면 로그 유형으로 개방형 사이버 보안 스키마 프레임워크(OCSF)를 선택합니다.
  6. 다음을 클릭합니다.
  7. 선택사항: 다음 입력 파라미터의 값을 지정합니다.
    • 분할 구분 기호: 로그 줄을 구분하는 데 사용되는 구분 기호입니다. \n만 사용할 수 있습니다.
    • 애셋 네임스페이스: 애셋 네임스페이스입니다.
    • 수집 라벨: 이 피드의 이벤트에 적용할 라벨입니다.
  8. 다음을 클릭합니다.
  9. 확정 화면에서 새 피드 구성을 검토한 다음 제출을 클릭합니다.
  10. 보안 비밀 키 생성을 클릭하여 이 피드를 인증하기 위한 보안 비밀 키를 생성합니다.
  11. 이 보안 비밀을 다시 볼 수 없으므로 보안 비밀 키를 복사하여 저장합니다. 새 보안 비밀 키를 다시 생성할 수 있지만 보안 비밀 키를 다시 생성하면 이전 보안 비밀 키는 더 이상 사용할 수 없게 됩니다.
  12. 세부정보 탭의 엔드포인트 정보 필드에서 피드 엔드포인트 URL을 복사합니다. 클라이언트 애플리케이션에서 이 엔드포인트 URL을 지정해야 합니다.
  13. 선택사항: 피드 사용 설정됨 전환 버튼을 클릭하여 피드를 사용 중지합니다. 피드는 기본적으로 사용 설정되어 있습니다.
  14. 완료를 클릭합니다.

웹훅 피드에 대한 API 키 만들기

  1. Google Cloud 콘솔의 사용자 인증 정보 페이지로 이동합니다.
  2. 사용자 인증 정보 만들기를 클릭한 후 API 키를 선택합니다.
  3. Chronicle API에 대한 API 키 액세스를 제한합니다.

엔드포인트 URL 지정

  1. 클라이언트 애플리케이션에서 웹훅 피드에서 제공되는 HTTPS 엔드포인트를 지정합니다.
  2. 다음 형식의 커스텀 헤더의 일부로 API 키와 보안 비밀 키를 지정하여 인증을 사용 설정합니다.

    X-goog-api-key = API_KEY

    X-Webhook-Access-Key = SECRET

    URL에 지정하는 대신 헤더로 API 키를 지정하는 것이 좋습니다. 웹훅 클라이언트가 커스텀 헤더를 지원하지 않는 경우 쿼리 파라미터를 다음 형식으로 사용하여 API 키와 보안 비밀 키를 지정할 수 있습니다.

      ENDPOINT_URL?key=API_KEY&secret=SECRET
    

    다음을 바꿉니다.

    • ENDPOINT_URL: 피드 엔드포인트 URL입니다.
    • API_KEY: Google SecOps에 인증하기 위한 API 키입니다.
    • SECRET: 피드를 인증하기 위해 생성한 보안 비밀 키입니다.

맞춤 API 피드 설정

Google Security Operations 맞춤 API 피드 (코드 없는 커넥터라고도 함)를 사용하면 유연한 구성 기반 모델을 사용하여 서드 파티 REST API에서 원격 분석을 수집할 수 있습니다. 콘솔에서 직접 엔드포인트, 인증, 페이지로 나누기 전략, 상태 관리를 정의하여 데이터 가져오기를 구성할 수 있습니다.

주요 이점

  • 통합 가속화: 백엔드 업데이트를 기다리지 않고 안내 마법사를 통해 몇 분 만에 새로운 원격 분석 소스를 온보딩합니다.
  • 상태 저장 체크포인트: 폴링 주기 전반에서 데이터 중복이 없고 누락된 로그가 없는지 확인합니다.
  • 상위-하위 팬아웃: 리소스 나열 및 연결된 원격 분석 가져오기와 같은 2단계 검색 워크플로를 지원합니다.
  • 자동 복원력 및 비율 제한: 공급업체 제한 및 할당량 소진을 방지합니다. 안정적이고 중단 없는 인그레션을 위해 맞춤 API 피드는 지수 백오프로 HTTP 429 응답을 자동으로 처리하고, 구성 가능한 비율 제한 및 작업 지연 스테거링으로 요청을 조정하고, 안전 가이드라인을 적용합니다. 자세한 내용은 비율 제한 및 스로틀링 가이드를 참고하세요.

기본 요건

맞춤 API 피드를 만들기 전에 다음 기본 요건을 확인하세요.

  • 권한: 피드를 만들거나 수정하려면 Chronicle API 관리자 (roles/chronicle.admin) 또는 Chronicle API 편집자 (roles/chronicle.editor) 역할이 있어야 합니다.
  • 서드 파티 API 요구사항:
    • 유효한 API 기본 URL (https:// 사용해야 함)
    • API 사용자 인증 정보 (API 키, 기본 인증 사용자 인증 정보 또는 OAuth 2.0 클라이언트 ID/보안 비밀)
    • 엔드포인트 경로, 요청 매개변수, JSON 응답 구조, 비율 제한을 자세히 설명하는 공급업체 API 참고 리소스
  • Secret Manager 액세스: 사용자 인증 정보는 Secret Manager 내에서 암호화되고 안전하게 관리됩니다. 커넥터를 실행하는 서비스 ID는 Secret Manager (roles/secretmanager.secretAccessorroles/secretmanager.admin)와 자동으로 상호작용합니다.

맞춤 API 피드 구성

맞춤 API 피드를 구성하려면 다음 단계를 따르세요.

  1. SIEM 설정 > 피드로 이동합니다.
  2. 새 피드 추가를 클릭합니다.
  3. 단일 피드 구성을 클릭합니다.
  4. 피드 이름 필드에 고유한 설명이 포함된 이름을 입력합니다 (예: 1Password-Audit-Events).
  5. 소스 유형 목록에서 맞춤 API를 선택합니다.
  6. 로그 유형 목록에서 타겟 Google SecOps 로그 유형을 선택합니다.
  7. 다음을 클릭합니다.
  8. 일반 설정에서 다음을 구성합니다.

    • 기본 URL: 기본 호스트를 입력합니다 (예: https://events.1password.com). https://로 시작해야 합니다. 하위 경로 또는 후행 슬래시를 추가하지 마세요.

    • 폴링 빈도: 플랫폼에서 새 원격 분석을 위해 API를 확인하는 빈도를 분 단위로 지정합니다. 지원되는 범위: 5~2,880분 (기본값: 15분) 표준 API (순차) 피드의 경우 10~15분이 표준입니다. 목록 및 세부정보 (상위-하위) 피드의 경우 중복 없이 전체 팬아웃 작업이 실행되도록 30~60분이 권장됩니다.

  9. 인증에서 지원되는 인증 방법 중 하나를 선택한 다음 필수 필드를 구성합니다.

    • 기본 인증: 사용자 이름 (API 계정 ID)과 보안 비밀 (보안 비밀번호 또는 토큰)을 입력합니다.
    • OAuth 2.0 클라이언트 사용자 인증 정보: OAuth 2.0 클라이언트 사용자 인증 정보 부여 흐름을 사용하여 인증합니다. Google SecOps는 각 수집 주기 전에 베어러 액세스 토큰을 자동으로 요청, 캐시, 새로고침합니다. OAuth 토큰 엔드포인트 (예: https://auth.vendor.com/oauth/token), OAuth 클라이언트 ID, OAuth 클라이언트 보안 비밀을 입력합니다.
    • API 키 요청 헤더: 요청 헤더에 삽입된 맞춤 API 키를 사용하여 인증합니다 (가장 일반적인 엔터프라이즈 REST 패턴). 헤더 이름 (예: Authorization 또는 X-API-Key)과 헤더 값 (예: Bearer <SECRET_TOKEN> 또는 <SECRET_KEY>)을 입력합니다.
    • API 키 쿼리 매개변수: URL 쿼리 매개변수에 삽입된 맞춤 API 키를 사용하여 인증합니다. 쿼리 매개변수 이름 (예: api_key)과 쿼리 파라미터 값 (예: <SECRET_KEY>)을 입력합니다.
  10. 커스텀 API에서 사용하는 커넥터 모델을 선택합니다.

    • 표준 API (순차적): 각 폴이 이전 폴의 상태를 기반으로 직접 빌드되는 선형 폴링 흐름입니다. 이 모델에서 다음 폴링은 이전 폴링에서 추출된 커서, 토큰 또는 타임스탬프를 사용하여 새 데이터만 가져옵니다. 공급업체에서 원격 분석 이벤트 레코드를 직접 반환하는 엔드포인트를 제공하는 경우 (예: 1Password, Okta, SentinelOne, GitHub, Slack) 이 카드를 선택합니다.
    • 목록 및 세부정보 (상위-하위): 2단계 탐색 흐름입니다. 피드는 리소스 또는 객체 목록 (예: 사용자 ID 또는 지역 목록)을 가져오기 위해 초기 호출 (상위)을 실행합니다. 그러면 피드에서 식별된 각 개별 리소스의 상세 원격 분석을 가져오기 위해 종속 후속 호출 (하위)을 자동으로 생성합니다. 공급업체 API에 2단계 검색 패턴이 필요한 경우 이 카드를 선택합니다. 먼저 엔드포인트를 호출하여 동적 엔티티 목록 (예: 영역, 계정, 프로젝트, 기기)을 가져온 다음 엔티티별 후속 세부정보 요청을 실행하여 원격 분석 (예: Cloudflare, AWS CloudWatch, Tenable)을 가져옵니다.
  11. 표준 API (순차)를 선택한 경우 다음 단계를 따르세요.

    1. API 엔드포인트에서 다음 매개변수를 구성하여 요청의 기술적 경로와 속도 페이싱을 정의합니다.
      • 엔드포인트 경로: 기준 URL에 추가되는 특정 API 경로입니다 (예: /api/v1/auditevents). 이는 쿼리할 정확한 원격 분석 리소스를 정의합니다.
      • HTTP 메서드: URL 쿼리 매개변수를 사용하여 데이터를 가져오려면 GET을 선택하고 검색 페이로드 또는 필터 본문을 제출하려면 POST를 선택합니다.
    2. 요청 본문: POST 요청의 경우 JSON 데이터 페이로드를 제공합니다. {"limit": 100, "start_time": "{{.last_timestamp}}"}와 같은 동적 체크포인트 변수를 삽입할 수 있습니다.
    3. 분당 최대 요청 수: 분당 전송할 최대 요청 수를 입력합니다. 공급업체 API 비율 제한을 준수하기 위한 클라이언트 측 비율 제한기입니다 (기본값: RPM 5 = 12초마다 요청 1개). 이 설정은 다중 페이지 페이지로 나누기 중에 할당량 소진을 방지합니다.
    4. 선택사항: 맞춤 헤더에서 헤더 이름을 구성한 다음 추가를 클릭하여 대상 API에 필요한 특수 HTTP 헤더 (예: Content-Type: application/json, Accept: application/json)를 정의합니다.
    5. 선택사항: 쿼리 매개변수에서 을 구성한 다음 추가를 클릭하여 URL 쿼리 문자열에 추가되는 추가 필터 또는 옵션 (예: count=1000, status=active)을 지정하거나 동적 템플릿 변수 (예: start={{.last_run_time}})를 바인딩합니다.
    6. 페이지로 나누기 전략: 서드 파티 API에서 다중 페이지 결과 집합을 처리하는 데 필요한 페이지로 나누기 메커니즘을 선택한 후 필수 필드를 구성합니다.
      • 없음: 페이징 없이 단일 요청으로 데이터를 가져옵니다.
      • 토큰 페이지로 나누기: 토큰 (맞춤 키)을 사용하여 다음 페이지를 가져옵니다. 다음 페이지 토큰 JSON 경로 (예: meta.next_cursor) 및 토큰 페이지로 나누기 쿼리 매개변수 이름 (예: cursor)을 입력합니다.
      • 링크 페이지로 나누기: 대답에 제공된 URL을 따라 더 많은 데이터를 가져옵니다. 다음 페이지 링크 JSON 경로 (예: links.next 또는 @odata.nextLink)를 입력합니다.
      • 오프셋 페이지로 나누기: 정해진 수의 레코드를 건너뛰어 다음 집합을 가져옵니다. 오프셋 쿼리 매개변수 이름 (예: offset)을 입력합니다.
      • 페이지 번호 페이지로 나누기: 다음 순차적 페이지 번호로 이동합니다. 페이지 번호 쿼리 매개변수 이름 (예: page)을 입력합니다.
    7. 체크포인트에서 커넥터가 반복되는 폴링 주기 간에 중단된 위치를 기억할 수 있도록 하는 설정을 구성합니다.

      • 전략: 다음 전략 중 하나를 선택하고 필수 필드를 구성합니다.
        • 없음: 주기에 걸쳐 진행 상황을 추적하지 않고 사용 가능한 모든 데이터를 가져옵니다.
        • 최신 타임스탬프: 최신 레코드의 타임스탬프를 추적합니다. 체크포인트 값 JSON 경로 (예: timestamp 또는 event_time) 및 체크포인트 변수 (예: last_run_time, 후속 설문조사에서 {{.last_run_time}}로 참조됨)를 입력합니다.
        • 최신 레코드: 가장 높은 레코드 ID를 추적하여 새 레코드만 가져옵니다. 체크포인트 값 JSON 경로 (예: id 또는 event_id) 및 체크포인트 변수 (예: last_id, {{.last_id}}로 참조됨)를 입력합니다.
        • 반복자 토큰: API에서 제공하는 지속적인 연속 토큰을 사용합니다. 체크포인트 값 JSON 경로체크포인트 변수 (예: iterator_token, {{.iterator_token}}로 참조됨)를 입력합니다.
    8. 응답 매핑에서 플랫폼이 로그를 찾아 추출하는 방법을 알려주는 규칙을 제공합니다.

      • 타겟 데이터 JSON 경로: 타겟 로그 항목 목록이 있는 API 응답 페이로드의 정확한 경로를 입력합니다. 객체로 래핑된 배열 (예: {"items": [...]})의 경우 items를 입력합니다. 루트 JSON 배열을 직접 반환하는 API (예: [{...}, {...}])의 경우 이 필드를 완전히 비워 둡니다 ([]).
  12. 목록 및 세부정보 (상위-하위)를 선택한 경우 다음을 수행합니다.

    1. 상위 요청 (탐색): 항목 목록을 반환하는 엔드포인트를 구성합니다.
      1. API 엔드포인트에서 다음 매개변수를 구성하여 요청의 기술적 경로와 속도 페이싱을 정의합니다.
        • 엔드포인트 경로: 기준 URL에 추가되는 특정 API 경로입니다 (예: /api/v1/auditevents). 쿼리할 정확한 원격 분석 리소스를 정의합니다.
        • HTTP 메서드: URL 쿼리 매개변수를 사용하여 데이터를 가져오려면 GET을 선택하고 검색 페이로드 또는 필터 본문을 제출하려면 POST를 선택합니다.
        • 요청 본문: POST 요청의 경우 JSON 데이터 페이로드를 제공합니다. {"limit": 100, "start_time": "{{.last_timestamp}}"}와 같은 동적 체크포인트 변수를 삽입할 수 있습니다.
      2. 분당 최대 요청 수: 분당 전송할 최대 요청 수를 입력합니다. 공급업체 API 비율 제한을 준수하기 위한 클라이언트 측 비율 제한기입니다 (기본값: RPM 5 = 12초마다 요청 1개). 이 설정은 다중 페이지 페이지로 나누기 중에 할당량 소진을 방지합니다.
      3. 선택사항: 맞춤 헤더에서 헤더 이름을 구성한 다음 추가를 클릭하여 대상 API에 필요한 특수 HTTP 헤더 (예: Content-Type: application/json, Accept: application/json)를 정의합니다.
      4. 선택사항: 쿼리 매개변수에서 을 구성한 다음 추가를 클릭하여 URL 쿼리 문자열에 추가되는 추가 필터 또는 옵션 (예: count=1000, status=active)을 지정하거나 동적 템플릿 변수 (예: start={{.last_run_time}})를 바인딩합니다.
      5. 페이지로 나누기 전략: 서드 파티 API에서 다중 페이지 결과 집합을 처리하는 데 필요한 페이지로 나누기 메커니즘을 선택한 후 필수 필드를 구성합니다.
        • 없음: 페이징 없이 단일 요청으로 데이터를 가져옵니다.
        • 토큰 페이지로 나누기: 토큰 (맞춤 키)을 사용하여 다음 페이지를 가져옵니다. 다음 페이지 토큰 JSON 경로 (예: meta.next_cursor) 및 토큰 페이지로 나누기 쿼리 매개변수 이름 (예: cursor)을 입력합니다.
        • 링크 페이지로 나누기: 대답에 제공된 URL을 따라 더 많은 데이터를 가져옵니다. 다음 페이지 링크 JSON 경로 (예: links.next 또는 @odata.nextLink)를 입력합니다.
        • 오프셋 페이지로 나누기: 정해진 수의 레코드를 건너뛰어 다음 집합을 가져옵니다. 오프셋 쿼리 매개변수 이름 (예: offset)을 입력합니다.
        • 페이지 번호 페이지로 나누기: 다음 순차적 페이지 번호로 이동합니다. 페이지 번호 쿼리 매개변수 이름 (예: page)을 입력합니다.
      6. 체크포인트에서 커넥터가 반복되는 폴링 주기 사이에 중단된 위치를 기억할 수 있도록 하는 설정을 구성합니다.
        • 전략: 다음 전략 중 하나를 선택하고 필수 필드를 구성합니다.
          • 없음: 주기에 걸쳐 진행 상황을 추적하지 않고 사용 가능한 모든 데이터를 가져옵니다.
          • 최신 타임스탬프: 최신 레코드의 타임스탬프를 추적합니다. 체크포인트 값 JSON 경로 (예: timestamp 또는 event_time) 및 체크포인트 변수 (예: last_run_time, 후속 설문조사에서 {{.last_run_time}}로 참조됨)를 입력합니다.
          • 최신 레코드: 가장 높은 레코드 ID를 추적하여 새 레코드만 가져옵니다. 체크포인트 값 JSON 경로 (예: id 또는 event_id) 및 체크포인트 변수 (예: last_id, {{.last_id}}로 참조됨)를 입력합니다.
          • 반복자 토큰: API에서 제공하는 지속적인 연속 토큰을 사용합니다. 체크포인트 값 JSON 경로체크포인트 변수 (예: iterator_token, {{.iterator_token}}로 참조됨)를 입력합니다.
    2. 데이터 추출 (브리지): 다음을 구성합니다.
      • 상품 식별자 JSON 경로: 개별 항목을 고유하게 식별하는 상위 응답의 특정 필드입니다 (예: id 또는 zone_id). 커넥터는 상위 배열의 각 항목에서 이 식별자를 추출합니다.
      • 템플릿 변수 이름: 추출된 ID를 저장할 맞춤 변수 이름을 지정합니다 (예: zone_id). UI에 아래의 하위 요청에서 {{.zone_id}} 사용이라는 동적 배지가 표시됩니다.
    3. 하위 요청 (세부정보): 각 항목의 상세 로그를 반환하는 엔드포인트를 구성합니다.
      1. API 엔드포인트에서 다음 매개변수를 구성하여 요청의 기술적 경로와 속도 페이싱을 정의합니다.
        • 엔드포인트 경로: 기준 URL에 추가되는 특정 API 경로입니다 (예: /client/v4/zones/{{.zone_id}}/logs/received). 쿼리할 정확한 원격 분석 리소스를 정의합니다.
        • HTTP 메서드: URL 쿼리 매개변수를 사용하여 데이터를 가져오려면 GET을 선택하고 검색 페이로드 또는 필터 본문을 제출하려면 POST를 선택합니다.
        • 요청 본문: POST 요청의 경우 JSON 데이터 페이로드를 제공합니다. {"limit": 100, "start_time": "{{.last_timestamp}}"}와 같은 동적 체크포인트 변수를 삽입할 수 있습니다.
      2. 분당 최대 요청 수: 분당 전송할 최대 요청 수를 입력합니다. 공급업체 API 비율 제한을 준수하기 위한 클라이언트 측 비율 제한기입니다 (기본값: RPM 5 = 12초마다 요청 1개). 이 설정은 다중 페이지 페이지로 나누기 중에 할당량 소진을 방지합니다.
      3. 선택사항: 맞춤 헤더에서 헤더 이름을 구성한 다음 추가를 클릭하여 대상 API에 필요한 특수 HTTP 헤더 (예: Content-Type: application/json, Accept: application/json)를 정의합니다.
      4. 선택사항: 쿼리 매개변수에서 을 구성한 다음 추가를 클릭하여 URL 쿼리 문자열에 추가되는 추가 필터 또는 옵션 (예: count=1000, status=active)을 지정하거나 동적 템플릿 변수 (예: start={{.last_run_time}})를 바인딩합니다.
      5. 페이지로 나누기 전략: 서드 파티 API에서 다중 페이지 결과 집합을 처리하는 데 필요한 페이지로 나누기 메커니즘을 선택한 후 필수 필드를 구성합니다.
        • 없음: 페이징 없이 단일 요청으로 데이터를 가져옵니다.
        • 토큰 페이지로 나누기: 토큰 (맞춤 키)을 사용하여 다음 페이지를 가져옵니다. 다음 페이지 토큰 JSON 경로 (예: meta.next_cursor) 및 토큰 페이지로 나누기 쿼리 매개변수 이름 (예: cursor)을 입력합니다.
        • 링크 페이지로 나누기: 대답에 제공된 URL을 따라 더 많은 데이터를 가져옵니다. 다음 페이지 링크 JSON 경로 (예: links.next 또는 @odata.nextLink)를 입력합니다.
        • 오프셋 페이지로 나누기: 정해진 수의 레코드를 건너뛰어 다음 집합을 가져옵니다. 오프셋 쿼리 매개변수 이름 (예: offset)을 입력합니다.
        • 페이지 번호 페이지로 나누기: 다음 순차적 페이지 번호로 이동합니다. 페이지 번호 쿼리 매개변수 이름 (예: page)을 입력합니다.
      6. 체크포인트에서 커넥터가 반복되는 폴링 주기 사이에 중단된 위치를 기억할 수 있도록 하는 설정을 구성합니다.
        • 전략: 다음 전략 중 하나를 선택하고 필수 필드를 구성합니다.
          • 없음: 주기에 걸쳐 진행 상황을 추적하지 않고 사용 가능한 모든 데이터를 가져옵니다.
          • 최신 타임스탬프: 최신 레코드의 타임스탬프를 추적합니다. 체크포인트 값 JSON 경로 (예: timestamp 또는 event_time) 및 체크포인트 변수 (예: last_run_time, 후속 설문조사에서 {{.last_run_time}}로 참조됨)를 입력합니다.
  13. 다음 일정 및 라벨 설정을 구성합니다.

    • 폴링 빈도: 표준 간격 (예: 5m, 1h)을 선택합니다.
    • 네임스페이스: 선택적 조직 태그입니다.
    • 수집 라벨: 데이터 RBAC의 키-값 쌍입니다.
  14. 제출을 클릭합니다. Google SecOps는 자동 사용자 인증 정보 및 엔드포인트 유효성 검사를 실행합니다. 유효성 검사에 성공하면 피드가 폴링을 시작합니다.

샘플 구성 1: 1Password 감사 이벤트 (표준 API (순차) 모델)

다음 선언적 JSON 구성은 1Password의 커서 기반 체크포인트가 있는 표준 API (순차) 모델을 보여줍니다.

{
  "base_url": "https://events.1password.com",
  "polling_frequency": 15,
  "header_auth": {
    "header_key_values": [
      {
        "key": "Authorization",
        "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
      }
    ]
  },
  "primary_request": {
    "request_settings": {
      "endpoint_path": "/api/v1/auditevents",
      "http_method": "POST",
      
      "request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
      
      "custom_headers": [
        {
          "key": "Content-Type",
          "value": "application/json"
        }
      ],
      "max_requests_per_minute": 5
    },
    "pagination_strategy": {
      "token": {
        "next_page_token_json_path": "additional_items_url",
        "query_param": "cursor"
      }
    },
    "checkpointing": {
      "latest_timestamp_strategy": {
        "checkpoint_value_path": "timestamp",
        "checkpoint_variable": "last_run_time"
      }
    },
    "response_mapping": {
      "target_data_path": ["items"]
    }
  }
}

구체적인 샘플 구성 2: Cloudflare 영역 원격 분석 (목록 및 세부정보 (상위-하위) 모델)

다음 선언적 JSON 구성은 Cloudflare의 목록 및 세부정보 (상위-하위) 팬아웃 모델을 보여줍니다.

{
 "base_url": "https://api.cloudflare.com",
 "polling_frequency": 30,
 "header_auth": {
   "header_key_values": [
     {
       "key": "Authorization",
       "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
     }
   ]
 },

 "primary_request": {
   "request_settings": {
     "endpoint_path": "/client/v4/zones",
     "http_method": "GET"
   },
   "response_mapping": {
     "target_data_path": ["result"]
   },
   "pagination_strategy": {
     "none": {}
   },
   "checkpointing": {
     "none_strategy": {}
   },
   "dependent_requests_config": {
     "item_id_json_path": "id",
     "item_id_variable": "zone_id",
     "dependent_requests": [
       {
         "request_settings": {
           "endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
           "http_method": "GET",
           "query_parameters": [
             {
               "key": "start",
               "value": "{{.last_run_time}}"
             },
             {
               "key": "count",
               "value": "1000"
             }
           ],
           "max_requests_per_minute": 5
         },

         "pagination_strategy": {
           "none": {}
         },
         "checkpointing": {
           "latest_timestamp_strategy": {
             "checkpoint_value_path": "EdgeStartTimestamp",
             "checkpoint_variable": "last_run_time"
           }
         },
         "response_mapping": {
           "target_data_path": []
         }
       }
     ]
   }
 }
}

맞춤 API 권장사항

  • 폴링 빈도 안내:
    • 적당한 폴링 간격으로 시작: 대량 엔드포인트의 초기 폴링 간격을 15분 또는 30분으로 설정하여 벤더 API 할당량 동작을 관찰한 후 5분으로 낮춥니다.
    • 대량 팬아웃에 최적화: 수십 개 또는 수백 개의 리소스를 검색하는 상위-하위 (목록 및 세부정보) 피드의 경우 다음 검색 주기가 시작되기 전에 모든 페이싱된 하위 작업이 완전히 완료되도록 폴링 빈도를 30~60분으로 설정하는 것이 좋습니다.
  • 수집 경로 검증: 상태 체크포인트를 구성하기 전에 공급업체 문서 또는 API 테스트 도구를 사용하여 타임스탬프의 정확한 JSON 필드 이름을 확인합니다.
  • 다중 하위 요소 API 분해: 서드 파티 API에서 단일 사용자 목록의 알림 감사 로그를 가져와야 하는 경우 최적의 격리를 유지하기 위해 두 개의 별도 단일 하위 요소 피드 (알림용 하나, 감사 로그용 하나)를 만듭니다.

비율 제한 및 제한 가이드라인

고객 피드 구성이 서드 파티 공급업체 할당량을 초과하거나 시스템 리소스를 독점하지 않도록 맞춤 API 피드 유형은 다음과 같은 자동 가이드라인을 구현합니다.

  • 구성 가능한 요청 페이싱 (비율 제한): 발신 HTTP 요청은 공급업체 비율 제한을 초과하지 않도록 자동으로 페이싱됩니다. 기본 페이싱 비율은 분당 5개 요청 (12초마다 1개 요청)입니다. 엔드포인트 설정의 분당 최대 요청 수 필드를 사용하여 엔드포인트별로 조정하여 공급업체에서 게시한 API 할당량과 일치시킬 수 있습니다.
  • 자녀 요청 한도: 상위-하위 (목록 및 세부정보) 피드의 경우 디스커버리 요청은 폴링 주기당 최대 500개의 하위 요청을 디스패치할 수 있습니다.
  • 단일 수준 팬아웃 깊이: 커넥터는 최대 팬아웃 깊이를 1단계 (상위 항목 검색 → 하위 항목 세부정보)로 엄격하게 적용합니다. 중첩된 종속 요청 (손자 호출)은 지원되지 않습니다.
  • 응답 페이로드 크기 상한: 단일 요청 또는 페이지에 허용되는 최대 HTTP 응답 크기는 50MB입니다. 페이지로 나누지 않은 API가 50MB를 초과하는 응답을 반환하면 리소스 소진 오류와 함께 가져오기가 실패합니다. 이를 방지하려면 항상 페이지로 나누기 쿼리 매개변수 (예: limit 또는 page_size)를 구성하여 더 작은 배치로 레코드를 가져오세요.
  • 자동 HTTP 429 백오프: 서드 파티 공급업체 API가 HTTP 429 (요청한 횟수가 너무 많음)로 응답하면 Google SecOps에서 자동으로 상태를 캡처하고 지수 백오프 기간을 시작하여 공급업체 할당량 창이 다시 채워질 때까지 작업 실행을 일시중지합니다.

맞춤 API 제한

수집 경로를 계획할 때 커스텀 API 피드 유형에는 다음과 같은 제한사항이 있습니다.

  • 엄격한 JSON 지원: JSON API 응답만 지원됩니다. XML, CSV, Parquet, Avro와 같은 다른 형식은 지원되지 않습니다.
  • 동적 요청 서명 없음: 요청별 동적 암호화 서명이 필요한 API는 지원되지 않습니다 (예: AWS SigV4, Akamai, Oracle OCI).
  • 다단계 인증 없음: 폴링 전에 사용자 인증 정보를 임시 세션 토큰으로 교환하기 위해 초기 프로그래매틱 로그인 호출이 필요한 API (예: Saviynt)는 지원되지 않습니다.
  • WebSocket 또는 푸시 수집 없음: 맞춤 API 피드는 표준 HTTPS 풀 폴링을 지원합니다. 지속적인 스트리밍 연결 (WebSocket) 및 수신 웹훅은 지원되지 않습니다.
  • 상호 TLS (mTLS) 없음: 인증은 API 키, 기본 인증 또는 표준 OAuth 2.0 클라이언트 사용자 인증 정보를 사용해야 합니다. 클라이언트 측 인증서 핸드셰이크는 지원되지 않습니다.

맞춤 API 피드 문제 해결

Cloud Logging 로그 탐색기에서 맞춤 API 피드의 오류를 조사하려면 다음 쿼리를 사용하세요.

resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"

FEED_ID를 피드 ID로 바꿉니다.

실패한 HTTP 요청만 필터링하려면 다음 쿼리를 사용하세요.

jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400

FEED_ID를 피드 ID로 바꿉니다.

일반적인 실패 모드 및 해결 방법

증상 / 오류 근본 원인 해결 방법 / 해결책
HTTP 401 승인되지 않음 / HTTP 403 금지됨 API 키, 비밀번호 또는 OAuth 사용자 인증 정보가 만료되었거나 잘못되었습니다. 피드를 수정하고 유효한 사용자 인증 정보를 다시 입력한 후 제출을 클릭합니다.
HTTP 404 Not Found 잘못된 기본 URL 또는 엔드포인트 경로 템플릿 공급업체 API 참고 리소스에서 엔드포인트를 검사합니다. 기준 URL이 깔끔하게 끝나고 엔드포인트 경로가 /로 시작하는지 확인합니다.
HTTP 429 요청이 너무 많음 공급업체 API 비율 제한을 초과했습니다. 폴링 빈도를 늘리거나 쿼리 매개변수에서 limit 매개변수를 줄입니다.
JSON 추출 오류 (items_path가 비어 있음) 응답 구성 경로가 일치하지 않습니다. API 응답 페이로드 구조를 확인하고 타겟 데이터 JSON 경로를 업데이트합니다.
중복 데이터 수집 상태 구성 타임스탬프 또는 ID 추출기 경로가 잘못되었습니다. 타임스탬프의 로그 레코드 필드 이름을 확인하고 추출기 경로를 업데이트합니다.

피드 관리

데이터 피드를 구성한 후 관리 도구를 사용하여 수집 상태를 모니터링하고, 기존 매개변수를 수정하고, 피드 수명 주기를 관리합니다. 이 섹션에서는 피드 상태를 해석하고 지속적인 데이터 공개 상태를 보장하기 위해 필수 유지보수 작업을 수행하는 방법을 설명합니다.

피드 페이지에서는 구성된 피드 목록을 탐색하고 정리하는 데 도움이 되는 여러 도구를 제공합니다.

  • 검색: 검색창을 사용하여 피드 이름, 피드 ID 또는 소스 유형으로 피드를 찾습니다.

  • 필터: 필터 아이콘을 클릭하여 특정 피드 속성을 기준으로 목록을 좁힙니다.

  • CSV 다운로드: CSV로 다운로드를 클릭하여 현재 피드 목록을 CSV 파일로 내보냅니다.

  • 페이지로 나누기: 페이지로 나누기 컨트롤을 사용하여 다음 작업을 할 수 있습니다.

    • 페이지당 행 수를 변경합니다.

    • 페이지 탭과 화살표를 사용하여 여러 페이지의 피드를 탐색합니다.

  • 마지막 새로고침 시간: 타임스탬프를 확인하여 피드 목록이 마지막으로 업데이트된 시간을 확인합니다.

구성된 피드 보기

피드 페이지에는 구성한 모든 피드가 표시됩니다.

  1. SIEM 설정> 피드로 이동합니다. 기본 페이지에 구성된 모든 피드가 표시됩니다.
  2. 각 행 위로 마우스 포인터를 가져가 more_vert 더보기 메뉴를 표시합니다.
  3. 메뉴에서 피드 세부정보를 확인하고, 피드를 수정하거나, 사용 중지하거나, 삭제할 수 있습니다.

피드 상태 모니터링

초기 피드 페이지에서 피드 상태를 모니터링할 수 있으며, 피드 상태는 다음과 같을 수 있습니다.

  • 활성: 피드가 구성되었으며 Google SecOps 계정으로 데이터를 수집할 준비가 되었습니다.
  • InProgress: Google SecOps가 구성된 서드 파티에서 데이터를 가져오려고 시도합니다.
  • 완료됨: 이 피드에서 데이터를 성공적으로 검색했습니다.
  • 보관처리됨: 중지된 피드입니다.
  • 실패: 피드에서 데이터를 가져올 수 없습니다. 이 문제의 원인은 구성 문제일 수 있습니다. 질문을 클릭하여 구성 오류를 표시합니다. 오류를 수정하고 피드를 다시 제출했으면 피드 페이지로 돌아가서 피드 작동 여부를 확인합니다.

기존 피드 수정

피드 페이지에서 다음과 같이 기존 피드를 수정할 수 있습니다.

  1. 기존 피드 위에 마우스 포인터를 올려놓고 오른쪽 열의 more_vert를 클릭합니다.

  2. 피드 수정을 클릭합니다. 이제 피드의 입력 매개변수를 수정하고 Google SecOps에 다시 제출할 수 있습니다. Google SecOps에서는 업데이트된 피드를 사용하려고 시도합니다.

피드 사용 설정 (재개) 및 사용 중지 (일시중지)

피드를 사용 중지하면 Google SecOps가 해당 소스에서 새 데이터를 수집하지 않습니다. 데이터 수집을 즉시 중지하려면 피드를 삭제해야 합니다. 활성 또는 제한된 기존 전송은 완료될 때까지 계속됩니다. 피드를 다시 사용 설정하면 Google SecOps에서 피드가 사용 중지된 동안 누락된 데이터를 가져올 수 있습니다. 이 기능을 '백필 가능성'이라고 합니다.

상태 열에서 사용 설정된 피드의 라벨이 Active, InProgress, Completed 또는 Failed로 지정됩니다. 중지된 필드의 라벨은 Archived로 지정됩니다. 설명은 피드 상태 모니터링을 참고하세요.

피드 페이지에서 기존 피드를 사용 설정 (재개)하거나 사용 중지 (일시중지)할 수 있습니다.

  1. 기존 피드 위에 마우스 포인터를 올려놓고 오른쪽 열의 more_vert를 클릭합니다.

  2. 선택사항: 피드 사용 설정됨 전환 버튼을 클릭하여 피드를 사용 설정합니다.

  3. 선택사항: 피드 사용 중지 전환 버튼을 클릭하여 피드를 사용 중지합니다. 이제 피드의 라벨이 Archived로 지정됩니다.

피드를 다시 사용 설정할 때 데이터 복구 (백필 가능 여부)

Google SecOps에서 데이터를 채울 수 있는지 여부는 피드가 풀 기반 (지원됨)인지 푸시 기반 (지원되지 않음)인지에 따라 달라집니다.

풀 기반 피드

이러한 피드를 사용하면 Google SecOps가 외부 소스에서 데이터를 가져옵니다. 풀 피드에는 다음이 포함됩니다.

  • Amazon S3, Google Cloud Storage, Azure Blob Storage와 같은 클라우드 스토리지 버킷
  • SFTP 서버
  • Microsoft 365, Okta, Proofpoint와 같은 서드 파티 API

    풀 기반 피드를 다시 사용 설정하면 Google SecOps에서 피드가 사용 중지된 동안 생성된 데이터를 가져올 수 있습니다.

푸시 기반 피드

이러한 피드를 사용하면 외부 시스템이 Google SecOps로 데이터를 '푸시'합니다. 푸시 피드에는 다음이 포함됩니다.

  • HTTPS 웹훅
  • Google Cloud Pub/Sub
  • Amazon Kinesis Data Firehose
  • Bindplane과 같은 직접 API/에이전트 수집

Google SecOps는 푸시 기반 피드에서 데이터 백필을 자동으로 시작할 수 없습니다. 피드가 사용 중지되고 시스템에서 데이터를 푸시하는 동안 Google SecOps는 HTTP 403 Forbidden 오류 또는 일반 4xx 오류를 전송합니다.

시스템에서 Google SecOps로 데이터를 저장하고 다시 전송하지 않으면 데이터가 손실됩니다. 또한 시스템이 '실패 시 삭제' 또는 버퍼 지우기로 설정된 경우 해당 기간 동안 데이터가 영구적으로 손실됩니다. 데이터 손실을 방지하려면 피드가 다시 사용 설정되면 데이터를 버퍼링하고 다시 전송하도록 시스템을 구성해야 합니다. 그런 다음 피드가 재개되면 Google SecOps에서 누락된 데이터를 수집할 수 있습니다.

백필 고려사항

  • 소스 시스템 제한: Google SecOps에서 풀 기반 피드에서 백필할 수 있는 이전 데이터의 양은 소스 시스템에서 데이터를 보관하는 기간과 API에서 허용하는 내용에 따라 제한됩니다. 예를 들어 일부 API는 지난 7일간의 데이터에 대한 액세스만 제공합니다.
  • Google SecOps 버퍼: 자동 복구를 위해 풀 기반 피드의 Google SecOps 내부 버퍼는 최대 90일 동안 데이터를 보유하며 그 후에는 데이터가 삭제됩니다.
  • 테넌트 제한: 개념 증명과 같은 비유료 테넌트의 경우 이전 데이터의 백필에 제한이 있을 수 있습니다.
  • 수집 할당량: 실시간 데이터 수집에 영향을 미치지 않도록 백필 데이터는 라이브 데이터보다 낮은 우선순위로 처리됩니다. 풀 기반 데이터 백필에도 비율 제한이 적용되며, 일반적으로 로그 유형별 테넌트의 버스트 한도의 1/3 (33%)로 제한됩니다. 이를 통해 EDR 에이전트와 같은 중요한 푸시 기반 피드가 부정적인 영향을 받지 않습니다.
  • 동적 비율 제한: 백필이 사용 가능한 모든 풀 할당량을 소모하면 5분 간격의 나머지 시간 동안 수집이 일시중지되고 간격이 다시 시작되면 자동으로 재개됩니다.
  • 클라우드 스토리지: 피드 설정을 사용하여 신규 또는 업데이트된 파일의 필터나 '최대 파일 기간'과 같은 기간 필터와 같은 백필을 제어할 수 있습니다.
  • 대규모 백로그: 풀 기반 피드의 대규모 백로그로 인해 다시 사용 설정 시 문제가 발생하는 경우 Google 지원팀에 문의하여 백로그를 삭제할 수 있습니다. 즉, 피드에서 앞으로 새로운 데이터만 수집하고 누락된 데이터는 다시 채워지지 않습니다.
  • 사용 중지된 피드 수정: 피드가 사용 중지된 동안 피드에 적용된 구성 변경사항은 피드가 다시 사용 설정되는 즉시 적용됩니다.

피드 삭제

피드 페이지에서 기존 피드를 삭제할 수도 있습니다.

  1. 기존 피드 위에 마우스 포인터를 올려놓고 오른쪽 열의 more_vert를 클릭합니다.

  2. 피드 삭제를 클릭합니다. 피드 삭제 창이 열립니다. 피드를 영구 삭제하려면 예, 삭제합니다를 클릭합니다.

맞춤 API 피드의 경우 대기 중인 백로그 데이터 삭제라는 선택사항 체크박스가 있는 대화상자가 표시됩니다.

  • 선택 해제 (기본값): 피드 구성과 사용자 인증 정보가 삭제되지만 대기열 백로그 데이터는 수집을 통해 처리할 수 있습니다.
  • 선택됨: 피드 구성, 사용자 인증 정보, 모든 대기 중 백로그 데이터가 영구적으로 삭제됩니다.

수집 속도 제어

테넌트의 데이터 수집 속도가 특정 기준점에 도달하면 수집 속도가 높은 소스가 다른 데이터 소스의 수집 속도에 영향을 주지 않도록 Google Security Operations에서 새로운 데이터 피드 수집 속도를 제한합니다. 이 경우 지연이 발생하지만 데이터는 손실되지 않습니다. 수집 볼륨과 테넌트의 사용 기록에 따라 기준점이 결정됩니다.

Cloud Customer Care에 문의하여 비율 제한 증가를 요청할 수 있습니다.

실패한 피드 문제 해결

피드 페이지에서 다음과 같이 기존 피드의 소스 유형, 로그 유형, 피드 ID, 상태 등의 세부정보를 확인할 수 있습니다.

  1. 기존 피드 위에 마우스 포인터를 올려놓고 오른쪽 열의 more_vert를 클릭합니다.

  2. 피드 보기를 클릭합니다. 피드 세부정보를 보여주는 대화상자가 나타납니다. 실패한 피드의 경우 세부정보 > 상태에서 오류 세부정보를 확인할 수 있습니다.

피드가 실패한 경우 세부정보에는 오류의 원인과 해결 단계가 포함됩니다.

데이터 피드 작업 시 발생할 수 있는 오류 메시지는 소스 및 수집 오류 표를 참고하세요.

피드 활동을 자세히 분석하고 문제를 해결하려면 Cloud Logging에서 로그를 확인하세요. Cloud Logging으로 피드 활동 분석하기를 참고하세요.

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