Google SecOps와 함께 Bindplane 사용
이 문서에서는 Google Security Operations용 Bindplane을 설명합니다.
Bindplane은 모든 소스의 로그를 수집, 미세 조정하여 Google SecOps로 내보낼 수 있는 원격 분석 파이프라인입니다.
Bindplane은 Google 전용 버전 2개를 제공합니다.
Bindplane에는 다음과 같은 주요 구성요소가 포함됩니다.
Bindplane 수집기 OpenTelemetry (OTel) Collector를 기반으로 하는 오픈소스 에이전트입니다. Microsoft Windows 이벤트 로그를 비롯한 다양한 소스에서 로그를 수집하여 Google SecOps에 전송합니다. 온프레미스 또는 클라우드에 수집기를 설치할 수 있습니다.
이 구성요소를 OpenTelemetry용 Bindplane 배포 (BDOT) 수집기, bindplane 에이전트, 수집 에이전트, 수집기 또는 에이전트라고도 합니다.
Bindplane 서버. OTel 수집기 배포를 관리하기 위한 포괄적이고 통합된 플랫폼입니다. 이러한 배포는 Google SecOps 및 Google Cloud에 있을 수 있습니다. 많은 Google SecOps 고객이 Bindplane Server를 사용하지만 사용은 선택사항입니다. Bindplane Server는 온프레미스 또는 Bindplane 클라우드에서 실행할 수 있습니다. 서버에 대한 자세한 내용은 Bindplane 서버를 참고하세요.
이 구성요소를 Bindplane 관측 가능성 파이프라인 (OP) 관리 콘솔 또는 Bindplane 관리 콘솔이라고도 합니다.
Bindplane의 Google 버전
Bindplane은 Google을 위해 특별히 두 가지 버전(Bindplane(Google 버전) 및 Bindplane Enterprise(Google 버전))을 제공합니다.
Bindplane (Google 버전)
Bindplane (Google 버전)은 모든 Google SecOps 고객에게 제공됩니다.
Bindplane 클라우드에서 Bindplane (Google 버전)을 셀프 서비스로 사용할 수 있습니다.
Bindplane (Google 버전)을 설치하고 자체 호스팅하거나 온프레미스 Bindplane 서버의 키를 생성하려면 Bindplane (Google 버전)을 참고하세요.
Bindplane Enterprise (Google 버전): Google SecOps Enterprise Plus 고객용
Bindplane Enterprise (Google 버전)는 Google SecOps Enterprise Plus 고객에게 제공됩니다.
대규모 배포에는 Bindplane Enterprise (Google 버전)가 권장됩니다.
Google 계정팀에 문의하여 Bindplane Enterprise (Google 버전)의 라이선스 키를 받으세요.
Bindplane Google 버전의 차이점
다음 표에는 Bindplane Google 버전의 차이점이 나와 있습니다.
주제/기능 | Bindplane (Google 버전) | Bindplane Enterprise (Google 버전) |
---|---|---|
비용 | 모든 Google SecOps 고객에게 추가 비용 없이 제공 | Google SecOps Enterprise Plus 고객에게 무료로 제공 |
라우팅/대상 | Google만 해당(Google SecOps, Cloud Logging, BigQuery, Google SecOps를 통한 Cloud Storage 포함) | Google(SIEM 마이그레이션을 위한 Google 이외의 대상으로의 라우팅 12개월 포함) |
필터링 | 정규 표현식을 사용한 기본 필터 | 고급 필터링 프로세서 (예: 조건, 필드, 심각도별 필터링), 데이터 감소, 로그 샘플링, 중복 제거 |
수정 | 해당 사항 없음 | PII 마스킹 |
혁신 | 필드 추가, 필드 이동, 데이터 파싱 (KV, JSON, CSV, XML, 타임스탬프, 정규식으로 파싱), 필드 이름 바꾸기, 이벤트 브레이커 | Bindplane (Google 버전)에서 지원되는 모든 기능 더하기 삭제 필드, 빈 값 삭제, 병합 |
일반 플랫폼 수준 기능 | 게이트웨이 (수집기의 집계 데이터), Bindplane 수집기, 온프레미스 또는 클라우드 호스팅 Bindplane 서버 (Bindplane 관리 레이어), 모든 소스, Google SecOps 프로세서를 통한 자동 호스트 모니터링, 영구 대기열, 원격 분석 보강, 고가용성, RBAC, Google SecOps 수집 API 지원, 사용자 인증 정보 난독화, 수집기 그룹화, 동적 로그 유형 할당을 비롯한 고급 플릿 관리 | Bindplane (Google 버전)에서 지원되는 모든 기능 |
Bindplane 수집기 아키텍처
Bindplane은 BDOT 수집기(일반적으로 수집기라고 함)를 사용하여 개방형 에이전트 관리 프로토콜(OpAMP)로 원격 분석 관리를 표준화합니다. Bindplane을 사용하여 맞춤 OpenTelemetry Collector 배포를 만들고 관리할 수도 있습니다.
수집기는 외부 종속 항목이 없는 경량 웹 서버로 Linux 또는 Docker에서 실행할 수 있습니다.
Bindplane OpenTelemetry 수집기의 배포 아키텍처에 대해 자세히 알아보려면 배포를 참고하세요.
다음 섹션에서는 사용 가능한 아키텍처 옵션을 설명합니다.
수집기가 게이트웨이 역할을 하는 수집기에 로그를 전송합니다.
대규모 배포의 경우 게이트웨이 역할을 하는 Bindplane Enterprise (Google 버전) 수집기를 사용하는 것이 좋습니다. 이러한 게이트웨이는 네트워크를 통해 다른 수집기에서 원격 분석을 수신하고, 선택적으로 추가 처리를 실행하고, 데이터를 Google SecOps로 라우팅합니다.
게이트웨이 역할을 하는 수집기는 다른 모든 수집기와 동일한 바이너리를 사용합니다.
다음 다이어그램은 게이트웨이 역할을 하는 수집기로 로그를 전송하는 수집기를 보여줍니다.
수집기가 Google SecOps 수집 API로 로그를 직접 전송
다음 다이어그램은 수집기가 로그를 Google SecOps 수집 API로 직접 전송하는 것을 보여줍니다.
수집기가 Cloud Logging에 직접 로그를 전송함
다음 다이어그램은 수집기가 Cloud Logging으로 직접 로그를 전송하는 방식을 보여줍니다.
수집기가 여러 대상으로 로그를 전송함
다음 다이어그램은 여러 대상에 로그를 전송하는 수집기를 보여줍니다.
Bindplane 서버
Bindplane 서버는 다음과 같은 주요 기능을 제공합니다.
- 중앙 집중식 관리 서버를 사용하면 Google Cloud에서 모든 OTel 수집기 배포를 관리할 수 있습니다. 각 배포의 상태를 확인하고 수집기 시작, 중지, 다시 시작과 같은 일반적인 관리 작업을 실행할 수 있습니다.
- 실시간 모니터링 서버는 OTel 수집기 배포를 실시간으로 모니터링합니다. CPU 사용량, 메모리 사용량, 처리량과 같은 측정항목을 추적할 수 있습니다. 로그와 트레이스를 확인하여 문제를 해결할 수도 있습니다.
- 알림 및 알림 서버를 사용하면 수집기가 다운되거나 측정항목 기준점이 초과되는 등의 중요한 이벤트가 발생할 때를 대비하여 경고 및 알림을 설정할 수 있습니다.
- 구성 관리 서버를 사용하면 OTel 수집기의 구성을 중앙에서 관리할 수 있습니다. 구성 파일을 수정하고, 환경 변수를 설정하고, 모든 배포에 보안 정책을 적용할 수 있습니다.
- Google Cloud와 통합 Google Cloud 에서 OTel 수집기 배포를 생성 및 관리하고 서버를 사용하여 Google Cloud 리소스에 액세스할 수 있습니다.
Bindplane은 클라우드 및 온프레미스 배포 옵션을 제공합니다. 자세한 내용은 Bindplane 서버 사용을 참고하세요.
기술 요구사항 및 권장사항
이 섹션에서는 Google SecOps로 Bindplane을 설치하고 실행하기 위한 기술 요구사항과 권장사항을 설명합니다.
대역폭 요구사항
Bindplane은 다음 항목의 네트워크 연결을 유지합니다.
- 수집기 관리
- 수집기 처리량 측정
- 명령줄 및 웹 사용자 인터페이스
연결 요구사항
Bindplane은 기본적으로 포트 3001에서 리슨합니다. 이 포트는 구성할 수 있습니다.
Bindplane 포트는 다음 용도로 사용됩니다.
- OpAMP (WebSocket)를 사용한 수집기 명령 및 제어
- 수집기 처리량 측정 요청 (HTTP
POST
요청) - 브라우저 및 CLI 사용자 (HTTP 및 WebSocket)
수집기는 OpAMP (WebSocket) 및 처리량 측정 (HTTP)을 위해 Bindplane에 대한 연결을 시작할 수 있어야 합니다.
Bindplane은 수집기에 대한 연결을 시작하지 않습니다. Bindplane이 수집기 네트워크에 연결되지 않도록 방화벽을 구성할 수 있지만 수집기 네트워크는 구성된 포트에서 Bindplane에 연결할 수 있어야 합니다.
Bindplane 수집기 일반 기술 요구사항
Bindplane 수집기의 일반적인 기술 요구사항에 대해 알아보려면 다음을 참고하세요.
수집기 리소스 요구사항
Bindplane의 리소스 요구사항은 관리되는 수집기 수에 따라 다릅니다. 관리형 수집기 수가 증가하면 CPU, 메모리, 디스크 처리량/IOPS, 네트워크 소비도 증가합니다.
CPU, 메모리, 스토리지 용량 크기 조정에는 다음 표를 사용하세요.
수집기 수 | Bindplane 노드 | 내결함성 | CPU 코어 | 메모리 | 데이터베이스 |
---|---|---|---|---|---|
1~100명 | 1 | 해당 사항 없음 | 2 | 4GB | bbolt |
100~25,000 | 1 | 해당 사항 없음 | 4 | 16GB | postgres |
1~60,000 | 3 | 1 | 2 | 8GB | postgres |
60,001~125,000명 | 5 | 1 | 2 | 8GB | postgres |
125,001~250,000명 | 10 | 2 | 2 | 8GB | postgres |
설치 및 배포 계획
다음 섹션에는 Bindplane 배포를 계획할 때 고려해야 하는 권장사항과 추천이 포함되어 있습니다.
확장 및 내결함성 고려
수평 확장은 내결함성을 제공하고 내보내기 프로그램 병목 현상을 제거할 수 있으므로 수평 확장이 더 좋습니다.
게이트웨이 모드에서 Bindplane 수집기를 실행할 때는 내결함성 및 수평 확장을 제공하기 위해 부하 분산기와 페어링하는 것이 좋습니다.
필요한 수집기 수 계산
워크로드에 필요한 수집기 수를 계산할 때는 예상 처리량 또는 로그 비율을 고려하고 다음 표를 사용하세요. 이 표에서는 각 수집기에 CPU 코어가 4개 있고 메모리가 16GB 있다고 가정합니다. 표에는 프로세서가 포함된 계산이 포함되어 있지 않습니다. 프로세서를 추가하면 컴퓨팅 요구사항이 증가합니다.
원격 분석 처리량 | 초당 로그 수 | 수집기 |
---|---|---|
5 GB/m | 250,000 | 2 |
10 GB/m | 500,000 | 3 |
20 GB/m | 1,000,000 | 5 |
100GB/월 | 5,000,000 | 25 |
내결함성을 위해 수집기 플릿을 과도하게 프로비저닝
내결함성을 보장하기 위해 수집기 플릿을 과도하게 프로비저닝합니다. 하나 이상의 수집기 시스템에 장애가 발생하거나 유지보수를 위해 오프라인 상태가 되는 경우 나머지 수집기가 원격 분석 처리량을 관리할 수 있는 충분한 용량을 갖춰야 합니다.
고정된 수의 수집기를 사용하는 경우 CPU와 메모리의 수직 확장을 구현하여 처리량을 늘릴 수 있습니다.
처리 오버헤드 오프로드
일반적으로 수집기가 최대한 적은 작업을 실행하도록 하는 것이 좋습니다. 처리 요구사항이 많은 경우 해당 처리를 게이트웨이 수집기 플릿으로 오프로드하는 것이 유용할 수 있습니다. 예를 들어 비용이 많이 드는 정규 표현식 작업으로 원격 분석을 필터링하는 대신 게이트웨이 수집기가 이 작업을 실행하도록 할 수 있습니다. 일반적으로 게이트웨이 수집기는 전용 시스템에서 실행됩니다. 데이터베이스 서버에서 실행될 수 있는 비 게이트웨이 수집기와 달리 동일한 시스템에서 실행되는 다른 서비스의 컴퓨팅 성능을 사용하지 않으므로 처리 오버헤드가 정당화됩니다.
게이트웨이 모드 권장사항
게이트웨이 모드에서 Bindplane 수집기를 실행할 때는 다음 권장사항에 따라 배포를 계획하는 것이 좋습니다.
- 부하 분산기 뒤에 수집기를 2개 이상 배치합니다.
- 각 수집기에는 코어가 2개 이상 있어야 합니다.
- 각 수집기에는 최소 8GB의 메모리가 있어야 합니다.
- 각 수집기에는 영구 대기열에 사용할 수 있는 공간이 60GB 있어야 합니다.
필요한 경우 부하 분산기 사용
고가용성 모드에서 Bindplane을 운영하는 경우 부하 분산기가 필요합니다.
게이트웨이 모드에서 Bindplane 수집기를 실행할 때는 성능과 중복성을 높이기 위해 부하 분산기를 사용하세요. 부하 분산을 사용하면 게이트웨이 Fleet을 수평으로 확장하고 중단 없이 장애를 견딜 수 있습니다.
Bindplane 수집기는 다양한 부하 분산기와 함께 작동할 수 있습니다.
자세한 내용은 부하 분산기를 참고하세요.
부하 분산 포트 및 프로토콜
Bindplane은 기본적으로 포트 3001에서 리슨합니다.
OpenTelemetry에서 다양한 네트워크 기반 수신기를 지원하려면 부하 분산기가 다음을 지원해야 합니다.
- TCP/UDP 전송 프로토콜
- HTTP 및 gRPC 애플리케이션 프로토콜
부하 분산 크기 조정
Bindplane 노드는 최대 내결함성을 위해 30,000개 이하의 수집기를 관리해야 합니다. 각 수집기는 Bindplane에 대한 두 개의 연결을 엽니다 (OpAMP 원격 관리를 위한 연결 하나와 처리량 측정항목 게시를 위한 연결 하나). 이 한도는 대부분의 부하 분산기에서 적용하는 백엔드 인스턴스당 연결 한도(약 65,535개)를 초과하지 않도록 하는 데 도움이 됩니다.
조직에 수집기가 100,000개 있는 경우 클러스터 크기가 3이면 충분하지 않습니다. 각 노드는 약 33,000개의 수집기를 담당하므로 Bindplane 인스턴스당 66,000개의 TCP 연결이 됩니다. 유지보수를 위해 한 노드가 오프라인 상태가 되면 이 상황은 더욱 악화됩니다. 각 나머지 Bindplane 인스턴스가 50,000개의 수집기 또는 100,000개의 TCP 연결을 관리하기 때문입니다.
부하 분산 크기 조정 권장사항
- 상태 점검 구현 수집기가 트래픽을 수신할 준비가 되었는지 확인하도록 부하 분산기를 구성합니다.
- 연결을 균등하게 분배 연결은 수집기 간에 균등하게 분산되어야 합니다.
필수 프로토콜 지원 OpenTelemetry에서 다양한 네트워크 기반 수신기를 지원하려면 부하 분산기가 다음을 지원해야 합니다.
- TCP/UDP 전송 프로토콜
- HTTP 및 gRPC 애플리케이션 프로토콜
자세한 내용은 수집기 복원력을 참고하세요.
소스 유형 부하 분산
네트워크를 통해 원격 시스템에서 원격 분석을 수신하는 모든 소스 유형은 부하 분산에 적합한 후보입니다. 여기에는 다음이 포함됩니다.
- OTLP
- Syslog
- TCP/UDP
- Splunk HEC
- Fluent Forward
프로덕션 환경에서 고가용성 모드 사용
단일 인스턴스 또는 다중 인스턴스 구성으로 Bindplane 인스턴스를 배포할 수 있습니다. 고가용성 (HA)과 복원력이 필요한 프로덕션 배포의 경우 다중 인스턴스 (HA) 배포 모델을 사용하는 것이 좋습니다.
Bindplane이 25,000개 이상의 수집기를 관리하는 경우 고가용성 (HA) 모드에서 Bindplane을 운영하는 것이 좋습니다.
Bindplane의 HA에 대해 알아보려면 고가용성을 참고하세요.
HA용 수집기 및 Bindplane 서버 수 계산
HA 모드에서 Bindplane을 운영할 때는 각 Bindplane 서버가 처리할 수집기 수를 고려해야 합니다.
Bindplane 인스턴스의 총수에서 유지보수로 인해 사용할 수 없게 될 것으로 예상되는 최대 노드 수를 뺍니다. 노드 장애 발생 시 각 노드가 30,000개 이하의 수집기를 관리해야 합니다.
HA용 Postgres
HA 모드에서 Bindplane을 운영하는 경우 Postgres가 필수입니다.
HA용 Prometheus
HA 모드에서 Bindplane을 운영하는 경우 Prometheus가 필요합니다.
자세한 내용은 Prometheus를 참고하세요.
HA용 이벤트 버스
Bindplane은 이벤트 버스를 사용하여 Bindplane 내 구성요소 간에 통신합니다. HA 모드에서 Bindplane을 운영할 때 이벤트 버스를 사용하여 Bindplane 서버 간에 이벤트를 보낼 수 있습니다.
자세한 내용은 이벤트 버스를 참고하세요.
테스트 환경 또는 개념 증명을 위해 단일 인스턴스 배포 사용
테스트 환경이나 개념 증명의 경우 단일 인스턴스 배포를 사용하는 것이 좋습니다.
자세한 내용은 단일 인스턴스를 참고하세요.
백엔드 사용자 인증 정보 격리
모든 수집기 시스템에 사용자 인증 정보를 배포하는 대신 게이트웨이 수집기에만 사용자 인증 정보를 유지할 수 있습니다. 이렇게 하면 사용자 인증 정보 순환이 간소화되고 사용자 인증 정보 배포를 시스템의 하위 집합으로 제한하여 보안 공격 표면이 줄어듭니다.
게이트웨이 수집기 방화벽
내부 네트워크에서 방화벽으로 보호되는 경계 네트워크 내에 게이트웨이 수집기를 배치할 수 있습니다. 다른 수집기가 게이트웨이 수집기로 데이터를 전달하도록 허용하면서 게이트웨이 수집기가 애플리케이션 네트워크에 액세스하지 못하도록 네트워크를 구성할 수 있습니다. 이렇게 하면 엔드포인트에 인터넷 직접 액세스 권한을 부여하지 않고도 클라우드 기반 백엔드로 원격 분석을 전송할 수 있습니다.
방화벽은 구성된 포트에서 Bindplane에 도달하는 HTTP 트래픽을 허용해야 합니다.
방화벽 구성 확인
수집기와 인터넷 사이에 있는 방화벽이나 인증된 프록시를 사용하려면 다음 호스트에 대한 액세스 열기 규칙이 필요합니다.
연결 유형 | 대상 | 포트 |
---|---|---|
TCP | malachiteingestion-pa.googleapis.com | 443 |
TCP | asia-northeast1-malachiteingestion-pa.googleapis.com | 443 |
TCP | asia-south1-malachiteingestion-pa.googleapis.com | 443 |
TCP | asia-southeast1-malachiteingestion-pa.googleapis.com | 443 |
TCP | australia-southeast1-malachiteingestion-pa.googleapis.com | 443 |
TCP | europe-malachiteingestion-pa.googleapis.com | 443 |
TCP | europe-west2-malachiteingestion-pa.googleapis.com | 443 |
TCP | europe-west3-malachiteingestion-pa.googleapis.com | 443 |
TCP | europe-west6-malachiteingestion-pa.googleapis.com | 443 |
TCP | europe-west12-malachiteingestion-pa.googleapis.com | 443 |
TCP | me-central1-malachiteingestion-pa.googleapis.com | 443 |
TCP | me-central2-malachiteingestion-pa.googleapis.com | 443 |
TCP | me-west1-malachiteingestion-pa.googleapis.com | 443 |
TCP | northamerica-northeast2-malachiteingestion-pa.googleapis.com | 443 |
TCP | accounts.google.com | 443 |
TCP | oauth2.googleapis.com | 443 |
프로덕션 배포에 PostgreSQL 사용
Postgres는 Bindplane의 프로덕션 배포에 필요합니다.
Postgres는 HA 모드에서 Bindplane을 작동하기 위한 필수 요건입니다.
CPU 코어 수와 사용 가능한 메모리는 일반적으로 PostgreSQL 스토리지 백엔드의 성능을 제한합니다. 솔리드 스테이트 드라이브 (SSD)와 같이 지연 시간이 짧고 처리량이 높은 스토리지를 사용하여 PostgreSQL 스토리지를 지원하는 것이 좋습니다.
수집기 수 | CPU 코어 | 메모리 |
---|---|---|
1~60,000 | 4 | 16GB |
60,001~125,000명 | 8 | 32GB |
125,001~250,000명 | 16 | 64GB |
자세한 내용은 다음을 참조하세요.
적절한 인증 구현
Bindplane은 다음 프로토콜 및 서비스를 사용한 인증을 지원합니다. 올바르게 구현되었는지 확인하세요.
- Azure Entra LDAP 자세한 내용은 Azure LDAP 및 Bindplane 인증 유형 변경을 참고하세요.
- LDAP.
- OpenID Connect(OIDC).
- 지역
- SAML
- Postgres TLS 자세한 내용은 Postgres TLS를 참고하세요.
- Kubernetes 자세한 내용은 GKE 워크로드 아이덴티티를 참고하세요.
Bindplane 서버 사용
대부분의 Google SecOps 고객은 Bindplane 서버를 사용하지만 사용은 선택사항입니다. Bindplane 서버를 설치하는 경우 storage.googleapis.com
에 액세스할 수 있어야 합니다. 수집기만 설치하는 경우에는 이 액세스 권한이 필요하지 않습니다.
로그를 표준화하고 Google SecOps로 내보내도록 Bindplane 서버를 구성하는 방법을 보여주는 데모를 보려면 [이 페이지](https://bindplane.com/use-case-demo)로 이동한 후 Google SecOps 구성을 선택하세요.
Bindplane Cloud 서버 사용
Bindplane Cloud는 Google 고객에게 제공됩니다.
Google 버전에 로그인합니다.
Bindplane Cloud Server와 관련된 문제는 Bindplane 지원팀에 문의하세요. 온프레미스 Bindplane Server와 관련된 문제는 Google SecOps 지원팀에 문의하세요.
Google Cloud에서 Bindplane 서버 사용
Google Cloud에서 Bindplane 서버를 실행하는 방법에 관한 자세한 내용은 Bindplane Enterprise Edition을 참고하세요.
Bindplane 온프레미스 서버 사용
온프레미스 Bindplane 서버 사용에는 기존 Google Cloud 서비스 약관이 적용됩니다.
Linux에 온프레미스 서버 설치
스크립트를 실행하거나 (권장) 바이너리 파일을 다운로드하고 수동으로 설치하여 Linux에 온프레미스 Bindplane 서버를 설치할 수 있습니다. 자세한 내용은 Bindplane 서버 설치를 참고하세요.
스크립트를 사용하여 Linux에 온프레미스 Bindplane 서버를 설치하려면 다음 단계를 따르세요.
다음 스크립트를 실행합니다.
curl -fsSlL https://storage.googleapis.com/bindplane-op-releases/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh
안내에 따라 서버를 초기화합니다.
바이너리 파일을 사용하여 Linux에 온프레미스 Bindplane 서버를 설치하려면 다음을 실행하세요.
다음 파일 중 하나를 다운로드합니다.
Bindplane 서버 구성의 안내에 따라 구성 파일을 업데이트합니다.
지원되는 Linux 배포판:
- Red Hat, Centos, Oracle Linux 7, 8, 9
- Debian 11 및 12
- Ubuntu LTS 20.04 및 22.04
- SUSE Linux 12 및 15
- Alma 및 Rocky Linux
자세한 내용은 다음을 참조하세요.
Docker 온프레미스 배포
자세한 내용은 Bindplane 서버 설치를 참고하세요.
Bindplane Docker 컨테이너 이미지는 다음 위치에서 찾을 수 있습니다.
- GitHub 패키지:
ghcr.io/observiq/Bindplane-ee
- Google 아티팩트 저장소:
us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
- Docker hub:
observiq/bindplane-ee
컨테이너 이미지에는 출시 버전이 태그로 지정됩니다. 예를 들어 출시 v1.35.0에는 observiq/bindplane-ee:1.35.0
태그가 지정됩니다.
Bindplane 수집기 설치
이 섹션에서는 다양한 시스템에 Google SecOps용 Bindplane 수집기를 설치하는 방법을 설명합니다.
수집기는 일반적으로 최소한의 리소스를 사용합니다. 하지만 대량의 로그를 처리할 때는 다른 서비스에 영향을 주지 않도록 리소스 소비량에 유의해야 합니다. 자세한 내용은 기술 요구사항 및 권장사항, 설치 및 배포 계획, 에이전트 크기 조정 및 확장을 참고하세요.
수집기 (즉, OTel 에이전트)를 설치하는 방법을 알아보려면 Bindplane OTel Collector를 참고하세요.
GitHub 문서 bindplane-otel-collector를 참고할 수도 있습니다.
수집기를 설치하려면 다음이 필요합니다.
Google SecOps 수집 인증 파일
인증 파일을 다운로드하려면 다음 단계를 따르세요.
- Google SecOps 콘솔을 엽니다.
- SIEM 설정 > 수집 에이전트로 이동합니다.
- Google SecOps 수집 인증 파일을 다운로드합니다.
Google SecOps 고객 ID
고객 ID를 찾으려면 다음 단계를 따르세요.
- Google SecOps 콘솔을 엽니다.
- SIEM 설정 > 프로필로 이동합니다.
- 조직 세부정보 섹션에서 고객 ID를 복사합니다.
Windows 2012 SP2 이상 또는 systemd가 있는 Linux 호스트
인터넷 연결
GitHub 액세스
배포 도구
이 섹션에서는 Bindplane의 배포 도구에 대해 설명합니다.
GitOps
다음을 포함하는 GitOps 모델을 사용하여 Bindplane 리소스를 배포합니다.
- Bindplane 인증
- Bindplane CLI
- 네트워크 액세스
- GitHub 저장소 및 GitHub Actions와의 통합
- 기존 리소스 내보내기
- 민감한 값 관리
- GitHub Actions 워크플로 설정
- 직접 수정 또는 UI 내보내기 방법을 사용하여 구성을 커밋하고 테스트하고, 자동 출시를 사용 설정하고, 리소스를 업데이트하는 단계별 안내
- 민감한 값 업데이트 및 RBAC 사용
자세한 내용은 GitOps를 참고하세요.
Ansible
Ansible로 Bindplane을 배포하는 방법을 알아보려면 bindplane-agent-ansible을 참고하세요.
Bindplane CLI
Bindplane CLI에 대해 알아보려면 GitOps를 참고하세요.
Terraform
Terraform을 사용하여 Bindplane 리소스를 구성하는 방법을 알아보려면 Bindplane 제공업체를 참고하세요.
Kubernetes
Bindplane을 사용한 Kubernetes에 대해 알아보려면 다음을 참고하세요.
Windows에 Bindplane 수집기 설치
Windows에 Bindplane 수집기를 설치하려면 다음 PowerShell 명령어를 실행하세요.
msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet
또는 설치 마법사를 사용하여 설치하려면 Windows용 최신 설치 프로그램을 다운로드하세요. 설치 프로그램을 다운로드한 후 설치 마법사를 열고 안내에 따라 Bindplane 수집기를 구성하고 설치합니다.
Windows에 Bindplane 수집기를 설치하는 방법을 자세히 알아보려면 Windows 설치를 참고하세요.
Linux에 Bindplane 수집기 설치
설치할 패키지를 자동으로 결정하는 스크립트를 사용하여 Linux에 수집기를 설치할 수 있습니다. 동일한 스크립트를 사용하여 기존 설치를 업데이트할 수도 있습니다.
설치 스크립트를 사용하여 설치하려면 다음 스크립트를 실행하세요.
sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh
로컬 패키지에서 설치
로컬 패키지에서 수집기를 설치하려면 패키지 경로와 함께 -f
를 사용합니다.
sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh -f path_to_package
RPM 설치
출시 페이지에서 아키텍처용 RPM 패키지를 다운로드하고 rpm
을 사용하여 패키지를 설치합니다. amd64
패키지 설치에 대해서는 다음 예시를 참조하세요.
sudo rpm -U ./observiq-otel-collector_v${VERSION}_linux_amd64.rpm sudo systemctl enable --now observiq-otel-collector
VERSION
을 다운로드한 패키지의 버전으로 바꿉니다.
DEB 설치
출시 페이지에서 아키텍처에 맞는 DEB 패키지를 다운로드하고 dpkg
를 사용하여 패키지를 설치합니다. amd64
패키지 설치에 대해서는 다음 예시를 참고하세요.
sudo dpkg -i --force-overwrite ./observiq-otel-collector_v${VERSION}_linux_amd64.deb sudo systemctl enable --now observiq-otel-collector
VERSION
을 다운로드한 패키지의 버전으로 바꿉니다.
Bindplane 수집기 구성
수집기를 설치하고 나면 observiq-otel-collector
서비스가 실행되고 구성할 준비가 됩니다.
수동으로 또는 Bindplane 서버를 사용하여 수집기를 구성할 수 있습니다.
수집기를 수동으로 구성하는 경우 수집기가 Google SecOps로 인증되도록 내보내기 매개변수를 업데이트해야 합니다.
OTel 수집기 구성 파일
Linux에서 수집기의 구성 파일은 /opt/observiq-otel-collector/config.yaml
에 있습니다.
OTel 수집기 서비스 및 로그
수집기는 기본적으로 C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log
에 로깅합니다.
수집기 프로세스의 표준 오류 로그는 C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err
에서 확인할 수 있습니다.
Linux에서 수집기의 로그를 보려면 sudo tail -F /opt/observiq-otel-collector/log/collector.log
를 실행합니다.
일반적인 Linux OTel 수집기 서비스 명령어는 다음과 같습니다.
OTel 수집기 서비스를 중지하려면
sudo systemctl stop observiq-otel-collector
를 실행합니다.OTel 수집기 서비스를 시작하려면
sudo systemctl start observiq-otel-collector
를 실행합니다.OTel 수집기 서비스를 다시 시작하려면
sudo systemctl restart observiq-otel-collector
를 실행합니다.시작 시 OTel 수집기 서비스를 사용 설정하려면
sudo systemctl enable observiq-otel-collector
를 실행합니다.
구성 변경사항을 적용하려면 수집기 서비스를 다시 시작하세요.
구성을 변경할 때는 구성 변경사항을 적용하기 위해 수집기 서비스를 다시 시작해야 합니다 (sudo systemctl restart observiq-otel-collector
).
기본 샘플 구성 파일 사용
기본적으로 수집기 구성 파일은 C:\Program Files\observIQ OpenTelemetry Collector\config.yaml
에 있습니다.
수집기에서 사용하는 샘플 구성 파일과 인증 토큰을 다운로드하려면 다음 단계를 따르세요.
- Google SecOps 콘솔을 열고 SIEM 설정 > 수집 에이전트로 이동합니다.
구성 파일에서 다음 두 섹션을 맞춤설정합니다.
- 수신 도구: 수집기가 수집하여 Google SecOps로 전송해야 하는 로그를 지정합니다.
- 내보내기 도구: 수집기가 로그를 전송하는 대상을 지정합니다.
다음 내보내기 도구가 지원됩니다.
- Google SecOps 내보내기 도구: 로그를 Google SecOps 수집 API로 직접 전송합니다.
- Google SecOps 포워더 내보내기 도구: Google SecOps 포워더에 로그를 전송합니다.
- Cloud Logging 내보내기: Cloud Logging으로 로그를 전송합니다.
내보내기 도구에서 다음을 맞춤설정합니다.
customer_id
: Google SecOps 고객 ID입니다.endpoint
: Google SecOps 리전 엔드포인트입니다.creds
: 인증 토큰입니다.또는,
creds_file_path
를 사용하여 사용자 인증 정보 파일을 직접 참조할 수도 있습니다. Windows 구성의 경우 백슬래시로 경로를 이스케이프합니다.log_type
: 로그 유형입니다. 로그 유형으로 WINDOWS_DNS를 선택하는 것이 좋습니다.ingestion_labels
: 수집 라벨입니다. 이러한 라벨은 Google SecOps에서 로그를 식별합니다.namespace
: 선택적 네임스페이스입니다.각 로그 유형에는 내보내기를 구성해야 합니다.
로그 수집 구성 샘플
다음 섹션에는 로그 수집을 위한 구성 샘플이 포함되어 있습니다.
Windows 이벤트 및 sysmon을 Google SecOps에 직접 전송
샘플에서 다음 매개변수를 구성합니다.
-
namespace
ingestion_labels
log_type
customer_id
creds
샘플 구성:
receivers:
windowseventlog/sysmon:
channel: Microsoft-Windows-Sysmon/Operational
raw: true
windowseventlog/security:
channel: security
raw: true
windowseventlog/application:
channel: application
raw: true
windowseventlog/system:
channel: system
raw: true
processors:
batch:
exporters:
chronicle/sysmon:
endpoint: malachiteingestion-pa.googleapis.com
creds: '{
"type": "service_account",
"project_id": "malachite-projectname",
"private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
"private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
"client_email": "account@malachite-projectname.iam.gserviceaccount.com",
"client_id": "123456789123456789",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
"universe_domain": "googleapis.com"
}'
log_type: 'WINDOWS_SYSMON'
override_log_type: false
raw_log_field: body
customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'
chronicle/winevtlog:
endpoint: malachiteingestion-pa.googleapis.com
creds: '{
"type": "service_account",
"project_id": "malachite-projectname",
"private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
"private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
"client_email": "account@malachite-projectname.iam.gserviceaccount.com",
"client_id": "123456789123456789",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
"universe_domain": "googleapis.com"
}'
log_type: 'WINEVTLOG'
override_log_type: false
raw_log_field: body
customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'
service:
pipelines:
logs/sysmon:
receivers: [windowseventlog/sysmon]
processors: [batch]
exporters: [chronicle/sysmon]
logs/winevtlog:
receivers:
- windowseventlog/security
- windowseventlog/application
- windowseventlog/system
processors: [batch]
exporters: [chronicle/winevtlog]
Windows 이벤트 및 syslog를 Google SecOps에 직접 전송
샘플에서 다음 매개변수를 구성합니다.
windowseventlogreceiver
tcplogreceiver
listen_address
chronicleexporter
namespace
ingestion_labels
log_type
customer_id
creds
샘플 구성:
receivers:
tcplog:
listen_address: "0.0.0.0:54525"
windowseventlog/source0__application:
attributes:
log_type: windows_event.application
channel: application
max_reads: 100
poll_interval: 1s
raw: true
start_at: end
windowseventlog/source0__security:
attributes:
log_type: windows_event.security
channel: security
max_reads: 100
poll_interval: 1s
raw: true
start_at: end
windowseventlog/source0__system:
attributes:
log_type: windows_event.system
channel: system
max_reads: 100
poll_interval: 1s
raw: true
start_at: end
exporters:
chronicle/chronicle_w_labels:
compression: gzip
creds: '{ json blob for creds }'
customer_id: <customer_id>
endpoint: malachiteingestion-pa.googleapis.com
ingestion_labels:
env: dev
log_type: <applicable_log_type>
namespace: testNamespace
raw_log_field: body
service:
pipelines:
logs/source0__chronicle_w_labels-0:
receivers:
- windowseventlog/source0__system
- windowseventlog/source0__application
- windowseventlog/source0__security
exporters:
- chronicle/chronicle_w_labels
logs/source1__chronicle_w_labels-0:
receivers:
- tcplog
exporters:
- chronicle/chronicle_w_labels
Windows 이벤트 및 syslog를 Google SecOps 포워더에 전송
샘플에서 다음 매개변수를 구성합니다.
windowseventlogreceiver
tcplogreceiver
listen_address
chronicleforwarder
endpoint
샘플 구성:
receivers:
tcplog:
listen_address: "0.0.0.0:54525"
windowseventlog/source0__application:
attributes:
log_type: windows_event.application
channel: application
max_reads: 100
poll_interval: 1s
raw: true
start_at: end
windowseventlog/source0__security:
attributes:
log_type: windows_event.security
channel: security
max_reads: 100
poll_interval: 1s
raw: true
start_at: end
windowseventlog/source0__system:
attributes:
log_type: windows_event.system
channel: system
max_reads: 100
poll_interval: 1s
raw: true
start_at: end
exporters:
chronicleforwarder/forwarder:
export_type: syslog
raw_log_field: body
syslog:
endpoint: 127.0.0.1:10514
transport: udp
service:
pipelines:
logs/source0__forwarder-0:
receivers:
- windowseventlog/source0__system
- windowseventlog/source0__application
- windowseventlog/source0__security
exporters:
- chronicleforwarder/forwarder
logs/source1__forwarder-0:
receivers:
- tcplog
exporters:
- chronicleforwarder/forwarder
syslog를 Google SecOps에 직접 전송
샘플에서 다음 매개변수를 구성합니다.
tcplogreceiver
listen_address
chronicleexporter
namespace
ingestion_labels
log_type
customer_id
Creds
샘플 구성:
receivers:
tcplog:
listen_address: "0.0.0.0:54525"
exporters:
chronicle/chronicle_w_labels:
compression: gzip
creds: '{ json blob for creds }'
customer_id: <customer_id>
endpoint: malachiteingestion-pa.googleapis.com
ingestion_labels:
env: dev
log_type: <applicable_log_type>
namespace: testNamespace
raw_log_field: body
service:
pipelines:
logs/source0__chronicle_w_labels-0:
receivers:
- tcplog
exporters:
- chronicle/chronicle_w_labels
Windows 이벤트를 원격으로 수집하여 Google SecOps로 직접 전송
샘플에서 다음 매개변수를 구성합니다.
windowseventlogreceiver
username
password
server
chronicleexporter
namespace
ingestion_labels
log_type
customer_id
creds
샘플 구성:
receivers:
windowseventlog/system:
channel: system
max_reads: 100
start_at: end
poll_interval: 10s
raw: true
remote:
username: "username"
password: "password"
server: "remote-server"
windowseventlog/application:
channel: application
max_reads: 100
start_at: end
poll_interval: 10s
raw: true
remote:
username: "username"
password: "password"
server: "server-ip"
windowseventlog/security:
channel: security
max_reads: 100
start_at: end
poll_interval: 10s
raw: true
remote:
username: "username"
password: "password"
server: "server-ip"
exporters:
chronicle/chronicle_w_labels:
compression: gzip
creds: '{ json blob for creds }'
customer_id: <customer_id>
endpoint: malachiteingestion-pa.googleapis.com
ingestion_labels:
env: dev
log_type: WINEVTLOG
namespace: testNamespace
raw_log_field: body
service:
pipelines:
logs/source0__chronicle_w_labels-0:
receivers:
- windowseventlog/system
- windowseventlog/application
- windowseventlog/security
exporters:
- chronicle/chronicle_w_labels
Cloud Logging으로 데이터 전송
샘플에서 credentials_file
매개변수를 구성합니다.
샘플 구성:
exporters:
googlecloud:
credentials_file: /opt/observiq-otel-collector/credentials.json
SQL 데이터베이스를 쿼리하고 결과를 Google SecOps로 전송
샘플에서 다음 매개변수를 구성합니다.
sqlqueryreceiver
chronicleexporter
namespace
ingestion_labels
log_type
customer_id
creds
샘플 구성:
receivers:
sqlquery/source0:
datasource: host=localhost port=5432 user=postgres password=s3cr3t sslmode=disable
driver: postgres
queries:
- logs:
- body_column: log_body
sql: select * from my_logs where log_id > $$1
tracking_column: log_id
tracking_start_value: "10000"
processors:
transform/source0_processor0__logs:
error_mode: ignore
log_statements:
- context: log
statements:
- set(attributes["chronicle_log_type"], "POSTGRESQL") where true
exporters:
chronicle/chronicle_sql:
compression: gzip
creds: '{
"type": "service_account",
"project_id": "malachite-projectname",
"private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
"private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
"client_email": "account@malachite-projectname.iam.gserviceaccount.com",
"client_id": "123456789123456789",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
"universe_domain": "googleapis.com"
}'
customer_id: customer_id
endpoint: malachiteingestion-pa.googleapis.com
log_type: POSTGRESQL
namespace: null
raw_log_field: body
retry_on_failure:
enabled: false
sending_queue:
enabled: false
service:
pipelines:
logs/source0_chronicle_sql-0:
receivers:
- sqlquery/source0
processors:
- transform/source0_processor0__logs
exporters:
- chronicle/chronicle_sql
정규 표현식과 일치하는 로그 삭제
정규 표현식과 일치하는 로그를 삭제하도록 수집기를 구성할 수 있습니다. 이는 알려진 오류나 디버깅 메시지와 같은 원치 않는 로그를 필터링하는 데 유용합니다.
정규 표현식과 일치하는 로그를 삭제하려면 구성에 filter/drop-matching-logs-to-Chronicle
유형의 프로세서를 추가하세요. 이 프로세서는 IsMatch
함수를 사용하여 정규 표현식에 대해 로그 본문을 평가합니다. 함수가 true
를 반환하면 로그가 삭제됩니다.
다음 구성 예시에서는 로그 본문에 <EventID>10</EventID>
또는 <EventID>4799</EventID>
문자열이 포함된 로그를 삭제합니다.
필요한 패턴과 일치하도록 정규 표현식을 맞춤설정할 수 있습니다. IsMatch
함수는 RE2 정규 표현식 문법을 사용합니다.
샘플 구성:
processors:
filter/drop-matching-logs-to-Chronicle:
error_mode: ignore
logs:
log_record:
- (IsMatch(body, "<EventID>10</EventID>")) or (IsMatch(body, "<EventID>4799</EventID>"))
다음 예에서는 동일한 구성의 파이프라인에 프로세서를 추가합니다.
service:
pipelines:
logs/winevtlog:
receivers:
- windowseventlog/security
- windowseventlog/application
- windowseventlog/system
processors:
- filter/drop-matching-logs-to-Chronicle # Add this line
- batch
exporters: [chronicle/winevtlog]
Bindplane 운영 및 유지관리
이 섹션에서는 일상적인 작동 및 유지보수 작업을 설명합니다.
OTel 구성 확인
Bindplane OTel 구성을 확인하는 방법을 알아보려면 OTelBin을 참고하세요.
수집기 출시 업데이트
Bindplane은 bindplane-otel-collector/releases를 폴링하여 새 수집기 출시를 감지할 수 있습니다. 이 기능은 선택사항입니다.
Bindplane 구성에서 agentVersions.syncInterval
을 0
로 설정하여 GitHub 폴링을 사용 중지할 수 있습니다.
agentVersions:
syncInterval: 0
백업 및 재해 복구
Bindplane을 사용한 백업 및 재해 복구에 대해 알아보려면 Bindplane 리소스를 참고하세요.
PostgreSQL 백업 및 재해 복구
Bindplane을 사용한 PostgreSQL 백업 및 재해 복구에 대해 알아보려면 PostgreSQL 문서를 참고하세요.
BBolt 백업 및 재해 복구
Bindplane을 사용한 BBolt (지원 중단됨) 백업 및 재해 복구에 대해 알아보려면 BBolt 스토어 문서를 참고하세요.
복원력 및 재시도
재시도는 재시도를 지원하는 모든 대상 위치에서 기본적으로 사용 설정됩니다. 기본적으로 실패한 요청은 5초 후에 재시도되며 최대 30초까지 점진적으로 백오프됩니다. 5분이 지나면 요청이 영구적으로 삭제됩니다.
자세한 내용은 수집기 복원력을 참고하세요.
심각도 필터로 로그 볼륨 줄이기
로그 볼륨을 줄이는 방법을 알아보려면 심각도 필터로 로그 볼륨 줄이기를 참고하세요.
서드 파티 수집기와의 Bindplane 통합
에지에서 수집할 때 Bindplane 수집기를 사용하면 Bindplane이 더 강력해지지만 대부분의 경우 Bindplane은 기존 인프라 내에 유지될 수 있습니다. 예를 들어 Fluent Bit 또는 Splunk Universal Forwarder를 이미 사용하고 있다면 계속 사용할 수 있습니다.
Splunk와의 Bindplane 통합
Bindplane을 사용하는 Splunk에 대해 알아보려면 다음을 참고하세요.
다른 서드 파티 수집기와의 Bindplane 통합
Bindplane과 서드 파티 수집기와의 통합에 대해 알아보려면 OpAMP 확장 프로그램을 사용하여 다른 OpenTelemetry 수집기 연결을 참고하세요.
자동 호스트 모니터링
Google Security Operations Silent Host Monitoring을 사용하면 Google Cloud Monitoring을 사용하여 수집률 변경에 대한 알림을 만들 수 있습니다. 수집기별로 알림을 생성하고 수집률이 정의된 기준점 아래로 떨어지면 알림을 보내 잠재적인 수집기 중지를 알립니다.
Bindplane을 사용하여 자동 호스트 모니터링을 수행하는 방법은 다음을 참고하세요.
Linux에서 Bindplane 업그레이드
끝에 --init
플래그 없이 설치 명령어를 실행하면 Bindplane을 업그레이드할 수 있습니다. Bindplane 서버에서 이 스크립트를 실행하여 Bindplane을 업그레이드합니다. 자세한 내용은 Bindplane 서버 업그레이드, 다운그레이드 또는 제거를 참고하세요.
Bindplane 모니터링
Bindplane 모니터링 방법을 알아보려면 Bindplane 모니터링을 참고하세요.
Bindplane에서 Kubernetes 모니터링
Bindplane에서 Kubernetes를 모니터링하는 방법을 알아보려면 Kubernetes 모니터링을 참고하세요.
추가 문서
Bindplane (이전 명칭: observIQ)에 대해 자세히 알아보려면 다음을 참고하세요.
- OpenTelemetry 기반의 업계 최고 수준 관측 가능성 및 보안
- Bindplane 권장사항과 함께 Google SecOps 사용하기
- Bindplane 솔루션
- Bindplane 시작하기
- Google Cloud에 지원되는 로그 유형
- 조건 프로세서별 필터링
- Bindplane에서 사용 가능한 소스
도움이 더 필요하신가요? 커뮤니티 회원 및 Google SecOps 전문가로부터 답변을 받으세요.