BindPlane mit Google SecOps verwenden

In diesem Dokument wird Bindplane für Google Security Operations beschrieben.

BindPlane ist eine Telemetrie-Pipeline, mit der Logs aus beliebigen Quellen erfasst, optimiert und in Google SecOps exportiert werden können.

Bindplane bietet zwei Versionen speziell für Google.

Bindplane umfasst die folgenden Hauptkomponenten:

• Bindplane Collector Ein Open-Source-Agent, der auf dem OpenTelemetry-Collector (OTel) basiert. Es erfasst Logs aus verschiedenen Quellen, einschließlich Microsoft Windows-Ereignisprotokollen, und sendet sie an Google SecOps. Sie können die Collectors lokal oder in der Cloud installieren. Diese Komponente wird auch als Bindplane Distribution for OpenTelemetry (BDOT) Collector-Bindplane-Agent, Erfassungs-Agent, Collector oder Agent bezeichnet.
• Bindplane Server: Eine umfassende und einheitliche Plattform zur Verwaltung Ihrer OTel-Collector-Bereitstellungen. Diese Bereitstellungen können in Google SecOps und Google Cloudvorhanden sein. Bindplane Server kann lokal oder in der Bindplane-Cloud ausgeführt werden. Weitere Informationen zur Konsole finden Sie unter Bindplane Management Console. Diese Komponente wird auch als Bindplane Observability Pipeline (OP) Management Console oder Bindplane Management Console bezeichnet.

Google-Versionen von BindPlane

BindPlane bietet zwei Versionen speziell für Google: BindPlane (Google Edition) und BindPlane Enterprise (Google Edition).

Bindplane (Google Edition)

Alle Google SecOps-Kunden haben ohne Aufpreis Zugriff auf Bindplane (Google Edition). Weitere Informationen finden Sie unter Industry-Leading Observability and Security Powered by OpenTelemetry.

Sie können Bindplane (Google-Version) in der Bindplane-Cloud selbst verwalten.

Informationen zur Installation und zum Self-Hosting von BindPlane (Google Edition) finden Sie unter BindPlane (Google Edition).

Bindplane Enterprise (Google-Version) – für Google SecOps Enterprise Plus-Kunden

Bindplane Enterprise (Google-Version) ist für Google SecOps Enterprise Plus-Kunden enthalten.

Bindplane Enterprise (Google Edition) wird für umfangreiche Bereitstellungen empfohlen.

Wenden Sie sich an Ihr Google-Kontoteam, um Ihren Lizenzschlüssel für Bindplane Enterprise (Google Edition) zu erhalten.

BindPlane-Versionen von Google – Unterschiede

In der folgenden Tabelle sind die Unterschiede zwischen den Google-Versionen von Bindplane aufgeführt:

Bindplane-Verwaltungskonsole

Die Verwendung der Bindplane Management Console ist optional. Viele Google SecOps-Kunden verwenden Bindplane Server.

Die BindPlane-Verwaltungskonsole bietet die folgenden Hauptfunktionen:

• Zentrale Verwaltung: In der Konsole können Sie alle Ihre OTel-Collector-Bereitstellungen für Google Cloudverwalten. Sie können den Status jeder Bereitstellung aufrufen und allgemeine Verwaltungsaufgaben wie das Starten, Beenden und Neustarten von Collectors ausführen.
• Echtzeit-Monitoring: Die Konsole bietet Echtzeit-Monitoring Ihrer OTel-Collector-Bereitstellungen. Sie können Messwerte wie CPU-Auslastung, Speicherauslastung und Durchsatz im Blick behalten sowie Logs und Traces ansehen, um Probleme zu beheben.
• Benachrichtigungen: In der Konsole können Sie Benachrichtigungen für wichtige Ereignisse einrichten, z. B. wenn ein Collector ausfällt oder ein Messwertschwellenwert überschritten wird.
• Konfigurationsverwaltung: In der Konsole können Sie die Konfiguration Ihrer OTel-Collectoren zentral verwalten. Sie können Konfigurationsdateien bearbeiten, Umgebungsvariablen festlegen und Sicherheitsrichtlinien auf alle Ihre Bereitstellungen anwenden.
• Einbindung in Google Cloud: Sie können OTel Collector-Bereitstellungen in Google Cloud erstellen und verwalten und über die Console auf Ihre Google Cloud -Ressourcen zugreifen.

BindPlane-Agent – Architektur

Bindplane Agent kann in Linux oder Docker als einfacher Webserver ohne externe Abhängigkeiten ausgeführt werden.

Bindplane verwendet den BDOT-Collector, um die Telemetrieverwaltung mit dem Open Agent Management Protocol (OpAMP) zu standardisieren. Mit Bindplane können Sie auch benutzerdefinierte OpenTelemetry Collector-Distributionen erstellen und verwalten.

Weitere Informationen zur Bereitstellungsarchitektur von Bindplane OpenTelemetry Collectors finden Sie unter Bindplane OTel Collector.

In den folgenden Abschnitten werden die verfügbaren Architekturoptionen beschrieben.

Erfassungs-Agents senden Protokolle an einen Erfassungs-Agent, der als Gateway fungiert.

Für groß angelegte Bereitstellungen empfehlen wir die Verwendung von Bindplane Enterprise-Agents (Google-Version), die als Gateways fungieren. Diese Gateways empfangen Telemetriedaten von anderen Collectors über das Netzwerk, führen optional eine zusätzliche Verarbeitung durch und leiten die Daten an Google SecOps weiter.

Ein Erfassungs-Agent, der als Gateway fungiert, verwendet dasselbe Binärprogramm wie alle anderen Erfassungs-Agents.

Das folgende Diagramm zeigt, wie Erfassungs-Agents Logs an einen Erfassungs-Agent senden, der als Gateway fungiert.

Erfassungs-Agents senden Logs direkt an die Google SecOps Ingestion API.

Das folgende Diagramm zeigt, wie Erfassungs-Agents Logs direkt an die Google SecOps Ingestion API senden.

Erfassungs-Agents senden Logs direkt an Cloud Logging

Das folgende Diagramm zeigt, wie Erfassungs-Agents Logs direkt an Cloud Logging senden.

Erfassungs-Agents senden Logs an mehrere Ziele

Das folgende Diagramm zeigt, wie Erfassungs-Agents Logs an mehrere Ziele senden.

Bindplane-Bereitstellungstypen

Bindplane bietet Cloud- und lokale Bereitstellungsoptionen.

Lokale Bereitstellungen

• Linux
• Docker

Weitere Informationen finden Sie unter BindPlane Server installieren.

Linux

Linux-Distributionen:

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

Weitere Informationen nachstehend:

• BindPlane Server installieren
• Paket-Downloads

Docker-Container-Images

Bindplane-Docker-Container-Images finden Sie an den folgenden Speicherorten:

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

Container-Images werden mit der Releaseversion getaggt, z. B. hat Release v1.35.0 das Tag observiq/bindplane-ee:1.35.0.

Technische Anforderungen und Empfehlungen

In diesem Abschnitt werden die technischen Anforderungen und Empfehlungen für die Installation und Ausführung von Bindplane mit Google SecOps beschrieben.

Bandbreitenanforderungen

Bindplane unterhält Netzwerkverbindungen für Folgendes:

• Collector-Verwaltung
• Collector-Durchsatzmessungen
• Befehlszeilen und Weboberflächen

Verbindungsanforderungen

Bindplane überwacht standardmäßig Port 3001. Dieser Port ist konfigurierbar.

Der Bindplane-Port wird für Folgendes verwendet:

• Collector-Befehle und ‑Steuerung über OpAMP (WebSocket)
• Anfragen zur Messung des Collector-Durchsatzes (HTTP POST-Anfrage)
• Browser- und CLI-Nutzer (HTTP und WebSocket)

Collectors müssen Verbindungen zu Bindplane für OpAMP (WebSocket) und Durchsatzmessungen (HTTP) initiieren können.

BindPlane initiiert niemals Verbindungen zu den Collectors. Sie können eine Firewall konfigurieren, um zu verhindern, dass Bindplane die Collector-Netzwerke erreicht. Collector-Netzwerke müssen jedoch in der Lage sein, Bindplane über den konfigurierten Port zu erreichen.

Allgemeine technische Anforderungen an Bindplane-Collector

Informationen zu den allgemeinen technischen Anforderungen für den BindPlane-Collector finden Sie unter:

• Bindplane OTel-Collector auf GitHub
• BindPlane-Collectors installieren und deinstallieren
• Voraussetzungen für die Installation
• Richtlinien für die Größenanpassung und Skalierung von Collectoren

Ressourcenanforderungen für Collector

Die Ressourcenanforderungen von Bindplane unterscheiden sich je nach Anzahl der verwalteten Collectoren. Mit zunehmender Anzahl verwalteter Collectors steigen auch die CPU-, Arbeitsspeicher-, Festplattendurchsatz-/IOPS- und Netzwerknutzung.

Verwenden Sie die folgende Tabelle für die Dimensionierung von CPU, Arbeitsspeicher und Speicherkapazität:

Installation und Bereitstellung planen

Die folgenden Abschnitte enthalten Empfehlungen und Best Practices, die Sie bei der Planung der Bindplane-Bereitstellung berücksichtigen sollten.

Skalierung und Fehlertoleranz berücksichtigen

Gateway-Collector empfangen Telemetriedaten über das Netzwerk. Wir empfehlen, sie mit einem Load Balancer zu kombinieren, um sowohl Fehlertoleranz als auch horizontale Skalierung zu ermöglichen.

Horizontales Skalieren ist vorzuziehen, da es Fehlertoleranz bietet und Engpässe bei Exportern beseitigen kann.

Anzahl der benötigten Collectoren berechnen

Berücksichtigen Sie bei der Berechnung der Anzahl der für Ihre Arbeitslast erforderlichen Collectors den erwarteten Durchsatz oder die erwartete Protokollrate und verwenden Sie die folgende Tabelle. In dieser Tabelle wird davon ausgegangen, dass jeder Collector vier CPU-Kerne und 16 GB Arbeitsspeicher hat. In der Tabelle werden keine Prozessoren berücksichtigt. Wenn Prozessoren hinzugefügt werden, steigt der Rechenleistungsbedarf.

Collector-Flotte für Fehlertoleranz überdimensionieren

Stellen Sie mehr Collector-Instanzen bereit als benötigt, um Fehlertoleranz zu gewährleisten. Falls ein oder mehrere Collectors ausfallen oder zur Wartung offline genommen werden, müssen die verbleibenden Collectors über genügend Kapazität verfügen, um den Telemetrie-Durchsatz zu bewältigen.

Wenn Sie mit einer festen Anzahl von Collectors arbeiten, können Sie die CPU und den Arbeitsspeicher vertikal skalieren, um den Durchsatz zu erhöhen.

Verarbeitungsaufwand auslagern

Im Allgemeinen sollten Ihre Collectors so wenig Arbeit wie möglich verrichten. Wenn Sie hohe Anforderungen an die Verarbeitung haben, kann es sinnvoll sein, diese Verarbeitung auf eine Flotte von Gateway-Collectoren auszulagern. Anstatt Telemetriedaten beispielsweise mit einem aufwendigen regulären Ausdruck zu filtern, können Sie diese Aufgabe von den Gateway-Collectoren ausführen lassen. In der Regel werden Gateway-Collectors auf einem dedizierten System ausgeführt. Dies rechtfertigt den Verarbeitungsaufwand, da er nicht die Rechenleistung anderer Dienste beansprucht, die auf demselben System ausgeführt werden. Das ist bei einem Nicht-Gateway-Collector, der möglicherweise auf einem Datenbankserver ausgeführt wird, anders.

Best Practices für den Gateway-Modus

Wenn Sie einen Bindplane-Erfassungsagenten als Gateway verwenden, planen Sie die Bereitstellung im Gateway-Modus mit den folgenden Best Practices:

• Platzieren Sie mindestens zwei Collectors hinter einem Load-Balancer.
• Jeder Collector sollte mindestens zwei Kerne haben.
• Jeder Collector sollte mindestens 8 GB Arbeitsspeicher haben.
• Jeder Collector sollte 60 GB nutzbaren Speicherplatz für eine persistente Warteschlange haben.

Bei Bedarf Load-Balancer verwenden

Ein Load-Balancer ist erforderlich, wenn Bindplane im Hochverfügbarkeitsmodus ausgeführt wird.

Wenn Sie einen Bindplane-Erfassungsagenten im Gateway-Modus verwenden, sollten Sie einen Load-Balancer einsetzen, um die Leistung und Redundanz zu erhöhen. Load-Balancing ermöglicht auch die horizontale Skalierung Ihrer Gateway-Flotte und die Fähigkeit, Ausfälle zu überstehen, ohne dass es zu Ausfällen kommt.

Der Bindplane-Erfassungsagent kann im Gateway-Modus mit einer Vielzahl von Load-Balancern verwendet werden. In diesem Dokument werden keine spezifischen Optionen behandelt, da die meisten gängigen Load-Balancing-Lösungen die Funktionen unterstützen, die für den zuverlässigen Betrieb mehrerer Collectors erforderlich sind.

Weitere Informationen finden Sie unter Load Balancer.

Load-Balancing-Port und ‑Protokolle

Bindplane überwacht standardmäßig Port 3001.

Um die große Bandbreite an netzwerkbasierten Empfängern in OpenTelemetry zu unterstützen, muss der Load-Balancer Folgendes unterstützen:

• TCP/UDP-Transportprotokolle
• HTTP- und gRPC-Anwendungsprotokolle

Dimensionierung des Load-Balancing

Bindplane-Knoten sollten aus Gründen der maximalen Fehlertoleranz nicht mehr als 30.000 Collectors verwalten. Jeder Collector öffnet zwei Verbindungen zu Bindplane (eine für die OpAMP-Remote-Verwaltung und eine zum Veröffentlichen von Durchsatzmesswerten). Dieses Limit trägt dazu bei, dass Sie das Verbindungslimit von etwa 65.535 pro Backend-Instanz, das von den meisten Load Balancern auferlegt wird, nicht überschreiten.

Wenn eine Organisation 100.000 Collectors hat, wäre eine Clustergröße von drei nicht ausreichend. Jeder Knoten wäre für etwa 33.000 Collectors verantwortlich, was 66.000 TCP-Verbindungen pro Bindplane-Instanz entspricht. Diese Situation verschlimmert sich, wenn ein Knoten zur Wartung heruntergefahren wird, da jede verbleibende Bindplane-Instanz dann 50.000 Collectors oder 100.000 TCP-Verbindungen verwalten würde.

Best Practices für die Dimensionierung von Load Balancing

• Systemdiagnosen implementieren Konfigurieren Sie den Load-Balancer so, dass der Collector bereit ist, Traffic zu empfangen.
• Verbindungen gleichmäßig verteilen: Verbindungen sollten gleichmäßig auf die Collectors verteilt werden.

• Erforderliche Protokolle unterstützen: Um die große Bandbreite an netzwerkbasierten Empfängern in OpenTelemetry zu unterstützen, muss der Load-Balancer Folgendes unterstützen:

  • TCP/UDP-Transportprotokolle
  • HTTP- und gRPC-Anwendungsprotokolle

Weitere Informationen finden Sie unter Collector-Resilience.

Load-Balancing nach Quelltyp

Jeder Quelltyp, der Telemetriedaten von Remote-Systemen über das Netzwerk empfängt, eignet sich für das Load-Balancing, einschließlich der folgenden:

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

Hochverfügbarkeitsmodus in Produktionsumgebungen verwenden

Sie können eine Bindplane-Instanz entweder in einer Einzelinstanzkonfiguration oder in einer Konfiguration mit mehreren Instanzen bereitstellen. Für Produktionsbereitstellungen, die Hochverfügbarkeit (High Availability, HA) und Ausfallsicherheit erfordern, empfehlen wir die Verwendung eines Bereitstellungsmodells mit mehreren Instanzen (HA).

Wenn Bindplane mehr als 25.000 Collectors verwaltet, empfehlen wir, Bindplane im Hochverfügbarkeitsmodus (High Availability, HA) zu betreiben.

Informationen zur Hochverfügbarkeit in BindPlane finden Sie unter Hochverfügbarkeit.

Anzahl der Collector- und Bindplane-Server für HA berechnen

Wenn Sie BindPlane im HA-Modus betreiben, müssen Sie berücksichtigen, wie viele Collectors jeder BindPlane-Server verarbeiten soll.

Nehmen Sie die Gesamtzahl der Bindplane-Instanzen und ziehen Sie die maximale Anzahl von Knoten ab, die aufgrund von Wartungsarbeiten voraussichtlich nicht verfügbar sein werden. Achten Sie darauf,dass jeder Knoten während eines Knotenausfalls nicht mehr als 30.000 Collectors verwaltet.

Postgres für HA

Postgres ist eine Voraussetzung, wenn Sie Bindplane im HA-Modus betreiben.

Prometheus für HA

Prometheus ist erforderlich, wenn Sie Bindplane im Hochverfügbarkeitsmodus betreiben.

Weitere Informationen finden Sie unter Prometheus.

Ereignisbus für HA

BindPlane verwendet einen Ereignisbus für die Kommunikation zwischen Komponenten innerhalb von BindPlane. Wenn Sie Bindplane im HA-Modus betreiben, können Sie den Ereignisbus verwenden, um Ereignisse zwischen Bindplane-Servern zu senden.

Weitere Informationen finden Sie unter Event Bus.

Single-Instance-Bereitstellung für eine Testumgebung oder einen Proof-of-Concept verwenden

Für eine Testumgebung oder einen Proof-of-Concept empfehlen wir die Bereitstellung einer einzelnen Instanz.

Weitere Informationen finden Sie unter Einzelne Instanz.

Back-End-Anmeldedaten isolieren

Anstatt Anmeldedaten auf allen Collector-Systemen bereitzustellen, können Sie sie ausschließlich auf den Gateway-Collectors speichern. Dies vereinfacht die Rotation von Anmeldedaten und verringert die Sicherheitsangriffsfläche, da die Bereitstellung von Anmeldedaten auf eine Teilmenge Ihrer Systeme beschränkt wird.

Gateway-Collector schützen

Sie können Gateway-Collectoren in einem Perimeternetzwerk platzieren, das durch eine Firewall vom internen Netzwerk getrennt ist. Sie können Ihr Netzwerk so konfigurieren, dass Ihre anderen Collectors Daten an die Gateway-Collectors weiterleiten dürfen, die Gateway-Collectors aber nicht auf Ihr Anwendungsnetzwerk zugreifen können. So können Sie Telemetriedaten an ein cloudbasiertes Backend senden, ohne Ihren Endpunkten direkten Zugriff auf das Internet zu gewähren.

Die Firewall muss HTTP-Traffic auf dem konfigurierten Port an Bindplane zulassen.

Firewallkonfiguration prüfen

Für alle Firewalls oder authentifizierten Proxys zwischen dem Agent und dem Internet sind Regeln erforderlich, um den Zugriff auf die folgenden Hosts zu ermöglichen:

PostgreSQL für Produktionsbereitstellungen verwenden

Postgres ist für Produktionsbereitstellungen von Bindplane erforderlich.

Postgres ist eine Voraussetzung für den Betrieb von Bindplane im HA-Modus.

Die Anzahl der CPU-Kerne und der verfügbare Arbeitsspeicher begrenzen in der Regel die Leistung von PostgreSQL-Speicher-Back-Ends. Wir empfehlen, den PostgreSQL-Speicher mit Speicher mit niedriger Latenz und hohem Durchsatz zu sichern, z. B. mit Solid-State-Laufwerken (SSDs).

Weitere Informationen nachstehend:

• PostgreSQL-Dokumentation
• Einrichtungsanleitung für Postgres
• Postgres Store-Konfiguration
• Postgres-TLS-Einrichtung

Geeignete Authentifizierung implementieren

Bindplane unterstützt die Authentifizierung mit den folgenden Protokollen und Diensten. Achten Sie darauf, dass sie richtig implementiert sind:

• Azure AD LDAP Weitere Informationen finden Sie unter Azure LDAP und Bindplane-Authentifizierungstyp ändern.
• LDAP
• OpenID Connect (OIDC).
• Lokal
• SAML
• Postgres-TLS Weitere Informationen finden Sie unter Postgres TLS.
• Kubernetes Weitere Informationen finden Sie unter GKE Workload Identity.

BindPlane Management Console installieren

Die meisten Google SecOps-Kunden verwenden die Bindplane Management Console. Wenn Sie die App installieren, benötigen Sie Zugriff auf storage.googleapis.com. Wenn Sie nur den Agent installieren, ist dieser Zugriff nicht erforderlich.

Bindplane Cloud ist auch für Google-Kunden verfügbar. Laden Sie die kostenlose Version herunter und senden Sie eine E-Mail an support@bindplane.com, um ein Upgrade auf die von Google unterstützte Version anzufordern.

Es gibt drei Möglichkeiten, die Bindplane Management Console bereitzustellen:

• Bindplane Cloud: Das SaaS-Angebot von Bindplane für Bindplane Server.
• Auf einem Linux-Host herunterladen und installieren: als DEB-Paket, RPM-Paket oder Docker-Image verfügbar.
• Über den Google Cloud Marketplace installieren und bereitstellen

BindPlane-Agent installieren

In diesem Abschnitt wird beschrieben, wie Sie den Bindplane-Agent für Google SecOps auf verschiedenen Hostbetriebssystemen installieren.

Agent-Collectors benötigen in der Regel nur minimale Ressourcen. Wenn Sie jedoch große Mengen an Logs verarbeiten, sollten Sie auf den Ressourcenverbrauch achten, um Auswirkungen auf andere Dienste zu vermeiden. Weitere Informationen finden Sie unter Technische Anforderungen und Empfehlungen, Installation und Bereitstellung planen und Agent-Größe und ‑Skalierung.

Weitere Informationen zum Installieren des OTel-Agents finden Sie unter BindPlane Collectors installieren und deinstallieren.

Bei Problemen mit dem Collector wenden Sie sich bitte an den Google Cloud -Support.

Für die Installation des Agents benötigen Sie Folgendes:

• Google SecOps-Datei für die Authentifizierung der Aufnahme

  So laden Sie die Authentifizierungsdatei herunter:

  1. Öffnen Sie die Google SecOps-Konsole.
  2. Rufen Sie SIEM Settings > Collection Agent auf.
  3. Laden Sie die Authentifizierungsdatei für die Google SecOps-Aufnahme herunter.

• Google SecOps-Kunden-ID

  So finden Sie die Kunden-ID:

  1. Öffnen Sie die Google SecOps Console.
  2. Rufen Sie SIEM-Einstellungen > Profil auf.
  3. Kopieren Sie die Kunden-ID aus dem Bereich Organisationsdetails.

• Windows 2012 SP2 oder höher oder Linux-Host mit systemd

• Internetverbindung

• GitHub-Zugriff

Tools zur Bereitstellung

In diesem Abschnitt werden die Bereitstellungstools für Bindplane beschrieben.

GitOps

Stellen Sie Bindplane-Ressourcen mit einem GitOps-Modell bereit, das Folgendes umfasst:

• Bindplane-Authentifizierung
• Bindplane-CLI
• Netzwerkzugriff
• Integration in ein GitHub-Repository und GitHub Actions
• Vorhandene Ressourcen exportieren
• Sensible Werte verwalten
• GitHub Actions-Workflow einrichten
• Schritt-für-Schritt-Anleitung zum Übertragen und Testen der Konfiguration, zum Aktivieren automatischer Roll-outs und zum Aktualisieren von Ressourcen mithilfe von direkten Änderungen oder der UI-Exportmethode
• Sensible Werte aktualisieren und RBAC verwenden

Weitere Informationen finden Sie unter GitOps.

Ansible

Informationen zum Bereitstellen von BindPlane mit Ansible finden Sie unter bindplane-agent-ansible.

Bindplane-CLI

Informationen zur Bindplane-Befehlszeile finden Sie unter GitOps.

Terraform

Informationen zur Verwendung von Terraform zum Konfigurieren Ihrer Bindplane-Ressourcen finden Sie unter Bindplane-Anbieter.

Kubernetes

Weitere Informationen zu Kubernetes mit Bindplane finden Sie unter:

• Dynamischer Kubernetes-Clustername
• Kubernetes-Postgres-Migration

Bindplane-Agent unter Windows installieren

Führen Sie den folgenden PowerShell-Befehl aus, um den Bindplane-Agent unter Windows zu installieren:

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

Alternativ können Sie das aktuelle Installationsprogramm für Windows herunterladen, um die Installation mit einem Installationsassistenten durchzuführen. Öffnen Sie nach dem Herunterladen des Installationsprogramms den Installationsassistenten und folgen Sie der Anleitung, um den Bindplane-Agenten zu konfigurieren und zu installieren.

Weitere Informationen zur Installation des BindPlane-Agents unter Windows finden Sie unter Windows-Installation.

BindPlane-Agent unter Linux installieren

Sie können den Agent unter Linux mit einem Skript installieren, das automatisch ermittelt, welches Paket installiert werden soll. Sie können dasselbe Skript auch verwenden, um eine vorhandene Installation zu aktualisieren.

Führen Sie das folgende Skript aus, um die Installation mit dem Installationsskript durchzuführen:

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

Weitere Informationen zum Konfigurieren des Collectors finden Sie unter bindplane-otel-collect.

Installation aus einem lokalen Paket

Wenn Sie den Agent aus einem lokalen Paket installieren möchten, verwenden Sie -f mit dem Pfad zum Paket.

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

RPM-Installation

Laden Sie das RPM-Paket für Ihre Architektur von der Seite mit den Releases herunter und installieren Sie das Paket mit rpm. Im folgenden Beispiel wird das Paket amd64 installiert:

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

Ersetzen Sie VERSION durch die Version des heruntergeladenen Pakets.

DEB-Installation

Laden Sie das DEB-Paket für Ihre Architektur von der Seite „Releases“ herunter und installieren Sie das Paket mit dpkg. Sehen Sie sich das folgende Beispiel für die Installation des amd64-Pakets an:

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

Ersetzen Sie VERSION durch die Version des heruntergeladenen Pakets.

Weitere Informationen finden Sie unter BindPlane-Agent installieren.

Bindplane-Agent konfigurieren

Nach der Installation des Agents wird der observiq-otel-collector-Dienst ausgeführt und kann konfiguriert werden.

Sie können den Agent entweder manuell oder über die Bindplane Management Console konfigurieren.

Wenn Sie den Agent manuell konfigurieren, müssen Sie die Exportparameter aktualisieren, damit der Agent sich bei Google SecOps authentifiziert.

OTel Collector-Konfigurationsdatei

Unter Linux befindet sich die Konfigurationsdatei des Collectors unter /opt/observiq-otel-collector/config.yaml.

OTel-Collector-Dienst und ‑Logs

Der Agent protokolliert standardmäßig in C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

Das Standardfehlerlog für den Agent-Prozess finden Sie unter C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

Weitere Informationen zum Konfigurieren des Collectors finden Sie unter bindplane-otel-collect.

Wenn Sie unter Linux Logs vom Collector aufrufen möchten, führen Sie sudo tail -F /opt/observiq-otel-collector/log/collector.log aus.

Häufige Linux-Befehle für den OTel-Collector-Dienst:

• Führen Sie sudo systemctl stop observiq-otel-collector aus, um den OTel Collector-Dienst zu beenden.

• Führen Sie sudo systemctl start observiq-otel-collector aus, um den OTel Collector-Dienst zu starten.

• Führen Sie sudo systemctl restart observiq-otel-collector aus, um den OTel Collector-Dienst neu zu starten.

• Führen Sie sudo systemctl enable observiq-otel-collector aus, um den OTel Collector-Dienst beim Start zu aktivieren.

Agent-Dienst für die Konfigurationsänderungen neu starten

Wenn Sie die Konfiguration ändern, müssen Sie den Agent-Dienst neu starten, damit die Konfigurationsänderungen wirksam werden (sudo systemctl restart observiq-otel-collector).

Standard-Beispielkonfigurationsdatei verwenden

Standardmäßig befindet sich eine Agent-Konfigurationsdatei unter C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

Sie können eine Beispielkonfigurationsdatei und ein Authentifizierungstoken, die vom Agent verwendet werden, in der Google SecOps-Konsole > SIEM Settings > Collection Agent herunterladen.

Passen Sie die folgenden beiden Abschnitte in der Konfigurationsdatei an:

• Receiver: Gibt an, welche Logs der Agent erfassen und an Google SecOps senden soll.
• Exporter: Gibt das Ziel an, an das der Agent die Logs sendet. Die folgenden Exporter werden unterstützt:
  • Google SecOps-Exporter: Sendet Logs direkt an die Google SecOps-Aufnahme-API.
  • Google SecOps Forwarder Exporter: Sendet Protokolle an den Google SecOps Forwarder.
  • Cloud Logging-Exporter: Sendet Logs an Cloud Logging.

Passen Sie im Exporter Folgendes an:

• customer_id: Ihre Google SecOps-Kundennummer.
• endpoint: Ihr regionaler Google SecOps-Endpunkt.

• creds: Ihr Authentifizierungstoken.

  Alternativ können Sie mit creds_file_path direkt auf die Datei mit den Anmeldedaten verweisen. Bei der Windows-Konfiguration müssen Sie den Pfad mit Backslashes maskieren.

• log_type: Logtyp. Wir empfehlen, WINDOWS_DNS als Logtyp auszuwählen.

• ingestion_labels: Labels für die Datenaufnahme. Diese Labels identifizieren die Logs in Google SecOps.

• namespace: Optionaler Namespace.

  Für jeden Logtyp müssen Sie einen Exporteur konfigurieren.

Beispiele für die Konfiguration der Logerfassung

Die folgenden Abschnitte enthalten Konfigurationsbeispiele für die Protokollerfassung.

Windows-Ereignisse und Sysmon-Ereignisse direkt an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

• chronicleexporter

  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

Beispielkonfiguration:

receivers:
  windowseventlog/sysmon:
    channel: Microsoft-Windows-Sysmon/Operational
    raw: true
  windowseventlog/security:
    channel: security
    raw: true
  windowseventlog/application:
    channel: application
    raw: true
  windowseventlog/system:
    channel: system
    raw: true

processors:
  batch:

exporters:
  chronicle/sysmon:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.iam.gserviceaccount.com",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}' 
    log_type: 'WINDOWS_SYSMON'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'
  chronicle/winevtlog:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.iam.gserviceaccount.com",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}'
    log_type: 'WINEVTLOG'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'

service:
  pipelines:
    logs/sysmon:
      receivers: [windowseventlog/sysmon]
      processors: [batch]
      exporters: [chronicle/sysmon]
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: [batch]
      exporters: [chronicle/winevtlog]

Windows-Ereignisse und Syslog direkt an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

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

Beispielkonfiguration:

receivers:
    tcplog:
      listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicle/chronicle_w_labels
        logs/source1__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Windows-Ereignisse und Syslog an den Google SecOps-Forwarder senden

Konfigurieren Sie diese Parameter im Beispiel:

• windowseventlogreceiver
• tcplogreceiver
  • listen_address
• chronicleforwarder
  • endpoint

Beispielkonfiguration:

receivers:
tcplog:
    listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicleforwarder/forwarder:
        export_type: syslog
        raw_log_field: body
        syslog:
            endpoint: 127.0.0.1:10514
            transport: udp
service:
    pipelines:
        logs/source0__forwarder-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicleforwarder/forwarder
        logs/source1__forwarder-0:
            receivers:
                - tcplog
            exporters:
                - chronicleforwarder/forwarder

Syslog direkt an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

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

Beispielkonfiguration:

receivers:
  tcplog:
    listen_address: "0.0.0.0:54525"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Windows-Ereignisse remote erfassen und direkt an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

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

Beispielkonfiguration:

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

Daten an Cloud Logging senden

Konfigurieren Sie den Parameter credentials_file im Beispiel.

Beispielkonfiguration:

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

SQL-Datenbank abfragen und Ergebnisse an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

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

Beispielkonfiguration:

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

Logs löschen, die mit einem regulären Ausdruck übereinstimmen

Sie können den Collector so konfigurieren, dass Logs, die einem regulären Ausdruck entsprechen, verworfen werden. Dies ist nützlich, um unerwünschte Logs herauszufiltern, z. B. bekannte Fehler oder Debugging-Nachrichten.

Wenn Sie Logs verwerfen möchten, die einem regulären Ausdruck entsprechen, fügen Sie Ihrer Konfiguration einen Prozessor vom Typ filter/drop-matching-logs-to-Chronicle hinzu. Dieser Prozessor verwendet die Funktion IsMatch, um den Log-Body anhand des regulären Ausdrucks auszuwerten. Wenn die Funktion true zurückgibt, wird der Log verworfen.

In der folgenden Beispielkonfiguration werden Logs verworfen, die die Strings <EventID>10</EventID> oder <EventID>4799</EventID> im Log-Text enthalten.

Sie können den regulären Ausdruck an jedes beliebige Muster anpassen. Die Funktion IsMatch verwendet die RE2-Syntax für reguläre Ausdrücke.

Beispielkonfiguration:

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

Im folgenden Beispiel wird der Prozessor der Pipeline in derselben Konfiguration hinzugefügt:

service:
  pipelines:
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: 
      - filter/drop-matching-logs-to-Chronicle # Add this line
      - batch
      exporters: [chronicle/winevtlog]

Bindplane-Betrieb und -Wartung

In diesem Abschnitt werden Routinevorgänge und Wartungsmaßnahmen beschrieben.

OTel-Konfiguration prüfen

Informationen zum Überprüfen der BindPlane-OTel-Konfiguration finden Sie unter OTelBin.

Versionsupdates für Collectors

BindPlane kann bindplane-otel-collector/releases abfragen, um neue Collector-Releases zu erkennen. Diese Funktion ist optional.

Sie können das GitHub-Polling deaktivieren, indem Sie in Ihrer Bindplane-Konfiguration agentVersions.syncInterval auf 0 setzen:

agentVersions:
syncInterval: 0

Sicherung und Notfallwiederherstellung

Informationen zur Sicherung und Notfallwiederherstellung mit BindPlane finden Sie unter BindPlane-Ressourcen.

Sicherung und Notfallwiederherstellung von PostgreSQL

Informationen zur PostgreSQL-Sicherung und ‑Notfallwiederherstellung mit Bindplane finden Sie in der PostgreSQL-Dokumentation.

BBolt-Sicherung und ‑Notfallwiederherstellung

Informationen zur Sicherung und Notfallwiederherstellung mit Bindplane für BBolt (eingestellt) finden Sie in der BBolt Store-Dokumentation.

Robustheit und Wiederholungsversuche

Die Funktion „Wiederholen“ ist standardmäßig für alle Ziele aktiviert, die sie unterstützen. Standardmäßig werden fehlgeschlagene Anfragen nach fünf Sekunden wiederholt und das Backoff wird progressiv auf bis zu 30 Sekunden erhöht. Nach fünf Minuten werden Anfragen endgültig gelöscht.

Weitere Informationen finden Sie unter Collector-Resilience.

Logvolumen mit dem Schweregradfilter reduzieren

Informationen zum Reduzieren des Logvolumens finden Sie unter Logvolumen mit dem Schweregradfilter reduzieren.

Bindplane-Integrationen mit Drittanbieter-Agents

Bindplane ist zwar leistungsfähiger, wenn Sie den Bindplane-Agenten für die Erfassung am Edge verwenden, in den meisten Fällen kann Bindplane jedoch in Ihrer vorhandenen Infrastruktur verbleiben. Wenn Sie beispielsweise bereits Fluent Bit oder Splunk Universal Forwarders verwenden, können Sie dies weiterhin tun.

BindPlane-Integration in Splunk

Weitere Informationen zu Splunk mit BindPlane finden Sie unter:

• Splunk OTEL Collector mit BindPlane verwenden
• Splunk UF mit Bindplane verwenden

Bindplane-Integrationen mit anderen Drittanbieter-Agents

Informationen zu BindPlane-Integrationen mit Drittanbieter-Agents finden Sie unter Andere OpenTelemetry Collectors über die OpAMP-Erweiterung verbinden.

Silent Host Monitoring

Informationen zur Verwendung von Bindplane für das Silent-Host-Monitoring finden Sie unter:

• Google SecOps Silent Host Monitoring
• BindPlane für SHM mit Google Cloud Monitoring konfigurieren

Bindplane unter Linux aktualisieren

Wenn Sie den Installationsbefehl ohne das Flag --init am Ende ausführen, wird Bindplane aktualisiert. Führen Sie dieses Skript auf Ihrem BindPlane-Server aus, um BindPlane zu aktualisieren. Weitere Informationen finden Sie unter Bindplane Server upgraden, downgraden oder deinstallieren.

Bindplane überwachen

Informationen zum Monitoring von BindPlane finden Sie unter BindPlane-Monitoring.

Kubernetes-Monitoring

Informationen zum Kubernetes-Monitoring in Bindplane finden Sie unter Kubernetes-Monitoring.

Zusätzliche Referenzdokumentation

Weitere Informationen zu BindPlane (früher observIQ) finden Sie unter:

• Bindplane-Lösungen
• Bindplane-Kurzanleitung
• Unterstützte Protokolltypen für Google Cloud
• Nach Condition Processor filtern
• Für BindPlane verfügbare Quellen

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten