Utilizzare Bindplane con Google SecOps

Questo documento descrive Bindplane per Google Security Operations.

Bindplane è una pipeline di telemetria che può raccogliere, perfezionare ed esportare i log da qualsiasi origine in Google SecOps.

Bindplane offre due versioni appositamente per Google.

Bindplane include i seguenti componenti principali:

• Bindplane Collector. Un agente open source basato su OpenTelemetry (OTel) Collector. Raccoglie i log da varie origini, inclusi i log eventi di Microsoft Windows, e li invia a Google SecOps. Puoi installare i raccoglitori on-premise o nel cloud. Questo componente è anche chiamato agente Bindplane di distribuzione per OpenTelemetry (BDOT), agente di raccolta, collector o agente.
• Bindplane Server. Una piattaforma completa e unificata per la gestione dei deployment del collettore OTel. Questi deployment possono risiedere in Google SecOps e Google Cloud. Bindplane Server può essere eseguito on-premise o nel cloud Bindplane. Per saperne di più sulla console, consulta Console di gestione Bindplane. Questo componente è anche chiamato console di gestione della pipeline di osservabilità (OP) di Bindplane o console di gestione di Bindplane.

Versioni Google di Bindplane

Bindplane offre due versioni appositamente per Google: Bindplane (Google Edition) e Bindplane Enterprise (Google Edition).

Bindplane (Google Edition)

Tutti i clienti di Google SecOps hanno accesso a Bindplane (Google Edition) senza costi aggiuntivi. Per scoprire di più, consulta Visibilità e sicurezza leader del settore basate su OpenTelemetry.

Puoi utilizzare Bindplane (Google Edition) self-service sul cloud Bindplane.

Per scoprire come iniziare a installare e auto-ospitare Bindplane (Google Edition), consulta Bindplane (Google Edition).

Bindplane Enterprise (Google Edition) per i clienti di Google SecOps Enterprise Plus

Bindplane Enterprise (Google Edition) è incluso per i clienti di Google SecOps Enterprise Plus.

Bindplane Enterprise (Google Edition) è consigliato per i deployment su larga scala.

Contatta il team del tuo Account Google per ottenere la codice licenza per Bindplane Enterprise (Google Edition).

Versioni di Bindplane Google: differenze

La seguente tabella elenca le differenze tra le versioni di Bindplane Google:

Console di gestione Bindplane

L'utilizzo della console di gestione Bindplane è facoltativo. Molti clienti di Google SecOps utilizzano Bindplane Server.

La console di gestione Bindplane offre le seguenti funzionalità principali:

• Gestione centralizzata. La console consente di gestire tutti i deployment del collettore OTel in Google Cloud. Puoi visualizzare lo stato di ogni deployment, nonché eseguire attività di gestione comuni come l'avvio, l'arresto e il riavvio dei raccoglitori.
• Monitoraggio in tempo reale. La console fornisce il monitoraggio in tempo reale delle implementazioni del collettore OTel. Puoi monitorare metriche come l'utilizzo della CPU, l'utilizzo della memoria e il throughput, nonché visualizzare log e tracce per risolvere i problemi.
• Avvisi e notifiche. La console ti consente di configurare avvisi e notifiche per eventi importanti, ad esempio quando un raccoglitore non funziona o quando viene superata una soglia metrica.
• Gestione della configurazione. La console ti consente di gestire centralmente la configurazione dei tuoi raccoglitori OTel. Puoi modificare i file di configurazione, impostare le variabili di ambiente e applicare le norme di sicurezza a tutti i tuoi deployment.
• Integrazione con Google Cloud. Puoi creare e gestire i deployment del collettore OTel in Google Cloud e utilizzare la console per accedere alle tue risorse Google Cloud .

Architettura dell'agente Bindplane

Bindplane Agent può essere eseguito in Linux o Docker come server web leggero senza dipendenze esterne.

Bindplane utilizza il raccoglitore BDOT per standardizzare la gestione della telemetria con Open Agent Management Protocol (OpAMP). Puoi anche creare e gestire distribuzioni personalizzate di OpenTelemetry Collector con Bindplane.

Per saperne di più sull'architettura di deployment dei raccoglitori Bindplane OpenTelemetry, consulta Bindplane OTel Collector.

Le sezioni seguenti descrivono le opzioni di architettura disponibili.

Gli agenti di raccolta inviano i log a un agente di raccolta che funge da gateway

Per le implementazioni su larga scala, ti consigliamo di utilizzare agenti Bindplane Enterprise (Google Edition) che fungono da gateway. Questi gateway ricevono la telemetria da altri raccoglitori tramite la rete, eseguono facoltativamente un'elaborazione aggiuntiva e indirizzano i dati a Google SecOps.

Un agente di raccolta che funge da gateway utilizza lo stesso binario di tutti gli altri agenti di raccolta.

Il seguente diagramma mostra gli agenti di raccolta che inviano i log a un agente di raccolta che funge da gateway.

Gli agenti di raccolta inviano i log direttamente all'API di importazione di Google SecOps

Il seguente diagramma mostra gli agenti di raccolta che inviano i log direttamente all'API di importazione di Google SecOps.

Gli agenti di raccolta inviano i log direttamente a Cloud Logging

Il seguente diagramma mostra gli agenti di raccolta che inviano i log direttamente a Cloud Logging.

Gli agenti di raccolta inviano i log a più destinazioni

Il seguente diagramma mostra gli agenti di raccolta che inviano log a più destinazioni.

Tipi di deployment di Bindplane

Bindplane offre opzioni di deployment cloud e on-premise.

Deployment on-premise

• Linux
• Docker

Per saperne di più, vedi Installare Bindplane Server.

Linux

Distribuzioni Linux:

• Red Hat, Centos, Oracle Linux 7, 8, 9
• Debian 11 e 12
• Ubuntu LTS 20.04 e 22.04
• SUSE Linux 12 e 15
• Alma e Rocky Linux

Per saperne di più, consulta le seguenti risorse:

• Installare Bindplane Server
• Download di pacchetti

Immagini container Docker

Puoi trovare le immagini container Docker di Bindplane nelle seguenti posizioni:

• Pacchetti GitHub: ghcr.io/observiq/Bindplane-ee
• Repository di artefatti Google: us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
• Docker Hub: observiq/bindplane-ee

Le immagini container sono taggate con la versione della release: ad esempio, la release v1.35.0 avrà il tag observiq/bindplane-ee:1.35.0.

Requisiti tecnici e consigli

Questa sezione descrive i requisiti tecnici e i consigli per l'installazione e l'esecuzione di Bindplane con Google SecOps.

Requisiti di larghezza di banda

Bindplane gestisce le connessioni di rete per quanto segue:

• Gestione dei raccoglitori
• Misurazioni della velocità effettiva del raccoglitore
• Interfacce utente web e a riga di comando

Requisiti di connettività

Per impostazione predefinita, Bindplane rimane in ascolto sulla porta 3001. Questa porta è configurabile.

La porta Bindplane viene utilizzata per:

• Comando e controllo del collettore utilizzando OpAMP (WebSocket)
• Richieste di misurazione del throughput del raccoglitore (richiesta HTTP POST)
• Utenti di browser e CLI (HTTP e WebSocket)

I raccoglitori devono essere in grado di avviare connessioni a Bindplane per OpAMP (WebSocket) e misurazioni del throughput (HTTP).

Bindplane non avvia mai connessioni ai raccoglitori. Puoi configurare un firewall per impedire a Bindplane di raggiungere le reti del raccoglitore. Tuttavia, le reti del raccoglitore devono essere in grado di raggiungere Bindplane sulla porta configurata.

Requisiti tecnici generali del raccoglitore Bindplane

Per informazioni sui requisiti tecnici generali per il raccoglitore Bindplane, vedi quanto segue:

• Bindplane OTel collector su GitHub
• Installare e disinstallare i raccoglitori Bindplane
• Prerequisiti per l'installazione
• Linee guida per il dimensionamento e lo scaling del raccoglitore

Requisiti delle risorse del raccoglitore

I requisiti di risorse di Bindplane variano in base al numero di raccoglitori gestiti. All'aumentare del numero di raccoglitori gestiti, aumentano anche il consumo di CPU, memoria, velocità effettiva/IOPS del disco e rete.

Utilizza la seguente tabella per il dimensionamento di CPU, memoria e capacità di archiviazione:

Pianificare l'installazione e il deployment

Le sezioni seguenti includono consigli e best practice da prendere in considerazione quando pianifichi il deployment di Bindplane.

Considera scalabilità e tolleranza agli errori

I raccoglitori del gateway ricevono i dati di telemetria tramite la rete. Ti consigliamo di accoppiarli a un bilanciatore del carico per fornire sia la tolleranza agli errori che lo scalabilità orizzontale.

Lo scale up orizzontale è preferibile perché offre tolleranza di errore e può eliminare i colli di bottiglia dell'esportatore.

Calcolare il numero di raccoglitori necessari

Quando calcoli il numero di raccoglitori necessari per il tuo workload, considera il throughput o la frequenza di log previsti e utilizza la seguente tabella. Questa tabella presuppone che ogni raccoglitore abbia quattro core CPU e 16 GB di memoria. La tabella non tiene conto dei processori; quando vengono aggiunti, i requisiti di calcolo aumentano.

Esegui il provisioning eccessivo del parco raccoglitori per la tolleranza agli errori

Esegui il provisioning eccessivo del parco risorse di raccolta per garantire la tolleranza agli errori. Nel caso in cui uno o più sistemi di raccolta non funzionino o vengano messi offline per manutenzione, i raccoglitori rimanenti devono avere una capacità sufficiente per gestire il throughput della telemetria.

Se lavori con un numero fisso di raccoglitori, puoi implementare lo scale up verticale di CPU e memoria per aumentare la velocità effettiva.

Ridurre il sovraccarico di elaborazione

In genere, vuoi che i collettori svolgano il minor lavoro possibile. Se hai requisiti di elaborazione elevati, può essere utile scaricare l'elaborazione su una flotta di raccoglitori gateway. Ad esempio, anziché filtrare la telemetria con un'operazione di espressione regolare costosa, puoi fare in modo che i raccoglitori del gateway eseguano questa attività. In genere, i raccoglitori gateway vengono eseguiti su un sistema dedicato. Ciò giustifica il sovraccarico di elaborazione perché non consuma la potenza di calcolo di altri servizi in esecuzione sullo stesso sistema, a differenza di un raccoglitore non gateway che potrebbe essere in esecuzione su un server di database.

Best practice per la modalità gateway

Quando utilizzi un agente di raccolta Bindplane come gateway, ovvero in modalità gateway, pianifica il deployment seguendo queste best practice:

• Posiziona almeno due raccoglitori dietro un bilanciatore del carico.
• Ogni raccoglitore deve avere un minimo di due core.
• Ogni raccoglitore deve avere almeno 8 GB di memoria.
• Ogni raccoglitore deve avere 60 GB di spazio utilizzabile per una coda persistente.

Utilizzare un bilanciatore del carico quando necessario

Un bilanciatore del carico è necessario quando Bindplane viene utilizzato in modalità ad alta disponibilità.

Quando utilizzi un agente di raccolta Bindplane in modalità gateway, utilizza un bilanciatore del carico per aumentare le prestazioni e la ridondanza. Il bilanciamento del carico consente anche lo scale out del parco risorse gateway e la capacità di resistere ai guasti senza causare interruzioni.

L'agente di raccolta Bindplane può funzionare con un'ampia gamma di bilanciatori del carico quando opera in modalità gateway. Questo documento non descrive opzioni specifiche, perché le soluzioni di bilanciamento del carico più diffuse supportano le funzionalità necessarie per il funzionamento affidabile di più raccoglitori.

Per saperne di più, consulta Bilanciatore del carico.

Porta e protocolli di bilanciamento del carico

Per impostazione predefinita, Bindplane rimane in ascolto sulla porta 3001.

Per supportare l'ampia gamma di ricevitori basati sulla rete in OpenTelemetry, il bilanciatore del carico deve supportare:

• Protocolli di trasporto TCP/UDP
• Protocolli applicativi HTTP e gRPC

Dimensionamento del bilanciamento del carico

I nodi Bindplane non devono gestire più di 30.000 raccoglitori per la massima tolleranza agli errori. Ogni raccoglitore apre due connessioni a Bindplane (una per la gestione remota di OpAMP e una per la pubblicazione delle metriche di velocità effettiva). Questo limite contribuisce a garantire di non superare il limite di connessioni di circa 65.535 per istanza di backend imposto dalla maggior parte dei bilanciatori del carico.

Se un'organizzazione ha 100.000 raccoglitori, una dimensione del cluster di tre non sarebbe sufficiente. Ogni nodo sarebbe responsabile di circa 33.000 raccoglitori, il che si traduce in 66.000 connessioni TCP per istanza Bindplane. Questa situazione peggiora se un nodo viene disattivato per la manutenzione, poiché ogni istanza Bindplane rimanente gestisce 50.000 raccoglitori o 100.000 connessioni TCP.

Best practice per il dimensionamento del bilanciamento del carico

• Implementa controlli di integrità. Configura il bilanciatore del carico per assicurarti che il collettore sia pronto a ricevere il traffico.
• Distribuisci le connessioni in modo uniforme. Le connessioni devono essere distribuite in modo uniforme tra i raccoglitori.

• Supporta i protocolli richiesti. Per supportare l'ampia gamma di ricevitori basati sulla rete in OpenTelemetry, il bilanciatore del carico deve supportare:

  • Protocolli di trasporto TCP/UDP
  • Protocolli applicativi HTTP e gRPC

Per saperne di più, consulta Resilienza del raccoglitore.

Bilanciamento del carico di tipo origine

Qualsiasi tipo di origine che riceve dati di telemetria da sistemi remoti sulla rete è un candidato idoneo per il bilanciamento del carico, tra cui:

• OTLP
• Syslog
• TCP/UDP
• Splunk HEC
• Fluent Forward

Utilizzare la modalità ad alta disponibilità negli ambienti di produzione

Puoi eseguire il deployment di un'istanza Bindplane in una configurazione a singola istanza o multi-istanza. Per i deployment di produzione che richiedono alta disponibilità e resilienza, ti consigliamo di utilizzare un modello di deployment multi-istanza (HA).

Quando Bindplane gestisce più di 25.000 raccoglitori, ti consigliamo di utilizzarlo in modalità ad alta affidabilità (HA).

Per scoprire di più sull'alta disponibilità in Bindplane, consulta Alta disponibilità.

Calcolare il numero di raccoglitori e server Bindplane per l'alta disponibilità

Quando utilizzi Bindplane in modalità ad alta disponibilità, devi considerare il numero di raccoglitori che prevedi che ogni server Bindplane gestisca.

Prendi il numero totale di istanze Bindplane e sottrai il numero massimo di nodi che prevedi di non essere disponibili a causa della manutenzione. Assicurati che ogni nodo gestisca non più di 30.000 raccoglitori durante un'interruzione del nodo.

Postgres per l'alta disponibilità

Postgres è un prerequisito quando utilizzi Bindplane in modalità HA.

Prometheus per l'alta disponibilità

Prometheus è obbligatorio quando utilizzi Bindplane in modalità ad alta disponibilità.

Per scoprire di più, consulta Prometheus.

Bus di eventi per l'alta disponibilità

Bindplane utilizza un bus di eventi per comunicare tra i componenti al suo interno. Quando utilizzi Bindplane in modalità HA, puoi utilizzare il bus degli eventi per inviare eventi tra i server Bindplane.

Per saperne di più, consulta Event Bus.

Utilizza un deployment a singola istanza per un ambiente di test o una proof of concept

Per un ambiente di test o una prova di fattibilità, ti consigliamo di utilizzare un deployment a singola istanza.

Per saperne di più, consulta Singola istanza.

Isolare le credenziali di backend

Anziché distribuire le credenziali a tutti i sistemi di raccolta, puoi conservarle esclusivamente sui raccoglitori gateway. In questo modo, la rotazione delle credenziali viene semplificata e la superficie di attacco alla sicurezza viene ridotta limitando l'implementazione delle credenziali a un sottoinsieme dei tuoi sistemi.

Proteggere i raccoglitori del gateway con firewall

Puoi posizionare i raccoglitori del gateway all'interno di una rete perimetrale, protetta dalla rete interna da un firewall. Puoi configurare la rete in modo da consentire agli altri raccoglitori di inoltrare i dati ai raccoglitori gateway, impedendo al contempo ai raccoglitori gateway di accedere alla rete dell'applicazione. In questo modo puoi inviare dati di telemetria a un backend basato sul cloud senza concedere ai tuoi endpoint l'accesso diretto a internet.

Il firewall deve consentire al traffico HTTP di raggiungere Bindplane sulla porta configurata.

Verificare la configurazione del firewall

Eventuali firewall o proxy autenticati tra l'agente e internet richiedono regole per aprire l'accesso ai seguenti host:

Utilizza PostgreSQL per i deployment di produzione

PostgreSQL è obbligatorio per i deployment di produzione di Bindplane.

PostgreSQL è un prerequisito per il funzionamento di Bindplane in modalità ad alta disponibilità.

Il numero di core CPU e la memoria disponibile in genere limitano le prestazioni dei backend di archiviazione PostgreSQL. Ti consigliamo di eseguire il backup dello spazio di archiviazione PostgreSQL con uno spazio di archiviazione a bassa latenza e throughput elevato, ad esempio unità a stato solido (SSD).

Per saperne di più, consulta le seguenti risorse:

• Documentazione di PostgreSQL
• Guida alla configurazione di Postgres
• Configurazione dell'archivio Postgres
• Configurazione TLS di Postgres

Implementa l'autenticazione corretta

Bindplane supporta l'autenticazione con i seguenti protocolli e servizi; assicurati che siano implementati correttamente:

• Azure Entra LDAP. Per saperne di più, consulta Azure LDAP e Modifica del tipo di autenticazione di Bindplane.
• LDAP.
• OpenID Connect (OIDC).
• Locale.
• SAML.
• TLS Postgres. Per saperne di più, consulta TLS di Postgres.
• Kubernetes. Per saperne di più, consulta Workload Identity di GKE.

Installa la console di gestione Bindplane

La maggior parte dei clienti di Google SecOps utilizza la console di gestione Bindplane. Se lo stai installando, devi accedere a storage.googleapis.com. Se installi solo l'agente, questo accesso non è necessario.

Bindplane Cloud è disponibile anche per i clienti Google. Scarica la versione gratuita e invia un'email all'indirizzo support@bindplane.com per richiedere l'upgrade alla versione supportata da Google.

Esistono tre modi per eseguire il deployment della console di gestione Bindplane:

• Bindplane Cloud: l'offerta SaaS di Bindplane per Bindplane Server.
• Scarica e installa su un host Linux: disponibile come pacchetto DEB, pacchetto RPM o immagine Docker.
• Installare ed eseguire il provisioning da Google Cloud Marketplace.

Installa l'agente Bindplane

Questa sezione descrive come installare l'agente Bindplane per Google SecOps su diversi sistemi operativi host.

I raccoglitori di agenti in genere utilizzano risorse minime. Tuttavia, quando gestisci grandi volumi di log, tieni presente il consumo di risorse per evitare di influire su altri servizi. Per ulteriori informazioni, consulta Requisiti tecnici e consigli, Pianificare l'installazione e il deployment e Dimensionamento e scalabilità dell'agente.

Per scoprire di più su come installare l'agente OTel, consulta Installare e disinstallare i raccoglitori Bindplane.

Per eventuali problemi relativi al raccoglitore, contatta l' Google Cloud assistenza.

Per installare l'agente, devi disporre di quanto segue:

• File di autenticazione per l'importazione di Google SecOps

  Per scaricare il file di autenticazione:

  1. Apri la console Google SecOps.
  2. Vai a Impostazioni SIEM > Agente di raccolta.
  3. Scarica il file di autenticazione dell'importazione di Google SecOps.

• ID cliente Google SecOps

  Per trovare l'ID cliente:

  1. Apri la console Google SecOps.
  2. Vai a Impostazioni SIEM > Profilo.
  3. Copia l'ID cliente dalla sezione Dettagli dell'organizzazione.

• Windows 2012 SP2 o versioni successive o host Linux con systemd

• Connettività a internet

• Accesso a GitHub

Strumenti di deployment

Questa sezione descrive gli strumenti di deployment per Bindplane.

GitOps

Esegui il deployment delle risorse Bindplane utilizzando un modello GitOps, che include quanto segue:

• Autenticazione Bindplane
• Interfaccia a riga di comando Bindplane
• Accesso alla rete
• Integrazione con un repository GitHub e GitHub Actions
• Esportazione delle risorse esistenti
• Gestione dei valori sensibili
• Stabilire un flusso di lavoro di GitHub Actions
• Istruzioni passo passo per eseguire il commit e testare la configurazione, attivare i rollout automatici e aggiornare le risorse utilizzando modifiche dirette o il metodo di esportazione dell'interfaccia utente
• Aggiornamento dei valori sensibili e utilizzo del controllo dell'accesso basato sui ruoli (RBAC)

Per saperne di più, vedi GitOps.

Ansible

Per informazioni sul deployment di Bindplane con Ansible, consulta bindplane-agent-ansible.

Interfaccia a riga di comando Bindplane

Per scoprire di più sulla CLI Bindplane, consulta GitOps.

Terraform

Per scoprire di più sull'utilizzo di Terraform per configurare le risorse Bindplane, consulta Provider Bindplane.

Kubernetes

Per scoprire di più su Kubernetes con Bindplane, consulta quanto segue:

• Nome cluster dinamico Kubernetes
• Migrazione di Kubernetes Postgres

Installare l'agente Bindplane su Windows

Per installare l'agente Bindplane su Windows, esegui il seguente comando PowerShell:

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

In alternativa, per eseguire l'installazione utilizzando una procedura guidata, scarica il programma di installazione più recente per Windows. Dopo aver scaricato il programma di installazione, apri la procedura guidata di installazione e segui le istruzioni per configurare e installare l'agente Bindplane.

Per saperne di più sull'installazione dell'agente Bindplane su Windows, consulta Installazione di Windows.

Installa l'agente Bindplane su Linux

Puoi installare l'agente su Linux utilizzando uno script che determina automaticamente quale pacchetto installare. Puoi anche utilizzare lo stesso script per aggiornare un'installazione esistente.

Per installare utilizzando lo script di installazione, esegui il seguente script:

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

Per scoprire di più sulla configurazione del raccoglitore, consulta bindplane-otel-collect.

Installazione da un pacchetto locale

Per installare l'agente da un pacchetto locale, utilizza -f con il percorso del pacchetto.

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh -f path_to_package

Installazione di RPM

Scarica il pacchetto RPM per la tua architettura dalla pagina delle release e installalo utilizzando rpm. Per installare il pacchetto amd64, consulta il seguente esempio:

sudo rpm -U ./observiq-otel-collector_v${VERSION}_linux_amd64.rpm
sudo systemctl enable --now observiq-otel-collector

Sostituisci VERSION con la versione del pacchetto che hai scaricato.

Installazione DEB

Scarica il pacchetto DEB per la tua architettura dalla pagina delle release e installalo utilizzando dpkg. Per installare il pacchetto amd64, consulta il seguente esempio:

sudo dpkg -i --force-overwrite ./observiq-otel-collector_v${VERSION}_linux_amd64.deb
sudo systemctl enable --now observiq-otel-collector

Sostituisci VERSION con la versione del pacchetto che hai scaricato.

Per saperne di più, consulta Installazione dell'agente Bindplane.

Configura l'agente BindPlane

Dopo l'installazione dell'agente, il servizio observiq-otel-collector viene eseguito ed è pronto per la configurazione.

Puoi configurare l'agente manualmente o utilizzando la console di gestione Bindplane.

Se configuri l'agente manualmente, devi aggiornare i parametri dell'esportatore per assicurarti che l'agente esegua l'autenticazione con Google SecOps.

File di configurazione del raccoglitore OTel

In Linux, il file di configurazione del raccoglitore si trova in /opt/observiq-otel-collector/config.yaml.

Servizio di raccolta OTel e log

Per impostazione predefinita, l'agente registra i log in C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

Il log degli errori standard per il processo dell'agente si trova in C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

Per saperne di più sulla configurazione del raccoglitore, consulta bindplane-otel-collect.

In Linux, per visualizzare i log del raccoglitore, esegui sudo tail -F /opt/observiq-otel-collector/log/collector.log.

Comandi comuni del servizio di raccolta OTel di Linux:

• Per arrestare il servizio di raccolta OTel, esegui sudo systemctl stop observiq-otel-collector.

• Per avviare il servizio di raccolta OTel, esegui sudo systemctl start observiq-otel-collector.

• Per riavviare il servizio di raccolta OTel, esegui sudo systemctl restart observiq-otel-collector.

• Per attivare il servizio di raccolta OTel all'avvio, esegui sudo systemctl enable observiq-otel-collector.

Riavvia il servizio dell'agente per le modifiche alla configurazione

Quando modifichi la configurazione, devi riavviare il servizio dell'agente affinché le modifiche alla configurazione diventino effettive (sudo systemctl restart observiq-otel-collector).

Utilizzare un file di configurazione di esempio predefinito

Per impostazione predefinita, un file di configurazione dell'agente si trova in C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

Puoi scaricare un file di configurazione di esempio e un token di autenticazione utilizzati dall'agente dalla console Google SecOps > Impostazioni SIEM > Agente di raccolta.

Personalizza le seguenti due sezioni nel file di configurazione:

• Ricevitore: specifica quali log devono essere raccolti e inviati a Google SecOps dall'agente.
• Exporter: specifica la destinazione a cui l'agente invia i log. Sono supportati i seguenti esportatori:
  • Esportatore Google SecOps: invia i log direttamente all'API di importazione di Google SecOps.
  • Esportatore di inoltro Google SecOps: invia i log all'inoltro Google SecOps.
  • Esportatore Cloud Logging: invia i log a Cloud Logging.

Nell'esportatore, personalizza quanto segue:

• customer_id: il tuo ID cliente Google SecOps.
• endpoint: l'endpoint regionale di Google SecOps.

• creds: il token di autenticazione.

  In alternativa, puoi utilizzare creds_file_path per fare riferimento direttamente al file delle credenziali. Per la configurazione di Windows, esegui l'escape del percorso con le barre rovesciate.

• log_type: Tipo di log. Ti consigliamo di selezionare WINDOWS_DNS come Tipo di log.

• ingestion_labels: etichette di importazione. Queste etichette identificano i log in Google SecOps.

• namespace: spazio dei nomi facoltativo.

  Per ogni tipo di log è necessario configurare un esportatore.

Esempi di configurazione della raccolta dei log

Le sezioni seguenti contengono esempi di configurazione per la raccolta dei log.

Inviare eventi Windows e Sysmon direttamente a Google SecOps

Configura questi parametri nell'esempio:

• chronicleexporter

  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

Configurazione di esempio:

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]

Inviare eventi Windows e syslog direttamente a Google SecOps

Configura questi parametri nell'esempio:

• windowseventlogreceiver
• tcplogreceiver
  • listen_address
• chronicleexporter
  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

Configurazione di esempio:

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

Inviare eventi Windows e syslog al forwarder Google SecOps

Configura questi parametri nell'esempio:

• windowseventlogreceiver
• tcplogreceiver
  • listen_address
• chronicleforwarder
  • endpoint

Configurazione di esempio:

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

Inviare syslog direttamente a Google SecOps

Configura questi parametri nell'esempio:

• tcplogreceiver
  • listen_address
• chronicleexporter
  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • Creds

Configurazione di esempio:

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

Raccogliere gli eventi di Windows da remoto e inviarli direttamente a Google SecOps

Configura questi parametri nell'esempio:

• windowseventlogreceiver
  • username
  • password
  • server
• chronicleexporter
  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

Configurazione di esempio:

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

Inviare dati a Cloud Logging

Configura il parametro credentials_file nell'esempio.

Configurazione di esempio:

exporters:
  googlecloud:
    credentials_file: /opt/observiq-otel-collector/credentials.json

Esegui una query su un database SQL e invia i risultati a Google SecOps

Configura questi parametri nell'esempio:

• sqlqueryreceiver
• chronicleexporter
  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

Configurazione di esempio:

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

Elimina i log che corrispondono a un'espressione regolare

Puoi configurare il raccoglitore in modo che elimini i log che corrispondono a un'espressione regolare. È utile per filtrare i log indesiderati, ad esempio errori noti o messaggi di debug.

Per eliminare i log che corrispondono a un'espressione regolare, aggiungi un processore di tipo filter/drop-matching-logs-to-Chronicle alla configurazione. Questo processore utilizza la funzione IsMatch per valutare il corpo del log rispetto all'espressione regolare. Se la funzione restituisce true, il log viene eliminato.

La seguente configurazione di esempio elimina i log che contengono le stringhe <EventID>10</EventID> o <EventID>4799</EventID> nel corpo del log.

Puoi personalizzare l'espressione regolare in modo che corrisponda a qualsiasi pattern di cui hai bisogno. La funzione IsMatch utilizza la sintassi delle espressioni regolari RE2.

Configurazione di esempio:

processors:
    filter/drop-matching-logs-to-Chronicle:
        error_mode: ignore
        logs:
            log_record:
                - (IsMatch(body, "<EventID>10</EventID>")) or (IsMatch(body, "<EventID>4799</EventID>"))

L'esempio seguente aggiunge il processore alla pipeline nella stessa configurazione:

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]

Funzionamento e manutenzione di Bindplane

Questa sezione descrive le operazioni di routine e le azioni di manutenzione.

Verificare una configurazione OTel

Per scoprire come verificare la configurazione di Bindplane OTel, consulta OTelBin.

Aggiornamenti delle release di collector

Bindplane può eseguire il polling di bindplane-otel-collector/releases per rilevare le nuove release del raccoglitore. Questa funzionalità è facoltativa.

Puoi disattivare il polling di GitHub impostando agentVersions.syncInterval su 0 nella configurazione di Bindplane:

agentVersions:
syncInterval: 0

Backup e ripristino di emergenza

Per informazioni su backup e ripristino di emergenza con Bindplane, consulta Risorse Bindplane.

Backup e ripristino di emergenza PostgreSQL

Per informazioni sul backup e sul ripristino di emergenza di PostgreSQL con Bindplane, consulta la documentazione di PostgreSQL.

Backup e ripristino di emergenza di BBolt

Per informazioni su backup e ripristino di emergenza di BBolt (ritirato) con Bindplane, consulta la documentazione di BBolt Store.

Resilienza e riprova

Per impostazione predefinita, i tentativi vengono abilitati su tutte le destinazioni che li supportano. Per impostazione predefinita, le richieste non riuscite vengono ritentate dopo cinque secondi e vengono ritardate progressivamente fino a 30 secondi. Dopo cinque minuti, le richieste vengono eliminate definitivamente.

Per saperne di più, consulta Resilienza del raccoglitore.

Ridurre il volume di log con il filtro di gravità

Per scoprire come ridurre il volume dei log, consulta Ridurre il volume dei log con il filtro per gravità.

Integrazioni di Bindplane con agenti di terze parti

Sebbene Bindplane sia più potente quando utilizzi l'agente Bindplane per la raccolta all'edge, nella maggior parte dei casi può rimanere all'interno della tua infrastruttura esistente. Ad esempio, se utilizzi già Fluent Bit o Splunk Universal Forwarders, puoi continuare a farlo.

Integrazione di Bindplane con Splunk

Per scoprire di più su Splunk con Bindplane, consulta quanto segue:

• Utilizzo di Splunk OTEL Collector con Bindplane
• Utilizzo di Splunk UF con Bindplane

Integrazioni di Bindplane con altri agenti di terze parti

Per informazioni sulle integrazioni di Bindplane con agenti di terze parti, consulta Connessione di altri raccoglitori OpenTelemetry utilizzando l'estensione OpAMP.

Monitoraggio host silenzioso

Per informazioni sull'utilizzo di Bindplane per il monitoraggio host silenzioso, consulta quanto segue:

• Monitoraggio host silenzioso di Google SecOps
• Configura Bindplane per SHM con Google Cloud Monitoring

Esegui l'upgrade di Bindplane su Linux

L'esecuzione del comando di installazione senza il flag --init alla fine è sufficiente per eseguire l'upgrade di Bindplane. Esegui questo script sul server Bindplane per eseguire l'upgrade di Bindplane. Per saperne di più, vedi Eseguire l'upgrade, il downgrade o la disinstallazione di Bindplane Server.

Monitorare Bindplane

Per scoprire di più sul monitoraggio di Bindplane, consulta Monitoraggio di Bindplane.

Monitoraggio di Kubernetes

Per scoprire di più sul monitoraggio di Kubernetes in Bindplane, consulta Monitoraggio di Kubernetes.

Documentazione di riferimento aggiuntiva

Per saperne di più su Bindplane (precedentemente noto come observIQ), consulta le seguenti risorse:

• Soluzioni Bindplane
• Guida rapida di Bindplane
• Tipi di log supportati per Google Cloud
• Filtrare per processore di condizioni
• Origini disponibili per Bindplane

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.