인제스트 볼륨 최적화

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

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

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

시작하기 전에

다음 항목이 있거나 다음을 수행해야 합니다.

  • 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 Server 콘솔 버전 1.96.4 이상이 필요합니다.
  • Bindplane Cloud의 경우 인증에 워크로드 아이덴티티 제휴 (WIF)가 지원됩니다. 자체 호스팅 Bindplane 배포에는 서비스 계정 JSON 키 사용자 인증 정보가 필요합니다.
  • 프로세서 노드를 구성하기 위한 Bindplane 관리 콘솔 또는 Google SecOps Data Pipeline 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 에이전트를 사용하여 수집된 로그
  • 피드를 통해 가져온 데이터
  • Ingestion API를 통해 전송된 커스텀 로그

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

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

1단계: 파이프라인 설정

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

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

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

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

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

필터링이 중요하지만 변환 프로세서를 사용하여 보관하는 로그에서 불필요한 대규모 필드를 삭제하고 수정 프로세서를 사용하여 민감한 정보를 null로 설정하는 것도 고려해 보세요.

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

다음 섹션에서는 각 기본 수집 유형에 대해 데이터 처리 파이프라인을 사용하여 필터링하는 방법을 설명합니다.

Google Cloud 로그

  • 업스트림 필터링 (권장사항): 비용을 최대한 절감하려면 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 전문가에게 문의하여 답변을 받으세요.