수집 볼륨 최적화

다음에서 지원:

이 가이드에서는 Google Security Operations 데이터 처리 파이프라인을 구성하는 데 중점을 두어 수집 볼륨을 최적화하는 방법을 설명합니다. 이 기능을 사용하면 소스와 관계없이 완전히 수집되기 전에 데이터를 필터링, 변환, 수정하는 통합된 방법을 제공합니다. 이 방법을 사용하면 데이터 품질과 위협 감지 효율성이 개선됩니다.

이 가이드는 Google SecOps로의 로그 수집을 관리하는 보안 엔지니어, Google SecOps 분석가, 클라우드 관리자를 대상으로 합니다.

필터링되지 않은 대량의 로그를 수집하면 예산과 리소스에 부담이 될 수 있습니다. 비용이 증가하고 검색 및 분석 기능이 느려지며 보안 분석가가 관련 없는 데이터의 홍수 속에서 중요한 알림을 놓칠 가능성이 높아집니다. 효과적인 필터링은 비용 효율적이고 효율적인 Google SecOps 배포에 매우 중요합니다.

시작하기 전에

다음과 같은 Identity and Access Management(IAM) 역할이 있거나 다음을 수행해야 합니다.

  • Identity and Access Management (IAM) 역할: 사전 정의된 Chronicle API Admin 역할 (roles/chronicle.admin) 또는 다음 권한 중 하나가 포함된 커스텀 역할
    • chronicle.logProcessingPipelines.*
    • chronicle.logTypes.get
    • chronicle.logTypes.list
    • chronicle.feeds.get
    • chronicle.feeds.list
    • chronicle.logs.list
  • Bindplane 버전: Bindplane 서버 콘솔 버전 1.96.4 이상이 필요합니다.
  • Bindplane Cloud의 경우 워크로드 아이덴티티 제휴 (WIF)가 인증에 지원됩니다. 자체 호스팅 Bindplane 배포에는 서비스 계정 JSON 키 사용자 인증 정보가 필요합니다.
  • 프로세서 노드를 구성하기 위한 Bindplane 관리 콘솔 또는 Google SecOps 데이터 파이프라인 API에 대한 액세스 권한
  • 볼륨 감소를 위해 필터, 변환, 수정 프로세서를 구성하는 데 필요한 정확한 필드, 로그 유형, 조건을 식별합니다.
  • 수집 방법과 연결된 특정 로그 유형, 수집기 ID (Bindplane 소스의 경우) 또는 피드 이름 (데이터 피드의 경우)을 일치시켜 파이프라인 스트림 입력을 정의합니다.
  • 로그를 Google Cloud 수집하는 경우 데이터가 SecOps 파이프라인에 도달하기 전에 최대한의 비용 절감을 위해 업스트림 필터링을 구현하는 데 필요한 로깅 내보내기 필터를 정의합니다.
  • 로그 데이터 이해:
    • 볼륨이 크거나 가치가 낮은 로그 식별: 현재 수집 측정항목을 분석하여 볼륨과 비용에 가장 큰 영향을 미치는 로그 유형과 소스를 파악합니다. 자세한 내용은 수집 측정항목 개요를 참고하세요.
    • 필터링 기준 결정: 삭제, 변환 또는 수정할 로그를 안정적으로 식별하는 특정 필드, 값, 패턴 (정규 표현식) 또는 조건을 결정합니다.
    • 수집 방법 파악: 각 타겟 로그 소스가 수집되는 방식 (직접, Bindplane, 피드, API)을 이해합니다. 이는 파이프라인 스트림을 구성하는 방식에 영향을 미칩니다.

주요 용어

  • 데이터 처리 파이프라인: 로그 데이터가 저장되고 색인이 생성되기 전에 도착할 때 필터링, 변환, 수정하는 데 사용되는 기능입니다.
  • 필터/필터링: 볼륨 최적화를 위한 기본 기능으로, 보안 분석에 필요하지 않은 이벤트를 선택적으로 삭제하는 조건을 정의합니다.
  • 변환: 정규화된 도메인 이름 (FQDN)을 삭제하거나 이벤트 내에서 상세 필드를 삭제하는 등 사용 편의성을 높이기 위해 로그 형식을 수정하는 데 사용되는 기능입니다.
  • Redact: 로그가 저장되기 전에 로그에서 민감한 정보를 마스크 처리하거나 완전히 삭제하여 규정 준수 및 개인 정보 보호에 도움이 되는 기능입니다.
  • Bindplane 에이전트: 온프레미스 시스템 또는 기타 클라우드 시스템에서 수집된 로그의 수집 방법입니다.
  • 피드: Cloud Storage, Amazon S3 또는 서드 파티 API와 같은 소스에서 가져온 데이터의 수집 방법입니다.
  • 수집 API: 데이터 처리 파이프라인을 사용하여 서버 측 필터링을 허용하는 커스텀 로그 데이터를 전송하는 방법입니다.
  • 업스트림 필터링: 최적의 비용 절감을 위해 로깅 내보내기 필터를 사용하여 소스에서 로그를 Google Cloud 필터링하는 권장사항입니다.
  • 스트림: 데이터 처리 파이프라인의 입력으로 사용되는 로그 유형 및 수집 소스 (예: 피드 또는 API)로 정의된 특정 데이터 흐름입니다.
  • 프로세서 노드: 데이터를 순차적으로 조작하는 하나 이상의 프로세서 (필터, 변환 또는 수정 작업)가 포함된 파이프라인 내의 구성요소입니다.
  • 대상: 데이터 처리 파이프라인의 엔드포인트로, 일반적으로 처리된 데이터가 최종 수집 및 분석을 위해 전송되는 Google SecOps 인스턴스입니다.

최적화를 위해 데이터 처리 파이프라인 사용

Google SecOps의 데이터 처리 파이프라인은 데이터 수집 프로세스에 대한 강력한 사전 파싱 제어를 제공합니다. 데이터가 저장되고 색인이 생성되기 전에 도착할 때 로그에 적용되는 규칙과 작업을 정의할 수 있습니다. 자세한 내용은 데이터 처리 파이프라인 설정 및 관리를 참고하세요.

주요 기능

  • 필터: 볼륨 최적화를 위한 기본 초점입니다. 원시 로그 콘텐츠, 속성 또는 정규 표현식을 사용하여 보안 분석에 필요하지 않은 이벤트를 선택적으로 삭제하는 조건을 정의할 수 있습니다. 이는 노이즈와 비용을 줄이는 데 중요합니다.
  • 변환: 사용 편의성을 높이거나 이벤트 내에서 불필요한 데이터를 삭제하도록 로그 형식을 수정합니다. 예로는 호스트 이름에서 FQDN 삭제, JSON 페이로드 파싱 및 재구성, 상세하지만 관련 없는 필드 삭제가 있습니다.
  • 수정: 로그가 저장되기 전에 로그에서 개인 식별 정보 (PII)와 같은 민감한 정보를 마스크 처리하거나 완전히 삭제하여 규정 준수 및 개인 정보 보호 요건을 충족하는 데 도움이 됩니다.

범용 적용 가능성

데이터 처리 파이프라인의 주요 이점은 모든 수집 방법의 데이터에 적용할 수 있다는 것입니다. 이를 통해 다음과 같은 일관된 필터링 레이어를 제공합니다.

  • Google Cloud 기본 제공 로그
  • Bindplane 에이전트를 사용하여 수집된 로그
  • 피드를 통해 가져온 데이터
  • 수집 API를 통해 전송된 커스텀 로그

자세한 내용은 이 가이드의 메서드별 필터링 전략 섹션을 참고하세요.

데이터 처리 파이프라인으로 필터링 구현

1단계: 파이프라인 설정

Bindplane 관리 콘솔을 통해 또는 공개 Google SecOps 데이터 파이프라인 API를 사용하여 데이터 처리 파이프라인을 구성하고 관리할 수 있습니다. 이를 통해 스트림 (입력)을 정의하고, 프로세서 노드 (필터, 변환, 수정)를 구성하고, 파이프라인 배포를 관리할 수 있습니다.

포괄적인 설정 안내는 데이터 처리 파이프라인 설정 및 관리를 참고하세요.

2단계: 필터링을 위한 프로세서 구성

파이프라인 내에서 노드에 프로세서를 추가할 수 있습니다. 볼륨을 줄이려면 주로 필터 프로세서를 사용해야 합니다. 조건 또는 정규 표현식을 기반으로 로그를 삭제하도록 이러한 프로세서를 구성할 수 있습니다. OTTL (OpenTelemetry 변환 언어) 구문을 사용하여 커스텀 파이프라인 조건 및 문을 구성합니다.

  • 조건: 로그 데이터의 필드 또는 속성을 평가합니다.
  • 정규 표현식: 원시 로그 메시지 내에서 패턴을 일치시킵니다.
  • OTTL 예: 문은 set(attributes["labels.myLabel.value"], "myValue")입니다.

필터링이 중요하지만 변환 프로세서를 사용하여 유지하는 로그에서 크고 불필요한 필드를 삭제하고 수정 프로세서를 사용하여 민감한 데이터를 무효화할 수도 있습니다.

3단계: 메서드별 필터링 전략

다음 섹션에서는 각 기본 수집 유형에 대한 데이터 처리 파이프라인으로 필터링에 접근하는 방법을 설명합니다.

Google Cloud 로그

  • 업스트림 필터링 (권장사항): 최적의 비용 절감을 위해 Google은 Cloud Logging 내보내기 필터를 사용하여 소스에서 로그를 필터링하는 것이 좋습니다. Google Cloud 이렇게 하면 원치 않는 로그가 Google SecOps로 전송되는 것을 방지할 수 있습니다. 필요한 경우 데이터 처리 파이프라인을 사용하여 추가 필터링을 할 수 있습니다. 자세한 내용은 데이터 수집 Google Cloud 가이드, 특히 내보내기 필터 설정 맞춤설정 섹션을 참고하세요.

  • 파이프라인 애플리케이션: 적절한 Google Cloud 로그 유형 및 수집 방법(직접 또는 클라우드 네이티브)을 선택하여 데이터 처리 파이프라인을 구성합니다. 콘텐츠를 기반으로 원치 않는 로그를 삭제하도록 필터 프로세서를 정의합니다.

Bindplane 에이전트

온프레미스 시스템 또는 기타 클라우드 시스템에서 Bindplane 에이전트가 수집한 로그는 데이터 처리 파이프라인을 사용하여 필터링할 수 있습니다. Bindplane 소스와 연결된 로그 유형 및 수집기 ID와 일치하도록 스트림을 구성합니다. 자세한 내용은 Google SecOps에서 Bindplane 사용을 참고하세요.

데이터 피드

피드 (예: Cloud Storage, Amazon S3 또는 서드 파티 API)를 사용하여 수집된 데이터의 경우 파이프라인 스트림을 구성할 때 피드 이름과 로그 유형을 선택하여 데이터 처리 파이프라인 필터를 적용할 수 있습니다. 자세한 내용은 피드 작업 가이드를 참고하세요.

Chronicle API 수집 방법

Chronicle API 수집 방법을 사용하여 데이터를 전송하는 경우에도 데이터 처리 파이프라인을 활용할 수 있습니다. API 호출에서 사용하는 로그 유형과 일치하도록 파이프라인 스트림을 구성합니다. 이렇게 하면 커스텀 로그 스트림의 서버 측 필터링이 가능합니다. 자세한 내용은 Chronicle API 수집 방법 가이드를 참고하세요.

권장사항

  • 가능한 경우 업스트림 필터링: 에서 언급한 대로 Google Cloud항상 소스에 최대한 가까운 로그를 필터링합니다. 이는 데이터 전송 및 처리 오버헤드를 줄이므로 가장 비용 효율적인 접근 방식입니다.
  • 구체적으로 지정: 좁고 잘 정의된 필터부터 시작하여 알려진 볼륨이 크고 가치가 낮은 로그를 제외합니다. 유용한 데이터를 실수로 삭제할 수 있는 지나치게 광범위한 필터는 사용하지 않도록 합니다.
  • 반복 및 개선: 필터의 효과를 정기적으로 검토합니다. 올바른 이벤트를 포착하고 있나요? 필터링해야 할 새로운 노이즈가 있나요?
  • 필터 문서화: 특히 복잡한 정규 표현식 또는 조건부 로직의 경우 어떤 필터가 적용되어 있는지, 그 이유는 무엇인지 기록해 둡니다.

검증 및 테스트

  • 테스트: 먼저 비프로덕션 환경에서 또는 소규모 데이터 하위 집합으로 필터를 테스트해야 합니다.
  • 필터 검증: Bindplane 콘솔의 파이프라인 편집기 내에서 테스트 기능을 사용합니다. 이렇게 하면 샘플 로그를 입력하고 프로세서가 적용된 후 출력을 확인하여 필터가 예상대로 작동하는지 확인할 수 있습니다.
  • 수집 모니터링: 파이프라인을 배포한 후 Google SecOps에서 수집 대시보드를 모니터링하여 데이터 볼륨과 비용에 미치는 영향을 관찰합니다. 자세한 내용은 수집 측정항목 개요를 참고하세요.
  • 구성 보기: Google SecOps UI의 SIEM 설정 > 데이터 처리 에서 모든 구성을 볼 수 있습니다.
  • 외부 관리: 구성을 검색하고 'Bindplane에서 열기'를 클릭하여 고급 관리를 위해 Bindplane 콘솔로 바로 이동할 수 있습니다.

제한사항

  • 서비스 한도: 지나치게 복잡한 정규 표현식 또는 파이프라인당 많은 수의 프로세서는 성능에 영향을 미치거나 한도가 적용될 수 있습니다. 서비스 한도에서 Google SecOps 한도를 확인해야 합니다.
  • Google SecOps 패키지: Google SecOps 패키지의 기능과 기능을 알고 있어야 합니다. 자세한 내용은 Google SecOps 패키지를 참고하세요.
  • 재사용성: 강력하지만 한 로그 유형 또는 소스의 파이프라인 구성은 조정 없이 다른 로그 유형 또는 소스에 직접 재사용할 수 없습니다.
  • 최대 프로세서: 파이프라인당 최대 10개의 프로세서를 정의합니다.
  • 정규 표현식 성능: 정규 표현식 일치를 과도하게 사용하지 마세요. 시간 초과로 인해 파이프라인 생성 또는 배포가 실패할 수 있습니다. 데이터를 JSON으로 파싱하고 특정 필드로 필터링하는 것이 좋습니다.
  • 스트림 연결 제약조건: 동일한 로그 유형의 여러 피드에 대해 서로 다른 파이프라인을 만들 수 있지만 정확히 동일한 스트림 정의 (예: 동일한 피드 또는 동일한 로그 유형 캐치올)는 둘 이상의 활성 파이프라인과 연결할 수 없습니다. 로그 유형을 모든 수집 방법 으로 설정하면 캐치올 역할을 하며 해당 로그 유형의 특정 피드에 대해 다른 파이프라인을 구성할 수 없습니다.

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