Usar o Bindplane com o Google SecOps

Compatível com:

Este documento descreve o Bindplane para o Google Security Operations.

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

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

O Bindplane inclui os seguintes componentes principais:

  • Coletor do Bindplane. Um agente de código aberto baseado no OpenTelemetry (OTel) Collector. Ele coleta registros de várias fontes, incluindo logs de eventos do Microsoft Windows, e os envia para o Google SecOps. É possível instalar os coletores no local ou na nuvem.

    Esse componente também pode ser chamado de Coletor da distribuição do Bindplane para OpenTelemetry (BDOT), agente do Bindplane, agente de coleta, coletor ou agente.

  • Servidor do Bindplane. Uma plataforma abrangente e unificada para gerenciar suas implantações de coletores do OTel. Essas implantações podem estar no Google SecOps e no Google Cloud. Muitos clientes do Google SecOps usam o Bindplane Server, mas o uso dele é opcional. O servidor do Bindplane pode ser executado no local ou na nuvem do Bindplane. Para mais informações sobre o servidor, consulte Servidor do BindPlane.

    Esse componente também pode ser chamado de console de gerenciamento do pipeline de observabilidade (OP) do Bindplane ou console de gerenciamento do Bindplane.

Edições do Google do Bindplane

O Bindplane oferece duas edições especialmente para o Google: Bindplane (edição do Google) e Bindplane Enterprise (edição do Google).

Bindplane (edição do Google)

O Bindplane (edição do Google) é fornecido a todos os clientes do Google SecOps.

Você pode usar o autoatendimento do Bindplane (Google Edition) na nuvem do Bindplane.

Para começar a instalar e auto-hospedar o Bindplane (Google Edition) ou gerar sua chave para um servidor Bindplane local, consulte Bindplane (Google Edition).

Bindplane Enterprise (edição do Google): para clientes do Google SecOps Enterprise Plus

O Bindplane Enterprise (edição do Google) está incluído para clientes do Google SecOps Enterprise Plus.

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

Entre em contato com a equipe da sua Conta do Google para receber a chave de licença do Bindplane Enterprise (Google Edition).

Edições do Bindplane no Google: diferenças

A tabela a seguir lista as diferenças entre as edições do Bindplane no Google:

Tópico/recurso Bindplane (edição do Google) Bindplane Enterprise (edição do Google)
Custo Incluído sem custo financeiro adicional para todos os clientes do Google SecOps Incluído sem custos financeiros para clientes do Google SecOps Enterprise Plus
Trajetos/destinos Somente o Google, incluindo o Google SecOps, o Cloud Logging, o BigQuery e o Cloud Storage pelo Google SecOps do Google, incluindo 12 meses de roteamento para um destino que não seja do Google para migrações de SIEM
Filtragem Filtro básico com expressão regular Processadores de filtragem avançada (por exemplo, filtrar por condição, campo, gravidade etc.), redução de dados, amostragem de registros, remoção de duplicação
edição N/A Mascaramento de PII
Transformação Adicionar campo, mover campo, analisar dados (KV, JSON, CSV, XML, carimbo de data/hora, análise por expressão regular), renomear campo, separador de eventos Inclui todos os recursos compatíveis com o Bindplane (Google Edition) mais campo de exclusão, exclusão de valores vazios, coalescência
Recursos gerais no nível da plataforma Gateway (agrega dados de coletores), coletores do Bindplane, servidor do Bindplane (camada de gerenciamento do Bindplane) local ou hospedado na nuvem, todas as fontes, monitoramento silencioso de host pelo processador do Google SecOps, fila persistente, telemetria de enriquecimento, alta disponibilidade, RBAC, APIs de ingestão do Google SecOps compatíveis, ofuscação de credenciais, gerenciamento avançado de frota, incluindo agrupamento de coletores, atribuição dinâmica de tipo de registro Todos os recursos compatíveis com o Bindplane (Google Edition)

Arquitetura do coletor do Bindplane

O Bindplane usa o coletor BDOT, genericamente chamado de coletor, para padronizar o gerenciamento de telemetria com o Open Agent Management Protocol (OpAMP). Também é possível criar e gerenciar distribuições personalizadas do OpenTelemetry Collector com o Bindplane.

O coletor pode ser executado no Linux ou no Docker como um servidor da Web leve sem dependências externas.

Para saber mais sobre a arquitetura de implantação dos coletores do Bindplane OpenTelemetry, consulte Implantação.

As seções a seguir descrevem as opções de arquitetura disponíveis.

Os coletores enviam registros para um coletor que atua como gateway

Para implantações em grande escala, recomendamos o uso de coletores do Bindplane Enterprise (Google Edition) que atuam como gateways. Esses gateways recebem telemetria de outros coletores pela rede, realizam processamento adicional (opcional) e encaminham os dados para o Google SecOps.

Um coletor que atua como gateway usa o mesmo binário que todos os outros coletores.

O diagrama a seguir mostra coletores enviando registros para um coletor que atua como gateway:

Os coletores enviam registros para um coletor que atua como gateway

Os coletores enviam registros diretamente para a API de ingestão do Google SecOps

O diagrama a seguir mostra coletores enviando registros diretamente para a API de ingestão do Google SecOps:

Os coletores enviam registros diretamente para a API de ingestão do Google SecOps

Os coletores enviam registros diretamente para o Cloud Logging

O diagrama a seguir mostra coletores enviando registros diretamente para o Cloud Logging:

Os coletores enviam registros diretamente para o Cloud Logging

Os coletores enviam registros para vários destinos

O diagrama a seguir mostra coletores enviando registros para vários destinos:

O coletor envia registros para vários destinos

Servidor do Bindplane

O servidor do BindPlane oferece os seguintes recursos principais:

  • Gerenciamento centralizado. O servidor permite gerenciar todas as implantações do coletor do OTel em Google Cloud. É possível conferir o status de cada implantação e realizar tarefas comuns de gerenciamento, como iniciar, parar e reiniciar coletores.
  • Monitoramento em tempo real. O servidor oferece monitoramento em tempo real das implantações do coletor OTel. É possível acompanhar métricas como uso da CPU, uso da memória e capacidade de transferência. Também é possível consultar registros e rastreamentos para resolver problemas.
  • Alertas e notificações. O servidor permite configurar alertas e notificações para eventos importantes, como quando um coletor fica inativo ou quando um limite de métricas é excedido.
  • Gerenciamento de configurações. O servidor permite gerenciar centralmente a configuração dos coletores do OTel. É possível editar arquivos de configuração, definir variáveis de ambiente e aplicar políticas de segurança a todos os seus implantações.
  • Integração com Google Cloud. É possível criar e gerenciar implantações do coletor OTel no Google Cloud e usar o servidor para acessar seus recursos do Google Cloud .

O Bindplane oferece opções de implantação na nuvem e no local. Para mais informações, consulte Usar o servidor do Bindplane.

Requisitos e recomendações técnicas

Nesta seção, descrevemos os requisitos e as recomendações técnicas para instalar e executar o Bindplane com o Google SecOps.

Requisitos de largura de banda

O Bindplane mantém conexões de rede para o seguinte:

  • Gerenciamento de coletores
  • Medições de capacidade de processamento do coletor
  • Interfaces de linha de comando e de usuário da Web

Requisitos de conectividade

Por padrão, o Bindplane detecta a porta 3001. Essa porta é configurável.

A porta do Bindplane é usada para:

  • Comando e controle do coletor usando OpAMP (WebSocket)
  • Solicitações de medição de taxa de transferência do coletor (solicitação HTTP POST)
  • Usuários de navegador e CLI (HTTP e WebSocket)

Os coletores precisam iniciar conexões com o Bindplane para OpAMP (WebSocket) e medições de capacidade (HTTP).

O Bindplane nunca inicia conexões com os coletores. É possível configurar um firewall para impedir que o Bindplane alcance as redes do coletor. No entanto, as redes do coletor precisam conseguir alcançar o Bindplane na porta configurada.

Requisitos técnicos gerais do coletor do Bindplane

Para saber mais sobre os requisitos técnicos gerais do coletor do BindPlane, consulte:

Requisitos de recursos do coletor

Os requisitos de recursos do Bindplane variam de acordo com o número de coletores gerenciados. À medida que o número de coletores gerenciados aumenta, o mesmo acontece com o consumo de CPU, memória, capacidade/IOPS de disco e rede.

Use a tabela a seguir para dimensionar a capacidade de CPU, memória e armazenamento:

Contagem de coletores Nós do Bindplane Tolerância a falhas Núcleos da CPU Memória banco de dados
1 a 100 1 N/A 2 4 GB bbolt
100 a 25.000 1 N/A 4 16 GB postgres
1 a 60.000 3 1 2 8 GB postgres
60.001 a 125.000 5 1 2 8 GB postgres
125.001 a 250.000 10 2 2 8 GB postgres

Planejar a instalação e a implantação

As seções a seguir incluem recomendações e práticas recomendadas que você deve considerar ao planejar a implantação do Bindplane.

Considere o escalonamento e a tolerância a falhas

O escalonamento horizontal é preferível porque oferece tolerância a falhas e pode eliminar gargalos do exportador.

Ao executar coletores do Bindplane no modo de gateway, recomendamos que você os pareie com um balanceador de carga para oferecer tolerância a falhas e escalonamento horizontal.

Calcular quantos coletores são necessários

Ao calcular o número de coletores necessários para sua carga de trabalho, considere a taxa de transferência ou de registros esperada e use a tabela a seguir. Esta tabela pressupõe que cada coletor tem quatro núcleos de CPU e 16 GB de memória. A tabela não inclui cálculos com processadores. Quando eles são adicionados, os requisitos de computação aumentam.

Capacidade de processamento de telemetria Registros/segundo Coletores
5 GB/m 250.000 2
10 GB/m 500.000 3
20 GB/m 1.000.000 5
100 GB/m 5.000.000 25

Fazer o superprovisionamento da frota de coletores para tolerância a falhas

Faça o overprovisioning da frota de coletores para garantir a tolerância a falhas. Se um ou mais sistemas de coleta falharem ou forem desativados para manutenção, os coletores restantes precisarão ter capacidade suficiente para gerenciar a taxa de transferência de telemetria.

Se você estiver trabalhando com um número fixo de coletores, implemente o escalonamento vertical da CPU e da memória deles para aumentar a capacidade de transferência.

Reduzir a sobrecarga de processamento

Em geral, é melhor que os coletores façam o mínimo de trabalho possível. Se você tiver requisitos de processamento pesados, pode ser útil descarregar 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 cara, você pode fazer com que os coletores de gateway executem essa tarefa. Em geral, os coletores de gateway são executados em um sistema dedicado. Isso justifica a sobrecarga de processamento porque não consome o poder de computação de outros serviços em execução no mesmo sistema, ao contrário de um coletor não gateway que pode estar sendo executado em um servidor de banco de dados.

Práticas recomendadas para o modo gateway

Ao executar coletores do Bindplane no modo de gateway, recomendamos que você planeje a implantação com as seguintes práticas recomendadas:

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

Use um balanceador de carga quando necessário

Um balanceador de carga é necessário quando você opera o Bindplane no modo de alta disponibilidade.

Ao executar coletores do Bindplane no modo de gateway, use um balanceador de carga para aumentar o desempenho e a redundância. O balanceamento de carga também permite o escalonamento horizontal da frota de gateways e a capacidade de resistir a falhas sem causar interrupções.

O coletor do Bindplane pode trabalhar com uma ampla variedade de balanceadores de carga.

Para saber mais, consulte Balanceador de carga.

Porta e protocolos de balanceamento de carga

Por padrão, o Bindplane detecta a porta 3001.

Para oferecer suporte à ampla variedade de receptores baseados em rede no OpenTelemetry, o balanceador de carga precisa ser compatível com:

  • Protocolos de transporte TCP/UDP
  • Protocolos de aplicativo HTTP e gRPC

Dimensionamento do balanceamento de carga

Os nós do Bindplane não podem gerenciar mais de 30.000 coletores para ter tolerância a falhas máxima. Cada coletor abre duas conexões com o Bindplane (uma para gerenciamento remoto do OpAMP e outra para publicação de métricas de capacidade de transmissão). Esse limite ajuda a garantir que você não exceda o limite de conexão de aproximadamente 65.535 por instância de back-end imposto pela maioria dos balanceadores de carga.

Se uma organização tiver 100.000 coletores, um tamanho de cluster de três será insuficiente. Cada nó seria responsável por aproximadamente 33.000 coletores, o que se traduz em 66.000 conexões TCP por instância do Bindplane. Essa situação piora se um nó for desativado para manutenção, já que cada instância restante do Bindplane gerenciaria 50.000 coletores ou 100.000 conexões TCP.

Práticas recomendadas de dimensionamento do balanceamento de carga

  • Implemente verificações de integridade. Configure o balanceador de carga para garantir que o coletor esteja pronto para receber tráfego.
  • Distribua as conexões de maneira uniforme. As conexões precisam ser distribuídas igualmente entre os coletores.

  • Suporte aos protocolos necessários. Para oferecer suporte à ampla variedade de receptores baseados em rede no OpenTelemetry, o balanceador de carga precisa ser compatível com:

    • Protocolos de transporte TCP/UDP
    • Protocolos de aplicativo HTTP e gRPC

Para saber mais, consulte Resiliência do coletor.

Balanceamento de carga do tipo de origem

Qualquer tipo de origem que receba telemetria de sistemas remotos pela rede é um candidato adequado para o balanceamento de carga, incluindo:

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

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

É possível implantar uma instância do Bindplane em uma configuração de instância única ou várias instâncias. Para implantações de produção que exigem alta disponibilidade (HA) e resiliência, recomendamos o uso de um modelo de implantação de várias instâncias (HA).

Quando o Bindplane gerencia mais de 25.000 coletores, recomendamos que você opere o Bindplane no modo de alta disponibilidade (HA).

Para saber mais sobre a alta disponibilidade no Bindplane, consulte Alta disponibilidade.

Calcular o número de coletores e servidores do Bindplane para alta disponibilidade

Ao operar o Bindplane no modo de alta disponibilidade, considere quantos coletores cada servidor do Bindplane vai processar.

Pegue o número total de instâncias do Bindplane e subtraia o número máximo de nós que você espera que fiquem indisponíveis devido à manutenção. Verifique se cada nó gerencia no máximo 30.000 coletores durante uma interrupção.

Postgres para alta disponibilidade

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

Prometheus para alta disponibilidade

O Prometheus é necessário quando você opera o Bindplane no modo de alta disponibilidade.

Para saber mais, consulte Prometheus.

Barramento de eventos para HA

O Bindplane usa um barramento de eventos para se comunicar entre componentes. Ao operar o Bindplane no modo de alta disponibilidade, você pode usar o barramento de eventos para enviar eventos entre servidores do Bindplane.

Para saber mais, consulte Barramento de eventos.

Use uma implantaçã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 usar uma implantação de instância única.

Para saber mais, consulte Instância única.

Isolar credenciais de back-end

Em vez de implantar credenciais em todos os sistemas de coleta, você pode manter as credenciais exclusivamente nos coletores de gateway. Isso simplifica a rotação de credenciais e reduz a superfície de ataque de segurança, limitando a implantação de credenciais a um subconjunto dos seus sistemas.

Proteger com firewall os coletores de gateway

É possível colocar coletores de gateway em uma rede de perímetro, protegida por firewall da rede interna. É possível configurar sua rede para permitir que os outros coletores encaminhem dados para os coletores de gateway, bloqueando o acesso deles à rede de aplicativos. Isso permite enviar telemetria para um back-end baseado na nuvem sem conceder aos endpoints acesso direto à Internet.

O firewall precisa permitir que o tráfego HTTP alcance o Bindplane na porta configurada.

Verificar a configuração do firewall

Todos os firewalls ou proxies autenticados entre o coletor e a Internet exigem regras para abrir o acesso aos seguintes hosts:

Tipo de conexão Destino Porta
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

Usar o PostgreSQL para implantações de produção

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

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

O número de núcleos de CPU e a memória disponível geralmente limitam o desempenho dos back-ends de armazenamento do PostgreSQL. Recomendamos fazer backup do armazenamento do PostgreSQL com armazenamento de baixa latência e alto rendimento, como unidades de estado sólido (SSDs).

Contagem de coletores Núcleos da CPU Memória
1 a 60.000 4 16 GB
60.001 a 125.000 8 32 GB
125.001 a 250.000 16 64 GB

Para saber mais, consulte:

Implementar a autenticação adequada

O Bindplane é compatível com a autenticação usando os seguintes protocolos e serviços. Verifique se eles estão implementados corretamente:

Usar o servidor Bindplane

A maioria dos clientes do Google SecOps usa o servidor Bindplane, mas o uso dele é opcional. Se você estiver instalando o servidor do Bindplane, precisará de acesso a storage.googleapis.com. Se você estiver instalando apenas um coletor, esse acesso não será necessário.

Para uma demonstração de como configurar o servidor Bindplane para padronizar e exportar registros para o Google SecOps, acesse [esta página](https://bindplane.com/use-case-demo) e selecione Configuração do Google SecOps.

Usar o servidor do Bindplane Cloud

O Bindplane Cloud está disponível para clientes do Google.

Faça login na Google Edition.

Para problemas relacionados ao servidor do Bindplane Cloud, entre em contato com o suporte do Bindplane. Para problemas relacionados ao Bindplane Server local, entre em contato com o suporte do Google SecOps.

Usar o servidor do Bindplane no seu Google Cloud

Para informações sobre como executar o servidor do Bindplane no seu Google Cloud, consulte Bindplane Enterprise Edition.

Usar o servidor local do Bindplane

O uso do servidor Bindplane local é regido pelos Google Cloud Termos de Serviço atuais.

Instalar o servidor local no Linux

É possível instalar o servidor Bindplane local no Linux executando um script (recomendado) ou baixando um arquivo binário e instalando manualmente. Para saber mais, consulte Instalar o servidor do Bindplane.

Para instalar o servidor Bindplane local no Linux com um script, faça o seguinte:

  1. Execute este script:

    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

  2. Siga as instruções, que orientam você até a inicialização do servidor.

Para instalar o servidor Bindplane local no Linux com um arquivo binário, faça o seguinte:

  1. Faça o download de um dos seguintes arquivos:

  2. Atualize o arquivo de configuração usando as instruções em Configurar o servidor Bindplane.

Distribuições do Linux compatíveis:
  • 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:

Implantações locais do Docker

Para saber mais, consulte Instalar o servidor do Bindplane.

As imagens de contêiner do Docker do Bindplane estão nos seguintes locais:

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

As imagens de contêiner são marcadas com a versão de lançamento. Por exemplo, o lançamento v1.35.0 terá a tag observiq/bindplane-ee:1.35.0.

Instalar o coletor do BindPlane

Esta seção descreve como instalar o coletor do Bindplane para o Google SecOps em vários sistemas.

Os coletores geralmente usam recursos mínimos. No entanto, ao processar grandes volumes de registros, fique atento ao consumo de recursos para não afetar outros serviços. Para mais informações, consulte Requisitos e recomendações técnicas, Planejar a instalação e a implantação e Dimensionamento e escalonamento do agente.

Para saber como instalar o coletor (ou seja, o agente OTel), consulte Coletor OTel do Bindplane.

Consulte também a documentação do GitHub bindplane-otel-collector.

Para instalar o coletor, você precisa do seguinte:

  • Arquivo de autenticação de ingestão do Google SecOps

    Para fazer o download do arquivo de autenticação, siga estas etapas:

    1. Abra o console do Google SecOps.
    2. Acesse Configurações do SIEM > Agente de coleta.
    3. Baixe o arquivo de autenticação de ingestão do Google SecOps.

  • ID de cliente do Google SecOps

    Para encontrar o ID do cliente, siga estas etapas:

    1. Abra o console do Google SecOps.
    2. Acesse Configurações do SIEM > Perfil.
    3. Copie o ID do cliente na seção Detalhes da organização.

  • Windows 2012 SP2 ou mais recente ou host Linux com systemd

  • Conectividade com a Internet

  • Acesso ao GitHub

Ferramentas de implantação

Esta seção descreve as ferramentas de implantação do Bindplane.

GitOps

Implante recursos do Bindplane usando um modelo GitOps, que inclui o seguinte:

  • Autenticação do Bindplane
  • CLI do Bindplane
  • Acesso à rede
  • Integração com um repositório do GitHub e o GitHub Actions
  • Como exportar recursos atuais
  • Gerenciar valores sensíveis
  • Como estabelecer um fluxo de trabalho do GitHub Actions
  • Instruções detalhadas para confirmar e testar a configuração, ativar os rollouts automáticos e atualizar os recursos usando edições diretas ou o método de exportação da UI
  • Atualizar valores sensíveis e usar o RBAC

Para saber mais, consulte GitOps.

Ansible

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

CLI do Bindplane

Para saber mais sobre a CLI Bindplane, consulte GitOps.

Terraform

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

Kubernetes

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

Instalar o coletor do BindPlane no Windows

Para instalar o coletor do 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

Se preferir instalar usando um assistente de instalação, faça o download do instalador mais recente para Windows. Depois de baixar o instalador, abra o assistente de instalação e siga as instruções para configurar e instalar o coletor do Bindplane.

Para saber mais sobre como instalar o coletor do BindPlane no Windows, consulte Instalação no Windows.

Instalar o coletor do BindPlane no Linux

É possível instalar o coletor no Linux usando um script que determina automaticamente qual pacote instalar. Você também pode usar o mesmo script para atualizar uma instalação atual.

Para instalar usando o 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

Instalação de um pacote local

Para instalar o coletor 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

Faça o download do pacote RPM para sua arquitetura na página de versões e instale o pacote usando rpm. Consulte o exemplo a seguir 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 você baixou.

Instalação do DEB

Faça o download do pacote DEB para sua arquitetura na página de versões e instale o pacote usando dpkg. Consulte o exemplo a seguir 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 você baixou.

Configurar o coletor do BindPlane

Depois de instalar o coletor, o serviço observiq-otel-collector é executado e fica pronto para configuração.

É possível configurar o coletor manualmente ou usando o servidor Bindplane.

Se você estiver configurando o coletor manualmente, atualize os parâmetros do exportador para garantir que o coletor faça a autenticação com o Google SecOps.

Arquivo de configuração do coletor do OTel

No Linux, o arquivo de configuração do coletor pode ser encontrado em /opt/observiq-otel-collector/config.yaml.

Serviço e registros do coletor OTel

Por padrão, o coletor gera registros em C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

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

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

Comandos comuns do serviço de coleta do OTel no Linux:

  • Para interromper o serviço do coletor do 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 de coleta do OTel na inicialização, execute sudo systemctl enable observiq-otel-collector.

Reinicie o serviço do coletor para que as mudanças de configuração entrem em vigor.

Ao mudar a configuração, reinicie o serviço do coletor para que as alterações entrem em vigor (sudo systemctl restart observiq-otel-collector).

Usar um arquivo de configuração de amostra padrão

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

Para fazer o download de um arquivo de configuração de amostra e um token de autenticação usados pelo coletor:

  • Abra o console do Google SecOps e acesse Configurações do SIEM > Agente de coleta.

Personalize as duas seções a seguir no arquivo de configuração:

  • Destinatário: especifica quais registros o coletor deve coletar e enviar ao Google SecOps.
  • Exporter: especifica o destino para onde o coletor envia os registros. Os seguintes exportadores são compatíveis:
    • Exportador do Google SecOps: envia registros diretamente para a API de ingestão do Google SecOps.
    • Exportador de encaminhador do Google SecOps: envia registros para o encaminhador do Google SecOps.
    • Exportador do Cloud Logging: envia registros para o Cloud Logging.

No exportador, personalize o seguinte:

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

  • creds: seu token de autenticação.

    Como alternativa, use creds_file_path para referenciar o arquivo de credenciais diretamente. Para a configuração do Windows, use barras invertidas para escapar o caminho.

  • log_type: tipo de registro. Recomendamos selecionar WINDOWS_DNS como o Tipo de registro.

  • ingestion_labels: rótulos de ingestão. Esses rótulos identificam os registros no Google SecOps.

  • namespace: namespace opcional.

    Cada tipo de registro exige a configuração de um exportador.

Exemplos de configuração de coleta de registros

As seções a seguir contêm exemplos de configuração para coleta de registros.

Enviar eventos do Windows e sysmon diretamente para o Google SecOps

Configure estes parâmetros no exemplo:

Exemplo de configuração:

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]

Enviar eventos do Windows e syslog diretamente para o Google SecOps

Configure estes parâmetros no exemplo:

Exemplo de configuração:

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

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

Configure estes parâmetros no exemplo:

Exemplo de configuração:

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

Enviar syslog diretamente para o Google SecOps

Configure estes parâmetros no exemplo:

Exemplo de configuração:

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

Coletar eventos do Windows remotamente e enviá-los diretamente para o Google SecOps

Configure estes parâmetros no exemplo:

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

Exemplo de configuração:

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

Enviar dados para o Cloud Logging

Configure o parâmetro credentials_file na amostra.

Exemplo de configuração:

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

Consultar um banco de dados SQL e enviar os resultados para o Google SecOps

Configure estes parâmetros no exemplo:

Exemplo de configuração:

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

Descartar registros que correspondem a uma expressão regular

É possível configurar o coletor para descartar registros que correspondam a uma expressão regular. Isso é útil para filtrar registros indesejados, como erros conhecidos ou mensagens de depuração.

Para descartar registros que correspondem a uma expressão regular, adicione um processador do tipo filter/drop-matching-logs-to-Chronicle à sua configuração. Esse processador usa a função IsMatch para avaliar o corpo do registro em relação à expressão regular. Se a função retornar true, o registro será descartado.

O exemplo de configuração a seguir descarta os registros que contêm as strings <EventID>10</EventID> ou <EventID>4799</EventID> no corpo do registro.

Você pode personalizar a expressão regular para corresponder a qualquer padrão necessário. A função IsMatch usa a sintaxe de expressão regular RE2.

Exemplo de configuração:

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 a seguir 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 seção descreve as ações rotineiras de operação e manutenção.

Verificar uma configuração do OTel

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

Atualizações de lançamento do coletor

O BindPlane pode pesquisar bindplane-otel-collector/releases para detectar novas versões do coletor. Esse recurso é opcional.

Para desativar a pesquisa do GitHub, defina agentVersions.syncInterval como 0 na configuração do Bindplane:

agentVersions:
syncInterval: 0

Backup e recuperação de desastres

Para saber mais sobre backup e recuperação de desastres com o Bindplane, consulte Recursos do Bindplane.

Backup e recuperação de desastres do PostgreSQL

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

Backup e recuperação de desastres do BBolt

Para saber mais sobre o backup e a recuperação de desastres do BBolt (descontinuado) com o Bindplane, consulte a documentação do BBolt Store.

Resiliência e nova tentativa

A repetição é ativada por padrão em todos os destinos compatíveis. Por padrão, as solicitações com falha são repetidas após cinco segundos e têm uma espera progressiva de até 30 segundos. Após cinco minutos, as solicitações são descartadas permanentemente.

Para saber mais, consulte Resiliência do coletor.

Reduzir o volume de registros com o filtro de gravidade

Para saber como reduzir o volume de registros, consulte Reduzir o volume de registros com o filtro de gravidade.

Integrações do Bindplane com coletores de terceiros

Embora o Bindplane seja mais eficiente quando você usa o coletor Bindplane para coleta na borda, na maioria dos casos, ele pode permanecer na sua infraestrutura atual. Por exemplo, se você já estiver usando o Fluent Bit ou os encaminhadores universais do Splunk, poderá continuar fazendo isso.

Integração do BindPlane com o Splunk

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

Integrações do Bindplane com outros coletores de terceiros

Para saber mais sobre as integrações do Bindplane com coletores de terceiros, consulte Conectar outros coletores do OpenTelemetry usando a extensão OpAMP.

Monitoramento silencioso de hosts

Com o monitoramento silencioso de hosts do Google Security Operations, é possível criar alertas para mudanças na taxa de ingestão usando o Google Cloud Monitoring. Ele gera alertas por coletor e notifica você quando a taxa de ingestão fica abaixo do limite definido, sinalizando possíveis interrupções do coletor.

Para informações sobre como usar o Bindplane para monitoramento silencioso de hosts, consulte:

Fazer upgrade do Bindplane no Linux

Executar o comando de instalação sem a flag --init no final é suficiente para fazer upgrade do Bindplane. Execute este script no servidor do Bindplane para fazer upgrade do Bindplane. Para saber mais, consulte Fazer upgrade, downgrade ou desinstalar o Bindplane Server.

Monitorar o Bindplane

Para saber como monitorar o Bindplane, consulte Monitorar o Bindplane.

Monitorar o Kubernetes no Bindplane

Para saber como monitorar o Kubernetes no Bindplane, consulte Monitoramento do Kubernetes.

Documentação adicional

Para saber mais sobre o Bindplane (antigo observIQ), consulte o seguinte:

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