Déployer l'agent Bindplane pour la collecte

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. Un 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 peut également être appelé collecteur Bindplane Distribution pour OpenTelemetry (BDOT), agent Bindplane, agent de collecte, collecteur ou agent.

  • Serveur BindPlane. Une 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. De nombreux clients Google SecOps utilisent Bindplane Server, mais son utilisation est facultative. Le serveur BindPlane peut s'exécuter sur site ou dans le cloud BindPlane. Pour en savoir plus sur le serveur, consultez Serveur BindPlane.

    Ce composant peut également être 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 (Google Edition)

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

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

Pour commencer à installer et à auto-héberger BindPlane (Google Edition) ou générer votre clé pour un serveur BindPlane sur site, consultez BindPlane (Google Edition).

Bindplane Enterprise (Google Edition) : pour les clients Google SecOps Enterprise Plus et Google Unified Security (GUS)

Bindplane Enterprise (Google Edition) est inclus pour les clients Google SecOps Enterprise Plus et GUS.

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

Téléchargez votre clé de licence Bindplane Enterprise

Les clients Google SecOps Enterprise Plus et GUS peuvent télécharger leur clé de licence Bindplane Enterprise (Google Edition) directement depuis la console de la plate-forme :

  1. Dans la console Google SecOps, accédez à Paramètres > Gestion des données > Agents de collecte.
  2. Dans la fiche Licence Bindplane, cliquez sur Télécharger la licence pour enregistrer votre fichier de clé de licence.
  3. Appliquez la clé de licence téléchargée à votre installation du serveur BindPlane. Pour en savoir plus, consultez Appliquer une licence BindPlane.

Différences entre les éditions Google de BindPlane

Le tableau suivant présente les différences entre les éditions Google de BindPlane :

Thème/Fonctionnalité Bindplane (Google Edition) Bindplane Enterprise (Google Edition)
Coût Inclus sans frais supplémentaires pour tous les clients Google SecOps Inclus sans frais pour les clients Google SecOps Enterprise Plus
Routage/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és (par exemple, filtrage par condition, champ, gravité, etc.), réduction des données, échantillonnage des journaux, déduplication
Masquage N/A Masquage des informations permettant d'identifier personnellement l'utilisateur
Transformation Ajouter un champ, déplacer un champ, analyser des données (KV, JSON, CSV, XML, code temporel, analyser par expression régulière), renommer un champ, séparateur d'événements Inclut toutes les fonctionnalités compatibles avec BindPlane (Google Edition) plus les fonctionnalités de suppression de champ, de suppression des valeurs vides et de coalescence
Fonctionnalités générales au niveau de la plate-forme Passerelle (agrégation des données des collecteurs), collecteurs Bindplane, serveur Bindplane (couche de gestion Bindplane) sur site ou hébergé dans le cloud, toutes les sources, surveillance des hôtes silencieux via le processeur Google SecOps, file d'attente persistante, enrichissement de la télémétrie, haute disponibilité, RBAC, compatibilité avec les deux API d'ingestion Google SecOps, obscurcissement des identifiants, gestion avancée du parc, y compris le regroupement des collecteurs, attribution dynamique du type de journal Toutes les fonctionnalités compatibles avec BindPlane (Google Edition)

Architecture du collecteur BindPlane

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

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

Pour en savoir plus sur l'architecture de déploiement des collecteurs OpenTelemetry BindPlane, consultez Déploiement.

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

Les collecteurs envoient les journaux à un collecteur agissant en tant que passerelle

Pour les déploiements à grande échelle, nous vous recommandons d'utiliser des collecteurs qui agissent comme des 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 collecteur agissant en tant que passerelle utilise le même binaire que tous les autres collecteurs.

Le schéma suivant montre des collecteurs envoyant des journaux à un collecteur agissant en tant que passerelle :

Les collecteurs envoient les journaux à un collecteur agissant en tant que passerelle

Les collecteurs envoient les journaux directement à l'API d'ingestion Google SecOps

Le schéma suivant montre des collecteurs envoyant des journaux directement à l'API d'ingestion Google SecOps :

Les collecteurs envoient les journaux directement à l'API d'ingestion Google SecOps

Les collecteurs envoient les journaux directement à Cloud Logging.

Le schéma suivant montre des collecteurs envoyant des journaux directement à Cloud Logging :

Les collecteurs envoient les journaux directement à Cloud Logging.

Les collecteurs envoient des journaux à plusieurs destinations

Le diagramme suivant montre des collecteurs envoyant des journaux à plusieurs destinations :

Le collecteur envoie des journaux à plusieurs destinations

Serveur BindPlane

Le serveur BindPlane offre les fonctionnalités clés suivantes :

  • Gestion centralisée. Le serveur vous permet de gérer tous vos déploiements de collecteurs OTel dans Google Cloud. Vous pouvez afficher l'état de chaque déploiement et effectuer des tâches de gestion courantes, telles que le démarrage, l'arrêt et le redémarrage des collecteurs.
  • Surveillance en temps réel. Le serveur fournit une surveillance en temps réel de vos déploiements de collecteurs OTel. Vous pouvez suivre des métriques telles que l'utilisation du processeur, l'utilisation de la mémoire et le débit. Vous pouvez également afficher les journaux et les traces pour résoudre les problèmes.
  • Alertes et notifications. Le serveur vous permet de configurer des alertes et des notifications pour les événements importants, par exemple lorsqu'un collecteur tombe en panne ou qu'un seuil de métrique est dépassé.
  • Gestion de la configuration. Le serveur 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 le serveur pour accéder à vos ressources Google Cloud .

Bindplane propose des options de déploiement dans le cloud et sur site. Pour en savoir plus, consultez Utiliser le serveur BindPlane.

Exigences techniques et recommandations

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

Par défaut, BindPlane écoute sur le port 3001. Ce port est configurable.

Le port Bindplane est utilisé pour :

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

Les collecteurs doivent pouvoir initier des connexions à BindPlane pour OpAMP (WebSocket) et les 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 du collecteur BindPlane

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

Ressources nécessaires pour le collecteur

Les besoins en ressources de Bindplane diffèrent en fonction du nombre de collecteurs gérés. À mesure que le nombre de collecteurs gérés augmente, l'utilisation du processeur, de la mémoire, du débit/des IOPS du disque et du réseau augmente également.

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

Nombre de collecteurs Nœuds BindPlane Tolérance aux pannes Cœurs de processeur Mémoire 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 l'installation et le déploiement

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

Tenir compte du scaling et de la tolérance aux pannes

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

Lorsque vous exécutez des collecteurs BindPlane en mode passerelle, nous vous recommandons de les associer à un équilibreur de charge pour assurer la tolérance aux pannes et le scaling horizontal.

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 prévus, 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 besoins en 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/m 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 mettre en œuvre un scaling vertical de leur processeur et de leur mémoire pour augmenter le débit.

Décharger les frais généraux 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 vers 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 il ne consomme pas la puissance de calcul des autres services exécutés sur le même système, contrairement à un collecteur sans passerelle qui peut être exécuté sur un serveur de base de données.

Bonnes pratiques pour le mode passerelle

Lorsque vous exécutez des collecteurs BindPlane en mode passerelle, nous vous recommandons de planifier 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 requis lorsque vous utilisez BindPlane en mode haute disponibilité.

Lorsque vous exécutez des collecteurs 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'interruption de service.

Le collecteur Bindplane peut fonctionner avec un large éventail d'équilibreurs de charge.

Pour en savoir plus, consultez Configuration de l'équilibreur de charge.

Port et protocoles d'équilibrage de charge

Par défaut, BindPlane écoute sur le port 3001.

Pour prendre en charge le large éventail 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

Les nœuds Bindplane ne doivent pas gérer plus de 30 000 collecteurs pour une tolérance maximale aux pannes. 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 connexion d'environ 65 535 par instance backend imposée par la plupart des équilibreurs de charge.

Si une organisation dispose de 100 000 collecteurs, un cluster de trois nœuds ne suffira pas. 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 arrêté pour maintenance, car chaque instance BindPlane restante gère alors 50 000 collecteurs, soit 100 000 connexions TCP.

Bonnes pratiques pour le dimensionnement de l'équilibrage de charge

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

  • Prenez en charge les protocoles requis. Pour prendre en charge le large éventail 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 basé sur le type de 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 éléments suivants :

  • OTLP
  • Syslog
  • TCP/UDP
  • HEC Splunk
  • 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 d'utiliser Bindplane 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, selon vous, deviendront indisponibles en raison d'une maintenance. Assurez-vous que chaque nœud ne gère pas plus de 30 000 collecteurs lors d'une panne de nœud.

Postgres pour la haute disponibilité

Postgres est un prérequis lorsque vous utilisez BindPlane en mode haute disponibilité.

Prometheus pour la haute disponibilité

Prometheus est requis lorsque vous utilisez 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 haute disponibilité, 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 démonstration de faisabilité

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

Pour en savoir plus, consultez Instance unique.

Isoler les identifiants de backend

Au lieu de déployer des identifiants sur tous vos systèmes de collecteurs, 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.

Protéger vos collecteurs de passerelle par un pare-feu

Vous pouvez placer des collecteurs de passerelle dans un réseau périphérique, protégé par un pare-feu du réseau interne. Vous pouvez configurer votre réseau pour autoriser vos autres collecteurs à 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 dans 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 (API Ingestion)

Tous les pare-feu ou proxys authentifiés entre le collecteur 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

Prérequis pour l'ingestion Google SecOps avec Bindplane

Cette section décrit les conditions préalables à l'ingestion de données dans Google SecOps à l'aide de Bindplane, en particulier lorsque vous utilisez l'API Chronicle Ingestion.

Exigences réseau pour l'API Chronicle (HTTPS)

Lorsque vous utilisez BindPlane avec l'API Chronicle Ingestion, qui utilise HTTPS, assurez-vous que vos configurations de réseau et de pare-feu autorisent les connexions sortantes vers les points de terminaison de l'API Chronicle.

Si votre organisation utilise des restrictions de pare-feu basées sur l'adresse IP, vous devez tenir compte de la nature dynamique des adresses IP Google Cloud . Étant donné que Google SecOps n'est pas compatible avec l'ajout d'adresses IP statiques à la liste d'autorisation pour les API d'ingestion, il n'est pas recommandé de s'appuyer uniquement sur des adresses IP statiques, car cela peut entraîner des échecs d'ingestion.

Pour maintenir l'ingestion continue des données, tenez compte des points suivants :

  • Liste d'autorisation basée sur le domaine : nous vous recommandons de configurer votre pare-feu pour autoriser le trafic HTTPS sortant (port 443) vers l'ensemble du domaine *.chronicle.googleapis.com.
  • Points de terminaison régionaux : Bindplane doit être configuré pour utiliser le point de terminaison régional approprié pour votre instance Google SecOps, par exemple us-chronicle.googleapis.com, europe-chronicle.googleapis.com, etc. Vous trouverez la liste complète des points de terminaison régionaux dans la documentation Migrer de l'ancienne API SIEM vers l'API Chronicle.
  • Mises à jour automatiques des adresses IP : si l'ajout à la liste d'autorisation basé sur le domaine n'est pas possible, vous devez mettre en place un système automatisé pour récupérer et mettre à jour régulièrement les plages d'adresses IP associées à *.chronicle.googleapis.com. Les plages d'adresses IP actuelles pour les API Google peuvent être obtenues à partir des fichiers goog.json et cloud.json, comme décrit dans la documentation sur les adresses IP de Google. Mettez en place un système pour mettre à jour de manière dynamique vos règles de pare-feu en fonction de ces sources.

Utiliser PostgreSQL pour les déploiements de production

Postgres est requis pour les déploiements en production de BindPlane.

Postgres est un prérequis pour utiliser 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, comme des disques durs 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 :

Utiliser le serveur BindPlane

La plupart des clients Google SecOps utilisent le serveur BindPlane, mais son utilisation est facultative. Si vous installez le serveur BindPlane, vous devez avoir accès à storage.googleapis.com. Si vous n'installez qu'un collecteur, cet accès n'est pas requis.

Pour voir une démonstration de la configuration du serveur Bindplane pour standardiser les journaux et les exporter vers Google SecOps, accédez à Démonstrations de cas d'utilisation de Bindplane, puis sélectionnez Configuration de Google SecOps.

Utiliser le serveur BindPlane Cloud

Bindplane Cloud est disponible pour les clients Google.

Connectez-vous à l'édition Google.

Pour tout problème lié à Bindplane Cloud Server, contactez l'assistance Bindplane. Pour tout problème lié au serveur BindPlane sur site, contactez l'assistance Google SecOps.

Utilisez le serveur BindPlane sur votre Google Cloud

Pour savoir comment exécuter le serveur Bindplane sur votre Google Cloud, consultez Bindplane Enterprise Edition.

Utiliser le serveur sur site Bindplane

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

Installer le serveur sur site sous Linux

Vous pouvez installer le serveur BindPlane sur site sous 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://downloads.bindplane.com/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh

  2. Suivez les instructions qui vous guident tout au long de l'initialisation du 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.

Distributions Linux compatibles :
  • 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 :

Déploiements Docker sur site

Pour en savoir plus, consultez Installer le serveur BindPlane.

Vous trouverez les images de conteneurs 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 la release : par exemple, la release v1.35.0 aura le tag observiq/bindplane-ee:1.35.0.

Installer le collecteur BindPlane

Cette section explique comment installer le collecteur Bindplane pour Google SecOps sur différents systèmes.

Les collecteurs utilisent généralement un minimum de ressources. Toutefois, lorsque vous traitez de grands volumes de journaux, tenez compte de la consommation de ressources pour éviter d'avoir un impact sur d'autres services. Pour en savoir plus, consultez Exigences techniques et recommandations, Planifier l'installation et le déploiement et Dimensionnement et scaling des agents.

Pour savoir comment installer le collecteur (c'est-à-dire l'agent OTel), consultez Bindplane OTel Collector.

Vous pouvez également consulter la documentation GitHub bindplane-otel-collector.

Pour installer le collecteur, vous avez besoin des éléments suivants :

  • Fichier d'authentification d'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 > Gestion des données > Agents de collecte.
    3. Téléchargez le fichier d'authentification d'ingestion Google SecOps. L'étape suivante dépend de votre méthode de transfert :
      • gRPC : utilisez le fichier d'authentification téléchargé.
      • HTTPS : créez un compte de service dans le projet Google Cloud associé à Google SecOps et attribuez-lui le rôle Éditeur Chronicle.

  • Numéro client Google SecOps

    Pour trouver le numéro client, procédez comme suit :

    1. Ouvrez la console Google SecOps.
    2. Accédez à Paramètres > Administration > 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 comprend 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'interface utilisateur
  • Mettre à jour des valeurs sensibles et utiliser le RBAC

Pour en savoir plus, consultez GitOps.

Ansible

Pour en savoir plus sur le déploiement de 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 le collecteur Bindplane sous Windows

Pour installer le collecteur 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 effectuer l'installation à l'aide d'un assistant d'installation en téléchargeant le dernier programme d'installation pour Windows. Après avoir téléchargé le programme d'installation, ouvrez l'assistant d'installation et suivez les instructions pour configurer et installer le collecteur BindPlane.

Pour en savoir plus sur l'installation du collecteur BindPlane sur Windows, consultez Installation sur Windows.

Installer le collecteur BindPlane sous Linux

Vous pouvez installer le collecteur sous 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

Installation à partir d'un package local

Pour installer le collecteur à 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 RPM

Téléchargez le package RPM correspondant à votre architecture depuis 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é.

Installation DEB

Téléchargez le package DEB correspondant à votre architecture depuis la page des versions, puis installez-le à l'aide de dpkg. Reportez-vous à 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.

Configurer le collecteur BindPlane

Après l'installation du collecteur, le service observiq-otel-collector s'exécute et est prêt à être configuré.

Vous pouvez configurer le collecteur manuellement ou à l'aide du serveur BindPlane.

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

Fichier de configuration du collecteur OTel

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

Service et journaux du collecteur OTel

Par défaut, le collecteur consigne les journaux dans C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

Le journal d'erreur standard du processus du collecteur se trouve dans C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

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 collecteur OTel Linux :

  • Pour arrêter le service de collecteur 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 collecteur 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 du collecteur pour que les modifications de configuration

Lorsque vous modifiez la configuration, vous devez redémarrer le service de collecteur pour que les modifications de configuration 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 collecteur se trouve dans C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

Pour télécharger un exemple de fichier de configuration et de jeton d'authentification utilisé par le collecteur :

  • Ouvrez la console Google SecOps, puis accédez à Paramètres > Gestion des données > Agents de collecte.

Personnalisez les deux sections suivantes dans le fichier de configuration :

  • Récepteur : spécifie les journaux que le collecteur doit collecter et envoyer à Google SecOps.
  • Exportateur : spécifie la destination vers laquelle le collecteur envoie les journaux. Les exportateurs suivants sont compatibles :
    • Exportateur Google SecOps : envoie les journaux directement à l'API d'ingestion Google SecOps.
    • Exportateur de redirecteur Google SecOps : envoie les journaux au redirecteur 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 référencer directement le 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 : étiquettes d'ingestion. Ces étiquettes 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 de journaux.

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

Configurez ces paramètres dans l'exemple :

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.",
  "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.",
  "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.",
  "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.",
  "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'exemple :

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'exemple :

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 syslog directement à Google SecOps

Configurez ces paramètres dans l'exemple :

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

Collectez des événements Windows à distance et envoyez-les directement à Google SecOps.

Configurez ces paramètres dans l'exemple :

  • 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'exemple.

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'exemple :

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.",
  "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.",
  "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 correspondant à une expression régulière. Cette fonctionnalité est utile pour 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 contenant 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 à n'importe quel modèle. La fonction IsMatch utilise la syntaxe d'expression régulière 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]

Exploitation et maintenance de BindPlane

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

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 Ressources Bindplane.

Sauvegarde et reprise après sinistre PostgreSQL

Pour en savoir plus sur la sauvegarde et la reprise après sinistre 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 de BBolt (obsolète) avec BindPlane, consultez la documentation sur le magasin BBolt.

Résilience et nouvelle tentative

La nouvelle tentative est activée par défaut sur toutes les destinations compatibles. 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 supprimé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 des journaux, consultez Réduire le volume des journaux avec le filtre de gravité.

Intégrations Bindplane avec des collecteurs tiers

Bien que Bindplane soit plus puissant lorsque vous utilisez le collecteur 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 à Splunk

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

Intégrations de BindPlane avec d'autres collecteurs tiers

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

Surveillance silencieuse de l'hôte

La surveillance des hôtes silencieux de Google Security Operations vous permet de créer des alertes pour les changements de taux d'ingestion à l'aide de Google Cloud Monitoring. Elle génère des alertes par collecteur et vous avertit lorsque le taux d'ingestion passe sous le seuil que vous avez défini, ce qui indique un arrêt potentiel du collecteur.

Pour en savoir plus sur l'utilisation de Bindplane pour la surveillance des hôtes silencieux, consultez les ressources suivantes :

Mettre à niveau BindPlane sous Linux

Il suffit d'exécuter la commande d'installation sans l'option --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 le serveur BindPlane.

Surveiller BindPlane

Pour savoir comment surveiller BindPlane, consultez Surveiller BindPlane.

Surveiller Kubernetes dans BindPlane

Pour savoir comment surveiller Kubernetes dans BindPlane, consultez Surveillance de Kubernetes.

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