このページは Cloud Translation API によって翻訳されました。

Google SecOps で Bindplane を使用する

以下でサポートされています。

Google SecOps SIEM

このドキュメントでは、Google Security Operations 用の Bindplane について説明します。

Bindplane はテレメトリーパイプラインです。任意のソースからログを収集、絞り込み、Google SecOps にエクスポートできます。

Bindplane には、Google 専用の 2 つのエディションがあります。

Bindplane には、次の主要コンポーネントが含まれています。

Bindplane コレクタ。OpenTelemetry（OTel）Collector に基づくオープンソースエージェント。Microsoft Windows イベントログなど、さまざまなソースからログを収集し、Google SecOps に送信します。コレクタはオンプレミスまたはクラウドにインストールできます。このコンポーネントは、OpenTelemetry（BDOT）Collector 用の Bindplane Distribution の Bindplane エージェント、コレクションエージェント、コレクタ、エージェントとも呼ばれます。
Bindplane サーバー。OTel コレクタのデプロイを管理するための包括的で統合されたプラットフォーム。これらのデプロイは、Google SecOps と Google Cloudに存在できます。Bindplane Server は、オンプレミスまたは Bindplane クラウドで実行できます。コンソールの詳細については、Bindplane Management コンソールをご覧ください。このコンポーネントは、Bindplane Observability Pipeline（OP）管理コンソールまたは Bindplane 管理コンソールとも呼ばれます。

Bindplane の Google エディション

Bindplane には、Google 専用の 2 つのエディション（Bindplane（Google エディション）と Bindplane Enterprise（Google エディション））があります。

Bindplane（Google エディション）

Bindplane（Google エディション）は、すべての Google SecOps のお客様に提供されます。

その他のガイダンスについては、次のリソースをご覧ください。

オンプレミスインストールについては、オンプレミスデプロイをご覧ください。
詳細については、OpenTelemetry を活用した業界をリードするオブザーバビリティとセキュリティをご覧ください。

Bindplane（Google エディション）は、Bindplane Cloud でセルフサービスできます。

Bindplane（Google エディション）のインストールとセルフホスティングを開始する方法については、Bindplane（Google エディション）をご覧ください。

Bindplane Enterprise（Google エディション） - Google SecOps Enterprise Plus のお客様向け

Google SecOps Enterprise Plus をご利用のお客様には、Bindplane Enterprise（Google エディション）が含まれています。

大規模なデプロイには、Bindplane Enterprise（Google エディション）をおすすめします。

Bindplane Enterprise（Google エディション）のライセンスキーを取得するには、Google アカウントチームにお問い合わせください。

Bindplane Google エディション - 違い

次の表に、Bindplane Google エディションの違いを示します。

特長	Bindplane（Google エディション）	Bindplane Enterprise（Google エディション）
費用	Google SecOps のすべてのお客様に無料で提供	Google SecOps Enterprise Plus のお客様は無料で利用可能
ルーティング/宛先	Google のみ（Google SecOps、Cloud Logging、BigQuery、Google SecOps 経由の Cloud Storage など）	Google（SIEM 移行のための Google 以外の宛先への 12 か月間のルーティングを含む）
フィルタリング	正規表現を使用した基本フィルタ	高度なフィルタリングプロセッサ（条件、フィールド、重大度などでフィルタリング）、データの削減、ログサンプリング、重複除去
秘匿化	N/A	個人情報（PII）のマスキング
変換	フィールドの追加、フィールドの移動、データの解析（KV、JSON、CSV、XML、タイムスタンプ、正規表現による解析）、フィールドの名前変更、イベントブレーカー	Bindplane（Google エディション）でサポートされているすべての機能に加えて、フィールドの削除、空の値の削除、coalesce が含まれます。
一般的なプラットフォームレベルの機能	Gateway（エージェントからのデータを集約）、収集用の Bindplane エージェント、オンプレミスまたはクラウドホスト用の Bindplane 管理レイヤ、すべてのソース、SecOps プロセッサによるサイレントホストモニタリング、永続キュー、テレメトリーの拡充、HA、RBAC、両方の SecOps 取り込み API のサポート、認証情報の難読化、エージェントのグループ化、動的なログタイプの割り当てなどの高度なフリート管理	Bindplane（Google エディション）でサポートされているすべての機能

Bindplane 管理コンソール

Bindplane 管理コンソールの使用は任意です。Google SecOps の多くのお客様が Bindplane Server を使用しています。

Bindplane Management コンソールには、次の主な機能があります。

一元管理。コンソールを使用すると、 Google Cloud全体で OTel コレクタのすべてのデプロイを管理できます。各デプロイのステータスを表示したり、コレクタの起動、停止、再起動などの一般的な管理タスクを実行したりできます。
リアルタイムモニタリング。コンソールでは、OTel コレクタのデプロイのリアルタイムモニタリングが提供されます。CPU 使用率、メモリ使用率、スループットなどの指標を追跡し、ログとトレースを表示して問題をトラブルシューティングできます。
アラートと通知。コンソールでは、コレクタがダウンした場合や指標のしきい値を超えた場合など、重要なイベントのアラートと通知を設定できます。
構成管理。コンソールを使用すると、OTel コレクタの構成を一元的に管理できます。構成ファイルの編集、環境変数の設定、セキュリティポリシーのすべてのデプロイへの適用を行うことができます。
Google Cloudとの統合。 Google Cloud で OTel コレクタのデプロイを作成して管理し、コンソールを使用して Google Cloud リソースにアクセスできます。

Bindplane エージェントのアーキテクチャ

Bindplane エージェントは、外部依存関係のない軽量のウェブサーバーとして Linux または Docker で実行できます。

Bindplane は BDOT コレクタを使用して、Open Agent Management Protocol（OpAMP）でテレメトリー管理を標準化します。Bindplane を使用して、OpenTelemetry Collector のカスタム ディストリビューションを作成して管理することもできます。

Bindplane OpenTelemetry Collector のデプロイアーキテクチャの詳細については、Bindplane OTel Collector をご覧ください。

以降のセクションでは、使用可能なアーキテクチャオプションについて説明します。

収集エージェントがゲートウェイとして機能する収集エージェントにログを送信する

大規模なデプロイでは、ゲートウェイとして機能する Bindplane Enterprise（Google エディション）エージェントを使用することをおすすめします。これらのゲートウェイは、ネットワーク経由で他のコレクタからテレメトリーを受信し、必要に応じて追加の処理を実行して、データを Google SecOps に転送します。

ゲートウェイとして機能するコレクションエージェントは、他のすべてのコレクションエージェントと同じバイナリを使用します。

次の図は、ゲートウェイとして機能する収集エージェントにログを送信する収集エージェントを示しています。

収集エージェントがゲートウェイとして機能する収集エージェントにログを送信する

収集エージェントはログを Google SecOps 取り込み API に直接送信します

次の図は、収集エージェントがログを Google SecOps 取り込み API に直接送信する様子を示しています。

収集エージェントはログを Google SecOps 取り込み API に直接送信します

収集エージェントがログを Cloud Logging に直接送信する

次の図は、収集エージェントがログを Cloud Logging に直接送信する様子を示しています。

収集エージェントがログを Cloud Logging に直接送信する

収集エージェントが複数の宛先にログを送信する

次の図は、複数の宛先にログを送信する収集エージェントを示しています。

収集エージェントが複数の宛先にログを送信する

Bindplane のデプロイタイプ

Bindplane には、クラウドとオンプレミスのデプロイオプションがあります。

オンプレミスのデプロイ

オンプレミスの Bindplane サーバーの使用には、既存の Google Cloud 利用規約が適用されます。

Linux オンプレミス環境

オンプレミスの Bindplane サーバーは、スクリプトを実行するか（推奨）、バイナリファイルをダウンロードして手動でインストールすることで、Linux にインストールできます。詳細については、Bindplane Server をインストールするをご覧ください。

スクリプトを使用して Linux にオンプレミス Bindplane サーバーをインストールするには、次の操作を行います。

次のスクリプトを実行します。

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
手順に沿って操作すると、サーバーの初期化が完了します。

バイナリファイルを使用して Linux にオンプレミスの Bindplane サーバーをインストールする手順は次のとおりです。

次のいずれかのファイルをダウンロードします。
Bindplane Server を構成するの手順に沿って、構成ファイルを更新します。

オンプレミス環境での Docker のデプロイ

詳細については、Bindplane Server をインストールするをご覧ください。

Linux

Linux ディストリビューション:

Red Hat、Centos、Oracle Linux 7、8、9
Debian 11、12
Ubuntu LTS 20.04 と 22.04
SUSE Linux 12 および 15
Alma Linux と Rocky Linux

詳細については、以下をご覧ください。

Docker コンテナイメージ

Bindplane Docker コンテナイメージは、次の場所にあります。

GitHub パッケージ: ghcr.io/observiq/Bindplane-ee
Google アーティファクトリポジトリ: us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
Docker Hub: observiq/bindplane-ee

コンテナイメージにはリリースバージョンのタグが付けられます。たとえば、リリース v1.35.0 には observiq/bindplane-ee:1.35.0 というタグが付けられます。

技術要件と推奨事項

このセクションでは、Google SecOps で Bindplane をインストールして実行するための技術要件と推奨事項について説明します。

帯域幅の要件

Bindplane は、次のネットワーク接続を維持します。

コレクタ管理
コレクタのスループットの測定
コマンドラインとウェブユーザーインターフェース

接続要件

デフォルトでは、Bindplane はポート 3001 をリッスンします。このポートは構成可能です。

Bindplane ポートは次の目的で使用されます。

OpAMP（WebSocket）を使用したコレクタのコマンドと制御
コレクタスループット測定リクエスト（HTTP POST リクエスト）
ブラウザと CLI ユーザー（HTTP と WebSocket）

コレクタは、OpAMP（WebSocket）とスループット測定（HTTP）のために Bindplane への接続を開始できる必要があります。

Bindplane がコレクタへの接続を開始することはありません。ファイアウォールを構成して Bindplane がコレクタネットワークにアクセスできないようにすることはできますが、コレクタネットワークは構成されたポートで Bindplane にアクセスできる必要があります。

Bindplane コレクタの一般的な技術要件

Bindplane コレクタの一般的な技術要件については、以下をご覧ください。

コレクタリソースの要件

Bindplane のリソース要件は、管理対象コレクタの数によって異なります。マネージドコレクタの数が増加すると、CPU、メモリ、ディスクスループット/IOPS、ネットワーク消費量も増加します。

CPU、メモリ、ストレージ容量のサイジングには、次の表を使用します。

コレクタ数	Bindplane ノード	フォールトトレラント	CPU コアの数	メモリ	データベース
1～100 人	1	なし	2	4 GB	bbolt
100 ～ 25,000	1	なし	4	16 GB	postgres
1 ～ 60,000	3	1	2	8 GB	postgres
60,001 ～ 125,000	5	1	2	8 GB	postgres
125,001 ～ 250,000	10	2	2	8 GB	postgres

インストールとデプロイを計画する

以降のセクションでは、Bindplane のデプロイを計画する際に考慮すべき推奨事項とベストプラクティスについて説明します。

スケーリングとフォールトトレランスを考慮する

ゲートウェイコレクタは、ネットワーク経由でテレメトリーデータを受信します。フォールトトレランスと水平スケーリングの両方を提供するために、ロードバランサとペアにすることをおすすめします。

水平スケーリングは、フォールトトレランスを提供し、エクスポータのボトルネックを解消できるため、推奨されます。

必要なコレクタの数を計算する

ワークロードに必要なコレクタの数を計算するときは、予想されるスループットまたはログレートを考慮し、次の表を使用します。この表は、各コレクタに 4 つの CPU コアと 16 GB のメモリがあることを前提としています。この表にはプロセッサを使用した計算は含まれていません。プロセッサを追加すると、コンピューティング要件が増加します。

テレメトリースループット	ログ/秒	コレクタ
5 GB/m	250,000	2
10 GB/m	500,000	3
20 GB/m	1,000,000	5
100 GB/月	5,000,000	25

フォールトトレランスのためにコレクタフリートをオーバープロビジョニングする

フォールトトレランスを確保するために、コレクタフリートをオーバープロビジョニングします。1 つ以上のコレクタシステムで障害が発生した場合や、メンテナンスのためにオフラインになった場合、残りのコレクタはテレメトリースループットを管理するのに十分な容量を備えている必要があります。

固定数のコレクタを使用している場合は、CPU とメモリの垂直スケーリングを実装してスループットを向上させることができます。

オフロード処理のオーバーヘッド

一般に、コレクタの処理はできるだけ少なくすることが望ましいです。処理要件が厳しい場合は、その処理をゲートウェイコレクタのフリートにオフロードすると便利です。たとえば、コストの高い正規表現演算でテレメトリーをフィルタリングする代わりに、ゲートウェイコレクタにそのタスクを実行させることができます。通常、ゲートウェイコレクタは専用システムで実行されます。ゲートウェイコレクタはデータベースサーバーで実行される可能性がある非ゲートウェイコレクタとは異なり、同じシステムで実行されている他のサービスのコンピューティング能力を消費しないため、この処理オーバーヘッドは正当化されます。

ゲートウェイモードのベストプラクティス

Bindplane コレクションエージェントをゲートウェイとして（つまり、ゲートウェイモード）で使用する場合は、次のベストプラクティスに沿ってデプロイを計画します。

少なくとも 2 つのコレクタをロードバランサの背後に配置します。
各コレクタには、少なくとも 2 つのコアが必要です。
各コレクタには、少なくとも 8 GB のメモリが必要です。
各コレクタには、永続キュー用に 60 GB の使用可能な容量が必要です。

必要に応じてロードバランサを使用する

Bindplane を高可用性モードで運用する場合は、ロードバランサが必要です。

ゲートウェイモードで Bindplane コレクションエージェントを使用する場合は、パフォーマンスと冗長性を高めるためにロードバランサを使用します。ロードバランシングにより、ゲートウェイフリートの水平スケーリングが可能になり、停止を引き起こすことなく障害に耐えることができます。

Bindplane コレクションエージェントは、ゲートウェイモードで動作する場合、さまざまなロードバランサと連携できます。このドキュメントでは、特定のオプションについては説明しません。これは、最も一般的なロードバランシングソリューションが、複数のコレクタを確実に動作させるために必要な機能をサポートしているためです。

詳細については、ロードバランサをご覧ください。

ロードバランシングのポートとプロトコル

Bindplane はデフォルトでポート 3001 をリッスンします。

OpenTelemetry の広範なネットワークベースのレシーバをサポートするには、ロードバランサが次の機能をサポートする必要があります。

TCP/UDP 転送プロトコル
HTTP と gRPC アプリケーションプロトコル

ロードバランシングのサイジング

フォールトトレランスを最大限に高めるには、Bindplane ノードで管理するコレクタの数を 30,000 以下にする必要があります。各コレクタは、Bindplane への 2 つの接続を開きます（1 つは OpAMP リモート管理用、もう 1 つはスループット指標のパブリッシュ用）。この上限により、ほとんどのロードバランサで設定されているバックエンドインスタンスあたりの接続上限（約 65,535 個）を超えないようにできます。

組織に 10 万個のコレクタがある場合、クラスタサイズ 3 では不十分です。各ノードは約 33,000 個のコレクタを担当します。これは、Bindplane インスタンスあたり 66,000 個の TCP 接続に相当します。メンテナンスのために 1 つのノードが停止すると、この状況はさらに悪化します。残りの Bindplane インスタンスがそれぞれ 50,000 個のコレクタまたは 100,000 個の TCP 接続を管理することになるためです。

ロードバランシングのサイジングに関するベストプラクティス

ヘルスチェックを実装する。コレクタがトラフィックを受信する準備ができていることを確認するようにロードバランサを構成します。
接続を均等に分散する。接続はコレクタ間で均等に分散する必要があります。
必要なプロトコルをサポートする。OpenTelemetry の広範なネットワークベースのレシーバをサポートするには、ロードバランサが次の機能をサポートする必要があります。
- TCP/UDP 転送プロトコル
- HTTP と gRPC アプリケーションプロトコル

詳細については、コレクタの復元力をご覧ください。

ソースタイプのロードバランシング

ネットワーク経由でリモートシステムからテレメトリーを受信するソースタイプは、ロードバランシングの候補として適しています。たとえば、次のものがあります。

OTLP
Syslog
TCP / UDP
Splunk HEC
Fluent Forward

本番環境で高可用性モードを使用する

Bindplane インスタンスは、単一インスタンス構成またはマルチインスタンス構成でデプロイできます。高可用性（HA）と復元力を必要とする本番環境デプロイの場合は、マルチインスタンス（HA）デプロイモデルを使用することをおすすめします。

Bindplane が 25,000 個を超えるコレクタを管理する場合は、高可用性（HA）モードで Bindplane を運用することをおすすめします。

Bindplane の HA については、高可用性をご覧ください。

HA 用のコレクタと Bindplane サーバーの数を計算する

Bindplane を HA モードで運用する場合は、各 Bindplane サーバーが処理するコレクタの数を検討する必要があります。

Bindplane インスタンスの合計数から、メンテナンスによって使用不可になることが予想されるノードの最大数を差し引きます。ノードの停止中に各ノードが管理するコレクタの数が 30,000 を超えないようにします。

HA 用の Postgres

HA モードで Bindplane を運用する場合、Postgres が前提条件となります。

HA 用 Prometheus

HA モードで Bindplane を運用する場合は、Prometheus が必要です。

詳細については、Prometheus をご覧ください。

HA 用のイベントバス

Bindplane は、イベントバスを使用して Bindplane 内のコンポーネント間で通信します。HA モードで Bindplane を運用する場合は、イベントバスを使用して Bindplane サーバー間でイベントを送信できます。

詳細については、イベントバスをご覧ください。

テスト環境または概念実証に単一インスタンスデプロイを使用する

テスト環境または概念実証には、単一インスタンスのデプロイを使用することをおすすめします。

詳細については、単一インスタンスをご覧ください。

バックエンド認証情報を分離する

認証情報をすべてのコレクタシステムにデプロイする代わりに、認証情報をゲートウェイコレクタでのみ保持できます。これにより、認証情報のローテーションが簡素化され、認証情報のデプロイをシステムの一部に制限することで、セキュリティ攻撃対象領域が縮小されます。

ゲートウェイコレクタをファイアウォールで保護する

ゲートウェイコレクタは、内部ネットワークからファイアウォールで保護された境界ネットワーク内に配置できます。他のコレクタがデータをゲートウェイコレクタに転送できるように、またゲートウェイコレクタがアプリケーションネットワークにアクセスできないように、ネットワークを構成できます。これにより、エンドポイントにインターネットへの直接アクセス権を付与することなく、クラウドベースのバックエンドにテレメトリーを送信できます。

ファイアウォールで、構成されたポートで HTTP トラフィックが Bindplane に到達できるようにする必要があります。

ファイアウォール構成を確認する

エージェントとインターネットの間にあるファイアウォールまたは認証プロキシには、次のホストへのアクセス権を開放するルールが必要です。

接続タイプ	発信先	ポート
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

本番環境のデプロイに PostgreSQL を使用する

Bindplane の本番環境デプロイには Postgres が必要です。

Postgres は、HA モードで Bindplane を運用するための前提条件です。

通常、CPU コアの数と使用可能なメモリによって、PostgreSQL ストレージバックエンドのパフォーマンスが制限されます。PostgreSQL ストレージは、ソリッドステートドライブ（SSD）などの低レイテンシで高スループットのストレージでバックアップすることをおすすめします。

コレクタ数	CPU コアの数	メモリ
1 ～ 60,000	4	16 GB
60,001 ～ 125,000	8	32 GB
125,001 ～ 250,000	16	64 GB

詳細については、以下をご覧ください。

適切な認証を実装する

Bindplane は、次のプロトコルとサービスによる認証をサポートしています。これらが適切に実装されていることを確認してください。

Azure Entra LDAP。詳細については、Azure LDAP と Bindplane 認証タイプの変更をご覧ください。
LDAP。
OpenID Connect（OIDC）。
ローカル。
SAML。
Postgres TLS。詳細については、Postgres TLS をご覧ください。
Kubernetes。詳細については、GKE Workload Identity をご覧ください。

Bindplane 管理コンソールをインストールする

ほとんどの Google SecOps のお客様は、Bindplane Management コンソールを使用しています。インストールする場合は、storage.googleapis.com へのアクセス権が必要です。エージェントのみをインストールする場合は、このアクセスは必要ありません。

Bindplane Cloud は Google のお客様もご利用いただけます。無料版をダウンロードし、support@bindplane.com にメールを送信して、Google がサポートするバージョンへのアップグレードをリクエストします。

Bindplane Management コンソールをデプロイする方法は 3 つあります。

Bindplane Cloud: Bindplane Server 向けの Bindplane の SaaS サービス。
Linux ホストにダウンロードしてインストールする: DEB パッケージ、RPM パッケージ、Docker イメージとして利用できます。
Google Cloud Marketplace からインストールしてプロビジョニングする。

Bindplane エージェントをインストールする

このセクションでは、さまざまなホストオペレーティングシステムに Google SecOps 用 Bindplane エージェントをインストールする方法について説明します。

通常、エージェントコレクタは最小限のリソースを使用します。ただし、大量のログを処理する場合は、他のサービスに影響を与えないように、リソース消費に注意してください。詳細については、技術要件と推奨事項、インストールとデプロイを計画する、エージェントのサイジングとスケーリングをご覧ください。

OTel エージェントのインストール方法については、Bindplane コレクタのインストールとアンインストールをご覧ください。

エージェントをインストールするには、次のものが必要です。

Google SecOps の取り込み認証ファイル

ファイルをダウンロードするには、次の手順に従います。
1. Google SecOps コンソールを開きます。
2. [SIEM 設定] > [収集エージェント] に移動します。
3. Google SecOps の取り込み認証ファイルをダウンロードします。
Google SecOps のお客様 ID

お客様 ID を確認する手順は次のとおりです。
1. Google SecOps コンソールを開きます。
2. [SIEM 設定] > [プロファイル] に移動します。
3. [組織の詳細情報] セクションからお客様 ID をコピーします。
Windows 2012 SP2 以降、または systemd を使用する Linux ホスト
インターネット接続
GitHub へのアクセス

デプロイツール

このセクションでは、Bindplane のデプロイツールについて説明します。

GitOps

次のものを含む GitOps モデルを使用して Bindplane リソースをデプロイします。

Bindplane 認証
Bindplane CLI
ネットワークアクセス
GitHub リポジトリと GitHub Actions との統合
既存のリソースをエクスポートする
機密性の高い値の管理
GitHub Action ワークフローを確立する
構成のコミットとテスト、自動ロールアウトの有効化、直接編集または UI エクスポート方法を使用したリソースの更新の手順
機密性の高い値を更新して RBAC を使用する

詳細については、GitOps をご覧ください。

Ansible

Ansible を使用した Bindplane のデプロイについては、bindplane-agent-ansible をご覧ください。

Bindplane CLI

Bindplane CLI については、GitOps をご覧ください。

Terraform

Terraform を使用して Bindplane リソースを構成する方法については、Bindplane プロバイダをご覧ください。

Kubernetes

Bindplane を使用した Kubernetes の詳細については、以下をご覧ください。

Windows に Bindplane エージェントをインストールする

Windows に Bindplane エージェントをインストールするには、次の PowerShell コマンドを実行します。

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

または、インストールウィザードを使用してインストールするには、Windows 用の最新のインストーラをダウンロードします。インストーラをダウンロードしたら、インストールウィザードを開き、手順に沿って Bindplane エージェントを構成してインストールします。

Windows に Bindplane エージェントをインストールする方法については、Windows のインストールをご覧ください。

Linux に Bindplane エージェントをインストールする

インストールするパッケージを自動的に決定するスクリプトを使用して、Linux にエージェントをインストールできます。同じスクリプトを使用して、既存のインストールを更新することもできます。

インストールスクリプトを使用してインストールするには、次のスクリプトを実行します。

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

コレクタの構成方法については、bindplane-otel-collect をご覧ください。

ローカルパッケージからのインストール

ローカルパッケージからエージェントをインストールするには、-f を使用してパッケージのパスを指定します。

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

RPM のインストール

リリースページからアーキテクチャ用の RPM パッケージをダウンロードし、rpm を使用してパッケージをインストールします。amd64 パッケージをインストールする例を次に示します。

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

VERSION は、ダウンロードしたパッケージのバージョンに置き換えます。

DEB のインストール

リリースページからアーキテクチャ用の DEB パッケージをダウンロードし、dpkg を使用してパッケージをインストールします。amd64 パッケージのインストールについては、次の例を参照してください。

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

VERSION は、ダウンロードしたパッケージのバージョンに置き換えます。

詳細については、Bindplane エージェントのインストールをご覧ください。

Bindplane エージェントを構成する

エージェントをインストールすると、observiq-otel-collector サービスが実行され、構成の準備が整います。

エージェントは、手動または Bindplane 管理コンソールを使用して構成できます。

エージェントを手動で構成する場合は、エージェントが Google SecOps で認証されるようにエクスポーターパラメータを更新する必要があります。

OTel コレクタ構成ファイル

Linux では、コレクタの構成ファイルは /opt/observiq-otel-collector/config.yaml にあります。

OTel コレクタサービスとログ

エージェントはデフォルトで C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log にログを記録します。

エージェントプロセスの標準エラーログは C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err にあります。

コレクタの構成の詳細については、bindplane-otel-collect をご覧ください。

Linux でコレクタのログを表示するには、sudo tail -F /opt/observiq-otel-collector/log/collector.log を実行します。

一般的な Linux OTel コレクタサービスコマンド:

OTel コレクタサービスを停止するには、sudo systemctl stop observiq-otel-collector を実行します。
OTel コレクタサービスを開始するには、sudo systemctl start observiq-otel-collector を実行します。
OTel コレクタサービスを再起動するには、sudo systemctl restart observiq-otel-collector を実行します。
起動時に OTel コレクタサービスを有効にするには、sudo systemctl enable observiq-otel-collector を実行します。

構成の変更のためにエージェントサービスを再起動する

構成を変更する場合は、構成の変更を有効にするためにエージェントサービスを再起動する必要があります（sudo systemctl restart observiq-otel-collector）。

デフォルトのサンプル構成ファイルを使用する

デフォルトでは、エージェント構成ファイルは C:\Program Files\observIQ OpenTelemetry Collector\config.yaml にあります。

エージェントで使用されるサンプル構成ファイルと認証トークンは、[Google SecOps コンソール] > [SIEM 設定] > [収集エージェント] からダウンロードできます。

構成ファイルで次の 2 つのセクションをカスタマイズします。

レシーバー: エージェントが収集して Google SecOps に送信するログを指定します。
エクスポーター: エージェントがログを送信する宛先を指定します。次のエクスポーターがサポートされています。
- Google SecOps エクスポーター: ログを Google SecOps 取り込み API に直接送信します。
- Google SecOps フォワーダーエクスポーター: Google SecOps フォワーダーにログを送信します。
- Cloud Logging エクスポーター: ログを（Cloud Logging）に送信します。

エクスポーターで、次のようにカスタマイズします。

customer_id: Google SecOps のお客様 ID。
endpoint: Google SecOps リージョンエンドポイント。
creds: 認証トークン。

または、creds_file_path を使用して認証情報ファイルを直接参照することもできます。Windows 構成の場合は、バックスラッシュでパスをエスケープします。
log_type: ログタイプ。[ログタイプ] として [WINDOWS_DNS] を選択することをおすすめします。
ingestion_labels: 取り込みラベル。これらのラベルは、Google SecOps でログを識別します。
namespace: オプションの名前空間。

各ログタイプにはエクスポーターを構成する必要があります。

ログ収集構成のサンプル

以降のセクションでは、ログ収集の構成例を示します。

Windows イベントと sysmon を Google SecOps に直接送信する

サンプルで次のパラメータを構成します。

chronicleexporter
- namespace
- ingestion_labels
- log_type
- customer_id
- creds

構成の例:

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

processors:
  batch:

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

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

Windows イベントと syslog を Google SecOps に直接送信する

サンプルで次のパラメータを構成します。

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

構成の例:

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

Windows イベントと syslog を Google SecOps フォワーダーに送信する

サンプルで次のパラメータを構成します。

構成の例:

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

syslog を Google SecOps に直接送信する

サンプルで次のパラメータを構成します。

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

構成の例:

receivers:
  tcplog:
    listen_address: "0.0.0.0:54525"

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

Windows イベントをリモートで収集し、Google SecOps に直接送信する

サンプルで次のパラメータを構成します。

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

構成の例:

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

Cloud Logging にデータを送信する

サンプルで credentials_file パラメータを構成します。

構成の例:

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

SQL データベースにクエリを実行し、結果を Google SecOps に送信する

サンプルで次のパラメータを構成します。

sqlqueryreceiver
chronicleexporter
- namespace
- ingestion_labels
- log_type
- customer_id
- creds

構成の例:

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

正規表現に一致するログを削除する

正規表現に一致するログを削除するようにコレクタを構成できます。これは、既知のエラーやデバッグメッセージなど、不要なログを除外するのに役立ちます。

正規表現に一致するログを削除するには、filter/drop-matching-logs-to-Chronicle タイプのプロセッサを構成に追加します。このプロセッサは、IsMatch 関数を使用して、ログ本文を正規表現と照合して評価します。関数が true を返すと、ログは破棄されます。

次の構成例では、ログ本文に文字列 <EventID>10</EventID> または <EventID>4799</EventID> を含むログを削除します。

正規表現をカスタマイズして、必要なパターンに一致させることができます。IsMatch 関数は、RE2 正規表現構文を使用します。

構成の例:

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

次の例では、同じ構成のパイプラインにプロセッサを追加します。

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

Bindplane の運用とメンテナンス

このセクションでは、日常的な運用とメンテナンスのアクションについて説明します。

OTel 構成を検証する

Bindplane OTel 構成を確認する方法については、OTelBin をご覧ください。

コレクタリリースアップデート

Bindplane は bindplane-otel-collector/releases をポーリングして、新しいコレクタリリースを検出できます。この機能は省略可能です。

Bindplane 構成で agentVersions.syncInterval を 0 に設定すると、GitHub ポーリングを無効にできます。

agentVersions:
syncInterval: 0

バックアップと障害復旧

Bindplane を使用したバックアップと障害復旧については、Bindplane リソースをご覧ください。

PostgreSQL のバックアップと障害復旧

Bindplane を使用した PostgreSQL のバックアップと障害復旧については、PostgreSQL のドキュメントをご覧ください。

BBolt のバックアップと障害復旧

Bindplane を使用した BBolt（非推奨）のバックアップと障害復旧については、BBolt Store のドキュメントをご覧ください。

復元性と再試行

再試行は、サポートされているすべての宛先でデフォルトで有効になっています。デフォルトでは、失敗したリクエストは 5 秒後に再試行され、最大 30 秒まで段階的にバックオフされます。5 分後に、リクエストは完全に削除されます。

詳細については、コレクタの復元力をご覧ください。

重大度フィルタを使用してログの量を減らす

ログの量を減らす方法については、重大度フィルタを使用してログの量を減らすをご覧ください。

サードパーティエージェントとの Bindplane 統合

BindPlane は、エッジでの収集に BindPlane エージェントを使用するとより強力になりますが、ほとんどの場合、BindPlane は既存のインフラストラクチャ内に留まることができます。たとえば、すでに Fluent Bit または Splunk Universal Forwarder を使用している場合は、引き続き使用できます。

Bindplane と Splunk の統合

Bindplane を使用した Splunk については、以下をご覧ください。

他のサードパーティエージェントとの Bindplane 統合

Bindplane とサードパーティエージェントの統合については、OpAMP 拡張機能を使用して他の OpenTelemetry コレクタを接続するをご覧ください。

Silent Host Monitoring

Bindplane を使用したサイレントホストモニタリングについては、以下をご覧ください。

Linux で Bindplane をアップグレードする

最後に --init フラグを指定せずにインストールコマンドを実行するだけで、Bindplane をアップグレードできます。Bindplane をアップグレードするには、Bindplane サーバーでこのスクリプトを実行します。詳細については、Bindplane Server のアップグレード、ダウングレード、アンインストールをご覧ください。

Bindplane をモニタリングする

Bindplane のモニタリングについては、Bindplane のモニタリングをご覧ください。

Kubernetes のモニタリング

Bindplane での Kubernetes モニタリングについては、Kubernetes モニタリングをご覧ください。

その他のリファレンスドキュメント

Bindplane（以前の observIQ）の詳細については、以下をご覧ください。

さらにサポートが必要な場合 コミュニティメンバーや Google SecOps のプロフェッショナルから回答を得ることができます。

Google SecOps で Bindplane を使用する

Bindplane の Google エディション

Bindplane（Google エディション）

Bindplane Enterprise（Google エディション） - Google SecOps Enterprise Plus のお客様向け

Bindplane Google エディション - 違い

Bindplane 管理コンソール

Bindplane エージェントのアーキテクチャ

収集エージェントがゲートウェイとして機能する収集エージェントにログを送信する

収集エージェントはログを Google SecOps 取り込み API に直接送信します

収集エージェントがログを Cloud Logging に直接送信する

収集エージェントが複数の宛先にログを送信する

Bindplane のデプロイタイプ

オンプレミスのデプロイ

Linux オンプレミス環境

オンプレミス環境での Docker のデプロイ

Linux

Docker コンテナ イメージ

技術要件と推奨事項

帯域幅の要件

接続要件

Bindplane コレクタの一般的な技術要件

コレクタ リソースの要件

インストールとデプロイを計画する

スケーリングとフォールト トレランスを考慮する

必要なコレクタの数を計算する

フォールト トレランスのためにコレクタ フリートをオーバー プロビジョニングする

オフロード処理のオーバーヘッド

ゲートウェイ モードのベスト プラクティス

必要に応じてロードバランサを使用する

ロード バランシングのポートとプロトコル

ロード バランシングのサイジング

ロード バランシングのサイジングに関するベスト プラクティス

ソースタイプのロード バランシング

本番環境で高可用性モードを使用する

HA 用のコレクタと Bindplane サーバーの数を計算する

HA 用の Postgres

HA 用 Prometheus

HA 用のイベントバス

テスト環境または概念実証に単一インスタンス デプロイを使用する

バックエンド認証情報を分離する

ゲートウェイ コレクタをファイアウォールで保護する

ファイアウォール構成を確認する

本番環境のデプロイに PostgreSQL を使用する

適切な認証を実装する

Bindplane 管理コンソールをインストールする

Bindplane エージェントをインストールする

デプロイツール

GitOps

Ansible

Bindplane CLI

Terraform

Kubernetes

Windows に Bindplane エージェントをインストールする

Linux に Bindplane エージェントをインストールする

ローカル パッケージからのインストール

RPM のインストール

DEB のインストール

Bindplane エージェントを構成する

OTel コレクタ構成ファイル

OTel コレクタ サービスとログ

構成の変更のためにエージェント サービスを再起動する

デフォルトのサンプル構成ファイルを使用する

ログ収集構成のサンプル

Windows イベントと sysmon を Google SecOps に直接送信する

Windows イベントと syslog を Google SecOps に直接送信する

Windows イベントと syslog を Google SecOps フォワーダーに送信する

syslog を Google SecOps に直接送信する

Windows イベントをリモートで収集し、Google SecOps に直接送信する

Cloud Logging にデータを送信する

SQL データベースにクエリを実行し、結果を Google SecOps に送信する

正規表現に一致するログを削除する

Bindplane の運用とメンテナンス

OTel 構成を検証する

コレクタ リリース アップデート

バックアップと障害復旧

PostgreSQL のバックアップと障害復旧

BBolt のバックアップと障害復旧

復元性と再試行

重大度フィルタを使用してログの量を減らす

サードパーティ エージェントとの Bindplane 統合

Docker コンテナイメージ

コレクタリソースの要件

スケーリングとフォールトトレランスを考慮する

フォールトトレランスのためにコレクタフリートをオーバープロビジョニングする

ゲートウェイモードのベストプラクティス

ロードバランシングのポートとプロトコル

ロードバランシングのサイジング

ロードバランシングのサイジングに関するベストプラクティス

ソースタイプのロードバランシング

テスト環境または概念実証に単一インスタンスデプロイを使用する

ゲートウェイコレクタをファイアウォールで保護する

ローカルパッケージからのインストール

OTel コレクタサービスとログ

構成の変更のためにエージェントサービスを再起動する

コレクタリリースアップデート

サードパーティエージェントとの Bindplane 統合

他のサードパーティエージェントとの Bindplane 統合

その他のリファレンスドキュメント