Use o Bindplane com o Google SecOps

Este documento descreve o Bindplane para o Google Security Operations.

O Bindplane é um pipeline de telemetria que pode recolher, refinar e exportar registos de qualquer origem para o Google SecOps.

O Bindplane oferece duas edições especialmente para o Google.

O Bindplane inclui os seguintes componentes principais:

• Bindplane Collector. Um agente de código aberto, baseado no OpenTelemetry (OTel) Collector. Recolhe registos de várias origens, incluindo registos de eventos do Microsoft Windows, e envia-os para o Google SecOps. Pode instalar os coletores no local ou na nuvem. Este componente também é denominado agente do Bindplane para o coletor do OpenTelemetry (BDOT), agente de recolha, coletor ou agente.
• Bindplane Server. Uma plataforma abrangente e unificada para gerir as suas implementações do coletor OTel. Estas implementações podem residir no Google SecOps e Google Cloud. O Bindplane Server pode ser executado no local ou na nuvem do Bindplane. Para mais informações acerca da consola, consulte o artigo Consola de gestão do Bindplane. Este componente também é denominado consola de gestão da pipeline de observabilidade (OP) do Bindplane ou consola de gestão do Bindplane.

Edições Google do Bindplane

O Bindplane oferece duas edições especialmente para a Google: Bindplane (Google Edition) e Bindplane Enterprise (Google Edition).

Bindplane (Google Edition)

Todos os clientes do Google SecOps têm acesso ao Bindplane (Google Edition) sem custos adicionais. Para saber mais, consulte o artigo Observabilidade e segurança líderes da indústria com tecnologia OpenTelemetry.

Pode usar o Bindplane (Google Edition) de forma autónoma na nuvem do Bindplane.

Para saber como começar a instalar e alojar o Bindplane (Google Edition) por si próprio, consulte o artigo Bindplane (Google Edition).

Bindplane Enterprise (Google Edition): para clientes do Google SecOps Enterprise Plus

O Bindplane Enterprise (Google Edition) está incluído para clientes do Google SecOps Enterprise Plus.

O Bindplane Enterprise (Google Edition) é recomendado para implementações em grande escala.

Contacte a equipa da Conta Google para receber a chave de licença do Bindplane Enterprise (Google Edition).

Edições do Google Bindplane: diferenças

A tabela seguinte indica as diferenças nas edições Google do Bindplane:

Consola de gestão do Bindplane

A utilização da consola de gestão do Bindplane é opcional. Muitos clientes do Google SecOps usam o Bindplane Server.

A consola de gestão do Bindplane oferece as seguintes funcionalidades principais:

• Gestão centralizada. A consola permite-lhe gerir todas as suas implementações do coletor OTel em Google Cloud. Pode ver o estado de cada implementação, bem como realizar tarefas de gestão comuns, como iniciar, parar e reiniciar coletores.
• Monitorização em tempo real. A consola oferece monitorização em tempo real das suas implementações do coletor OTel. Pode acompanhar métricas como a utilização da CPU, a utilização da memória e a taxa de transferência, bem como ver registos e rastreios para resolver problemas.
• Alertas e notificações. A consola permite-lhe configurar alertas e notificações para eventos importantes, como quando um coletor fica inativo ou quando um limite de métricas é excedido.
• Gestão da configuração. A consola permite-lhe gerir centralmente a configuração dos seus coletores OTel. Pode editar ficheiros de configuração, definir variáveis de ambiente e aplicar políticas de segurança a todas as suas implementações.
• Integração com Google Cloud. Pode criar e gerir implementações do coletor OTel no Google Cloud e usar a consola para aceder aos seus Google Cloud recursos.

Arquitetura do agente Bindplane

O agente do Bindplane pode ser executado no Linux ou no Docker como um servidor Web leve sem dependências externas.

O Bindplane usa o coletor BDOT para padronizar a gestão da telemetria com o protocolo de gestão de agentes abertos (OpAMP). Também pode criar e gerir distribuições personalizadas do OpenTelemetry Collector com o Bindplane.

Para saber mais sobre a arquitetura de implementação dos coletores do OpenTelemetry do Bindplane, consulte o artigo Bindplane OTel Collector.

As secções seguintes descrevem as opções de arquitetura disponíveis.

Os agentes de recolha enviam registos para um agente de recolha que atua como uma gateway

Para implementações em grande escala, recomendamos que use agentes Bindplane Enterprise (Google Edition) que atuam como gateways. Estas gateways recebem telemetria de outros coletores através da rede, realizam opcionalmente processamento adicional e encaminham os dados para o Google SecOps.

Um agente de recolha que atua como uma gateway usa o mesmo binário que todos os outros agentes de recolha.

O diagrama seguinte mostra agentes de recolha a enviar registos para um agente de recolha que funciona como uma gateway.

Os agentes de recolha enviam registos diretamente para a API de carregamento do Google SecOps

O diagrama seguinte mostra os agentes de recolha a enviar registos diretamente para a API de carregamento do Google SecOps.

Os agentes de recolha enviam registos diretamente para o Cloud Logging

O diagrama seguinte mostra agentes de recolha a enviar registos diretamente para o Cloud Logging.

Os agentes de recolha enviam registos para vários destinos

O diagrama seguinte mostra agentes de recolha a enviar registos para vários destinos.

Tipos de implementação do Bindplane

O Bindplane oferece opções de implementação na nuvem e nas instalações.

Implementações nas instalações

• Linux
• Docker

Para saber mais, consulte o artigo Instale o Bindplane Server.

Linux

Distribuições Linux:

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

Para saber mais, consulte o seguinte:

• Instale o Bindplane Server
• Transferências de pacotes

Imagens de contentores Docker

Pode encontrar imagens de contentores Docker do Bindplane nas seguintes localizações:

• Pacotes do GitHub: ghcr.io/observiq/Bindplane-ee
• Repositório de artefactos da Google: us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
• Docker hub: observiq/bindplane-ee

As imagens de contentores são etiquetadas com a versão de lançamento: por exemplo, o lançamento v1.35.0 tem a etiqueta observiq/bindplane-ee:1.35.0.

Requisitos técnicos e recomendações

Esta secção descreve os requisitos técnicos e as recomendações para instalar e executar o Bindplane com o Google SecOps.

Requisitos de largura de banda

O Bindplane mantém as ligações de rede para o seguinte:

• Gestão de coletores
• Medições do débito do coletor
• Interfaces de linhas de comando e de utilizador Web

Requisitos de conetividade

O Bindplane deteta a porta 3001 por predefinição. Esta porta é configurável.

A porta do Bindplane é usada para:

• Comando e controlo do coletor através do OpAMP (WebSocket)
• Pedidos de medição do débito do coletor (pedido HTTP POST)
• Utilizadores do navegador e da CLI (HTTP e WebSocket)

Os coletores têm de poder iniciar ligações ao Bindplane para OpAMP (WebSocket) e medições de débito (HTTP).

O Bindplane nunca inicia ligações aos coletores. Pode configurar uma firewall para impedir que o Bindplane alcance as redes do coletor. No entanto, as redes do coletor têm de conseguir alcançar o Bindplane na porta configurada.

Requisitos técnicos gerais do coletor do Bindplane

Para saber mais acerca dos requisitos técnicos gerais do coletor do Bindplane, consulte o seguinte:

• Bindplane OTel collector no GitHub
• Instale e desinstale coletores do Bindplane
• Pré-requisitos para a instalação
• Diretrizes de dimensionamento e escalabilidade do coletor

Requisitos de recursos do coletor

Os requisitos de recursos do Bindplane diferem com base no número de coletores geridos. À medida que o número de coletores geridos aumenta, a CPU, a memória, a taxa de transferência/IOPS do disco e o consumo de rede também aumentam.

Use a tabela seguinte para determinar o tamanho da CPU, da memória e da capacidade de armazenamento:

Planeie a instalação e a implementação

As secções seguintes incluem recomendações e práticas recomendadas que deve considerar quando planear a implementação do Bindplane.

Considere a escalabilidade e a tolerância a falhas

Os coletores de gateway recebem dados de telemetria através da rede. Recomendamos que os associe a um equilibrador de carga para oferecer tolerância a falhas e escalabilidade horizontal.

A escalabilidade horizontal é preferível porque oferece tolerância a falhas e pode eliminar os obstáculos dos exportadores.

Calcule de quantos coletores precisa

Ao calcular o número de coletores necessários para a sua carga de trabalho, considere o débito ou a taxa de registo previstos e use a tabela seguinte. Esta tabela pressupõe que cada coletor tem quatro núcleos de CPU e 16 GB de memória. A tabela não tem em conta os processadores. Quando são adicionados processadores, os requisitos de computação aumentam.

Aprovisione em excesso a frota de coletores para tolerância a falhas

Aprovisione em excesso a frota de coletores para garantir a tolerância a falhas. Caso um ou mais sistemas de recolha falhem ou sejam colocados offline para manutenção, os restantes coletores têm de ter capacidade suficiente para gerir o débito de telemetria.

Se estiver a trabalhar com um número fixo de coletores, pode implementar o escalonamento vertical da respetiva CPU e memória para aumentar a taxa de transferência.

Reduza a sobrecarga de processamento

Geralmente, quer que os seus coletores façam o mínimo de trabalho possível. Se tiver requisitos de processamento elevados, pode ser útil transferir esse processamento para uma frota de coletores de gateway. Por exemplo, em vez de filtrar a telemetria com uma operação de expressão regular dispendiosa, pode fazer com que os coletores de gateway realizem essa tarefa. Geralmente, os coletores de gateway são executados num sistema dedicado. Isto justifica a sobrecarga de processamento, uma vez que não consome a capacidade de computação de outros serviços em execução no mesmo sistema, ao contrário de um coletor não de gateway que pode estar em execução num servidor de base de dados.

Práticas recomendadas para o modo de gateway

Quando usa um agente de recolha do Bindplane como gateway, ou seja, no modo de gateway, planeie a implementação com as seguintes práticas recomendadas:

• Coloque, pelo menos, dois coletores atrás de um balanceador de carga.
• Cada coletor deve ter um mínimo de dois núcleos.
• Cada coletor deve ter, no mínimo, 8 GB de memória.
• Cada coletor deve ter 60 GB de espaço utilizável para uma fila persistente.

Use um balanceador de carga quando necessário

É necessário um balanceador de carga quando o Bindplane é operado no modo de alta disponibilidade.

Quando usa um agente de recolha do Bindplane no modo de gateway, use um equilibrador de carga para aumentar o desempenho e a redundância. O equilíbrio de carga também permite o escalonamento horizontal da sua frota de gateways e a capacidade de resistir a falhas sem causar interrupções.

O agente de recolha do Bindplane pode funcionar com uma vasta gama de equilibradores de carga quando funciona no modo de gateway. Este documento não aborda opções específicas, porque as soluções de equilíbrio de carga mais populares suportam as funcionalidades necessárias para operar vários coletores de forma fiável.

Para saber mais, consulte o artigo Load Balancer.

Porto e protocolos de balanceamento de carga

O Bindplane deteta a porta 3001 por predefinição.

Para suportar a vasta gama de recetores baseados na rede no OpenTelemetry, o equilibrador de carga tem de suportar:

• Protocolos de transporte TCP/UDP
• Protocolos de aplicação HTTP e gRPC

Dimensionamento do balanceamento de carga

Os nós do Bindplane não devem gerir mais de 30 000 coletores para uma tolerância a falhas máxima. Cada coletor abre duas ligações ao Bindplane (uma para a gestão remota do OpAMP e outra para publicar métricas de débito). Este limite ajuda a garantir que não excede o limite de ligação de aproximadamente 65 535 por instância de back-end imposto pela maioria dos equilibradores de carga.

Se uma organização tiver 100 000 coletores, um tamanho do cluster de três seria insuficiente. Cada nó seria responsável por aproximadamente 33 000 coletores, o que se traduz em 66 000 ligações TCP por instância do Bindplane. Esta situação piora se um nó for desativado para manutenção, uma vez que cada instância do Bindplane restante geriria 50 000 coletores ou 100 000 ligações TCP.

Práticas recomendadas para dimensionar o balanceamento de carga

• Implemente verificações de funcionamento. Configure o balanceador de carga para se certificar de que o coletor está pronto para receber tráfego.
• Distribuir as ligações uniformemente. As associações devem ser distribuídas uniformemente entre os coletores.

• Suportar protocolos necessários. Para suportar a vasta gama de recetores baseados na rede no OpenTelemetry, o equilibrador de carga tem de suportar:

  • Protocolos de transporte TCP/UDP
  • Protocolos de aplicação HTTP e gRPC

Para saber mais, consulte o artigo Resiliência do coletor.

Balanceamento de carga do tipo de origem

Qualquer tipo de origem que receba telemetria de sistemas remotos através da rede é um candidato adequado para o equilíbrio de carga, incluindo o seguinte:

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

Use o modo de alta disponibilidade em ambientes de produção

Pode implementar uma instância do Bindplane numa configuração de instância única ou de várias instâncias. Para implementações de produção que requerem elevada disponibilidade (HA) e resiliência, recomendamos que use um modelo de implementação de várias instâncias (HA).

Quando o Bindplane gere mais de 25 000 coletores, recomendamos que opere o Bindplane no modo de alta disponibilidade (HA).

Para saber mais sobre a HA no Bindplane, consulte o artigo Alta disponibilidade.

Calcule o número de coletores e servidores Bindplane para HA

Quando opera o Bindplane no modo de HA, tem de considerar quantos coletores espera que cada servidor do Bindplane processe.

Pegue no número total de instâncias do Bindplane e subtraia o número máximo de nós que espera que fiquem indisponíveis devido à manutenção. Certifique-se de que cada nó gere, no máximo, 30 000 coletores durante uma indisponibilidade do nó.

Postgres para HA

O Postgres é um pré-requisito quando opera o Bindplane no modo de HA.

Prometheus para HA

O Prometheus é necessário quando opera o Bindplane no modo de HA.

Para saber mais, consulte o artigo Prometheus.

Barramento de eventos para HA

O Bindplane usa um barramento de eventos para comunicar entre componentes no Bindplane. Quando opera o Bindplane no modo HA, pode usar o barramento de eventos para enviar eventos entre servidores do Bindplane.

Para saber mais, consulte o artigo Event Bus.

Use uma implementação de instância única para um ambiente de teste ou uma prova de conceito

Para um ambiente de teste ou uma prova de conceito, recomendamos que use uma implementação de instância única.

Para saber mais, consulte o artigo Instância única.

Isole as credenciais de back-end

Em vez de implementar credenciais em todos os sistemas de recolha, pode manter as credenciais exclusivamente nos recolhedores de gateway. Isto simplifica a rotação de credenciais e reduz a superfície de ataque de segurança, limitando a implementação de credenciais a um subconjunto dos seus sistemas.

Proteja os seus coletores de gateway com uma firewall

Pode colocar coletores de gateway numa rede de perímetro, protegida por firewall da rede interna. Pode configurar a sua rede para permitir que os outros coletores encaminhem dados para os coletores de gateway, ao mesmo tempo que impede que os coletores de gateway acedam à rede da sua aplicação. Isto permite-lhe enviar telemetria para um back-end baseado na nuvem sem conceder aos seus pontos finais acesso direto à Internet.

A firewall tem de permitir que o tráfego HTTP alcance o Bindplane na porta configurada.

Valide a configuração da firewall

Todas as firewalls ou proxies autenticados entre o agente e a Internet requerem regras para abrir o acesso aos seguintes anfitriões:

Use o PostgreSQL para implementações de produção

O Postgres é necessário para implementações de produção do Bindplane.

O Postgres é um pré-requisito para operar o Bindplane no modo de HA.

Geralmente, o número de núcleos da CPU e a memória disponível limitam o desempenho dos back-ends de armazenamento do PostgreSQL. Recomendamos que faça uma cópia de segurança do armazenamento do PostgreSQL com armazenamento de alta capacidade de processamento e baixa latência, como unidades de estado sólido (SSDs).

Para saber mais, consulte o seguinte:

• Documentação do PostgreSQL
• Guia de configuração do Postgres
• Configuração da loja Postgres
• Configuração do TLS do Postgres

Implemente a autenticação adequada

O Bindplane suporta a autenticação com os seguintes protocolos e serviços. Certifique-se de que estão implementados corretamente:

• Azure Entra LDAP. Para saber mais, consulte os artigos Azure LDAP e Alterar o tipo de autenticação do Bindplane.
• LDAP.
• OpenID Connect (OIDC).
• Local.
• SAML.
• TLS do Postgres. Para saber mais, consulte TLS do Postgres.
• Kubernetes. Para saber mais, consulte o artigo Identidade da carga de trabalho do GKE.

Instale a consola de gestão do Bindplane

A maioria dos clientes do Google SecOps usa a consola de gestão do Bindplane. Se o estiver a instalar, precisa de acesso ao storage.googleapis.com. Se estiver a instalar apenas o agente, este acesso não é necessário.

O Bindplane Cloud também está disponível para clientes Google. Transfira a versão gratuita e envie um email para support@bindplane.com para pedir uma atualização para a versão suportada pela Google.

Existem três formas de implementar a consola de gestão do Bindplane:

• Bindplane Cloud: oferta de SaaS da Bindplane para o Bindplane Server.
• Transferência e instalação num anfitrião Linux: disponível como um pacote DEB, um pacote RPM ou uma imagem Docker.
• Instale e aprovisione a partir do Google Cloud Marketplace.

Instale o agente do Bindplane

Esta secção descreve como instalar o agente do Bindplane para o Google SecOps em diferentes sistemas operativos de anfitrião.

Normalmente, os coletores de agentes usam recursos mínimos. No entanto, quando processar grandes volumes de registos, tenha em atenção o consumo de recursos para evitar afetar outros serviços. Para mais informações, consulte os artigos Requisitos técnicos e recomendações, Planeie a instalação e a implementação e Dimensionamento e escalabilidade do agente.

Para saber como instalar o agente OTel, consulte o artigo Instale e desinstale coletores do Bindplane.

Para problemas relacionados com o coletor, contacte o Google Cloud apoio técnico.

Para instalar o agente, precisa do seguinte:

• Ficheiro de autenticação de carregamento do Google SecOps

  Para transferir o ficheiro de autenticação, siga estes passos:

  1. Abra a consola do Google SecOps.
  2. Aceda a Definições do SIEM > Agente de recolha.
  3. Transfira o ficheiro de autenticação de carregamento do Google SecOps.

• ID de cliente do Google SecOps

  Para encontrar o ID de cliente, siga estes passos:

  1. Abra a consola do Google SecOps.
  2. Aceda a Definições do SIEM > Perfil.
  3. Copie o ID de cliente da secção Detalhes da organização.

• Windows 2012 SP2 ou posterior ou anfitrião Linux com systemd

• Conetividade à Internet

• Acesso ao GitHub

Ferramentas de implementação

Esta secção descreve as ferramentas de implementação do Bindplane.

GitOps

Implemente recursos do Bindplane através de um modelo GitOps, que inclui o seguinte:

• Autenticação do Bindplane
• Bindplane CLI
• Acesso à rede
• Integração com um repositório do GitHub e ações do GitHub
• Exportar recursos existentes
• Gerir valores sensíveis
• Estabelecer um fluxo de trabalho da GitHub Actions
• Instruções passo a passo para confirmar e testar a configuração, ativar implementações automáticas e atualizar recursos através de edições diretas ou do método de exportação da IU
• Atualizar valores confidenciais e usar o RBAC

Para saber mais, consulte o artigo GitOps.

Ansible

Para saber como implementar o Bindplane com o Ansible, consulte bindplane-agent-ansible.

Bindplane CLI

Para saber mais sobre a CLI do Bindplane, consulte GitOps.

Terraform

Para saber como usar o Terraform para configurar os seus recursos do Bindplane, consulte o fornecedor do Bindplane.

Kubernetes

Para saber mais sobre o Kubernetes com o Bindplane, consulte o seguinte:

• Nome do cluster dinâmico do Kubernetes
• Migração do Postgres para o Kubernetes

Instale o agente do Bindplane no Windows

Para instalar o agente Bindplane no Windows, execute o seguinte comando do PowerShell:

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

Em alternativa, para instalar através de um assistente de instalação, transfira o instalador mais recente para Windows. Depois de transferir o instalador, abra o assistente de instalação e siga as instruções para configurar e instalar o agente Bindplane.

Para saber como instalar o agente Bindplane no Windows, consulte o artigo Instalação no Windows.

Instale o agente do Bindplane no Linux

Pode instalar o agente no Linux através de um script que determina automaticamente que pacote instalar. Também pode usar o mesmo script para atualizar uma instalação existente.

Para instalar através do script de instalação, execute o seguinte script:

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

Para saber mais sobre a configuração do coletor, consulte bindplane-otel-collect.

Instalação a partir de um pacote local

Para instalar o agente a partir de um pacote local, use -f com o caminho para o pacote.

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

Instalação de RPM

Transfira o pacote RPM para a sua arquitetura na página de lançamentos e instale o pacote com rpm. Consulte o exemplo seguinte para instalar o pacote amd64:

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

Substitua VERSION pela versão do pacote que transferiu.

Instalação DEB

Transfira o pacote DEB para a sua arquitetura a partir da página de lançamentos e instale o pacote através do dpkg. Consulte o exemplo seguinte para instalar o pacote amd64:

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

Substitua VERSION pela versão do pacote que transferiu.

Para saber mais, consulte o artigo Instalação do agente Bindplane.

Configure o agente do Bindplane

Após a instalação do agente, o serviço observiq-otel-collector é executado e está pronto para a configuração.

Pode configurar o agente manualmente ou através da consola de gestão do Bindplane.

Se estiver a configurar o agente manualmente, tem de atualizar os parâmetros do exportador para garantir que o agente se autentica com o Google SecOps.

Ficheiro de configuração do coletor OTel

No Linux, o ficheiro de configuração do coletor encontra-se em /opt/observiq-otel-collector/config.yaml.

Serviço e registos do coletor OTel

Por predefinição, o agente regista-se no C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

O registo de erros padrão do processo do agente pode ser encontrado em C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

Para saber mais sobre a configuração do coletor, consulte bindplane-otel-collect.

No Linux, para ver os registos do coletor, execute sudo tail -F /opt/observiq-otel-collector/log/collector.log.

Comandos comuns do serviço de recolha do OTel do Linux:

• Para parar o serviço do coletor OTel, execute sudo systemctl stop observiq-otel-collector.

• Para iniciar o serviço do coletor OTel, execute sudo systemctl start observiq-otel-collector.

• Para reiniciar o serviço do coletor OTel, execute sudo systemctl restart observiq-otel-collector.

• Para ativar o serviço do coletor OTel no arranque, execute sudo systemctl enable observiq-otel-collector.

Reinicie o serviço do agente para as alterações de configuração

Quando alterar a configuração, tem de reiniciar o serviço do agente para que as alterações de configuração entrem em vigor (sudo systemctl restart observiq-otel-collector).

Use um ficheiro de configuração de exemplo predefinido

Por predefinição, um ficheiro de configuração do agente está localizado em C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

Pode transferir um ficheiro de configuração de exemplo e um token de autenticação usados pelo agente a partir da consola do Google SecOps > Definições do SIEM > Agente de recolha.

Personalize as duas secções seguintes no ficheiro de configuração:

• Receiver: especifica que registos o agente deve recolher e enviar para o Google SecOps.
• Exporter: especifica o destino para onde o agente envia os registos. Os seguintes exportadores são suportados:
  • Exportador do Google SecOps: envia registos diretamente para a API de carregamento do Google SecOps.
  • Exportador do encaminhador do Google SecOps: envia registos para o encaminhador do Google SecOps.
  • Exportador do Cloud Logging: envia registos para o Cloud Logging.

No exportador, personalize o seguinte:

• customer_id: o seu ID de cliente do Google SecOps.
• endpoint: o seu ponto final regional do Google SecOps.

• creds: o seu token de autenticação.

  Em alternativa, pode usar creds_file_path para fazer referência diretamente ao ficheiro de credenciais. Para a configuração do Windows, escape o caminho com barras invertidas.

• log_type: tipo de registo. Recomendamos que selecione WINDOWS_DNS como o Tipo de registo.

• ingestion_labels: etiquetas de carregamento. Estas etiquetas identificam os registos no Google SecOps.

• namespace: espaço de nomes opcional.

  Cada tipo de registo requer a configuração de um exportador.

Exemplos de configuração de recolha de registos

As secções seguintes contêm exemplos de configuração para a recolha de registos.

Envie eventos do Windows e sysmon diretamente para o Google SecOps

Configure estes parâmetros no exemplo:

• chronicleexporter

  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

Configuração de exemplo:

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]

Envie eventos do Windows e syslog diretamente para o Google SecOps

Configure estes parâmetros no exemplo:

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

Configuração de exemplo:

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

Envie eventos do Windows e syslog para o encaminhador do Google SecOps

Configure estes parâmetros no exemplo:

• windowseventlogreceiver
• tcplogreceiver
  • listen_address
• chronicleforwarder
  • endpoint

Configuração de exemplo:

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

Envie o syslog diretamente para o Google SecOps

Configure estes parâmetros no exemplo:

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

Configuração de exemplo:

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

Recolha eventos do Windows remotamente e envie-os diretamente para o Google SecOps

Configure estes parâmetros no exemplo:

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

Configuração de exemplo:

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

Envie dados para o Cloud Logging

Configure o parâmetro credentials_file no exemplo.

Configuração de exemplo:

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

Consultar uma base de dados SQL e enviar os resultados para o Google SecOps

Configure estes parâmetros no exemplo:

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

Configuração de exemplo:

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

Rejeite registos que correspondam a uma expressão regular

Pode configurar o coletor para rejeitar registos que correspondam a uma expressão regular. Isto é útil para filtrar registos indesejados, como erros conhecidos ou mensagens de depuração.

Para rejeitar registos que correspondam a uma expressão regular, adicione um processador do tipo filter/drop-matching-logs-to-Chronicle à sua configuração. Este processador usa a função IsMatch para avaliar o corpo do registo em relação à expressão regular. Se a função devolver true, o registo é ignorado.

A configuração de exemplo seguinte rejeita registos que contenham as strings <EventID>10</EventID> ou <EventID>4799</EventID> no corpo do registo.

Pode personalizar a expressão regular para corresponder a qualquer padrão de que necessite. A função IsMatch usa a sintaxe de expressão regular RE2.

Configuração de exemplo:

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

O exemplo seguinte adiciona o processador ao pipeline na mesma configuração:

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]

Operação e manutenção do Bindplane

Esta secção descreve as ações de funcionamento e manutenção de rotina.

Valide uma configuração do OTel

Para saber como validar a configuração do OTel do Bindplane, consulte OTelBin.

Atualizações de lançamento do coletor

O Bindplane pode sondar bindplane-otel-collector/releases para detetar novos lançamentos do coletor. Esta funcionalidade é opcional.

Pode desativar a sondagem do GitHub definindo agentVersions.syncInterval como 0 na configuração do Bindplane:

agentVersions:
syncInterval: 0

Cópia de segurança e recuperação de desastres

Para saber mais sobre a cópia de segurança e a recuperação de desastres com o Bindplane, consulte os recursos do Bindplane.

Cópia de segurança e recuperação de desastres do PostgreSQL

Para saber mais sobre a cópia de segurança e a recuperação de desastres do PostgreSQL com o Bindplane, consulte a documentação do PostgreSQL.

Cópia de segurança e recuperação de desastres do BBolt

Para saber mais sobre a cópia de segurança e a recuperação de desastres do BBolt (descontinuado) com o Bindplane, consulte a documentação da loja do BBolt.

Resiliência e nova tentativa

A repetição é ativada por predefinição em todos os destinos que a suportam. Por predefinição, as solicitações com falhas são repetidas após cinco segundos e são progressivamente anuladas durante um máximo de 30 segundos. Após cinco minutos, os pedidos são ignorados permanentemente.

Para saber mais, consulte o artigo Resiliência do coletor.

Reduza o volume de registos com o filtro de gravidade

Para saber como reduzir o volume de registos, consulte o artigo Reduza o volume de registos com o filtro de gravidade.

Integrações do Bindplane com agentes de terceiros

Embora o Bindplane seja mais eficaz quando usa o agente do Bindplane para recolha na extremidade, na maioria dos casos, o Bindplane pode permanecer na sua infraestrutura existente. Por exemplo, se já estiver a usar o Fluent Bit ou os encaminhadores universais do Splunk, pode continuar a fazê-lo.

Integração do Bindplane com o Splunk

Para saber mais sobre o Splunk com o Bindplane, consulte o seguinte:

• Usar o coletor OTEL do Splunk com o Bindplane
• Usar o Splunk UF com o Bindplane

Integrações do Bindplane com outros agentes de terceiros

Para saber mais sobre as integrações do Bindplane com agentes de terceiros, consulte o artigo Ligar outros coletores do OpenTelemetry através da extensão OpAMP.

Monitorização de anfitriões silenciosos

Para obter informações sobre a utilização do Bindplane para a monitorização de anfitriões silenciosos, consulte o seguinte:

• Monitorização silenciosa de anfitriões do Google SecOps
• Configure o Bindplane para SHM com o Google Cloud Monitoring

Atualize o Bindplane no Linux

A execução do comando de instalação sem a flag --init no final é suficiente para atualizar o Bindplane. Execute este script no seu servidor do Bindplane para atualizar o Bindplane. Para saber mais, consulte o artigo Atualize, altere para uma versão anterior ou desinstale o Bindplane Server.

Monitorize o Bindplane

Para saber como monitorizar o Bindplane, consulte o artigo Monitorizar o Bindplane.

Monitorização do Kubernetes

Para saber mais sobre a monitorização do Kubernetes no Bindplane, consulte o artigo Monitorização do Kubernetes.

Documentação de referência adicional

Para saber mais sobre o Bindplane (anteriormente conhecido como observIQ), consulte o seguinte:

• Bindplane Solutions
• Guia de início rápido do Bindplane
• Tipos de registos suportados para Google Cloud
• Filtre por processador de condições
• Origens disponíveis para o Bindplane

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais da Google SecOps.