Usar o Bindplane com o Google SecOps

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 é chamado de agente do Bindplane Distribution for OpenTelemetry (BDOT) Collector, agente de coleta, coletor ou agente.
• Servidor do Bindplane. Uma plataforma abrangente e unificada para gerenciar suas implantações do coletor OTel. Essas implantações podem estar no Google SecOps e no Google Cloud. O servidor do Bindplane pode ser executado no local ou na nuvem do Bindplane. Para mais informações sobre o console, consulte Console de gerenciamento do Bindplane. Esse componente também é 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)

Todos os clientes do Google SecOps têm acesso ao Bindplane (Google Edition) sem custo adicional. Para saber mais, consulte Observabilidade e segurança líderes do setor com tecnologia OpenTelemetry.

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

Para saber como começar a instalar e hospedar o Bindplane (Google Edition), consulte Bindplane (Google Edition).

Bindplane Enterprise (edição do Google): 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 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:

Console de gerenciamento do Bindplane

O uso do console de gerenciamento do Bindplane é opcional. Muitos clientes do Google SecOps usam o Bindplane Server.

O console de gerenciamento do Bindplane oferece os seguintes recursos principais:

• Gerenciamento centralizado. Com o console, é possível gerenciar todas as implantações do coletor OTel em Google Cloud. É possível conferir o status de cada implantação e realizar tarefas comuns de gerenciamento, como iniciar, interromper e reiniciar coletores.
• Monitoramento em tempo real. O console oferece monitoramento em tempo real das implantações do coletor OTel. É possível rastrear métricas como uso da CPU, uso da memória e capacidade de processamento, além de visualizar registros e rastreamentos para resolver problemas.
• Alertas e notificações. Com o console, é possível configurar alertas e notificações para eventos importantes, como quando um coletor fica inativo ou quando um limite de métrica é excedido.
• Gerenciamento de configurações. Com ele, é possível 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 em Google Cloud e usar o console para acessar seus recursos do Google Cloud .

Arquitetura do agente do Bindplane

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

O Bindplane usa o coletor BDOT 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.

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

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

Os agentes de coleta enviam registros para um agente de coleta que atua como um gateway.

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

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

O diagrama a seguir mostra agentes de coleta enviando registros para um agente de coleta que atua como um gateway.

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

O diagrama a seguir mostra agentes de coleta enviando registros diretamente para a API de ingestão do Google SecOps.

Os agentes de coleta enviam registros diretamente para o Cloud Logging

O diagrama a seguir mostra agentes de coleta enviando registros diretamente para o Cloud Logging.

Os agentes de coleta enviam registros para vários destinos

O diagrama a seguir mostra agentes de coleta enviando registros para vários destinos.

Tipos de implantação do Bindplane

O Bindplane oferece opções de implantação na nuvem e no local.

Implantações locais

• Linux
• Docker

Para saber mais, consulte Instalar o servidor do Bindplane.

Linux

Distribuições do 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:

• Instalar o servidor do Bindplane
• Downloads de pacotes

Imagens de contêiner do Docker

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.

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 de transferência (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 o seguinte:

• Coletor do Bindplane OTel no GitHub
• Instalar e desinstalar coletores do Bindplane
• Pré-requisitos para instalação
• Diretrizes de dimensionamento e escalonamento do coletor

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:

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

Os coletores de gateway recebem dados de telemetria pela rede. Recomendamos que você os pareie com um balanceador de carga para oferecer tolerância a falhas e escalonamento horizontal.

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

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 considera os processadores. Quando eles são adicionados, os requisitos de computação aumentam.

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

Faça o superprovisionamento 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, poderá implementar 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 usar um agente de coleta do Bindplane como um gateway (ou seja, no modo gateway), 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.

Usar um balanceador de carga quando necessário

Um balanceador de carga é necessário ao operar o Bindplane no modo de alta disponibilidade.

Ao usar um agente de coleta do Bindplane no modo de gateway, use um balanceador de carga para aumentar a performance 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 agente de coleta do Bindplane pode trabalhar com uma ampla variedade de balanceadores de carga quando opera no modo de gateway. Este documento não aborda nenhuma opção específica, porque as soluções de balanceamento de carga mais conhecidas oferecem suporte aos recursos necessários para operar vários coletores de maneira confiável.

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.

• Ofereça 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 que você use 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

Qualquer firewall ou proxy autenticado entre o agente e a Internet precisa de regras para abrir o acesso aos seguintes hosts:

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).

Para saber mais, consulte:

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

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:

• LDAP do Azure Entra. Para saber mais, consulte LDAP do Azure e Como mudar 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 Identidade da carga de trabalho do GKE.

Instalar o console de gerenciamento do BindPlane

A maioria dos clientes do Google SecOps usa o console de gerenciamento do Bindplane. Se você estiver instalando, precisará de acesso ao storage.googleapis.com. Se você estiver instalando apenas o agente, esse acesso não será necessário.

O Bindplane Cloud também está disponível para clientes do Google. Baixe a versão gratuita e envie um e-mail para support@bindplane.com solicitando um upgrade para a versão com suporte do Google.

Há três maneiras de implantar o console de gerenciamento do Bindplane:

• Bindplane Cloud: oferta de SaaS do Bindplane para o Bindplane Server.
• Fazer o download e instalar em um host Linux: disponível como um pacote DEB, RPM ou imagem do Docker.
• Instale e provisione no Google Cloud Marketplace.

Instalar o agente do Bindplane

Esta seção descreve como instalar o agente do Bindplane para o Google SecOps em diferentes sistemas operacionais host.

Os coletores de agentes 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 mais sobre como instalar o agente do OTel, consulte Instalar e desinstalar coletores do Bindplane.

Em caso de problemas relacionados ao coletor, entre em contato com o suporte do Google Cloud .

Para instalar o agente, 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 lançamentos 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:

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

Instalar o agente do Bindplane no Windows

Para instalar o agente do Bindplane em um sistema 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 agente do Bindplane.

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

Instalar o agente do BindPlane no Linux

É possível instalar o agente 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

Para saber mais sobre como configurar o coletor, consulte bindplane-otel-collect.

Instalação de um pacote local

Para instalar o agente 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.

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

Configurar o agente do Bindplane

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

É possível configurar o agente manualmente ou usando o console do Bindplane Management.

Se você estiver configurando o agente manualmente, atualize os parâmetros do exportador para garantir que ele 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 agente registra em C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

O registro 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 como configurar o coletor, consulte bindplane-otel-collect.

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 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 agente para aplicar as mudanças de configuração

Ao mudar a configuração, reinicie o serviço do agente 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 agente está localizado em C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

É possível fazer o download de um arquivo de configuração de amostra e um token de autenticação usados pelo agente no console do Google SecOps > Configurações do SIEM > Agente de coleta.

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

• Receiver: especifica quais registros o agente deve coletar e enviar ao Google SecOps.
• Exporter: especifica o destino para onde o agente 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:

• chronicleexporter

  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

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:

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

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:

• windowseventlogreceiver
• tcplogreceiver
  • listen_address
• chronicleforwarder
  • endpoint

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:

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

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:

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

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 correspondam 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 agentes de terceiros

Embora o Bindplane seja mais eficiente quando você usa o agente dele 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:

• Como usar o coletor OTEL do Splunk com o Bindplane
• Como 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 Como conectar outros coletores do OpenTelemetry usando a extensão OpAMP.

Monitoramento silencioso de hosts

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

• Monitoramento silencioso de hosts do Google SecOps
• Configurar o Bindplane para SHM com o Google Cloud Monitoring

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.

Monitoramento do Kubernetes

Para saber mais sobre o monitoramento do Kubernetes no Bindplane, consulte Monitoramento do Kubernetes.

Documentação de referência adicional

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

• Soluções do Bindplane
• Guia de início rápido do Bindplane
• Tipos de registros compatíveis com Google Cloud
• Filtrar por Condition Processor
• Fontes disponíveis para o Bindplane

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