Utiliser Bindplane avec Google SecOps

Compatible avec :

Ce document décrit Bindplane pour Google Security Operations.

Bindplane est un pipeline de télémétrie qui peut collecter, affiner et exporter des journaux depuis n'importe quelle source vers Google SecOps.

Bindplane propose deux éditions spécialement conçues pour Google.

Bindplane comprend les principaux composants suivants :

  • Collecteur BindPlane : Agent Open Source basé sur le collecteur OpenTelemetry (OTel). Il collecte les journaux de différentes sources, y compris les journaux d'événements Microsoft Windows, et les envoie à Google SecOps. Vous pouvez installer les collecteurs sur site ou dans le cloud. Ce composant est également appelé agent Bindplane Distribution for OpenTelemetry (BDOT) Collector bindplane, agent de collecte, collecteur ou agent.
  • Serveur Bindplane Plate-forme complète et unifiée pour gérer vos déploiements de collecteurs OTel. Ces déploiements peuvent résider dans Google SecOps et Google Cloud. Bindplane Server peut s'exécuter sur site ou dans le cloud Bindplane. Pour en savoir plus sur la console, consultez Console de gestion Bindplane. Ce composant est également appelé console de gestion Bindplane Observability Pipeline (OP) ou console de gestion Bindplane.

Éditions Google de Bindplane

Bindplane propose deux éditions spécialement conçues pour Google : Bindplane (Google Edition) et Bindplane Enterprise (Google Edition).

Bindplane (édition Google)

Bindplane (édition Google) est fourni à tous les clients Google SecOps.

Pour obtenir de l'aide, consultez les ressources suivantes :

Vous pouvez utiliser Bindplane (Google Edition) en libre-service sur le cloud Bindplane.

Pour savoir comment installer et auto-héberger Bindplane (édition Google), consultez Bindplane (édition Google).

Bindplane Enterprise (édition Google) : pour les clients Google SecOps Enterprise Plus

Bindplane Enterprise (édition Google) est inclus pour les clients Google SecOps Enterprise Plus.

Bindplane Enterprise (Google Edition) est recommandé pour les déploiements à grande échelle.

Contactez l'équipe chargée de votre compte Google pour obtenir votre clé de licence Bindplane Enterprise (Google Edition).

Éditions Google de Bindplane : différences

Le tableau suivant répertorie les différences entre les éditions Google de Bindplane :

Fonctionnalités Bindplane (édition Google) Bindplane Enterprise (édition Google)
Coût Inclus sans frais supplémentaires pour tous les clients Google SecOps Inclus sans frais pour les clients Google SecOps Enterprise Plus
Itinéraires/Destinations Google uniquement, y compris Google SecOps, Cloud Logging, BigQuery et Cloud Storage via Google SecOps Google, y compris le routage vers une destination non Google pendant 12 mois pour les migrations SIEM
Filtrage Filtre de base avec expression régulière Processeurs de filtrage avancé (par exemple, filtrer par condition, champ, gravité, etc.), réduction des données, échantillonnage des journaux, déduplication
Masquage N/A Masquage des informations personnelles identifiables
Transformation Ajouter un champ, déplacer un champ, analyser des données (KV, JSON, CSV, XML, code temporel, analyse par expression régulière), renommer un champ, séparateur d'événements Inclut toutes les fonctionnalités compatibles avec Bindplane (édition Google) plus les fonctionnalités "Supprimer le champ", "Supprimer les valeurs vides" et "Regrouper"
Fonctionnalités générales au niveau de la plate-forme Passerelle (agrégation des données des agents), agents Bindplane pour la collecte, couche de gestion Bindplane pour les environnements sur site ou hébergés dans le cloud, toutes les sources, surveillance silencieuse de l'hôte via le processeur SecOps, file d'attente persistante, enrichissement de la télémétrie, HA, RBAC, les deux API d'ingestion SecOps sont prises en charge, obscurcissement des identifiants, gestion avancée du parc, y compris le regroupement des agents, attribution dynamique du type de journal Toutes les fonctionnalités compatibles avec Bindplane (Google Edition)

Console de gestion Bindplane

L'utilisation de la console de gestion Bindplane est facultative. De nombreux clients Google SecOps utilisent Bindplane Server.

La console de gestion Bindplane propose les principales fonctionnalités suivantes :

  • Gestion centralisée : La console vous permet de gérer tous vos déploiements de collecteurs OTel sur Google Cloud. Vous pouvez afficher l'état de chaque déploiement et effectuer des tâches de gestion courantes, comme démarrer, arrêter et redémarrer des collecteurs.
  • Surveillance en temps réel : La console permet de surveiller en temps réel vos déploiements de collecteurs OTel. Vous pouvez suivre des métriques telles que l'utilisation du processeur, de la mémoire et du débit, ainsi qu'afficher les journaux et les traces pour résoudre les problèmes.
  • Alertes et notifications : La console vous permet de configurer des alertes et des notifications pour les événements importants, par exemple lorsqu'un collecteur est hors service ou lorsqu'un seuil de métrique est dépassé.
  • Gestion de la configuration : La console vous permet de gérer de manière centralisée la configuration de vos collecteurs OTel. Vous pouvez modifier les fichiers de configuration, définir des variables d'environnement et appliquer des règles de sécurité à tous vos déploiements.
  • Intégration à Google Cloud Vous pouvez créer et gérer des déploiements de collecteurs OTel dans Google Cloud et utiliser la console pour accéder à vos ressources Google Cloud .

Architecture de l'agent Bindplane

L'agent Bindplane peut s'exécuter sous Linux ou Docker en tant que serveur Web léger sans dépendances externes.

Bindplane utilise le collecteur BDOT pour standardiser la gestion de la télémétrie avec le protocole Open Agent Management Protocol (OpAMP). Vous pouvez également créer et gérer des distributions personnalisées du collecteur OpenTelemetry avec Bindplane.

Pour en savoir plus sur l'architecture de déploiement des collecteurs Bindplane OpenTelemetry, consultez Collecteur Bindplane OTel.

Les sections suivantes décrivent les options d'architecture disponibles.

Les agents de collecte envoient les journaux à un agent de collecte qui sert de passerelle.

Pour les déploiements à grande échelle, nous vous recommandons d'utiliser des agents Bindplane Enterprise (Google Edition) qui servent de passerelles. Ces passerelles reçoivent des données de télémétrie d'autres collecteurs sur le réseau, effectuent éventuellement un traitement supplémentaire et acheminent les données vers Google SecOps.

Un agent de collecte agissant en tant que passerelle utilise le même binaire que tous les autres agents de collecte.

Le schéma suivant montre des agents de collecte qui envoient des journaux à un agent de collecte faisant office de passerelle.

Les agents de collecte envoient les journaux à un agent de collecte qui sert de passerelle.

Les agents de collecte envoient les journaux directement à l'API d'ingestion Google SecOps.

Le schéma suivant montre des agents de collecte qui envoient des journaux directement à l'API d'ingestion Google SecOps.

Les agents de collecte envoient les journaux directement à l'API d'ingestion Google SecOps.

Les agents de collecte envoient les journaux directement à Cloud Logging.

Le schéma suivant montre des agents de collecte qui envoient des journaux directement à Cloud Logging.

Les agents de collecte envoient les journaux directement à Cloud Logging.

Les agents de collecte envoient des journaux vers plusieurs destinations

Le schéma suivant montre des agents de collecte qui envoient des journaux vers plusieurs destinations.

L'agent de collecte envoie les journaux à plusieurs destinations

Types de déploiement Bindplane

Bindplane propose des options de déploiement dans le cloud et sur site.

Déploiements sur site

L'utilisation du serveur Bindplane sur site est régie par les Conditions d'utilisation existantes deGoogle Cloud .

Déploiements Linux sur site

Vous pouvez installer le serveur Bindplane sur site sur Linux en exécutant un script (recommandé) ou en téléchargeant un fichier binaire et en l'installant manuellement. Pour en savoir plus, consultez Installer le serveur BindPlane.

Pour installer le serveur Bindplane sur site sous Linux à l'aide d'un script, procédez comme suit :

  1. Exécutez le script suivant :

    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. Suivez les instructions pour initialiser le serveur.

Pour installer le serveur Bindplane sur site sous Linux avec un fichier binaire, procédez comme suit :

  1. Téléchargez l'un des fichiers suivants :

  2. Mettez à jour le fichier de configuration en suivant les instructions de la section Configurer le serveur Bindplane.

Déploiements Docker sur site

Pour en savoir plus, consultez Installer le serveur BindPlane.

Linux

Distributions Linux :

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

Pour en savoir plus, consultez la ressource suivante :

Images de conteneurs Docker

Vous trouverez les images de conteneur Docker Bindplane aux emplacements suivants :

  • Packages GitHub : ghcr.io/observiq/Bindplane-ee
  • Dépôt d'artefacts Google : us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
  • Docker Hub : observiq/bindplane-ee

Les images de conteneur sont taguées avec la version de publication. Par exemple, la version v1.35.0 aura le tag observiq/bindplane-ee:1.35.0.

Exigences et recommandations techniques

Cette section décrit les exigences techniques et les recommandations pour installer et exécuter Bindplane avec Google SecOps.

Bande passante requise

Bindplane maintient les connexions réseau pour les éléments suivants :

  • Gestion des collecteurs
  • Mesures du débit du collecteur
  • Interfaces utilisateur Web et de ligne de commande

Connectivité requise

Bindplane écoute le port 3001 par défaut. Ce port est configurable.

Le port Bindplane est utilisé pour :

  • Commande et contrôle du collecteur à l'aide d'OpAMP (WebSocket)
  • Demandes de mesure du débit du collecteur (requête HTTP POST)
  • Utilisateurs de navigateurs et de CLI (HTTP et WebSocket)

Les collecteurs doivent pouvoir initier des connexions à Bindplane pour OpAMP (WebSocket) et des mesures de débit (HTTP).

Bindplane n'initie jamais de connexions aux collecteurs. Vous pouvez configurer un pare-feu pour empêcher Bindplane d'accéder aux réseaux de collecteurs. Toutefois, les réseaux de collecteurs doivent pouvoir accéder à Bindplane sur le port configuré.

Exigences techniques générales concernant le collecteur Bindplane

Pour en savoir plus sur les exigences techniques générales concernant le collecteur Bindplane, consultez les ressources suivantes :

Ressources requises pour le collecteur

Les exigences en termes de ressources de Bindplane varient en fonction du nombre de collecteurs gérés. À mesure que le nombre de collecteurs gérés augmente, la consommation de processeur, de mémoire, de débit/IOPS de disque et de réseau augmente également.

Utilisez le tableau suivant pour dimensionner la capacité du processeur, de la mémoire et du stockage :

Nombre de collecteurs Nœuds Bindplane Tolérance aux pannes Cœurs de processeur Mémoire Database (Base de données)
1–100 1 N/A 2 4 Go bbolt
100 - 25 000 1 N/A 4 16 Go postgres
1 à 60 000 3 1 2 8 Go postgres
60 001-125 000 5 1 2 8 Go postgres
125 001 à 250 000 10 2 2 8 Go postgres

Planifier votre installation et votre déploiement

Les sections suivantes incluent des recommandations et des bonnes pratiques à prendre en compte lorsque vous planifiez votre déploiement Bindplane.

Tenir compte de la mise à l'échelle et de la tolérance aux pannes

Les collecteurs de passerelle reçoivent les données de télémétrie sur le réseau. Nous vous recommandons de les associer à un équilibreur de charge pour assurer à la fois la tolérance aux pannes et le scaling horizontal.

Le scaling horizontal est préférable, car il offre une tolérance aux pannes et peut éliminer les goulots d'étranglement des exportateurs.

Calculer le nombre de collecteurs dont vous avez besoin

Lorsque vous calculez le nombre de collecteurs requis pour votre charge de travail, tenez compte du débit ou du taux de journaux attendus, et utilisez le tableau suivant. Ce tableau suppose que chaque collecteur dispose de quatre cœurs de processeur et de 16 Go de mémoire. Le tableau n'inclut pas les calculs avec les processeurs. Lorsque des processeurs sont ajoutés, les exigences de calcul augmentent.

Débit de télémétrie Journaux/seconde Collecteurs
5 Go/m 250 000 2
10 Go/m 500 000 3
20 Go/m 1 000 000 5
100 Go/mois 5 000 000 25

Surprovisionner le parc de collecteurs pour la tolérance aux pannes

Surprovisionnez le parc de collecteurs pour assurer la tolérance aux pannes. Si un ou plusieurs systèmes de collecte tombent en panne ou sont mis hors connexion pour maintenance, les collecteurs restants doivent disposer d'une capacité suffisante pour gérer le débit de télémétrie.

Si vous travaillez avec un nombre fixe de collecteurs, vous pouvez implémenter un scaling vertical de leur processeur et de leur mémoire pour augmenter le débit.

Décharger la surcharge de traitement

En général, vous souhaitez que vos collecteurs effectuent le moins de travail possible. Si vous avez des exigences de traitement importantes, il peut être utile de décharger ce traitement sur un parc de collecteurs de passerelle. Par exemple, au lieu de filtrer la télémétrie avec une opération d'expression régulière coûteuse, vous pouvez demander aux collecteurs de passerelle d'effectuer cette tâche. En général, les collecteurs de passerelle s'exécutent sur un système dédié. Cela justifie la surcharge de traitement, car elle ne consomme pas la puissance de calcul des autres services exécutés sur le même système, contrairement à un collecteur non-passerelle qui peut s'exécuter sur un serveur de base de données.

Bonnes pratiques pour le mode Passerelle

Lorsque vous utilisez un agent de collecte Bindplane comme passerelle, c'est-à-dire en mode passerelle, planifiez votre déploiement en suivant les bonnes pratiques suivantes :

  • Placez au moins deux collecteurs derrière un équilibreur de charge.
  • Chaque collecteur doit disposer d'au moins deux cœurs.
  • Chaque collecteur doit disposer d'au moins 8 Go de mémoire.
  • Chaque collecteur doit disposer de 60 Go d'espace utilisable pour une file d'attente persistante.

Utiliser un équilibreur de charge si nécessaire

Un équilibreur de charge est nécessaire lorsque vous utilisez Bindplane en mode haute disponibilité.

Lorsque vous utilisez un agent de collecte Bindplane en mode passerelle, utilisez un équilibreur de charge pour améliorer les performances et la redondance. L'équilibrage de charge permet également le scaling horizontal de votre parc de passerelles et la capacité à résister aux défaillances sans provoquer d'interruptions.

L'agent de collecte Bindplane peut fonctionner avec un large éventail d'équilibreurs de charge en mode passerelle. Ce document ne traite d'aucune option spécifique, car la plupart des solutions d'équilibrage de charge populaires sont compatibles avec les fonctionnalités nécessaires pour faire fonctionner plusieurs collecteurs de manière fiable.

Pour en savoir plus, consultez Équilibreur de charge.

Port et protocoles d'équilibrage de charge

Bindplane écoute le port 3001 par défaut.

Pour prendre en charge la large gamme de récepteurs réseau dans OpenTelemetry, l'équilibreur de charge doit être compatible avec les éléments suivants :

  • Protocoles de transport TCP/UDP
  • Protocoles d'application HTTP et gRPC

Dimensionnement de l'équilibrage de charge

Pour une tolérance aux pannes maximale,les nœuds Bindplane ne doivent pas gérer plus de 30 000 collecteurs. Chaque collecteur ouvre deux connexions à Bindplane (une pour la gestion à distance OpAMP et une pour la publication des métriques de débit). Cette limite permet de s'assurer que vous ne dépassez pas la limite de connexions d'environ 65 535 par instance de backend imposée par la plupart des équilibreurs de charge.

Si une organisation compte 100 000 collecteurs, une taille de cluster de trois serait insuffisante. Chaque nœud serait responsable d'environ 33 000 collecteurs, ce qui se traduit par 66 000 connexions TCP par instance Bindplane. Cette situation s'aggrave si un nœud est mis hors service pour maintenance, car chaque instance Bindplane restante gère alors 50 000 collecteurs ou 100 000 connexions TCP.

Bonnes pratiques pour dimensionner l'équilibrage de charge

  • Implémentez des vérifications de l'état. Configurez l'équilibreur de charge pour vous assurer que le collecteur est prêt à recevoir du trafic.
  • Répartissez les connexions de manière uniforme. Les connexions doivent être réparties de manière égale entre les collecteurs.

  • Prenez en charge les protocoles requis. Pour prendre en charge la large gamme de récepteurs réseau dans OpenTelemetry, l'équilibreur de charge doit être compatible avec les éléments suivants :

    • Protocoles de transport TCP/UDP
    • Protocoles d'application HTTP et gRPC

Pour en savoir plus, consultez Résilience du collecteur.

Équilibrage de charge de type source

Tout type de source qui reçoit des données de télémétrie de systèmes distants sur le réseau est un candidat approprié pour l'équilibrage de charge, y compris les suivants :

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

Utiliser le mode haute disponibilité dans les environnements de production

Vous pouvez déployer une instance Bindplane dans une configuration à instance unique ou à instances multiples. Pour les déploiements en production qui nécessitent une haute disponibilité et une résilience, nous vous recommandons d'utiliser un modèle de déploiement multi-instance (HA).

Lorsque Bindplane gère plus de 25 000 collecteurs, nous vous recommandons de l'utiliser en mode haute disponibilité (HA).

Pour en savoir plus sur la haute disponibilité dans BindPlane, consultez Haute disponibilité.

Calculer le nombre de collecteurs et de serveurs Bindplane pour la haute disponibilité

Lorsque vous utilisez Bindplane en mode haute disponibilité, vous devez tenir compte du nombre de collecteurs que chaque serveur Bindplane doit gérer.

Prenez le nombre total d'instances Bindplane et soustrayez le nombre maximal de nœuds qui devraient devenir indisponibles en raison de la maintenance. Assurez-vous que chaque nœud ne gère pas plus de 30 000 collecteurs en cas de panne d'un nœud.

Postgres pour la haute disponibilité

Postgres est un prérequis lorsque vous utilisez Bindplane en mode HA.

Prometheus pour la haute disponibilité

Prometheus est requis lorsque vous exécutez Bindplane en mode haute disponibilité.

Pour en savoir plus, consultez Prometheus.

Bus d'événements pour la haute disponibilité

Bindplane utilise un bus d'événements pour communiquer entre les composants de Bindplane. Lorsque vous utilisez Bindplane en mode HA, vous pouvez utiliser le bus d'événements pour envoyer des événements entre les serveurs Bindplane.

Pour en savoir plus, consultez Bus d'événements.

Utiliser un déploiement à instance unique pour un environnement de test ou une preuve de concept

Pour un environnement de test ou une preuve de concept, nous vous recommandons d'utiliser un déploiement à instance unique.

Pour en savoir plus, consultez Instance unique.

Isoler les identifiants du backend

Au lieu de déployer des identifiants sur tous vos systèmes de collecte, vous pouvez les conserver exclusivement sur les collecteurs de passerelle. Cela simplifie la rotation des identifiants et réduit la surface d'attaque de sécurité en limitant le déploiement des identifiants à un sous-ensemble de vos systèmes.

Pare-feu pour vos collecteurs de passerelle

Vous pouvez placer des collecteurs de passerelle dans un réseau de périmètre, protégé par un pare-feu du réseau interne. Vous pouvez configurer votre réseau pour permettre à vos autres collecteurs de transférer des données vers les collecteurs de passerelle, tout en empêchant les collecteurs de passerelle d'accéder au réseau de votre application. Cela vous permet d'envoyer des données de télémétrie à un backend basé sur le cloud sans accorder à vos points de terminaison un accès direct à Internet.

Le pare-feu doit autoriser le trafic HTTP à atteindre Bindplane sur le port configuré.

Vérifier la configuration du pare-feu

Tous les pare-feu ou proxys authentifiés entre l'agent et Internet nécessitent des règles pour ouvrir l'accès aux hôtes suivants :

Type de connexion Destination Port
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

Utiliser PostgreSQL pour les déploiements de production

Postgres est requis pour les déploiements de production de Bindplane.

Postgres est un prérequis pour faire fonctionner Bindplane en mode haute disponibilité.

Le nombre de cœurs de processeur et la mémoire disponible limitent généralement les performances des backends de stockage PostgreSQL. Nous vous recommandons de sauvegarder le stockage PostgreSQL avec un stockage à faible latence et à haut débit, tel que des disques SSD (Solid-State Drives).

Nombre de collecteurs Cœurs de processeur Mémoire
1 à 60 000 4 16 Go
60 001-125 000 8 32 Go
125 001 à 250 000 16 64 Go

Pour en savoir plus, consultez la ressource suivante :

Implémenter une authentification appropriée

Bindplane est compatible avec l'authentification avec les protocoles et services suivants. Assurez-vous qu'ils sont correctement implémentés :

Installer la console de gestion Bindplane

La plupart des clients Google SecOps utilisent la console Bindplane Management. Si vous l'installez, vous devez avoir accès à storage.googleapis.com. Si vous n'installez que l'agent, cet accès n'est pas nécessaire.

Bindplane Cloud est également disponible pour les clients Google. Téléchargez la version gratuite et envoyez un e-mail à support@bindplane.com pour demander à passer à la version compatible avec Google.

Vous pouvez déployer la console de gestion Bindplane de trois manières :

Installer l'agent Bindplane

Cette section explique comment installer l'agent Bindplane pour Google SecOps sur différents systèmes d'exploitation hôtes.

Les collecteurs d'agents utilisent généralement un minimum de ressources. Toutefois, lorsque vous traitez de grands volumes de journaux, faites attention à la consommation de ressources pour éviter d'impacter d'autres services. Pour en savoir plus, consultez Exigences et recommandations techniques, Planifier votre installation et votre déploiement et Dimensionnement et scaling de l'agent.

Pour savoir comment installer l'agent OTel, consultez Installer et désinstaller les collecteurs Bindplane.

Pour installer l'agent, vous avez besoin des éléments suivants :

  • Fichier d'authentification de l'ingestion Google SecOps

    Pour télécharger le fichier d'authentification, procédez comme suit :

    1. Ouvrez la console Google SecOps.
    2. Accédez à Paramètres du SIEM > Agent de collecte.
    3. Téléchargez le fichier d'authentification de l'ingestion Google SecOps.

  • Numéro client Google SecOps

    Pour trouver l'ID client, procédez comme suit :

    1. Ouvrez la console Google SecOps.
    2. Accédez à Paramètres SIEM > Profil.
    3. Copiez le numéro client dans la section Informations sur l'organisation.

  • Windows 2012 SP2 ou version ultérieure ou hôte Linux avec systemd

  • Connexion Internet

  • Accès à GitHub

Outils de déploiement

Cette section décrit les outils de déploiement pour Bindplane.

GitOps

Déployez les ressources Bindplane à l'aide d'un modèle GitOps, qui inclut les éléments suivants :

  • Authentification Bindplane
  • CLI Bindplane
  • Accès au réseau
  • Intégration à un dépôt GitHub et à GitHub Actions
  • Exporter des ressources existantes
  • Gérer les valeurs sensibles
  • Établir un workflow d'action GitHub
  • Instructions détaillées pour valider et tester la configuration, activer les déploiements automatiques et mettre à jour les ressources à l'aide de modifications directes ou de la méthode d'exportation de l'UI
  • Mettre à jour les valeurs sensibles et utiliser le RBAC

Pour en savoir plus, consultez GitOps.

Ansible

Pour savoir comment déployer Bindplane avec Ansible, consultez bindplane-agent-ansible.

CLI Bindplane

Pour en savoir plus sur la CLI Bindplane, consultez GitOps.

Terraform

Pour savoir comment utiliser Terraform pour configurer vos ressources Bindplane, consultez Fournisseur Bindplane.

Kubernetes

Pour en savoir plus sur Kubernetes avec Bindplane, consultez les ressources suivantes :

Installer l'agent Bindplane sur Windows

Pour installer l'agent Bindplane sur Windows, exécutez la commande PowerShell suivante :

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

Vous pouvez également télécharger le dernier programme d'installation pour Windows afin d'installer le pilote à l'aide d'un assistant d'installation. Après avoir téléchargé le programme d'installation, ouvrez l'assistant d'installation et suivez les instructions pour configurer et installer l'agent Bindplane.

Pour en savoir plus sur l'installation de l'agent BindPlane sur Windows, consultez Installation sur Windows.

Installer l'agent Bindplane sur Linux

Vous pouvez installer l'agent sur Linux à l'aide d'un script qui détermine automatiquement le package à installer. Vous pouvez également utiliser le même script pour mettre à jour une installation existante.

Pour effectuer l'installation à l'aide du script d'installation, exécutez le script suivant :

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

Pour savoir comment configurer le collecteur, consultez bindplane-otel-collect.

Installation à partir d'un package local

Pour installer l'agent à partir d'un package local, utilisez -f avec le chemin d'accès au package.

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

Installation de RPM

Téléchargez le package RPM pour votre architecture à partir de la page des versions, puis installez-le à l'aide de rpm. Reportez-vous à l'exemple suivant pour installer le package amd64 :

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

Remplacez VERSION par la version du package que vous avez téléchargée.

Installation DEB

Téléchargez le package DEB pour votre architecture depuis la page des versions et installez-le à l'aide de dpkg. Consultez l'exemple suivant pour installer le package amd64 :

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

Remplacez VERSION par la version du package que vous avez téléchargée.

Pour en savoir plus, consultez Installation de l'agent Bindplane.

Configurer l'agent Bindplane

Une fois l'agent installé, le service observiq-otel-collector s'exécute et est prêt à être configuré.

Vous pouvez configurer l'agent manuellement ou à l'aide de la console Bindplane Management.

Si vous configurez l'agent manuellement, vous devez mettre à jour les paramètres de l'exportateur pour vous assurer que l'agent s'authentifie auprès de Google SecOps.

Fichier de configuration du collecteur OTel

Sous Linux, le fichier de configuration du collecteur se trouve à l'emplacement /opt/observiq-otel-collector/config.yaml.

Service et journaux du collecteur OTel

Par défaut, l'agent enregistre les journaux dans C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

Le journal d'erreur standard pour le processus de l'agent est disponible sur C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

Pour en savoir plus sur la configuration du collecteur, consultez bindplane-otel-collect.

Sous Linux, pour afficher les journaux du collecteur, exécutez sudo tail -F /opt/observiq-otel-collector/log/collector.log.

Commandes courantes du service de collecte OTel Linux :

  • Pour arrêter le service de collecte OTel, exécutez sudo systemctl stop observiq-otel-collector.

  • Pour démarrer le service de collecteur OTel, exécutez sudo systemctl start observiq-otel-collector.

  • Pour redémarrer le service de collecte OTel, exécutez sudo systemctl restart observiq-otel-collector.

  • Pour activer le service de collecteur OTel au démarrage, exécutez sudo systemctl enable observiq-otel-collector.

Redémarrez le service de l'agent pour appliquer les modifications de configuration.

Lorsque vous modifiez la configuration, vous devez redémarrer le service de l'agent pour que les modifications prennent effet (sudo systemctl restart observiq-otel-collector).

Utiliser un exemple de fichier de configuration par défaut

Par défaut, un fichier de configuration de l'agent se trouve à l'emplacement C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

Vous pouvez télécharger un exemple de fichier de configuration et de jeton d'authentification utilisés par l'agent depuis la console Google SecOps > Paramètres du SIEM > Agent de collecte.

Personnalisez les deux sections suivantes du fichier de configuration :

  • Receiver : spécifie les journaux que l'agent doit collecter et envoyer à Google SecOps.
  • Exportateur : spécifie la destination vers laquelle l'agent envoie les journaux. Les exportateurs suivants sont acceptés :
    • Exportateur Google SecOps : envoie les journaux directement à l'API d'ingestion Google SecOps.
    • Exportateur de transfert Google SecOps : envoie les journaux au transfert Google SecOps.
    • Exportateur Cloud Logging : envoie les journaux à Cloud Logging.

Dans l'exportateur, personnalisez les éléments suivants :

  • customer_id : ID client Google SecOps.
  • endpoint : point de terminaison régional Google SecOps.

  • creds : votre jeton d'authentification.

    Vous pouvez également utiliser creds_file_path pour faire directement référence au fichier d'identifiants. Pour la configuration Windows, échappez le chemin d'accès avec des barres obliques inverses.

  • log_type : type de journal. Nous vous recommandons de sélectionner WINDOWS_DNS comme type de journal.

  • ingestion_labels : libellés d'ingestion. Ces libellés identifient les journaux dans Google SecOps.

  • namespace : espace de noms facultatif.

    Chaque type de journal nécessite la configuration d'un exportateur.

Exemples de configuration de la collecte de journaux

Les sections suivantes contiennent des exemples de configuration pour la collecte des journaux.

Envoyer des événements Windows et Sysmon directement à Google SecOps

Configurez ces paramètres dans l'échantillon :

Exemple de configuration :

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]

Envoyer des événements Windows et Syslog directement à Google SecOps

Configurez ces paramètres dans l'échantillon :

Exemple de configuration :

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

Envoyer des événements Windows et Syslog au redirecteur Google SecOps

Configurez ces paramètres dans l'échantillon :

Exemple de configuration :

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

Envoyer des journaux syslog directement à Google SecOps

Configurez ces paramètres dans l'échantillon :

Exemple de configuration :

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

Collecter des événements Windows à distance et les envoyer directement à Google SecOps

Configurez ces paramètres dans l'échantillon :

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

Exemple de configuration :

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

Envoyer des données à Cloud Logging

Configurez le paramètre credentials_file dans l'échantillon.

Exemple de configuration :

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

Interroger une base de données SQL et envoyer les résultats à Google SecOps

Configurez ces paramètres dans l'échantillon :

Exemple de configuration :

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

Supprimer les journaux qui correspondent à une expression régulière

Vous pouvez configurer le collecteur pour qu'il supprime les journaux qui correspondent à une expression régulière. Cela permet de filtrer les journaux indésirables, tels que les erreurs connues ou les messages de débogage.

Pour supprimer les journaux qui correspondent à une expression régulière, ajoutez un processeur de type filter/drop-matching-logs-to-Chronicle à votre configuration. Ce processeur utilise la fonction IsMatch pour évaluer le corps du journal par rapport à l'expression régulière. Si la fonction renvoie true, le journal est supprimé.

L'exemple de configuration suivant supprime les journaux qui contiennent les chaînes <EventID>10</EventID> ou <EventID>4799</EventID> dans le corps du journal.

Vous pouvez personnaliser l'expression régulière pour qu'elle corresponde au modèle de votre choix. La fonction IsMatch utilise la syntaxe des expressions régulières RE2.

Exemple de configuration :

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

L'exemple suivant ajoute le processeur au pipeline dans la même configuration :

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]

Fonctionnement et maintenance de Bindplane

Cette section décrit les actions de fonctionnement et de maintenance courantes.

Vérifier une configuration OTel

Pour savoir comment vérifier la configuration OTel de Bindplane, consultez OTelBin.

Mises à jour des versions du collecteur

Bindplane peut interroger bindplane-otel-collector/releases pour détecter les nouvelles versions du collecteur. Cette fonctionnalité est facultative.

Vous pouvez désactiver l'interrogation GitHub en définissant agentVersions.syncInterval sur 0 dans votre configuration Bindplane :

agentVersions:
syncInterval: 0

Sauvegarde et reprise après sinistre

Pour en savoir plus sur la sauvegarde et la reprise après sinistre avec Bindplane, consultez les ressources Bindplane.

Sauvegarde et reprise après sinistre de PostgreSQL

Pour en savoir plus sur la sauvegarde et la reprise après sinistre de PostgreSQL avec Bindplane, consultez la documentation PostgreSQL.

Sauvegarde et reprise après sinistre BBolt

Pour en savoir plus sur la sauvegarde et la reprise après sinistre BBolt (obsolète) avec Bindplane, consultez la documentation BBolt Store.

Résilience et nouvelle tentative

La réexécution est activée par défaut pour toutes les destinations qui la prennent en charge. Par défaut, les requêtes ayant échoué sont relancées après cinq secondes, puis l'intervalle entre les tentatives augmente progressivement jusqu'à 30 secondes. Au bout de cinq minutes, les requêtes sont définitivement abandonnées.

Pour en savoir plus, consultez Résilience du collecteur.

Réduire le volume de journaux avec le filtre de gravité

Pour savoir comment réduire le volume de journaux, consultez Réduire le volume de journaux avec le filtre de gravité.

Intégrations Bindplane avec des agents tiers

Bien que Bindplane soit plus puissant lorsque vous utilisez l'agent Bindplane pour la collecte en périphérie, dans la plupart des cas, Bindplane peut rester dans votre infrastructure existante. Par exemple, si vous utilisez déjà Fluent Bit ou Splunk Universal Forwarder, vous pouvez continuer à le faire.

Intégration de Bindplane avec Splunk

Pour en savoir plus sur Splunk avec Bindplane, consultez les ressources suivantes :

Intégrations Bindplane avec d'autres agents tiers

Pour en savoir plus sur les intégrations Bindplane avec des agents tiers, consultez Connecter d'autres collecteurs OpenTelemetry à l'aide de l'extension OpAMP.

Surveillance silencieuse de l'hôte

Pour savoir comment utiliser Bindplane pour la surveillance silencieuse des hôtes, consultez les ressources suivantes :

Mettre à niveau Bindplane sur Linux

Il suffit d'exécuter la commande d'installation sans l'indicateur --init à la fin pour mettre à niveau Bindplane. Exécutez ce script sur votre serveur Bindplane pour mettre à niveau Bindplane. Pour en savoir plus, consultez Mettre à niveau, rétrograder ou désinstaller Bindplane Server.

Surveiller Bindplane

Pour en savoir plus sur la surveillance de BindPlane, consultez Surveillance de BindPlane.

Surveillance dans Kubernetes

Pour en savoir plus sur le monitoring Kubernetes dans Bindplane, consultez Kubernetes Monitoring.

Documentation de référence supplémentaire

Pour en savoir plus sur Bindplane (anciennement observIQ), consultez les ressources suivantes :

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.